FE-744: Document Pi command containment evidence

.agents/skills/ln-build/SKILL.md

@@ -91,6 +91,8 @@ Run the project's verification harness. All checks must pass. If the card proved
 
 After verification, reconcile canonical state every time. The reconciliation may end in a no-op, but skipping it is not allowed.
 
+**Notation aid.** When the reconciliation records slice acceptance breakdowns, module sketches, call/dependency shapes, or schema-shaped invariants into canonical docs, use `pseudo` forms (`tree` for obligation decomposition; `chain` for call graphs; `graph` for cross-module relations; `data-shape` for sketched schemas). Preserve any `pseudo` artifacts already present in SPEC/PLAN — do not collapse them back into prose.
+
 Traceability depth is **conditional**, not automatic.
 
 After the build lands and verification passes, ask:
@@ -150,12 +152,19 @@ Before finishing reconciliation, perform a quick cross-skill check: if a later a
 
 ### Retire derivative artifacts
 
-After reconciliation, garbage-collect exhausted temporary files instead of leaving breadcrumbs or tombstones:
+After reconciliation, garbage-collect exhausted temporary files instead of leaving breadcrumbs or tombstones, but deletion is narrowly scoped.
+
+Default deletion target:
+
+- `memory/CARDS.md` — delete only when the execution queue is fully exhausted, superseded, or empty after reconciliation.
+
+Other volatile artifacts are **review-before-delete**, not automatic cleanup:
+
+- `HANDOFF.md` — delete only when it contains no unfinished transfer state and no future-context inventory that is not already captured in `memory/SPEC.md`, `memory/PLAN.md`, an active scope card, or a stable design memo.
+- `memory/REFACTOR.md` — delete only when every listed refactor step is done/dropped and no future sequence depends on it.
+- Provisional docs outside `memory/` (for example `docs/**/provisional*.md`, handoff plans, spike plans, or exploration inventories) — do **not** delete during `ln-build` cleanup unless the user explicitly asks or you first prove that all remaining future-facing inventory has been absorbed elsewhere. If only the current card is done but the artifact still contains later affordances, open questions, or scoping input, update it instead of deleting it.
 
-- `HANDOFF.md` — keep only if unfinished volatile transfer state still exists; otherwise delete it
-- `memory/CARDS.md` — keep only while queued scope cards still remain; otherwise delete it
-- `memory/REFACTOR.md` — keep only while unfinished refactor steps still depend on it; otherwise delete it
-- Do not create archive copies, numbered handoffs, or completion-pointer files
+Before deleting anything other than `memory/CARDS.md`, name the file, state why no future agent would need it, and prefer asking the user when uncertain. Do not create archive copies, numbered handoffs, or completion-pointer files.
 
 ## Routing
 

.agents/skills/ln-consult/SKILL.md

@@ -30,6 +30,7 @@ Start the assessment with 2-4 bullets naming:
 - the active frontier item or nearby priority
 - volatile state or manual follow-up from handoff
 - the main open risk
+- the cheapest tracer bullet that would score on proof of life, invariants, or uncertainty retirement (see `docs/praxis/ln-skills.md` §Tracer-bullet sequencing)
 
 ## Work-type classification
 
@@ -72,9 +73,23 @@ Only recommend the bounded or direct-build exceptions when all of these are true
 - the containing seam is already named in the live docs
 - no durable requirement / assumption / decision / invariant change is expected
 - post-build reconciliation can plausibly be a no-op
+- no high-impact unresolved `memory/SPEC.md` §Assumption is load-bearing for this work
 
 Only recommend the bounded serial exception when those same conditions hold and the next several commit-sized steps are obvious enough to queue without fresh planning.
 
+## Tracer-bullet override
+
+When several routes fit the work, prefer the one that fires the **tracer bullet that tells you the most**. A tracer-bullet slice scores on three convergent axes (see `docs/praxis/ln-skills.md` §Tracer-bullet sequencing): proof of life, invariants, uncertainty. The best next slice scores on more than one.
+
+Given the repo's pre-release posture, attack uncertainty by building. Recommend a non-build route only when no buildable tracer bullet can carry the proof:
+
+- `ln-design` — module shape itself is uncertain and any slice would lock in the wrong seam
+- `ln-oracles` — verification is too uncertain to distinguish a passing slice from a wrong one
+- `ln-spike` — research-grade or external question (third-party API contract, vendor perf characteristic, library behavior under load)
+- `ln-prototype` — feel, comparison, or UX-legibility question where playable variants beat real code
+
+Spikes are the escape hatch, not the default.
+
 ## Routing table
 
 | Situation | Work type | Suggest |
@@ -88,7 +103,7 @@ Only recommend the bounded serial exception when those same conditions hold and
 | One settled frontier item needs several small verified commits in sequence | bounded, hardening | `ln-scope` then serial `ln-build` loop, optionally via `memory/CARDS.md` |
 | Module interface needs exploration | structural | `ln-design` |
 | Full or light scope card exists, ready to code | bounded, hardening, bugfix | `ln-build` |
-| Technical uncertainty blocks progress | any | `ln-spike` |
+| Technical uncertainty blocks progress, or a cheap investigation could invalidate planned work | any | `ln-spike` |
 | Code works but needs restructuring | refactor | `ln-refactor` |
 | Code works but quality / architecture needs audit | any | `ln-review` |
 | Docs are stale, overweight, or milestone context needs cleanup | structural / maintenance | `ln-sync` |

.agents/skills/ln-design/SKILL.md

@@ -31,7 +31,9 @@ Spawn 3+ sub-agents simultaneously. Each must produce a **radically different**
 - "Optimize for the most common case"
 - "Take inspiration from [specific paradigm or library]"
 
-Each agent returns: **interface** (types, methods, params, invariants, ordering constraints, error modes, required configuration, and performance characteristics), **usage example**, **what it hides**, **seam / adapter strategy** where relevant, and **trade-offs**.
+Each agent returns: **interface** (types, methods, params, invariants, ordering constraints, error modes, required configuration, and performance characteristics), **usage example**, **what it hides**, **seam / adapter strategy** where relevant, **trade-offs**, **load-bearing claims** (1–3 falsifiable beliefs the design rests on — for each, note whether it is already covered by `memory/SPEC.md` §Assumptions), and **cheapest tracer bullet** — the thinnest `ln-scope` slice whose landing would light up the seam and break if the claim is wrong. Fall back to `ln-spike` only when no buildable slice could carry the proof.
+
+**Notation aid.** Express each candidate module shape using `pseudo` (`graph` or `tree` for module relations, `data-shape` for interface shapes, `lanes` for cross-actor seams). Side-by-side `pseudo` artifacts make alternatives directly comparable in the same form rather than as divergent prose.
 
 ### 3. Present and compare
 
@@ -43,16 +45,23 @@ Show each design sequentially, then compare in prose on:
 - **Ease of correct use** vs ease of misuse
 - **General-purpose vs specialized**: flexibility vs focus
 - **Implementation efficiency**: does the shape allow efficient internals?
+- **Epistemic cost**: how much unvalidated reality this shape asks callers / sequencing to trust, and how cheaply that trust can be tested before committing
 
-Highlight where designs diverge most.
+Highlight where designs diverge most, including which design has the cheapest path to falsification if its load-bearing claims are wrong.
 
 ### 4. Synthesize
 
 The best design often combines insights from multiple options. Ask which shape best fits the primary use case and whether elements from other designs are worth incorporating.
 
 ## Output
 
-Present the recommended module shape with rationale. If `memory/SPEC.md` exists, ensure names align with its lexicon.
+Present the recommended module shape with rationale, plus:
+
+- the 1–3 load-bearing claims it rests on
+- which of those are already covered by `memory/SPEC.md` §Assumptions and which need to be added there
+- the recommended first tracer bullet — a thin `ln-scope` slice that would light up the seam and break if the chosen design's highest load-bearing claim is wrong; fall back to `ln-spike` only when no slice could carry the proof more cheaply
+
+If `memory/SPEC.md` exists, ensure names align with its lexicon.
 
 Do not invent a standalone design document unless the user explicitly asks for one. Durable design choices reconcile back into `memory/SPEC.md` and `memory/PLAN.md`.
 
