intent-planner 0.13.1

package/templates/en/claude/skills/intent-improve/rules/improve-axes.md

@@ -0,0 +1,121 @@
+# Improve: three-axis evaluation and classification criteria
+
+Rules for cross-checking the `.intent/` deliverables against the implementation reality in post-implementation realignment. Used by the `intent-improve` skill. Whereas writeback is the regular per-packet path, improve is the cross-cutting safety net that also catches drift not tied to a packet.
+
+## The three evaluation axes
+
+- **completeness** (whether the intended content has been realized): whether the Expected Behavior / Scope of the packet files under active/ appears in the implementation and tests (the cross-cutting read is limited to active/; do not read archive/). Detects unrealized or partially realized content.
+- **correctness** (whether the realized content matches the intent): whether the implemented behavior matches the packet's Why / Expected Behavior. Detects realizations that differ from the intent and additions outside the intent.
+- **coherence** (whether the implementation is consistent with the North Star, Invariants, and Decision Rules): whether the implementation contradicts the North Star / Invariants / Anti-direction / Decision Rules of intent-compass.md. Detects local optimizations and invariant violations. It also detects Decision entries whose Revisit when conditions in the Decision Rules of intent-compass.md can be read as met from the implementation reality and `deltas` (cross-read in split form: the split files `.intent/deltas/*.md` (source of truth if present, natural-key ascending) → read-fallback to the legacy single `.intent/deltas.md` (generated mirror) if absent; when both coexist, treat split as source of truth and do not double-count the mirror). Report such detections with evidence under the existing classification "Decision Rules update recommended" (do not create a new classification). In addition, as a separate path with a different input source, substring-match each event string in `.intent/milestones.md` against the `Revisit when` field of every Decision Rule, and re-propose any matched Decision Rule for review under the same "Decision Rules update recommended" classification. Rules whose `Revisit when` is explicitly recorded as "undecided" are excluded from matching (so as not to produce a false firing). To avoid over-matching on events that are too short, assume sufficiently specific events (at or above a certain length). This milestones-originated matching is read-only and report-only; it does not auto-rewrite the compass and does not create a new corrective classification. The implementation/deltas-originated Revisit detection and the milestones-originated matching coexist, and both are reported under the "Decision Rules update recommended" classification.
+
+## Classification (5 kinds; multiple may apply)
+
+- **aligned**: no drift. Consistent on all three axes (no correction needed; still attach the evidence of consistency).
+- **intent reinforcement recommended**: the implementation is sound, but the `.intent/` side is thin or left implicit. Present update proposals that add to or clarify the deliverables (intent-tree.md / intent-compass.md / packet files).
+- **corrective packet recommended**: the drift is on the implementation side and code changes are needed. Since improve does not change code, present the corrective work as a new packet proposal (an addition proposal of a new packet file (under active/) → export → the regular path of cc-sdd implementation).
+- **Decision Rules update recommended**: a judgment gained in implementation conflicts with the existing Decision Rules, or a new decision criterion is needed. A Decision entry whose Revisit when conditions are detected as met is also reported for review under this classification. Follow the "Decision Rules change convention" below.
+- **invariant violation detected**: the implementation violates the Invariants. Report it with top priority and present a corrective packet proposal or a review of the invariant itself (the user's call).
+
+When multiple classifications apply, list them all, and organize the report per classification.
+
+## Handling of evidence
+
+- Sources of the implementation reality: the codebase (Read/Glob/Grep only; changes forbidden), the presence and placement of tests, the progress of `.kiro/specs/`, and `deltas` (promoted / pending; cross-read in split form). All of them are **read-only**.
+- **Cross-read `deltas` in split form (CONTRACT "Split and archive convention for append-only records"; the same discipline as `intent-overview`'s `aggregate-sources.md`)**: read the split files `.intent/deltas/*.md` (source of truth if present, natural-key ascending) → read-fallback to the legacy single `.intent/deltas.md` (generated mirror) if absent; when both coexist, treat split as source of truth and do not double-count the mirror; archive is history and is not mixed into the active tally (read-only).
+- Always attach evidence (file / relevant text) to the evaluation. Do not present an evaluation or correction proposal whose evidence cannot be shown.
+
+## Decision Rules change convention (the same convention as writeback)
+
+- A correction that changes the Decision Rules **adds a new entry** in the existing ADR form of intent-compass.md (**Context** / **Decision** / **Why** / **Alternatives considered** / **Consequences** / **Revisit when**) and annotates the superseded old entry as superseded with a reference to the succeeding entry.
+- Move the old entry annotated as superseded, with its 6 fields intact (do not summarize), into the retired Decision Rule's **per-rule file** `.intent/compass-archive/<rule-slug>.md` (CONTRACT split & archive convention; `<rule-slug>` via the existing slug rule — no new numbering; re-superseding the same rule collects into the same file). Create the `compass-archive/` directory if absent. Active Decision Rules entries remain written directly inside the compass.
+- Do not delete the old entry (history is preserved in compass-archive.md). Do not introduce custom fields (e.g., Supersedes).
+- Old 4-field entries recorded before the introduction of the 6-field format (those without Alternatives considered / Revisit when) remain valid; do not treat the missing fields as an error, flag them, or rewrite them.
+
+## Writeback guidance (division of roles as the safety net)
+
+- When an unrecorded write-back learning is detected — no delta entry in `deltas` (cross-read in split form: the split files `.intent/deltas/*.md` (source of truth if present) → read-fallback to the legacy single `.intent/deltas.md` if absent; no double-count) corresponding to the current Source Packet (the latest export), or an unrecorded decision that surfaced in the implementation — do not write a delta yourself; prompt the user to run `/intent-writeback`.
+- When declined items with the "on-hold" tag remain, only prompt for a re-proposal or a confirmed rejection. The final tag update (promote / confirm rejection / keep on hold) is the responsibility of `/intent-writeback`.
+- improve does not write into the `deltas` record (in either split or legacy single-mirror form) (all recording and state updates of deltas are done by writeback).
+
+## Validate catch-up guidance (a bridge to the conformance check)
+
+- Only when that run's 5 classifications include `Decision Rules update recommended` or `invariant violation detected` (= a run where a reflection that could affect compass's Decision Rules / Invariants may arise), attach, alongside the writeback guidance, one sentence prompting the user to run `/intent-validate` (the cross-check of whether a compass update has been caught up by each packet = the check for conformance staleness). On a run that is `aligned` only, or that does not include the two classifications above, do not attach it (avoid over-prompting).
+- improve itself does not make the conformance staleness judgment (the estimate of the right moment). The estimate of the right moment is the responsibility of intent-status, and improve only guides. The definitive diagnosis is made by `/intent-validate`.
+- This guidance is limited to adding a guidance sentence and does not change the three-axis evaluation (completeness / correctness / coherence) or the 5-classification logic at all (the 5 classifications are unchanged).
+
+## Recording to drift-log (drift-watch-linked)
+
+Only when `drift-watch: on`, copy the drift detected on the coherence axis (invariant violation / anti-direction conflict) into `.intent/drift-log.md` as an after-the-fact record. When `off` / missing / invalid, do not record (byte-equivalent to current behavior; the off-guard is guaranteed on the SKILL.md side).
+
+### Recording procedure
+
+- **Reuse the drift the coherence axis detected (invariant violation / anti-direction conflict) rather than detecting it anew**, and append it one at a time to `.intent/drift-log.md` as a `stage: improve` entry. The values are:
+  - `pattern: <the matched drift-patterns id | uncatalogued:<short name> | ->` (an id if identifiable, `uncatalogued:<short name>` for an actual drift outside the catalog, `-` if undeterminable)
+  - `stage: improve`
+  - `packet: <the attributable packet name | ->` (`-` if attribution cannot be determined)
+  - `mechanism: compass-invariant` (when an Invariant is violated) or `compass-anti-direction` (when the Anti-direction is conflicted; choose by which compass element was breached)
+  - `outcome: missed` (**a draft**: at improve time the drift has already happened and slipped through, so it is `missed` by default. The verdict is backed by the user's `user-verdict` being valid / false-alarm / unjudged)
+  - `user-verdict: unjudged`
+  - `recorded_at: <ISO 8601>`
+  - `commit: <short hash | ->`
+  - `note: <1-2 lines>` (what was violated / conflicted)
+- If multiple drifts are detected, append one entry per drift.
+- **Write in split form (CONTRACT "Split and archive convention for append-only records")**: drift-log is event-origin, so instead of appending to the end of a single `drift-log.md`, write one entry to a **per-date+slug split file** `drift-log/<date>-<slug>.md`. `<date>` is the recorded_at date; `<slug>` is derived from the pattern (the event) via the existing slug rule (`intent-packets/rules/packet-format.md`) — do not create new/sequential numbering. Because a different event touches a different file, tail collisions disappear by construction. Never rewrite or delete an existing entry (**append-only**).
+- **Always write all 9 keys in the fixed order**: `pattern` → `stage` → `packet` → `mechanism` → `outcome` → `user-verdict` → `recorded_at` → `commit` → `note`. Do not write an entry that is missing even one of the 9 keys.
+- **commit**: write the result of `git rev-parse --short HEAD`. When it cannot be obtained (non-repository, git CLI absent, etc.), use `-` (fail-open: keep recording).
+- **When the `drift-log/` directory is absent**: create the directory, then write the split file. An old single `drift-log.md`, if still present, can be read side-by-side by readers (migration is handled by this slice's migration step). Follow the sample in the "Entry format" section of `.intent/drift-log.md` (`### drift-log entry`) for the entry format.
+
+### Do not create a new correction class (separating recording from correction)
+
+- This recording **does not create a new correction class**. The "Classification (5 kinds)" above (aligned / intent reinforcement recommended / corrective packet recommended / Decision Rules update recommended / invariant violation detected) is left entirely unchanged. It merely **also copies** the drift detected on the coherence axis **into the drift-log schema**, separately from the correction classification.
+- **drift-watch records, improve corrects**. Recording (drift-log) and correction (the 5 classes) are separate responsibilities and are not mixed. Appending to drift-log neither substitutes for nor alters any correction.
+
+## Improvement report (pattern × outcome cross-tabulation)
+
+When `drift-watch: on`, improve also presents in its output an improvement report that cross-tabulates drift-log by `pattern × outcome`.
+
+- **The aggregation keys are aligned to the type (pattern)**. The structure by which the user can later reconcile the "without group (past failures) / with group (the drift-watch-on period)" is established **by the type id and the `commit` column of drift-log only** (do not create an additional comparison mechanism).
+- The report must always carry the following **honesty notes**:
+  - Read `missed=0` as "a suspicion of missing records," not "evidence it worked" (keeping only the moments it worked in the tally is confirmation bias).
+  - Frequent `false-positive` suggests the anti-direction is too broad.
+- These notes are of the same intent as the honesty note in `.intent/drift-log.md` and guarantee a reading not biased toward the "worked" family (prevented / caught).
+
+### Reading packet-scope-overflow as an "instrument that measures the first defense's efficacy" (DR9 second defense)
+
+Entries with `mechanism: packet-scope-overflow` (the second-defense detection drift-watch records when, after export, the user issues an implementation instruction that exceeds the target packet's `## Scope`) are read as an instrument that measures **whether the first defense (the convention-doc rule "go back to intent on scope overflow"—recall only, no enforcement) is actually working**. They ride the same pattern × outcome cross-tally, with one added reading discipline:
+
+- `outcome: caught` (the user heeded the warning and returned to intent via `/intent-packets` → re-export) = a moment when the first and second defenses worked.
+- `outcome: missed` (they ignored the warning and pushed through with cc-sdd) = a moment when the first defense's recall did not work = the **denominator of the intent-shift rate (the rate of scope creep)**. Only as these accumulate can "how much the first defense is failing" be observed (the chicken-and-egg: the mechanism that measures the first defense's efficacy lives inside the second defense itself).
+- `outcome: false-positive` (it was actually a valid scope extension) = a sign the check may be over-sensitive.
+- **Do not bring in numeric scoring or threshold solvers.** Do not assert "more caught means the first defense is working"; carry over the honesty notes as-is (`missed=0` = suspected missing record, frequent `false-positive` = over-sensitive check) and keep it to candidate presentation. Align the tally key to the type (pattern = `scope-creep` or `uncatalogued:scope-overflow`); build no extra comparison machinery.
+
+## Role boundary (the three-way split of recording, correction, and writeback)
+
+- **drift-watch does not hook writeback** (Requirement R8). So as not to muddy writeback's single responsibility — the two-stage promotion of deltas — recording to drift-log does not interfere with the writeback path at all. The behavior of "Writeback guidance" above is unchanged.
+- Recording (drift-log), correction (the 5 classes), and writeback (the two-stage promotion of deltas) are **three separate responsibilities**. Do not mix the three.
+
+## Context cost cues (tied to drift-watch)
+
+Alongside the coherence-axis evaluation, run a matching that makes you **notice** whether the way you are doing the post-implementation realignment is eating context (tokens). This is a **separate catalog** from drift-patterns (types of intent drift); only the symptom differs — it is "a situation that eats context" rather than "intent drift". This is awareness, not a norm, and because it differs in nature from the "recording to drift-log" and "improvement report (pattern×outcome tally)" above, it is **kept as a separate procedure**.
+
+- **Only when `drift-watch: on`** do this matching (do nothing when off / unset / invalid). When `.intent/context-cost-cues.md` is absent, skip the matching and announce that (do not stop).
+- **This is not recorded to any log.** Unlike the coherence-deviation detection above (which appends to `drift-log.md` and tallies pattern×outcome), context cost cues are **not appended to `drift-log.md` or to any other log**. Reason: consumption cannot be measured and its outcome cannot be evaluated, so mixing it into the log would pollute the drift-log tally with guesses; furthermore, what eats context legitimately differs per person, so recording it would intrude on privacy. **Do not apply the "append procedure for drift-log" or the "improvement-report tally" above to this matching, and do not include it in the pattern×outcome tally.**
+- **The 5 classes are unchanged**: this cue does not alter the existing 5 classes (aligned / strengthen intent / corrective packet / update Decision Rules / invariant violation) at all. It is presented as advice that leaves no log, separate from the corrective classes.
+
+### Procedure
+
+1. **Read context-cost-cues.md**
+   - Read `.intent/context-cost-cues.md` and obtain all types (seed + every type the user has grown). If absent, skip and announce (do not stop).
+
+2. **Match each type's symptom against how the realignment is proceeding**
+   - Check each type's `symptom` against the post-implementation realignment (the path/subject of reading code or done work). The `symptom` is a weak cue; if the fit is weak, stay silent (lean toward staying silent over false positives — to keep the awareness feature trustworthy).
+   - Use only the subject for matching. Do not read token consumption, git diffs, or runtime metrics.
+
+3. **When a type matches (present the cue; do not write to any log)**
+   - Name it to the user in a noticing tone. Example: "The way this realignment is proceeding may match `<id>` — this might be eating context."
+   - Add the type's "if this is unintentional" light alternative (thin entry point / JIT pull / limited input) as an **optional choice**. Example: "If this is unintentional, there is also <light alternative> (the judgment is yours)."
+   - **Do not correct or instruct.** Phrase it as a cue rather than an imperative or a verdict. Installing many skills or loading full content can be a legitimate high-cost choice, so do not dismiss a context-eating choice as unnecessary. Leave the judgment to the user.
+   - **Do not append to any log** (do not reuse the coherence-deviation append procedure or tally).
+
+4. **When no type matches**
+   - Name nothing. **Write nothing to any log** (do not record a miss either — this matching has no log at all).

package/templates/en/claude/skills/intent-overview/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: intent-overview
+description: Read-only aggregation skill that reads the scattered .intent/ artifacts and generates a formatted read-through/overview view under .intent/overview/ as a derived view. Never modifies any canonical artifact.
+allowed-tools: Read, Glob, Grep, Write
+argument-hint: none
+---
+
+# intent-overview Skill
+
+## Core Mission
+- **Success Criteria**:
+  - Reads the existing scattered `.intent/` artifacts (intent-tree / intent-compass / packets index & active / packets/plan / export-log / deltas / mode / drift-log) read-only, and generates a formatted overview view that humans and agents can read through at once at `.intent/overview/overview.md` (R1.1)
+  - Treats the output as a derived view and never creates, modifies, or deletes any canonical `.intent/*.md` artifact. Writes are limited to under `.intent/overview/` (R1.2)
+  - On re-run, regenerates the overview from the latest artifacts by full replacement, producing no duplication of the source of truth (idempotent regeneration. R1.3)
+  - When `.intent/` or a required artifact (e.g. intent-tree) is absent, writes nothing, states the absence explicitly, and guides the user to the skill to run first (e.g. `/intent-discover`) (R1.4)
+  - Makes clear that the output is derived / regenerable / not the source of truth (and Git-untracked) (the reader's concern takes priority, so this may be relegated to the end of the view. R1.5)
+  - Organizes the whole picture into concern-separated derived views (intent view / dependency-block view / progress view), reflecting progress not as a single percentage but along axes of differing nature
+  - Lays out all packets as a single progress rail at the top of the view, annotates each row with the five signals + `[current stage → next stage(s) to pass through]`, so that "which packet is 🔵 you are here now, which stages each will pass through next, and where the ⚪ remaining work / 🔴 unreflected items are" is visible at a glance (only mirroring the five signals and `state` read-only, without computing or inferring state)
+  - Aggregates while keeping canonical intent distinct from inferred intent, and design intent distinct from implementation reality; marks gaps and unobserved areas as "unfilled / unobserved" and never fills them in by guessing
+  - Does not call other skills directly; coordinates only via read-only access to scaffold files (`.intent/*.md`) and guidance in the output text (R6.5). Has no state machine / autonomous loop / resident process, and maintains zero external dependencies (R6.1 / R6.2)
+
+## Execution Steps
+
+### Step 1: Confirm `.intent/` and required artifacts exist (fail-fast)
+- When the user requests generation of an overview view, first confirm that the `.intent/` directory exists.
+- If `.intent/` or a required artifact (at minimum `.intent/intent-tree.md`) is absent, **write nothing**, state the absence explicitly, guide the user to the skill to run first (e.g. `/intent-discover`), and stop (fail-fast. R1.4). Do not create or update `.intent/overview/overview.md` at this point.
+- Read `.intent/mode.md` (do not stop if absent; the enforcement / drift-watch values are referenced in later steps. Read-only — never modify it).
+
+### Step 2: Read sources and aggregate by delegating to the four rules
+- This skill has no analysis / recovery / inspection logic of its own. The exact reading rules for each concern are delegated to the following four rules (referenced by relative path). Follow the exact headings, keys, and column names each rule specifies; keep canonical and inferred distinct; and state gaps and unobserved areas (never fill in by guessing).
+- `rules/aggregate-sources.md` — intent-document aggregation (intent-tree L0–L4 / intent-compass North Star, Anti-direction, Invariants, Decision Rules / packets index & active / plan / export-log / deltas). Separate canonical intent from inferred intent (derived from intent-tree's Assumptions / Open Questions). Code recovery is read-only from the refactor-mode `algo-intent-recovery` output; do no AST / scanner recovery of your own. If recovery output is absent, state the absence and guide the user to that algo (R2.x / R4.x).
+- `rules/mermaid-tree.md` — render intent-tree's L0→L4 as a pure Mermaid `graph`, with the corresponding text hierarchy alongside it as the source of truth. If intent-tree is empty/ungenerated, omit the Mermaid figure and state why (R3.x).
+- `rules/gap-readout.md` — read the drift-log and intent-validate inspection axes **without reimplementing** them, and aggregate them as the "design intent vs implementation reality" gap. Aggregate drift only when `mode.md`'s `## Drift-watch` section is `on` and `drift-log.md` exists; when `off` / unspecified / absent, omit that block and state it as unobserved. Map validate axes to the stable kebab-case ID catalog in `validate-checks.md`. The `## Enforcement` / `## Drift-watch` sections are read-only — never modified (R5.x).
+- `rules/progress-readout.md` — split progress not into a single percentage but into 3 axes (intent stability / realization completeness / evidence certainty), deriving each axis from reading existing artifacts and stating its provenance. Present axis-to-axis divergences as-is without collapsing them. Read packet frontmatter `depends_on` to derive block state read-only (dependencies are only read from declarations, never inferred or computed), and surface cycles / unresolved dependencies. Organize into concern-separated derived views (intent / dependency-block / progress). Omit any axis or view whose source artifact is absent, stating "unobserved / ungenerated" (R8.x / R9.x).
+- Branching policy: branch on whether inferred intent is present and on drift-watch on/off; when absent, omit the relevant block and state its status (never fill in by guessing). For backward compatibility, read an existing packet without `depends_on` as "no dependencies", without `## Evidence` as "unfilled", and the old 3-value state (`draft|active|done`)'s `active` as "in progress (equivalent to implementing)" (follow the rules' specifications).
+
+### Step 3: Write the overview view last (full replacement, derived)
+- Only after all reading and aggregation are complete, **last** write `.intent/overview/overview.md` by **full replacement** (idempotent regeneration. R1.3). Never write to any canonical `.intent/*.md`.
+- The composition order of the content follows "Output Description" (the progress rail = the conclusion at the top, then the concern-separated views, **with the derived / not-the-source-of-truth notice at the END**). Prioritize the human reader's "where am I now / what happens next," and do not fill the start of the view with the derived notice.
+- That this view is derived, regenerable, not the source of truth, and Git-untracked is made explicit in the end-of-view notice (R1.2 / R1.3 / R1.5). That each derived view is derived and regenerable (not the source of truth) is likewise shown in each view's notice (R9.5).
+
+## Output Description
+
+**Reader**: a human developer who wants to read through the whole of `.intent/` (and the AI that reads it downstream).
+**What this output makes them grasp first**: "of all packets, which one is 🔵 you are here now, which stages each will pass through next, and where the 🔴 unreflected / ⚪ remaining work are." Tool-internal notices such as derived / not-the-source-of-truth are not the reader's concern, so **relegate them to the END**.
+
+Compose the head of the view in the following order (the order that gets a human to "where am I / what happens next" by the shortest path).
+
+1. **Progress rail (top, conclusion)**: lay out all packets vertically and annotate each row with the five signals (✅ reflected / 🔵 you are here / ⚪ not started / 🔴 unreflected / ◻ merged), followed by `[current stage → next stage(s) to pass through]` (per `progress-readout.md` "Annotate each row with `[current stage → next stage(s) to pass through]`"). This makes "which P is you-are-here now and which stages remain after this" and "where the unreflected / remaining work are" visible at a glance on a single sheet.
+2. **Concern-separated derived views** (the rail's breakdown):
+   - **Intent view**: the Mermaid figure of intent-tree (L0–L4) + the text hierarchy, intent-compass, and the packet list (with plan / export-log / deltas alongside as context). Canonical and inferred kept distinct.
+   - **Dependency-block view**: dependency relations based on packets' `depends_on` and the resulting block state (with cycles / unresolved dependencies surfaced if any).
+   - **Progress view**: the 3 axes (intent stability / realization completeness / evidence certainty) with each axis's provenance, axis-to-axis divergences, and the design-intent vs implementation-reality gap aggregation (since the progress rail is brought to the top in 1., concentrate here on the breakdown of the 3 axes).
+3. **End-of-view notice**: that this view as a whole and each view is derived / regenerable / Git-untracked and not the source of truth (R1.2 / R1.3 / R1.5 / R9.5). Any view or axis without source material is omitted, with the reason (unobserved / ungenerated) stated.
+
+## Safety & Fallback
+- **Write boundary**: writes are limited to under `.intent/overview/`. The canonical `.intent/*.md` is read-only — never created, modified, or deleted there (the `Write` in the frontmatter is permitted solely for writing under `.intent/overview/`).
+- **Does not call other skills directly**: coordination happens only via read-only access to scaffold files (`.intent/*.md`) and guidance in the output text (R6.5). It holds no decision logic for recovery (`algo-intent-recovery`) / inspection (intent-validate) / drift (drift-watch); it only reads the outputs and definitions they leave behind.
+- **Has no state machine / autonomous loop / resident process** (R6.1). The output view itself serves as a snapshot at read time.
+- **Zero external dependencies** (INV2 / R6.2). Introduces no external package; limited to Node standard and natural-language heuristics.
+- **Does not modify application code** (INV6 / R6.3).
+- **When prerequisites are absent**: when `.intent/` or a required artifact is missing, write nothing, state the absence, guide the user to the skill to run first (e.g. `/intent-discover`), and stop (R1.4).
+- **On partial gaps**: when inferred intent is unfetched / drift-watch is off / intent-tree is empty, omit the relevant block and state "unfetched / unobserved / ungenerated" (never fill in by guessing). When Mermaid cannot be generated, present the text hierarchy as the source of truth, omit the figure, and note the reason.

package/templates/en/claude/skills/intent-overview/rules/aggregate-sources.md

@@ -0,0 +1,61 @@
+# Intent Document Aggregation Procedure (read-only, derived re-generation)
+
+The canonical source for how the `intent-overview` skill aggregates and formats scattered `.intent/` intent artifacts into a single read-through view. SKILL.md holds only the procedure and reporting format; "what to read from which heading/column, and how to order it" refers to this document. This rule is **read-only** and never modifies the canonical `.intent/*.md` (writes go only under `.intent/overview/`). It does not re-implement the recovery / validation / drift decision logic — it only reads the outputs those layers leave behind.
+
+## Aggregation targets and exact references (fixed)
+
+The headings and column names of each artifact are fixed in the table below (if they change, this rule must follow — i.e. a Revalidation Trigger). Canonical descriptions and inferred (guessed) descriptions are presented separately and never mixed.
+
+| Source | File to read | Exact heading/column (fixed) | Handling in the view |
+|---|---|---|---|
+| Intent tree | `.intent/intent-tree.md` | `## L0`–`## L4` (hierarchy body) + `## Assumptions` (+ `## Open Questions` if present) | Format L0–L4 as canonical. Assumptions / Open Questions go in a separate frame as inferred |
+| Compass | `.intent/intent-compass.md` | `## North Star` / `## Anti-direction` / `## Invariants` / `## Decision Rules` | Format the 4 sections as-is into a read-through |
+| Packet index | `.intent/packets/index.md` | columns `packet_id \| name \| state \| summary` | Aggregate the index table. Show each packet's state alongside |
+| Packet body | `.intent/packets/active/*.md` | frontmatter 10 keys (including `depends_on`) + body `## Evidence` section | Read frontmatter and Evidence, tie them to the progress / dependency / evidence context |
+| Plan | `.intent/packets/plan.md` | `## Walking Skeleton` / `## Recommended First Packet` / `## Deferred` | Present as the "next-step context" of the packet aggregation |
+| Export history | split form `.intent/export-log/*.md` (source of truth if present; `exported_at` ascending) / else old `.intent/export-log.md` (generated mirror) | columns `packet \| exported_at \| commit` | Present as an export history timeline (readable even when split) |
+| Learnings (deltas) | split form `.intent/deltas/*.md` (if present) + old `.intent/deltas.md` (when coexisting) | `Status` + learning tags | Tie to the packet aggregation as pending learnings (readable even when split) |
+
+## Showing active side / archive split (two layers of the reading view; derived, machine-generated)
+
+The append-only records (deltas / export-log / drift-log / milestones / compass-archive) are divided by the split into an **active side (the thin current projection) and archive (history)**. The overview reading view presents these two layers **shown split** (the derived machine generation of INV25-(1) / DR33; it creates no new canonical file and modifies no source of truth, read-only).
+
+| Layer | What to read | Treatment in the reading view |
+|---|---|---|
+| **Active side** | directly under each record's split dir `.intent/<rec>/*.md` (source of truth if present; natural-key ascending) / else old `.intent/<rec>.md` (generated mirror) | Present thinly as the "current" section (the current projection). When the split form and the old mirror coexist, treat the split form as the source of truth and do not double-count the mirror |
+| **Archive (history)** | files under each record's `.intent/<rec>/archive/` (e.g. `deltas/archive/<year>/`; compass-archive is per-rule) | Present as a "history" section in a **separate frame** from the active side. Do not mix it into the active tally (pending learnings, latest export, etc.) |
+
+- The split view is a **derived machine generation**; it does not add a new canonical file (writes go only under `.intent/overview/`; the source of truth is read-only). In environments where `archive/` is absent, omit the "history" section (do not error).
+- In environments with only the old single-file format (split / archive not yet deployed), read the active side from the old mirror and omit the "history" section with a note that history is delegated to git history (backward compatible; do not fill in by guessing).
+
+## Packet frontmatter and state value domain (fixed)
+
+- Frontmatter has **10 keys** (including `depends_on`). `depends_on` is a set of packet_ids (dependencies).
+- `state` is one of **5 values**: `draft | ready | implementing | verifying | done`.
+- The packet body's `## Evidence` section contains verification results and check-axis IDs (kebab-case).
+
+## Backward compatibility (reading the legacy schema)
+
+Read backward-compatibly even in environments where the new schema (10 keys, 5 values) is not yet deployed. Do not fill in missing parts by guessing.
+
+| Observed state | How to read it |
+|---|---|
+| `depends_on` is absent | Read as "no dependencies (empty set)" |
+| `## Evidence` section is absent | Read as "not filled in" |
+| Legacy 3-value state (`draft \| active \| done`) remains | Read `active` as "in progress (≈implementing)". `draft` / `done` stay as-is |
+
+## Handling of inferred (reverse-inference) — delegated, read-only
+
+- This rule does **not** independently perform intent reverse-inference from code. No AST traversal, no static analysis, no external scanner (INV2 / R4.4).
+- It **reads** the inferred intent that refactor-mode `algo-intent-recovery` left in the intent-tree (originating from `## Assumptions` / `## Open Questions`), marks it explicitly as inferred, and presents it separated from the canonical L0–L4 body (R4.1 / R4.3 / R2.4).
+- **When reverse-inference has not been obtained** (refactor-mode discover not run, and no inferred in `## Assumptions`): state that absence explicitly and guide the user to run refactor-mode discover including `algo-intent-recovery`. Do not fill in by guessing (R4.2).
+
+## Handling of missing / blank artifacts
+
+- When an aggregation-target artifact is blank or partial, mark the relevant part explicitly as **"not filled in"**. Do not fill in by guessing (R2.5).
+- When a source file itself is absent, state that absence explicitly and guide the user to the skill that should be run first (do not write).
+
+## Output discipline
+
+- Place canonical intent (tree L0–L4 / compass 4 sections / packets / plan / export-log / deltas) and inferred intent (from recovery) side by side, **kept distinct**.
+- State that the generated view is **derived / re-generatable** and not the canonical source. Never write back to the canonical.

package/templates/en/claude/skills/intent-overview/rules/gap-readout.md

@@ -0,0 +1,54 @@
+# Gap Aggregation: Design Intent vs Implementation Reality
+
+The source of truth by which the `intent-overview` skill assembles the "design intent vs implementation reality" gap section. SKILL.md holds only the procedure and report format; what to read, under which conditions, and how is governed by this file. This layer only **reads, never re-implements** the check axes of drift-watch / intent-validate, and holds no judgment logic of its own. All observation is limited to Read / Glob / Grep, and never modifies the canonical artifacts (mode.md / drift-log.md / validate-checks.md).
+
+## Invariant discipline (read-only cross-cutting layer)
+
+- This layer only **reads** the outputs and definitions of drift-watch / intent-validate; it does not run detection or checks itself (Out of Boundary).
+- The `## Enforcement（ユーザー管理）` / `## Drift-watch（ユーザー管理）` sections of `mode.md` are **read-only** and never modified (same discipline as intent-status).
+- Absent or not-observed blocks are not filled in by guessing; their state (not observed / not obtained) is stated explicitly and the block is omitted.
+
+## Conditional read of drift-log (R5.1 / R5.4)
+
+drift-log is read only when **both conditions hold simultaneously**.
+
+1. The `## Drift-watch（ユーザー管理）` section of `mode.md` is `on`.
+2. `.intent/drift-log.md` exists.
+
+Only when both conditions hold, read drift-log with Read / Grep, aggregate the detection entries, and present them in the gap section. If any of the cases applies — `off` / unset / drift-log absent — **omit** the gap-aggregation block and state its status explicitly as "not observed (drift-watch is off, or no drift-log)". The default for drift-watch is `off`; not-observed is treated not as a defect but as the initial state.
+
+### Fixed schema of drift-log (9 keys, fixed order)
+
+Each entry holds the following 9 keys as a fixed-order Markdown list (matching the drift-log.md source of truth). This layer only reads on the premise of this key set and order, and does not alter the format.
+
+```
+pattern → stage → packet → mechanism → outcome → user-verdict → recorded_at → commit → note
+```
+
+- `packet` is the **3rd** canonical key (after `stage`, before `mechanism`).
+- Aggregation is performed from the two columns `outcome` and `user-verdict`.
+  - `outcome`: one of the 5 values `prevented` / `caught` / `missed` / `false-positive` / `not-applicable`.
+  - `user-verdict`: one of the 3 values `valid` / `false-alarm` / `unjudged`.
+- The presentation is at minimum a `pattern × outcome` cross-tabulation (matching the operating notes of drift-log.md), with `user-verdict` (the user's confirmation) shown alongside. `outcome` is the draft made by drift-watch and `user-verdict` is the user's confirmation; the two are not conflated in presentation.
+
+### How to read missed=0 (avoiding confirmation bias)
+
+Do not assert `missed=0` (zero records of "got through without being prevented") as "evidence it worked". Present it as a **"suspected recording gap"** (following the precedent of intent-status and the opening note of drift-log.md). Having only the moments it worked (`prevented` / `caught`) remain is confirmation bias; read on the premise that the moments it did not work (`missed` / `false-positive` / `not-applicable`) are recorded just as evenly.
+
+## Mapping of intent-validate check axes (R5.2 / R5.3)
+
+intent-validate is a read-only skill with `allowed-tools: Read, Glob, Grep` and **writes no check results to a persistent file**. Therefore this layer does not read a "validate result file"; instead it reads the **check-axis ID catalog** in `intent-validate/rules/validate-checks.md`, and organizes the overview's gap observations within that ID system.
+
+- Reference: the check catalog table of `intent-validate/rules/validate-checks.md` (the `ID` column = stable kebab-case IDs, the `深刻度の目安` (severity) column = severity classification). Additions and changes to checks are governed by that table; this layer cites the ID column as-is (does not re-derive).
+- Severity classification uses the 3 classes of `validate-checks.md` (`要修正` / `推奨` / `情報`) as-is.
+- The dependency-soundness check axes `dependency-cycle` (a cycle A→…→A in `depends_on`) and `dependency-broken-ref` (a reference to a non-existent packet_id) actually exist in this catalog, and both are `要修正`-grade. When a cycle or unresolved dependency is observed in the dependency/block view (progress-readout), present it tied to the corresponding stable ID.
+- The check logic itself is **not re-implemented** (R5.2). This layer borrows the vessel that is the ID system and merely distributes the gap observations seen in the overview into that vessel.
+- Where check results are referenceable, present them tied to a stable kebab-case ID. Where not referenceable (validate not run, or results not left in an artifact), **omit** the tie to an ID and state the absence explicitly (absorbing R5.3's "where referenceable"-conditional requirement by omission when not referenceable).
+
+## Composition of the output block
+
+The gap section is composed of the following elements (omit elements that have no material and state the reason).
+
+1. **drift aggregation** (only when both conditions hold): a `pattern × outcome` cross-tabulation with `user-verdict` alongside. `missed=0` is annotated as a "suspected recording gap".
+2. **Check-axis mapping**: organize the gap observations seen in the overview within the stable kebab-case ID system of `validate-checks.md`. Tie referenceable ones to an ID; omit and state absence for those that are not.
+3. **mode status**: show the current values of `## Enforcement` / `## Drift-watch` read-only alongside (never modified).

package/templates/en/claude/skills/intent-overview/rules/mermaid-tree.md

@@ -0,0 +1,78 @@
+# Mermaid visualization rule for the intent-tree
+
+Canonical reference for how the `intent-overview` skill renders the L0→L4 hierarchy of `intent-tree.md` as a diagram. SKILL.md holds only the procedure and report format; the Mermaid generation method, escaping conventions, and the text-alongside discipline defer to this rule. The output of this rule is confined to the derived views under `.intent/overview/`; it never writes to canonical sources (`.intent/*.md`, including `intent-tree.md`) — read-only. Judgment is limited to natural-language heuristics and reading existing artifacts; it does not depend on an AST, external scanners, or external renderers (INV2).
+
+## Render target and pure-Mermaid principle (R3.1)
+
+- The render target is the items under each of the `## L0:`–`## L4:` headings in `intent-tree.md`. Output a tree — L0 at the top (apex), L4 (packet candidates = P) at the bottom (leaves) — as pure, self-authored Mermaid `graph` text.
+- The default direction is `graph TD` (Top-Down), because a top-to-bottom hierarchy reads most clearly.
+- The output is only Mermaid syntax wrapped in a ` ```mermaid ` … ` ``` ` code fence. Do not use external plugins, custom notations, image generation, theme extensions, or external renderers (INV2 = zero dependencies; diagram correctness is not made to depend on a renderer implementation — it is guaranteed by the text written alongside).
+- Edges must **always** point "from the higher L level to the lower L level" (`L<n> --> L<n+1>`), connected with `-->`. Do not draw reverse (lower→higher) edges. In `graph TD`, rank (vertical position) is determined by edge direction, so a wrong direction makes L4 (P) float upward or L1/L2 sink downward — the layout breaks. **Always guarantee, via edge direction, that L0 is the top rank and L4 is the bottom rank.**
+
+## Preventing rank breakage (do not create orphan nodes) (R3.1)
+
+In `graph TD`, a node with zero incoming edges (an orphan) becomes a ranking root and **floats to the top rank**. The result is breakage like "L1/L2 mixed below while P (L4) ends up on top." To prevent this, **every node except L0 must carry at least one parent edge and must not be left orphaned**.
+
+- **Item whose parent is unambiguous**: connect from the matching parent node at the immediately higher level with `parent --> child`.
+- **Item whose parent is not unambiguous (do not connect to a specific parent by guessing)**: do not orphan it — connect it to an **anchor for the entire immediately-higher level**. Specifically, for each level `L<n>` (n≥1), when the items at the higher level `L<n-1>` are multiple and the parent cannot be uniquely determined, define one **level-anchor node** `L<n-1>_anchor` (e.g. label `["L<n-1> (multiple parent candidates)"]`) that gathers the `L<n-1>` items, connect each real `L<n-1>` node to `L<n-1>_anchor`, and then `L<n-1>_anchor --> child`. This places a child with an ambiguous parent correctly below `L<n-1>` in vertical rank so it does not float up. Note in the text hierarchy that an anchor was used (i.e., the parent was not unique), while preserving the rule of not asserting a specific parent by guessing.
+- **Item that cannot have a parent because the higher level is empty** (e.g. L2 exists but L1 is blank): do not orphan it — connect it directly to the **nearest existing higher level** (L0 in this example) and note in the text hierarchy that an intervening level is blank. Even with an empty intermediate level, the lower level must not float up.
+- In every case, **edge direction is always higher→lower**, preserving the vertical order with L0 at the top rank and L4 (P) at the bottom rank.
+
+## Node-ID convention (collision avoidance)
+
+A node ID is the identifier the renderer interprets, kept separate from the label (the displayed string). IDs are derived mechanically and stably and are not generated from the label text.
+
+- **Allowed characters**: ASCII alphanumerics and the underscore `_` only. The first character must be a letter. Do not include non-ASCII text, symbols, or spaces in an ID.
+- **Derivation rule**: derive the ID mechanically as `L<level number>_<0-based occurrence index within the same level>`. Examples: the sole L0 item is `L0_0`; the first L2 item is `L2_0`; the second L2 item is `L2_1`.
+- **Collision avoidance**: because (level, within-level index) is unique, the ID is also unique. Since it does not depend on the label string, IDs never collide even when items share the same name, are empty, or contain special characters. When the same item has multiple parents (is shared), define the node only once under its first-occurrence ID, and thereafter reuse that ID to add edges only (do not redefine the node).
+
+## Label convention (escaping / stripping special characters)
+
+Labels are wrapped in the square-bracket-plus-double-quote form `ID["..."]`. The label body must not contain characters that break Mermaid syntax.
+
+- **Forbidden characters**: the label body must not contain `(` `)` `[` `]` `"` `/`. Strip these mechanically from the item text (delete the character and close up the surrounding text). Because stripping can change meaning, when a node has been stripped, note that in the text hierarchy described below (the text hierarchy preserves the original text and is never stripped).
+- **Newlines and pipes**: collapse newlines into a single space within the label. Strip `|` (pipe) from the label.
+- **Length**: for diagram readability, when a label exceeds roughly 40 characters, truncate to the first 40 characters and append `…` (even when truncated, the text hierarchy preserves the full text).
+- For an item whose label body is empty (the item is blank), use `["(blank)"]`-free form, i.e. `["blank"]` (containing no forbidden characters), and state it as "blank" in the text hierarchy (do not fill in by guessing).
+
+## Always write the text hierarchy alongside as canonical (R3.2)
+
+- **Always** write the corresponding text hierarchy (an indented bullet list) immediately after the Mermaid diagram. This keeps read-through unblocked even in environments where the diagram fails to render; the text hierarchy is the basis for reading in the overview view (the source of truth within this view).
+- The text hierarchy preserves the original text of `intent-tree.md`. Escaping, stripping, and truncation performed for labels are not applied to the text hierarchy; record it verbatim (when stripping or truncation was performed for a label, the corresponding text line may be annotated).
+- State in the view that this block is derived and is regenerable from `intent-tree.md` as the source of truth (it updates on re-run, not by hand-editing).
+
+## When the intent-tree is empty / not yet generated (R3.3)
+
+- When `intent-tree.md` does not exist, or none of `## L0:`–`## L4:` contains any item (all levels blank), **do not output the Mermaid diagram**.
+- State the reason for omitting the diagram explicitly ("nothing to visualize because the intent-tree is empty / not yet generated") and direct the user to the skill to run first (`/intent-discover`). Do not generate nodes by guessing.
+- When only some levels are blank, do not omit the diagram; represent blank levels with a "blank" label plus an explicit note in the text hierarchy.
+
+## Example (a small L0→L2 tree)
+
+Suppose `intent-tree.md` reads as follows (one L0 item, one L1 item, two L2 items, where the second L2 item contains the forbidden characters `(` `)`):
+
+- L0: Make scattered intent readable in one pass
+- L1: Keep the conversation going while holding the whole picture
+- L2: Aggregate intent documents / L2: Mermaid visualization (diagram and table)
+
+The Mermaid block produced is (L0 is the apex; every edge points higher→lower; both L2 items connect under L1 so nothing is orphaned):
+
+```mermaid
+graph TD
+  L0_0["Make scattered intent readable in one pass"]
+  L1_0["Keep the conversation going while holding the whole picture"]
+  L2_0["Aggregate intent documents"]
+  L2_1["Mermaid visualization diagram and table"]
+  L0_0 --> L1_0
+  L1_0 --> L2_0
+  L1_0 --> L2_1
+```
+
+The text hierarchy written alongside (canonical; preserves the original text, label stripping not applied):
+
+- L0: Make scattered intent readable in one pass
+  - L1: Keep the conversation going while holding the whole picture
+    - L2: Aggregate intent documents
+    - L2: Mermaid visualization (diagram and table)  ← `()` stripped in the diagram label
+
+> This block is derived. The source of truth is `intent-tree.md`, and it is regenerated by re-running `/intent-overview`. Do not edit it by hand.

package/templates/en/claude/skills/intent-overview/rules/progress-readout.md

@@ -0,0 +1,119 @@
+# Multi-axis progress readout and concern-separated views
+
+The canonical source the `intent-overview` skill uses to mirror packet progress on three axes instead of a single %, to derive block state read-only from `depends_on`, and to organize concern-separated derived views. This rule is **read-only**: it does **not compute, score, or infer** progress axes or dependencies. The canonical source of progress, dependency, and evidence is the packet (frontmatter + `## Evidence` section) that `intent-planner-packet-progress` maintains, and overview only **mirrors** it. Checks that require computation (dependency health, validate axes) are the responsibility of intent-validate / drift-watch / algo-intent-recovery; this rule only **reads their results**.
+
+## Core principle (read-only mirror)
+
+- The packet canonical source (the 10-key frontmatter of `active/*.md` + the body `## Evidence` section) is the **single source of truth** for progress, dependency, and evidence. Overview only regenerates derived views from it; it does not modify the canonical source and does not duplicate it.
+- Do **not compress progress into a single overall %**. Present it split across three axes of differing natures.
+- For each axis and each view, state the source explicitly ("which part of which existing artifact was read"). Show that it is based on reading files, not on AI self-report.
+- For any axis or view with no corresponding artifact, state "not observed / not filled in / no dependencies" explicitly and **never fill the gap by guessing**.
+
+## Progress rail (read-only mirror)
+
+**Before** the three progress axes (the qualitative breakdown), lay out all packets as a single vertical rail so the reader can see at a glance "which stage each packet is in." The rail is not an overall indicator that compresses the three axes; it is the **bird's-eye view that sits in front of** the three axes (grasp the overall position from the rail, then read each packet's breakdown via the three axes — a complementary relationship). The rail is also a read-only mirror: it does **not compute, infer, or score** state. It reads existing artifacts (packet frontmatter `state` / `superseded_by`, `export-log.md`, `deltas.md`) and only **mechanically determines and mirrors** which of the five signals below applies.
+
+### The five signals and their determination (all mechanically observable from `.intent/`)
+
+Cross-check each packet by `state` × whether export-log has a row × whether deltas has a corresponding entry, and assign exactly one signal — **evaluating top-down and taking the first that matches** (first-match).
+
+| Signal | Meaning | Determination | Source |
+|--------|---------|---------------|--------|
+| ◻ merged | merged into a successor packet and done with its role | `superseded_by` is non-empty | packet frontmatter |
+| ✅ reflected | implementation complete and written back into intent | `state: done` **and** deltas has a promoted/closed entry for this packet | packet + deltas.md |
+| 🔵 you are here | the one stage currently being worked on (exported, not yet reflected) | of the rows with an export-log row and no corresponding deltas entry, the one that **matches the current Source Packet (the latest export-log row)** | latest export-log row + deltas.md |
+| 🔴 unreflected | evidence of implementation exists but not yet reflected into intent (a leftover) | of the rows with an export-log row and no corresponding deltas entry, those other than the current Source Packet | export-log + deltas.md |
+| ⚪ not started | not yet exported to cc-sdd | export-log has no row for this packet (active but not exported) | export-log + packets/active |
+
+- **Both 🔵 and 🔴 are "exported, not yet reflected."** The only difference is whether it is "the one currently being worked on (latest row = 🔵)" or "a leftover from the past (anything else = 🔴)". This visually separates the one stage in progress from the N items buried by writeback omission. 🔴 does not add a new separate warning block; it **surfaces as a mismatch on the rail (implementation advanced but reflection lags)**. This is a concretization of "Present axis mismatches as-is" below, not the addition of a new check.
+
+### Annotate each row with `[current stage → next stage(s) to pass through]` (pipeline projection)
+
+The five signals mirror the **reflection progress** (whether it has been exported / whether it has been written back), but that alone does not let the reader see "**which stage of intent-building → implementation → writeback this packet is currently in, and which stages remain after this**". So, following the signal, **annotate each packet row with `[current stage → next stage(s) to pass through]`**. This is not a new observation or computation; it merely **re-reads** the packet frontmatter `state` (the declared value already read on axis 2 of "the three progress axes") **as a position on the fixed pipeline below, and mirrors it** (preserving the read-only mirror discipline of no inference / no scoring).
+
+- **Fixed pipeline (the forward order of stages)**: `discover → compass → packets → export → implement (cc-sdd) → verify → writeback`. This is the same ordering as intent-planner's standard flow (the command order in footnote 5 of status's decision table `decision-table.md`), and is taken as the reference for stage ordering. Read the correspondence between each command stage and packet `state` as follows.
+  - `state: draft` = being drafted → **next stages: compass → packets** (the stage that works out the intent and decision criteria)
+  - `state: ready` = ready to start (dependencies resolved, awaiting implementation) → **next stages: export → implement**
+  - `state: implementing` = under implementation → **next stages: verify → writeback**
+  - `state: verifying` = implemented, awaiting verification (Evidence not yet confirmed) → **next stage: writeback** (after Evidence is confirmed)
+  - `state: done` = complete → **next stage: none (this lane is complete)**
+- **Write the "current stage" as a composite of the five signals and `state`.** Examples: when the signal is 🔵 you are here with `state: implementing`, write `🔵 you are here [implementing → next: verify→writeback]`; ⚪ not started with `state: ready`, write `⚪ not started [ready → next: export→implement]`; ⚪ not started with `state: draft`, write `⚪ not started [draft → next: compass→packets]`. This makes "which P is being worked on, and which stages remain after this" readable on one line.
+- **The next stage is a projection from the pipeline definition, not an inference.** It merely **maps `state` onto the next fixed stage and mirrors it**; it does not predict duration, difficulty, or success/failure. For a packet blocked because `depends_on` has an undone dependency, annotate `(blocked, waiting on <packet_id>)` before the next-stage note (block determination follows the read-only derivation of the "Dependency-block view"; do not infer or compute).
+- **Backward compatibility**: read the legacy 3-value `state: active` as equivalent to `implementing`, i.e. `[active(=implementing) → next: verify→writeback]`. For a packet whose `state` itself cannot be observed, do not assert the stage annotation; state `[stage: not observed]` explicitly (do not fill by guessing).
+- **Do not invent a new matching rule for the deltas correspondence.** Reuse the existing canonical discipline ("current Source Packet = latest export-log row," "text matching by packet name," "the mechanical determination of whether a corresponding delta exists is valid only for the first cycle") from aggregate-sources / the deltas.md operating notes as-is. For the second cycle onward (after re-export / re-implementation), do not determine reflection need mechanically; state "user judgment" explicitly.
+- **Bird's-eye view of remaining work**: the ⚪ rows directly represent "the remaining work to start next," and each row's `[current stage → next stage(s) to pass through]` annotation makes "which stages that packet will pass through next" visible at a glance as well. The rail's purpose is to show remaining work and unreflected items at a glance on a single sheet; a packet blocked by a dependency may be annotated on its rail row following the "Dependency-block view" derivation below (do not infer or compute dependencies).
+- **Backward compatibility**: treat legacy 3-value `state: active` as "in progress" and determine 🔵/🔴/⚪ by whether export-log has a row. Absent `superseded_by` = "not merged." Absent deltas = "not reflected." For a packet where `state` itself cannot be observed, do not assert a signal; state "not observed" (do not fill by guessing).
+- **Declare derived**: the rail is also derived / regenerable and is not the source of truth. The source of truth is the packet frontmatter, export-log, and deltas; the rail is a snapshot at read time.
+
+## The three progress axes (not a single %)
+
+Present progress split across the following three axes. Each axis is **derived** from reading existing artifacts (not computed, not scored). Always annotate each axis with its source (where in which artifact it was derived from).
+
+### Axis 1: Intent stability
+
+An axis that qualitatively mirrors "how settled the upstream intent is".
+
+- **Source**: `intent-tree.md` (unfilled spots in L0–L4, `## Open Questions`, `## Assumptions`), `intent-compass.md` (unfilled North Star / Anti-direction / Invariants / Decision Rules).
+- **How to read**: Show, **qualitatively**, the unfilled L levels and empty headings, the count of remaining items under `## Open Questions`, and the ratio of `## Assumptions` (inferred = derived by inference) to the canonical settled descriptions. Do not turn the ratio into a strict numeric score (read-only mirror discipline; no quantitative scoring).
+- Keep inferred (originating from `## Assumptions` / `## Open Questions`) and canonical (the settled descriptions in L0–L4) **unmixed**, preserving the distinction even in the stability assessment.
+- If the source material (tree/compass) is absent, state "not observed" explicitly.
+
+### Axis 2: Realization completeness
+
+An axis that mirrors "how far it has been built (the current position of development)".
+
+- **Source**: the `state` in packet frontmatter.
+- **Value set (5 values)**: `draft | ready | implementing | verifying | done`. The values are mutually exclusive; a packet takes exactly one stage.
+  - `draft` = being drafted / unsettled; `ready` = ready to start (dependencies resolved, awaiting implementation); `implementing` = under implementation; `verifying` = implemented, awaiting verification (Evidence not yet confirmed); `done` = evidence obtained, complete.
+- **Backward compatibility**: For packets that still carry the legacy 3 values (`draft | active | done`), read `active` as "in progress (equivalent to `implementing`)". For an existing packet where the `state` key itself cannot be observed, set "realization completeness: not observed" and do not fill by guessing.
+- `state` is a **declarative record**; overview does not judge or advance transitions (it holds no state machine). Mirror the read value as-is.
+
+### Axis 3: Evidence certainty
+
+An axis that mirrors "how strongly the implementation result is backed by verification".
+
+- **Source**: the presence and certainty of the body `## Evidence` section, the `intent-validate` check axes (the stable kebab-case IDs in `validate-checks.md`), and the cross-check against `drift-log.md` (when drift-watch is `on` and it exists).
+- **How to read**: Read whether `## Evidence` holds confirmed verification results (date performed, the corresponding check axis ID, the source = intent-validate / drift-watch / human confirmation). Organize the check axis IDs that each Evidence entry references against the ID system of `validate-checks.md`.
+- **Reading the check axes**: Because intent-validate does not write its results to a persistent file, read the **check axis ID catalog** in `validate-checks.md` (the stable kebab-case IDs and their severity classification) and organize the evidence perspective using that ID system. Do **not reimplement** the check logic.
+- **Backward compatibility**: For an existing packet with no `## Evidence` section, draw "evidence certainty: not filled in", and do not fill the gap by guessing.
+- When evidence cannot be read because validate has not run, Evidence is absent, or drift-log is absent, state "not observed" explicitly.
+
+## Present axis mismatches as-is, without flattening
+
+Because the three axes differ in nature, their per-axis values can diverge. **Do not flatten that divergence into a single indicator; surface it as a mismatch.** Annotate the sources so it can be traced to the difference between which artifacts gave rise to the mismatch.
+
+- Example: "`verifying` but Evidence not yet confirmed" — realization completeness (axis 2) has advanced but evidence certainty (axis 3) is not yet confirmed.
+- Example: "`done` but a trace hole vs an upper invariant" — evidence certainty (axis 3) is in place but there is a gap vs intent stability (axis 1).
+
+By specification, the `verifying` stage represents the state "realization advanced but evidence not yet confirmed". Therefore, for a `verifying` packet, overview **mirrors the gap as-is** between realization completeness (axis 2) and evidence certainty (axis 3) (it does not round one to match the other).
+
+## Dependency-block view (read-only derivation)
+
+Present inter-packet dependency and block state **by reading the declaration only**.
+
+- **Source**: the `depends_on` in packet frontmatter (a set of the `packet_id`s of dependency packets; default `[]`).
+- **Block derivation (read-only)**: Display a packet as **BLOCKED** when "there is a packet in `depends_on` whose `state` is not `done`". Do **not infer or compute** dependencies. Derive it solely by reading the declared `depends_on`, and do not write it back to the packet (consistent with packet-progress R3.3 / R3.5).
+- **Stating cycles / unresolved dependencies**: If there is a cycle (A→…→A) or a broken dependency referencing a nonexistent `packet_id`, state it explicitly.
+  - If the intent-validate `dependency-cycle` / `dependency-broken-ref` check results are available, present it tied to them (do not reimplement the check logic).
+  - Only when the check results are unavailable, a naive read-time detection (a simple traversal of the declared `depends_on` set) may be noted at **caveat level**. State clearly that this is a read-time aid, not a substitute for the check.
+- **Backward compatibility**: For an existing packet with no `depends_on` key, draw "no dependencies (equivalent to the empty set)", and do not fill dependencies by guessing.
+
+## Concern-separated derived views (view-based presentation)
+
+Do not mix the whole picture into a single long document; organize it into concern-separated derived views. At minimum, compose the following three views.
+
+- **Intent view**: derived from aggregate-sources (the aggregation of tree / compass / packets / plan / export-log / deltas). Present canonical and inferred kept distinct.
+- **Dependency-block view**: the "Dependency-block view" above. `depends_on` and the block state based on it, plus cycles / unresolved dependencies.
+- **Progress view**: the "three progress axes" above. The three axes and the mismatches among them.
+
+For each view, observe the following.
+
+- **Regenerate from the single source of truth**: Regenerate each view from the canonical `.intent/*.md`, and do not duplicate the source of truth across views. Do not hold the same information redundantly in multiple views (each view is a projection of the canonical source).
+- **Omit views with no source material**: If the source material for a derived view is absent, **omit that view and state the reason (not observed / not generated / no dependencies)**. Do not fill an empty view by guessing.
+- **Declare derived**: For each view, declare that "this is derived / regenerable and is not the source of truth". The source of truth is the original `.intent/*.md`, and the view is a snapshot at read time.
+
+## Backward-compatibility summary
+
+- `depends_on` absent → draw the dependency-block view as "no dependencies" (do not fill the gap by guessing).
+- `## Evidence` absent → draw evidence certainty (axis 3) as "not filled in" (do not fill the gap by guessing).
+- Legacy 3-value `state` (`active`) → read it as "in progress", equivalent to `implementing`. For a packet where `state` itself cannot be observed, set realization completeness to "not observed".