docs: consolidate Phase B.2 documentation and consistency checks

.agents/skills/add-bsp/SKILL.md

@@ -80,12 +80,15 @@ Execute each item before moving to the next. Do **not** assume any item is alrea
 
 ### 4. Write `boot.s`
 
-Minimum content (aarch64 EL1 example):
+Minimum stack/FP/BSS skeleton for a target already confirmed to enter at aarch64 EL1. Mask DAIF before unsafe setup; install vectors and finish the target boot checklist before unmasking. This is not a complete reference-BSP boot implementation:
 
 ```asm
     .section .text.boot, "ax"
     .global _start
 _start:
+    /* 0. Mask debug, SError, IRQ and FIQ before stack/FP/BSS setup */
+    msr     daifset, #0xf
+
     /* 1. Set stack pointer */
     adrp    x0, __stack_top
     add     x0, x0, :lo12:__stack_top
@@ -111,7 +114,7 @@ _start:
     b       2b
 ```
 
-Adjust for EL2→EL1 transition if the target enters at EL2 (add `msr hcr_el2, …` / `eret` sequence before step 1).
+For EL2 entry, follow the target’s Accepted boot-flow ADR and complete the EL2→EL1 policy before using this EL1 skeleton. A bare HCR/ERET insertion is not sufficient: interrupt masks, stack selection, timer access, trap controls and transition context depend on the verified target. The reference [ADR-0024](../../../docs/decisions/0024-el-drop-policy.md) and [boot.s](../../../bsp-qemu-virt/src/boot.s) show the existing QEMU policy; do not assume another board has the same entry state.
 
 ### 5. Implement `cpu.rs`
 
@@ -130,7 +133,7 @@ Implement `tyrne_hal::Console` for the target UART. Follow the existing `Pl011Ua
 
 `kernel_entry` must:
 1. Initialise the console and print the greeting (`tyrne: hello from kernel_main`).
-2. Call `tyrne_kernel::sched` to register tasks and start the scheduler.
+2. Initialize the target-specific prerequisites and use `tyrne_kernel::sched` to register/start the selected smoke workload. That workload must emit its completion marker after doing its declared work.
 3. Never return (`-> !`).
 
 Provide a `#[panic_handler]` that writes to the console and loops.
@@ -147,27 +150,33 @@ Model on [`bsp-qemu-virt/linker.ld`](../../../bsp-qemu-virt/linker.ld). At minim
 
 Create `tools/run-<target>.sh`. For QEMU targets, model on [`tools/run-qemu.sh`](../../../tools/run-qemu.sh):
 
-- Include the `--int-log` flag (`-d int -D /tmp/qemu_int.log`) for silent-hang debugging.
+- Include an exception-log option for silent-hang debugging. The reference `--int-log` uses `-d int -D <logfile>`, with `${TMPDIR:-/tmp}/qemu_int.<pid>.log` printed at startup; use the printed path. Smoke `--int` instead uses `-d int,unimp`.
 - Document the QEMU machine flags in the script header.
 
 For real hardware, document the flashing command (e.g. `openocd`, `rpiboot`, `cargo flash`).
 
 ### 10. Verify the smoke test
 
