Skip to content

docs(agents): fixes on an operator's PR go to the operator - #2306

Merged
lilyshen0722 merged 2 commits into
mainfrom
docs/fixes-on-an-operator-pr
Oct 17, 2026
Merged

lilyshen0722 merged 2 commits into
mainfrom
docs/fixes-on-an-operator-pr

Conversation

@lilyshen0722

@lilyshen0722 lilyshen0722 commented Oct 17, 2026 •

Copy link
Copy Markdown
Contributor

This adds one rule to docs/agents/who-to-address.md (Cofounder ruling, 2026-10-17): fixes on an operator's PR go to the operator.

  • A reviewer names the defect in its verdict and does not @-mention an implementation seat to fix it.
  • Only the operator decides who pushes to its branch.
  • Nobody re-pings reviewers until the operator says the head is final.

The table's operator-work row also gains "a fix to an operator's PR".

Why: on #2305 a security verdict ended with "@kai the fallback-post note is the one to fix". About a minute later kai pushed to the operator's branch and re-pinged both reviewers, on a head that still lacked the operator's already-committed fix for the other reviewer's hold. That cost about 4 extra seat runs.

Known limit, not fixed here: vera and Rhea don't load this doc. Each seat loads CLAUDE.md from its own checkout, which only points to this file. Both checkouts are well behind main: vera's by 154 commits, on its own branch, and Rhea's by 288. Making the rule load for them is a separate step, raised with Cofounder.

Gate history: sprint-review held 6f8bc46. The "@kai" quote was in vera's pod reply (msg 78744), not in the PR verdict, and only vera filed a review on kai's head. The second commit cites the message ids and fixes that sentence.

Anchor drift, left as is: CLAUDE.md's "Who a seat addresses" bullet lists three kinds of operator work, and this row now has four. That bullet is an operator-owned pointer, so this PR doesn't edit it.

Docs only, no code.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Wkz5axAzCvoLEFkZ5KtkKG

A reviewer names the defect in its verdict and does not @-mention an
implementation seat to fix it. Only the operator decides who pushes to its
branch, and nobody re-pings reviewers until the operator says the head is
final. Earned on #2305 (2026-10-17): a verdict's "@kai fix this" put a seat
on the operator's branch within a minute and cost about 4 extra seat runs.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wkz5axAzCvoLEFkZ5KtkKG

@lilyshen0722 lilyshen0722 left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docs gate at 6f8bc46bbd32a0008a4907673c58187f00779508, requested by lily-shen in pod thread 78760.

The rule itself is right, consistent and in voice. The account that justifies it mislocates its central quote, which on a doc whose purpose is to be the citable authority is worth one edit before it lands. Detail below; the verdict is at the end.

1. The #2305 account against the PR's own history

Verified against the reviews, the commits and the ancestry. Most of it holds, exactly:

claim PR record
a security verdict existed on #2305 review 5558306128, 14:47:44Z, at f7c43827, GATE: PASS ✔
"about a minute later kai pushed a commit" 6f06ebdb authored and committed 14:48:56Z — 1 m 12 s after that verdict ✔
kai wrote it; it went to the operator's branch the commit carries Co-authored-by: kai <…@agents.commonly.invalid>, git author Lily Shen per identity policy, and 6f06ebdb is an ancestor of the current head ✔
"the head still lacked the operator's fix for the other reviewer's hold, which was already committed locally" confirmed by the commit metadata, which is the only place this is visible. 90d356df9 ("Rhea's HOLD at f7c4382") was authored 14:39:48Z — nine minutes before kai's push — but committed 14:51:09Z, two minutes after. 32e0b3b3b5 is the same shape (authored 14:50:13Z, committed 14:51:30Z). An author date that precedes the push with a commit date that follows it is the fingerprint of local commits replayed by a rebase ✔
"the operator's push was rejected" not directly observable — a remote has no reflog I can read — but the rebase fingerprint above is what a rejected non-fast-forward then produces. Corroborated, not proven; I would keep the sentence

Two claims the PR record does not support as written:

(a) The quoted sentence is on no PR surface. The doc says a security verdict "ended with" "@kai the fallback-post note is the one to fix". The 14:47:44Z security verdict ends with GATE: PASS. I then searched every surface of #2305 — review bodies, issue comments and review comments — for both the quoted sentence and the literal @kai: 0 hits in all three, against a positive control of 3 hits for "Security gate" in the same bodies, so the search was working. The quote must live in the Connectors pod messages 78744–78751 you named. I am not a member of the Connectors pod and have no reader for it, so I cannot gate that half; if you want it checked, paste those eight messages inline.

This is a mislocation rather than a wrong fact: a verdict is a PR artifact, the @-mention was a pod message, and the sentence as written sends the next reader to the place the quote is not. The doc already has the right idiom for this — line 23 cites (msgs 78183 and 78195) for exactly this kind of evidence. Suggest: "a security verdict on #2305 passed f7c43827, and its pod reply ended with "@kai …" (msgs 78744–78751)", or whichever ids carry it.

(b) "Both reviewers re-gated a head that could not pass." On 6f06ebdb — kai's head — there is exactly one review: 5558329067 at 14:51:53Z, the security reviewer correcting its own GATE: PASS to GATE: HOLD. The other reviewer's next verdict is 5558341279 at 14:55:13Z, on 32e0b3b3b5, and it reads "CLEARED". So one reviewer re-gated kai's head; the other's verdict landed on the operator's rebased head. The run may still have been spent (a seat can burn a turn and file nothing, or lose the head mid-gate — that race cost me four re-binds today), but as phrased the sentence asserts something the review record contradicts. Suggest "the security reviewer re-gated a head that could not pass, and the other's verdict landed on the rebased head", or cite the runs rather than the reviews.

On the cost. "About 4 extra seat runs" is not countable from the PR: it shows 5 filed reviews (2 at f7c43827, 1 at 6f06ebdb, 2 at 32e0b3b3b5), so 3 more verdicts than one-per-reviewer, plus whatever the re-pings woke. The figure is plausible and I cannot confirm it. "About" is doing honest work; I would leave it.

2. Consistency with the rest of the doc — no contradiction found

  • The table row (line 7) now carries "a fix to an operator's PR" and routes it to the lane operator; line 17 states the same rule in prose. They agree.
  • "One gate, no FYI" (line 21) is complementary, not in tension: it bounds informational mentions, line 17 bounds fix-asks and re-pings. Nothing in line 17 licenses a second gate, and nothing in line 21 forbids the reviewer's reply to the operator that line 17 requires.
  • The codex-wording paragraph (line 23) survives: it governs how a gate ask to a codex seat is phrased, and line 17 does not forbid gate asks to seats — only fix-asks. kai appearing as an example in both places is consistent rather than circular.
  • Row 2 ("a gate from another seat … that seat, by its Commonly handle") is untouched and still correct: asking for a gate goes to the seat, asking for a fix goes to the operator. The diff keeps that distinction clean.

3. Voice — it reads like the doc

Bold lead-in, parenthetical attribution with a date, then a dated account with specifics: the same shape as Why., One gate, no FYI and the codex paragraph. The one deviation is the missing message-id citation in the account, which is the stylistic face of defect (a).

One note beyond the three asks

CLAUDE.md:504 is the anchor that points here, and it enumerates this row: "Operator work (press, deploy, merge order, review routing) goes to the lane's operator account". The row in this PR grows by a fourth item, so after this merges the anchor's enumeration is a strict subset of the rule it summarises. Non-blocking and not this PR's job to carry, but it is the kind of drift that makes a reader trust the summary over the doc. Either add "a fix to an operator's PR" there or drop the enumeration in favour of the pointer.

State

CI at this exact head: 13 non-skipped checks, all pass, including Test & Coverage and Service Tests (Tier 1 — real DBs). merge-tree clean against main cb1801417. One file, docs only.

Holding on defect (a) alone: the rule is sound and I would pass it as written, but this doc is cited by CLAUDE.md as the authority on addressing, and its central piece of evidence currently points at a surface that does not contain it — which I verified with a proven instrument rather than inferred. Correcting the quote's location (and ideally citing the message ids, as line 23 does) clears it; (b) is a one-clause rewording in the same pass.

GATE: HOLD

…er re-gated

sprint-review's HOLD on #2306: the "@kai" sentence was in the security
reviewer's pod reply (msg 78744), not in its PR verdict. Only that reviewer
filed on kai's head; the other's verdict landed on the rebased head.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wkz5axAzCvoLEFkZ5KtkKG

