Skip to content

docs(decisions): record the session ID of each author and of the reviewer #450

Closed

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.

Problem

just finish accepts any reviewer name that is not empty (sdk/extensionrepo/readiness.go line 30, ledger.go line 78). Pascal chose on 2026-11-03 to replace that name with recorded session IDs (option 3a). No decision says how a build records these IDs:

  • Claude Code hooks and Codex hooks receive a session ID.
  • A Codex subagent hook reports the ID of its parent.
  • No code records session IDs today (sdk/extensionrepo/records.go lines 49-92).

Goal

A decision in docs/north-star/decisions/ says how a build records the session ID of each author and of the reviewer, without text that the agent types. A scratch extension proves the decision on Claude Code and on Codex.

Acceptance rules

The decision answers each of these questions:

  1. Which hook or launcher gives the ID, for each harness, and from which version.
  2. Who installs that hook, and where: the template, the user, or ncly.
  3. How each commit of a round maps to the session that wrote it.
  4. How the reviewer ID is captured and bound to the reviewed commit.
  5. What happens to rounds before an extension adopts the rule.
  6. What a detached just signoff checks.
  7. Why a reviewer in a Codex subagent fails, and how the skill starts the reviewer in a separate session instead.
  8. Why the proof is called "a different recorded session", and not independent reasoning.

Examples

  • Success: in a scratch extension, a Claude Code session writes a commit, a Codex session reviews it, and the record holds two different IDs that nobody typed.
  • Failure: the decision needs the agent to type its own ID.

Check

The decision is merged. The pull request quotes the two recorded IDs of the scratch extension and the parent ID that a Codex subagent reports.

by Opus-5.5 via Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    2-type:taskSupporting work such as maintenance, documentation, refactoring, or verification3-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