intent-planner 0.13.1

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

@@ -0,0 +1,47 @@
+# Algorithm: Migration Slicing
+
+A technique for decomposing a large change into "migration slices" that preserve behavior and can be shipped individually. Used in the Packet decomposition phase of `refactor` mode. It cuts the gap between the intended design and the current state into behavior-preserving / testable / rollbackable units, deriving a path that advances from the current state one step at a time.
+
+## Procedure
+
+Input = the Intent of the refactor target (the intended design) and the current state, plus the drift list produced by Drift Analysis.
+
+1. **Mikado pre-pass: back-calculate the prerequisites**
+   - For resolving each drift (the goal), recursively back-calculate "what must be true first for this to be changed safely", and write the prerequisite graph (the Mikado Method's Mikado Graph) as an indented bullet list.
+   - The **leaves** — entries with no prerequisites — are the changes you can start with. This is a desk back-calculation at planning time; do not experimentally change code to find out (write the implementation-time Mikado discipline of "revert immediately when an experiment fails, and attack from the leaves" into each slice's Rollback so it flows into the exported implementation hints).
+
+2. **Cut the gap into minimal migration units**
+   - Split the current → intended gap into the smallest units that can be applied without breaking behavior. Raise slices starting from the changes close to the leaves of the prerequisite graph (think of dependency discovery as the graph's job and unit decomposition as the slice's job, separately).
+   - Make each slice individually deployable and have it advance the design one step while preserving the existing behavior.
+
+3. **Order by dependency, into a chain of unblocks**
+   - Order the slices by their dependencies so that each slice unblocks the next.
+   - Confirm that at whichever slice you stop, the state up to that point is consistent (intermediate states are also behavior-preserving).
+   - When multiple slices are startable within the dependency constraints, **put first the one that reduces the most risk / unblocks the most downstream slices**, and attach a one-sentence reason (no numeric scoring — that would be groundless pseudo-quantification).
+
+4. **Attach a verification point and rollback to each slice**
+   - Attach a characterization / regression verification point to each slice so that behavior preservation is observable → **Validation**.
+   - How to revert on failure (each slice must be reversible on its own) → **Rollback**.
+
+## Assembling the packet
+
+Consolidate the ordered migration slices into packets. Each packet satisfies the following.
+
+- **Parent Intent**: a reference to the corresponding L1/L2/L3 (required). If it stems from a drift, also indicate the original drift.
+- **Scope / Non-scope**: the migration this slice includes / does not include.
+- **Expected Behavior**: the existing behavior preserved after the migration.
+- **Safety / Invariants**: invariants that must not be broken during the migration.
+- **Validation / Rollback**: derived from the above.
+- **cc-sdd Mapping**: the policy for how to hand off to cc-sdd.
+
+## Discipline
+
+- Each slice must be **behavior-preserving / testable / rollbackable**.
+- **Drift traceability**: every drift in the input drift list must terminate as one of — a slice (packet), an Open Question, or an explicit deferral with a reason. Never silently drop a drift.
+- Order slices by dependency, and each must be individually deployable.
+- 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.
+- This is the structuring of intent (a packet-decomposition technique), not migration execution code. Do not change code.
+
+## Output
+
+An ordered set of migration slices. Each slice has the structure above, and its Scope / Validation / Rollback flow into each packet. Update (present as a proposal) the packet files (under `active/`).

package/templates/en/codex/skills/intent-packets/rules/decision-slots.md

@@ -0,0 +1,88 @@
+# Decision Slots Catalog (completeness schema)
+
+The **single canonical source of the completeness schema** that lists easy-to-miss topics as a "table of contents". Instead of leaving coverage to free-form requirement prose, it structurally bounds the kinds of omissions. `intent-discover` (posture check), `intent-packets` (slot seeding), and `intent-validate` (satisfaction check) all read this catalog as the single reference.
+
+This catalog is a "sample (a table of contents of easy-to-miss topics)", not a fixed net. Filling gaps for a project type is delegated to discover's posture check and the mode-specific deltas.
+
+## Value range and status
+
+Each slot takes one of the value range `decided value | undecided (with reason) | not applicable`, and **must be closed** with one of the following 4 statuses (structurally preventing "silently skipping").
+
+| Status | Meaning | What to record alongside |
+|--------|---------|--------------------------|
+| Answered | A decided value exists | The decided value (in the packet's `## Decisions` or the closing section) |
+| Undecided | Not yet decided (deferred) | Reason, a downstream caveat, and a revisit condition (Revisit when) |
+| Not applicable | This slot does not apply to this packet | The rationale for non-applicability (do not silently drop it) |
+| Send to ADR candidate | An architecture-significant decision | Send it to the compass's Decision Rules (the target of up-front fixing) |
+
+- `Answered` corresponds to the value range `decided value`, `Undecided` to `undecided (with reason)`, and `Not applicable` to `not applicable`. `Send to ADR candidate` is a declaration until the value is decided on the compass side.
+- For a slot whose "closes in" is an existing section (`## Validation` / `## Expected Behavior`, etc.), you may declare in `## Decisions` that it "is closed in the existing section" rather than duplicating the value (do not define it twice).
+
+## Common core slots (seeded in all modes)
+
+8 slots seeded into every packet. The first 4 (centered on ④) stem from "decision-making under constraints"; the latter 4 fill gaps that existing artifacts did not cover.
+
+| ID | Slot name | What to confirm | Completion condition | Closes in | Up-front/deferred door | Rationale |
+|----|-----------|-----------------|----------------------|-----------|------------------------|-----------|
+| `decision-consistency` | Consistency model | On data change, strong (immediate) or eventual consistency | Which consistency model is declared and downstream can rely on it | packet `## Decisions` (new) | Up-front (one-way: costly external impact if overturned later) | Irreversible, binds multiple packets. ISO/IEC/IEEE 42010 decision/rationale |
+| `decision-idempotency` | Idempotency & retry | Preventing inconsistency on write retry (idempotency keys, etc.) | The behavior on retry is declared | packet `## Decisions` (new) | Deferrable (two-way: discretionary if localizable and reversible) | Affects the acceptance oracle; a retry-premised quality attribute |
+| `decision-error-semantics` | Error semantics & boundary validation | Boundary validation and error return when input is empty/unexpected (Fail-Fast, etc.) | The return contract on abnormal input is declared | packet `## Decisions` (new) | Deferrable (two-way) | Affects the acceptance oracle and external contracts |
+| `decision-authz` | Authorization | Which actors may act, and row-level permission to accessible data | Who can access what is declared | packet `## Decisions` (new) | Up-front (one-way: security/regulatory floor) | Irreversible, security floor. A high-cost decision |
+| `decision-quality-priority` | Quality-goal prioritization | Among performance/reliability/maintainability/security, the load-bearing top 2-3 attributes | The top attributes are declared with a ranking | packet `## Decisions` (new; may link with compass Invariants) | Deferrable (two-way) | A quality trade-off point. ISO/IEC 25010 quality vocabulary |
+| `decision-fit-criterion` | Numeric/fit criterion | How acceptance is measured (fit criterion / SLO / test oracle) | The numeric/observable acceptance condition is declared | Reference packet `## Validation` (existing). If undecided, declare in `## Decisions` | Deferrable (two-way) | Affects the acceptance oracle. Volere's fit criterion |
+| `decision-exception-flow` | Exception flow | Whether representative abnormal-path flows are defined, not only the happy path | Representative abnormal-path flows are declared | Reference packet `## Expected Behavior` (existing). If missing, declare in `## Decisions` | Deferrable (two-way) | Fills the happy-path-bias gap (PBR test/operations viewpoints) |
+| `decision-downstream-trace` | Downstream trace | Links to the work/tests that realize/verify this packet (realized-by / verified-by) | Downstream links are declared (or judged minimally-sufficient and left empty) | packet `## Verification protocol` / trace links (new, optional) | Deferrable (two-way) | Bidirectional trace (fills the pre-RS gap) |
+
+- Because `decision-fit-criterion` / `decision-exception-flow` close in existing sections, if they are closed in the existing section, place only a reference in `## Decisions` stating it "is closed in the existing section" (do not define it twice).
+- The common core is seeded in all modes. `intent-validate`'s `decision-slot-unsown` check detects "none of these 8 IDs is seeded in `## Decisions`" (common core unsown).
+
+## Mode-specific delta slots (added per mode)
+
+Delta slots **added** to the common core according to the mode in `.intent/mode.md`. The slot definitions are canonical in this table and are not hardcoded into the skill body (riding on the Mode/Algorithm/Skill three-layer separation).
+
+### standard
+
+| ID | Slot name | What to confirm | Completion condition | Closes in | Up-front/deferred door |
+|----|-----------|-----------------|----------------------|-----------|------------------------|
+| `decision-perf-budget` | Performance budget | The allowable envelope for latency/throughput/resources | The performance envelope is declared | packet `## Decisions` | Deferrable (two-way) |
+| `decision-data-ownership` | Data ownership | Where this data's source of truth is and who may modify it | The data's source of truth and the modifying party are declared | packet `## Decisions` | Up-front (one-way: large external impact if overturned later) |
+
+### refactor
+
+| ID | Slot name | What to confirm | Completion condition | Closes in | Up-front/deferred door |
+|----|-----------|-----------------|----------------------|-----------|------------------------|
+| `decision-characterization` | Behavior to preserve / characterization tests | Test points that pin the current observable behavior exactly as it is | The observed behavior is pinned | Reference the existing `algo-characterization-test.md` (do not define it twice) | Up-front (one-way: pin the safety net first) |
+| `decision-change-boundary` | Change boundary | How far it is OK to change, and what must not be touched | The changeable range and the untouchable range are declared | packet `## Decisions` | Up-front (one-way) |
+| `decision-rollout-safety` | Rollout safety | How to revert and what to observe when rolling out the change in stages | The rollout strategy and how to revert are declared | packet `## Decisions` / reference `## Rollback` (existing) | Deferrable (two-way) |
+
+### behavior-unknown
+
+| ID | Slot name | What to confirm | Completion condition | Closes in | Up-front/deferred door |
+|----|-----------|-----------------|----------------------|-----------|------------------------|
+| `decision-observed-facts` | Observed facts and their source | What was observed and where its source is | The observed facts and their source are declared | packet `## Decisions` / reference `## Expected Behavior` (existing) | Up-front (one-way: pin the facts first) |
+| `decision-hypothesis-confidence` | Distinguishing hypothesis from confidence | Which are facts and which are hypotheses, and to what degree of confidence | Facts/hypotheses and confidence are distinguished | packet `## Decisions` | Deferrable (two-way) |
+| `decision-current-vs-future` | Separating current behavior from future intent | Whether "it behaves like this now" and "we want it to behave like this" are conflated | Current behavior and future intent are declared separately | packet `## Decisions` | Deferrable (two-way) |
+
+### feature-growth
+
+| ID | Slot name | What to confirm | Completion condition | Closes in | Up-front/deferred door |
+|----|-----------|-----------------|----------------------|-----------|------------------------|
+| `decision-existing-boundary` | Consistency with existing boundaries | Whether it is consistent with existing module boundaries/contracts | The policy for consistency with existing boundaries is declared | packet `## Decisions` | Up-front (one-way) |
+| `decision-backward-compat` | Backward compatibility | Whether it breaks existing users / existing data | The backward-compatibility policy is declared | packet `## Decisions` | Up-front (one-way: a high-cost decision) |
+| `decision-data-migration` | Data migration | How to migrate existing data and consistency during migration | The migration strategy is declared | packet `## Decisions` | Up-front (one-way: irreversible) |
+| `decision-staged-rollout` | Staged rollout | How to run old and new in parallel and how to switch over | The staged-rollout strategy is declared | packet `## Decisions` | Deferrable (two-way) |
+| `decision-legacy-impact` | Impact on legacy features | The side effects this extension has on existing features | The impact on legacy features is declared | packet `## Decisions` | Deferrable (two-way) |
+
+## Three disciplines
+
+A skill applying this catalog observes the following three disciplines.
+
+1. **Do not offer defaults (anchoring avoidance)**: do not present a "reasonable default" or "recommended value" for a slot. This avoids the anchoring bias where judgment is dragged toward the first value presented. Symmetric side-by-side presentation of multiple options is reserved as a future extension candidate.
+2. **The tool does not infer applicability or values**: do not infer or auto-fill whether a slot applies, or which value it takes, from the artifact contents. People declare them (the same declaration-based discipline as not inferring `depends_on`). `intent-validate` only checks the slots/statuses actually declared.
+3. **Do not fix the ceiling (How)**: a slot declares "what to decide (what + constraints + oracle)" and does not make the packet carry the implementation How. The local search inside the rules is delegated to the agent's discretion zone.
+
+## How to extend
+
+- **Extension completes by just adding a row to the table** (no structural change to other files needed — the "table is canonical" pattern). To grow the common core, add a row to the common-core table; to grow a mode delta, add a row to that mode's table.
+- **For a slot covered by an existing artifact, reference the "closes in" and do not create a new container**. Intent/scope/stakeholders/constraints/acceptance evidence, etc. are covered by the existing tree / compass / packet existing sections, so do not recreate them in `## Decisions`; reference their closing section.
+- For a slot with the same subject as an existing rule (e.g. `decision-characterization`), keep it as a reference to the existing file (`algo-characterization-test.md`) and do not duplicate the definition.

package/templates/en/codex/skills/intent-packets/rules/export-route.md

@@ -0,0 +1,54 @@
+# Export Route (exit decision lane)
+
+A **read-only decision convention** that, after the planning phase (discover→compass→packets), chooses which exit to take based on the case type. There are three exits:
+
+- **cc-sdd implementation export** → `/intent-export-cc-sdd`
+- **OpenSpec implementation export** → `/intent-export-openspec`
+- **readable Spec projection** → `/intent-to-spec`
+
+This convention is the **single source of truth in intent-packets**; the exit suggestion in `/intent-packets` and the preflight in the export skills reference this rule (the rule body is not copied into other skills). The decision is semantic and is not pushed onto a mechanical check script such as `intent-check.mjs` (INV2).
+
+## Inputs (all read-only observation)
+
+The decision takes three inputs. Each is observed with Read / Glob and never creates, modifies, or deletes a file (read-only, INV5):
+
+1. **target format**: the value of the `format` line in `.intent/mode.local.md` (or the legacy `.intent/mode.md`), with range `cc-sdd` / `openspec` / `to-spec`.
+2. **mode**: the `mode` value in the same file (`non-code` / `standard`-family).
+3. **prerequisite**: whether the `.kiro/` directory exists (a hint for whether cc-sdd is set up).
+
+## Decision (first-match, deterministic)
+
+The same inputs always yield the same result (deterministic). Evaluate top-down and take the first matching row.
+
+### A. When format is explicitly set to a valid value (highest priority)
+
+| `format` | recommended exit |
+|----------|------------------|
+| `openspec` | `/intent-export-openspec` (**for an OpenSpec case, promote OpenSpec**) |
+| `cc-sdd` | `/intent-export-cc-sdd` |
+| `to-spec` | `/intent-to-spec` |
+
+When set, deterministically recommend that exit.
+
+### B. When format is unspecified (infer from mode + prerequisite)
+
+When `format` is "unspecified" (any of: (1) the line is absent, (2) a placeholder value `(undetermined — …)`, (3) a value outside the range — per the read contract in mode.local.md), infer and **present candidates** from mode and the presence of `.kiro/`. Cover all four quadrants as follows:
+
+| mode | `.kiro/` | result |
+|------|----------|--------|
+| non-code | absent | `/intent-to-spec` as the top candidate (a readable artifact is the goal, DR15) |
+| standard-family | present | `/intent-export-cc-sdd` as the top candidate (implementation case, cc-sdd already set up) |
+| non-code | present | **list candidates** (`/intent-to-spec` on top, but also list `/intent-export-cc-sdd`; a non-code case can still have cc-sdd set up, so do not collapse to one) |
+| standard-family | absent | **list candidates** (`/intent-export-cc-sdd` [needs setup], `/intent-to-spec`, `/intent-export-openspec`; not uniquely determined) |
+
+### C. Fallback
+
+Including any case not above: when format is unspecified and the exit cannot be uniquely determined from the inputs, **do not collapse to a single exit — list candidates** (present rather than assert; the exit depends on the user's intent).
+
+## Discipline
+
+- **Do not hardcode a single exit**: the problem is "collapsing to one exit without looking at the case type." Do not swap in another fixed destination (a to-spec-only or openspec-only path). When ambiguous, present candidates.
+- **read-only**: the decision only observes; it does not mutate state (INV5).
+- **Do not push onto a mechanical check**: keep the semantic decision in this rule plus context; do not move it into a script such as `intent-check.mjs` (INV2).
+- **Do not depend on asking the user back**: settle the exit suggestion via this rule's convention and defaults; do not assume interactive follow-up.
+- **Do not touch external tools**: reading whether `.kiro/` exists is observation, not a change to kiro / cc-sdd / OpenSpec (INV1).

package/templates/en/codex/skills/intent-packets/rules/first-packet.md

@@ -0,0 +1,35 @@
+# First Packet Recommendation
+
+The procedure for recommending and recording exactly one packet to start with, together with qualitative reasons. Always used at the priority presentation (Step 4) of `/intent-packets`.
+
+## Applicability
+
+- **Always apply.** Does not depend on designer-questions in `.intent/mode.md` (apply even when it is off or unrecorded).
+- In SKILL.md Step 4, apply this procedure **after** applying walking-skeleton (apply this procedure even when walking-skeleton was not applied).
+
+## Procedure
+
+1. **Read the materials**
+   - Read the packet candidates and their priorities, the "Walking Skeleton" section of `.intent/packets/plan.md` (if recorded), and the purpose in `.intent/mode.md`.
+
+2. **Choose exactly one packet to start with**
+   - For the reasons, cite the applicable ones among the following qualitative criteria: **risk reduction** / **unblocking dependencies** / **ease of rollback** / **size of learning**.
+   - When purpose=poc is recorded, always include the criterion "whether it can refute the hypothesis most cheaply" in the reasons (when purpose is unrecorded or product, do not reference purpose).
+
+2.5. **Confirm the priorities and acceptable trade-offs with the user**
+   - Before finalizing the recommendation, confirm the priorities and acceptable trade-offs with the user: **which to prioritize, speed vs. quality**, and **which scope may be cut or deferred for this starting point**.
+   - This is a confirmation, not a prompt to override the recommendation. The recommendation is a proposal; when the user's priority judgment obtained here conflicts with the recommendation, prefer the user's judgment and revise the recommendation and its reasons.
+   - Ask in a form where "not applicable / unknown / decide later" can be chosen, and do not force an answer. When a hold or "decide later" is chosen, do not fill it in by guessing; route the item to the "Open Questions" section of `.intent/packets/plan.md` (appending it while preserving the existing content if the section is absent) and continue the recommendation.
+
+3. **Align with the Walking Skeleton**
+   - If the decision on the walking skeleton (the minimal implementation that cuts end to end) is recorded, align the recommendation with it. When making a recommendation that does not align, state the reason explicitly.
+
+4. **Record the recommendation**
+   - Record in the "Recommended First Packet" section of `.intent/packets/plan.md`: **Recommended packet** (packet name) / **Reasons** (qualitative criteria) / **Alignment with Walking Skeleton** (aligned / if not aligned, the reason / Walking Skeleton not recorded).
+   - **Non-destructive append for older scaffolds**: if `plan.md` lacks a "Recommended First Packet" section, append the section while preserving the existing recorded content, then record.
+
+## Discipline
+
+- Do not use numeric scoring (weighted sums, point ratings).
+- The recommendation is a proposal; it does not override the user's own priority judgment.
+- Do not change code.

package/templates/en/codex/skills/intent-packets/rules/packet-format.md

@@ -0,0 +1,207 @@
+# Packet file format
+
+The **single canonical source** for the packet file format, ID rule, state transitions, and the index regeneration procedure (`.intent/packets/active/<packet_id>.md` and `.intent/packets/archive/<year>/<packet_id>.md`). Skills that create, update, or move packets — and skills that read packets — follow these rules.
+
+## Frontmatter schema (12 fixed keys)
+
+Each packet file starts with a YAML frontmatter (`---` delimited). The keys are **fixed to these 12**: `packet_id` / `name` / `state` / `created_at` / `updated_at` / `closed_at` / `parent_intents` / `spec_refs` / `superseded_by` / `summary` / `depends_on` / `mode`.
+
+```yaml
+---
+packet_id: pkt-20260612-auth-session-k3p9   # Immutable. Matches the file name. Trailing segment is a session-specific rand. For packet-to-packet references only
+name: "Auth session cleanup"           # Canonical packet name. Matching key for export-log / Source Packet / deltas / slug derivation
+state: implementing                    # draft | ready | implementing | verifying | done
+created_at: 2026-06-12T05:00:00Z       # Creation timestamp (ISO 8601)
+updated_at: 2026-06-12T05:00:00Z       # Last-updated timestamp (ISO 8601). Equal to created_at on creation; the moment of update on content change
+closed_at: ""                          # Filled in when done (date). Leave empty if unknown at migration
+parent_intents: [L1-2, L2-3]           # References into the tree
+spec_refs: []                          # Finalized at writeback completion
+superseded_by: ""                      # Successor packet_id when superseded
+summary: "Clean up auth sessions"      # Source of the one-line summary in the index
+depends_on: []                         # List of packet_ids this packet depends on (default []). For packet-to-packet references only
+mode: standard                         # Mode confirmed at draft time (fixed at draft time; never retroactively updated)
+---
+```
+
+- `state` takes one of 5 values: `draft | ready | implementing | verifying | done` (see "State value domain"). Superseded is **not a state** but a separate axis expressed by filling in `superseded_by` (see "State transitions and placement").
+- `depends_on` is a list of the `packet_id`s of the packets this packet depends on (default `[]`). Like `superseded_by`, **packet-to-packet references use `packet_id`** (never `name`). It holds only dependencies declared by a human; tools do not infer or compute dependencies.
+- **`mode` is the provenance record of the mode that was confirmed at the time the packet was drafted**. The value is a mode name (e.g. `standard` / `deep` / `quick`). The intent-packets skill resolves the mode at draft time using the CONTRACT.md fallback rule (mode.local.md → mode.md → standard) and stamps the resolved value. **Fixed at draft time** (DR13) — never retroactively update an existing packet's `mode` even if the local mode changes after drafting. If the mode is absent or undetermined, record the default `standard` and do not stop. **Backward compatibility**: an existing packet without `mode` is treated as a missing field; continue without stopping and do not auto-complete on every read. Not stamped in tree / compass / plan (DR11).
+- **`updated_at` is the packet's last-updated timestamp (ISO 8601)**. It is the canonical field that a writer skill (intent-packets / writeback etc.) stamps at the moment it changes the packet. The stamping discipline is:
+  - **On creation, initialize it equal to `created_at`** (never `—` or empty).
+  - **Record the moment of a content update** into `updated_at` (stamp the current time at that moment in ISO 8601).
+  - **Do not stamp on a re-run that involves no content change (idempotent)**. Do not advance the timestamp without a change.
+  - The stamping responsibility belongs to the writing phase (intent-packets / writeback etc.); the read-only verification layer (intent-validate) **only reads** `updated_at` and never rewrites it.
+  - **Backward compatibility**: an existing packet without `updated_at` is treated as a missing field; do not force an immediate bulk migration. The reader makes the absence explicit as "unfilled / unobserved" and does not fill it in by guessing (lazy completion, isomorphic to absent `depends_on` = "no dependencies"). The next writer flow that updates the packet appends it as a differential edit (non-destructive).
+- **Keep undetermined keys with empty values** (never omit the key itself — for determinism of index regeneration and checks). `depends_on` keeps `[]` even when there are no dependencies; do not omit the key.
+- **Summary maintenance norm**: a skill that updates a packet's body must also keep the frontmatter `summary` in sync.
+
+## How name and packet_id are used
+
+- **`name` is the canonical packet name (the matching key)**. The export-log `| packet |` column, the `## Source Packet` heading of cc-sdd drafts, the Delta headings in deltas, and the cc-sdd slug derivation all use `name`. Never use `packet_id` for any of these.
+- **`packet_id` is reserved for the file name (`<packet_id>.md`) and packet-to-packet references such as `superseded_by`**.
+
+### Mutability of name
+
+- After the first export (the moment a row lands in the export-log), `name` is **immutable**. Treat a rename as a supersede (create a successor packet + replace the old packet).
+- Renaming before export is allowed as a differential update (even then, `packet_id` and the file name do not change).
+
+### Resolving a name to a file
+
+1. Match the `name` column of `index.md`, or the frontmatter `name` under `active/`, to identify the file.
+2. If it is not in `active/`, reference `archive/` **explicitly** (an explicit exception to the principle "archive/ is normally not read").
+
+## ID rule
+
+- Format: `pkt-<YYYYMMDD>-<slug>-<rand>`. The date part is the **creation date** (obtained via the shell). The trailing `<rand>` is a **session-specific short random token** (see below) that guarantees IDs never collide even across concurrent sessions; it is part of the immutable identifier.
+- `<rand>` is 4 characters of lowercase ASCII letters and digits (`[a-z0-9]`), generated via the shell at creation time (e.g. `LC_ALL=C tr -dc 'a-z0-9' < /dev/urandom | head -c 4`). If it cannot be generated, do not fill in a guessed value; notify the user and stop (same discipline as when the date cannot be obtained).
+- The slug is derived from `name` by the rule in the next subsection. The next subsection is a **verbatim copy** of map-cc-sdd (the slug rule of the cc-sdd export); when changing it, revise both at the same time (the cc-sdd output directory name is derived from the same `name` by the same rule, so the two coincide).
+
+### Slug rule (deterministic)
+
+Derive the directory name (slug) from the packet name **deterministically** in the following order. The same packet name always yields the same slug.
+
+1. Apply NFC normalization.
+2. Trim leading/trailing whitespace.
+3. Lowercase ASCII uppercase letters.
+4. Replace whitespace and path-dangerous characters (`/ \ : * ? " < > |`) with `-`.
+5. Collapse consecutive `-` into one.
+6. Strip leading/trailing `-`.
+
+- Non-ASCII characters (Japanese etc.) are preserved as-is.
+- If the result is an empty string, use `unnamed-packet` as the slug and notify the user.
+
+### Collision avoidance (concurrent sessions)
+
+- The trailing `<rand>` ensures that creating a **different packet** with the same slug on the same day never yields a colliding ID. Even when **concurrent (parallel) sessions** cannot read each other's unsaved packets, the independently generated `<rand>` values differ, so the IDs differ. The old approach of reading existing packets and then assigning a numbered suffix (`-2`, `-3`, …) is not used, because parallel sessions cannot see each other and so cannot prevent the collision that way.
+- If, at creation time, a generated ID happens to match an existing file (in `active/` or `archive/`), never silently overwrite: regenerate `<rand>`, assign a different ID, and notify the user of the packet-name → ID mapping.
+- `packet_id` and the file name (`<packet_id>.md`) are **immutable** (they do not change on rename, state change, or move). Once fixed, `<rand>` — as part of the ID — does not change either.
+- **Backward compatibility**: legacy IDs without `<rand>` (`pkt-<YYYYMMDD>-<slug>`) remain valid. Do not force an immediate bulk migration; leave existing packet IDs as-is (a rename is treated as a supersede).
+
+## State value domain
+
+`state` is one of 5 values distinguishing the stage of progress. The values are mutually exclusive, and a packet is in exactly one stage. State is a **declarative state record**, not a management mechanism (state machine) with transition rules, guards, or automatic progression.
+
+| state | Meaning | Placement | Evidence | depends_on |
+|-------|---------|-----------|----------|------------|
+| `draft` | Drafting / undetermined | `active/` | Not required | Optional |
+| `ready` | Ready to start (dependencies resolved, awaiting implementation) | `active/` | Not required | Declaring it presumes all dependencies are `done` |
+| `implementing` | Under implementation | `active/` | Provisional in-progress records allowed | — |
+| `verifying` | Implemented, awaiting verification (Evidence undetermined) | `active/` | Being collected (mark as undetermined) | — |
+| `done` | Evidence obtained / complete | `archive/<year>/` | **Presumed finalized** | — |
+
+- The only terminal value is `done`. Finalizing `state=done` presupposes that the `## Evidence` section has finalized verification results (a declarative order of "human/check confirms → record → done", not an automatic transition).
+- Changes to the stage of progress are recorded declaratively, and their finalization rests on a human or a check gate (not finalized by AI self-report alone).
+
+### Backward-compatible migration (from the old `draft | active | done`)
+
+| Old state | New state | Rationale |
+|-----------|-----------|-----------|
+| `draft` | `draft` | Same |
+| `active` | `implementing` | Safe-side default for a started packet (loses the least information; can later be re-declared `ready`/`verifying`) |
+| `done` | `done` | Same |
+
+- Why `active → implementing` is the default: the old `active` covered both "started" and "ready to start", so we err on the safe side (treat as in progress) to prevent "treated as done while not finished".
+- Migration is **presented as a differential update proposal** and recorded after user confirmation. It does not destroy or delete existing packets (**move only**).
+- **Handling missing `depends_on`/`## Evidence`**: even if an existing packet lacks the `depends_on` key or the `## Evidence` section, do not force an immediate bulk migration. The reader treats absent `depends_on` as "no dependencies (equivalent to the empty set)" and absent `Evidence` as "unfilled" (do not fill in by guessing). The next create/update flow that touches the packet appends `depends_on: []` as a differential edit (non-destructive lazy completion).
+
+## State transitions and placement
+
+- Superseded is **not a state** but a separate axis: fill in `superseded_by` with the successor `packet_id`, not the state.
+- Placement mapping:
+  - `draft | ready | implementing | verifying` → `active/`
+  - `done` or `superseded_by` filled in → `archive/<year>/`
+- Writing the state and moving the file are one combined operation (never leave a done packet lingering in `active/`; lingering is subject to status's integrity checks).
+- **No deletion**: packet files are only moved, never deleted.
+
+## Body section structure
+
+Right after the frontmatter, place a `# <name>` heading (recommended), followed by the sections below (inheriting the structure of the current packet definition section).
+
+- `## Parent Intent` — The L0 / L1 / L2 / L3 this packet supports.
+- `## Why` — Why this packet is needed.
+- `## Scope` — What is included.
+- `## Non-scope` — What is not included.
+- `## Expected Behavior` — The behavior observable after completion.
+- `## Decisions` — Decision slots under constraints (the ④-centered slots of the completeness schema). Place it **after `## Expected Behavior` and before `## Safety / Invariants`**. **The canonical source of the slot value domain (`finalized value | undetermined (with reason) | not applicable`), the 4 statuses, the firing conditions, and the slot IDs is `decision-slots.md`** (read that catalog as the single reference; this section is its projection). **Required section** (unlike the optional sections below, it is always kept as the container that closes the common-core slots; if no slots are seeded, keep an empty section and do not fill in by guessing).
+- `## Safety / Invariants` — The constraints to uphold. **The canonical source of packet-specific invariants** (never write them into the compass; the compass holds only project-universal invariants).
+- `## Validation` — How to verify (**plan**). Tests, manual check, log check, type checking, etc.
+- `## Evidence` — What was verified (**result**). Place it right after `Validation` (plan) and before `Rollback`. Each entry can include "the verified result, the date performed, the corresponding check-axis ID (the stable kebab-case ID in `validate-checks.md`), and the source (intent-validate / drift-watch / human confirmation)".
+- `## Rollback` — How to revert on failure.
+- `## Out of scope` — **Optional (recommended)**. State what is not done (non-goals) to prevent over-implementation. If unfilled, the section may be omitted.
+- `## Verification protocol` — **Optional (recommended)**. Holds the tests to write first, the existing tests to protect, and the tests for additional failure modes to add. Downstream trace links (realized-by / verified-by) may also be held here optionally. If unfilled, the section may be omitted.
+- `## cc-sdd Mapping` — How to convert this packet into cc-sdd's requirements / design / tasks.
+
+### `## Decisions` (separating human-fixed from agent-discretion)
+
+`## Decisions` is the section that holds decision slots under constraints, and it carries the following two zones internally (keep them distinguished).
+
+- **Human-fixed (finalized values / visible rules)**: visible design rules that a human fixed up front. Slots with the value domain `finalized value`. The agent does not overturn these rules.
+- **Agent-discretion zone (deferred / undetermined)**: the area where local exploration inside the rules is delegated to the agent. Slots with the value domain `undetermined (with reason)` (`undetermined (deferred)`) correspond to this. For `undetermined`, also note the reason, the caveat for downstream, and the revisit condition (Revisit when).
+
+```markdown
+## Decisions
+### Human-fixed (finalized values / visible rules)
+- `decision-authz` answered: the only actor allowed to execute is the admin role
+### Agent-discretion (deferred / with revisit condition)
+- `decision-idempotency` undetermined: the retry approach is at implementation discretion. Revisit when: it becomes an externally exposed API
+```
+
+- The canonical source of the slot value domain, status, firing conditions, and slot IDs is `decision-slots.md`. This section is its projection; do not redefine the value domain or IDs here.
+- For a slot whose close-site is an existing section (`## Validation` / `## Expected Behavior` etc.), do not duplicate the value here; place only a reference noting "closed in the existing section" (no duplicate definition).
+- If no slots are seeded, **keep an empty section** (do not fill in by guessing); do not omit the section itself.
+
+### Section grading (required / optional)
+
+- **Required**: only `## Decisions` (the container that closes the common-core slots). Keep it as an empty section even when no slots are seeded.
+- **Optional (recommended)**: `## Out of scope` / `## Verification protocol` and the downstream trace links (realized-by / verified-by). If unfilled, the section **may be omitted** (maintaining the lightweight philosophy that avoids packet bloat and decision fatigue).
+- The frontmatter stays **fixed at 12 keys** and is not changed. The addition of these sections is **body sections only** and does not grow the frontmatter (trace links are also held in the body, not as new frontmatter keys).
+
+### Distinguishing `## Validation` (plan) and `## Evidence` (result)
+
+`Validation` is "how it is intended to be verified (plan)", and `Evidence` is "the actual result of verification (reality)"; the two are **not mixed**.
+
+```markdown
+## Evidence
+- 2026-06-15 — `unit: auth-session expiry test` green / `invariant-conflict` not applicable
+  - Check axes: invariant-conflict, l3-intent-mismatch
+  - Source: intent-validate (human confirmation: NN)
+```
+
+- Each entry can include the verified result, the date performed, the check-axis ID (kebab-case), and the source.
+- If there is no result, **keep an empty section** and do not fill in unfilled entries by guessing.
+- Evidence is recorded based on check results (intent-validate / drift-watch) or human confirmation rather than AI self-report, in a form whose source can be traced.
+- **`state=done` presupposes that Evidence has finalized verification results** (done with empty Evidence is a contradictory state).
+
+### Non-code degrade of the validation vocabulary (optional; canonical)
+
+The validation vocabulary in `## Validation` / `## Rollback` is written assuming code deliverables. When packing non-code deliverables (documents, business, research) with packets, you may apply the following read-throughs (this is an **optional degrade**, and this is the **canonical** definition of the read-through vocabulary — the non-code mode refers to this definition).
+
+- `testable` → "decidable by review viewpoints / acceptance criteria"
+- `rollback` → "version control / revert"
+- `behavior-preserving` → "do not break the meaning / agreements of existing deliverables"
+- (6) standalone completeness (termination judgment), "the user / caller" → "the reader / recipient" (for non-code deliverables, it means the packet's completed form is a coherent boundary that is not half-baked as seen by the reader / recipient)
+
+- This degrade is **optional** and does not make the code-assuming vocabulary mandatory (code deliverables keep using the original vocabulary).
+- Applying the degrade does **not skip the packets step**. Non-code work still goes through packets and retains the decision-slot seeding (C3) in `## Decisions` (it only re-reads the vocabulary; it does not bypass packets).
+
+## index.md regeneration procedure
+
+`.intent/packets/index.md` is a generated artifact and must not be hand-edited. A skill that changed the canonical (anything under packets/) regenerates it at the end of its run by the following procedure.
+
+1. Read **only the frontmatter** of every packet file under `active/` (do not read the bodies — deterministic).
+2. Build the `| packet_id | name | state | summary |` table in **ascending** `packet_id` order (`depends_on` is not emitted as an index column — for determinism and to avoid table bloat; the read-only side reads `depends_on` directly from the `active/` frontmatter).
+3. If `active/` is empty (or absent), the canonical form is the table with the header only.
+
+## Read-only consumer contract
+
+Read-only skills such as intent-status / intent-overview **only read** the following interfaces defined by this canonical source, and do not modify the packet canonical.
+
+- **`state` (5-value domain)**: `draft | ready | implementing | verifying | done`. Used to judge the stage of progress.
+- **`depends_on` (list of packet_ids)**: blocked status is derived read-only as "there is a packet in `depends_on` that is not `done` = blocked". The derived result is not written back to the packet. It does not auto-launch the next step or auto-determine ordering based on dependencies.
+- **`## Evidence` section**: verified results, date performed, check-axis ID, source. Material for the "degree of finalization of evidence" in progress.
+
+**Backward-compatible reading discipline (do not fill in by guessing)**:
+- Absent `depends_on` → read as "no dependencies (empty set)".
+- Absent/empty `## Evidence` → make it explicit as "unfilled / unobserved" and do not complete it.
+- Old `state: active` → read as "in progress (equivalent to `implementing`)".
+- When a new field or new section is unfilled or absent, make that location explicit as "unfilled / unobserved".

package/templates/en/codex/skills/intent-packets/rules/walking-skeleton.md

@@ -0,0 +1,35 @@
+# Walking Skeleton Check
+
+The procedure for confirming whether the top-priority packet spans the primary user journey end to end (i.e., is a walking skeleton). Used at the priority presentation (Step 4) of `/intent-packets`, only when designer-questions in `.intent/mode.md` is `on`. All dialogue is conducted as confirmation with the user (the means of confirmation follows the SKILL.md conventions).
+
+## Applicability
+
+- Read `designer-questions` in `.intent/mode.md`. Apply this procedure to the Step 4 priority presentation only when it is `on`.
+- **When designer-questions is not recorded as on (off or unrecorded), do not apply this procedure and do not change the existing Step 4 behavior** (notification for the unrecorded case follows the `.intent/mode.md` conventions).
+- **Do not reference purpose.**
+
+## Procedure
+
+1. **E2E verdict**
+   - Read the top-priority packet's Scope and Expected Behavior, and judge whether it spans the primary user journey end to end (input → processing → observable output).
+   - Ground the verdict in the packet's descriptions. A packet that stops at an intermediate layer (processing only, UI only, etc.) is judged "does not span".
+
+2. **Present the verdict and rationale, and confirm**
+   - Present the verdict (spans end-to-end / does not span) and its rationale to the user, and confirm.
+   - State the rationale in plain language: describe what this packet (the unit of work handed to cc-sdd) builds and what runs end to end after completion, so the rationale is readable without knowing the field names.
+
+3. **Propose remedies (when judged "does not span")**
+   - Propose how to make the first packet a walking skeleton, in one of the following forms:
+     - **Reordering proposal**: reorder the priorities so that a packet spanning E2E comes first.
+     - **Merge proposal**: merge the Scopes of multiple packets to create a packet that spans E2E.
+   - If the user intentionally defers the walking-skeleton conversion, accept that as a choice (do not silently drop it — record it; see step 4).
+
+4. **Record the confirmation result**
+   - Record in the "Walking Skeleton" section of `.intent/packets/plan.md`: **Top-priority packet** (packet name) / **E2E verdict** (spans end-to-end / does not span) / **Confirmation result** (what the user confirmed).
+   - For an intentional deferral, also record it together with the reason under the Deferred section.
+   - **Non-destructive append for older scaffolds**: if `plan.md` lacks a "Walking Skeleton" section, append the section while preserving the existing recorded content, then record.
+
+## Discipline
+
+- The confirmation result is referenced by intent-validate. Do not omit the record.
+- Do not change code.

package/templates/en/codex/skills/intent-release-note/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: intent-release-note
+description: An outward projection skill that reads the git commit history read-only, text-matches each commit against intent (packet name / parent intent / deltas / milestones) to thicken the "why it changed," and derives a release note under `.intent/release-note/` in a format (changelog-style / github-releases-style). It never modifies git or the canonical intent (read-only). Unmatched commits are kept as thin lines, surfacing the gap between intent and reality.
+---
+
+# intent-release-note Skill
+
+## Core Mission
+- **Success Criteria**:
+  - Read the git log of the given range (default = latest tag..HEAD; `<from>..<to>` may be given via argument, with fallback) **read-only** (no commit / tag creation / push).
+  - **Text-match** each commit against intent (packet name / parent intent / deltas / milestones) and, for matched ones, attach the "why (for which intent it changed)."
+  - List unmatched commits as thin changelog lines, **surfacing the gap between intent and reality** (do not silently drop them).
+  - Derive output under `.intent/release-note/` following a format (select `rules/format-changelog.md` / `rules/format-github-releases.md` by argument) by full replacement.
+  - Change neither the canonical intent (intent-tree / compass / packets) nor the git state (INV16 / INV17).
+
+## Execution Steps
+
+### Step 1: Range interpretation (fix the range)
+- When the user runs `/intent-release-note`, first interpret the range argument per `rules/source-scope.md`.
+- The default (no range given) is **latest tag..HEAD** (find the latest tag with `git describe --tags --abbrev=0` and use `<tag>..HEAD`). If `<from>..<to>` is given, use it.
+- If there is no latest tag and the default cannot be resolved, **fall back** to the full history and note this in the output (Fail-Soft). An invalid range argument is an explicit error and does not generate a release note.
+- Once the range is fixed, proceed to Step 2 (the range is uniquely determined by argument + default + fallback, not dependent on interactive completion).
+
+### Step 2: Read-only reading of the git log
+- Per the **read-only allowlist** in `rules/source-scope.md`, read the commits of the fixed range read-only.
+- Only read-only `git log` / `git tag` (listing) / `git describe` / `git rev-list` / `git rev-parse` / `git show` may be used.
+- **Never invoke writing operations** (`git commit` / `git tag <name>` creation / `git push` / `git checkout` / `git switch` / `git reset` / `git restore` / `git merge` / `git rebase` / `git cherry-pick`, etc.) (INV16).
+- Read each commit's hash, subject, body, author, and date as material.
+
+### Step 3: Text-matching commits against intent (propose candidates, do not assert)
+- **Text-match** each commit against intent. The priority of matching material is (1) packet name → (2) parent intent → (3) deltas → (4) milestones. Match the contents under `.intent/` (`packets/` / `intent-tree.md` / `intent-compass.md` / `deltas.md` / `milestones.md`) and the commit messages, **within what is mechanically observable from files**.
+- For a commit that text-matches any of them, attach the "why (for which intent it changed)." When multiple apply, take the highest-priority material.
+- Matching follows the same temperature as the existing `intent-status`: **carry no machine scoring, threshold, or new discriminator** (AD23), and when confidence is low, **propose as a candidate rather than asserting** (unmatched is the norm; tolerate false detections).
+- Commits that match none are **kept as thin changelog lines** (do not silently drop them; AD22).
+
+### Step 4: Format mapping (state the format if default)
+- Fix the format per `rules/format-select.md`. With argument `changelog` / `github-releases`, or the default (changelog) if unspecified, and **state in the output which format was generated**.
+- Hand the chosen format's output-structure rule (`rules/format-changelog.md` or `rules/format-github-releases.md`) the matched material from Step 3 (matched commits with their "why" + unmatched commits as thin lines) and assemble it.
+- Do not hardcode the target format into the body (delegate to rules; AD24). The output structure itself is the format-* rule's responsibility; this SKILL owns git reading, matching, and delegation.
+
+### Step 5: Derived Write (full replacement into `.intent/release-note/`)
+- Write the assembled release note to `.intent/release-note/release-note.md` by **full replacement** (derived, regenerable).
+- Confine the write destination to under `.intent/release-note/`. Change neither the canonical intent (intent-tree / compass / packets) nor the git state (INV16 / INV17).
+- When the target range contains no commits, state in the output that it is empty and change neither the canonical files nor git.
+
+## Output Description
+- At the top of the output, show the target range (with a note if it fell back) and the format (stating it if the default was used).
+- The body follows the chosen format's output structure (changelog-style = per-kind categories / github-releases-style = narrative + change list) (the layout of `rules/format-*.md`).
+- List intent-matched commits with a "why" and unmatched commits as thin lines, so that the gap is readable.
+
+## Safety & Fallback
+- **Read-only ownership boundary**: git is only read (only the Step 2 allowlist). Do not commit / create tags / push / change the working tree or refs (INV16).
+- **Derived-output ownership boundary**: writes go only under `.intent/release-note/`. Do not rewrite the canonical intent (INV17).
+- **Matching ownership boundary**: text-matching only (no machine scoring; AD23). Do not drop the gap (keep thin lines; AD22).
+- **Format ownership boundary**: delegate the output structure to `rules/format-*.md` and do not hardcode it into the body (AD24). Do not change the format-* output structure (fixed at the seam).
+- **Error cases**: no tag → fallback + note. invalid range → explicit error, do not generate. empty range → state empty. In all cases, change neither git nor the canonical files.

package/templates/en/codex/skills/intent-release-note/rules/format-changelog.md

@@ -0,0 +1,40 @@
+# Format Mapping: Changelog-Style (Keep a Changelog layout)
+
+The output structure used by the `intent-release-note` skill (added in a later packet) to assemble the git commit history and the intent-matching result into a **Keep a Changelog-style release note**. SKILL.md owns the procedure (reading git, matching intent); "which material goes under which heading and in what order" is defined by this rule.
+
+## Responsibility boundary (a structure definition, not reading or matching)
+
+- This rule is a **format mapping (output structure definition)**. It only defines the section layout, categorization, and ordering of the release note.
+- Procedures such as reading the git log, matching commits to intent (packet name / parent intent / deltas), and interpreting the range are **SKILL.md's responsibility**; this rule does not perform them (in this seam SKILL.md is not yet present; this rule is placed ahead as a container).
+- The **judgment** of attaching a "why (for which intent)" to matched commits and leaving unmatched commits as thin lines (surfacing the gap) belongs to SKILL.md. This rule only defines **which structure that result is poured into**.
+- That the output goes to a derived directory (`.intent/release-note/`, git-untracked, read-only) and never rewrites the canonical intent or git is the skill's invariant; this rule provides only the structure under that premise.
+
+## Basic stance (classify changes and stack them chronologically)
+
+The changelog style is a layout that **sorts the changes of one release (or one range) by category**. The reader is assumed to want to quickly grasp "what was added, changed, fixed, and removed in this version." Therefore:
+
+- Under a version (or range) heading, distribute changes into category buckets by kind.
+- Each entry is by default a concise single line; for entries tied to intent, append a brief "why" (the wording is prepared by SKILL.md; this rule places it under the relevant Added/Changed category).
+- Do not invent changes absent from the material for the sake of layout (leave unmatched commits as thin lines).
+
+## Structure (top to bottom)
+
+| Order | Section | What goes here |
+|---|---|---|
+| 1 | Heading (version / range and date) | Identifies the target range (default: previous tag..HEAD) and the generation date |
+| 2 | Added | Commits that constitute new features / additions |
+| 3 | Changed | Commits that change or improve existing behavior |
+| 4 | Fixed | Commits that are bug fixes |
+| 5 | Removed | Commits that remove a feature or element |
+| 6 | Other (uncategorized / unmatched changes) | Commits that cannot be categorized above or are not tied to intent, kept as thin lines (surfacing the gap) |
+
+- Categories (2–5) follow the standard Keep a Changelog categories. Omit any category heading that has no matching commits (do not create empty headings).
+- Section 6 is the bucket that keeps unmatched / uncategorizable commits as a thin single line **without silently dropping them**. Omit it if there is no material.
+- The "why" note on each entry is the matching result SKILL.md attached; place it as-is within the relevant category (this rule does not re-match).
+
+## Invariants
+
+- Do not re-read or modify git or the canonical intent (reading and matching belong to SKILL.md; writes belong to SKILL.md's Write into the derived directory).
+- Do not break the structure that classifies changes into per-kind categories (the core of the changelog-style layout).
+- Place both the "why" of intent-matched commits and the thin lines of unmatched commits without dropping either (do not erase the gap).
+- Do not add changes or background absent from the material for the sake of layout.