intent-planner 0.13.1

package/templates/en/claude/skills/intent-export-openspec/rules/drift-export-check.md

@@ -0,0 +1,50 @@
+# Drift Export Check
+
+The matching logic used at Step 1.6 of `/intent-export-openspec`: the target packet's design/tasks hints against the compass. It runs only when `drift-watch: on` (off / absent / invalid values do nothing). It sits after the enforcement gate (Step 1.5, which may stop) and before the Open Questions check (Step 1.7, which does not stop), and warns—right before handoff to OpenSpec, the moment before going-back stops working—whether the packet has drifted from the compass's direction.
+
+## The basis of the matching is the compass
+
+- **The basis of the matching is the North Star / Anti-direction / Invariants of `.intent/intent-compass.md`.** At the export stage the compass already exists, so here the basis is the compass, not the pattern catalog (`.intent/drift-patterns.md`) (the discover terrain diagnosis has neither compass nor packet yet, so it uses the pattern catalog as its basis. Export is its sibling stage, and the difference is that the basis is the compass).
+- The export matching is **premised on false-positives**. "Hitting" a compass element is not a confirmation of drift. We build in from the start that a valid design may be wrongly caught (false-positive), and we record swings and misses too.
+- **This matching is a direction checkpoint, and it does not stop.** Its inspection target is orthogonal to the enforcement gate (a procedure checkpoint that may stop). We never stop export over a drift detection (only the Step 1.5 enforcement gate may stop).
+
+## Procedure
+
+1. **Obtain the inputs**
+   - Take the target packet's **design/tasks hint generation content** (the body of the draft export is about to generate) as the input.
+   - Read the **North Star** / **Anti-direction** / **Invariants** (project-universal Invariants) of `.intent/intent-compass.md`.
+   - **When the compass is absent / unfilled**: skip the export matching and inform the user of that fact (do not stop / do not write to drift-log either). Do not run the remaining steps.
+
+2. **Match the design/tasks hints against the compass**
+   - Hold the design/tasks hints about to be generated against the compass's **Invariants** (do they breach a constraint that must not be broken?), **Anti-direction** (are they leaning toward a direction decided to be avoided?), and **North Star** (have they drifted from the final state?).
+   - This is a **semantic match**, not a mechanical decision. Premised on false-positives, pick it up if in doubt.
+
+3. **When there is a conflict**
+   - Present a **warning only** to the user—**do not stop export**. Name what was breached (which Invariant / Anti-direction / North Star) and which part of the design/tasks hints is off.
+   - Append one entry to `drift-log.md` (see the append procedure below). The values are:
+     - `pattern: <a matching drift-patterns id | uncatalogued:<short name> | ->`（an id if identifiable; `uncatalogued:<short name>` for an actual drift outside the catalog; `-` if undeterminable）
+     - `stage: export`
+     - `packet: <target packet name>`
+     - `mechanism: compass-anti-direction`（when an Anti-direction was breached）or `compass-invariant`（when an Invariant was breached; pick by which compass element was breached）
+     - `outcome: caught`（a **draft**. This is drift-watch's estimate; the verdict is decided by the user's `user-verdict` and the resolution below）
+     - `user-verdict: unjudged`
+     - `recorded_at: <ISO 8601>`
+     - `commit: <short hash | ->`
+     - `note: <1-2 lines>`（what was breached and what was warned about）
+   - If multiple places conflict, append one entry per conflict.
+
+4. **outcome is confirmed by the user's judgment (resolving the draft)**
+   - Step 3 only **drafts** `caught` for `outcome`; the final value is decided by the user's judgment:
+     - When the user heeds the warning and pulls the design back → `caught` (capture succeeded, the "worked" family)
+     - When the user ignores it and passes it through anyway → `missed` (could not prevent it, it got through, the "did not work" family)
+     - When the design was actually valid and it was a false alarm → `false-positive` (it was a false alarm, the "did not work" family)
+   - `user-verdict` backs the final value: `valid` if the point was sound / `false-alarm` if it was a false alarm / `unjudged` if not judged. Even if the user has not judged it, it stays `unjudged` and remains a target for recording and tallying.
+
+## The append procedure to drift-log
+
+- **Write in split form (CONTRACT "Split and archive convention for append-only records")**: drift-log is event-origin, so instead of appending to the end of a single `drift-log.md`, write one entry to a **per-date+slug split file** `drift-log/<date>-<slug>.md`. `<date>` is the recorded_at date; `<slug>` is derived from the pattern (the event) via the existing slug rule (`intent-packets/rules/packet-format.md`) — do not create new/sequential numbering. Because a different event touches a different file, tail collisions disappear by construction. Never rewrite or delete an existing entry (**append-only**).
+- **Always write all 9 keys in fixed order**: `pattern` → `stage` → `packet` → `mechanism` → `outcome` → `user-verdict` → `recorded_at` → `commit` → `note`. Do not write an entry that is missing even one of the 9 keys.
+- **recorded_at**: write the recording time in ISO 8601 (transaction time).
+- **commit**: write the result of `git rev-parse --short HEAD`. When it cannot be obtained (non-repository, git CLI absent, etc.), use `-` (fail-open; recording continues).
+- **When the `drift-log/` directory is absent**: create the directory, then write the split file. An old single `drift-log.md`, if still present, can be read side-by-side by readers (migration is handled by this slice's migration step).
+- Follow the sample in the "Entry format" section of `.intent/drift-log.md` (`### drift-log entry`) for the entry format.

package/templates/en/claude/skills/intent-export-openspec/rules/export-questions.md

@@ -0,0 +1,23 @@
+# Export Questions Check
+
+The procedure for confirming unanswered `[by export]` Open Questions before running the export. Used at Step 1.7 of `/intent-export-openspec`. All dialogue is conducted as confirmation with the user (the means of confirmation follows the SKILL.md conventions).
+
+## Detection
+
+- Read the Open Questions sections of `.intent/intent-tree.md` and `.intent/intent-compass.md`, and detect questions containing `[by export]`. A question remaining in the section is treated as unanswered.
+- Detection targets only these two files. The canonical source of questions is the Open Questions sections of both files; the Deferred section of `.intent/packets/plan.md` is a record of intentional deferrals, not questions, and is therefore out of scope.
+- **Do not reference the enforcement setting (the Enforcement section of `.intent/mode.md`)** (this operates independently of the Step 1.5 enforcement gate).
+
+## Procedure
+
+1. **When nothing is detected (including older scaffolds without the tag convention)**
+   - Present nothing and proceed to the next step (no behavior change).
+
+2. **When questions are detected**
+   - Present the list of detected questions.
+   - Confirm with the user whether to "answer them before exporting, or proceed as is".
+   - This is a confirmation, not a stop. When the user explicitly instructs to proceed, run the export.
+
+## Discipline
+
+- Do not change code.

package/templates/en/claude/skills/intent-export-openspec/rules/map-openspec.md

@@ -0,0 +1,75 @@
+# Mapping: packet → OpenSpec
+
+The rules for converting one chosen packet into an OpenSpec proposal draft + delta spec hint. Used by the `intent-export-openspec` skill. This is one of the per-export-target mappings (for OpenSpec). To add another target (e.g. cc-sdd), add `rules/map-<target>.md` and create a corresponding `intent-export-<target>` skill (the seam). Do not change `map-cc-sdd`.
+
+## Input scope (strict / information-source contract)
+
+- Read only **the one target packet** and **the Invariants / Anti-direction of `.intent/intent-compass.md`**.
+- **Do not read** the full Intent Tree or other packets. Only when the overall direction is needed, reference Tree L0–L1 **as a summary** in a pinpoint manner (no body transcription).
+- This keeps the amount of information passed to OpenSpec to about 1 packet's worth (preventing token explosion).
+- **Do not quote/transcribe other packets or the Intent Tree body** into the deliverables (proposal / delta). Limit sources to the target packet and the compass.
+
+## Output (drafts of 2 files / do not create the main body)
+
+Write the drafts under the per-packet directory `.intent/openspec/<packet-slug>/` (slug derivation is in the next section, "Output layout"). Align **one-directionally** with OpenSpec's entry contract (`/opsx:propose <natural-language change description>`, the proposal's Why/What Changes/Impact, the delta spec's ADDED/MODIFIED/REMOVED + `### Requirement:` / `#### Scenario:`). Do not depend on OpenSpec's internal implementation.
+
+### `.intent/openspec/<packet-slug>/proposal.md`
+
+The **proposal draft** fed into OpenSpec's `/opsx:propose`. Always include the three headings.
+
+- `## Why` — Transcribe the packet's intent / Why and state the **parent intent** (the higher-level aim this packet serves). Describe why this change is needed now.
+- `## What Changes` — List the packet's deliverables / Scope as **bullets**. State the compass's **Anti-direction** within this section **as out-of-scope (what not to do)**.
+- `## Impact` — The specs / contracts this change affects and the constraints to protect. Transcribe the compass's **Invariants**, listing the affected scope (contracts / capabilities touched) alongside the invariants.
+- **primary output**: Write it so that a **minimal and always-valid change description** that can be fed into `/opsx:propose` is derivable from the top of the proposal (the structured proposal is added value on top of that).
+- Limit the information source to the target packet (Why/Scope/Expected Behavior/Safety) and the compass's Invariants / Anti-direction.
+
+### `.intent/openspec/<packet-slug>/spec-delta.md`
+
+A **hint skeleton** for OpenSpec's delta spec (not the main body).
+
+- Map the packet's acceptance criteria / Expected Behavior onto the skeleton of `### Requirement: <name>` (**normative SHALL / MUST statements**) and `#### Scenario: <name>` (**GIVEN / WHEN / THEN**).
+- **Seed the heading syntax accurately** (`### Requirement:` / `#### Scenario:`) to guide toward a structure that passes OpenSpec's validate.
+- Follow the dispatch rule in the next section, "Delta dispatch".
+- Do not complete the main body. Reconciliation and completion are left to OpenSpec (from `/opsx:propose` onward) (INV4).
+
+## Delta dispatch (ADDED / MODIFIED / REMOVED)
+
+- **Default**: Place all of the packet's acceptance criteria under `## ADDED Requirements`.
+- **Conditional**: Only when the packet's **Scope** or the compass's **Anti-direction** **explicitly references a change/removal** of an existing capability or behavior, place a hint of "**the name of the capability changed + the direction of change**" under `## MODIFIED Requirements` / `## REMOVED Requirements`.
+- MODIFIED / REMOVED stay as identification hints for the change target; reconciliation with the existing spec and finalization are left to OpenSpec. If there is no explicit reference, do not place MODIFIED / REMOVED.
+
+## Output layout (slug rule and collision rule)
+
+### 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. This rule is **identical** to the slug rule in `packet-format.md` and `map-cc-sdd` (aligning output-path derivation across export targets).
+
+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 rule
+
+- A collision occurs only when the slug matches an existing directory AND that directory's proposal.md points to a **different** packet name. Assign a numbered alternative starting at `-2`, and notify the user of the packet-name → directory-name mapping. Never silently overwrite.
+- If it points to the **same** packet name, it is not a collision but a re-export: update the drafts in that same directory in place.
+
+## Intent propagation (carry it into the deliverables OpenSpec generates)
+
+- State the **parent intent** in the proposal's `## Why` and the **invariants** in `## Impact`, passing them in a structure that is easy to take into the deliverables (spec / design / tasks) OpenSpec generates.
+- Render the compass's **Invariants** into OpenSpec's **normative statements (SHALL / MUST)** and the constraints of `## Impact`. When an invariant is relevant to a delta's `### Requirement:`, seed that constraint as a normative statement there too.
+- Aim: that parent intent and invariants keep working even at the stage of moving from an OpenSpec change to implementation, so that local-optimum prevention does not evaporate via OpenSpec either.
+- **Responsibility boundary**: intent-planner's responsibility goes only as far as "propagating parent intent / invariants **through the structure of what is passed alone**". Do not intervene in OpenSpec's internal implementation. The actual incorporation is left to OpenSpec (do not depend on OpenSpec's behavior). Complete incorporation is **not a guarantee, but a probability maximized by structure**.
+
+## Invariants
+
+- Do not complete **the main body** of OpenSpec's proposal / delta spec (drafts / hint skeleton only). Completing the delta is left to `/opsx:propose` onward (INV4).
+- The proposal's `## Why` / `## Impact` must always include references to parent intent and invariants.
+- Do not quote/transcribe other packets or the Intent Tree body into the deliverables (limit sources to the target packet + compass).
+- **Never write into another packet's directory** (write only under the target packet's slug directory).
+- Do not intervene in OpenSpec's skills / internal implementation. Confine output to `.intent/openspec/` and do not touch `.intent/cc-sdd/`.

package/templates/en/claude/skills/intent-from-spec/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: intent-from-spec
+description: Inward ingestion skill that reads a user-provided natural-language spec (PRD / design spec / feature spec / issue / user story) read-only, extracts unstated intent candidates, surfaces silence as gaps against the existing rulers, qualitatively prioritizes by load-bearing, and presents an omission recap. All extractions are Assumptions (hypotheses); output is limited to derived artifacts under `.intent/spec-ingest/` and never modifies any canonical artifact.
+allowed-tools: Read, Glob, Grep, Write
+argument-hint: The natural-language spec text to ingest (a file path or pasted body)
+---
+
+# intent-from-spec Skill
+
+## Core Mission
+- **Success Criteria**:
+  - Reads the user-provided natural-language spec (a general development spec text such as a PRD / design spec / feature spec / issue / user story) read-only, and extracts intent candidates for purpose, outcomes, capabilities, invariants, constraints, anti-direction, and implicit assumptions. Marks all extracted candidates as Assumptions (inferred intent) and never mixes them with canonical (confirmed intent) (R1.1 / R1.2)
+  - Does not use source code, execution traces, or test results as extraction input. Input is limited to the user-specified natural-language spec text (R1.4)
+  - Picks up the must-hold constraints contained in the spec (technical / security requirements) without dropping them, as Compass Invariants candidates, and limits their destination to Invariants (reflection into steering (tech.md) / design is delegated downstream. R1.5 / R1.6)
+  - When no spec text is provided as input, performs no extraction, asks the user for the spec to ingest, and stops (fail-fast. R1.3)
+  - Reads the existing rulers (the inspection catalog in `validate-checks.md` and the common-core slots in `decision-slots.md`) against the spec, and enumerates the unfilled items as gaps. Shows in an observable form which category / slot each gap is the silence of, and presents it as a hypothesis rather than a confirmed defect (R2.1 / R2.2 / R2.3)
+  - While presenting gaps, does not stop processing; limits itself to warnings / awareness (same stance as drift-watch. R2.4)
+  - Qualitatively sorts the extractions / gaps by load-bearing (whether their loss would damage the correctness of what follows), and presents high items distinctly from low. The judgment merely reads and copies the "front-load / defer door" column in `decision-slots.md`, and holds no mathematical solver, numeric score, or threshold (R3.1 / R3.2 / R3.3)
+  - Summarizes "what was checked (presenting the frames) and what was left unfilled" as an omission recap, prompting reconfirmation (R4.1)
+  - Treats only approved items as candidates to load onto the canonical Intent structure, and retains unapproved items as Assumptions without discarding them. Performs no auto-reflection into canonical; promotion is delegated to the user's manual copy (R4.2 / R4.3 / R4.4)
+  - Limits output to derived artifacts under `.intent/spec-ingest/`, and never modifies any canonical `.intent/*.md`, application code, or the input spec (read-only. R5.2). Follows the `intent-*` naming convention and does not modify external spec tools or the kiro-* development environment (R5.6)
+
+## Execution Steps
+
+### Step 1: Confirm the input (natural-language spec text) exists (fail-fast)
+- When the user runs `/intent-from-spec`, first confirm whether the natural-language spec text to ingest (a file path or pasted body) is provided.
+- If no spec text is provided, **write nothing**, state the absence of the input explicitly, ask the user to provide the spec to ingest (a path or pasted body), and stop (fail-fast. R1.3). Do not write anything under `.intent/spec-ingest/` at this point.
+- Do **not** use source code, execution traces, or test results as extraction input. Recovering intent from those is a separate path handled by behavior-unknown mode's code→Intent, outside this skill's scope (R1.4).
+- The ruler sources of truth (`intent-validate/rules/validate-checks.md` / `intent-packets/rules/decision-slots.md`) and the canonical `.intent/*.md` (intent-tree / compass / mode, if present) are referenced read-only in later steps. Do not stop if absent (state the absence for anything that cannot be linked).
+
+### Step 2: Delegate to the four rules to extract, check, sort, and recap
+- This skill has no extraction / checking / judgment / scoring logic of its own. The exact reading, transcription, and linking rules for each concern are delegated to the following four rules (referenced by relative path). Follow the exact headings, transcription destinations, and ID systems each rule specifies; mark all extracted candidates as Assumptions; only read the rulers without reimplementing them; and state gaps and unobserved areas explicitly without filling them in by guessing.
+- `rules/extract-intent.md` — reads the spec text and extracts intent candidates across the seven categories of purpose / outcomes / capabilities / invariants / constraints / anti-direction / implicit assumptions. Marks all candidates as Assumptions and writes each out with a heading and granularity whose transcription destination (intent-tree's L0–L4 Assumptions / compass's Invariants, Anti-direction, Decision Rules) is uniquely determined. Picks up the must-hold constraints such as technical / security requirements without dropping them, as compass Invariants candidates, and limits their destination to Invariants (reflection into tech.md / design is not included in the output = delegated downstream. R1.1 / R1.2 / R1.4 / R1.5 / R1.6 / R5.1).
+- `rules/gap-readout.md` — **reads** the stable kebab-case inspection IDs in `validate-checks.md` and the common-core 8 slot IDs in `decision-slots.md`, and enumerates the items unfilled against the input spec as gaps. Shows which ruler's silence each gap is (ID linking) and which category / slot's silence it is (observable evidence), and presents it as a hypothesis rather than a confirmed defect. Defines no new inspection IDs / slot IDs of its own. Since spec-ingest is a proposer, not an acceptance gate, it **may infer** slot applicability from the spec's silence **but does not confirm** (a different posture from validate). Does not stop processing; warnings only (R2.1 / R2.2 / R2.3 / R2.4).
+- `rules/load-bearing.md` — for the gaps / intent candidates that gap-readout linked to slot IDs, qualitatively sorts high/low by merely reading and copying the **"front-load / defer door" column** in `decision-slots.md`. "Front-load" = high (dangerous if it falls), "deferrable" = low. Holds no mathematical solver, numeric score, or threshold, and invents no new discriminating axis. Items that cannot be linked to a slot ID are stated as load-bearing-unknown (absence). Presents high distinctly observable from low, and retains low without discarding it (R3.1 / R3.2 / R3.3).
+- `rules/omission-recap.md` — summarizes as a list "the frames checked (what was read) / the filled areas / the unfilled areas (silence) / the areas that could not be checked (absence)", avoiding the "silence of silence" (the omission error where the AI hints at completeness and the human stops searching). Cites the existing IDs that gap-readout linked, without redefining them. Treats only approved items as candidates for canonical promotion, retains unapproved items as Assumptions, and guides that promotion is a manual copy in which the user carries approved items by hand into the discover / compass dialogue (no machine handoff. R4.1 / R4.2 / R4.3 / R4.4).
+
+### Step 3: Write the derived view to `.intent/spec-ingest/` last (full replacement, derived)
+- Only after all extraction, checking, sorting, and recap are complete, **last** write `.intent/spec-ingest/spec-ingest.md` by **full replacement** (idempotent regeneration). Never write to any canonical `.intent/*.md` (intent-tree / compass, etc.), steering (tech.md), design, or the input spec.
+- In the view header, declare that this view is derived / regenerable, not the source of truth, and Git-untracked, and that all intent candidates / gaps / load-bearing levels described are Assumptions (hypotheses) and remain provisional until the user's approval (R1.2).
+- Compose the output per extract-intent's transcription-destination headings, at a granularity the user can copy 1:1 into intent-tree's Assumptions / compass's blocks (keeping the promotion seam manual).
+
+## Output Description
+- `.intent/spec-ingest/spec-ingest.md` (derived, regenerable, Git-untracked; the view header declares it is not the source of truth and that all items are Assumptions). Its content includes:
+  - **Intent candidates (extraction)**: per extract-intent's output contract, presents purpose / outcomes / capabilities candidates (→ intent-tree L0–L4 Assumptions), Invariants candidates (→ compass Invariants, including technical / security constraints), Anti-direction candidates (→ compass Anti-direction), and implicit-assumption candidates (→ intent-tree Assumptions / compass Decision Rules), with headings whose transcription destination is uniquely determined. Each candidate carries its extraction basis (from which spec description / silence).
+  - **Gaps (silence)**: enumerates as hypotheses the gaps that gap-readout linked to IDs in `validate-checks.md` / `decision-slots.md`, together with which category / slot's silence each is.
+  - **Load-bearing sorting**: presents high items distinctly from low (e.g. grouping high at the top). Items that cannot be linked to a slot are stated as load-bearing-unknown.
+  - **Omission recap**: a list of the frames checked / filled areas / unfilled areas / areas that could not be checked, plus promotion guidance for the user to transcribe approved items by hand into discover / compass.
+- Categories / axes without source material are stated as "no relevant description (silence) / unobserved" and omitted (never filled in by guessing).
+
+## Safety & Fallback
+- **Write boundary**: writes are limited to under `.intent/spec-ingest/`. The canonical `.intent/*.md` (intent-tree / compass / mode, etc.), the ruler sources of truth (`validate-checks.md` / `decision-slots.md`), steering (tech.md), design, and the input spec are read-only — never created, modified, or deleted there (the `Write` in the frontmatter is permitted solely for writing under `.intent/spec-ingest/`. R5.2).
+- **Gaps are hypotheses (warnings only — never stop)**: gaps, load-bearing levels, and intent candidates are all Assumptions (hypotheses), not confirmed defects / severities. While presenting them, never stop processing; limit to warnings / awareness (same stance as drift-watch. R2.3 / R2.4).
+- **Approval gate — promotion is manual**: reflection into canonical requires the user's explicit approval. Treat only approved items as candidates for canonical promotion, and retain unapproved items as Assumptions without discarding them. Perform no auto-reflection into canonical. Promotion is a manual copy in which the user carries approved items by hand into the discover / compass dialogue; spec-ingest does not call discover / compass, and discover / compass do not auto-read spec-ingest's output (no machine handoff = no hidden shared ownership. R4.2 / R4.3 / R4.4).
+- **Does not reimplement the rulers**: never runs inspections / slot verification of its own; only reads the ID catalogs in `validate-checks.md` / `decision-slots.md` and the "front-load / defer door" column. Holds no inspection IDs / slot IDs / scoring / weighting engine of its own.
+- **Zero external dependencies** (INV2 / R5.3). Introduces no external package, AST parser, or mathematical solver; limited to Node standard and natural-language heuristics, completing extraction within a natural-language workflow.
+- **Does not modify application code** (R5.2). In the intent-planning phase, modifies neither application code nor the input spec (read-only).
+- **Naming / no external modification**: follows the `intent-*` naming convention and does not modify external spec tools or the kiro-* development environment (R5.6).
+- **When prerequisites are absent**: when no input spec text exists, write nothing, state the absence, ask the user to provide the spec to ingest (a path or pasted body), and stop (fail-fast. R1.3).
+- **On partial gaps**: for any of the seven categories the spec is silent on, gaps that cannot be linked to the ruler catalogs, and items that cannot be linked to a slot and are load-bearing-unknown, state the area explicitly as "no relevant description (silence) / absent / unknown" and omit it (never fill in by guessing).

package/templates/en/claude/skills/intent-from-spec/rules/extract-intent.md

@@ -0,0 +1,56 @@
+# Intent Candidate Extraction Procedure (read-only; all candidates are Assumptions)
+
+The single source of truth by which the `intent-from-spec` skill reads the natural-language specification text the user provides (PRDs, design specs, feature specs, issues, user stories, and other general development specifications) and extracts candidates for intent that is not stated explicitly. SKILL.md holds only the procedure and report format; "what to read under which category, and toward which transcription destination to write it out" is governed by this rule. This rule only **reads** the specification; it does not modify the input specification, the canonical `.intent/*.md`, steering (tech.md, etc.), or the design at all (writes go only under `.intent/spec-ingest/`).
+
+## posture (a proposer, not an adjudicator)
+
+What this rule performs is **extraction (proposal)** by the heuristics of LLM judgment, not certification of confirmed intent. Every extracted candidate is a **hypothesis (Assumption)** and is treated as provisional until the user confirms and approves it. Processing does not stop; it stays at presenting warnings and observations (consistent with the product invariant that inferred intent is treated as provisional until a human reviews it). Therefore this rule **may infer** slot applicability from the specification's statements and silences, **but does not finalize** it.
+
+## Input boundary (fixed)
+
+- Input is **limited** to the natural-language specification text the user designates (path reference or paste).
+- **Source code, execution traces, and test results are not used as input for intent extraction.** Recovering intent from those is a separate path handled by the code→Intent of behavior-unknown mode, and is out of scope for this rule.
+- When no input is given, perform no extraction and ask the user for the specification to be supplied (write nothing).
+
+## Candidate categories to extract (7 kinds; all Assumptions)
+
+Read the specification text and extract candidates in the following 7 categories. For each candidate, attach the extraction basis (which statement or which silence in the specification it was derived from). **Mark every extracted candidate as an Assumption (inferred intent) and do not mix it with canonical (confirmed intent).**
+
+1. **Purpose** — what this product/feature exists for.
+2. **Desired Outcomes** — the state changes one wants to cause for users, business, operations, and developer experience.
+3. **Capabilities** — the responsibilities/capabilities that support the outcomes (as capabilities, not feature names).
+4. **Invariants** — behavior, APIs, data, UX, and operational constraints that must never be broken. Includes "constraints to be upheld" such as technical and security requirements.
+5. **Constraints** — technical/security/operational requirements and preconditions to be upheld.
+6. **anti-direction** — directions one must not proceed in; local optima to avoid.
+7. **Implicit Assumptions** — matters the specification presupposes without stating them, and the judgments derived therefrom.
+
+> Constraints to be upheld, such as technical and security requirements, are **not dropped**, whether stated explicitly or implicit. Pick these up reliably into the Invariants category and write them out as the Invariants candidates in the output contract below.
+
+## output contract (write out under headings whose transcription destination is uniquely determined)
+
+Write each candidate at a heading and granularity that lets a person transcribe it 1:1 to its destination. Make the headings correspond uniquely to the destinations in the table below. The responsibility of this rule extends only to **writing out** the candidates; reflecting them into destinations (the canonical intent-tree / compass, and steering / design) is not performed here. Promotion occurs when the user manually carries approved candidates into the discover / compass dialogue (there is no machine handoff).
+
+| Extraction category | Heading to write out | Destination (by hand; not reflected by this rule) |
+|---|---|---|
+| Purpose | `### Purpose candidates (→ intent-tree L0 Assumptions)` | intent-tree `## Assumptions` (corresponding to L0: Product Purpose) |
+| Desired Outcomes | `### Outcome candidates (→ intent-tree L1 Assumptions)` | intent-tree `## Assumptions` (corresponding to L1: Desired Outcomes) |
+| Capabilities | `### Capability candidates (→ intent-tree L2 Assumptions)` | intent-tree `## Assumptions` (corresponding to L2: Capabilities) |
+| Invariants | `### Invariants candidates (→ compass Invariants)` | compass `## Invariants` |
+| Constraints | `### Constraint candidates (→ compass Invariants)` | compass `## Invariants` |
+| anti-direction | `### Anti-direction candidates (→ compass Anti-direction)` | compass `## Anti-direction` |
+| Implicit Assumptions | `### Implicit-assumption candidates (→ intent-tree Assumptions / Decision Rules)` | intent-tree `## Assumptions`, and judgments derived from the assumptions become compass `## Decision Rules` candidates |
+
+- **Purpose, Outcomes, and Capabilities** are written at a granularity that can be transcribed 1:1 into the corresponding L0–L4 level `## Assumptions` items of the intent-tree (do not write into the canonical L0–L4 body).
+- **anti-direction** is written at a granularity transcribable into the compass `## Anti-direction` block.
+- **Judgments derived from implicit assumptions** are written out as compass `## Decision Rules` candidates (candidates, not finalized ADRs).
+- **Invariants and Constraints (constraints to be upheld, including technical/security requirements) are written out as candidates for the compass `## Invariants` block.** The destination of Invariants candidates is **limited** to the compass Invariants.
+
+## Downstream delegation (what not to include in output)
+
+- Reflecting Invariants candidates into steering (tech.md) or design is handled by the existing flows (writeback / export / by hand). **Reflection into tech.md / design is not included in the output of this rule.** The responsibility of this rule stays at recording them as Invariants candidates under headings bound for the compass, preserving a single source of truth.
+- Writing into the canonical intent-tree / compass is also not performed (promotion is by hand, after approval).
+
+## Handling of omissions / non-observation
+
+- Among the 7 categories, those on which the specification is silent are not filled in by guessing but stated explicitly as "no corresponding statement (silence)." Treating silence itself as a gap is the responsibility of the gap-readout side; this rule presents, distinctly, the candidates it could extract and the absence of categories it could not extract.
+- All outputs are made explicit as derived, regenerable, and not the source of truth. Nothing is written back to canonical.

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

@@ -0,0 +1,54 @@
+# Silence Gap Readout Procedure (read-only; only reads the rulers; gaps are hypotheses)
+
+The single source of truth by which the `intent-from-spec` skill holds the existing rulers up against the natural-language specification the user provides and surfaces the places where the specification is **silent** as gaps. SKILL.md holds only the procedure and report format; "which rulers to read and how, and which category/slot silence to bind them to" is governed by this rule. This rule only **reads** the rulers' catalogs; it does not define its own check IDs or slot IDs. The source of truth for the decision logic lives in the references, and this rule merely borrows that ID system as a vessel and sorts into it the items the specification fails to satisfy. Observation is limited to Read / Glob / Grep, and it does not modify the input specification, the canonical `.intent/*.md`, or the rulers' sources at all (writes go only under `.intent/spec-ingest/`).
+
+## posture (a proposer, not an accept/reject gate)
+
+State this rule's posture at the top. It is a **different posture** from the adjacent `intent-validate`, and is not a contradiction.
+
+- `intent-packets/rules/decision-slots.md` rules that "a tool (the slot validator) must not infer slot applicability from artifact content." That is because `intent-validate` is an **accept/reject gate (an adjudicator)** — if an adjudicator infers applicability from content, it produces unjust verdicts that stop or pass work on matters that were never declared.
+- `intent-from-spec` is a **proposer**, not an adjudicator. Its output is not an accept/reject verdict but **Assumptions (hypotheses)** that require human confirmation.
+- Therefore, with this rule, **spec-ingest may infer slot applicability from the specification's silences, but does not finalize it.** validate is forbidden from inferring because it is an adjudicator; for this rule, a proposer, to infer is not an exception to that discipline — it stands on a different posture from the start.
+- Every inferred applicability is marked as a hypothesis and treated as provisional until the user confirms and approves it (consistent with the product invariant that inferred intent is treated as provisional until a human reviews it).
+
+## Rulers to read (reference IDs; do not define them)
+
+This rule **reads** the ID catalogs of the following two existing sources of truth. The ranges, firing conditions, and severities of the IDs are owned by the references; this rule does not duplicate or redefine them ("the table is canonical").
+
+1. **The check catalog table in `intent-validate/rules/validate-checks.md`** — read the stable kebab-case ID set in the `ID` column (`invariant-conflict` / `anti-direction-violation` / `requirements-smell` / `decision-slot-empty` / `decision-slot-unsown`, and so on) and the severity-guideline column. Adding or changing checks is owned by that table, and this rule cites the ID column as-is (it does not re-derive them).
+2. **The common-core slot table in `intent-packets/rules/decision-slots.md`** — read the 8-slot ID set sown in all modes (`decision-consistency` / `decision-idempotency` / `decision-error-semantics` / `decision-authz` / `decision-quality-priority` / `decision-fit-criterion` / `decision-exception-flow` / `decision-downstream-trace`). The slots' classifications and closing destinations are owned by the reference, and this rule cites those IDs as-is.
+
+> This rule **never defines new** check IDs or slot IDs of its own. It creates no IDs absent from the catalogs above and sorts observed gaps into the existing IDs.
+
+## Gap-enumeration procedure
+
+Once intent-candidate extraction (extract-intent) is complete, read the catalogs above and, holding them up against the input specification, enumerate the **items that go unfilled** as gaps. Each gap shows the following three points in an observable form.
+
+1. **Which ruler's silence** — make explicit which it corresponds to among the stable kebab-case IDs of `validate-checks.md` or the common-core slot IDs of `decision-slots.md` (bind referenceable ones to an ID, and for ones that cannot be bound, omit the ID and state the absence explicitly).
+2. **Which category/slot silence** — show which absence in the specification (which check classification, which slot) the gap corresponds to, together with observable evidence (which part of the specification is silent).
+3. **Presentation as a hypothesis** — present it not as a confirmed defect but as a **hypothesis** the user should confirm ("there is a suspicion that the specification is silent on this item"). Do not certify confirmed defects.
+
+### Examples of binding (IDs are cited from the reference catalogs)
+
+- The specification is silent on the consistency model at data change → bind it as silence of the `decision-consistency` slot of `decision-slots.md` and present as a hypothesis.
+- The specification is silent on the return contract for abnormal input → silence of the `decision-error-semantics` slot.
+- The specification is silent on access rights / the executing actor → silence of the `decision-authz` slot.
+- Vague, subjective, or comparative wording remains in the requirement statements → bind to `requirements-smell` of `validate-checks.md`, quote it, and leave it to the user's judgment (do not write paraphrases back into the source of truth).
+- A statement in a direction that could conflict with the compass Invariants → `invariant-conflict`; a statement in a direction to be avoided → bind to `anti-direction-violation` and present as a hypothesis.
+
+> All of the above are examples, not the definitions of the IDs themselves. The ranges, firing conditions, and severities are owned by the reference catalogs.
+
+## Do not stop processing (warn only; same stance as drift-watch)
+
+- Even while presenting gaps, do **not stop** processing. Because this rule is not an accept/reject gate, the existence of a gap does not stop work or what follows; it stays at presenting warnings and observations (consistent with drift-watch's "warn only; do not stop" stance).
+- Every enumerated gap is a hypothesis and is held as an Assumption until the user confirms and approves it. It is neither approved nor rejected, and not discarded.
+
+## Avoid the "silence of silence" (also show what was checked)
+
+- Beyond showing each gap, also present **what was checked (the frame of the rulers read)** to avoid the error of omission caused by the checked frame itself being invisible (summarizing the checked frame and the places that went unfilled is the responsibility of omission-recap, but this rule too makes "which vessel it was held up against" observable by stating the ID system it bound to).
+- For places that cannot be referenced (no corresponding ID exists in the catalog; the ruler does not hold that viewpoint), do not fill in by guessing; **omit** the binding to an ID and state the absence explicitly.
+
+## Handling of output
+
+- All outputs are derived, regenerable, and not the source of truth. Nothing is written back to the canonical intent-tree / compass (promotion is by hand, after approval).
+- This rule does not modify the rulers' sources of truth (`validate-checks.md` / `decision-slots.md`) at all. It does not run checks or slot validation itself; it merely goes and reads the ID catalogs.

package/templates/en/claude/skills/intent-from-spec/rules/load-bearing.md

@@ -0,0 +1,48 @@
+# load-bearing Sorting Procedure (read-only; only reads the table; holds no numbers)
+
+The single source of truth by which the `intent-from-spec` skill qualitatively prioritizes the extracted intent candidates and surfaced gaps by "whether they are of a kind that, if dropped, damages the correctness of what follows (whether they are load-bearing)," and presents items with a high load-bearing degree in a form distinguishable from low ones. SKILL.md holds only the procedure and report format; "what to read as the discriminating axis and how to sort into high/low" is governed by this rule. This rule does **not invent** a new discriminating axis; it merely **reads and copies** a column of an existing source of truth. Observation is limited to Read / Glob / Grep, and it does not modify the input specification, the canonical `.intent/*.md`, or the rulers' sources at all (writes go only under `.intent/spec-ingest/`).
+
+## The discriminating axis is a read-the-table operation, not a fresh judgment
+
+The core of this rule comes down to "**reading and copying an existing column of `decision-slots.md`**." It does not define or derive the high/low axis in this rule, and it holds no mathematical solver, numeric score, or threshold whatsoever. Sorting is a table-citing operation, not the performing of new weighting or scoring.
+
+- The load-bearing degree per slot is already written in the **"front-load / defer door" column** of `intent-packets/rules/decision-slots.md`. This rule reads that column as the **primary discriminating axis**.
+- That column **exists in all of** the common-core slot table and every mode-specific delta table (standard / refactor / behavior-unknown / feature-growth) of `decision-slots.md`. Therefore, whichever slot is cited, that column can be read unambiguously.
+- The "rationale" column **exists only in the common-core table**. So it is not made the primary key of discrimination; it is used only as material to **supplement the explanation** of why something was judged high (borrowing only the wording for why dropping it is dangerous, while the high/low discrimination itself is performed on the "front-load / defer door" column).
+
+## The column read and the high/low correspondence
+
+Copy the value of the "front-load / defer door" column of `decision-slots.md` as-is, as follows.
+
+| Value of the "front-load / defer door" column | load-bearing degree | Meaning |
+|------------------------------------------------|---------------------|---------|
+| front-load (one-way; irreversible; floor of security / legal regulation) | **high** | Overturning it later has large external impact, and if dropped it damages the correctness of what follows. Silence on it is dangerous |
+| deferrable (two-way; localizable and reversible) | **low** | It can be re-decided in both directions and is reversible, and can be patched locally later. Even if silent, it is unlikely to directly break what follows |
+
+- Silence on a slot whose column value begins with "front-load" is **high**, and silence on a slot whose value begins with "deferrable" is **low**. No further gradation (intermediate values, numbers) is introduced in this rule.
+- The parentheticals of "front-load" / "deferrable" (one-way/two-way, irreversible/reversible, floor of security / legal regulation, and so on) are the places where the table itself explains why that high/low is read so, and this rule cites that wording as-is for the reason of presentation (it does not redefine it).
+
+### Examples of copying (values are cited from the reference table)
+
+- `decision-authz` (authorization) is "front-load (one-way: floor of security / legal regulation)" → silence is **high**. As the reason, append "irreversible; security floor" from the common-core table's "rationale" column as a supplement.
+- `decision-consistency` (consistency model) is "front-load (one-way: overturning it later has large external impact)" → silence is **high**.
+- `decision-error-semantics` (error semantics) is "deferrable (two-way)" → silence is **low**.
+- `decision-data-migration` (data migration; feature-growth) is "front-load (one-way: irreversible)" → silence is **high**.
+
+> All of these are examples of copying the values of the reference table, not re-adjudication in this rule. If a value changes, the reference table is canonical, and this rule merely follows and re-reads it.
+
+## Application to gaps and intent candidates
+
+- For a gap that gap-readout bound to a slot ID of `decision-slots.md`, cite the "front-load / defer door" column of that slot row and attach high/low. For a gap that cannot be bound to a slot ID (one for which the catalog has no corresponding column), do not attach high/low by guessing; state the absence explicitly as **load-bearing unknown**.
+- For intent candidates too (invariants, constraints, anti-directions, etc. that extract-intent picked up), if there is a corresponding slot, cite that row's column and attach high/low. In particular, Invariants candidates derived from technical / security requirements often fall on "front-load" slots such as `decision-authz`, and lean toward **high**.
+- Both high and low are **hypotheses, not confirmed severities**. They are held as Assumptions until the user confirms and approves them, and this rule's sorting neither discards nor finalizes any item.
+
+## Present high and low distinguishably
+
+- In presentation, distinguish high items from low ones in an **observable** way (e.g., grouping high ones at the top, attaching an explicit label, and so on). Do not pour all gaps out equally; let the user address the dangerous-if-dropped ones first.
+- Distinction stays at labeling and does not cut low ones away. Low ones too are held as Assumptions and included in omission-recap's re-confirmation scope.
+
+## Handling of output
+
+- All outputs are derived, regenerable, and not the source of truth. Nothing is written back to the canonical intent-tree / compass (promotion is by hand, after approval).
+- This rule does not modify the rulers' source of truth (`decision-slots.md`) at all. It holds no scoring or weighting engine of its own; it merely goes and reads the "front-load / defer door" column.

package/templates/en/claude/skills/intent-from-spec/rules/omission-recap.md

@@ -0,0 +1,42 @@
+# omission recap Procedure (summarize what was checked and what went unfilled, and prompt re-confirmation)
+
+The single source of truth by which the `intent-from-spec` skill, after finishing extraction (extract-intent), readout (gap-readout), and qualitative sorting (load-bearing), summarizes **what was checked (presenting the frame) and what went unfilled** for the user and prompts re-confirmation. SKILL.md holds only the procedure and report format; "how to summarize the checked frame, how to hold unapproved items, and how to guide promotion of approved items" is governed by this rule. This rule defines no new checks or slots; it **summarizes as-is** the frame of the existing ID system (`validate-checks.md` / `decision-slots.md`) that gap-readout bound to. Observation is limited to Read / Glob / Grep, and it does not modify the input specification, the canonical `.intent/*.md`, or the rulers' sources at all (writes go only under `.intent/spec-ingest/`).
+
+## Why a recap is needed (avoid the "silence of silence")
+
+State this rule's purpose at the top. Whereas the adjacent gap-readout "shows each gap," this rule bears the role of "**summarizing, as a list, the checked frame itself and the places that went unfilled.**"
+
+- Merely showing each gap individually does not let the user see **how far the AI checked**. When the checked frame itself is invisible, the user jumps to the conclusion that "it is already covered" and stops their own search. This is the "**silence of silence**" (an error of omission / automation bias in which the human stops searching because the AI implied completeness).
+- To avoid this, the recap **explicitly presents the frame of the rulers that were checked**. It lists "which rulers were read (the check catalog of validate-checks, the 8 slots of decision-slots), and of those which were filled, which were silent, and which could not be checked," and shows the very outline of the inspection to the user.
+- Beyond the silences, it also makes explicit the **places that could not be checked** (no corresponding ID exists in the catalog; the ruler does not hold that viewpoint). It does not fill them in by guessing; it leaves absence as absence. Not claiming coverage is itself a responsibility of the recap.
+
+## What the recap summarizes
+
+Receiving the output of extract-intent, gap-readout, and load-bearing, it lists the following in an observable form. In every case it cites as-is the existing IDs that gap-readout bound to, and does not re-derive or redefine them.
+
+1. **The checked frame (what was read)** — present the rulers read (the check catalog of `validate-checks.md`, the common-core 8 slots of `decision-slots.md`) and show the outline of the inspection.
+2. **The places that were filled (items the specification answered)** — show the frames the specification answered, making it observable that the recap did not "pick up only silences."
+3. **The places that went unfilled (silences)** — list the gaps gap-readout enumerated, together with the bound IDs. Record the qualitative sorting of load-bearing (high / low) in a distinguishable form alongside.
+4. **The places that could not be checked (absence)** — make explicit, without filling in by guessing, the places where there is no bound ID and judgment was withheld, as absence.
+
+## Approval gate (only approved items are promoted to canonical)
+
+The recap is a presentation to prompt re-confirmation, not a finalization. Reflecting anything into canonical requires the user's explicit approval.
+
+- Only when the user **confirms and approves** an item is that item made a target for placement onto the canonical intent structure (the intent-tree / compass Invariants, Anti-direction, Decision Rules) (Req 4.2).
+- Items that have not gone through the user's confirmation are **not automatically reflected** into canonical (Req 4.3). At the moment the recap presents them, every item is still a hypothesis.
+- Items that were not approved are **not discarded but held as Assumptions** (Req 4.4). This is a hold, not a rejection, and they remain in the derived area (`.intent/spec-ingest/`) for re-confirmation on later occasions.
+
+## Promotion is a human copy (it holds no machine handoff)
+
+This is the crux of this feature's boundary, and not stating it would create hidden shared ownership.
+
+- spec-ingest's output is **derived and regenerable**, not the canonical source of truth. spec-ingest merely writes out approved candidates into the derived area in a "**transcribable form**."
+- Promotion to canonical is done by a **human copy in which the user carries approved items by hand into the discover / compass dialogue**. spec-ingest **does not call** discover / compass, and discover / compass **do not automatically read** spec-ingest's output. No automatic linkage (machine handoff) exists between them.
+- Therefore the recap presents a **guide**: "please transcribe the items you approved, yourself, into the discover / compass dialogue." The recap itself never performs promotion. By writing out with headings and granularity that can be copied 1:1 into the transcription destination (the Assumptions of the intent-tree / each block of the compass), it makes the human transcription easy (keeping the seam of promotion in human hands).
+- Through this separation, no double source of truth between the derived (spec-ingest) and the canonical (intent-tree / compass) is created, and the overlap of ownership (hidden shared ownership) is avoided.
+
+## Handling of output
+
+- All outputs are derived, regenerable, and not the source of truth. Nothing is written back to the canonical intent-tree / compass (promotion is by hand, after approval).
+- This rule does not modify the rulers' sources of truth (`validate-checks.md` / `decision-slots.md`) at all; it merely summarizes the output of gap-readout and load-bearing. It does not run checks or slot validation itself.

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

@@ -0,0 +1,70 @@
+---
+name: intent-improve
+description: After implementation, cross-check the .intent/ deliverables against the implementation reality on the three axes of completeness / correctness / coherence, classify the drift, and propose corrections. Reflects changes only after user approval. Guides missed write-backs to /intent-writeback.
+disable-model-invocation: true
+allowed-tools: Read, Write, Glob, Grep, AskUserQuestion
+argument-hint: <target scope (optional)>
+---
+
+# intent-improve Skill
+
+## Core Mission
+- **Success Criteria**:
+  - The `.intent/` deliverables and the implementation reality (codebase, tests, cc-sdd spec progress) are evaluated on the three axes (completeness / correctness / coherence)
+  - The evaluation results are presented in the 5 classifications (aligned / intent reinforcement recommended / corrective packet recommended / Decision Rules update recommended / invariant violation detected), with evidence (file / relevant text)
+  - Only the corrections the user approved are reflected into `.intent/` (the approval unit is per proposal)
+  - When an unrecorded write-back learning is detected, the skill does not write a delta itself but prompts the user to run `/intent-writeback`
+  - On a run whose 5 classifications include `Decision Rules update recommended` or `invariant violation detected`, following the provisions of `rules/improve-axes.md`, it also prompts the user to run `/intent-validate` (the check for conformance catch-up) (on a run that does not include them, it does not prompt; it only guides and does not itself make a conformance judgment)
+  - When drift-watch is on, the coherence detections are recorded into drift-log as stage:improve / outcome:missed and a pattern×outcome improvement report is presented (when off / missing / invalid / missing section / missing mode.md, nothing is done; the 5 classifications are unchanged)
+  - When drift-watch is on, context-cost-cues are matched and ways of progressing that eat context are named in a noticing tone (recorded to no log, not included in the pattern×outcome tally, the 5 classifications unchanged; when off, nothing is done)
+  - No application code has been changed at all
+
+## Execution Steps
+
+### Step 1: Collect the current state
+- Read the `.intent/` deliverables (intent-tree.md / intent-compass.md / `.intent/packets/index.md` + the packet files under active/ (cross-cutting read for the completeness axis; do not read archive/) / the per-packet drafts under `cc-sdd/<slug>/` / deltas.md). If `.intent/` is absent, guide the user through setup (installing intent-planner and running `/intent-discover`) and stop.
+- Read `.intent/mode.local.md` (falling back to `.intent/mode.md` if absent) for the mode state. If both are absent, continue with the standard default and announce it.
+- Collect the implementation reality: the codebase (read-only via Read/Glob/Grep), the presence and placement of tests, the progress of `.kiro/specs/` (only if it exists), and the promoted / pending entries of deltas.md.
+- If `.kiro/` is absent, continue without cc-sdd context. If deltas.md is absent, continue treating it as "no delta records" (non-blocking).
+- If a target scope is specified by argument, narrow down to it; otherwise target the whole of `.intent/`.
+
+### Step 2: Evaluate on the three axes
+- Read `rules/improve-axes.md` and cross-check `.intent/` against the implementation reality on the three axes of completeness / correctness / coherence.
+- Always attach evidence (file / relevant text) to the evaluation. Do not present an evaluation whose evidence cannot be shown.
+
+### Step 3: Classify and report
+- Classify the evaluation results into the 5 classifications (aligned / intent reinforcement recommended / corrective packet recommended / Decision Rules update recommended / invariant violation detected; multiple may apply) and present them organized per classification.
+- When unrecorded write-back learnings or declined items with the "on-hold" tag are detected, also include guidance to `/intent-writeback` following the provisions of `rules/improve-axes.md`.
+- On a run whose 5 classifications include `Decision Rules update recommended` or `invariant violation detected`, following the "Validate catch-up guidance" provisions of `rules/improve-axes.md`, also include guidance to `/intent-validate` (the check for conformance catch-up) alongside the writeback guidance (on a run that does not include them, do not include it; only guide and do not make the judgment yourself).
+- When drift-watch is on (when off / missing / invalid / missing section / missing mode.md, do nothing): check the `drift-watch` value in the `## Drift-watch (user-managed)` section of `.intent/mode.md`, and only when it is `on`, following the provisions of `rules/improve-axes.md`, record the drift detected on the coherence axis (invariant violation / anti-direction conflict) into `.intent/drift-log.md` as a `stage: improve` / `outcome: missed` draft, and present a `pattern × outcome` cross-tabulated improvement report. Delegate the recording details (the fixed 9-key order, append-only, obtaining commit, creating drift-log when absent) to `rules/improve-axes.md` (do not duplicate them here). This recording **does not create a new correction class** (the 5 classifications above are unchanged), and does not write into deltas.md or hook writeback. When off / missing / invalid / missing section / missing mode.md, do not record or aggregate drift and proceed as before (byte-equivalent to current behavior). Note that the report of the 5 classifications above is always done regardless of the drift-watch value. In addition, when `drift-watch: on`, following the "Context cost cues" section at the end of `rules/improve-axes.md`, match `.intent/context-cost-cues.md` and name, in a noticing tone, ways of progressing that eat context (**recorded to no log, not included in the pattern × outcome tally, and the 5 classifications stay unchanged**; skip if the catalog is absent).
+
+### Step 4: Confirm approval per proposal for the corrections
+- For each item that needs correction, present the correction proposal (a deliverable update proposal or a corrective packet proposal) and confirm the user's approval **per proposal** (do not force bulk approval).
+- Proposals that were not approved end as presentation only (do not rewrite).
+
+### Step 5: Reflect only the approved corrections
+- Reflect only the approved corrections into the canonical deliverables (intent-tree.md / intent-compass.md / under `.intent/packets/` (the target packet file / plan.md)).
+- When the canonical under `.intent/packets/` has been changed (including when a delta promotion is reflected into the target packet file), regenerate `.intent/packets/index.md` from the frontmatter under active/.
+- Corrections that change the Decision Rules follow the change convention of `rules/improve-axes.md` (add a new entry in ADR form + annotate the old entry as superseded with a reference to its successor and move it to `.intent/compass-archive/<rule-slug>.md` (a per-rule file)).
+- Do not write into deltas.md (recording deltas and finalizing declined-item tags are the responsibility of `/intent-writeback`).
+
+## Output Description
+
+**Reader**: a human developer who, after implementation, approves and corrects the drift between intent and implementation.
+**What this output makes them grasp first**: "**here is the drift between implementation and intent (invariant violations come first if any). There are N items pending approval.** If there is a missed write-back, go to `/intent-writeback`." The breakdown of the three-axis evaluation is detail for the decision.
+
+Lead the output with the conclusion (the drift and the pending approvals).
+
+- **Divergence summary (top)**: show the key points of the detected corrections by classification. If there is an `invariant violation detected`, lead with it as the top priority. If everything is `aligned` (no drift), state explicitly "aligned, no correction needed".
+- **Approval-pending list (next, per proposal)**: attach evidence (file / relevant text) to each correction proposal. Phrased so it is clear what gets reflected by approving what.
+- **Writeback guidance** (when applicable): when an unrecorded write-back learning is detected, guidance to run `/intent-writeback`.
+- **Validate catch-up guidance** (when applicable): on a run whose 5 classifications include `Decision Rules update recommended` / `invariant violation detected`, attach the guidance to run `/intent-validate` (the check for conformance catch-up) alongside the writeback guidance.
+- **Details**: the three-axis evaluation summary (completeness / correctness / coherence) and the breakdown by classification (aligned / intent reinforcement recommended / corrective packet recommended / Decision Rules update recommended / invariant violation detected).
+- **Improvement report** (when drift-watch=on): a report cross-tabulating drift-log by `pattern × outcome`. Always attach the honesty notes (`missed=0` is a suspicion of missing records / frequent `false-positive` suggests the anti-direction is too broad), align the aggregation keys to the type (pattern), and establish the group comparison (without group / with group) by the type id and the `commit` column of drift-log only (do not create an additional comparison mechanism).
+
+## Safety & Fallback
+- Do not rewrite the `.intent/` deliverables without user approval. Confirm approval per proposal.
+- Do not change application code (INV6. Code is read-only via Read/Glob/Grep).
+- Do not write into `.kiro/` (progress is read-only). The absence of `.kiro/` continues without cc-sdd context.
+- Do not write directly into deltas.md. Handling of missed write-backs and on-hold items is guidance to `/intent-writeback` only; the final updates are done by writeback.
+- The absence of `.intent/` guides the user through setup and stops. The absence of mode.md does not stop; continue with the standard default and announce it.