FE-795: Track live graph observer frontier

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

@@ -11,7 +11,7 @@ If context is unclear, ask **one** clarifying question — then recommend.
 
 The canonical rule is simple: durable planning state lives only in `memory/SPEC.md` and `memory/PLAN.md`, and new or uncertain work defaults to the canonical flow until a narrow exception is clearly justified.
 
-Do not invent new planning documents, sidecar ledgers, or alternate storage locations without explicit user permission. If a fact matters beyond the current step, reconcile it into `memory/SPEC.md` or `memory/PLAN.md`; if it is temporary transfer state, keep it in `HANDOFF.md`; if it is a temporary multi-card execution queue inside one frontier item, keep it in `memory/CARDS.md`; if it is a temporary refactor execution plan, keep it in `memory/REFACTOR.md`. Derivative files stay live only while they still carry unfinished work.
+Do not invent new planning documents, sidecar ledgers, or alternate storage locations without explicit user permission. If a fact matters beyond the current step, reconcile it into `memory/SPEC.md` or `memory/PLAN.md`; if it is temporary transfer state, keep it in `HANDOFF.md`; if it is one or more prepared scope cards for a frontier item, keep them in a scope file under `memory/cards/`; if it is a temporary refactor execution plan, keep it in `memory/REFACTOR.md`. Derivative files stay live only while they still carry unfinished work.
 
 Orient, then classify.
 
@@ -62,7 +62,7 @@ Bounded exception:
 
 Bounded serial exception:
 
-`ln-scope → ln-build → commit → ln-build ...` inside one already-settled frontier item, optionally with the prepared queue persisted in `memory/CARDS.md`
+`ln-scope → ln-build → commit → ln-build ...` inside one already-settled frontier item, optionally with the prepared chain persisted as a `Mode: chain` scope file under `memory/cards/`
 
 Direct-build exception:
 
@@ -100,7 +100,7 @@ Spikes are the escape hatch, not the default.
 | Spec exists, needs work sequencing | structural | `ln-plan` |
 | Verification strategy is the main uncertainty | structural | `ln-oracles` |
 | Next work item needs precise boundaries | structural or bounded | `ln-scope` |