@@ -63,10 +72,11 @@ After choosing a design, present these options to the user (use `tool-ask-questi
 | #   | Label         | Target     | Why                                      |
 | --- | ------------- | ---------- | ---------------------------------------- |
 | 1   | Scope a slice | `ln-scope` | Design is chosen, define the first slice |
-| 2   | Write a spec  | `ln-spec`  | Module needs a full spec before slicing  |
-| 3   | Grill it more | `ln-grill` | Design choice raised new questions       |
+| 2   | Spike first   | `ln-spike` | The chosen design rests on a low-confidence load-bearing claim worth retiring before scoping |
+| 3   | Write a spec  | `ln-spec`  | Module needs a full spec before slicing  |
+| 4   | Grill it more | `ln-grill` | Design choice raised new questions       |
 
-Recommended: **1**
+Recommended: **1** — including when a load-bearing claim is low-confidence, because the preferred falsifier is a tracer-bullet slice that breaks if the claim is wrong. Recommend **2 (Spike first)** only when no buildable slice could carry the proof.
 
 ---
 *Adapted from [mattpocock/skills/design-an-interface](https://github.com/mattpocock/skills/tree/main/design-an-interface).*

.agents/skills/ln-judo-review/SKILL.md

@@ -44,6 +44,8 @@ Functional core / imperative shell (Gary Bernhardt): when independent work is ne
 
 If yes, name it. Do not settle for a cleaner version of the same messy idea when a much simpler idea is plausible.
 
+**Notation aid.** When proposing a code-judo move, express it as paired `pseudo` artifacts — current shape (`tree` for module structure, `graph` for control/dependency, `chain` for call flow) → desired shape with the deleted branches, helpers, modes, or layers visibly absent. A concrete before/after pair shows whether complexity actually *vanishes* rather than relocates — which is the whole point of judo over rearrangement. Node/edge counts before vs after are honest metrics: a desired-state graph with fewer nodes and fewer edges than the current one is the artifact form of "deletions over rearrangements."
+
 ## Tone
 
 Direct, serious, demanding. Not rude. Do not soften major maintainability issues into mild suggestions. Worked examples of the register:

.agents/skills/ln-plan/SKILL.md

@@ -18,6 +18,8 @@ Use **slice** for the buildable scope card produced by `ln-scope` and implemente
 
 The vertical-slicing instinct still applies at planning time: frontier items should cut through the relevant concerns of `memory/SPEC.md` instead of becoming layer-by-layer chores. The term "frontier" names their canonical/branch role; the term "slice" remains reserved for scoped execution.
 
+**Notation aid.** Express the `Dependencies` block as `pseudo graph` rather than a hand-drawn tree — cross-edges (optional successors, on-promotion edges) and dependency-edge types (`-[hard]->`, `-[optional]->`, `-[on promotion]->`) stay visible, and horizon items go in an `unconnected` group so they're acknowledged without implying spine relations. See `pseudo references/graph.md` worked example "roadmap dependency graph."
+
 ## Plan document shape
 
 Prefer the conflict-resistant mature shape:
@@ -100,6 +102,29 @@ When a frontier completes, remove it from `Sequencing`, add a terse `Recently Co
 
 If live low-confidence assumptions block downstream work, stop the plan at that boundary. Plan spikes or thinner proving frontier items, not fantasy certainty.
 
+### Tracer-bullet sequencing
+
+Sequencing is not only seam-driven. A good tracer-bullet frontier scores on three convergent axes (see `docs/praxis/ln-skills.md` §Tracer-bullet sequencing): **proof of life**, **invariants**, **uncertainty**. The strongest next frontier scores on more than one.
+
+When ranking candidates, weigh:
+
+- **blast radius** if a load-bearing assumption turns out false
+- **reversibility cost** if discovered late vs early
+- **validation cost** (cheap slice vs expensive end-to-end rework)
+- **load-bearingness** (how many active/next frontiers depend on it)
+
+Annotate each `Active` / `Next` frontier definition with the relevant axes when they are in play:
+
+- `Retires: <SPEC assumption id(s)>` — collapses the assumption by landing
+- `Depends on: <SPEC assumption id(s)> (validated enough)` — assumption must be settled first
+- `Blocked by: <SPEC assumption id(s)>` — load-bearing; do not start until retired
+- `Lights up: <pipeline / seam>` — establishes a new end-to-end path
+- `Stabilizes: <invariant id(s) or seam>` — locates or fixes structure others will aim from
+
+**Spike exception.** Use `ln-spike` only when no buildable frontier could carry the proof. Do not insert ceremonial spikes when a tracer-bullet frontier exists.
+
+This sequencing pressure is distinct from "Epistemic horizon": that rule tells the planner to *stop* at fog; this rule tells the planner to **fire the tracer that tells you the most**.
+
 ## Procedure
 
 1. Read `memory/PLAN.md` if it exists. Identify existing frontier ids and retire/archive stale completed material into `docs/archive/PLAN_HISTORY.md`.
@@ -146,7 +171,8 @@ After writing the plan, present these options to the user (use `tool-ask-questio
 | --- | ----------------- | ------------ | --- |
 | 1   | Scope next slice  | `ln-scope`   | The frontier is clear and ready to scope |
 | 2   | Design oracles    | `ln-oracles` | Verification design needs explicit work |
-| 3   | Grill it more     | `ln-grill`   | Planning surfaced unresolved product questions |
-| 4   | Back to triage    | `ln-consult` | Direction needs reassessment |
+| 3   | Spike first       | `ln-spike`   | A load-bearing assumption should be retired before scoping |
+| 4   | Grill it more     | `ln-grill`   | Planning surfaced unresolved product questions |
+| 5   | Back to triage    | `ln-consult` | Direction needs reassessment |
 
-Recommended: **1**
+Recommended: **1** unless tracer-bullet sequencing surfaced a question that no buildable frontier could answer cheaper than a spike (then **3**).

.agents/skills/ln-refactor/SKILL.md

@@ -36,6 +36,8 @@ What is wrong, from the developer's perspective.
 
 The target state, from the developer's perspective.
 
+**Notation aid.** Express the structural delta as paired `pseudo` artifacts — `tree` current → `tree` desired, or `graph` current → `graph` desired — under the Problem Statement / Solution headings. The paired form makes the change concrete before commits begin and gives reviewers a single artifact to diff.
+
 ## Commits
 
 Ordered list of tiny commits. Each described in plain English — no file paths or snippets. Each leaves the codebase working.