-Boot the kernel and confirm:
+Boot the selected workload and confirm this minimal serial-success shape; `...` elides workload-specific lines:
 
 ```text
 tyrne: hello from kernel_main
 tyrne: starting cooperative scheduler
-tyrne: task A — iteration 0
-tyrne: task B — iteration 0
 ...
-tyrne: task A done; spinning
+tyrne: all tasks complete
+```
+
+Exact intervening/trailing lines depend on the kernel version and target workload; see the [README Quick start](../../../README.md#quick-start) for the verified reference trace. This minimal porting check does not establish full reference EL0/IPC parity: the reference [smoke.sh](../../../tools/smoke.sh) separately gates debug/release console, userspace exit/completion and fault classes. Retain evidence for whichever workload the target ADR declares.
+
+If the kernel hangs silently, run with `--int-log` (QEMU) or attach a JTAG debugger (real hardware). After quitting QEMU, inspect its printed path:
+
+```sh
+grep "Taking exception" '<path-printed-by-run-script>'
 ```
 
-If the kernel hangs silently, run with `--int-log` (QEMU) or attach a JTAG debugger (real hardware) and check for the following before anything else:
+Check the following before anything else:
 
-1. Exception log: `grep "Taking exception" /tmp/qemu_int.log`
+1. Exception log at the printed PID-scoped path — which exception fired?
 2. CPACR_EL1 — is FPEN set? (ESR EC=0x07 = FP/SIMD trap)
 3. SP misalignment — AAPCS64 stack-alignment fault?
 4. BSS not zeroed — statics have garbage values?
@@ -200,7 +209,7 @@ Trailer: `Refs: ADR-NNNN` (the boot-flow ADR from step 1).
 ## Anti-patterns
 
 - **Skipping the boot-flow ADR.** Every BSP has target-specific boot decisions; writing code before documenting them produces undocumented assumptions.
-- **Copying `boot.s` without checking the EL.** QEMU `virt` enters EL1; RPi4 enters EL2. The CPACR_EL1 sequence is only needed if the kernel runs at EL1; at EL2 you need CPTR_EL2.
+- **Copying `boot.s` without checking the EL.** Confirm the actual target entry state. The EL1 skeleton configures CPACR_EL1 after EL1 entry; EL2 setup and the transition require the target’s Accepted boot policy, not a single substitute register write.
 - **Using `#[inline(never)]` instead of `#[unsafe(naked)]` for the context switch.** The compiler will still emit a prologue. See `docs/standards/unsafe-policy.md §5a`.
 - **Omitting d8–d15 from `Aarch64TaskContext`.** NEON is enabled at boot; the compiler may allocate d8–d15 in any function. Omitting them silently corrupts task state at higher optimisation levels.
 - **Not zeroing BSS.** Rust guarantees `.bss` is zero; if the hardware or QEMU does not zero it, every static initialised to zero will have garbage values.

.agents/skills/conduct-review/SKILL.md

@@ -51,6 +51,14 @@ when-to-use: When a trigger for any of the four review types fires — milestone
    - Body: one-paragraph summary of the verdict / adjustments.
    - Trailer: `Refs: ADR-0013` and any ADRs the review cites.
 
+## Evidence retention
+
+Follow [ADR-0044](../../../docs/decisions/0044-review-evidence-retention.md) and [documentation storage policy](../../../docs/standards/documentation-style.md#evidence-storage). Keep complete canonical Markdown reports, original verdicts/findings/read limits, actual source identities and compact archive metadata in Git. Put bulk execution streams, intermediate JSON, source exports and encoded scratch archives outside Git in a digest-verified durable archive with independently tested recovery; expiring Actions artifacts alone are insufficient.
+
+Before producing a source export, exclude previously retained raw archive/snapshot trees so evidence does not recursively retain itself. Preserve original evidence in its authoritative archive rather than embedding retained archives or entire source exports in new Git JSON. Never remove original verdicts or invent a historical run to obtain a smaller diff. Hash checks establish integrity, not a complete semantic read; retain each reviewer’s actual scope and limitations. The [recovery guide](../../../docs/guides/review-evidence.md) explains original SHA/source recovery.
+
+Stage intended artifacts and run the separate footprint command/fixtures in addition to corpus checks. The approved limits cover the index and complete HEAD history; later deletion does not erase an oversized historical blob. Future exceptions require exact-path reasons and reviewed fixtures, never broad review-directory exclusions. This storage discipline adds no substitute for any master-plan role or required independent review round.
+
 ## Acceptance criteria
 
 - [ ] Correct review type chosen for the trigger.

.agents/skills/propose-standard-change/SKILL.md

@@ -23,11 +23,11 @@ when-to-use: Whenever a rule in `docs/standards/` needs to change. Covers additi
    - If no ADR explicitly motivated the rule, the current standard is effectively an implicit decision that never had its ADR. The first step is to write the ADR that captures it — then supersede it — rather than silently changing the standard.
 
 3. **Decide ADR path.**
-   - **Amendment of existing ADR.** The old ADR is still largely right; it just needs to be updated or clarified. Use the *amendment* pattern — edit the ADR in place with a Proposed-amendment note, get it accepted, then update the standard.
+   - **Factual clarification of an existing Accepted ADR.** Preserve the original body and append a dated rider stating the correction and its evidence, following [ADR-0025 Rule 2](../../../docs/decisions/0025-adr-governance-amendments.md#rule-2--riders-are-not-failures-their-frequency-is-a-signal). Review the rider before updating the standard. A rider must not silently introduce a substantive rule change under the old ADR's Accepted status. Proposed drafts remain editable.
    - **Supersession.** The old decision is being reversed or significantly changed. Use [supersede-adr](../supersede-adr/SKILL.md): write a new ADR that supersedes the old one.
    - **New ADR, no supersession.** The change is additive — a new principle, a new constraint — that the old ADRs did not address. Use [write-adr](../write-adr/SKILL.md) to record the new decision.
 
-4. **Author the ADR first.** Standards follow decisions. Do not change the standard file until the ADR is `Accepted`. Drafting both in parallel is fine; committing the standard change before the ADR is not.
+4. **Author the ADR first.** Standards follow decisions. For a substantive new or changed decision, obtain the maintainer's explicit approval and make the motivating ADR `Accepted` before changing the standard file. For a factual clarification of an already Accepted decision, review and record the append-only rider first. Drafting in parallel is fine; committing the standard change before its decision or correction record is not.
 
 5. **Update the standard file.** Once the ADR is Accepted:
    - Edit `docs/standards/<file>.md`.
@@ -53,7 +53,7 @@ when-to-use: Whenever a rule in `docs/standards/` needs to change. Covers additi
 ## Acceptance criteria
 
 - [ ] Motivating ADR written (or identified if pre-existing).
-- [ ] ADR is `Accepted` before the standard file is modified.
+- [ ] Motivating decision is `Accepted` before the standard file is modified; a substantive new or changed decision has explicit maintainer approval, and any factual clarification rider is reviewed and recorded first.
 - [ ] Standard file change minimal; unchanged adjacent rules untouched.
 - [ ] References at the bottom of the standard point to the new ADR.
 - [ ] Downstream effects searched; affected docs updated or tracked.

.agents/skills/start-task/SKILL.md

@@ -8,7 +8,7 @@ when-to-use: When the next task in the active milestone becomes ready to pick up
 
 ## Inputs
 
-- The **phase and milestone** the task belongs to (e.g. `A`, `A2`).
+- The **phase and milestone/bridge Track** the task belongs to (e.g. `A` / `A2`, or `B.2` / `B.2-2`). Path IDs are lowercase without dots: C → `phase-c` / `phase-c.md`; B.2 → `phase-b2` / `phase-b2.md`. Bridge Tracks B.2-1…B.2-6 are distinct from Phase B milestones B0–B6.
 - A **short imperative title** (e.g. "Capability table foundation").
 - Enough context to write a useful user story: who wants this, what they want, why.
 - The **dependencies** — prior tasks (T-NNN) that must be `Done` before this one starts, if any.
@@ -18,7 +18,7 @@ when-to-use: When the next task in the active milestone becomes ready to pick up
 
 1. **Read the current roadmap state.**
    - Check [`docs/roadmap/current.md`](../../../docs/roadmap/current.md).
-   - Confirm the phase and milestone exist in [`docs/roadmap/phases/phase-<letter>.md`](../../../docs/roadmap/phases/).
+   - Confirm the phase and milestone exist in [`docs/roadmap/phases/phase-<id>.md`](../../../docs/roadmap/phases/).
    - If the milestone is not on the roadmap, stop and ask the maintainer — a missing milestone is a structural change and needs an ADR per [ADR-0013](../../../docs/decisions/0013-roadmap-and-planning.md).
 
 2. **Assign the next T-NNN.**
@@ -27,7 +27,7 @@ when-to-use: When the next task in the active milestone becomes ready to pick up
    - IDs are sequential across the whole project, not restarted per phase.
    - **Single-writer assumption.** Two concurrent task-creation flows can both observe the same "highest existing T-NNN" and allocate the same ID. v1 relies on a *single active writer* per branch: run this skill on a branch rebased onto `development`, and if at merge time another `T-NNN-*.md` with your chosen id has landed, re-run the numbering step (list again, pick a fresh highest+1, `git mv` the file, update every internal reference). A ledger-based reservation mechanism may arrive later; for now, the single-writer convention is the contract.
 
-3. **Create the task file** at `docs/analysis/tasks/phase-<letter>/T-NNN-<kebab-slug>.md`.
+3. **Create the task file** at `docs/analysis/tasks/phase-<id>/T-NNN-<kebab-slug>.md`.
    - Copy from [`docs/analysis/tasks/TEMPLATE.md`](../../../docs/analysis/tasks/TEMPLATE.md).
    - Fill the frontmatter fields: `Phase`, `Milestone`, `Status`, `Created`, `Author`, `Dependencies`, `Informs`, `ADRs required`. No placeholder values left from the template.
 
@@ -38,9 +38,9 @@ when-to-use: When the next task in the active milestone becomes ready to pick up
    - If the task is being picked up for immediate work, move to `In Progress`.
    - Do not jump straight to `In Review` or `Done`.
 
-6. **Update the phase's task index** at `docs/analysis/tasks/phase-<letter>/README.md`. Add the new task to its table.
+6. **Update the phase's task index** at `docs/analysis/tasks/phase-<id>/README.md`. Add the new task to its table.
 
-7. **Update the phase plan** at `docs/roadmap/phases/phase-<letter>.md` if the task is mentioned by id in the milestone's `Tasks under <Mx>` list.
+7. **Update the phase plan** at `docs/roadmap/phases/phase-<id>.md` if the task is mentioned by id in the milestone's `Tasks under <Mx>` list.
 
 8. **Update [`docs/roadmap/current.md`](../../../docs/roadmap/current.md)** if the status is `In Progress`.
    - The `Active task` line points at the new file.
@@ -58,7 +58,7 @@ when-to-use: When the next task in the active milestone becomes ready to pick up
 
 ## Acceptance criteria
 
-- [ ] New file at `docs/analysis/tasks/phase-<letter>/T-NNN-<slug>.md`.
+- [ ] New file at `docs/analysis/tasks/phase-<id>/T-NNN-<slug>.md`.
 - [ ] Frontmatter fields are filled — no placeholders from the template.
 - [ ] User story section answers *who / what / why* in one sentence.
 - [ ] Acceptance criteria are concrete and testable (3–8 items; at most 10).

.agents/skills/supersede-adr/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: supersede-adr
 description: Override a prior Accepted ADR with a new one, updating both files so the forward and backward pointers are consistent.
-when-to-use: When a decision recorded in a prior ADR is being reversed or significantly changed. Not for minor clarifications (edit the original with a Proposed-amendment note instead).
+when-to-use: When a decision recorded in a prior ADR is being reversed or significantly changed. Not for minor clarifications (append a dated correction rider under ADR-0025 instead).
 ---
 
 # Supersede ADR
@@ -20,19 +20,26 @@ Before starting, the agent must have:
 1. **Read the old ADR in full.** Understand what it claimed, what alternatives it considered, and what consequences it accepted. Do not supersede what you have not read.
 
 2. **Decide: supersession or amendment?**
-   - **Amendment** (not this skill): small clarifications, typo fixes, reference updates. Edit the original ADR in place.
+   - **Amendment** (not this skill): small clarifications, typo fixes, reference updates. For an Accepted ADR, append a dated correction/pointer rider under [ADR-0025 Rule 2](../../../docs/decisions/0025-adr-governance-amendments.md#rule-2--riders-are-not-failures-their-frequency-is-a-signal), preserving the original body. Proposed drafts remain editable.
    - **Supersession** (this skill): the decision outcome changes, the considered options change meaningfully, or the consequences shift enough that a reader should understand a new decision has been made.
 
 3. **Write the new ADR** using the [write-adr](../write-adr/SKILL.md) skill.
-   - In the **Context** section of the new ADR, explicitly say:
-     > This ADR supersedes [ADR-NNNN: Title](NNNN-slug.md). The earlier decision…
-     Then explain what was decided originally and what has changed to warrant the new decision.
+   - In the **Context** section of the new ADR, explicitly say (template; substitute the actual sibling filename):
+
+```markdown
+This ADR supersedes [ADR-NNNN: Title](NNNN-slug.md). The earlier decision…
+```
+
+   Then explain what was decided originally and what has changed to warrant the new decision.
    - In the **References** section, link the superseded ADR.
 
 4. **Update the old ADR's header.**
    - Change `Status:` from `Accepted` to `Superseded by MMMM` (where MMMM is the new ADR's number).
-   - Add a `> **Superseded.**` callout at the very top of the body, before the Context section:
-     > **Superseded by [ADR-MMMM: New Title](MMMM-new-slug.md) (YYYY-MM-DD).** The original decision below is preserved for the historical record.
+   - Add a callout at the very top of the body, before Context (template; substitute the actual sibling filename and date):
+
+```markdown
+> **Superseded by [ADR-MMMM: New Title](MMMM-new-slug.md) (YYYY-MM-DD).** The original decision below is preserved for the historical record.
+```
    - **Do not edit the original body.** The original reasoning is the historical record and must stay intact.
 
 5. **Update the ADR index** at [`docs/decisions/README.md`](../../../docs/decisions/README.md):
@@ -65,7 +72,7 @@ Before starting, the agent must have:
 - **Superseding without new information.** If nothing has changed, the old decision is still right and supersession is not needed.
 - **Silent overrides.** Making a contradicting decision in a new ADR without flipping the old one's status leaves the repo with two contradictory "Accepted" ADRs.
 - **Forgetting the back-pointer.** The old ADR must link forward to the new one; otherwise a reader following references misses the supersession.
-- **Using supersession for a minor fix.** That is an amendment, not a supersession. Edit in place.
+- **Using supersession for a minor fix.** That is an amendment, not a supersession. Append a dated correction/pointer to an Accepted record; preserve its body.
 
 ## References