intent-planner 0.13.1

package/templates/en/agents/gemini/GEMINI.md

@@ -0,0 +1,62 @@
+# intent-planner (quickstart for Gemini CLI)
+
+intent-planner is a lightweight **Intent Planning layer** where the human and the agent align on "the overall intent" and "a unified design policy" **before** starting implementation. It prevents architectural drift — where each file looks fine on its own but the overall design intent slowly erodes — by stopping the agent from escaping into local optimization without a cross-cutting intent.
+
+This is not a full IDD framework; it is a pre-spec stage that sits **before** the spec-driven flow (cc-sdd). The intent worked out here is bridged into cc-sdd's requirements → design → tasks flow non-destructively and at low token cost.
+
+## Workflow
+
+Start from `/intent-discover` and run the following in order. Review each step's deliverable (Markdown under `.intent/`) before proceeding.
+
+1. `/intent-discover` — Build the Intent Tree (L0–L4), recommend/confirm the mode for working out the Intent, and confirm/record whether to delegate the designer-role questions (designer-questions)
+2. `/intent-compass` — Create decision criteria such as North Star / Anti-direction / Invariants
+3. `/intent-packets` — Decompose into work units (packets) before handing off to cc-sdd
+4. `/intent-export-cc-sdd` — Convert the chosen packets into cc-sdd drafts
+
+The four above are the "planning" phase. After export, the intent is not disposable; keep growing it as a cycle with the four maintain/anytime skills.
+
+- `/intent-status` — Anytime (when unsure). Recommend a summary of where you are plus exactly one "next move" (read-only)
+- `/intent-validate` — Before export (recommended). Report contradictions, coverage gaps, and boundary inconsistencies across deliverables with severity (read-only)
+- `/intent-writeback` — After a packet's implementation is done. Record the learnings gained from the implementation into `.intent/deltas.md` as deltas, and promote only the approved items into the canonical deliverables
+- `/intent-improve` — At milestones (e.g. after implementing several packets). Re-align `.intent/` with the implementation reality on the three axes of completeness / correctness / coherence
+
+These `intent-*` skills live at `.agents/skills/intent-*/SKILL.md` (Gemini CLI reads `.agents/skills/` as Agent Skills).
+
+## Active prompts (imperative, short)
+
+- Before implementing anything, run `/intent-discover` first.
+- When unsure where you are, run `/intent-status`.
+- While implementing, read only the relevant **packet** plus the related **Invariant** / Decision Rule — not the whole Compass or Tree.
+
+## Pull discipline (don't full-load)
+
+Before implementing, read only the relevant **packet** and the **Invariant** / Decision Rule that touch it. Do not constantly load the full Compass or full Tree. Do not transcribe Spec/Invariant bodies here; point to the source instead (`.intent/intent-compass.md`, `.intent/intent-tree.md`, the relevant packet under `.intent/packets/`).
+
+## Steering is not recommended
+
+Do not generate cross-cutting `steering` (especially steering custom) every time a responsibility is added. The constraints you need are supplied per-spec by intent through `export` (just-in-time, JIT), so prefer pulling the exact constraint over standing up new steering.
+
+## .intent/ scaffold
+
+The Intent intelligence (mode definitions, algorithm rules, cc-sdd bridge) and the planning deliverables live in `.intent/` and are agent-independent.
+
+- `intent-tree.md` — Intent Tree (L0–L4)
+- `intent-compass.md` — North Star / Anti-direction / Invariants
+- `packets/` — the Packet Plan (`plan.md`) and the packet files (1 packet = 1 file under `active/`; `index.md` lists the active packets, and completed packets move to `archive/`)
+- `mode.md` / `modes/` — the Intent-working mode (the selected mode, the `designer-questions` / `purpose` records, and the mode definitions)
+- `cc-sdd/` — drafts of cc-sdd requirements / design / tasks to hand off (kept per packet in `<slug>/` directories)
+
+See `.intent/README.md` for details.
+
+## cc-sdd integration
+
+Hand the target packet's `.intent/cc-sdd/<slug>/requirements.md` (a condensed Project Description) produced by `/intent-export-cc-sdd` to cc-sdd's `/kiro-spec-init`, and the Intent Planning results carry smoothly into cc-sdd's spec-driven flow. intent-planner only goes as far as drafts; cc-sdd generates the body, and a human reviews each phase.
+
+## Rules
+
+- Do not change application code during the Intent Planning phase.
+- Do not propose local refactors that do not support a parent intent.
+- Each packet must always reference a parent intent, and each task must preserve the invariants.
+- When intent is unclear, do not edit code; write it into Open Questions.
+- Treat inferred intent as provisional until a human reviews it.
+- If an implementation request exceeds the exported packet's Scope, do not keep implementing — go back to intent: open a new packet for the new area with `/intent-packets` (or widen the packet's scope and supersede it), then re-export. This prevents missing the new area's decisions (authorization, consistency, idempotency, error semantics) and packet-specific invariants.

package/templates/en/claude/skills/CONTRACT.md

@@ -0,0 +1,86 @@
+# intent-* Skill Shared Contract
+
+The conventions that every `intent-*` skill follows. The scope is the whole set of skills whose names start with `intent-`, not an enumerated list (adding a skill does not require revising this contract; it applies as-is). They are aligned to the same skeleton as cc-sdd's `kiro-*` skills and coexist non-destructively.
+
+## frontmatter (required fields)
+
+```yaml
+---
+name: intent-<phase>            # Must start with intent-. Never collide with kiro-* (required for all skills)
+description: <one-line summary>  # A description that makes clear when to use it (required for all skills)
+allowed-tools: Read, Write, Glob, Grep, AskUserQuestion  # (required for all skills)
+argument-hint: <description of arguments>  # (required for all skills)
+# disable-model-invocation: true  # Required only for canonical-writers (see below). Not placed on auto-invocable skills
+---
+```
+
+- The required fields are the four `name` / `description` / `allowed-tools` / `argument-hint` (uniformly for all skills).
+- **`disable-model-invocation: true` is required only for skills that rewrite canonical (canonical-writers)**. Skills that do not rewrite canonical — either read-only or with Write limited to a derived area `.intent/<area>/` (auto-invocable) — **do not place it** = the model may invoke them automatically from context.
+  - The **decision axis for auto-invocability is "whether it rewrites canonical (the sources of truth such as intent-tree / intent-compass / the packets and plan.md under `.intent/packets/`)"**. If it does not rewrite canonical, it is auto-invocable (no `disable`); if it does, set `disable-model-invocation: true` to make it slash-invocation only.
+  - This "auto-invocable" axis is **a different axis from the "read-only skills (narrowing `allowed-tools` to `Read, Glob, Grep`; only `intent-status` / `intent-validate`)"** in the frontmatter exceptions section below (do not conflate them). The read-only-skill axis is a discipline about narrowing allowed-tools, whereas the auto-invocable axis also includes `intent-overview` / `intent-from-spec` / `intent-to-spec`, which carry `Write` (they are auto-invocable because their Write is limited to a derived area and does not rewrite canonical). See the "read-only skills" note below for the detailed cross-reference.
+  - **Skill classification (the source-of-truth enumeration that downstream references)**:
+    - **auto-invocable (5)** = **do not place** `disable-model-invocation`: `intent-status` / `intent-validate` / `intent-overview` / `intent-from-spec` / `intent-to-spec`.
+    - **canonical-writer (7)** = **require** `disable-model-invocation: true`: `intent-discover` / `intent-compass` / `intent-packets` / `intent-writeback` / `intent-improve` / `intent-export-cc-sdd` / `intent-export-openspec`.
+    - This enumeration must stay consistent with the test's `AUTO_INVOCABLE_SKILLS` (`test/structure-pack.test.mjs`) (a brake against duplicated management). When changing the auto-invocable set, update this enumeration and that test together.
+- `name` is `intent-*`. The directory name must match it too. Never collide with `kiro-*`.
+- `allowed-tools` is **limited to planning-oriented tools**: `Read, Write, Glob, Grep, AskUserQuestion` (add `Agent` if needed).
+  - Exception: only export skills (currently `intent-export-cc-sdd` to invoke `/kiro-spec-init`, and `intent-export-openspec` to invoke `/opsx:propose`) may add `Skill`. Invocation is limited to this single command per skill.
+  - Exception (Bash, strictly limited): skills that run the staleness check (currently the gate checks in `intent-export-cc-sdd` / `intent-export-openspec` and the freshness warning in `intent-status`) may add `Bash` solely to launch the read-only script `node .intent/scripts/intent-check.mjs` and — for the export record of the export skills (`intent-export-cc-sdd` / `intent-export-openspec`) — to run the read-only `git rev-parse --short HEAD` (neither creates, modifies, nor deletes any files). No other Bash use is permitted to intent-* skills.
+  - Exception: **read-only skills** (currently `intent-status` / `intent-validate`) narrow `allowed-tools` to **`Read, Glob, Grep`**. They carry neither `Write` nor the interactive-confirmation tool (`AskUserQuestion`). This is an intentional, permitted narrowing of the standard set. As an exception, under the Bash-limited exception above, `intent-status` may additionally use `Bash` solely to launch the read-only script `node .intent/scripts/intent-check.mjs` (the property of creating, modifying, and deleting no files is preserved; its `allowed-tools` becomes `Read, Glob, Grep, Bash`). `intent-validate` carries no Bash.
+    - Note (a different terminology axis): this **"read-only skill" axis (allowed-tools narrowing; only `intent-status` / `intent-validate`)** and the **"auto-invocable" axis (does not rewrite canonical; the 5 skills that do not place `disable-model-invocation`)** in the frontmatter required-fields convention above are **different axes**. Auto-invocable also includes `intent-overview` / `intent-from-spec` / `intent-to-spec`, which carry `Write`, so the two sets do not coincide. Do not conflate them.
+
+## Body structure
+
+Align to the cc-sdd style.
+
+```
+# <skill-name> Skill
+
+## Core Mission
+- Success Criteria: ...
+
+## Execution Steps
+### Step 1: ...   (Read and apply rules/*.md as needed)
+### Step 2: ...
+
+## Output Description
+- The generated update proposal
+- Open Questions that the human should review
+- The command to run next
+
+## Safety & Fallback
+- Behavior on error / missing prerequisites
+```
+
+## Shared constraints
+
+- **Output is fundamentally a "proposed update"**. Writing to `.intent/` is allowed.
+- **Do not change application code** (INV6).
+  - The scope of INV6 is "do not change application code", not "do not invoke other skills". The two are distinct concepts. `intent-export-cc-sdd` invoking `/kiro-spec-init` does not contradict INV6 (it touches no code).
+- **Respect the mode (read fallback contract)**: resolve mode state in the order **`mode.local.md` → otherwise old `mode.md` → otherwise the `standard` default** (backward-compatible fallback). Follow the mode definition in the definition file. When neither `mode.local.md` nor old `mode.md` is present, continue with `standard` as the default and add "mode undetermined; `/intent-discover` recommended" to the Open Questions (do not stop). Enforcement / Drift-watch (shared policy) are read from `mode.md` (not subject to this fallback contract).
+- **When a prior deliverable is missing**, do not fill the gap with guesses; guide the user to "run the corresponding command first" and stop (distinguish this from the absence of mode state).
+
+## Question and Terminology Conventions
+
+- **Self-contained questions**: every question or confirmation addressed to the user must be a self-contained sentence that can be answered without knowing the terminology. When a term is used, include a one-line explanation inside the question text itself (e.g., "Confirm whether the first packet (unit of work) is a walking skeleton (a minimal implementation that runs end to end from input to output)").
+- **English terms + one-line explanations**: keep terms in English; do not replace them with translated coinages. When an explanation is needed, attach a one-line explanation that states the function or meaning (in parentheses or as a blockquote) at the first occurrence.
+- **Do not invent coined terms**: do not invent new coined terms that are absent from the canonical vocabulary (the ubiquitous language already in use across the intent deliverables); reuse an existing term. If you must introduce a new term, attach a one-line explanation at its first occurrence.
+
+## State sharing across skills
+
+- The shared state points are **`mode.local.md`** (mode state: mode / designer-questions / purpose; local-only, git-ignored) and **`mode.md`** (shared policy: Enforcement / Drift-watch; git-tracked) — two files (do not create hidden sharing). The read fallback contract is consolidated in "Respect the mode" above.
+- `.intent/deltas.md` is a **deliverable** just like the packet files under `.intent/packets/` (written by intent-writeback, read by intent-status / intent-improve); it is distinct from the mode-state sharing described above. It is not the introduction of new hidden sharing.
+
+### Split and archive convention for append-only records
+
+The append-only single-Markdown records under `.intent/` (deltas / export-log / drift-log / milestones / compass-archive and the like — records of the same shape, where writers append at the end and readers read the whole file) collide on a single anchor (the end of the file) under concurrent appends and grow unbounded. To resolve this structurally, append-only records take a physical form that follows the conventions below (this is the single source of truth for the convention).
+
+1. **Separate the active surface (the current projection) from history (archive)**. Keep the currently-referenced records thin on the active surface, and move terminal (no-longer-updated) entries off to archive.
+2. **The split key has two classifications**. Records stop appending to the end of a single file and are instead written to small files split by a non-colliding natural key. The classification is decided by the record's origin: **packet-origin = a file per packet** (e.g. `deltas/<packet-slug>.md`) / **event-origin = a file per date+slug** (e.g. `drift-log/<date>-<slug>.md`). Because a different packet / different event touches a different file, end-of-file collisions disappear in principle.
+3. **Do not use sequential numbering; use date+slug**. Do not use a central-counter sequence such as `0001` in file names (concurrent sessions cannot see each other's numbering and so cannot avoid collisions). Use date+slug instead.
+4. **Archive eviction follows the existing `archive/<year>/` structure**. Move terminal entries off to `archive/<year>/` (a per-year directory; the precedent that packets already have) under the record directory, keeping the active surface thin. Do not invent a new eviction naming scheme.
+5. **Do not use merge=union for records whose order is load-bearing**. `merge=union` (erasing conflict markers via gitattributes) silently breaks order, so do not use it for records where entry order carries meaning. Collisions are eliminated structurally by the split (convention 2).
+
+- **Naming of the split key references the existing packet slug rule and does not redefine a new numbering scheme**. The deterministic slug derivation (NFC normalization → trim → lowercase → dangerous characters to `-` → collapse consecutive `-` → strip leading/trailing `-` → preserve non-ASCII) and the date part (the drafting date) have their single source of truth in the slug rule of `intent-packets/rules/packet-format.md`; the split key need only reference it (do not bring in new numbering logic or a central counter).
+- The content of records (each record's entry format, fixed key order, etc.) is out of scope of this convention; split and archive govern placement only (content is kept behavior-preserving).
+- **Placement for the five record files (where convention 2 applies)**: apply the classification above to all five files. **packet-origin** = `deltas/<packet-slug>.md` / `export-log/<packet-slug>.md` (a file per packet). **event-origin** = `drift-log/<date>-<slug>.md` / `milestones/<date>-<event-slug>.md` (a file per date+slug). **compass-archive is per superseded Decision Rule (rule-unit)** = `compass-archive/<rule-slug>.md` (re-superseding the same rule goes to the same file). Until reader cross-following is complete, keep the old `export-log.md` as a generated active mirror (split files concatenated in `exported_at` order; derived, never hand-edited) alongside the split files, regenerated by the writer on every export.

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

@@ -0,0 +1,55 @@
+---
+name: intent-compass
+description: From the Intent Tree, build the decision criteria for this change (North Star / Anti-direction / Invariants / Decision Rules). Prevents Claude from escaping into local optimizations. Does not implement.
+disable-model-invocation: true
+allowed-tools: Read, Write, Glob, Grep, AskUserQuestion, Bash
+argument-hint: <focus of this change (optional)>
+---
+
+# intent-compass Skill
+
+## Core Mission
+- **Success Criteria**:
+  - North Star / Current Drift / Direction / Anti-direction / Invariants / Decision Rules / Evidence / Open Questions are all present
+  - The local optimizations Claude tends to make are explicitly enumerated in Anti-direction
+  - Only project-universal invariants are kept in the compass; packet-specific invariants are canonical in the packet file (Safety / Invariants)
+  - No application code has been changed at all
+
+## Execution Steps
+
+### Step 1: Read the prerequisites
+- Read `.intent/intent-tree.md`. If absent, guide the user to "run `/intent-discover` first" and stop.
+- While reading, when you see an unsettled verb slipped into the settled phrasing of the compass / intent-tree (assume / reuse / planned / TBD / tentative, etc.), do not fix it by guessing; present it as a conversion proposal into Open Questions or an undetermined slot (with the reason and the revisit condition (Revisit when)). Promotion to a fixed value is left to the user's confirmation. Do not re-convert spots already recorded in Open Questions / Deferred / an undetermined slot.
+- Read `.intent/mode.local.md` (falling back to `.intent/mode.md` if absent) for the mode state. If both are absent, default to standard and add "mode undetermined; `/intent-discover` recommended" to the Open Questions (do not stop).
+- If an existing `.intent/intent-compass.md` exists, read it.
+
+### Step 2: Apply the mode definition's algorithm
+- Open the mode definition that `.intent/mode.local.md` (falling back to `.intent/mode.md`) `definition` points to, and read and apply the algo rule (`rules/algo-*.md`) assigned to the Compass construction phase (currently `rules/algo-qoc.md` for every mode). The examples are not exhaustive; the mode definition's table is always authoritative.
+
+### Step 3: Build the Compass
+- As a step before derivation, read and apply `rules/constraint-surfacing.md`. Match the bundled domain-convention catalog read-only and surface draft candidates for Anti-direction / Invariants (candidates only; do not auto-transcribe. Do not replace the existing derivation. Stay silent when the catalog is absent).
+- Following QOC, draw the North Star, and condense the Decision Rules as lightweight ADRs (the field structure of an entry is canonically defined by `rules/algo-qoc.md`).
+- Explicitly enumerate the local optimizations / quick-fix refactors Claude tends to make in Anti-direction (most important).
+- Resolve the Invariants into two layers:
+  - **Project-universal invariants** (common to all work, small in quantity) → keep them in the compass Invariants, and recommend placing them in `.kiro/steering/` via `/kiro-steering-custom` so they take effect across all work (do not place automatically; keep them small to avoid increasing startup context).
+  - **Packet-specific invariants** (a specific work unit) → draft them directly in the packet file's Safety / Invariants (do not write them in the compass; `/intent-packets` fills them in when drafting the packet).
+- Stamp the section update date (the writer's responsibility): when writing the compass, stamp **only the line of the section whose content you actually updated**. If you update the Invariants section, record that moment in `Updated (Invariants):`; if you update the Decision Rules section, record that moment in `Updated (Decision Rules):` (ISO 8601). Do not always stamp both — stamp a line only when its section was updated. Leave a section's line unchanged when its content did not change (idempotent; do not stamp when nothing changed). Replace the initial marker `—` (the scaffold default) with the timestamp at the moment you actually update that section. Obtain the timestamp with the Bash `date`. If you cannot obtain the date/time, do not write a guessed date — report that instead. Stamping is the writer's (this skill's) responsibility and is not given to the read-only verification layer (intent-validate).
+
+### Step 4: Present
+- Present the proposed update to `.intent/intent-compass.md`. Do not make implementation changes.
+
+## Output Description
+
+**Reader**: a human developer who is about to head into implementation (and the AI that does the implementing).
+**What this output makes them grasp first**: "**these are the local optimizations to avoid in this change (Anti-direction)**. The decision criteria are in place, so next is `/intent-packets`." The core of this skill is making the Anti-direction explicit, so lead with it.
+
+Lead the output with the conclusion.
+
+- **Local optimizations to avoid this time (Anti-direction, top)**: name the quick-fix refactors / local optimizations Claude tends to make (the most important output of this skill).
+- **Next move (one line)**: `/intent-packets` (decomposition into work units; carving out packets at a granularity that can be handed to cc-sdd).
+- **Details**: the proposed update to `.intent/intent-compass.md` (North Star / Direction / Invariants / Decision Rules), the universal invariants recommended for steering placement (if any), and the Open Questions needed for decisions.
+
+## Safety & Fallback
+- If there is no Intent Tree, stop and guide the user to `/intent-discover`.
+- The absence of mode.md does not stop; continue with the standard default and announce it.
+- Do not change application code.

package/templates/en/claude/skills/intent-compass/rules/algo-qoc.md

@@ -0,0 +1,62 @@
+# Algorithm: QOC (Questions-Options-Criteria)
+
+A technique for recording design decisions as "question, options, selection criteria". Used in the Intent Compass construction phase common to all modes. By preserving the grounds for decisions, it prevents drifting into local optimizations later (especially at the impl stage).
+
+## Procedure
+
+1. **Draw the North Star from the Intent Tree**
+   - From L0/L1, condense "the final state this change wants to approach" into one.
+
+2. **Expand decision points with QOC**
+   - **Question**: the point of hesitation ("how to realize X").
+   - **Options**: list multiple options that could be taken.
+   - **Criteria**: by what criteria to choose. Check against the Intent Tree's L1 (outcomes) and invariants (constraints that must not be broken).
+   - Condense the adopted option into `Decision Rules` as a **lightweight ADR** (Architecture Decision Record, Nygard format). One decision per entry, with **Context** (the question and situation) / **Decision** (the option taken) / **Why** (the selection criteria) / **Alternatives considered** (the alternatives examined; transcribe a summary of the Options compared in QOC but not adopted, together with the reasons they were rejected) / **Consequences** (what this decision imposes — explicitly connect to the Invariants it enforces and the Anti-direction it forbids) / **Revisit when** (the conditions under which this decision should be revisited; if the conditions cannot be determined, explicitly record "undetermined" — do not leave the field blank).
+   - Division of roles: QOC is the **exploration tool for comparing options**; the ADR-shaped Decision Rule is the **canonical record that binds future implementation sessions**. Keep the comparison process in Evidence, and promote only the adopted decisions into Decision Rules.
+
+3. **Explicitly enumerate Anti-direction**
+   - Write the directions to avoid. In particular, concretely enumerate **the local optimizations / quick-fix refactors Claude tends to make**. This is the most important section of the Compass.
+   - Use a **pre-mortem** to generate the list: **assume** this change has been implemented and the overall design ended up broken or off-intent — then ask "what did the agent do?" Looking back from that imagined future (prospective hindsight) surfaces failure paths to record as Anti-direction. It detects failure factors better than ad-hoc enumeration.
+   - Examples: "fix some other processing while at it", "bulk replacement without tests", "push domain logic into the UI".
+
+4. **Fix the Invariants in two layers**
+   - Behavior / API / data / UX / operational constraints that must not be broken.
+
+   - **Before deriving anything by inference, confirm with the user using a fixed set of categories**. Establish user-supplied constraints as canonical first, then add inference-derived constraints afterward only to fill the gaps (complement, not replacement). Present the following categories **in order of importance** (to control cognitive load):
+     1. Data / personal information (PII) — what data must never be deleted or leaked.
+     2. External dependencies / existing contracts — what behavior must hold even if they go down or change.
+     3. Operations / failure-mode behavior — what to protect first under failure, high load, or partial outage.
+     4. Security / privacy / legal — what conventions or regulations are fatal to violate.
+     5. Performance / availability — whether there is a threshold below which it counts as failure.
+     6. Technical constraints — whether there is a technology stack / language / framework / platform / license that must be used or must not be used. For this category, loss-reverse reasoning is unnatural, so ask in the **affirmative (direct form)** rather than the negative ("is there any technology that must be used or must not be used?"). Run whatever surfaces through an **over-promotion filter**: is it a constraint that becomes an external problem when broken (a requirement-level How), rather than a preference or default choice (a solution-level How)? Turn only the former into an Invariant. Note that this is distinct from the design decisions (L3) derived by this change; place here only external, change-independent boundaries (do not duplicate with L3).
+     7. Invariants / prohibitions — anything else that "must never be the case".
+   - For each category, attach **2–3 weak cues of differing nature, generated on the spot** from the read project context (tech stack / domain / existing code / README) — do not embed fixed example strings. Always state that the examples are **not exhaustive ("this is not a complete list; raise anything else")** so thinking is not fixated on the shown examples.
+   - When no concrete examples can be generated from the context, present only the category frame (the heading) so the user can fill it in from their own context (fallback).
+   - Phrase the question not in the affirmative ("is X needed?") but as a **failure premise / in the negative** (e.g. "what is the worst that happens if this is completely ignored", "what must be protected even if an external dependency goes down", "what data must never be deleted"). Turn only what truly must be protected into an Invariant, from the loss scenario; do not mix in excessive assumptions (the technical-constraints category uses the direct form; see that category for the reason).
+   - For each category, present it so the user can choose "not applicable / unknown / confirm later"; do not force an answer. For items the user defers or marks "confirm later", do not fill them with guesses — escape them to `Open Questions` (with the `[by export]` tag where appropriate) and do not halt compass construction.
+
+   - Sort the collected constraints into the **two Invariant layers**. **Project-universal invariants** (common to all work, small in quantity) are fixed into the compass `## Invariants`. **Packet-specific invariants** (constraints limited to a specific work unit) are held in `## Open Questions` as "packet-specific constraints (candidates)", since during the compass phase packets are normally not yet drafted (later `/intent-packets` transcribes them into the relevant packet's Safety/Invariants). Among the non-functional requirements, those that are **target values** (performance / availability thresholds, etc.) are sorted into `Decision Rules` or the Intent Tree's L1 (measurement criteria).
+   - For the project-universal ones, recommend placing them in `.kiro/steering/` via `/kiro-steering-custom` so they take effect across all work (do not place automatically; keep them small to avoid increasing startup context).
+
+5. **Leave Evidence and Open Questions**
+   - Put the evidence supporting each decision (README / code / tests / logs / issues) into `Evidence`.
+   - Put questions needed for decisions but still undetermined into `Open Questions`.
+   - Attach the `[by export]` tag only to questions that must be answered before export (untagged questions can be answered at any time).
+
+6. **Confirm omissions and excess with an omission recap**
+   - Before presenting the `intent-compass.md` update proposal, briefly summarize the collected and inferred constraints / non-functional requirements / invariants and ask the user "is anything missing, or conversely is any assumption excessive?" (present it as material for a human to correct the LLM's oversights and hallucinations).
+   - When the user points out a **missing** item, add that constraint to the record location appropriate to its kind and re-present: universal Invariant → `## Invariants` / packet-specific → held in `## Open Questions` as a "packet-specific constraint (candidate)" / target value → `Decision Rules` or L1. Missing purpose/success items are out of compass scope (handled on the Intent Tree side); in this file, correct only the compass constraints.
+   - When the user points out an **excess**, after confirmation remove that entry from canonical (`## Invariants`, etc.). If unsure, do not delete it but demote it to `## Open Questions`. Always confirm with the user before deleting.
+   - Keep the re-edit to at most one round trip (do not converse endlessly in the recap). Escape any remaining points to `## Open Questions`.
+
+## Discipline
+
+- A Decision Rule must always include the "why". Do not write only the conclusion.
+- When overturning a decision, mark the old entry as superseded and add a new entry. Do not silently let contradictory decisions sit side by side.
+- Old 4-field entries recorded before the introduction of the 6-field format (those without Alternatives considered / Revisit when) remain valid; do not treat the missing fields as an error, flag them, or rewrite them.
+- Do not leave Anti-direction empty. List at least a few concrete examples of local optimizations.
+- Do not change code.
+
+## Output
+
+Update (present as a proposal) the `North Star / Current Drift / Direction / Anti-direction / Invariants / Decision Rules / Evidence / Open Questions` of `intent-compass.md`.

package/templates/en/claude/skills/intent-compass/rules/constraint-surfacing.md

@@ -0,0 +1,41 @@
+# Constraint Surfacing (surfacing constraint starting points)
+
+A procedure that matches the bundled domain-convention catalog (`.intent/constraint-starters.md`) read-only and surfaces **draft candidates** for Anti-direction / Invariants. Used during the Compass construction phase of `/intent-compass`, **as a step before** deriving Anti-direction / Invariants. If the user has grown their own constraints (`.intent/constraint-library.md`), add those to the candidates as well.
+
+This is a **supplement that does not replace** C2's derivation (the container that makes Anti-direction/Invariants explicit in the compass to suppress local optima): impact list → Invariants, premortem → Anti-direction. The existing derivation runs as is; this only injects "draft candidates of conventions that fit the context" ahead of it.
+
+## Discipline (must hold)
+
+- **Surfacing stays a read-only draft.** Do not **auto-write** matched conventions into Anti-direction / Invariants. Transcription into the compass happens by hand after the user picks what to adopt (confirmation with the user uses this skill's own confirmation mechanism).
+- **Do not push.** Do not surface conventions that do not fit the context. Narrow the candidates; involve no stop or coercion. If the fit is weak, stay silent (lean toward silence over false positives, to keep the draft feature trustworthy).
+- **Match semantically.** Judge by reading "fits when" against the context. Do not lean on mechanical string scoring or regular-expression matching.
+- **Do not replace or duplicate the existing derivation.** The impact-list → Invariants and premortem → Anti-direction steps stay as is. This procedure only adds a supply of candidates ahead of them.
+- **Stay silent when the catalog is absent.** When `.intent/constraint-starters.md` is absent, skip the matching and say so (do not stop). Same for `.intent/constraint-library.md` (skip if absent).
+- **Do not record to any log.** Surfacing stays a read-only suggestion and keeps no record.
+
+## Procedure
+
+1. **Read the catalog**
+   - Read `.intent/constraint-starters.md` (bundled conventions) and, if present, `.intent/constraint-library.md` (constraints the user grew) read-only, and obtain all conventions (per `## id:`). If both are absent, skip and say so (do not stop).
+
+2. **Match each convention's "fits when" against the context**
+   - Match each convention's `fits when` against the case you are about to write the compass for (material, domain, boundaries touched). `fits when` is a cue, not a strong rule; if the fit is weak, do not surface that convention.
+   - Use only the case context for matching. Do not read code diffs or runtime metrics.
+
+3. **Surface matched conventions as draft candidates (do not write)**
+   - Surface the `starter` (Anti-direction candidate / Invariant candidate) of matched conventions to the user as candidates. Example: "This case may match `<id>` (<name>) — how about <Anti-direction candidate> / <Invariant candidate> as a starter (adoption is up to you)?".
+   - **Do not auto-write into the compass.** Whether to adopt is the user's call; only adopted ones are taken into Anti-direction / Invariants by hand.
+   - Do not surface non-matching conventions. Narrow so there are not too many candidates.
+
+4. **Proceed to the existing derivation**
+   - After surfacing candidates, run the existing Anti-direction / Invariant derivation (impact list → Invariants, premortem → Anti-direction) as usual. Candidates the user adopted are taken in by hand within that derivation.
+
+5. **Accumulate adopted constraints into the personal ledger (optional, by hand / with consent)**
+   - Among the starters surfaced in ③, if the user **adopted** a constraint as "this is my standard," guide them to append it to the personal ledger `.intent/constraint-library.md` in its fixed schema (`## id:` / name / domain / fits when / constraint / origin). Next time it is surfaced as a candidate alongside the bundled catalog and is reused within the repo.
+   - **Do not auto-write into the ledger.** Appending happens by the user's manual action, or only under the user's explicit approval (it carries no auto-accumulate behavior — a read-only gate). **If the user does not adopt, append nothing.** Leave the existing surfacing behavior unchanged.
+   - **Keep accumulation inside this project only.** The append target is only inside this project's `.intent/` directory; provide no mechanism to share or persist constraints across projects (do not guide cross-project accumulation).
+   - When the personal ledger `.intent/constraint-library.md` is absent, skip the accumulation and say so (do not stop — backward compatible).
+
+## Relationship to discover
+
+- In discover's terrain-diagnosis lane (`drift-terrain.md`), the same catalog is matched lightly when `drift-watch: on` to give early awareness. This procedure (compass) is the primary touchpoint; discover is supplementary.

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

@@ -0,0 +1,63 @@
+---
+name: intent-discover
+description: The entry point of Intent Planning. From the repository's pain points, README, and an overview of existing code, build an Intent Tree (L0-L4) and recommend/confirm the mode for working out the Intent. Does not implement.
+disable-model-invocation: true
+allowed-tools: Read, Write, Glob, Grep, AskUserQuestion
+argument-hint: <problem / idea / target scope>
+---
+
+# intent-discover Skill
+
+## Core Mission
+- **Success Criteria**:
+  - The L0–L4 Intent Tree is structured, with canonical (confirmed) and inferred (guessed) separated
+  - The mode for working out the Intent is recommended/confirmed and recorded in `.intent/mode.local.md` (the local canonical source for mode state)
+  - Whether question delegation (designer-questions) is needed is confirmed and recorded in `.intent/mode.local.md` (the purpose as well when on; if deferred, it is noted in Open Questions)
+  - Open Questions that the human should review are made explicit
+  - When drift-watch is on, terrain diagnosis is performed, the matching pattern is named, and it is recorded in drift-log (when off, nothing is done)
+  - 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; when off, nothing is done)
+  - No application code has been changed at all
+
+## Execution Steps
+
+### Step 1: Select the mode
+- Read and apply `rules/mode-selection.md`.
+- Check the available modes (`.intent/modes/*.md`) and recommend a mode based on the repository situation.
+- Confirm with the user via `AskUserQuestion` (run the recommend→confirm wiring even if standard is the only candidate).
+- Record the confirmed result in `.intent/mode.local.md` (the local canonical source for mode state; not tracked by git). Enforcement / Drift-watch (shared policy) stay in `.intent/mode.md` and are not touched.
+- **Recommend → confirm → record the target format (optional, deferrable)**: after confirming the mode, when the target format (which exit to take = `cc-sdd` / `openspec` / `to-spec`) can be inferred from the case, ask the user to confirm it, and on confirmation record it in the `format` line of `.intent/mode.local.md`. The inference signals are the case type (mode; whether the artifact is code or a document; presence of `.kiro/` or a repository-root `openspec/`, etc.), and the format→exit correspondence is kept consistent with `intent-packets/rules/export-route.md` (the exit decision lane). Follow the **same confirmation discipline as mode / designer-questions / purpose**: if it cannot be inferred, or the user defers/declines, **do not fill it in by guessing — do not record it** (continue with it unspecified; the exit decision later falls back to inference). Recording the format is optional; discover continues as before even without it. **Only `/intent-discover` writes the format** (other skills read it read-only — DR26).
+- Read `rules/designer-questions.md` and confirm/record question delegation (designer-questions).
+
+### Step 2: Apply the algorithm according to the mode definition
+- Read the confirmed mode definition (e.g. `.intent/modes/standard.md`).
+- Open the mode definition that `.intent/mode.local.md`'s `definition` (falling back to the old `.intent/mode.md`) points to, and read and apply the algo rule (`rules/algo-*.md`) assigned to the Intent Tree construction phase (standard → `rules/algo-gore-lite.md`; refactor → `rules/algo-gore-lite.md` + `rules/algo-drift-analysis.md`, plus `rules/algo-intent-recovery.md` for intent-less code). The examples are not exhaustive; the mode definition's table is always authoritative.
+
+### Step 3: Build the Intent Tree
+- Following GORE-lite, decompose L0 (purpose) → L1 (outcomes) → L2 (capabilities) → L3 (behavior/architectural intent) → L4 (candidate packets).
+- Separate confirmed intent from guesses (Assumptions). Put anything undetermined into Open Questions.
+- If an existing `.intent/intent-tree.md` exists, read it and present additions/updates as a proposal rather than overwriting.
+
+### Step 3.5: Terrain Diagnosis (drift-watch)
+- Check the value of `drift-watch` in the `## Drift-watch (user-managed)` section of the `.intent/mode.md` read in Step 1. When it is not `on` (including off, unspecified, invalid value, missing section, or missing mode.md), do not perform terrain diagnosis; continue to Step 4 as before (byte-identical to current behavior).
+- Only when it is `on`, read and apply `rules/drift-terrain.md`. The symptom × in-progress Intent Tree matching, the named presentation of matching patterns, drafting anti-direction / invariant candidates into Open Questions, and appending to drift-log are all delegated to the rule's procedure (do not duplicate the procedure here). Also apply the "Context cost cues" section at the end of that rule: match the types in `.intent/context-cost-cues.md` and name, in a noticing tone, ways of progressing that eat context (recorded to no log; skip if the catalog is absent).
+
+### Step 4: Present
+- Present the proposed update to `.intent/intent-tree.md`.
+- Apply the additional Intent Tree confirmations in `rules/designer-questions.md` (L1 measurement criteria / screen rough), following the rule's applicability conditions.
+- Do not make implementation changes. Do not jump ahead with refactoring proposals.
+
+## Output Description
+
+**Reader**: a human developer who is about to start working out the intent.
+**What this output makes them grasp first**: "the skeleton of the Intent Tree is in place. **Next is `/intent-compass`**. But these are the only Open Questions to answer before finalizing."
+
+Lead the output with the conclusion.
+
+- **Next move (top, one line)**: `/intent-compass` (building the decision criteria; defining the Invariants / Anti-direction that prevent local optimizations).
+- **Open Questions that need confirmation**: the points a human must finalize (left as questions rather than filled in by guessing). Phrased so it is clear that clearing only these is enough before moving on.
+- **Details (proposed deliverable updates)**: the proposed update to `.intent/intent-tree.md` (L0–L4 / Open Questions / Assumptions; canonical and inferred kept distinct), the confirmed mode (`.intent/mode.local.md`), and the confirmed designer-questions / purpose.
+
+## Safety & Fallback
+- If the input (problem / target scope) is ambiguous, do not fill in with guesses; ask the user.
+- If an existing Intent Tree exists, do not destroy it; present the diff as a proposed update.
+- Do not change application code.

package/templates/en/claude/skills/intent-discover/rules/algo-drift-analysis.md

@@ -0,0 +1,34 @@
+# Algorithm: Drift Analysis
+
+Makes the gap (drift) between the current implementation/structure and the intended design observable. Used together with GORE-lite in the discover phase of `refactor` mode to surface, among L0–L4, the divergence between the current state and especially L3 (behavioral / design intent).
+
+## Procedure
+
+1. **Inventory the current state (input)**
+   - Grasp the target repository's structure, dependency direction, key behaviors, and whether tests exist. Exhaustiveness is not required, but **thicken the drift to a depth sufficient for the downstream Migration Slicing to cut practical slices** (a thin inventory yields a thin drift list and slices that become guesswork). Use a granularity that can be matched against intent as the guide.
+   - Keep at hand the implicit design intent (L1–L3 drawn out via GORE-lite). If the intended design cannot be recovered from the current state (the spec has been fully lost), `behavior-unknown` mode may fit better than refactor; if that signal surfaces during discover, note the mode reconsideration in Open Questions.
+
+2. **Match with a Reflexion worksheet**
+   - For the matching, use a lightweight worksheet borrowing the structure of Software Reflexion Models (Murphy & Notkin). Narrow the key components to **5–15 elements per analysis** (not broad and shallow — important spots, narrow and deep), and for each element lay out:
+     - **Intended responsibility / dependency** (from the Intent: the corresponding L1 Desired Outcome / L2 Capability / L3 Behavioral / Architectural Intent)
+     - **Observed responsibility / dependency** (from code reading: reading imports/references, directory structure, and call direction is sufficient) and its **evidence** (file / code location)
+   - Classify each element as **convergence (matches) / divergence (deviates) / absence (in the intent but not found in the implementation)**.
+   - This turns the drift list from "an enumeration of things that bother you" into a diff list defined in relation to the intent model.
+
+3. **Enumerate the drifts**
+   - Raise the worksheet's divergence / absence entries as drifts. Write each drift as a "current → intended" pair, attaching **diff kind (divergence / absence), evidence, and confidence (whether the evidence is direct or includes inference)**. Do not delve into speculative causes.
+   - As interpretation, distinguish the types: deviation (design that contradicts intent), decay (boundaries / dependencies that have eroded over time), and accumulated local optima (point optimizations that encroach on the overall intent).
+
+4. **Classify each drift under a parent intent**
+   - Identify "which Intent each drift deviates from" and tie it to the corresponding L1/L2/L3.
+   - Send any whose tied Intent is ambiguous or undetermined to Open Questions.
+
+## Discipline
+
+- **A planning technique, not execution**: capturing drift is the structuring of intent; do not perform refactoring or code changes here.
+- **Separate facts from guesses**: record the observed current state as fact, and separate conjecture about causes / response direction into `Assumptions`.
+- **Send undetermined items to Open Questions**: anything where you cannot judge which intent it deviates from, do not fill with guesses; write it into Open Questions.
+
+## Output
+
+A list of drifts (current → intended, diff kind and type of deviation, evidence and confidence, corresponding parent intent). Reflect them (present as a proposal) into the L3 and Open Questions / Assumptions of GORE-lite's `intent-tree.md`.

package/templates/en/claude/skills/intent-discover/rules/algo-gore-lite.md

@@ -0,0 +1,35 @@
+# Algorithm: GORE-lite
+
+A lightweight version of Goal-Oriented Requirements Engineering. It progressively decomposes implicit intent into an L0–L4 goal hierarchy. Used in the Intent Tree construction phase common to all modes (standard / refactor / behavior-unknown all build on this algo).
+
+## Procedure
+
+1. **L0: Fix the Product Purpose in 1–2 sentences**
+   - "What does this product/subsystem exist for". Write the reason for existing, not the means.
+
+2. **L1: Draw out the Desired Outcomes**
+   - To satisfy L0, whose state / what state do you want to change and how. Perspectives: user / business / operations / developer experience.
+   - Write in terms of "the state change you want to cause", not "features".
+   - **Actor pass**: for each Outcome, write one line each for "who benefits / who could block or oppose / who is responsible for realizing it / what environmental assumptions it depends on" (the actor/dependency perspective of the i* family). A goal hierarchy without actors misleads where responsibilities are placed at implementation time. Lines you are not confident about go to Assumptions.
+
+3. **L2: Decompose into Capabilities**
+   - List the capabilities that support each Desired Outcome. Write them as responsibilities/capabilities, not feature names.
+   - The unit of "able to do X". Do not delve into implementation means.
+
+4. **L3: Derive the Behavioral / Architectural Intents**
+   - The behavior / design intent that makes each Capability hold. Include boundaries, dependency direction, side effects, data consistency, and UI/UX constraints.
+   - This is the intent of "why this design", not the implementation itself.
+
+5. **L4: Produce the Candidate Packets**
+   - Candidate work units just before implementation. A granularity above an Issue and before a spec.
+   - Be mindful of which L1/L2/L3 each candidate supports (this becomes the parent intent at packet-ization time).
+
+## Discipline
+
+- **Do not mix canonical and inferred**: put confirmed intent in the body and separate guesses into the `Assumptions` section. Do not assert without grounds.
+- **Send undetermined items to Open Questions**: anything that requires a decision during decomposition but lacks the information, do not fill with guesses; write it into Open Questions.
+- **Do not change code**: discover is the structuring of intent, not implementation.
+
+## Output
+
+Update (present as a proposal) the `L0 / L1 / L2 / L3 / L4 / Open Questions / Assumptions` sections of `intent-tree.md`.

package/templates/en/claude/skills/intent-discover/rules/algo-impact-analysis.md

@@ -0,0 +1,37 @@
+# Algorithm: Impact Analysis
+
+Inventories, before implementation, which existing boundaries, contracts, and data flows a new feature touches. Used together with GORE-lite in the discover phase of `feature-growth` mode. It translates the idea of Change Impact Analysis (Bohner & Arnold) from tool-based dependency analysis into a planning technique based on LLM reading. Where Drift Analysis asks "what is the gap between the current state and the intent" (discover of refactor), Impact Analysis asks "what existing things does this addition touch" — the questions differ, so the two are not interchangeable.
+
+## Procedure
+
+Input = the new feature's intent (L1–L4 already structured via GORE-lite) and the existing codebase.
+
+1. **Identify the starting set**
+   - From the new feature's intent (especially L3/L4), list the starting points (modules, layers, APIs, data) in the existing codebase that it is likely to touch — the candidates the new feature will "read, call, or extend".
+   - Grasp the existing codebase's structure by LLM reading: reading imports/references, directory structure, and call direction is sufficient (do not assume AST analysis or static-analysis tooling).
+
+2. **Trace the ripple**
+   - From each starting point, follow "if this is touched, what else is affected" one step at a time along the dependency direction, widening the candidates (the CIA idea of a starting impact set → candidate impact set). Exhaustiveness is not required, but **thicken the impact list to a depth sufficient for the downstream Additive Slicing to design the seams** (a thin inventory turns the seams into guesswork).
+   - Attach **evidence** (file / code location) to each candidate. Treat ripples that cannot be confirmed by reading as conjecture and separate them into `Assumptions`.
+
+3. **Structure into the impact list**
+   - Raise the candidates as the impact list. Structure each item with the following three points:
+     - **Boundary touched**: module / layer / API
+     - **Existing contract depended on**: API signature, data schema, events, behavior
+     - **Kind of impact**: read / call / extend / requires change
+   - This structure becomes the downstream contract: in compass, each item is raised into a protective Invariant ("do not change X's existing contract"); in packets, Additive Slicing takes it as the input for seam design.
+   - If "requires change" dominates, that is a sign of redesign rather than addition — note a mode reconsideration (refactor) in Open Questions.
+
+4. **When you find drift, route it elsewhere**
+   - If, during the investigation, you discover a structural problem in the existing design (drift: decayed boundaries, dependencies contradicting the intent — problems outside feature-growth's purpose), **do not fix it within this mode**; record it in Open Questions and recommend separate work in `refactor` mode. Keep only the fact "the new feature touches it" in the impact list.
+
+## Discipline
+
+- **A planning technique, not execution**: inventorying impact is the structuring of intent; do not perform code changes or seam implementation here.
+- **Structural prohibition of drive-by refactoring**: even if you find drift, do not fix it within feature-growth. Send it to Open Questions + a refactor recommendation.
+- **Separate facts from guesses**: record impacts confirmed by reading as evidence-backed facts, and separate conjecture about unconfirmed ripples into `Assumptions`.
+- **Send undetermined items to Open Questions**: for boundaries where you cannot judge whether they are touched, do not fill with guesses; write them into Open Questions.
+
+## Output
+
+The impact list (each item: boundary touched / existing contract depended on / kind of impact, with evidence). It becomes the input for the Invariants in compass and for the seam design by Additive Slicing in packets. Reflect undetermined items and discovered drift (present as a proposal) into the Open Questions / Assumptions of `intent-tree.md`.

package/templates/en/claude/skills/intent-discover/rules/algo-intent-recovery.md

@@ -0,0 +1,39 @@
+# Algorithm: Intent Recovery
+
+A technique for recovering intent after the fact from existing code that was written without recording any intent (vibe coding). It sits between GORE-lite and Drift Analysis in the discover phase of `refactor` mode. Drift Analysis measures the gap between an intended design and the current state, but vibe-coded code lacks that baseline entirely. This technique back-derives candidate intent from the observable facts of the code and produces a baseline that Drift Analysis can consume.
+
+## When to use
+
+- The existing code was written without explicit design intent, spec, or design documentation (vibe coding, a prototype pushed into production, the legacy of someone who has left, etc.).
+- Even when you try to draw out L0–L3 with GORE-lite, the "how it should be" exists neither in anyone's head nor in documentation, and can only be drawn from the code.
+- The behavior itself is observable (so this is not a `behavior-unknown` case), but the **intent that produced that behavior is absent**.
+
+## Procedure
+
+Input = existing code whose intent is absent (structure, dependencies, key behaviors). Output = back-derived candidate intent (L0–L3, all inferred).
+
+1. **Back-derive candidate intent from the code**
+   - From the structure, dependency direction, key data flows, and recurring patterns, draw out "what this code appears to be trying to achieve" as L1 (outcomes) / L2 (capabilities) / L3 (behavior / design intent).
+   - This is a **conjecture** from the observed code, not the author's true intent.
+
+2. **Always place recovered intent as inferred**
+   - Place the back-derived L0–L3 not as canonical (confirmed) but as **inferred (guessed = Assumptions)**. In vibe coding, the distinction between "happened to write it this way" and "designed it this way" is not preserved in the code, so mixing it with the confirmed side falls into the trap of treating fabricated intent as fact.
+   - Note the basis for the recovery (which code observation it was drawn from) alongside each inferred intent.
+
+3. **Sort intentional vs. accidental, and send confirmation back to humans**
+   - For each recovered intent, sort whether it is "the result of a design decision" or "incidental / by happenstance". Do not finalize unjudgeable ones by guessing; send them to **Open Questions** and seek human confirmation.
+   - Only intent that a human has confirmed / endorsed may later be promoted to canonical.
+
+4. **Pass it to Drift Analysis as a baseline**
+   - Use the recovered (inferred) candidate intent as the "intended design" side of the input to the subsequent Drift Analysis. This lets Drift Analysis measure the drift of "recovered intent → current code".
+   - If the recovered intent is thin, the drift will be thin too, so draw out L1–L3 to a degree sufficient for Drift Analysis to produce a practical drift.
+
+## Discipline
+
+- **Recovery, not justification**: draw out intent from the fact that the code is written as it is; do not endorse "the existing code is correct". Raise even mistaken designs and unnecessary complexity as candidate intent, and handle them via Drift / Open Questions.
+- **Always inferred**: do not mix recovered intent with canonical. Do not promote it to confirmed without human endorsement (strictly observe GORE-lite's canonical/inferred separation).
+- **A planning technique, not execution**: do not change code here.
+
+## Output
+
+Back-derived candidate intent (L0–L3, all inferred, with recovery basis and intentional/accidental sorting). Reflect it (present as a proposal) into the corresponding L levels and the Assumptions / Open Questions of `intent-tree.md`, and use it as the input to Drift Analysis.