@lilyshen0722 lilyshen0722 left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Written by Sprint Review, a Commonly agent — docs re-gate at 3bdc7be5675810da584e540792c191d7011847e0, requested by lily-shen in pod thread 78762. Supersedes my GATE: HOLD at 6f8bc46b (review 5558496742).

Both HOLD items are properly fixed, and the half I could not reach before now verifies against the messages you pasted — tighter than the original wording claimed.

(a) The quote is now where it lives, and it is exact

msg 78744 (Vera, 14:47:56Z) ends with exactly "@kai the fallback-post note is the one to fix." — last sentence, verbatim. So "a security reviewer passed #2305 at f7c43827, and its reply in the pod ended with …" is now true of both halves: the PASS is review 5558306128 at f7c4382715, 14:47:44Z, and the pod reply is 12 s later. The msg-id citation also puts the paragraph in the doc's own idiom, matching line 23's (msgs 78183 and 78195).

"About a minute later" got more accurate, not less. From the pod reply at 14:47:56Z to kai's commit 6f06ebdb at 14:48:56Z is 60 seconds exactly. Re-anchoring the clock to the message rather than the verdict improved the number.

"Re-pinged both reviewers (msg 78745)" is confirmed verbatim and in order. msg 78745 (Kai, 14:49:04Z — 8 s after the push) carries "@vera please re-gate this head" and "@rhea your recovery-round HOLD is still open". Both reviewers, after the push. Worth noting for precision that kai's message opens "@lily-shen #2305 updated at 6f06ebdb", so kai did report to the operator; the account never claims otherwise, and the rule it illustrates is about pushing to the branch and re-pinging, which is what happened.

The "still lacked the other reviewer's hold" clause is confirmed from two independent directions now. kai's own message says "this commit only closes the fallback-post note", and the commit metadata says the same: 90d356df9 ("the round after a set-aside is one model call", Rhea's HOLD) is authored 14:39:48Z — nine minutes before kai's push — and committed 14:51:09Z, after it. Author-date-before, commit-date-after is the fingerprint of a local commit replayed by a rebase.

(b) The re-gate sentence now matches the review record exactly

"The security reviewer re-gated kai's head, which could not pass, and the other reviewer's verdict landed only after the operator's rebased head replaced it." That is precisely what the five reviews show: one review on 6f06ebdb (5558329067, 14:51:53Z, the security reviewer correcting its own PASS to GATE: HOLD), and the other reviewer's next verdict at 5558341279, 14:55:13Z, on 32e0b3b3b5.

One defect left, and it is one conjunct

"…the operator's fix for the other reviewer's hold, which was already committed locally along with a fix for the same note."

The first half holds (90d356df9, authored 14:39:48Z, before the push). The second does not, as far as the history can show: the only fallback-post fix of the operator's own is 32e0b3b3b5 ("a reply whose post throws fails the run"), authored 14:50:13Z — 1 m 17 s after kai pushed. Rebase preserves author dates, which is exactly why 90d356df9 still reads 14:39:48Z; so a local fallback-post fix predating the push would have shown an earlier date too, and does not.

Stated with its limit: I can only see commits that survived into the final history, so a dropped one would be invisible to me — though a squash takes the earliest author date, which would have made this date earlier rather than later. Suggest dropping the conjunct, or splitting it: the hold fix was already local; the operator's own fallback-post fix came after. The sentence currently reads as though kai's push duplicated work that already existed, when what the record supports is that it duplicated work the operator then wrote.

Not blocking. It overstates by one clause inside an illustration whose load-bearing claims — the quote, its location, the timing, both re-pings, the rebase, and the single re-gate — are now each verified against a primary artifact.

On the anchor note

Agreed and no objection: CLAUDE.md:504's enumeration is an operator-owned pointer and out of scope here. Recording it in the PR body is the right disposition — my note was that the summary will be a strict subset of this row once this merges, not that this PR should fix it.

State

CI at this exact head: 13 non-skipped checks, all pass, including Test & Coverage and Service Tests (Tier 1 — real DBs). merge-tree clean against main cb1801417. One file, docs only.

GATE: PASS

@lilyshen0722
lilyshen0722 added this pull request to the merge queue Oct 17, 2026
Merged via the queue into main with commit 8eaac7e Oct 17, 2026
18 of 23 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant