Skip to content

feat(template): just finish and just signoff fail when a session receipt is missing or the reviewer is an author #451

Open

Description

@pascalandy

Outside the plan: Pascal assigned this card on 2026-11-03, through the grooming of Epic 18. Its pull request says that it is outside the plan. Refined on 2026-11-04 after the decision of #450 (D069). Pascal approved the split into four Stories.

Problem

just finish accepts any reviewer name that is not empty (sdk/extensionrepo/readiness.go line 30). The ledger accepts any change reviewer and readiness reviewer that are not empty (sdk/extensionrepo/ledger.go line 78).

Goal

just finish and a detached just signoff fail when a session receipt is missing, or when the reviewer ID is equal to an author ID. Pascal chose this rule on 2026-11-03 (option 3a). D069 decides the mechanism: author receipts and review receipts in Git notes under refs/notes/nicely-sessions. This Story applies the rule. The capture and the receipts are the other Stories of Epic 18.

Acceptance rules

  1. An extension records its adoption commit as the boundary. Finished rounds before that boundary stay legacy: no tool adds IDs to them or changes their claims. An open round that crosses the boundary starts a new captured round. This follows D069 section 5.
  2. just finish and a detached just signoff fetch the notes ref and freeze its object ID before they check. They require each item of D069 section 6:
    • The source HEAD is the full head SHA of the completed review, and the base is the base of the round.
    • Each commit of the enforced range has a complete author receipt from a supported capture.
    • The review receipt comes from a completed new root launch, with no missing capture and no open required finding.
    • The reviewer ID is different from each author ID of the round.
    • The source HEAD and the frozen receipt set do not change during the checks and the status publication.
  3. The checks need no active harness, no session ID in the environment and no ID argument.
  4. Each failure names the field or the SHA and gives a fix: a recording instruction or a re-review instruction.
  5. The signoff reports the frozen receipt set that it checked, because Git notes are metadata that a user can edit.
  6. The contract, the template skill and the rule index call this proof "a different recorded session". They say that it does not prove independent reasoning, a different human or a different model (D069 section 8).

Examples

  • Success: the author session a1 writes the round, the reviewer session r7 reviews it, and just finish passes.
  • Failure: the reviewer ID is a1. just finish fails and names the reviewer field.
  • Failure: the reviewed head has no review receipt. just finish fails and gives the re-review instruction.
  • Failure: a detached just signoff cannot fetch the notes ref. It fails and posts no status.

Check

Scenarios under testdata/script/ prove each example, with two authors in one round. scripts/template-test.sh passes. The pull request quotes a real build in a scratch extension: a Claude Code author and a Codex reviewer, with two different recorded IDs.

by Opus-5.5 via Claude Code

Activity

  1. added
    2-type:featureNew or improved functionality; specification lives in the issue
    3-pty:p2Normal planned work; default when no priority is established
    on Nov 3, 2026
  2. added
    1-needs-infoSpecific information is missing from the issue
    1-ready-for-agentValidated work, sufficiently specified for an autonomous agent
    and removed
    1-needs-infoSpecific information is missing from the issue
    on Nov 3, 2026
  3. changed the title [-]feat(template): just finish fails when the reviewer session is missing or is an author session[/-] [+]feat(template): just finish and just signoff fail when a session receipt is missing or the reviewer is an author[/+] on Nov 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    1-ready-for-agentValidated work, sufficiently specified for an autonomous agent2-type:featureNew or improved functionality; specification lives in the issue3-pty:p2Normal planned work; default when no priority is established

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions