Repository navigation
fix(mate): a bare change's own title, and a describe through HQ's roll - #38
Merged
Merged
Conversation
R12-15: a backend and a storefront both read the session's long task as
their changes' titles for seven minutes, until the Mate described them.
A change was opened with the work session's intent, which is the same line
in every repository the session touched.
A change no description has reached is now titled by what it holds: the
subject of the newest commit beyond main the Mate wrote (no merge, no
commit of zcp's own, no zcp init), else the files that differ from main
("Add index.js and package.json"), else "Mate: <hostname>", cut at a word
as before. Every commit zcp writes carries a "Delivered-by: zcp" trailer so
its own words are never read as the Mate's. A push retitles a change while
its body is empty; once described, the title is the Mate's. A delivery
still commits the deployed tree under the task's words.
…g a draft HQ's Core rolls for about 20 s. A describe that met it failed once, nothing tried it again, and the change stayed a draft. describe-change now tries its calls to HQ again — a growing wait apart, a minute in all, each call sent once and bounded — while HQ is not reached (refused, reset, no connection within the bound) or answers 502, 503 or 504. HQ's own refusal (a 4xx, a 500) and a try HQ connected for and left unanswered stay final. A picture upload that meets a 5xx is HQ not serving it, no longer read as HQ refusing the picture. When the minute is spent the answer says plainly that the description did not land and the change is still a draft, the words kept. Deliveries still fail fast.
…istory The briefing asks every repository for a baseline commit before any change. With zcp's own commits skipped, that commit stayed the Mate's newest one, so every repository's change read "baseline commit" and R12-15 was back. And a checkout that took a squash in by an ordinary merge, before deliveries started from a fresh base, still held the landed change's commits, so a new change could be titled by one that had already landed. The briefing now writes the baseline under a "Zcp-Commit: baseline" trailer, and zcp's own trailer becomes "Zcp-Commit: delivery"; a change's title skips any commit with that key. For checkouts from before the marker, a commit under "baseline commit" or sitting on the pair's zcp init or on the join of the repository's base is skipped too. History that already landed, refs/zcp/landed/* and each landedHead of a merged change the Mate's state lists, or the pair records, is left out.
title is optional on describe-change, and retitling stopped once a change
had a body, so a describe without a title froze zcp's title of the moment
("baseline commit", before the last fix), and that title became main's
squash subject. And a delivery read the title, then retitled it: a describe
from another chat landing in between was written over.
The pair now records the title zcp last gave its change (ZcpTitle), and a
delivery retitles the change only while HQ still holds that title. A
describe without a title leaves it zcp's, following the work; one with a
title drops the record, so the title is the Mate's for good. A describe now
holds the pair's checkout as a delivery does, so the two never interleave;
held past the wait, it writes nothing and says so.
Requiring title on a describe was the other way: it would refuse the Mate
and still need the record to know whose title HQ holds.
…its change through the roll A retried describe whose PATCH reached HQ but whose answer was lost said "did not land ... still a draft", while the change was described. HQ has no read of a change's words to check, so the answer now says so: when every try surely never reached HQ (refused, no connection within the bound, a standby's own 503) the words did not land; when one may have (a connection dropped after the words were sent, a balancer's 502 or 504), they may not have landed, and describing again with the same words changes nothing. With no change on record, the describe read the Mate's state once, and HQ's roll made it answer "No change is open". That read is now tried as the description is, and HQ staying away is said as not knowing which change is open, with nothing written or kept.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A change's title and description from a long Mate run, and the review's findings.
A bare change's title
main, or its changed files, never the session's intent. Both repositories of one session used to share the session's long intent as their title.Zcp-Commit: baseline) and skipped, as are zcp's own delivery commits (Zcp-Commit: delivery) and history that already landed.A describe through HQ's rolling deploy
Tests for each case;
go testpasses for tools, ops, workflow and content,go vetis clean, and golangci-lint reports no issues.🤖 Generated with Claude Code