@tyroneross/build-loop 0.36.0 → 0.43.0

package/skills/architecture/review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: build-loop:architecture-review
-description: Use when Phase 4 Review covers a build that crosses 2+ layers, or the user asks for an "architectural review" or "full integrity check". Covers system flow, component connections, documentation drift, and lessons; heavy-weight, native copy from NavGator.
+description: Full architectural integrity pass — system flow, connections, documentation drift, and lessons in one report. Use when the user asks for "an architectural review" or "full integrity check" on a build crossing 2+ layers. Not for a single violation/orphan pass (use `architecture-rules`) — this is the heavier superset.
 version: 0.1.0
 user-invocable: false
 source: NavGator/skills/code-review/SKILL.md

package/skills/architecture/rules/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: build-loop:architecture-rules
-description: Use when Phase 4 Review checks architectural integrity, the user asks to "check for violations" or "find circular deps", or before a release. Detects orphans, layer violations, circular dependencies, and hotspots; build-loop's native rules engine from NavGator.
+description: Detect structural rule violations — layer violations, circular dependencies, and connection hotspots. Use when the user asks to "check for violations" or "find circular deps". Not for code with zero callers (use `architecture-dead`) or a full narrative review (use `architecture-review`).
 version: 0.1.0
 user-invocable: false
 source: NavGator/commands/test.md
@@ -11,7 +11,7 @@ source_hash: 4a967c08ff3d7cddd408e7caefcd07b09e8931bcaccf9ea70c0f5aa94349e0d1
 
 # Architecture Rules / Violation Check
 
-Run NavGator's rules engine to detect architectural violations using the `mcp__plugin_navgator__rules` MCP tool. Classifies findings as blocking (circular dependency, layer violation, database isolation breach, frontend-direct-DB at error level) vs warning (hotspot, high-fan-out, orphan).
+Run NavGator's rules engine to detect architectural violations using the `mcp__plugin_navgator__rules` MCP tool. Classifies findings as blocking (circular dependency, layer violation, database isolation breach, frontend-direct-DB at error level) vs warning (hotspot, high-fan-out, orphan, shallow-module).
 
 > **Divergence note**: NavGator has no discrete SKILL.md for rules. The canonical wrapper is `commands/test.md`, which orchestrates `navgator rules` + `navgator dead` + pipeline traces. This skill extracts the rules-only workflow.
 
@@ -34,7 +34,7 @@ Run NavGator's rules engine to detect architectural violations using the `mcp__p
 | Severity | Categories |
 |----------|-----------|
 | **Blocking** | `circular-dependency`, `layer-violation`, `database-isolation`, `frontend-direct-db` (error level) |
-| **Warning** | `hotspot`, `high-fan-out`, `orphan` |
+| **Warning** | `hotspot`, `high-fan-out`, `orphan`, `shallow-module` (thin pass-through: high fan-out, low fan-in — advisory design guidance, never blocks) |
 
 3. Diff against the Phase 1 baseline if present in `.build-loop/state.json.architecture.rules.baseline`
 4. Flag recurrences against `.navgator/lessons/lessons.json` (lessons with matching `signature`)

package/skills/architecture/scan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: build-loop:architecture-scan
-description: Use when Phase 1 Assess detects stale architecture state, the user asks for an "architecture scan", or before blast-radius analysis. Refreshes Build Loop's native component and connection data in `.build-loop/architecture/`, with NavGator reserved for escalation-only capabilities.
+description: Refresh build-loop's native component/connection data before any other architecture check runs. Use when the user asks for "an architecture scan" or Phase 1 Assess finds the data stale. Not for finding violations or dead code — `architecture-rules`/`architecture-dead` need this data first.
 version: 0.1.0
 user-invocable: false
 source: NavGator/skills/architecture-scan/SKILL.md

package/skills/architecture/trace/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: build-loop:architecture-trace
-description: Use when the user asks to "trace data flow", "follow this request end-to-end", or "show how X reaches Y". Follows a component's connections from input to output across the architecture; build-loop's native trace copied from NavGator's CLI.
+description: Follow one component's connections end-to-end, input to output. Use when the user asks to "trace data flow", "follow this request end-to-end", or "show how X reaches Y".
 version: 0.1.0
 user-invocable: false
 source: NavGator/commands/trace.md

package/skills/attribution-standard/SKILL.md

@@ -8,7 +8,7 @@ user-invocable: false
 
 # Attribution Standard
 
-Four overlapping mechanisms make stripping attribution either illegal, mechanically tedious, or detectable. Each survives a different removal pattern. The research backing this skill is at `~/dev/research/apache-2.0-attribution-watermarking-2026-05-22.md`.
+Four overlapping mechanisms make stripping attribution either illegal, mechanically tedious, or detectable. Each survives a different removal pattern. The research backing this skill is "Apache-2.0 Attribution & Watermarking" (private research note, 2026-05-22 — substance summarized here).
 
 ## The four layers
 
@@ -21,9 +21,9 @@ Four overlapping mechanisms make stripping attribution either illegal, mechanica
 
 ## Canonical strings
 
-Apply identically wherever they appear. Memorise these — do not paraphrase.
+**These are build-loop's own values** (this repo's actual copyright holder) — use them verbatim only when stamping attribution onto build-loop itself. **Applying this skill to any OTHER repo requires the target repo's own name/email/years**, not these: derive from `git config user.name` / `user.email` in that repo, an existing LICENSE/NOTICE holder if one is already present, or ask the user. The `attribution_stamp.py` script's `--name`/`--email`/`--years` flags default to the build-loop values below if omitted — **always pass all three explicitly for a non-build-loop repo**; never invoke the script bare against someone else's repo.
 
-| Field | Value |
+| Field | Value (build-loop's own) |
 |---|---|
 | Copyright holder | `Tyrone Ross, Jr` |
 | SPDX email tail | `<46267523+tyroneross@users.noreply.github.com>` |
@@ -57,9 +57,9 @@ For Python-heavy repos with no `src/` directory (like agent-rally-point), pass t
 ```bash
 python scripts/attribution_stamp.py \
   --repo <path-to-repo> \
-  --name "Tyrone Ross, Jr" \
-  --email "46267523+tyroneross@users.noreply.github.com" \
-  --years 2025-2026 \
+  --name "<target repo's copyright holder — NOT build-loop's, unless stamping build-loop itself>" \
+  --email "<target repo owner's email/SPDX tail>" \
+  --years <target repo's applicable year range> \
   --canary-files <path1> <path2> \
   [--paths <override-paths...>] \
   [--restamp]

package/skills/auto-decision-capture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: auto-decision-capture
-description: Project-scoped skill for proactive in-session decision capture. Provides Claude the signal taxonomy, confidence ladder, overwrite rules, and the three extraction prompts (SPO triplet / MADR-aligned / batch consolidation) so substantive decisions land in build-loop-memory without manual triggering. Use when the user makes a substantive choice, confirms a proposal, or implies a constraint with textual evidence.
+description: Passively capture a substantive decision the user just made, in real time, into build-loop-memory. Fires automatically when the user confirms a choice or states a constraint — not user-invoked. Not for findings/issues (use `auto-finding-capture`), after-the-fact review (use `recursive-retrospective`), or surfacing an unstated call the user never saw so he can reverse it (use `silent-assumptions`).
 user-invocable: false
 when_to_use: |
   - User issues a direct verbal marker ("let's go with X", "ship it", "use Y")
@@ -231,7 +231,9 @@ python3 scripts/recall.py --query "test framework"
 ## Extraction prompts (inline reference)
 
 These three prompts are the canonical extraction templates from
-`~/dev/research/topics/repo-episodic-memory-framework/repo-episodic-memory-framework.md` §12.
+"Repo Episodic Memory Framework" (private research note — substance
+summarized here; see §12), reproduced in full below so this skill has
+no dependency on the note being present.
 Use them whenever you need to extract structured decisions from
 unstructured conversation. Keep temperature low (0.1–0.3).
 
@@ -418,3 +420,30 @@ candidate, and promotes via `scripts/memory_writer.py --type lesson|feedback`
 complementary: this skill catches what you can see during the turn; the
 companion catches what the deterministic scanner can find at the end of
 the session.
+
+## The decision-surface family — one core, several variants
+
+Four skills share one job: put a set of calls in front of the user and capture a
+ruling. They differ only in the KIND of call, so they share a core rather than
+forking one — the variant registry (`scripts/decision_surface.py`), the
+interactive page and its save/self-publish plumbing
+(`skills/decision-queue/assets/template.html`), and the durable writer
+(`scripts/write_decision/__main__.py`). **Adding a variant is a registry entry,
+never a fork of the core.**
+
+**Choose by the question the user is actually asking, never by name.** An agent
+that picks on name alone reaches for the one it already knows and rebuilds
+something that exists.
+
+| Member | Answers | Layer | Does work stop? |
+|---|---|---|---|
+| [`silent-assumptions`](../silent-assumptions/SKILL.md) | "What did you decide without me?" | surface | No — work continued under your default |
+| [`decision-queue`](../decision-queue/SKILL.md) | "What is waiting on me?" | surface | Yes — work has stopped |
+| [`auto-decision-capture`](../auto-decision-capture/SKILL.md) | "What did we already settle, and where is it written down?" | capture | No — fires passively |
+| [`auto-finding-capture`](../auto-finding-capture/SKILL.md) | "What concrete issues has anyone surfaced?" | capture | No — fires passively |
+
+`python3 scripts/decision_surface.py` prints this table (`--json` for machines).
+The registry is the one place a member is declared; this table is its prose
+mirror and must match it.
+
+**You are here: `auto-decision-capture`.** Reach for `silent-assumptions` when the user never saw the call at all and you need it rendered for a ruling; this skill records a decision the user already made, it does not surface one he did not know about.

package/skills/auto-finding-capture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: auto-finding-capture
-description: Project-scoped skill documenting build-loop's DEFAULT-ON auto-capture of clearly-identified findings/issues into the backlog, regardless of which terminal or agent surfaced them. Provides the detection contract, routing rules, dedup strategy, and the standing rule that agents/critics must NOT gate identified issues behind a user selection. Use when an agent, audit, or critic surfaces a concrete severity-labeled issue, or when reasoning about where findings persist.
+description: Passively capture a concrete, severity-labeled finding or issue into the backlog, in real time. Fires automatically whenever an agent, audit, or critic surfaces one — never gated behind a user selection. Not for decisions (use `auto-decision-capture`) or for a judgement call the agent made without asking, which is not a defect and does not belong in the backlog (use `silent-assumptions`).
 user-invocable: false
 when_to_use: |
   - Any agent/audit/critic states a concrete, severity-labeled issue in the session
@@ -117,3 +117,30 @@ An LLM-judged extraction path (for findings stated without a severity label or a
 finding keyword) is a possible future extension. v1 is deterministic-only by
 design: it satisfies the acceptance contract, adds no dependency, and keeps
 precision high. Add the LLM path only against a named, observed miss in this repo.
+
+## The decision-surface family — one core, several variants
+
+Four skills share one job: put a set of calls in front of the user and capture a
+ruling. They differ only in the KIND of call, so they share a core rather than
+forking one — the variant registry (`scripts/decision_surface.py`), the
+interactive page and its save/self-publish plumbing
+(`skills/decision-queue/assets/template.html`), and the durable writer
+(`scripts/write_decision/__main__.py`). **Adding a variant is a registry entry,
+never a fork of the core.**
+
+**Choose by the question the user is actually asking, never by name.** An agent
+that picks on name alone reaches for the one it already knows and rebuilds
+something that exists.
+
+| Member | Answers | Layer | Does work stop? |
+|---|---|---|---|
+| [`silent-assumptions`](../silent-assumptions/SKILL.md) | "What did you decide without me?" | surface | No — work continued under your default |
+| [`decision-queue`](../decision-queue/SKILL.md) | "What is waiting on me?" | surface | Yes — work has stopped |
+| [`auto-decision-capture`](../auto-decision-capture/SKILL.md) | "What did we already settle, and where is it written down?" | capture | No — fires passively |
+| [`auto-finding-capture`](../auto-finding-capture/SKILL.md) | "What concrete issues has anyone surfaced?" | capture | No — fires passively |
+
+`python3 scripts/decision_surface.py` prints this table (`--json` for machines).
+The registry is the one place a member is declared; this table is its prose
+mirror and must match it.
+
+**You are here: `auto-finding-capture`.** Reach for `silent-assumptions` when the thing to surface is a judgement call YOU made rather than a defect you found; a silent assumption is not a finding and does not belong in the backlog.

package/skills/build-loop/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: build-loop
 description: "Orchestrated build loop for multi-step code work. TRIGGER on verb language ('build', 'implement', 'create', 'add', 'ship', 'wire up', 'integrate', 'refactor', 'migrate', 'rewrite', 'replace') OR symptom language ('fix', 'broken', 'doesn't work', 'isn't loading', 'not displaying', 'missing', 'should show', 'needs to', 'make it', 'show this differently') OR any task touching 2+ files, adding/removing an endpoint, crossing an architectural boundary, or attached screenshots of a bug. SKIP one-line edits, pure Q&A, conversational clarifications, status checks, and trivial typos/renames."
-user-invocable: true
+user-invocable: false
 ---
 
 <!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
@@ -26,22 +26,24 @@ Intent → internal mode:
 - **Root-cause analysis**: blameless RCA producing durable system levers — "root cause", "why did this fail", "post-mortem" (delegates to the `root-cause-analysis` skill).
 - **Retrospective**: recursive learning retrospective on a build/project — "retrospective", "retro", "what did we learn", "review this project's trajectory" (delegates to `recursive-retrospective`). *Example: "I need a root cause and a retrospective" → run does both.*
 - **Plan / spec**: "write a plan", "spec this" → spec-writing + plan-verify.
+- **Repository maintenance / closeout**: repository structure, duplicate source, sibling consolidation, build artifacts, branches, worktrees, stashes, or local-main closeout → `repo-maintenance` (`repo-closeout` remains a temporary compatibility alias).
 - **PRD**: "start a PRD", "spec out a new app" → prd-bridge / start-prd flow.
 - **Self-improve / promote / knowledge / handoff / memory setup**: "scan recent runs", "promote this experiment", "record a decision", "hand this off", "set up memory" → the matching internal skill (self-improve, promotion-reviewer, knowledge, handoff, setup-memory).
+- **Drain proposals**: "drain proposals", "review the proposal backlog", "what proposals are open" → the `drain-proposals` skill. Interactive and never auto-applies; every item needs an explicit apply / reject / defer.
 
 **Design intent:** one command for humans, plain-language routing, everything else agent-invoked within build-loop. If a request doesn't match a mode, run treats it as a Build task or asks one clarifying question — it never makes the user pick a command.
 
 ### Parallelism config
 
-Fan-out width is machine-aware. The cap is `effective_max_implementers(workdir)` from `scripts/parallelism.py`: `min(config.parallelism.maxImplementers, cpu_count−2, hard ceiling 12)`, defaulting to 8 when no config is present.
+Fan-out width is supervisor-controlled. `autonomy_supervisor.py fanout` resolves `parallelism.py` capacity, then applies live backpressure. Effective width is the minimum of independent MECE work, project/request capacity, CPU headroom, cloud token budget, shared cross-session capacity, and the absolute ceiling of 150. Default project capacity remains 8.
 
-To raise the cap toward the hard ceiling, set in `.build-loop/config.json`:
+To set a project preference, use `.build-loop/config.json`:
 
 ```json
 { "parallelism": { "maxImplementers": 8 } }
 ```
 
-Values above 12 are clamped. Values above `cpu_count−2` are clamped to `cpu_count−2` to leave headroom for the orchestrator and host OS.
+The preference never forces that many workers. The supervisor admits only independent chunks supported by live resource and provider telemetry. Values above 150 are clamped; local capacity also preserves two CPU cores for the orchestrator and host OS.
 
 ## Autonomous Mode + Per-Commit Mode
 
@@ -50,7 +52,7 @@ Both are conditional modes — their flag tables, budget/iteration caps, questio
 - the invocation carries `--long` / `--budget` / `--autonomous=false`, or the goal text matches a long-running keyword (`overnight`, `large-scale`, `multi-day`, …) → **Autonomous Mode** detail;
 - `state.json.selfRecursive.enabled` is true, or the invocation carries `--per-commit` / `--no-per-commit` → **Per-Commit Mode** detail.
 
-Default behavior with none of those signals: classic single-pass Phase 1–6, 2h budget, autonomous queue-drain on. The end-of-run `issues/` then `backlog/` drain is a SHIPPED DEFAULT (2026-06-04), reversible per-repo via `.build-loop/config.json` `sessionPrefs.continueFromQueues: "never"`.
+Default behavior with none of those signals: classic single-pass Phase 1–6, 2h budget, autonomous execution-queue drain on. Backlog items stay deferred until class-aware promotion at a planning boundary; initiatives and decisions never auto-promote.
 
 ## Scope Check
 
@@ -102,6 +104,30 @@ Self-heal is **both reactive and proactive**. It is not only triggered by errors
 
 **Closure test (counterfactual):** a root cause is not closed at "an actionable control." It is closed only when the named lever would have **prevented, detected, or contained THIS exact failure on the real input** (not a hand-constructed one) — a control that exists but stays dormant on the real signal does not count. **Fix strength:** prefer the strongest feasible control — `eliminate → impossible-state → automated-block → detect → contain → decision-support → docs` — over the reflex "add a detect-gate." A dependency you don't own is never "ignore it": isolate / validate / monitor / degrade / escalate / accept-residual-risk explicitly.
 
+### Finding disposition — "pre-existing" is not a decision (C-FINDINGS / every_finding_dispositioned)
+
+Every finding a run surfaces — lint, type, security, scanner or detector warning, failing or skipped test, deprecation, contract drift — reaches exactly one terminal state before "done": **fixed**, **waived against a durable record**, or **escalated as a new record**. "Pre-existing" says when a defect arrived, never whether it may stand. A report that names a warning and moves on has disclosed it, not dispositioned it; across runs that is how a repo accretes permanent warnings every future run re-observes and re-dismisses at full token cost.
+
+Route each finding: **inside** the run's owned files → fix it (C-HEAL self-heal, then C-RCA to root cause). **Outside** them → escalate and record — `scripts/backlog.py new` for this repo, `scripts/file_to_operations_center.py` for any other (`references/keep-going-policy.md` §"Flagged-issue default route") — and report the returned id. Scope bounds what a run FIXES; it never bounds what a run RECORDS, so out-of-scope findings get handed off rather than absorbed. **Genuinely acceptable** → waive, and only against a durable record:
+
+```bash
+python3 scripts/waivers.py check --repo "$PWD" --rule <id> --path <file> [--anchor <sym|line:N>] --json   # exit 0 = already waived
+python3 scripts/waivers.py new   --repo "$PWD" --rule <id> --path <file> --rationale "..." --authority "user|agent:<name>|decision:<path>" --expires "<date|version|until-file-changes>"
+```
+
+**Before filing a finding that a value is factually WRONG about the world, search (C-CLAIMS/search_before_contradicting_code).**
+Company and product names, rebrands, acquisitions, model IDs, versions, pricing, API
+signatures, deprecations, legal names: all of these change after a model's cutoff, so
+disagreeing with one is a prompt to search, never a finding on its own. Two tells that
+the code is right and the model is stale: the value sits among siblings that are plainly
+correct, or a migration/repair script/test already treats the other value as legacy. A
+search costs seconds; a wrong correction to a world-fact ships a regression and fights
+whatever migration already encodes the new value. Walk the tree in
+`references/research-trigger-policy.md` §"Encounter Trigger" — it fires in ANY phase,
+including runs whose goal carries no research signal, which is exactly when this misses.
+
+An agent's own unrecorded "out of scope" or "not mine" is not a waiver, and a user's spoken waiver counts only once written. Every waiver names its expiry; absent one it defaults to re-surfacing the next time its covered file changes. Phase 4G carries the `## Findings disposition` table — one row per finding, its state, and the record it points at.
+
 ### Follow-up auto-drain at chunk boundary
 
 A chunk boundary is not a checkpoint. When the orchestrator (or any session under the build-loop skill) is about to write a final report containing a "still-to-do" / "deferred" / "next pass" list of same-shape, same-intent items, route those items through the follow-up queue instead of writing them to the user as prose questions:
@@ -139,6 +165,8 @@ their brief explicitly hands them a bounded implementation task.
 
 **Codex permission gate**: generic Build Loop wording such as "parallel-safe groups" is not by itself authorization to spawn Codex subagents. In Codex, spawn workers only when the user explicitly asks for delegation/parallel agent work or uses a command flag such as `--parallel`. Without that signal, keep execution local while preserving the MECE plan.
 
+**System-access requests**: before a read-only command could trigger a macOS administrator or privacy request, run it through `scripts/system_access_request.py` with a specific `--purpose`, `--scope`, and `--requester`. The wrapper prints that explanation before dispatch, records the first request, and makes identical callers wait. A dispatched denial, cancellation, or failure never triggers an automatic retry; only a process that failed before dispatch is retryable. Use this path for `sfltool dumpbtm`; do not invoke it directly.
+
 **Native agent-rally capabilities**: build-loop vendors `skills/agent-rally-point/SKILL.md` and `skills/agent-rally-watcher/SKILL.md` as embedded mini-plugin skills. Use those skill entrypoints for Rally Point substrate or watcher work before reaching for the standalone repos. The grouped extraction contract is `scripts/rally_point/plugin_boundary.json`; validate it with `python3 scripts/agent_rally.py boundary --repo "$PWD" --check --json`.
 
 **Ephemeral plan cleanup**: never delete a `.build-loop/plan*.md` or
@@ -146,7 +174,7 @@ their brief explicitly hands them a bounded implementation task.
 build-loop-memory via `python3 scripts/archive_project_plan.py <plan> --workdir
 "$PWD"`. Use `--remove-source` only after the archive write succeeds.
 
-**Coding-host coordination polling gate**: when a build-loop task involves more than one coding host, an active rally-point peer, an active coord file, any `inbox/<tool>.jsonl` message, or any `inbox/all.jsonl` broadcast, the current host must keep a cheap watcher live while work is in flight. Rally/coordination output is routing metadata only, not verification evidence; use it to decide who to coordinate with, then verify code/package/release facts against the authoritative source. Use a stable tool id (`claude_code`, `codex`, `cursor`, etc.). Run a one-shot status check first:
+**Coding-host coordination polling gate**: when a build-loop task involves more than one coding host, an active rally-point peer, an active coord file, any `inbox/<tool>.jsonl` message, or any `inbox/all.jsonl` broadcast, the current host must keep a cheap watcher live while work is in flight. Rally/coordination output is routing metadata only, not verification evidence; use it to decide who to coordinate with, then verify code/package/release facts against the authoritative source. Set `TOOL_NAME` to the stable host family (`claude_code`, `codex`, `cursor`, etc.) and `SESSION_ID` to the stable host session. Build Loop qualifies that pair into an exact native Rally actor; Build Loop local fallback deliberately keeps the base tool plus session id. Run a one-shot status check first:
 
 ```bash
 python3 scripts/coordination_status.py --workdir "$PWD" --session-id "$SESSION_ID" --tool "$TOOL_NAME" --json
@@ -158,7 +186,7 @@ If the status has `active_peers`, `coordination_file`, `inbox_unread_count > 0`,
 python3 scripts/coordination_watch.py --workdir "$PWD" --session-id "$SESSION_ID" --tool "$TOOL_NAME" --interval 5 --jsonl --baseline-current
 ```
 
-Keep that process attached in the host's tool/session mechanism and poll it before commits, before final responses, and after any 30s work interval. When it emits a revision or inbox change, immediately rerun `coordination_status.py --tool "$TOOL_NAME"`, then run `python3 scripts/rally_point/inbox.py read --workdir "$PWD" --tool "$TOOL_NAME" --json` to read the resolved-channel inbox for `<tool>` plus the common broadcast inbox, and post the required channel response. Do not ask the user to paste peer messages that are already present in the rally channel, the addressed inbox, or the common broadcast inbox.
+Keep that process attached in the host's tool/session mechanism and poll it before commits, before final responses, and after any 30s work interval. When it emits a revision or inbox change, immediately rerun `coordination_status.py --tool "$TOOL_NAME" --session-id "$SESSION_ID"`, then run `python3 scripts/rally_point/inbox.py read --workdir "$PWD" --tool "$TOOL_NAME" --session-id "$SESSION_ID" --json` to read the exact native actor's inbox (or the base-tool local inbox) plus the common broadcast inbox, and post the required channel response. Do not ask the user to paste peer messages that are already present in the rally channel, the addressed inbox, or the common broadcast inbox.
 
 ## Intent Capability Pack
 
@@ -198,6 +226,8 @@ Build-loop prefers installed plugins and skills over reinventing patterns. Each
 
 Understand current state, load memory through the automatic context bootstrap, detect tools, map architecture, capture north star + update intent, assess clean-sheet vs current-constraints approach lenses, define goal and criteria. Writes `.build-loop/context-bootstrap.json`, `.build-loop/context/current.md` via `scripts/context_snapshot.py`, `.build-loop/intent.md`, and `.build-loop/goal.md`.
 
+Groundwork intake: when `$GROUNDWORK_BUILD_REQUEST` or `.designdoc/build-request.json` is present, validate it with the adjacent canonical Spec through `scripts/groundwork_exchange.py validate-request` before planning; failures block Execute.
+
 Key steps: detect plugins → set sub-routers → map architecture → run `scripts/context_bootstrap.py` (bootstrap surfaces queue counts+top items+progressive lessons in the packet; check `session_prefs.continue_from_queues` and ask the user ONCE when "ask" and any queue has items; see `agents/build-orchestrator.md` §"Queue surfacing + session preference" and `AGENTS.md` §"Memory bootstrap + queue surfacing" for the full surface+ask protocol) → run `scripts/research_trigger.py` to decide Research plugin depth and blocked final-claim handling → run `scripts/task_surface.py` when surfacing open work → load PRD if present → capture intent → capture approach lenses for non-trivial recommendations → for UI work load `references/ui-io-contract.md` and inventory affected inputs/outputs → define scoring criteria → synthesis-density routing (count `synthesis_dimensions`; escalate to thinking-tier when > 5).
 
 **Load `skills/build-loop/references/phase-1-assess.md`** for the full step-by-step protocol including UI pre-flight, workspace concurrency checks, recovery check, and synthesis-density routing details.
@@ -222,17 +252,28 @@ Key steps: subagent-driven-development → model assignment (Sonnet default) →
 
 Seven sub-steps run in order (A–G): Critic → Validate → Optimize (opt-in) → Fact-Check → Simplify → Auto-Resolve → Report. F (Auto-Resolve) drains non-destructive items via `scripts/autonomy_gate.py` (auto/warn/confirm/block routing). G (Report) is final-pass-only.
 
-Key steps: independent-auditor (build scope) adversarial read → build-loop-owned UI validation when UI changed → code-based graders → live smoke gate → LLM judges → fact-checker + mock-scanner + architecture-rules in parallel → simplify → autonomy gate queue → final scorecard + run entry → **non-gating post-push retrospective dispatch** (`build-loop:retrospective-synthesizer` writes the 9-section `.build-loop/retrospectives/<date>/<run-id>.md` + ≤5-line summary surfaced inline; enforce-candidates land at `.build-loop/proposals/enforce-from-retro/` for human review — never auto-promoted; fire-and-continue, run-close is NOT delayed). On self-recursive runs, G appends `## Self-modifications (readback)` listing every self-modification attempted this run — file, what/why, gate verdict, additional-review finding — so the human sees results at the end without the loop stopping. Full spec in `agents/build-orchestrator.md` §G.
+Groundwork return: when Phase 1 accepted a request, Review-G emits `.designdoc/implementation-map.json` through `scripts/groundwork_exchange.py emit-map`; failures route to Iterate and Groundwork alone calculates convergence.
+
+Key steps: independent-auditor (build scope) adversarial read → build-loop-owned UI validation when UI changed → code-based graders → live smoke gate → LLM judges → fact-checker + mock-scanner + architecture-rules in parallel → public/private documentation boundary check when docs changed or publication is in scope → simplify → autonomy gate queue → final scorecard + run entry (asserted by `scripts/run_close_lint.py` — a report may not be emitted while the `runs[]` write is missing) → **non-gating post-push retrospective dispatch** (`build-loop:retrospective-synthesizer` writes the 9-section `.build-loop/retrospectives/<date>/<run-id>.md` + ≤5-line summary surfaced inline, AND a required durable copy to `build-loop-memory/projects/<slug>/retrospectives/` via `memory_writer.py` — `.build-loop/` is gitignored, so the local copy alone does not survive a clone; enforce-candidates land at `.build-loop/proposals/enforce-from-retro/` for human review — never auto-promoted; fire-and-continue, run-close is NOT delayed). On self-recursive runs, G appends `## Self-modifications (readback)` listing every self-modification attempted this run — file, what/why, gate verdict, additional-review finding — so the human sees results at the end without the loop stopping. Full spec in `agents/build-orchestrator.md` §G.
+
+**Documentation publication boundary.** When documentation changed, a repository is
+being prepared for publication, or Review finds plan/RCA/audit/retrospective material,
+load `references/public-repository-documentation-boundary.md`. Verify repository
+visibility. Private repositories retain internal records. Public repositories retain
+only current user-, contributor-, and agent-facing product material; archive internal
+plans, RCAs, future architecture, review artifacts, and maintainer operations to the
+private `build-loop-memory` project lane before removing and ignoring them. A missing
+private-memory receipt blocks the documentation review from passing.
 
 **Load `skills/build-loop/references/phase-4-review.md`** for sub-step details, gate matrices, routing rules, and the full Sub-step F Auto-Resolve protocol (all 4 verdict arms including `warn` exit-0 behavior).
 
-**Independent commit auditor — boundary gate + dispatched judge.** Single consolidated auditor (2026-05-23 — replaces retired `commit-auditor` and earlier retired `sonnet-critic`). Two surfaces share the same context-gathering procedure and verdict taxonomy: (1) a PreToolUse Bash hook fires `scripts/audit_before_commit.py` on every `git commit` regardless of who initiates it (manual, Codex, build-loop, IDE) — deterministic packet-builder, hard-blocks (exit 2) on staged secrets and merge-conflict markers, bypass via `BUILDLOOP_AUDIT_BYPASS=1`; (2) the `independent-auditor` agent dispatches at Phase 3 chunk-close (chunk advisory) and Phase 4 Review-A (build scope) for LLM-grade judgment. Four verdicts: `yay (approve)` / `nay (reject)` / `suggest_correction` / `look_again`. **Auditor dispatch ladder (GAP-1):** a *nested* orchestrator (dispatched as a subagent, or per-commit mode) has no Agent tool and cannot dispatch the auditor — it walks `dispatched-agent → peer-host (rally / codex exec) → not-run:parent-must-dispatch`, records the chosen rung in `auditor_status`, and **never** lets inline self-reasoning masquerade as the independent auditor. A `not-run:parent-must-dispatch` run is not review-complete: under the parent-dispatch contract the dispatching parent owes the audit before Report. Full reference: `skills/build-loop/references/independent-auditor.md` + `references/phase-4-review.md` §"Sub-step A" + `agents/independent-auditor.md`.
+**Independent commit auditor — boundary gate + dispatched judge.** Single consolidated auditor (2026-05-23 — replaces retired `commit-auditor` and earlier retired `sonnet-critic`). Two surfaces share the same context-gathering procedure and verdict taxonomy: (1) a PreToolUse Bash hook fires `scripts/audit_before_commit.py` on every `git commit` regardless of who initiates it (manual, Codex, build-loop, IDE) — deterministic packet-builder, hard-blocks (exit 2) on staged secrets and merge-conflict markers, bypass via `BUILDLOOP_AUDIT_BYPASS=1`; (2) the `independent-auditor` agent dispatches at Phase 3 chunk-close (chunk advisory) and Phase 4 Review-A (build scope) for LLM-grade judgment. Four verdicts: `yay (approve)` / `nay (reject)` / `suggest_correction` / `look_again`. **Auditor dispatch ladder (GAP-1):** a *nested* orchestrator (dispatched as a subagent, or per-commit mode) has no Agent tool and cannot dispatch the auditor — it walks `dispatched-agent → peer-host (rally / codex exec) → not-run:parent-must-dispatch`, records the chosen rung in `auditor_status`, and **never** lets inline self-reasoning masquerade as the independent auditor. A `not-run:parent-must-dispatch` run is not review-complete: the nested orchestrator writes a machine-checkable **owed-verification manifest** (`.build-loop/owed-verification.json` via `scripts/owed_verification.py write`) and flips `state.json.review_incomplete = true`, so under the parent-dispatch contract the dispatching parent MUST dispatch the owed verifiers and `clear` the manifest before Report — the manifest replaces "parent remembers" with a gate (`owed_verification.py check`). Full reference: `skills/build-loop/references/independent-auditor.md` + `references/phase-4-review.md` §"Sub-step A" + `agents/independent-auditor.md`.
 
 ## Phase 5: Iterate — Fix Review Failures + UX Queue (up to 5x)
 
 Fix failures surfaced by Review plus drain the UX queue from Sub-step D Gates 7-8, systematically. Loops back to Review after each pass. Hard stop at 5 iterations.
 
-Key steps: prioritized work list (Validate failures → blocker UX → major UX → optimization → UI coverage gaps) → fan-out up to `effective_max` implementers (see `scripts/parallelism.py effective_max_implementers(workdir)` — default 8; `min(config.parallelism.maxImplementers, cpu_count−2, hard ceiling 12)`) → stuck-cascade (evidence-gap → memory re-check → parallel assess at 2 fails → causal-tree at 3 fails) → UI re-validate hook → overflow to followup/.
+Key steps: prioritized work list (Validate failures → blocker UX → major UX → optimization → UI coverage gaps) → supervisor-selected adaptive fan-out (default project preference 8; absolute ceiling 150; resource, provider, independent-work, and shared-capacity limits remain binding) → stuck-cascade (evidence-gap → memory re-check → parallel assess at 2 fails → independent audit at the third same unresolved verdict → quarantine at the fifth) → UI re-validate hook → overflow to followup/.
 
 **Load `skills/build-loop/references/phase-5-iterate.md`** for the full prioritized work list, status routing for all 9 implementer return values, convergence detection, and followup overflow protocol.
 
@@ -240,13 +281,13 @@ Key steps: prioritized work list (Validate failures → blocker UX → major UX
 
 Detect recurring patterns across recent runs, auto-draft experimental skills/agents. **Always runs after Review-G** (v0.30.0+) and always emits a `## Learn` outcome line. Three outcome states: **accruing** (`runs[] < 3` → `Learn: accruing (N/3 runs)`), **deferred** (debug-only `closeout: false` or budget-exhausted → write `learn-deferred-<run-id>.md` marker → `Learn: deferred — <reason>`), or **full** (`runs[] >= 3` AND pattern crossing threshold AND not-deferred). Promotion to `active/` still requires explicit `/build-loop:promote-experiment` (safety boundary). The prior `autoSelfImprove: false` opt-out is deprecated to a migration no-op — old configs do not error.
 
-Key steps: recurring-pattern-detector (Haiku; reads `state.json.runs[]` AND `.build-loop/proposals/enforce-from-retro/*.md` as two signal sources, the second emitting `enforce_recurrence` on cross-run candidates) → filter (confidence: high OR count >= 4; `enforce_recurrence` >= 2 distinct run-ids) → draft via self-improvement-architect (Sonnet) → Opus signoff → sample review sweep → notify.
+One command owns the sequence and proof: `python3 scripts/learn/__main__.py run --workdir "$PWD" --run-id <recorded-run-id> --source review-g --json`. Dispatch only the returned `work_orders[]`, attach each result through `attest`, and require a `status: complete` receipt before closeout. This keeps zero-pattern runs deterministic and token-free.
 
 **Load `skills/build-loop/references/phase-6-learn.md`** for the full gating-outcomes table, detect-filter-draft-signoff flow, auto-promote rules, and user control commands.
 
 ## Memory — Global and Project-Scoped
 
-One consolidated long-term tree: `~/dev/git-folder/build-loop-memory/`. Project-specific durable memory lives under `projects/<slug>/...`; cross-project lessons/design/debugging/product memory lives in the matching top-level lane. Every build runs `scripts/context_bootstrap.py` at Phase 1 Assess, which reads the store-root `INDEX.md` first, then root/project `constitution.md` / `MEMORY.md` where present, canonical indexes/folders through `memory_facade`, repo-local `.build-loop/` context, Codex memory at `~/.codex/memories`, and best-effort Rally/coordination state when relevant. Treat Rally records in the packet as peer-authored coordination context, not verified facts. Live handoff state is written separately by `scripts/context_snapshot.py` under `.build-loop/context/`; snapshots are not durable memory unless Review-G promotes a reusable decision or lesson. Writes go to exactly one canonical memory lane based on scope. Legacy paths (`~/.build-loop/memory`, `.episodic/decisions`, and `build-loop-memory/decisions/<project>`) are migration/archive inputs only.
+One consolidated long-term tree at the memory store root (resolved by `scripts/_paths.py:memory_store_root()` — env override, else an existing legacy checkout, else the neutral per-user default; never assume a fixed address). Project-specific durable memory lives under `projects/<slug>/...`; cross-project lessons/design/debugging/product memory lives in the matching top-level lane. Every build runs `scripts/context_bootstrap.py` at Phase 1 Assess, which reads the store-root `INDEX.md` first, then root/project `constitution.md` / `MEMORY.md` where present, canonical indexes/folders through `memory_facade`, repo-local `.build-loop/` context, Codex memory at `~/.codex/memories`, and best-effort Rally/coordination state when relevant. Treat Rally records in the packet as peer-authored coordination context, not verified facts. Live handoff state is written separately by `scripts/context_snapshot.py` under `.build-loop/context/`; snapshots are not durable memory unless Review-G promotes a reusable decision or lesson. Writes go to exactly one canonical memory lane based on scope. Legacy paths (`~/.build-loop/memory`, `.episodic/decisions`, and `build-loop-memory/decisions/<project>`) are migration/archive inputs only.
 
 Routing rule: "Would this apply to a different project?" Yes → global. No → project. Ambiguous → ask the user once.
 
@@ -260,19 +301,76 @@ Append-only memory contract: (1) steering answers from `AskUserQuestion` append
 
 **Parsing rule**: scan the argument string for the literal token `--resume`. The next whitespace-delimited token is the run-id (or `latest`). Anything else is part of the goal text.
 
-**On `--resume <run-id>` or `--resume latest`** — BEFORE Phase 1 Assess, run `python3 ${CLAUDE_PLUGIN_ROOT}/scripts/resume_resolver.py --workdir "$PWD" --resume-arg "<run-id-or-latest>" --staleness-minutes 5`. Returns `decision: "resume" | "abort" | "fresh"`. On `resume`:
+Before either path, resolve `RUNTIME_PLUGIN_ROOT` to the root of the currently
+loaded Build Loop package (the directory containing both `scripts/` and
+`skills/`). Use `BUILD_LOOP_ROOT` when the host exports it; otherwise derive the
+root from the already-resolved path of this `SKILL.md`. Do not assume a
+host-specific plugin-root environment variable, and do not use the target
+project's root unless Build Loop itself is the target.
+
+**On `--resume <run-id>` or `--resume latest`** — BEFORE Phase 1 Assess, run `python3 "$RUNTIME_PLUGIN_ROOT/scripts/resume_resolver.py" --workdir "$PWD" --resume-arg "<run-id-or-latest>" --staleness-minutes 5`. Returns `decision: "resume" | "abort" | "fresh" | "prompt_user"`. On `resume`:
 
 1. Read `.build-loop/intent.md` and `.build-loop/plan.md` (already on disk — DO NOT re-derive).
 2. Dispatch build-orchestrator with prefix: `RESUME_MODE: run_id=<id>; remaining_chunks=<json>; iterate_attempt=<n>; concurrent_modifications=<json>`
 3. Agent §0 handles the rest — skips Phase 1+2, jumps to Phase 3 on `remaining_chunks` only.
 
-**On NO `--resume` (normal dispatch)** — BEFORE Phase 1 step 1, run the same resolver with `--resume-arg ""`. If it returns `decision: "prompt_user"`, surface to the user verbatim:
+**On NO `--resume` (normal dispatch)** — BEFORE Phase 1 step 1, run the same resolver with `--resume-arg ""`. When the host supplies a stable current session id, pass it explicitly as `--current-session-id "<id>"`; never infer ownership from heartbeat freshness. An exact session match proves continuity only, so a `decision: "resume"` result continues the existing run through the same Resume Mode path above—it never starts fresh. If the resolver returns `decision: "prompt_user"`, surface to the user verbatim:
 > "Incomplete build detected (run_id=X, last heartbeat N min ago, M of K chunks complete). Resume with `/build-loop:run --resume X` or start fresh? Starting fresh will not delete the incomplete state — it persists until manually cleared."
 
+If it instead returns `decision: "abort"` with
+`required_action: "archive_legacy_crash"`, immediately rerun the resolver with
+`--archive-terminal-legacy-crash`. Proceed as a fresh run only when that second
+result returns `decision: "fresh"`, `archive_applied: true`, and
+`fresh_ready: true`. This path is limited to a schema-less crash whose terminal
+evidence the resolver revalidates under the state lock; every ambiguous or
+potentially active schema-less execution remains refused.
+
+Every other `abort` is a hard refusal: do not begin a fresh run. In particular,
+an existing nonterminal execution with a fresh, missing, timezone-less, or
+unparseable heartbeat is not fresh-run permission. An exact match between the
+explicit `--current-session-id` and `execution.current_session_id` proves only
+host/thread continuity and therefore resumes that run. It is not a unique
+invocation nonce and cannot authorize replacing the execution.
+
 This is the crash-resume staleness signal — heartbeat staleness on `state.json.execution`, no hook dependency, fires every fresh dispatch. (A crash-recovery concern, distinct from concurrent-presence collision, which is owned solely by Rally Point presence — see `KNOWN-ISSUES.md` §M4.)
 
 **Concurrent-modification handling**: when `concurrent_modifications` is non-empty in the resolver output, the agent's §0 branch surfaces each flagged chunk as `status: concurrent_modification_detected` and asks the user whether to redo the chunk (default) or keep the hand-edits.
 
+## Output contract — applies to EVERY user-facing message, not just the Phase 4 report
+
+Two references govern how build-loop talks to a human. Load them the first time a
+run emits user-facing text, and follow them for the rest of the session:
+
+- `references/output-style.md` — SENTENCE level. Lead with the answer to the
+  question actually asked. Strong verb over weak-verb-plus-filler
+  (`was responsible for` → `caused`). Data over adverbs
+  (`significantly increased` → `increased 42%`). Say `because` only when the cause
+  is proven, `suggesting` when evidence merely implies it.
+- `references/status-output-format.md` — BLOCK level, for findings, open items,
+  status updates, and recommendations. Heading is an action-verb phrase with real
+  numbers inline; second line is the consequence (what breaks, for whom, when);
+  specifics named individually; close with a decision or a status.
+
+**These are not Review-G-only.** They govern interim status, findings surfaced
+mid-run, handoffs, and any answer given while the skill is loaded. Review-G is
+where the deterministic lint runs, not where the contract begins. A run that
+reports conforming prose only in its final report has followed the lint and missed
+the rule.
+
+Self-check any substantial user-facing markdown before sending:
+
+```bash
+python3 scripts/report_lint.py <draft.md> --json   # weak-verb, filler-opener, hedge
+```
+
+WARN-only with self-heal — rewrite and move on; it never halts a run. The lint
+grades three mechanical rules; everything else in the two references is judgment,
+so a clean lint is not evidence the contract was met.
+
+The governing test, from `status-output-format.md` §2: *if an agent with zero
+context read only this line, would it know what to do?* A block that satisfies
+every rule and fails that test is still wrong.
+
 ## Efficiency
 
 - No extraneous code. Every line serves the goal
@@ -301,16 +399,21 @@ Build-loop can author new skills mid-flow when a repeated task pattern emerges a
 
 **Procedure:**
 
-1. Draft the skill during Phase 4 if the need arises. Use the `plugin-dev:skill-development` skill if available, else `fallbacks.md#agent-authoring` format (but for skills — name, description, body ≤200 lines, progressive disclosure).
-2. Use it immediately in the current build.
-3. At Review-F, score its usefulness: did it reduce friction? Would you use it next build?
-4. Decide: **keep**, **promote** (project → global), or **drop**.
+1. Draft the skill during Phase 4 if the need arises. Use the `plugin-dev:skill-development` skill if available, else `fallbacks.md#agent-authoring` format (but for skills — name, description, body ≤200 lines, progressive disclosure). Write `user-invocable: false` into the frontmatter: a new skill is hidden by default and is reached by build-loop routing, not by the user's slash menu.
+2. Stamp it in the same turn as the write, on the path you just wrote:
+   ```bash
+   python3 "${CLAUDE_PLUGIN_ROOT:-.}/scripts/stamp_skill_frontmatter.py" --apply <path-just-written>
+   ```
+   The harness computes `userInvocable ?? true`, so a SKILL.md carrying no field is PUBLIC. Step 1's frontmatter line is the fast path; this command is the control. Expected status `compliant` or `stamped`, exit 0. A `violation` or `malformed` exit means the skill you just authored is publicly invocable or unparseable — fix it and re-run before using the skill.
+3. Use it immediately in the current build.
+4. At Review-F, score its usefulness: did it reduce friction? Would you use it next build?
+5. Decide: **keep**, **promote** (project → global), or **drop**.
    - Keep (project) — leave in `.build-loop/skills/`.
-   - Promote — move to `~/.claude/skills/`, confirm with user.
+   - Promote — copy to `~/.claude/skills/<name>/SKILL.md`, run the stamper again **on the destination path** (`python3 "${CLAUDE_PLUGIN_ROOT:-.}/scripts/stamp_skill_frontmatter.py" --apply ~/.claude/skills/<name>/SKILL.md`), then confirm with the user using the exposure block in `skills/self-improve/SKILL.md` §"Promotion exposure statement". `~/.claude/skills/` loads in every session on every project, so this move — not the drafting step — is where exposure is decided.
    - Drop — delete and note in `.build-loop/feedback.md` why it didn't earn its keep.
-5. Record the decision through `scripts/memory_writer.py` into `build-loop-memory/lessons/` or `build-loop-memory/projects/<slug>/lessons/` as a `pattern` entry.
+6. Record the decision through `scripts/memory_writer.py` into `build-loop-memory/lessons/` or `build-loop-memory/projects/<slug>/lessons/` as a `pattern` entry.
 
-**Self-review/self-heal loop extension:** the self-review/self-heal loop (proactive arm of C-HEAL) MAY author new skills AND new scripts when doing so prevents a class of issue or streamlines repeated work. New skills start project-local and follow this same keep/promote/drop lifecycle. Promotion to the build-loop plugin repo or `~/.claude/skills/` still requires user confirmation (global scope is consequential). New scripts MUST have a colocated `test_<name>.py` — no untested script lands. When the authoring happens inside a self-recursive build (editing build-loop itself), every new or modified file passes through the SELF-MODIFICATION SAFETY GATE in `references/self-review.md` §"Self-modification of the restricted repo" before commit.
+**Self-review/self-heal loop extension:** the self-review/self-heal loop (proactive arm of C-HEAL) MAY author new skills AND new scripts when doing so prevents a class of issue or streamlines repeated work. New skills start project-local and follow this same keep/promote/drop lifecycle. Promotion to the build-loop plugin repo or `~/.claude/skills/` still requires user confirmation (global scope is consequential) and runs the destination-path stamper from step 5 before that confirmation is asked. New scripts MUST have a colocated `test_<name>.py` — no untested script lands. When the authoring happens inside a self-recursive build (editing build-loop itself), every new or modified file passes through the SELF-MODIFICATION SAFETY GATE in `references/self-review.md` §"Self-modification of the restricted repo" before commit.
 
 **Never proliferate skills**. A skill that isn't used twice across builds should be dropped. Prefer extending an existing skill over creating a new one.
 
@@ -347,14 +450,17 @@ Contextual material loaded on demand (not at skill invocation):
 - `references/phase-3-execute.md` — Full Phase 3 Execute protocol
 - `references/verify-dispatch.md` — Post-dispatch 5-step git/test ground-truth checklist; walk after any dispatched agent claims commits landed / tests passed (a solicited peer agreeing is not independent verification)
 - `references/dogfood-reload-checkpoint.md` — Self-recursive stop/reload/resume checkpoint and ACK/fallback protocol
+- `references/privileged-request-broker.md` — Naming, coalescing, and recording macOS administrator-password requests across concurrent tasks. Load when a build touches a command that asks for an admin password, when a user reports unexplained password dialogs, or when editing `scripts/privileged_commands.json`.
 - `references/phase-4-review.md` — Full Phase 4 Review protocol (sub-steps A–G, including Sub-step F Auto-Resolve with all 4 verdict arms)
 - `references/phase-5-iterate.md` — Full Phase 5 Iterate protocol
 - `references/phase-6-learn.md` — Full Phase 6 Learn protocol
 - `references/memory.md` — Memory system: global vs project stores, routing rule, read/write policy
+- `references/output-style.md` — Sentence-level user-facing style contract (see "Output contract" above)
+- `references/status-output-format.md` — Block-level shape for findings, open items, status, recommendations
 - `references/leadership.md` — Initiative + decision-escalation doctrine (decide-at-70%, self-research → memory → peers → persona panel → human-only-for-irreversible, parallel-work-before-idling, token-posture gauge). Synthesized from intent-based leadership / mission command / two-door decisions.
 - `references/research-trigger-policy.md` — Research plugin trigger/depth gate, t-shirt depth lower bounds, and final-claim citation/unavailable rule
 - `references/task-capture-policy.md` — Read-only active task surface over existing plan/state/queue/backlog surfaces; no new task ledger by default
-- `references/backlog-system.md` — Host-agnostic, multi-repo backlog system: MD+YAML items (canonical truth) + regenerable INDEX, pure-stdlib `scripts/backlog.py` (new/sync/list), one-way mirror to personal memory. Read via `BACKLOG.md`→`INDEX.md`→grep; write via the CLI
+- `references/backlog-system.md` — Host-agnostic classed backlog: planned pickup, approval-gated initiatives, contextual user decisions, lossless reconciliation, and explicit promotion into the executable queue
 - `references/agent-role-taxonomy.md` — Lead/peer/coder-assessor/reviewer/skill responsibility map; use before adding or renaming agents.
 - `references/capability-routing.md` — Full capability routing table, trigger conditions, sub-routers
 - `references/recent-design-structures.md` — Recent UI structure library loaded by `design-contract-specialist` in Phase 2. Structures are options, not mandates.
@@ -362,7 +468,7 @@ Contextual material loaded on demand (not at skill invocation):
 - `../ui-design/references/ui-guidance-sources.md` — Source map for local UI guidance across build-loop, UI Guidance, IBR, Mockup Gallery, document/deck plugins, research, vault, project-local hidden folders, and build-loop-memory.
 - `references/refactor-history/` — Internal assessment of the 2026-04 refactor. `ASSESSMENT.md` explains rationale, `trace-comparison.md` shows before/after flow, `STANDALONE_TEST_RUN.md` validates the model, `scenarios/01..06` contain 6 test scenarios.
 - `eval-guide.md` — How to interpret build-loop scorecards.
-- `fallbacks.md` — Degraded-but-useful behavior when bridge plugins or rendered UI tooling are absent. IBR remains explicit-only through `build-loop:ibr-bridge`.
+- `fallbacks.md` — Degraded-but-useful behavior when bridge plugins or rendered UI tooling are absent. Headless IBR verification follows `../../references/ibr-ui-verification-policy.md`; viewer surfaces remain explicit-only.
 - `phases/fact-check.md` — Detailed fact-check sub-step specification.
 
 Companion skills (each has its own SKILL.md; load via `Skill("build-loop:<name>")`):
@@ -373,7 +479,9 @@ Companion skills (each has its own SKILL.md; load via `Skill("build-loop:<name>"
 - `build-loop:architecture-{scan,impact,trace,rules,dead,review}` — native architecture skills sourced from NavGator (provenance + drift-detection via `build-loop:sync-skills`)
 - `build-loop:debugging-memory` · `build-loop:debug-loop` · `build-loop:logging-tracer` — bundled debugger primitives (orchestrator owns when-to-fire, these own the procedural detail)
 - `build-loop:plugin-builder` · `build-loop:mcp-builder` — plugin authoring (use together for plugins that expose MCP tools)
+- `build-loop:repo-maintenance` — repository structure, source-of-truth, artifact retention, sibling consolidation, and safe local-main closeout (`build-loop:repo-closeout` is the temporary compatibility alias)
 - `build-loop:authentication` — multi-provider auth reference library (Better Auth, Supabase, Google OAuth, Resend; routed by provider × topic)
+- `build-loop:data-plane-worktrees` — isolates mutable non-Git state across run worktrees; loads for SQLite/PostgreSQL migrations, generated indexes, Docker volumes/projects, mutable file stores, or external namespaces and drives the run manifest through terminal closeout.
 - `build-loop:building-with-deepagents` — OSS deepagents framework (activates on `from deepagents import`)
 - `build-loop:ui-design` — build-loop-owned UI design direction skill loaded before non-trivial UI implementation; `design-contract-specialist` writes the resulting `.build-loop/app-contract/ui.md`.
 - `build-loop:telemetry` — OpenTelemetry-first observability guidance (LLM/agent → Phoenix/Langfuse + OpenInference/OpenLLMetry; web/server → OTel SDK + Sentry; mobile/iOS → Embrace/OTel-swift over Firebase). Loaded in Phase 1 when a build touches a server/LLM/mobile app with no telemetry, or Phase 2 when adding a service/LLM path; encodes the user's decided OTel + GenAI-semconv stack.