intent-planner 0.13.1

package/templates/en/codex/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/codex/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/codex/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/codex/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".

package/templates/en/codex/skills/intent-packets/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: intent-packets
+description: From the Intent Tree and Intent Compass, build the Packet Plan before handing off to cc-sdd. Each packet has a parent intent and is behavior-preserving / testable / rollbackable. Does not implement.
+---
+
+# intent-packets Skill
+
+## Core Mission
+- **Success Criteria**:
+  - There are as many packet candidates as the expected change size warrants (do not pad the count; one packet is fine for very small changes; treat 1–7 as a loose guide), and each packet references a parent intent
+  - Each packet is drafted as an individual file under `.intent/packets/active/` (1 packet = 1 file)
+  - Each packet has Scope / Non-scope / Expected Behavior / Decisions / Safety(Invariants) / Validation / Evidence / Rollback / cc-sdd Mapping (keep `Evidence` as an empty section when there is no result)
+  - In each packet's `## Decisions` section, the common-core slots from `decision-slots.md` (plus the mode-specific diffs) are each closed with one of the 4 statuses (answered / undetermined / not-applicable / ADR candidate) (do not fill in defaults; do not silently skip)
+  - Each packet is at a behavior-preserving / testable / rollbackable granularity
+  - No existing packet file has been destroyed (changes are presented as differential update proposals)
+  - No application code has been changed at all
+
+## Execution Steps
+
+### Step 1: Read the prerequisites
+- Read `.intent/intent-tree.md` and `.intent/intent-compass.md`. If either is missing, guide the user to "run the corresponding command first" and stop.
+- While reading, when you see an unsettled verb slipped into the settled phrasing of the compass / intent-tree (assume / reuse / planned / TBD / tentative, etc.), do not fix it by guessing; present it as a conversion proposal into Open Questions or an undetermined slot (with the reason and the revisit condition (Revisit when)). Promotion to a fixed value is left to the user's confirmation. Do not re-convert spots already recorded in Open Questions / Deferred / an undetermined slot.
+- Read `.intent/mode.local.md` (falling back to `.intent/mode.md` if absent) for the mode state. If both are absent, default to standard and announce it in Open Questions (do not stop).
+- Read `.intent/packets/index.md` and the existing packet files under `.intent/packets/active/` (the basis for differential updates).
+- Legacy-install handling: if `.intent/packets/`, `plan.md`, `index.md`, or `README.md` is missing, the skill creates them itself before proceeding (do not wait for a scaffold reinstall).
+- After-the-fact drafting (when implementation ran ahead): when the invocation context or the user's report makes clear that **implementation proceeded / completed without a corresponding Packet**, treat it with the same procedure as normal drafting (raise the Packet even after the fact; being already implemented is not a reason to skip drafting). In this case:
+  - Record the established facts (the wiring / behavior already implemented) as `what + constraints + oracle` in the packet file.
+  - For the **spec that cannot yet be fixed** (the trigger, threshold, judgment means, etc. — decisions not yet committed to, or placed provisionally), do not fill them by guessing; put them explicitly into the container as Open Questions and Deferred (`undecided (deferred, with a revisit condition)`, always with the revisit condition). "Not drafting a Packet because the spec cannot be fixed" is wrong — holding the unfixed as-is is exactly the Packet's role.
+  - Guide the order: **first raise the Packet with this skill (the drafting phase), then return the learnings gained from the implementation reality to canonical via a delta with `/intent-writeback` (the post-implementation phase)**. These two run in opposite directions; do not perform only writeback while skipping the Packet drafting (the phase boundary follows writeback-protocol.md §3).
+
+### Step 2: Apply the mode definition's algorithm
+- Open the mode definition that `.intent/mode.local.md` (falling back to `.intent/mode.md`) `definition` points to, and read and apply the algo rule (`rules/algo-*.md`) assigned to the Packet decomposition phase (standard → `rules/algo-example-mapping.md`; refactor → `rules/algo-migration-slicing.md`; behavior-unknown → `rules/algo-example-mapping.md` + `rules/algo-characterization-test.md`). The examples are not exhaustive; the mode definition's table is always authoritative.
+
+### Step 3: Decompose into Packets
+- Following Example Mapping, expand each L2/L3 capability into "rules, examples, questions, deferred".
+- Derive Expected Behavior, Validation, and Rollback from the examples.
+- Consolidate into as many packets as the expected change size warrants (do not target a count or pad it; one packet is fine for very small changes; treat 1–7 as a loose guide). Measure size qualitatively by "the number of concerns touched × the breadth of impact on existing boundaries"; do not bring in effort estimates or other numeric metrics. Always give each packet a parent intent (a reference to L0/L1/L2/L3).
+- Draft each packet as an individual file at `.intent/packets/active/<packet_id>.md`. Read `rules/packet-format.md` and follow it for ID assignment, filling in the frontmatter keys, and the body section structure (including the `## Decisions` and `## Evidence` sections) — the canonical source is the single source of truth for the key set and value domains.
+- Stamp `updated_at` (the writer's responsibility): after writing a packet file, record its update timestamp in the frontmatter `updated_at` (ISO 8601). On a new packet, set `updated_at` to the same timestamp as `created_at`; when you change the content of an existing packet, update `updated_at` to that moment. On a re-run that involves no content change, do not change `updated_at` (idempotent; do not stamp when nothing changed). Obtain the timestamp with the shell `date`, the same way as `created_at`. If you cannot obtain the date/time, do not write a guessed date — report that instead. Stamping is the writer's (this skill's) responsibility and is not given to the read-only verification layer (intent-validate).
+- Read `rules/decision-slots.md` and seed the completeness-schema slots into each packet's `## Decisions` section (the canonical source for the slot definitions, value domains, and IDs is decision-slots.md; this section is its projection).
+  - Seed the common-core slots (the 8 IDs seeded in every mode) into every packet, and add the mode-specific diff slots according to `.intent/mode.local.md` (falling back to `.intent/mode.md`) mode (standard / refactor / behavior-unknown / feature-growth). The slot definitions are authoritative in the decision-slots.md table; do not hardcode them into the SKILL body.
+  - Close each slot with **exactly one** of the 4 statuses (answered / undetermined / not-applicable / send to ADR candidate) (structurally preventing "silently skipping"). Do not fill in a "reasonable default" or "recommended value" (anchoring avoidance). Do not infer or auto-fill a slot's applicability or value from the artifacts (a human declares them).
+  - Reflect the posture that discover recorded directly under tree L3 as "points that need a decision (④)" (even when no concrete value exists, treat the slot's existence as something to close).
+  - For slots already covered by existing artifacts, do not recreate them; reference their close target (e.g. `decision-fit-criterion` → `## Validation`, `decision-exception-flow` → `## Expected Behavior`, `decision-characterization` → `algo-characterization-test.md`). Do not write the value twice in `## Decisions`; declare that it "is closed in the existing section" (no duplicate definition).
+  - For an `undetermined` slot, also note the reason, the caveat for downstream, and the revisit condition (Revisit when). For a `not-applicable` slot, also note the rationale for non-applicability and do not silently drop it.
+- Dosage triage (front-load / defer): sort each decision into "a human fixes it up front (visible rule)" or "delegate it to the agent and defer it (hidden / discretion)".
+  - A decision that meets any of the 5 front-loading criteria (irreversible / costly to change later; ripples across multiple modules or external users (external impact); makes acceptance tests or observation weak when left ambiguous (acceptance oracle); a security / regulatory floor; binds multiple packets) is **fixed up front**. An architecture-significant decision meeting two or more is sent to the compass's Decision Rules as an ADR candidate.
+  - A decision that can be localized inside the design rules and is reversible (cheap-to-reverse) and explorable is kept as `undetermined (deferred, with revisit condition)` and may be delegated to the agent's discretion zone (do not leave it neglected; always note the revisit condition).
+  - Front-loading is not limited to "finalizing the decision itself early"; prioritize **front-loading learning, risk discovery, and test-oracle formation** (do not force an early lock-in of the conclusion).
+- Fill in `state` declaratively from the 5-value domain in `packet-format.md`. Do not finalize a progression stage (especially `verifying`/`done`) on the AI's self-report alone; base it on a human or a check gate (results from intent-validate / drift-watch). `state=done` presupposes finalized verification results in the `## Evidence` section.
+- In `depends_on`, declaratively list the `packet_id`s of the packets this one depends on (default `[]`; never omit the key even when empty). Tools do not infer or compute dependencies.
+- In the `## Evidence` section, record the verification result, the date, the check-axis ID (kebab-case ID from `validate-checks.md`), and the source (intent-validate / drift-watch / human confirmation). Evidence is based on check results or human confirmation, not the AI's self-report, and is recorded so the source is traceable. Keep it as an empty section when there is no result; never fill it in by guessing.
+- Present an existing packet's `state: active` as a migration proposal to `implementing`, and a missing `depends_on`/`## Evidence` as a lazy-completion proposal (a differential addition of `depends_on: []`), riding on the existing differential-update-proposal discipline (no forced bulk migration; move only; never delete).
+- If existing packet files exist, read them and present additions as differential update proposals rather than overwriting or destroying them.
+- Reflect the Compass's **project-universal** invariants into each packet's Safety, and draft packet-specific invariants directly in the packet file's Safety / Invariants (do not write them into the compass).
+- Read the constraints held in `.intent/intent-compass.md`'s `## Open Questions` as "packet-specific constraints (candidates)". For each candidate that matches this packet's work scope (Scope/Non-scope), ask the user in natural language to confirm it and wait for their answer, then transcribe it into that packet file's Safety / Invariants and remove the transcribed entry from the compass's `## Open Questions` (do not leave the hold duplicated). Candidates that match no packet remain held in the compass's `## Open Questions`.
+
+### Step 4: Judge termination, then present priorities and splits
+- Decomposition termination (composite stop condition): stop splitting once a packet satisfies all six conditions. (1) one packet maps to one primary concern; (2) the acceptance criteria reduce to observable inputs, conditions, and expected results; (3) the boundaries of the solution space (fixed / discretionary / forbidden) are explicit; (4) cheap-to-reverse (backing out is cheap); (5) the trace target is clear (you can follow the parent intent / spec_refs); (6) standalone completeness: a packet's own done is a coherent behavioral boundary that is not half-baked as seen by the user / caller (do not create a done for half-done behavior). (6) is an independent condition distinct from (4) — (4) is "the builder-side rollback safety (intermediate states can be backed out)", while (6) is "the caller-side semantic consistency of the completed form"; the observer differs (do not fold (6) into (4)). Before these hold it is too coarse; splitting further after they hold is over-decomposition.
+- The verifiability floor is discriminative testability: "a test can be written (testability)" is not enough; there must be "an oracle that can reject a wrong implementation". A packet for which no such rejecting oracle can be found has immature acceptance criteria — rework its Validation / Expected Behavior into observable form.
+- A packet whose acceptance criteria span multiple concerns or multiple quality-attribute trade-offs is judged "still too coarse"; propose splitting it along concern lines (move toward one packet = one concern).
+- Do not decompose a work unit down to implementation steps (a full specification of the how). Keep it at `what + constraints + oracle` (what / boundary constraints / an oracle that rejects wrong implementations), and leave the inside of the rules to the agent's discretion.
+- Maintain the existing granularity discipline (behavior-preserving / testable / rollbackable; the count is variable with the change size, with 1–7 as a loose guide, and do not pad the count), and use "one packet = one concern" and (6) standalone completeness explicitly in the termination judgment.
+- Indicate the packets' priority.
+- Read `rules/walking-skeleton.md` and apply it according to the rule's applicability conditions.
+- Read `rules/first-packet.md` and apply it.
+- Present split proposals for packets that are too large.
+- For packets confirmed by the user, declaratively update `state` from draft to `ready` (ready to start; dependencies resolved) and regenerate `index.md` (see `rules/packet-format.md` for the value domain and the regeneration procedure). Progression to in-progress/awaiting-verification/done (`implementing`/`verifying`/`done`) is done by subsequent declarations based on a human or a check gate.
+- Supersede: when a plan revision replaces an existing packet with a successor, fill in `superseded_by` on the old packet at the same time the successor packet is drafted, move it to `archive/<year>/`, and regenerate the index.
+- **In-flight guard**: if the packet being replaced has been exported (has a row in `.intent/export-log.md`) and has no terminal-state (promoted / closed) delta, warn that implementation may be in progress and do not move it without user confirmation.
+- Treat a rename request for an exported packet as a supersede, not a rename (the name-mutability rule in `rules/packet-format.md`).
+- Do not make implementation changes.
+
+## Output Description
+
+**Reader**: the human developer carving out work units and handing them to the implementation flow.
+**What this output makes them grasp first**: "**The packet to start with first is this (= the packet to export next). The next move is the exit that matches the case type.**" The packet list, priorities, and split proposals are the supporting detail.
+
+Lead with the conclusion (the packet to start and the next command).
+
+- **The packet to start with first (first, with reasons)**: the recommended packet = the packet to export next (the same one). Add why it is placed first.
+- **Next move (one line, branched by case type)**: apply `rules/export-route.md` (the exit decision lane) read-only and present the exit chosen from the case type. Do not recommend cc-sdd unconditionally (no hardcoding):
+  - If the target format (the `format` line in `.intent/mode.local.md`) is set to a valid value, recommend that exit: `cc-sdd` → `/intent-export-cc-sdd` / `openspec` → `/intent-export-openspec` / `to-spec` → `/intent-to-spec`.
+  - If `format` is unspecified (absent / placeholder / out of range), infer the top candidate from mode (non-code / standard-family) and the prerequisite (presence of `.kiro/`) (non-code + no `.kiro/` → `/intent-to-spec` / standard + `.kiro/` present → `/intent-export-cc-sdd`).
+  - When it cannot be uniquely determined, do not collapse to a single exit — list candidates (the exit depends on the user's intent; the decision detail is owned by `rules/export-route.md`).
+- **Details**: the packet files under `.intent/packets/active/` (new drafts and differential update proposals for existing ones; as many packets as the change size warrants, with 1–7 as a loose guide, each with a parent intent), updates to `.intent/packets/plan.md` and `.intent/packets/index.md`, packet priorities, and split proposals for packets that are too large.
+
+## Safety & Fallback
+- If there is no Intent Tree / Compass, stop and guide the user to the corresponding command.
+- The absence of mode.md does not stop; continue with the standard default and announce it.
+- Do not drop packets too far down into implementation tasks (above an Issue, before a spec).
+- Do not delete packet files (move only).
+- Shell command usage is limited to getting the date/time, directory creation (mkdir) and moves under `.intent/packets/` (the invariant of not changing application code stays).
+- Do not change application code.

package/templates/en/codex/skills/intent-packets/rules/algo-additive-slicing.md

@@ -0,0 +1,55 @@
+# Algorithm: Additive Slicing
+
+A technique for decomposing a new feature into "additive slices" that are added in an order that does not affect existing behavior. Used together with Example Mapping in the Packet decomposition phase of `feature-growth` mode. It composes the slices in three stages — establish the seam → additively stack the new feature → wire it into the existing system — deriving a path where each slice can be delivered independently while preserving the existing behavior. Where Migration Slicing takes a drift list (gaps to fix) as input, Additive Slicing takes the impact list and the new feature's intent — the inputs differ, so the two are not interchangeable.
+
+## Procedure
+
+Input = the new feature's intent (structured via GORE-lite and concretized via Example Mapping) and the impact list produced by Impact Analysis in discover (each item = boundary touched / existing contract depended on / kind of impact). A thin impact list turns the slices into guesswork — if it lacks the depth to design the seams, go back to discover.
+
+1. **Cut the slice that establishes the seam**
+   - From the impact list's "extend / requires change" items, identify the junction points where the new feature meets the existing system, and put first a **behavior-preserving slice that creates the junction with the minimal change to the existing code**.
+   - Reference the established tactics: the interface insertion of **Branch by Abstraction** (Fowler / Hammant), the expand stage of **Parallel Change (expand-contract)** (Danilo Sato), and the **seam concept** (Feathers, Working Effectively with Legacy Code). All are moves for "creating a point where a new implementation can be plugged in without changing existing behavior".
+   - When the seam-establishing slice completes, the existing observable behavior must be unchanged.
+
+2. **Stack the new feature additively**
+   - Beyond the seam, stack the new feature as a **set of slices consisting only of new code that does not touch existing code**. The slices in this stage are unreachable from the existing system before wiring, so they can be stacked while keeping the impact on existing behavior at zero.
+   - The examples concretized by Example Mapping flow into each slice's Expected Behavior.
+
+3. **Wire it in and activate**
+   - Finally, place the **wiring slice that activates the new feature via the seam**. The wiring must be revertible to disabled on its own (each packet's Toggle Plan makes this concrete).
+
+4. **Explore and split candidates with SPIDR**
+   - For exploring slice candidates and splitting slices that are too large, use **SPIDR** (Mike Cohn: the five cuts of Spike / Paths / Interfaces / Data / Rules) as an auxiliary heuristic.
+   - Rough affinity with the stages: seam stage = Interfaces, additive stage = Paths / Rules, wiring stage = Data / Rules.
+
+5. **Attach a verification point, rollback, and toggle plan to each slice**
+   - Attach a regression verification point for existing behavior, so that behavior preservation is observable → **Validation**.
+   - How to revert on failure (each slice must be reversible on its own) → **Rollback**.
+   - Which scope is off-by-default / under what condition the toggle gets removed → **Toggle Plan**.
+
+6. **Confirm the termination of the impact list**
+   - Confirm that every item in the impact list terminates as one of — "protected by the Safety / Invariants of some slice" or "sent to Open Questions". Leave no item that is neither.
+
+## Assembling the packet
+
+Consolidate the three-stage ordered additive slices into packets. Each packet satisfies the following.
+
+- **Parent Intent**: a reference to the corresponding L1/L2/L3 (required). If it protects an impact-list item, also indicate the original item.
+- **Scope / Non-scope**: the addition this slice includes / does not include.
+- **Expected Behavior**: derived from the "examples" of Example Mapping. For the seam and wiring slices, also note "the existing behavior preserved".
+- **Safety / Invariants**: invariants that must not be broken during the transition. State explicitly which impact-list items it protects (derived from the Compass invariants).
+- **Validation / Rollback**: derived from the above.
+- **Toggle Plan**: which scope is off-by-default / under what condition the toggle gets removed (Hodgson's Release Toggles). Estimating the toggle's implementation difficulty is outside the planning scope — write up to the plan for its existence and lifetime.
+- **cc-sdd Mapping**: the policy for how to hand off to cc-sdd.
+
+## Discipline
+
+- Each slice must be **behavior-preserving / testable / rollbackable**.
+- **Impact-list traceability**: every item in the input impact list must terminate as one of — protected by the Safety / Invariants of some slice, or sent to Open Questions. Never silently drop an item.
+- **Keep the stage order**: establish the seam → add → wire. Do not embed directly into existing modules without creating a seam.
+- Keep the count variable with the expected change size; do not pad it (one is fine for very small changes; treat 1–7 as a loose guide). For slices that are too large, present split proposals along the SPIDR cuts.
+- This is the structuring of intent (a packet-decomposition technique), not addition execution code. Do not change code.
+
+## Output
+
+An ordered set of additive slices (establish the seam → add → wire). Each slice has the structure above, and its Scope / Validation / Rollback / Toggle Plan flow into each packet. Update (present as a proposal) the packet files (under `active/`).

package/templates/en/codex/skills/intent-packets/rules/algo-characterization-test.md

@@ -0,0 +1,40 @@
+# Algorithm: Characterization Test
+
+A technique for capturing the "observable behavior" of unknown legacy as test points that pin it down exactly as it is now. Used together with Example Mapping in the Packet decomposition phase of `behavior-unknown` mode. **For a target with unknown behavior, run this technique first** and hand the observed facts to Example Mapping (you cannot write "examples" for behavior you do not know, so observation comes first). Before structuring intent, it fixes "how it behaves now" as a safety net and derives the packet's Expected Behavior and Validation from observed facts.
+
+## Procedure
+
+Input = the target whose behavior is unknown (legacy code / existing behavior). It does not depend on Example Mapping's output (rather, this technique's observation becomes Example Mapping's input).
+
+1. **Observe the current behavior and pin it down without judging**
+   - Observe the target's current inputs/outputs and side effects, and write them down as characterization test points (tests that pin the current behavior exactly as it is) without judging "whether it is correct".
+   - This is the planning of test points, not actual test code implementation.
+
+2. **Sort the pinned behavior into intentional / accidental and hand it to Example Mapping**
+   - For each pinned behavior, sort which are intentional and which are accidental. The intentional observed facts become the material that the subsequent Example Mapping organizes into "rules / examples".
+   - Send the accidental ones (side effects / dependencies that cannot be separated from intent) to **Open Questions**; do not promote them to intent by guessing.
+
+3. **Make the characterization tests the starting point of Validation**
+   - Use the sorted behavior points as the starting point of each packet's **Validation**, so they can be used for regression detection during refactoring.
+   - How to revert on failure → **Rollback**.
+
+## Assembling the packet
+
+Consolidate the pinned behavior points into packets. Each packet satisfies the following.
+
+- **Parent Intent**: a reference to the corresponding L1/L2/L3 (required). If it stems from an observation, also indicate the original behavior.
+- **Scope / Non-scope**: the behavior included / not included.
+- **Expected Behavior**: derived from the current observed behavior pinned above.
+- **Safety / Invariants**: among the pinned behaviors, the invariants that must not be broken.
+- **Validation / Rollback**: derived from the above.
+- **cc-sdd Mapping**: the policy for how to hand off to cc-sdd.
+
+## Discipline
+
+- **Observation, not judgment**: pin the current behavior as fact exactly as it is, and do not delve into judging correctness or into causes.
+- For anything where you cannot judge whether it is intentional or accidental, do not fill it with guesses; send it to **Open Questions**.
+- This is the structuring of intent (a technique that pins down intent by observing behavior), not actual test code implementation. Do not change code.
+
+## Output
+
+A set of test points that pin the current behavior (with the intentional / accidental sorting). The Expected Behavior / Validation of each point flows into each packet. Update (present as a proposal) the packet files (under `active/`).

package/templates/en/codex/skills/intent-packets/rules/algo-example-mapping.md

@@ -0,0 +1,47 @@
+# Algorithm: Example Mapping
+
+A technique for grounding abstract capabilities into observable concrete examples. Used in the Packet decomposition phase of the `standard` and `behavior-unknown` modes. It expands a capability into "rules, examples, questions, deferred" and derives the packet's Expected Behavior and Validation. In behavior-unknown mode, the observed facts pinned by the preceding Characterization Test become the input for the "examples" (observe first, organize after).
+
+## Procedure
+
+For each L2/L3 capability, expand it as if writing four-color cards.
+
+1. **Rules (the rules the capability follows)**
+   - Bullet the rules/constraints the capability must satisfy.
+
+2. **Examples (observable concrete scenarios)**
+   - For each rule, give concrete examples of "when this happens, behave like this".
+   - These become the packet's **Expected Behavior** (the behavior observable after completion).
+
+3. **Questions (undetermined)**
+   - Anything that cannot be filled in when trying to write an example, or that requires a decision, leave it as a "question".
+   - This becomes the packet's **Open Questions**, or is sent back to the Compass.
+
+4. **Deferred (what you decided not to do this time)**
+   - Anything judged mid-expansion as "this rule/example is excluded from this packet" must not be silently dropped — record it explicitly as **deferred**. It becomes the seed of a follow-up packet, or an Open Question.
+
+5. **Derive Validation and Rollback from the examples**
+   - How to verify each example (tests / manual check / type checking / log check) → **Validation**.
+   - How to revert on failure → **Rollback**.
+
+## Assembling the packet
+
+Consolidate the expansion results into packets. Each packet satisfies the following.
+
+- **Parent Intent**: a reference to the corresponding L0/L1/L2/L3 (required).
+- **Scope / Non-scope**: what is included / what is not.
+- **Expected Behavior**: derived from the "examples" above.
+- **Safety / Invariants**: derived from the Compass invariants.
+- **Validation / Rollback**: derived from the above.
+- **cc-sdd Mapping**: the policy for how to hand off to cc-sdd.
+
+## Discipline
+
+- Packets must be **behavior-preserving / testable / rollbackable**. In greenfield work with no existing behavior to preserve, read behavior-preserving as "can be introduced and removed standalone without affecting anything else".
+- Keep the count variable with the expected change size; do not pad it (one is fine for very small changes; treat 1–7 as a loose guide). For packets that are too large, present split proposals.
+- Do not drop them too far down into implementation tasks (above an Issue, before a spec).
+- Do not change code.
+
+## Output
+
+Update (present as a proposal) the packet files (under `active/`). Each packet has the structure above. Of the four expansion columns (Rules / Examples / Questions / Deferred), the rules and examples flow into each packet's Expected Behavior, the questions go to Open Questions, and the deferred items are kept in the `Deferred` section of `plan.md`.