-| 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` |
+| One settled frontier item needs several small verified commits in sequence | bounded, hardening | `ln-scope` then serial `ln-build` loop, optionally via a `Mode: chain` scope file under `memory/cards/` |
 | 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, or a cheap investigation could invalidate planned work | any | `ln-spike` |

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

@@ -10,7 +10,7 @@ Capture what lives in chat but not on disk. Git can reconstruct file changes. Bu
 
 The handoff must let a new thread act immediately without asking clarifying questions.
 
-`HANDOFF.md` is derivative and temporary. It is never canonical planning state: durable truth belongs in `memory/SPEC.md` and `memory/PLAN.md`, prepared multi-card execution queues may live temporarily in `memory/CARDS.md`, and retired history belongs only in `docs/archive/PLAN_HISTORY.md`.
+`HANDOFF.md` is derivative and temporary. It is never canonical planning state: durable truth belongs in `memory/SPEC.md` and `memory/PLAN.md`, prepared scope cards may live temporarily as scope files under `memory/cards/`, and retired history belongs only in `docs/archive/PLAN_HISTORY.md`.
 
 Default to one `HANDOFF.md` at the workspace root. Overwrite or replace the prior handoff; do not create numbered handoff archives, breadcrumb files, or completion tombstones without explicit permission.
 
@@ -35,7 +35,7 @@ Be precise about state:
 This is the critical step. Scan the conversation for volatile artifacts — information discussed but **not yet persisted to disk**:
 
 - **Scope cards** from `ln-scope` — target behavior, boundary crossings, acceptance criteria
-- **Queued scope cards** already persisted in `memory/CARDS.md` — capture only what is still volatile about them: which card is next, whether the queue is still valid, and any card-level corrections that have not been written back yet
+- **Queued scope cards** already persisted in scope files under `memory/cards/` — capture only what is still volatile about them: which file is active, which card is next, whether the chain is still valid, and any card-level corrections that have not been written back yet
 - **Plan drafts** from `ln-plan` — slice lists, ordering decisions, dependency reasoning not yet in `memory/PLAN.md`
 - **Design outputs** from `ln-design` — alternative module shapes considered, the chosen shape, and rejected tradeoffs
 - **Oracle design outputs** from `ln-oracles` — O/R/C assessment, selected oracle families, per-frontier or per-slice verification approaches, acknowledged blind spots, and whether verification design is complete / pending / stale relative to the code
@@ -57,7 +57,7 @@ What IS on disk:
 - **Git**: branch, recent commits (last 3-5), dirty/staged files
 - **Test status**: run the verification command if fast (<30s), otherwise note last known status
 - **Artifacts**: which of `memory/SPEC.md`, `memory/PLAN.md` exist? Are they current relative to what was discussed in conversation, or stale?
-- **Derivative queues**: does `memory/CARDS.md` exist, and if so, is it still the live execution queue or already stale?
+- **Derivative scope files**: do any files exist under `memory/cards/`, and if so, which are still live and which are already stale?
 - **Mini-sync triggers**: did manual verification happen, did frontier status change, or did residual risk surface without a doc update? If yes, name the exact drift the next thread must reconcile.
 
 ### 4. Produce handoff

.agents/skills/ln-handoff/assets/handoff-template.md

@@ -60,7 +60,7 @@
 | ------------------ | ------ | ------------------------- |
 | memory/SPEC.md     | yes/no | current / stale / missing |
 | memory/PLAN.md     | yes/no | current / stale / missing |
-| memory/CARDS.md    | yes/no | current / stale / n/a     |
+| memory/cards/      | list   | files: active / stale / n/a per file |
 | memory/REFACTOR.md | yes/no | current / stale / n/a     |
 
 ## Next steps

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

@@ -81,7 +81,7 @@ Update `memory/SPEC.md` §Verification Design:
 Update `memory/PLAN.md` frontier annotations:
 
 - Add or refresh the `Verification` line in each in-scope frontier definition with oracle family, loop tier, and cross-reference to `memory/SPEC.md` sections
-- Keep slice-level oracle detail in the current `ln-scope` card or `memory/CARDS.md` queue unless it changes the frontier definition
+- Keep slice-level oracle detail in the current `ln-scope` card or its scope file under `memory/cards/` unless it changes the frontier definition
 
 ### Cross-reference integrity
 

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

@@ -8,7 +8,7 @@ argument-hint: "[feature or project area to plan]"
 
 Plan the **rolling frontier**, not the whole historical timeline.
 
-`memory/PLAN.md` is the canonical record of what's next. `docs/archive/PLAN_HISTORY.md` is the only sanctioned archive for retired plan history. `memory/CARDS.md` is the sanctioned derivative queue for multiple prepared scope cards inside one frontier item; it is not canonical planning state. Do not invent other sidecar plan docs, milestone ledgers, or alternate memory locations without explicit permission.
+`memory/PLAN.md` is the canonical record of what's next. `docs/archive/PLAN_HISTORY.md` is the only sanctioned archive for retired plan history. `memory/cards/` is the sanctioned derivative location for prepared scope cards; one file per concern, named `<frontier-id>--<slug>.md` (or `dev--<slug>.md`, `tooling--<slug>.md`, `docs--<slug>.md` for non-frontier work). Scope files are not canonical planning state. Do not invent other sidecar plan docs, milestone ledgers, or alternate memory locations without explicit permission.
 
 ## Frontier vs slice vocabulary
 
@@ -39,7 +39,7 @@ Within `Sequencing`, use:
 
 Archive deeper history to `docs/archive/PLAN_HISTORY.md` instead of keeping it live in `memory/PLAN.md`.
 
-Treat frontier items as branch-sized work, not commit-sized work. If one frontier item will unfold as several consecutive verified slices, keep that execution queue in `memory/CARDS.md` or in session context instead of fragmenting `memory/PLAN.md` into a commit ledger. `memory/PLAN.md` may carry at most a lightweight pointer such as `current card queue: memory/CARDS.md`; detailed discretionary sub-slicing belongs in `memory/CARDS.md`.
+Treat frontier items as branch-sized work, not commit-sized work. If one frontier item will unfold as several consecutive verified slices, keep that chain in a `Mode: chain` scope file under `memory/cards/` or in session context instead of fragmenting `memory/PLAN.md` into a commit ledger. `memory/PLAN.md` may carry at most a lightweight pointer such as `current execution pointer: memory/cards/<frontier-id>--<slug>.md`; detailed discretionary sub-slicing belongs in the scope file itself.
 
 ## Input
 
@@ -135,7 +135,7 @@ This sequencing pressure is distinct from "Epistemic horizon": that rule tells t
 6. Add `Why now / unlocks` in a frontier definition when ordering would otherwise be opaque to a fresh thread.
 7. Keep `Recently Completed` to 2-3 terse items max. Move older history to `docs/archive/PLAN_HISTORY.md`, not to handoff files or ad hoc notes.
 8. Update `Dependencies` to reflect only active / next items, by frontier id.
-9. If several commit-sized execution steps are already obvious inside one frontier item, keep them out of `memory/PLAN.md`; they belong in `memory/CARDS.md` or in the active thread as derivative execution detail.
+9. If several commit-sized execution steps are already obvious inside one frontier item, keep them out of `memory/PLAN.md`; they belong in a scope file under `memory/cards/` or in the active thread as derivative execution detail.
 
 ### Cross-cutting obligations
 

.agents/skills/ln-plan/assets/plan-template.md

@@ -48,7 +48,7 @@
 - **Cross-cutting obligations:** [optional: subsystem / invariant / verification-layer obligations this frontier must preserve or establish]
 - **Traceability:** [→ SPEC.md requirement / assumption / decision / invariant if needed]
 - **Design docs:** [links if relevant]
-- **Current execution pointer:** [optional: `memory/CARDS.md` or next intended scope card; omit when not needed]
+- **Current execution pointer:** [optional: active scope file path(s) under `memory/cards/` for this frontier — list all active; omit when not needed]
 
 ## Recently Completed
 

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

@@ -20,7 +20,7 @@ The area to refactor: $ARGUMENTS
 
 1. Capture the problem. Explore the codebase to verify assertions. Present alternatives the user may not have considered. Hammer out exact scope — what changes, what stays.
 2. Check test coverage of the affected area. If coverage is insufficient for safe refactoring, the first step must be characterization tests (Feathers, *Working Effectively with Legacy Code*) — suggest `ln-build` for that before continuing.
-3. Break the refactor into tiny commits. Order by safety: renames first (align to the lexicon in `memory/SPEC.md` if it exists), then extractions (deepen shallow modules — Ousterhout), then interface alignments, then behavioral changes last. Each commit is a complete, passing state.
+3. Break the refactor into tiny commits. Order by safety: renames first (align to the lexicon in `memory/SPEC.md` if it exists), then extractions (deepen shallow modules — Ousterhout), then interface alignments, then behavioral changes last. Each commit is a complete, passing state. When a commit moves, renames, retires, or replaces files inside a directory that owns a `README.md`, the README update belongs in **the same commit as the topology change** — never deferred to a follow-up (see `AGENTS.md` §topology READMEs).
 4. Write the refactor plan to `memory/REFACTOR.md`. Delete the file when the refactor is complete or superseded.
 
 ## Output
@@ -52,6 +52,7 @@ Ordered list of tiny commits. Each described in plain English — no file paths
 - Interface changes
 - Architectural decisions
 - Schema changes, API contracts
+- Topology READMEs touched (which directory READMEs the refactor will update or retire)
 
 No file paths or code snippets — they go stale. Record in `memory/SPEC.md` §Decisions when finalized.
 

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

@@ -88,6 +88,18 @@ Concrete cues to look for:
 
 Collect findings as numbered items (category: `topography`). Frame each as: what the reader sees today, what they would have to internalize to find things, and the smallest topographic move that would make the tree teach itself. Routing for coordinated layout changes goes through `ln-refactor`; a single misplaced file can be a `ln-scope` slice.
 
+### Topology README accuracy (category: `topography`)
+
+Directory `README.md` files under `src/**/` are canonical topology documentation (see `AGENTS.md` §topology READMEs). For each touched area, open the nearest README and check:
+
+- **Ownership statement** still matches what the directory actually owns and does not own
+- **SPEC decision IDs** cited (e.g. `D52-L`) still exist in `memory/SPEC.md` and still mean what the README implies they mean
+- **Dependency-direction assertions** ("`graph/` imports from `db/`; no other layer imports `db/` directly") match the actual import graph in the touched files
+- **Layout sketches** still match the directory's contents — no retired files still listed, no new files unmentioned
+- **Migration notes** describe state that is still pending; shipped or abandoned migrations are stale and should retire
+
+Collect mismatches as numbered findings. Frame each as: which README, which claim, what the code now says. Routing for coordinated README updates clusters with other topographic findings into `ln-refactor`; a single stale citation can be a `ln-scope` slice (or, if the change is mechanical, an `ln-build` direct fix).
+
 ## Output
 
 Present findings as numbered candidates. Use the compact form for ordinary findings: