intent-planner 0.13.1 → 0.14.0

package/templates/en/codex/skills/intent-export-cc-sdd/rules/drift-export-check.md

@@ -4,7 +4,7 @@ The matching logic used at Step 1.6 of `/intent-export-cc-sdd`: the target packe
 
 ## 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 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 drift-prone-situation pre-check 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).
 

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

@@ -4,7 +4,7 @@ The matching logic used at Step 1.6 of `/intent-export-openspec`: the target pac
 
 ## 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 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 drift-prone-situation pre-check 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).
 

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

@@ -13,7 +13,7 @@ description: After implementation, cross-check the .intent/ deliverables against
   - 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)
+  - When drift-watch is on, context-cost-cues are matched and ways of progressing that eat context are named in a non-directive, noticing way (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
@@ -33,7 +33,7 @@ description: After implementation, cross-check the .intent/ deliverables against
 - 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).
+- 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 non-directive, noticing way, 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).

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

@@ -112,7 +112,7 @@ Alongside the coherence-axis evaluation, run a matching that makes you **notice*
    - Use only the subject for matching. Do not read token consumption, git diffs, or runtime metrics.
 
 3. **When a type matches (present the cue; do not write to any log)**
-   - Name it to the user in a noticing tone. Example: "The way this realignment is proceeding may match `<id>` — this might be eating context."
+   - Name it to the user in a non-directive, noticing way. Example: "The way this realignment is proceeding may match `<id>` — this might be eating context."
    - Add the type's "if this is unintentional" light alternative (thin entry point / JIT pull / limited input) as an **optional choice**. Example: "If this is unintentional, there is also <light alternative> (the judgment is yours)."
    - **Do not correct or instruct.** Phrase it as a cue rather than an imperative or a verdict. Installing many skills or loading full content can be a legitimate high-cost choice, so do not dismiss a context-eating choice as unnecessary. Leave the judgment to the user.
    - **Do not append to any log** (do not reuse the coherence-deviation append procedure or tally).

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

@@ -12,6 +12,11 @@ description: Read-only guidance skill that reads the current state of .intent/ a
   - Orphan-spec check: when `.kiro/specs/` has a spec that is in progress / done yet cannot be text-matched to any packet under `active/` or any delta in `deltas.md`, it is reported in the details as "possible un-drafted implementation (suspected to have been implemented without going through a Packet)" (candidate presentation, not an assertion; non-matchability is the normal case so false positives are tolerated, and the next-move first-match is not taken away; this check is not performed in environments without `.kiro/specs/`)
   - intent-tree unfiled check (discover skip): when `.kiro/specs/` has a spec whose design/implementation has advanced yet it cannot be text-matched to any of the **L0–L4 headings and bodies** of `.intent/intent-tree.md` (intent-planner has no ID anchors such as O#/C#/B#/P#, so determination is by text matching only), it is reported in the details as "possible implementation not filed into intent-tree (discover skip)" (candidate presentation, not an assertion; non-matchability is the normal case so false positives are tolerated, and the next-move first-match is not taken away; this check is not performed in environments without `.intent/intent-tree.md` or without `.kiro/specs/`). This unfiled check (tree layer), the existing orphan-spec check (Packet layer), and writeback omission (downstream layer) are partitioned into three layers, and when one spec matches multiple layers it is presented only in the single most-upstream layer so that no double warning is emitted
   - A leading mini progress rail (all packets laid out vertically with the five signals ✅/🔵/⚪/🔴/◻, each row also carrying `[current stage → next stage(s) to pass through]`) is placed at the top of the report so that "which packet is 🔵 you are here now, which stages each will pass through next, and where the ⚪ remaining work / 🔴 unreflected items are" is visible at a glance. Internal terms (the matching procedure, the integrity check, enforcement terms) are pushed down into the details (later) rather than led with
+  - The default output is slimmed into three layers (default = you-are-here + the next move emphasized on one line + Candidate Packets count/names + a one-line Ice box notice / details = the folded position / option = only on a natural-language trigger), and the one-line summary of the next move is never folded and is always emphasized at a prominent leading position
+  - The "dangerous notices" (freshness warning, packets integrity violations, unreflected `🔴`) are **shown in full as bare glyphs in the actual-impact context** (never folded), and a one-line summary "`⚠` N present (see details)" is also left on the folded details side to prevent them from being missed. In the explanatory context (legend, glossary, 0-count summary, etc.), the warning signals are toned down to inline code / words rather than bare glyphs so a zero-impact status does not startle the reader (INV32)
+  - The L4 "future addition candidates" of `.intent/intent-tree.md` are read using Read/Glob/Grep only, cross-checked against `archive/` and `.kiro/specs/` with the same text-matching means as the existing checks (orphan-spec / unfiled-state), and the unconsumed (neither packeted nor implemented) candidates are presented as a permanent default display of count + names (frozen-marked ones excluded; non-matchability tolerates false positives without assertion; if L4/archive/specs are absent, treat as 0)
+  - Ice box candidates with a frozen mark (`Deferred` / `保留` / `当面しない` / conditional hold, etc.) are not shown in the body in the default; instead a one-line notice "Frozen (Ice box): N. Show them with 'show me the icebox'" is included, and on a natural-language trigger they are expanded as count + names + freeze reason (ambiguous-boundary ones go on the Candidate side; no assertion)
+  - Only the presentation (output composition) is changed; the first-match selection logic for the "next move" is not changed (which move to recommend is untouched)
   - Exactly one "next move" is recommended via the first-match of `rules/decision-table.md`, accompanied by the reason and the judgment basis (which state of which deliverable it rests on)
   - The recommendation candidates are selected from discover / compass / packets / export / validate / improve / writeback / "no action needed"
   - When the enforcement in mode.md is remind or gate, a freshness check via intent-check is performed, and on detecting a violation (`result=stale` on the judgment line, or `pending` of 1 or more) a freshness warning quoting the intent-check stdout is included alongside the current-position summary (when off, unstated, an invalid value, or not executable, no warning is shown, as before)
@@ -19,7 +24,7 @@ description: Read-only guidance skill that reads the current state of .intent/ a
   - The section update dates of intent-compass.md (`Updated (Invariants):` / `Updated (Decision Rules):`) and the `updated_at` of the packets under active/ are cross-checked using Read/Glob/Grep only, and when the count of packets that are "not yet caught up after a compass update" reaches the threshold or more, `/intent-validate` is recommended as the right moment (decision table row 12), with its basis (which section was updated, how many are not caught up) included. It does not make a definitive diagnosis but stays at an estimate, and does not propose below the threshold (read-only preserved)
   - Each event in `.intent/milestones.md` is read using Read/Glob/Grep only, and any event for which neither "a `Updated (Decision Rules):` reflection stamp in compass" nor "a reference to the corresponding Decision in deltas" exists after the event's recorded time is grasped as an "unconsumed milestone (recorded but its corresponding revisit is unhandled)" and included as a residual in the current-position report (the same comparison shape as Step 3.6: lexicographic order of ISO 8601, only pairs where both ends are actually stamped; candidate presentation, not an assertion; when `.intent/milestones.md` is absent this check is omitted; read-only preserved)
   - No file has been created, modified, or deleted at all (read-only)
-  - Major terms in the output always carry a one-line plain-language explanation in the `term (explanation)` form
+  - Major terms in the output carry a one-line plain-language explanation in the `term (explanation)` form (two layers: lead = first occurrence / table headers only; details = every time; the glossary is kept and not abolished)
 
 ## Execution Steps
 
@@ -71,19 +76,32 @@ description: Read-only guidance skill that reads the current state of .intent/ a
 - Never list multiple candidates side by side (the reason and basis are listed alongside). Even ambiguous cases where multiple recommendations seem visible are folded mechanically into one by the priority order of the decision table.
 
 ### Step 5: Report
-Structure the report in the order that gets the reader to "where am I, and what do I do next" by the shortest path. Do not lead with internal terms (the matching procedure, the integrity check, enforcement terms); push them down into the details from (3) onward.
+Structure the report in the order that gets the reader to "where am I, and what do I do next" by the shortest path, and slim down the default output. Compose the output in three layers — **default (never folded) / details (the folded position) / option (only on a natural-language trigger)**. The default carries only the essentials ((1)–(4)) and the "dangerous notices"; push internal terms (the matching procedure, the integrity check, enforcement terms) and check details down into (5) details.
+
+**[Default] essentials that are never folded**
 
 - (1) **Progress rail (leading mini-rail)**: lay out all packets vertically and assign each one of the five signals (✅ reflected / 🔵 you are here / ⚪ not started / 🔴 unreflected / ◻ merged), **followed by `[current stage → next stage(s) to pass through]`**. Both the signal determination and the stage annotation follow the same discipline as overview's `progress-readout.md` "Progress rail" (the five signals cross-check `state` × whether export-log has a row × whether deltas has a corresponding entry via first-match; the stage annotation re-reads packet `state` as a position on the fixed pipeline `discover→compass→packets→export→implement→verify→writeback`; neither computes nor infers). Examples: `P2  🔵 you are here [implementing → next: verify→writeback]` / `P3  ⚪ not started [ready → next: export→implement]`. This makes **"which P is you-are-here now, which stages remain after this, and where the ⚪ remaining work / 🔴 unreflected items are" visible at a glance on a single sheet**. Annotate each signal's meaning per the glossary. The rail is a read-only mirror; status changes nothing.
-- (2) **The next move (exactly one, one line)**: present the skill name or "no action needed" **on one line** first, then append the recommendation reason + judgment basis (which state of which deliverable it rests on) concisely. Translate the first-match result of the decision table (`rules/decision-table.md`) into **the action a human takes next**, not into the internal row number.
-- (3) **Details (the folded position)**: each deliverable's present/absent/unfilled state and notable points that back the signals in (1); the current Source Packet (the packet name based on the latest row of export-log) and whether its directory (`.intent/cc-sdd/<slug>/`) exists. When packets integrity violations were detected (index ↔ active/ divergence, lingering done / superseded_by, the latest export-log row's packet absent from active/), include their content; when index.md is absent, include the regeneration prompt; when a violation was detected in Step 3, include the freshness warning quoting the intent-check stdout; when drift-watch is `on` in Step 3.5, include the drift-log light tally (`caught N / missed N / false-positive N / unjudged N`) as one block at the same position and temperature as the freshness warning; when conformance staleness's right moment (the not-caught-up count at or above the threshold) was detected in Step 3.6, include the basis "which compass section was updated, and how many packets are not caught up" at the same position and temperature as the freshness warning. When an intent-tree unfiled state (a suspected discover skip) was detected in Step 2, include one block with its spec name and the guidance "Design/implementation has advanced, but it could not be text-matched to any L0–L4 node of `.intent/intent-tree.md`. The discover phase itself may have been skipped. File it into intent-tree (L0–L4) via `/intent-discover`, then raise a Packet with `/intent-packets`, and return the implementation reality to canonical via `/intent-writeback` — that is the order", at the candidate-presentation temperature that avoids assertion (it does not change the decision-table result for the next move). When an orphan spec (a suspected un-drafted implementation) was detected in Step 2, include one block with its spec name and the guidance "This may have been implemented without going through a Packet. Even after the fact, raise a Packet with `/intent-packets` (making the unfixed spec explicit as Open Questions / Deferred), then return the implementation reality to canonical via `/intent-writeback` — that is the order", at the candidate-presentation temperature that avoids assertion (it does not change the decision-table result for the next move). **These two checks and the writeback omission (the freshness warning) are partitioned from upstream into three layers — tree layer → Packet layer → downstream layer — and when one spec matches multiple layers it is presented only in the single most-upstream layer so that no double warning is emitted** (do not re-emit a spec that matched upstream in the downstream orphan-spec / freshness warning; guide it as a staged remedy of `discover → packets → writeback`). When an unconsumed milestone (a milestone event recorded but whose corresponding revisit is unhandled) was detected in Step 3.7, include one block with its event name and the guidance "A milestone event is recorded, but the corresponding Decision revisit (Revisit reflection) may not yet have been consumed. Check the `Revisit when` matching / re-proposal for the corresponding Decision Rule via `/intent-improve` — that is the order", at the same position and temperature as the freshness warning (the candidate-presentation temperature that avoids assertion; it does not change the decision-table result for the next move).
-- (4) Open Questions: points that need user confirmation. Confirmation stays at presenting candidates in natural language, leaving the next-action decision to the user (one-way reporting).
+- (2) **The next move (exactly one, one line, always emphasized)**: present the skill name or "no action needed" **as a one-line summary** at a prominent leading position (**even when the default is slimmed down, this one line is never folded and is always shown**), then append the recommendation reason + judgment basis (which state of which deliverable it rests on) concisely. Translate the first-match result of the decision table (`rules/decision-table.md`) into **the action a human takes next**, not into the internal row number (**only the presentation changes; the first-match selection logic for which move to recommend is not changed**).
+- (3) **Candidate Packets (the pool of not-yet-packeted candidates)**: read the L4 "future addition candidates" of `.intent/intent-tree.md` with **Read / Glob / Grep only**, cross-check against `.intent/packets/archive/` and `.kiro/specs/` with the same text-matching means as the Step 2 orphan-spec / unfiled-state checks, narrow to the **unconsumed (neither packeted nor implemented) candidates**, and present them in the default as a bulleted list of **count + names**. Treat unmatchable cases as the norm, tolerate false positives, and stay at candidate presentation without assertion. **Candidates with a frozen mark (the Ice box below) are excluded from the count + names**. If L4 / archive / `.kiro/specs/` is absent, treat it as 0 and do not error.
+- (4) **Ice box notice (one line announcing the existence of frozen candidates)**: frozen candidates text-matched with **Read / Grep only** against frozen marks (`Deferred` / `保留` / `当面しない` / conditional hold, etc.) **are not shown in the body in the default**; instead, always include the one-line notice **"Frozen (Ice box): N. Show them with 'show me the icebox'"** in the default (if 0, omit the notice too to make the lead even lighter). Candidates with an ambiguous boundary (no mark but effectively shelved) are not treated as frozen and are shown on the (3) Candidate side (no assertion).
+- ⊕ **Dangerous notices (always shown in full in the default, never folded)**: the three kinds — **freshness warning (Step 3), packets integrity violations (index ↔ active/ divergence, lingering done / superseded_by, the latest export-log row's packet absent from active/), and unreflected 🔴** — are dangerous to miss, so **keep them shown in full in the default and do not fold them into (5) details**. When enforcement / drift-watch is off or unset, no freshness warning is emitted as before (existing behavior unchanged). **Warning-signal display split (INV32)**: here (the actual-impact context) `🔴` etc. are **emphasized as bare glyphs**, but in the explanatory context (legend, glossary, 0-count summary, empty rail) they are **not bare — toned down to inline code (`🔴`) / words ("unreflected")**. When the count is 0, show "no unreflected items" in words and emit no bare warning glyph (the warning's meaning is preserved).
+
+**[Details] pushed down to the folded position**
+
+- (5) **Details (the folded position)**: each deliverable's present/absent/unfilled state and notable points that back the signals in (1); the current Source Packet (the packet name based on the latest row of export-log) and whether its directory (`.intent/cc-sdd/<slug>/`) exists. The dangerous notices shown in the default at ⊕ also leave **a one-line summary "⚠ N present (see details)"** here to connect to the detail body (without removing them from the default). When index.md is absent, include the regeneration prompt; when drift-watch is `on` in Step 3.5, include the drift-log light tally (`caught N / missed N / false-positive N / unjudged N`) as one block here; when conformance staleness's right moment (the not-caught-up count at or above the threshold) was detected in Step 3.6, include the basis "which compass section was updated, and how many packets are not caught up" here. When an intent-tree unfiled state (a suspected discover skip) was detected in Step 2, include one block with its spec name and the guidance "Design/implementation has advanced, but it could not be text-matched to any L0–L4 node of `.intent/intent-tree.md`. The discover phase itself may have been skipped. File it into intent-tree (L0–L4) via `/intent-discover`, then raise a Packet with `/intent-packets`, and return the implementation reality to canonical via `/intent-writeback` — that is the order", at the candidate-presentation temperature that avoids assertion (it does not change the decision-table result for the next move). When an orphan spec (a suspected un-drafted implementation) was detected in Step 2, include one block with its spec name and the guidance "This may have been implemented without going through a Packet. Even after the fact, raise a Packet with `/intent-packets` (making the unfixed spec explicit as Open Questions / Deferred), then return the implementation reality to canonical via `/intent-writeback` — that is the order", at the candidate-presentation temperature that avoids assertion (it does not change the decision-table result for the next move). **These two checks and the writeback omission (the freshness warning) are partitioned from upstream into three layers — tree layer → Packet layer → downstream layer — and when one spec matches multiple layers it is presented only in the single most-upstream layer so that no double warning is emitted** (do not re-emit a spec that matched upstream in the downstream orphan-spec / freshness warning; guide it as a staged remedy of `discover → packets → writeback`). When an unconsumed milestone (a milestone event recorded but whose corresponding revisit is unhandled) was detected in Step 3.7, include one block with its event name and the guidance "A milestone event is recorded, but the corresponding Decision revisit (Revisit reflection) may not yet have been consumed. Check the `Revisit when` matching / re-proposal for the corresponding Decision Rule via `/intent-improve` — that is the order", at the same position and temperature as the freshness warning (the candidate-presentation temperature that avoids assertion; it does not change the decision-table result for the next move).
+- (6) Open Questions: points that need user confirmation. Confirmation stays at presenting candidates in natural language, leaving the next-action decision to the user (one-way reporting).
+
+**[Option] only on a natural-language trigger**
+
+- (7) **Ice box expansion**: only when the user requests via a natural-language trigger ("show me the icebox", etc.), expand the frozen candidates of (4) as **count + names + a short note of the freeze reason**. The expansion is also read-only with Read / Grep only; status changes nothing.
+
 - **Unset-or-absent display**: when a deliverable is unset or absent, show it in the `term (explanation): state` form — e.g. `Intent Tree (the hierarchical map of what you want to do): not created` — in plain English so that a reader who does not know the term can tell that the deliverable **does not yet exist / has no content**. Consistency-check violations (a stuck `superseded_by`, divergence from the index, an item remaining in archive, etc.) are shown the same way: annotate the term with its explanation and present in plain English **what is stuck / diverging and how**.
 
 ## Always-annotate rule for terms
 
-The terms that appear in the output are annotated with their meaning in the `term (explanation)` parenthetical form, by referring to the "Glossary" below. The concrete conventions are as follows.
+The terms that appear in the output are annotated with their meaning in the `term (explanation)` parenthetical form, by referring to the "Glossary" below. The annotation is **split into two layers — the lead (default) and the details (the folded position)**. The concrete conventions are as follows.
 
-- **Always-annotate rule**: the intent-planner-specific terms that appear in status output (deliverable names, state values, check terms, command names) are **kept in English as the canonical form and are never replaced by a translation**. Each term is annotated with a short plain-language explanation of its meaning, written in the `term (explanation)` parenthetical form. The annotation is **not limited to the first occurrence** — it is repeated every time the term appears in the output (status output is a fragmentary report whose visible items vary with the situation, so "first occurrence" is not stable; the priority is that the meaning is clear on the spot, every time).
+- **Two-layer annotation rule (lead = first occurrence / headers only; details = every time)**: the intent-planner-specific terms that appear in status output (deliverable names, state values, check terms, command names) are **kept in English as the canonical form and are never replaced by a translation**. Each term is annotated with a short plain-language explanation of its meaning, written in the `term (explanation)` parenthetical form. The annotation density is split by output layer: **in the lead (the slimmed-down default essentials), the annotation is limited to the first occurrence and table headers only** (to avoid lead redundancy and not bury "the next move"). **In the details (the folded position), the term is annotated every time it appears** (the details are a fragmentary report whose visible items vary with the situation, so "first occurrence" is not stable; the priority is that the meaning is clear on the spot, every time). The glossary itself is kept and the annotation is not abolished (the status-readability value of "readable even without knowing the term" is preserved on the details side).
 - **Avoiding redundancy in practice**: even when the same term recurs within a single output and full annotation would be redundant, no item is **left as the bare term**. In list / table item headers, keep the parenthetical annotation; in repeated in-prose mentions, the form may be tightened as long as the meaning remains traceable from context. When tightening the form, the condition is that the term's meaning stays traceable.
 
 ### Glossary
@@ -112,13 +130,15 @@ The terms that status refers to when producing output, with a one-line explanati
 
 **Progress rail (5 signals + stage annotation)** (cross-check a packet by `state` × whether export-log has a row × whether deltas has a corresponding entry, and assign one via first-match. Further, annotate each row with `[current stage → next stage(s) to pass through]`, re-reading packet `state` as a position on the fixed pipeline `discover→compass→packets→export→implement→verify→writeback`. The canonical determination lives in overview's `progress-readout.md` "Progress rail," not in `rules/decision-table.md`, but status's leading mini-rail uses the same five-signal vocabulary + stage annotation)
 
+> The signals in the legend are toned down to inline code (do not line up bare warning colors in the explanatory context = INV32). In the actual-impact context where a matching packet exists, they are shown in full as bare glyphs per INV31.
+
 | Signal | One-line explanation |
 |--------|----------------------|
-| ✅ reflected | implementation complete and written back into intent (`state: done` and a corresponding delta is promoted/closed) |
-| 🔵 you are here | the one stage currently being worked on (of the exported-not-yet-reflected, the current Source Packet = the latest export-log row) |
-| 🔴 unreflected | evidence of implementation exists but not yet reflected (of the exported-not-yet-reflected, those other than the current Source Packet = past leftovers) |
-| ⚪ not started | not yet exported to cc-sdd (no row in export-log) |
-| ◻ merged | merged into a successor packet and done with its role (`superseded_by` is non-empty) |
+| `✅` reflected | implementation complete and written back into intent (`state: done` and a corresponding delta is promoted/closed) |
+| `🔵` you are here | the one stage currently being worked on (of the exported-not-yet-reflected, the current Source Packet = the latest export-log row) |
+| `🔴` unreflected | evidence of implementation exists but not yet reflected (of the exported-not-yet-reflected, those other than the current Source Packet = past leftovers) |
+| `⚪` not started | not yet exported to cc-sdd (no row in export-log) |
+| `◻` merged | merged into a successor packet and done with its role (`superseded_by` is non-empty) |
 
 **Replacement axis**
 
@@ -152,12 +172,16 @@ The terms that status refers to when producing output, with a one-line explanati
 ## Output Description
 
 **Reader**: a human developer who wants to know, by the shortest path, "where am I now and what should I do next".
-**What this makes them grasp first**: (1) from the progress rail, "which packet is 🔵 you are here, and which stages remain after this", then (2) "exactly one next move". Internal terms (the matching, the integrity check, enforcement) are relegated to the details that follow. Compose the output in the order of Step 5 ((1) progress rail → (2) the next move → (3) details → (4) Open Questions).
-
-- (1) **Progress rail** (top, conclusion): lay out all packets vertically and annotate each row with the five signals + `[current stage → next stage(s) to pass through]` (the ⚪ remaining work and 🔴 unreflected items visible at a glance)
-- (2) **Exactly one next move** (with the recommendation reason and judgment basis)
-- (3) **Details**: the summary of the current position (existence and fill state per deliverable + notable points; includes the current Source Packet and whether its packet directory exists; when an enforcement violation is detected, includes the freshness warning quoting the intent-check stdout; when drift-watch is `on`, includes the drift-log light tally `caught N / missed N / false-positive N / unjudged N` as one block, and when it is not `on`, includes no such block; when conformance staleness's right moment (Step 3.6) is detected, includes the not-caught-up basis as one block, and when below the threshold, includes no such block). Also place here the result of the packets integrity check (the report of index ↔ active/ divergence, lingering done / superseded_by, and the latest export-log row's packet absent from active/; includes the regeneration prompt when the index is absent).
-- (4) Open Questions for a human to confirm
+**What this makes them grasp first**: slim down the default and present (1) from the progress rail, "which packet is 🔵 you are here, and which stages remain after this", then (2) "exactly one next move (one-line summary, never folded, always emphasized)", (3) Candidate Packets (the count + names of not-yet-packeted candidates), (4) a one-line Ice box notice. The "dangerous notices" (freshness warning, integrity violations, unreflected 🔴) are kept in full in the default. Internal terms (the matching, the integrity check, enforcement), check details, and the every-time term annotation are relegated to (5) details (the folded position) that follow. Compose the output in the three layers of Step 5 (default (1)–(4) + ⊕ dangerous notices → (5) details → (6) Open Questions → (7) Ice box expansion only on a trigger).
+
+- (1) **Progress rail** (default, conclusion): lay out all packets vertically and annotate each row with the five signals + `[current stage → next stage(s) to pass through]` (the `⚪` remaining work and `🔴` unreflected items visible at a glance; rows with an actual matching packet show bare glyphs)
+- (2) **Exactly one next move** (default, the one-line summary never folded and always emphasized, with the recommendation reason and judgment basis; only the presentation changes, the first-match selection logic is unchanged)
+- (3) **Candidate Packets** (default, count + names; the L4 unconsumed candidates read read-only; frozen-marked ones excluded; no assertion)
+- (4) **Ice box notice** (default, one line "Frozen (Ice box): N. Show them with 'show me the icebox'"; omitted if 0)
+- ⊕ **Dangerous notices** (kept in full in the default, never folded): freshness warning (quoting the intent-check stdout when an enforcement violation is detected), packets integrity violations (index ↔ active/ divergence, lingering done / superseded_by, the latest export-log row's packet absent from active/), unreflected 🔴
+- (5) **Details** (the folded position): the summary of the current position (existence and fill state per deliverable + notable points; includes the current Source Packet and whether its packet directory exists). The dangerous notices shown in the default at ⊕ also leave a one-line summary "⚠ N present (see details)" here. When drift-watch is `on`, includes the drift-log light tally `caught N / missed N / false-positive N / unjudged N` as one block, and when it is not `on`, includes no such block; when conformance staleness's right moment (Step 3.6) is detected, includes the not-caught-up basis as one block, and when below the threshold, includes no such block; includes the regeneration prompt when the index is absent.
+- (6) Open Questions for a human to confirm
+- (7) **Ice box expansion** (option, only on a natural-language trigger): expand the frozen candidates as count + names + a short note of the freeze reason
 
 ## Safety & Fallback
 - **Read-only declaration**: never create, modify, or delete any file (the frontmatter does not carry Write; Bash is limited to launching the read-only script `node .intent/scripts/intent-check.mjs` and does not change this property). drift-log is read via Read / Grep only (without widening what Bash launches and without writing to drift-log), and this read-only property is not changed.

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

@@ -25,7 +25,7 @@ description: After implementing an exported packet, record the learnings gained
 
 ### Step 2: Extract and present the learnings
 - Cross-check the implementation reality (the codebase, tests, and `.kiro/specs/`; all read-only) against the packet definition (the target packet file), the cc-sdd drafts, and intent-compass.md.
-- Extract learnings via the 5 perspectives of the rules ([decision] / [invariant-violation] / [implicit-behavior] / [deferred-resolved] / [question]) and present them as a tagged list.
+- Extract learnings via the 5 perspectives of the rules ([decision] / [invariant-violation] / [implicit-behavior] / [deferred-resolved] / [question]) and present them as a tagged list. Show each learning as `[tag] <a plain one-sentence summary (REQUIRED)>` (a plain sentence an approver can read directly and grasp), adding an optional `解説 (note):` only when background, rationale, or implications are needed (the note is not required; a summary-only learning is the normal form; see rules §2/§9).
 
 ### Step 3: Record the delta (canonical untouched)
 - Record the extracted learnings into `.intent/deltas.md` as a new entry (Status: pending).
@@ -33,7 +33,7 @@ description: After implementing an exported packet, record the learnings gained
 - At this stage, do not edit the canonical deliverables (intent-tree.md / intent-compass.md / the files under `.intent/packets/`) at all.
 
 ### Step 4: Confirm promotion (vary the approval granularity)
-- Vary the approval granularity by the kind of learning (rules §3 Stage 2). Do not ask about every item uniformly, one at a time.
+- Vary the approval granularity by the kind of learning (rules §3 Stage 2). Do not ask about every item uniformly, one at a time. The primary information for approval is each learning's plain one-sentence summary; the note is secondary, supplied only when needed.
 - **Gated items** (`[invariant-violation]` and `[decision]` that changes Decision Rules) are confirmed item by item.
 - **Everything else** (L3-append kind and `[question]` transcription) is presented as a list of reflection targets; ask whether there is any item to hold back, and promote in bulk if none is named.
 - For items held back (not approved), confirm one of "rejected (no re-proposal) | on-hold (re-propose at the next writeback)".
@@ -56,7 +56,7 @@ Lead the output with the conclusion (the promotion result and the completion pro
 - **Promotion result (top)**: what was promoted to canonical (intent-tree / intent-compass / packets), with reflection-target details. Show the deferred items distinguished by their declined tag "rejected (no re-proposal) / on-hold (re-propose next time)".
 - **Completion processing result (next)**: the target packet's `state: done` / `closed_at` / `spec_refs` entries, the move to `archive/<year>/`, and the index.md regeneration. Phrased so it is clear that "this packet is now closed".
 - **Promotion proposals** (if shown at the stage that asks for approval): gated items (invariant violations / Decision Rules changes) confirmed item by item; the L3-append kind presented as a list + naming the items to hold back.
-- **Details**: the list of extracted learnings (tagged with the 5 perspectives [decision]/[invariant-violation]/[implicit-behavior]/[deferred-resolved]/[question]) and the delta recording result (the entry in deltas.md).
+- **Details**: the list of extracted learnings (tagged with the 5 perspectives [decision]/[invariant-violation]/[implicit-behavior]/[deferred-resolved]/[question]; each line leads with its plain one-sentence summary and adds an optional note only when needed) and the delta recording result (the entry in deltas.md).
 
 ## Safety & Fallback
 - If the target packet cannot be identified, present the situation, ask the user to specify the write-back target, and stop.

package/templates/en/codex/skills/intent-writeback/rules/writeback-protocol.md

@@ -21,6 +21,8 @@ If the target still cannot be identified, present the situation (that it was not
 
 Cross-check the target packet's definition (the target packet file), the cc-sdd drafts (including the Intent-derived constraints), and intent-compass.md against the implementation reality (the codebase, tests, and `.kiro/specs/`; all read-only), and extract learnings from the following 5 perspectives. Tags map 1:1 to the perspectives. When reading the implementation reality, also include in the grep cross-check scope the code modules (file names, module names) named by Decision Rules (intent-compass.md), and you may extract a divergence between a Rule's main text and the implementation as an `[invariant-violation]`.
 
+Write each extracted learning as `[tag] <a plain one-sentence summary (REQUIRED)>`. The summary should be a plain sentence an approver who did not implement the packet can read directly and grasp — not a jargon-compressed noun phrase — even if it runs a little long for the sake of clarity. Only when background, rationale, or implications are needed, add an indented `  - 解説 (note): <…>` sub-line optionally below it (the note is not required; a summary-only learning is the normal form). This is the same format as the canonical deltas.md template in §9, and a learning extracted here is recorded into §9 in that very format.
+
 | Tag | Perspective |
 |------|------|
 | `[decision]` | A new decision (a judgment made during implementation that is not written in the packet definition) |
@@ -126,11 +128,15 @@ The following is **the source of truth** of the canonical deltas.md template; th
 
 ### Learnings
 
-- [decision] <a new decision>
-- [invariant-violation] <a discovered invariant violation>
-- [implicit-behavior] <implicit behavior not written in the intent>
-- [deferred-resolved] <a resolved Deferred>
-- [question] <a new unresolved Question>
+Write each learning as `[tag] <a plain one-sentence summary (REQUIRED)>`. The summary should be a plain sentence an approver can read directly and grasp — not a jargon-compressed noun phrase — even if it runs a little long for the sake of clarity. Only when background, rationale, or implications are needed, add an indented `  - 解説 (note): <…>` sub-line **optionally** below it (the note is not required; a summary-only learning is the normal form).
+
+- [decision] <a decision made during implementation that wasn't in the packet definition, in plain words>
+  - 解説 (note): <why this decision was reached — background or rationale (optional; omit if unneeded)>
+- [invariant-violation] <where an existing Invariant conflicts with the implementation reality, in plain words>
+  - 解説 (note): <which Invariant conflicts and how, and the intended response (optional)>
+- [implicit-behavior] <behavior not written in the intent that the implementation already exhibits, in plain words (usually summary-only)>
+- [deferred-resolved] <how a previously deferred item was resolved, in plain words>
+- [question] <a newly surfaced unresolved question, in plain words>
 
 ### Promotion record (when promoted / closed)
 

package/templates/en/intent/README.md

@@ -94,7 +94,7 @@ Another **optional cross-cutting layer** alongside enforcement. As implementatio
 
 **The default is off**, and nothing changes unless you configure it. Switch it to `on` by directly editing the "Drift-watch (user-managed)" section of `mode.md`.
 
-When on, `/intent-discover` runs a terrain diagnosis of the Intent Tree, and `/intent-export-cc-sdd` shows compass-matching warnings at the export waterline. **Both are warnings only and never stop you** (a separate concept from enforcement's `gate`; since false positives are assumed, there is no stopping value). Detections are recorded locally in `.intent/drift-log.md` (nothing is ever sent externally; it stays within `.intent/`).
+When on, `/intent-discover` runs a drift-prone-situation pre-check of the Intent Tree, and `/intent-export-cc-sdd` shows compass-matching warnings at the export waterline. **Both are warnings only and never stop you** (a separate concept from enforcement's `gate`; since false positives are assumed, there is no stopping value). Detections are recorded locally in `.intent/drift-log.md` (nothing is ever sent externally; it stays within `.intent/`).
 
 The basis is `.intent/drift-patterns.md` (a catalog of drift patterns). The distributed seed is not exhaustive; the premise is that **you grow it by adding the drifts you actually hit in your own work** as patterns. Aggregation (the improvement report) adds no new command — it rides on the light summary in `/intent-status` and the pattern×outcome cross-tabulation in `/intent-improve`.
 

package/templates/en/intent/constraint-starters.md

@@ -1,6 +1,6 @@
 # Constraint Starters (catalog of constraint starting points)
 
-> Read by `/intent-compass` (primary touchpoint) and `/intent-discover` (terrain diagnosis lane) as **draft candidates** when writing Anti-direction / Invariants. It is the source set for matching bundled domain conventions against your context to surface "this case is probably this." **Surfacing is a read-only draft; transcription into the compass happens manually after a human picks what to adopt** (the AI does not auto-transcribe). Constraints you personally reuse are grown in a separate file, `constraint-library.md`.
+> Read by `/intent-compass` (primary touchpoint) and `/intent-discover` (drift-prone-situation pre-check lane) as **draft candidates** when writing Anti-direction / Invariants. It is the source set for matching bundled domain conventions against your context to surface "this case is probably this." **Surfacing is a read-only draft; transcription into the compass happens manually after a human picks what to adopt** (the AI does not auto-transcribe). Constraints you personally reuse are grown in a separate file, `constraint-library.md`.
 
 ## How to read this catalog
 

package/templates/en/intent/deltas.md

@@ -22,11 +22,15 @@
 
 ### Learnings
 
-- [decision] <a new decision>
-- [invariant-violation] <a discovered invariant violation>
-- [implicit-behavior] <implicit behavior not written in the intent>
-- [deferred-resolved] <a resolved Deferred>
-- [question] <a new unresolved Question>
+Write each learning as `[tag] <a plain one-sentence summary (REQUIRED)>`. The summary should be a plain sentence an approver can read directly and grasp — not a jargon-compressed noun phrase — even if it runs a little long for the sake of clarity. Only when background, rationale, or implications are needed, add an indented `  - 解説 (note): <…>` sub-line **optionally** below it (the note is not required; a summary-only learning is the normal form).
+
+- [decision] <a decision made during implementation that wasn't in the packet definition, in plain words>
+  - 解説 (note): <why this decision was reached — background or rationale (optional; omit if unneeded)>
+- [invariant-violation] <where an existing Invariant conflicts with the implementation reality, in plain words>
+  - 解説 (note): <which Invariant conflicts and how, and the intended response (optional)>
+- [implicit-behavior] <behavior not written in the intent that the implementation already exhibits, in plain words (usually summary-only)>
+- [deferred-resolved] <how a previously deferred item was resolved, in plain words>
+- [question] <a newly surfaced unresolved question, in plain words>
 
 ### Promotion record (when promoted / closed)
 

package/templates/en/intent/drift-log.md

@@ -36,6 +36,6 @@ The "worked" family and the "did not work" family are enumerated symmetrically.
 |---|---|
 | `prevented` (prevention succeeded at discover) | `missed` (could not prevent it, it got through) |
 | `caught` (capture succeeded at export) | `false-positive` (it was a false alarm) |
-| | `not-applicable` (not present in the terrain; a swing and a miss) |
+| | `not-applicable` (not present in the situation; a swing and a miss) |
 
 Tallying assumes a `pattern × outcome` cross-tabulation. Read `missed=0` as "a suspicion of missing records," not as "it worked."

package/templates/en/intent/drift-patterns.md

@@ -1,13 +1,13 @@
 # Drift Patterns (catalog of drift types)
 
-> Read by `/intent-discover` as the basis for terrain diagnosis (when `drift-watch: on`). This is a file you grow by adding, as types, the drifts you actually hit in your own project.
+> Read by `/intent-discover` as the basis for drift-prone-situation pre-check (when `drift-watch: on`). This is a file you grow by adding, as types, the drifts you actually hit in your own project.
 
 ## How to read this catalog
 
 - **This is not exhaustive.** The types listed here are only a starting point (1 seed + 2 generic). The premise is that you append the drifts you actually hit in your own project as types and grow this file over time.
-- Each type is matched against `drift-log.md` by its aggregation key (`id`). The more types you add, the wider the range over which you can name "easy-to-drift terrain" before you start work.
+- Each type is matched against `drift-log.md` by its aggregation key (`id`). The more types you add, the wider the range over which you can name "drift-prone situation" before you start work.
 - The two bundled generic types (`premature-abstraction` / `layer-leak`) are placed as **weak cues with different symptoms**. They are deliberately varied so your thinking does not fixate on a single strong representative example (`microservice-over-split`).
-- "Matching" a type is not a confirmation of drift. Terrain diagnosis assumes false positives. When a type matches, you **write the anti-direction / invariant first** to act before you drift all the way out.
+- "Matching" a type is not a confirmation of drift. The drift-prone-situation pre-check assumes false positives. When a type matches, you **write the anti-direction / invariant first** to act before you drift all the way out.
 
 ## How to write a type
 
@@ -53,7 +53,7 @@ Append a new type with the schema below. Make `id` a unique kebab-case aggregati
 
 ## id: coinage-proliferation
 
-- name: Coinage-prone terrain
+- name: Coinage-prone situation
 - symptom: The AI keeps coining new terms that are absent from the canonical vocabulary (ubiquitous language) instead of reusing terms that already exist. Several phrasings pile up for the same concept, the vocabulary fragments, and the alignment of intent (the core of the product) erodes.
 - Things to write first:
   - Anti-direction: Do not invent a new term for a concept that already has a canonical term. If you must introduce a new term, attach a one-line explanation at first occurrence.
@@ -61,7 +61,7 @@ Append a new type with the schema below. Make `id` a unique kebab-case aggregati
 
 ## id: scope-creep
 
-- name: Scope-creep-prone terrain
+- name: Scope-creep-prone situation
 - symptom: An implementation instruction arrives later that exceeds an already-exported work unit's (packet's) declared scope (e.g., a front-end-only packet being asked to add back-end, authorization, or transaction-boundary work). Each addition feels locally natural, yet the packet-specific invariants that newly become necessary in the new territory (authorization, data consistency, transaction boundaries, idempotency) keep being left out as work piles up.
 - Things to write first:
   - Anti-direction: Do not push instructions that exceed an exported packet's `## Scope` straight through cc-sdd. Return the new territory to intent as a separate packet.

package/templates/en/intent/glossary.md

@@ -17,7 +17,7 @@
 | canonical vocabulary | ubiquitous language | The correct terms themselves registered in the ledger. A suspected coinage is judged as a term absent from this set. |
 | coinage-suspect | suspected coinage | The ID of the detection check that names, read-only, any term absent from the canonical vocabulary as a suspected coinage. |
 | glossary | vocabulary ledger | The lightweight canonical ledger (this file) that gathers canonical terms plus spelling variants / synonyms. The home of the mother-set. |
-| drift | — | A way of progressing that gradually departs from the original intent. drift-patterns catalogs it as terrain types. |
+| drift | — | A way of progressing that gradually departs from the original intent. drift-patterns catalogs it as situation types. |
 | packet | — | The minimal unit of intent handed from intent to spec / implementation. Its provenance is stamped in frontmatter. |
 | compass | intent-compass | The compass that folds intent into Decision Rules and Invariants. |
 | intent tree | intent-tree | The canonical body of intent that holds objective / problem / direction in a hierarchy. |

package/templates/en/intent/mode.md

@@ -28,5 +28,5 @@
 
 - **drift-watch** — strength of drift monitoring. One of `off` | `on`:
   - `off` (default): does nothing. Same behavior as before.
-  - `on`: terrain diagnosis at discover, compass-conformance warnings at the export boundary, and logs detections to drift-log.md. **All warning-only; never stops** (distinct from enforcement's gate; assumed to have false positives, so it does not stop).
+  - `on`: drift-prone-situation pre-check at discover, compass-conformance warnings at the export boundary, and logs detections to drift-log.md. **All warning-only; never stops** (distinct from enforcement's gate; assumed to have false positives, so it does not stop).
 - Toggle by editing this file directly. Only the two values off|on; there is no stopping (gate-equivalent) value. Unspecified / invalid values are treated as off and do not stop.

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

@@ -69,6 +69,7 @@ cc-sdd の流儀に揃える。
 - **問いは自己完結文にする**: 利用者への問い・確認の文面は、術語を知らなくても回答できる自己完結文とする。術語を使う場合は、問い文面の中に一行説明を含める（例: 「最初の packet（作業単位）が、入力から出力まで一通り動く最小実装（walking skeleton）になっているかを確認します」）。
 - **術語は英語のまま + 一行説明**: 術語を日本語の訳語に置換しない。説明が要る場合は、機能・意味を述べる一行説明（括弧書きまたは blockquote）を初出箇所に添える。
 - **造語を勝手に作らない**: 正規語彙（ubiquitous language＝intent 成果物で既に使われている合意済みの用語の集合）に無い新造の語を勝手に作らず、既存の語を再利用する。どうしても新しい語を導入する場合は、初出箇所に一行説明を添える。
+- **設計文書で導入する語は識別子に限り、説明文中の比喩の呼び名は普通の記述語で書く**: 設計文書（SKILL.md / rules / 規約文書 / `.intent` 成果物）で語を導入するとき、横断参照される識別子（コマンド名・frontmatter キー・ファイル名・ログ値・glossary 見出し）だけを残し、説明文の中だけで使う比喩の呼び名（書き手の語感で生まれ、機能を説明しているわけでもない語）は作らず、普通の記述語で書く。識別子は消すと参照が壊れるため一行説明を添えて残す。比喩の呼び名は普通の言葉に開く（読み手が語の意味を別途学ばなくても文意が取れるようにする）。
 
 ## スキル間の状態共有
 

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

@@ -38,4 +38,4 @@
 
 ## discover との関係
 
-- discover の地形診断レーン（`drift-terrain.md`）でも、`drift-watch: on` のとき同じカタログを薄く照合して早期に気づかせる。本手順（compass）が主接点であり、discover は補助。
+- discover の逸脱しやすい場面の事前チェックレーン（`drift-terrain.md`）でも、`drift-watch: on` のとき同じカタログを薄く照合して早期に気づかせる。本手順（compass）が主接点であり、discover は補助。

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

@@ -14,8 +14,8 @@ argument-hint: <課題・アイデア・対象範囲>
   - Intent の詰め方モードが推奨・確認され、`.intent/mode.local.md`（mode 状態のローカル正本）に記録されている
   - 問いの代行（designer-questions）の要否が確認され `.intent/mode.local.md` に記録されている（on の場合は purpose も。保留時は Open Questions に告知）
   - 人間が確認すべき Open Questions が明示されている
-  - drift-watch が on のとき、地形診断を行い該当型を名指しして drift-log に記録している（off のときは何もしない）
-  - drift-watch が on のとき、context-cost-cues を照合してコンテキストを食う進め方を気づき口調で名指している（どのログにも記録しない・off のときは何もしない）
+  - drift-watch が on のとき、逸脱しやすい場面の事前チェックを行い該当型を名指しして drift-log に記録している（off のときは何もしない）
+  - drift-watch が on のとき、context-cost-cues を照合してコンテキストを食う進め方を指図せず気づかせる言い方で名指している（どのログにも記録しない・off のときは何もしない）
   - アプリケーションコードを一切変更していない
 
 ## Execution Steps
@@ -37,9 +37,9 @@ argument-hint: <課題・アイデア・対象範囲>
 - 確定した意図と推測（Assumptions）を分離する。未確定は Open Questions に置く。
 - 既存の `.intent/intent-tree.md` があれば読み、上書きではなく追記・更新案として提示する。
 
-### Step 3.5: 地形診断（drift-watch）
-- Step 1 で読んだ `.intent/mode.md` の `## Drift-watch（ユーザー管理）` セクションから `drift-watch` の値を確認する。`on` でないとき（off・未記載・不正値・セクション不在・mode.md 不在を含む）は地形診断を行わず、現行どおり Step 4 へ続行する（現行動作とバイト等価）。
-- `on` のときのみ、`rules/drift-terrain.md` を読み、適用する。symptom × 構築中 Intent Tree の照合・該当型の名指し提示・anti-direction / invariant 候補の Open Questions への起案・drift-log への append は、すべて rule の手順に委ねる（ここに手順を複製しない）。同 rule 末尾の「コンテキストコストの気づき」節も併せて適用し、`.intent/context-cost-cues.md` の型を照合してコンテキストを食う進め方を気づき口調で名指す（どのログにも記録しない・カタログ不在ならスキップ）。
+### Step 3.5: 逸脱しやすい場面の事前チェック（drift-watch）
+- Step 1 で読んだ `.intent/mode.md` の `## Drift-watch（ユーザー管理）` セクションから `drift-watch` の値を確認する。`on` でないとき（off・未記載・不正値・セクション不在・mode.md 不在を含む）は逸脱しやすい場面の事前チェックを行わず、現行どおり Step 4 へ続行する（現行動作とバイト等価）。
+- `on` のときのみ、`rules/drift-terrain.md` を読み、適用する。symptom × 構築中 Intent Tree の照合・該当型の名指し提示・anti-direction / invariant 候補の Open Questions への起案・drift-log への append は、すべて rule の手順に委ねる（ここに手順を複製しない）。同 rule 末尾の「コンテキストコストの気づき」節も併せて適用し、`.intent/context-cost-cues.md` の型を照合してコンテキストを食う進め方を指図せず気づかせる言い方で名指す（どのログにも記録しない・カタログ不在ならスキップ）。
 
 ### Step 4: 提示する
 - `.intent/intent-tree.md` の更新案を提示する。

package/templates/ja/claude/skills/intent-discover/rules/drift-terrain.md

@@ -1,24 +1,24 @@
-# Drift Terrain（地形診断）
+# Drift Terrain（逸脱しやすい場面の事前チェック）
 
-`/intent-discover` の Step 3.5 で使う、symptom × 構築中 Intent Tree の照合ロジック。`drift-watch: on` のときだけ走る（off / 未記載 / 不正値は何もしない）。着手前に「この題材は踏みやすい地形だ」と名指しし、外れきる前に anti-direction / invariant を先に書かせるのが目的。
+`/intent-discover` の Step 3.5 で使う、symptom × 構築中 Intent Tree の照合ロジック。`drift-watch: on` のときだけ走る（off / 未記載 / 不正値は何もしない）。着手前に「この題材は逸脱しやすい場面だ」と名指しし、外れきる前に anti-direction / invariant を先に書かせるのが目的。
 
 ## 診断の根拠は型カタログのみ
 
 - **診断の根拠は `.intent/drift-patterns.md` の型カタログだけ**にする。discover の段階では compass も packet もまだ無いため、照合できる材料は型カタログしかない（本質的な制約）。compass の Invariant / Anti-direction を根拠にした照合は export 工程（drift-watch の別フック）の役目であり、ここでは行わない。
-- 地形診断は**誤検知前提**。型に「該当した」ことは逸脱の確定ではない。弱い手がかりで早めに名指しし、空振りも含めて記録する。
+- 逸脱しやすい場面の事前チェックは**誤検知前提**。型に「該当した」ことは逸脱の確定ではない。弱い手がかりで早めに名指しし、空振りも含めて記録する。
 
 ## 手順
 
 1. **drift-patterns.md を読む**
    - `.intent/drift-patterns.md` を読み、全型（seed + 利用者が育てた型すべて）を取得する。
-   - **不在のとき**: 地形診断をスキップし、その旨を利用者に告知する（停止しない / drift-log にも書かない）。以降の手順は実行しない。
+   - **不在のとき**: 逸脱しやすい場面の事前チェックをスキップし、その旨を利用者に告知する（停止しない / drift-log にも書かない）。以降の手順は実行しない。
 
 2. **各型の symptom を構築中の Intent Tree と照合する**
    - 各型の `symptom` を、いま構築している Intent Tree の**題材（topic）と L0–L3**（目的 / 成果 / 能力 / 振る舞い・設計意図）に照らす。
    - `symptom` は**弱い手がかり**であって「当てはまったら必ず逸脱」という強い判定条件ではない。誤検知前提で、疑わしければ拾う。
 
 3. **該当型があるとき**
-   - 利用者に**名指しで提示**する。例:「この題材は `<id>` を踏みやすい地形です」。
+   - 利用者に**名指しで提示**する。例:「この題材は `<id>` を逸脱しやすい場面です」。
    - その型の「先に書かせるもの」（Anti-direction / Invariant 候補）を、Intent Tree の **Open Questions / anti-direction 候補**へ追記する。題材に依存する部分は文脈から具体化する（型カタログの汎用文をそのまま貼らず、いまの題材に即した文面にする）。
    - `drift-log.md` へ1エントリ append する（後述の append 手順）。値は:
      - `pattern: <該当型の id>`
@@ -43,7 +43,7 @@
      - `user-verdict: unjudged`
      - `recorded_at: <ISO 8601>`
      - `commit: <短縮ハッシュ | ->`
-     - `note: <1〜2行>`（地形に該当型が無かった旨）
+     - `note: <1〜2行>`（場面に該当型が無かった旨）
 
 ## drift-log への append 手順
 
@@ -56,7 +56,7 @@
 
 ## コンテキストコストの気づき（drift-watch 連動）
 
-地形診断と並んで、コンテキスト（トークン）を食う進め方に**気づかせる**照合を行う。drift-patterns（意図逸脱の型）とは**別カタログ**であり、症状（symptom）が「意図逸脱」ではなく「コンテキストを食う場面」である点だけが異なる。これは規範ではなく気づきであり、上の drift-patterns 照合とは性質が違うので**手順を分けて持つ**。
+逸脱しやすい場面の事前チェックと並んで、コンテキスト（トークン）を食う進め方に**気づかせる**照合を行う。drift-patterns（意図逸脱の型）とは**別カタログ**であり、症状（symptom）が「意図逸脱」ではなく「コンテキストを食う場面」である点だけが異なる。これは規範ではなく気づきであり、上の drift-patterns 照合とは性質が違うので**手順を分けて持つ**。
 
 - **`drift-watch: on` のときだけ**この照合を行う（off / 未記載 / 不正値のとき何もしない）。`.intent/context-cost-cues.md` が不在のときは照合をスキップしてその旨を告知する（停止しない）。
 - **これはどのログにも記録しない**。上の drift-patterns 照合（該当・空振りで `drift-log.md` へ append する）とは異なり、コンテキストコストの気づきは **`drift-log.md` にも他のどのログにも append しない**。理由: 消費量は計測できず outcome を評価できないため、ログに混ぜると drift-log の集計を推測値で汚す。さらに何が文脈を食うかは人により正当に異なり、記録すればプライバシーに踏み込む。**上の「drift-log への append 手順」をこの照合には適用しない**。
@@ -71,7 +71,7 @@
    - 照合に使うのは構築中の Intent Tree の題材のみ。トークン消費量・git 差分・実行時メトリクスは読まない。
 
 3. **該当型があるとき（気づきの提示・ログには書かない）**
-   - 利用者に気づき口調で名指しする。例:「この題材は `<id>` に当てはまるかもしれません — これがコンテキストを食っている可能性があります」。
+   - 利用者に指図せず気づかせる言い方で名指しする。例:「この題材は `<id>` に当てはまるかもしれません — これがコンテキストを食っている可能性があります」。
    - その型の「もし意図せず効いていれば」の軽い代替（薄い入口 / JIT pull / 入力限定）を、**任意の選択肢**として添える。例:「もし意図せず効いていれば、<軽い代替> もあります（判断はお任せします）」。
    - **矯正・指図をしない**。命令形・断定で言わず、気づきの提示に留める。大量スキルの導入・全文ロード等は正当な高コスト選択でありうるので、コストを食う選択を不要と断じない。判断は利用者に委ねる。
    - **どのログにも append しない**（drift-patterns 照合の append 手順を流用しない）。
@@ -81,7 +81,7 @@
 
 ## 制約の叩き台の気づき（drift-watch 連動）
 
-地形診断と並んで、ドメイン定石の叩き台に**早く気づかせる**薄い照合を行う。これは compass を主接点とする制約叩き台の候補提示（`intent-compass/rules/constraint-surfacing.md`）の discover 側の補助であり、上の照合とは別カタログ（`.intent/constraint-starters.md`＝再利用したい制約定石）を見る。意図逸脱・コンテキストコストとは症状が異なるので**手順を分けて持つ**。
+逸脱しやすい場面の事前チェックと並んで、ドメイン定石の叩き台に**早く気づかせる**薄い照合を行う。これは compass を主接点とする制約叩き台の候補提示（`intent-compass/rules/constraint-surfacing.md`）の discover 側の補助であり、上の照合とは別カタログ（`.intent/constraint-starters.md`＝再利用したい制約定石）を見る。意図逸脱・コンテキストコストとは症状が異なるので**手順を分けて持つ**。
 
 - **`drift-watch: on` のときだけ**この照合を行う（off / 未記載 / 不正値のとき何もしない）。`.intent/constraint-starters.md` が不在のときは照合をスキップしてその旨を告知する（停止しない）。
 - **これはどのログにも記録しない**。上の drift-patterns 照合（`drift-log.md` へ append する）とは異なり、制約の叩き台の気づきは **`drift-log.md` にも他のどのログにも append しない**（context-cost-cues の気づきと同じ扱い）。
@@ -97,7 +97,7 @@
    - 照合に使うのは構築中の Intent Tree の題材のみ。コード差分・実行時メトリクスは読まない。
 
 3. **該当する定石があるとき（気づきの提示・ログには書かない）**
-   - 利用者に気づき口調で名指しする。例:「この題材は `<id>`（<name>）に当てはまるかもしれません — compass で叩き台として検討できます」。押し付けず、候補を絞る。
+   - 利用者に指図せず気づかせる言い方で名指しする。例:「この題材は `<id>`（<name>）に当てはまるかもしれません — compass で叩き台として検討できます」。押し付けず、候補を絞る。
    - 詳しい叩き台（Anti-direction 候補・Invariant 候補）の提示と採否は **compass（主接点）に委ねる**。discover では「この定石が効きそう」と早期に気づかせるまで。
    - **どのログにも append しない**。
 

package/templates/ja/claude/skills/intent-export-cc-sdd/rules/drift-export-check.md

@@ -4,7 +4,7 @@
 
 ## 照合の根拠は compass
 
-- **照合の根拠は `.intent/intent-compass.md` の North Star / Anti-direction / Invariants** にする。export の段階では compass が既に存在するため、ここでは型カタログ（`.intent/drift-patterns.md`）ではなく compass を根拠にする（discover の地形診断は compass も packet もまだ無いため型カタログを根拠にする。export はその姉妹工程で、根拠が compass である点が違い）。
+- **照合の根拠は `.intent/intent-compass.md` の North Star / Anti-direction / Invariants** にする。export の段階では compass が既に存在するため、ここでは型カタログ（`.intent/drift-patterns.md`）ではなく compass を根拠にする（discover の逸脱しやすい場面の事前チェックは compass も packet もまだ無いため型カタログを根拠にする。export はその姉妹工程で、根拠が compass である点が違い）。
 - 水際照合は**誤検知前提**。compass の要素に「抵触した」ことは逸脱の確定ではない。妥当な設計を誤って拾うこと（false-positive）を最初から織り込み、空振りも含めて記録する。
 - **この照合は方向の関所であり、停止しない**。enforcement ゲート（手続きの関所・停止しうる）とは検査対象が直交する。drift の検知で export を止めることはしない（停止できるのは Step 1.5 の enforcement ゲートだけ）。
 

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

@@ -4,7 +4,7 @@
 
 ## 照合の根拠は compass
 
-- **照合の根拠は `.intent/intent-compass.md` の North Star / Anti-direction / Invariants** にする。export の段階では compass が既に存在するため、ここでは型カタログ（`.intent/drift-patterns.md`）ではなく compass を根拠にする（discover の地形診断は compass も packet もまだ無いため型カタログを根拠にする。export はその姉妹工程で、根拠が compass である点が違い）。
+- **照合の根拠は `.intent/intent-compass.md` の North Star / Anti-direction / Invariants** にする。export の段階では compass が既に存在するため、ここでは型カタログ（`.intent/drift-patterns.md`）ではなく compass を根拠にする（discover の逸脱しやすい場面の事前チェックは compass も packet もまだ無いため型カタログを根拠にする。export はその姉妹工程で、根拠が compass である点が違い）。
 - 水際照合は**誤検知前提**。compass の要素に「抵触した」ことは逸脱の確定ではない。妥当な設計を誤って拾うこと（false-positive）を最初から織り込み、空振りも含めて記録する。
 - **この照合は方向の関所であり、停止しない**。enforcement ゲート（手続きの関所・停止しうる）とは検査対象が直交する。drift の検知で export を止めることはしない（停止できるのは Step 1.5 の enforcement ゲートだけ）。
 

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

@@ -16,7 +16,7 @@ argument-hint: <対象範囲（任意）>
   - 書き戻し未実施の学びを検出したら、自ら delta を書かず `/intent-writeback` の実行を促している
   - 5分類に `Decision Rules 更新推奨` または `invariant 違反検出` を含む回では、`rules/improve-axes.md` の規定に従い `/intent-validate`（conformance 追従の点検）の実行を併せて促している（含まない回では促さない。誘導のみで自らは conformance 判定をしない）
   - drift-watch が on のとき coherence 検出を drift-log に stage:improve・outcome:missed で記録し pattern×outcome 改善度レポートを出している（off / 未記載 / 不正値 / 節不在 / mode.md 不在のとき何もしない。5分類は不変）
-  - drift-watch が on のとき context-cost-cues を照合してコンテキストを食う進め方を気づき口調で名指している（どのログにも記録せず・pattern×outcome 集計にも含めず・5分類は不変・off のとき何もしない）
+  - drift-watch が on のとき context-cost-cues を照合してコンテキストを食う進め方を指図せず気づかせる言い方で名指している（どのログにも記録せず・pattern×outcome 集計にも含めず・5分類は不変・off のとき何もしない）
   - アプリケーションコードを一切変更していない
 
 ## Execution Steps
@@ -36,7 +36,7 @@ argument-hint: <対象範囲（任意）>
 - 評価結果を5分類（aligned / intent 強化推奨 / 是正 packet 推奨 / Decision Rules 更新推奨 / invariant 違反検出。複数該当可）し、分類ごとに整理して提示する。
 - 書き戻し未実施の学びや「保留」タグ付きの見送り項目を検出したら、`rules/improve-axes.md` の規定に従い `/intent-writeback` への誘導を併記する。
 - 5分類に `Decision Rules 更新推奨` または `invariant 違反検出` を含む回は、`rules/improve-axes.md` の「validate 追従誘導」規定に従い `/intent-validate`（conformance 追従の点検）への誘導を writeback 誘導と並置で併記する（含まない回は併記しない。誘導のみで自らは判定しない）。
-- drift-watch が on のとき（off / 未記載 / 不正値 / 節不在 / mode.md 不在は何もしない）: `.intent/mode.md` の `## Drift-watch（ユーザー管理）` セクションの `drift-watch` 値を確認し、`on` のときのみ、`rules/improve-axes.md` の規定に従い coherence 軸で検出した逸脱（invariant 違反 / anti-direction 抵触）を `.intent/drift-log.md` へ `stage: improve` / `outcome: missed` の下書きとして記録し、`pattern × outcome` クロス集計の改善度レポートを出す。記録手順の詳細（9キー固定順・append-only・commit 取得・drift-log 不在時の新規作成）は `rules/improve-axes.md` に委ねる（ここでは重複させない）。この記録は**新しい是正分類を作らず**（上の5分類は不変）、deltas.md への書き込みや writeback フックも行わない。off / 未記載 / 不正値 / 節不在 / mode.md 不在のときは drift 記録・集計を行わず現行どおり進む（現行動作とバイト等価）。なお上の5分類の報告は drift-watch の値によらず常に行う。あわせて `drift-watch: on` のとき、`rules/improve-axes.md` 末尾の「コンテキストコストの気づき」節に従い `.intent/context-cost-cues.md` を照合してコンテキストを食う進め方を気づき口調で名指す（**どのログにも記録せず・pattern × outcome 集計にも含めず・5分類も不変**。カタログ不在ならスキップ）。
+- drift-watch が on のとき（off / 未記載 / 不正値 / 節不在 / mode.md 不在は何もしない）: `.intent/mode.md` の `## Drift-watch（ユーザー管理）` セクションの `drift-watch` 値を確認し、`on` のときのみ、`rules/improve-axes.md` の規定に従い coherence 軸で検出した逸脱（invariant 違反 / anti-direction 抵触）を `.intent/drift-log.md` へ `stage: improve` / `outcome: missed` の下書きとして記録し、`pattern × outcome` クロス集計の改善度レポートを出す。記録手順の詳細（9キー固定順・append-only・commit 取得・drift-log 不在時の新規作成）は `rules/improve-axes.md` に委ねる（ここでは重複させない）。この記録は**新しい是正分類を作らず**（上の5分類は不変）、deltas.md への書き込みや writeback フックも行わない。off / 未記載 / 不正値 / 節不在 / mode.md 不在のときは drift 記録・集計を行わず現行どおり進む（現行動作とバイト等価）。なお上の5分類の報告は drift-watch の値によらず常に行う。あわせて `drift-watch: on` のとき、`rules/improve-axes.md` 末尾の「コンテキストコストの気づき」節に従い `.intent/context-cost-cues.md` を照合してコンテキストを食う進め方を指図せず気づかせる言い方で名指す（**どのログにも記録せず・pattern × outcome 集計にも含めず・5分類も不変**。カタログ不在ならスキップ）。
 
 ### Step 4: 是正案を提案ごとに承認確認する
 - 是正が必要な項目ごとに是正案（成果物の更新案または是正 packet 案）を提示し、**提案ごとに**ユーザーの承認を確認する（一括承認を強要しない）。