docs(records): Sage lead handover, rows 23-25 state, row 8 stub, BUILD-LOG rebuilt on HEAD

Records Jason's 2026-09-26 ruling: Sage leads the project, Darkwing is a
collaborating seat, development stays in T3, and the old ~/.mosaic fleet is
being retired. The lead role adds no push, merge or deploy authority.

- QUEUE rows 23-25 show their commits and pushes; row 8 links a parked stub
  brief listing the rulings Jason must make before fleet seats move.
- Shared records from Darkwing (rows 6, 16, 18, 22, #1511, #1512) and Dewey
  (row 5) that were waiting on one owner for the shared files.
- DEFERRED: T3 headers counted as human in the ledger (#1506), #1509 engine
  test leak and busy gap, #1512 re-run outcome.
- BUILD-LOG.md rebuilt as HEAD plus the uncommitted entries; the working copy
  had dropped the row 23-25 entries. Diff against HEAD is additions only.

All eight suites green. Not pushed.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

AGENTS.md

@@ -47,19 +47,106 @@ green at every step. Not production software — a proven foundation.
 9. **Append-only logs**: BUILD-LOG.md (phases), `activation-log.jsonl`,
    `.pruned.log`, docs/SESSIONS.md. Corrections are new entries, never edits.
 
+## Autonomous operation within an agreed plan
+
+Autonomy starts after alignment, not before it. For a new substantial assignment,
+recover the applicable mission, goal, task, `CURRENT.md` state, and prior owner
+decisions, then work with the user to establish a plan of action: the intended
+outcome, acceptance evidence, boundaries, and any gated actions. Recommend a
+concrete plan instead of presenting an open-ended menu. A direct request or
+existing approved plan that already settles those points is sufficient alignment;
+do not ask for ceremonial reconfirmation.
+
+Once the plan is established, carry it to verified completion without prompting
+for routine decisions or permission to take the next in-scope step. Authorization
+persists for the life of that assignment unless the user changes or revokes it.
+Treat mid-session user input as steering: incorporate it, update the plan or
+tracking record when needed, and continue.
+
+### Decide and continue
+
+- Resolve naming, implementation approach, layout, and similar non-breaking
+  choices from, in order: repository invariants and role policy, the approved
+  plan and acceptance criteria, established repository conventions, then the
+  smallest reversible option. Record a consequential choice and its tradeoff.
+- Perform the in-scope investigation, edits, tests, documentation, and tracking
+  needed for end-to-end acceptance. Do not ask whether to add obviously required
+  tests or documentation.
+- Diagnose failures and retry or remediate within the agreed scope. Fix a defect
+  when it blocks acceptance or is local to files already being changed; otherwise
+  record a bounded follow-up without expanding the assignment.
+- Resolve minor ambiguity in favor of the mission, goal, north star, and prior
+  owner decisions. State the assumption in the completion report.
+- Never stop merely to ask whether to proceed, which routine option to use, or
+  whether to execute the next step already contained in the plan.
+
+### Re-align or stop only at a real boundary
+
+Finish all independent work first, then ask one focused question only when:
+
+1. Two plausible readings materially change the outcome and the choice is costly
+   to reverse.
+2. The next action would exceed the agreed scope or authority, introduce an
+   unapproved breaking public/API/schema/data/policy change, or alter a security
+   boundary.
+3. Credentials or access are missing and no in-scope path remains.
+4. The action is destructive, irreversible, production-affecting, incurs spend,
+   or communicates externally on the user's behalf without explicit authority.
+5. Objectives or owner decisions genuinely conflict and repository evidence
+   cannot resolve them.
+6. A fail-closed policy refusal or another agent's overlapping ownership prevents
+   safe progress. Diagnose and report it; never route around it.
+
+Repository gates still apply. In particular, a successful implementation or a
+broad request to “finish” does not by itself authorize push, merge, deployment,
+release, production changes, policy/role expansion, or access to secrets. Perform
+such an action only when the established plan explicitly includes it. If blocked,
+report the exact boundary, what is complete, the recommended resolution, and the
+specific action that will resume; do not use “waiting for confirmation” as a
+substitute for a real blocker.
+
 ## Session protocol (mandatory)
 
 - **Register** your session in `docs/SESSIONS.md` — one append-only line
   (date, actor, scope, outcome). Never rewrite or remove entries.
 - **Cadence**: read `docs/plans/QUEUE.md` first; your next piece is the first
-  row you own that is briefed, in progress or in review, nothing else. Open only
-  the brief that row links to. Execute it fully (implement → test → verify against acceptance criteria → commit →
-  push → close issue) → move your QUEUE.md row → register in SESSIONS.md.
+  row you own that is briefed, in progress or in review, unless Jason has named
+  an explicit current priority in that queue. Open only
+  the brief that row links to. Execute it through every authorized stage (implement → test → verify against acceptance
+  criteria; commit, push, or close only when the established plan authorizes
+  each) → move your QUEUE.md row → register in SESSIONS.md.
 - "next" means one action. A batch mandate ("run the queue") repeats the
-  loop until green or blocked. Blocked means stop and report, never improvise.
+  loop until green or truly blocked under the boundary rules above.
 - Substantial work gets a Gitea issue and a BUILD-LOG phase entry
   (before/after, with corrections recorded honestly).
 
+## Internal development bootstrap
+
+Jason's current direction is repository-native development in
+`/mnt/storage/src/mosaic-stack`. Sage leads the project (Jason's ruling,
+2026-09-26) and coordinates coding, review and research through Darkwing, Dewey,
+Filbert, Rocko, Researcher and any further seats Jason launches under `agents/`.
+Darkwing is a collaborating agent seat, not the coordinator. Development sessions
+run in T3 for now. Work moves to the new stack; the old `~/.mosaic` fleet is being
+retired, and a fleet seat acting outside Jason's instructions is the failure this
+transition exists to prevent.
+Do not assign new development work to fleet seats during this bootstrap phase.
+Do not modify `~/.mosaic` launchers, provisioning or other state, or stop/migrate
+live fleet processes as part of this work. Preserve existing work and histories.
+Use the repository bootstrap/configuration and launch entry points; missing
+configuration still fails closed. This changes development coordination, not
+managed worker role policy or deployment authority. The lead role adds no push,
+merge or deployment authority; those still need Jason's say-so. See
+`agents/README.md` for the internal roster.
+
+For control-board attention, start a completed reply with `Input needed: ` and
+one specific nonempty request only when Jason must provide a decision or input.
+Put that line at column zero, before other text. Do not use it for routine
+completion or a wait on another agent. Ordinary completed replies are idle.
+Use code fences or blockquotes when showing this convention as an example.
+The signal is advisory status, never permission for a protected action. Seen
+acknowledges a request; it does not resolve it. See `packages/control-board/README.md`.
+
 ## Role model
 
 - **Conductor**: a system-scoped role — not an agent, not a daemon. Holds