arreio 1.1.0 → 1.2.1

package/skills/plan/references/plan-tier-selection.md

@@ -2,8 +2,8 @@
 title: Plan Tier Selection
 description: Reference for the Generate phase. Defines the Fast/Standard/Deep tier model, the selection algorithm that combines complexity, risk, and user preference, and the template sections each tier requires.
 type: reference
-version: 1.1
-timestamp: "2026-08-07"
+version: 1.2
+timestamp: "2026-10-01"
 ---
 
 # Plan Tier Selection
@@ -24,40 +24,45 @@ Tier selection happens at the start of the Generate phase, after reading the Des
 
 ## Selection Algorithm
 
+Tier selection is **two pure functions**. Run them step by step with the real values; never shortcut to a "typical" tier.
+
+Values are compared case-insensitively (`HIGH` = `High`). `risk_level` comes from the Research Findings; `complexity` from the Design Artifact.
+
 ```
-function select_tier(complexity, risk_level, user_preference):
-  # 1. Start from complexity-driven default
-  if complexity in [TRIVIAL, LOW]:
-    base_tier = Fast
-  elif complexity == MEDIUM:
-    base_tier = Standard
-  else:  # HIGH or VERY_HIGH
-    base_tier = Deep
-
-  # 2. Upgrade tier if risk warrants it
-  if risk_level == HIGH and base_tier == Fast:
-    base_tier = Standard
-  if risk_level == CRITICAL:
-    base_tier = Deep
-
-  # 3. Honor explicit user preference (never downgrade below risk floor)
-  if user_preference == "fast" and risk_level not in [HIGH, CRITICAL]:
-    return Fast
-  if user_preference == "deep":
-    return Deep
-  if user_preference == "standard" and risk_level != CRITICAL:
-    return Standard
-
-  return base_tier
+# A. Recommendation — computed in the Design phase (Step 4) and re-computed in Generate (Step 1).
+#    Depends ONLY on complexity and risk. Never on user input or --deep.
+function recommend_tier(complexity, risk_level):
+  # 1. Complexity-driven default
+  if complexity in [TRIVIAL, LOW]:   tier = Fast
+  elif complexity == MEDIUM:         tier = Standard
+  else:  # HIGH or VERY_HIGH         tier = Deep
+
+  # 2. Risk floor (see table below) — may only raise the tier
+  if risk_level == HIGH and tier == Fast: tier = Standard
+  if risk_level == CRITICAL:              tier = Deep
+  return tier
+
+# B. Selection — computed in the Generate phase (Step 1).
+function select_tier(complexity, risk_level, user_preference, force_deep):
+  recommended = recommend_tier(complexity, risk_level)
+  floor       = risk_floor(risk_level)            # Fast | Standard | Deep
+
+  if force_deep:                       return Deep                  # explicit user request; always honored
+  if user_preference == "auto":        return recommended           # Auto = the algorithm, NOT a fixed tier
+  # Explicit tier: honor it, but never go below the risk floor
+  return max(user_preference, floor)   # order: Fast < Standard < Deep
 ```
 
+`tier_recommended` is **always** `recommend_tier(...)` — it is never changed by user preference or `--deep`. `tier` is `select_tier(...)`. When they differ, the plan records an auditable override.
+
 ### Inputs
 
-| Input             | Source                          | Values                                |
-| ----------------- | ------------------------------- | ------------------------------------- |
-| `complexity`      | Design Artifact                 | TRIVIAL, LOW, MEDIUM, HIGH, VERY_HIGH |
-| `risk_level`      | Research Findings Artifact      | LOW, MEDIUM, HIGH, CRITICAL           |
-| `user_preference` | User (asked in Generate Step 1) | `fast`, `standard`, `deep`, or `auto` |
+| Input             | Source                                              | Values                                |
+| ----------------- | --------------------------------------------------- | ------------------------------------- |
+| `complexity`      | Design Artifact                                     | TRIVIAL, LOW, MEDIUM, HIGH, VERY_HIGH |
+| `risk_level`      | Research Findings Artifact                          | LOW, MEDIUM, HIGH, CRITICAL           |
+| `user_preference` | User (asked in Generate Step 1; see mode behavior)  | `fast`, `standard`, `deep`, or `auto` |
+| `force_deep`      | Orchestrator context (`--deep` flag, SKILL.md)      | `true` or `false` (default `false`)   |
 
 ### Risk Floor
 
@@ -72,6 +77,22 @@ The risk level sets a **minimum tier** that user preference cannot override:
 
 Rationale: High/critical risk mandates enough structure to capture alternatives, rollout, and rollback — even if the user wants a short plan.
 
+### Anti-Default Rules (read before computing)
+
+- **`Standard` is not a neutral default.** It is the result only for `MEDIUM` complexity (or a `HIGH` risk floor lifting a Fast result). `HIGH`/`VERY_HIGH` complexity → **Deep**; `TRIVIAL`/`LOW` → **Fast** unless risk lifts it.
+- **Compute, then write.** Fill the function inputs with the actual `complexity` and `risk_level`, evaluate, and only then write `tier_recommended`. Do not copy a tier from an example in this file.
+- **Auto means "use `tier_recommended`".** Never substitute `Standard` because it is the middle option.
+
+### Deep Override (`--deep`)
+
+The user can force a Deep plan in **any** interaction mode (including Autopilot and Smart) by invoking `/plan --deep <task>` (parsing rules in [SKILL.md](../SKILL.md#skill-invocation)).
+
+- `force_deep = true` → `tier = deep`, regardless of complexity, risk, or `user_preference`. The tier question is **not asked**, in any mode.
+- `tier_recommended` still holds the algorithm's result, so the override is auditable (`tier: deep`, `tier_recommended: fast`, etc.).
+- Deep only adds structure, so it never violates the risk floor.
+- The Smart-mode "tier is Deep" pause does **not** fire for a `--deep` plan (the user already chose it). CRITICAL-risk pause still applies.
+- Because Design runs before Generate, the Design phase also receives `force_deep` so it produces the material a Deep plan needs (≥ 2 alternatives, rollout draft, integration map) — see [design.md](../modules/design.md) Steps 4–5.
+
 ## Tier Section Requirements
 
 ### Fast Tier
@@ -109,33 +130,42 @@ Required sections (all Standard sections, plus):
 - Explicit complexity and tier in frontmatter
 - Cross-system integration map (data-flow or sequence diagram)
 
+**Required does not mean invented.** On a Deep plan forced by `--deep` for a small change, a required item that genuinely does not apply (e.g., data migration for a doc-only change) is written as `Not applicable — <one-line reason>`. Never omit the item and never fabricate content to fill it.
+
 ## Interaction Mode Behavior
 
-| Mode      | Tier Selection Behavior                                                                             |
-| --------- | --------------------------------------------------------------------------------------------------- |
-| Detailed  | Ask the user to confirm the selected tier; offer to override                                        |
-| Smart     | Auto-select; pause **only** if selected tier is Deep (or user preference conflicts with risk floor) |
-| Autopilot | Auto-select with `user_preference = auto`; never pause                                              |
+| Mode      | `user_preference`                                      | Tier Selection Behavior                                                                                   |
+| --------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- |
+| Detailed  | Asked (prompt below), unless `force_deep`              | Ask the user; offer to override. `force_deep` → no question, announce "Deep plan forced by `--deep`"      |
+| Smart     | `auto` (asked only if a pause trigger fires)           | Auto-select; pause **only** on the triggers below                                                         |
+| Autopilot | `auto`                                                 | Auto-select; never pause                                                                                  |
+
+`force_deep = true` overrides `user_preference` in every row.
 
 **Smart mode pause triggers:**
 
-- Selected tier is Deep (signals complex work worth a review)
+- Selected tier is Deep **and `force_deep` is false** (signals complex work worth a review)
 - User preference conflicts with risk floor (e.g., user wants Fast but risk is HIGH)
 - Research phase reported CRITICAL risk (Security or Payments)
 
 ## Asking the User for Preference
 
-In Detailed mode (or when Smart mode pauses), ask the user one question:
+In Detailed mode (or when Smart mode pauses), ask one question. **Build it from the computed values — every `<…>` placeholder below must be replaced; never print an example tier.**
 
 ```
-Based on the design complexity (HIGH) and risk level (HIGH), I recommend the Standard tier.
+Design complexity is <complexity> (score <total>/15) and risk level is <risk_level>.
+I recommend the <tier_recommended> tier.
 Which tier would you like for the plan?
   - Fast: Short plan, minimal structure (1-2 pages)
-  - Standard: Full plan with phased units and risk table (2-4 pages) [Recommended]
+  - Standard: Full plan with phased units and risk table (2-4 pages)
   - Deep: Comprehensive plan with alternatives and rollout ops (4+ pages)
-  - Auto: Let the algorithm decide (result: Standard)
+  - Auto: Use the recommendation (result: <tier_recommended>)
 ```
 
+- Append ` [Recommended]` to the option that equals `tier_recommended`.
+- If the risk floor makes an option unavailable (e.g., Fast at HIGH risk), keep it listed but say "(below risk floor — will be raised to <floor>)".
+- Tip to include once in the question text: `/plan --deep` forces a Deep plan without this question.
+
 Record the user's choice as the selected **`tier`** in the final plan frontmatter; preserve the algorithm's suggestion as **`tier_recommended`** so an override is auditable.
 
 ## Worked Examples
@@ -143,19 +173,34 @@ Record the user's choice as the selected **`tier`** in the final plan frontmatte
 ### Example 1: Low complexity, low risk
 
 - `complexity = LOW`, `risk_level = LOW`, `user_preference = auto`
-- Base tier: Fast. No risk upgrade. Auto preference → **Fast**.
+- `recommend_tier` → Fast. Auto → **Fast** (`tier_recommended: fast`).
+
+### Example 2: Medium complexity, medium risk, auto
+
+- `complexity = MEDIUM`, `risk_level = MEDIUM`, `user_preference = auto`
+- `recommend_tier` → Standard. Auto → **Standard** (`tier_recommended: standard`).
 
-### Example 2: Medium complexity, high risk, user wants fast
+### Example 3: Medium complexity, high risk, user wants fast
 
 - `complexity = MEDIUM`, `risk_level = HIGH`, `user_preference = fast`
-- Base tier: Standard. Risk upgrade: already Standard (HIGH floor). User wants Fast but HIGH risk floor is Standard → **Standard**.
+- `recommend_tier` → Standard. Floor (HIGH) = Standard. `max(Fast, Standard)` → **Standard**.
 - Smart mode would pause (preference conflicts with risk floor).
 
-### Example 3: High complexity, critical risk (payments)
+### Example 4: High complexity, high risk, auto
+
+- `complexity = HIGH` (score 8), `risk_level = HIGH`, `user_preference = auto`
+- `recommend_tier` → **Deep** (HIGH complexity → Deep; not Standard). Auto → **Deep** (`tier_recommended: deep`).
+- Smart mode pauses (Deep tier).
+
+### Example 5: High complexity, critical risk (payments)
 
 - `complexity = HIGH`, `risk_level = CRITICAL`, `user_preference = auto`
-- Base tier: Deep. CRITICAL forces Deep. Auto preference → **Deep**.
-- Smart mode pauses (Deep tier + CRITICAL risk).
+- `recommend_tier` → Deep. Auto → **Deep**. Smart mode pauses (Deep + CRITICAL).
+
+### Example 6: `--deep` on a small change, Autopilot
+
+- `complexity = LOW`, `risk_level = LOW`, `force_deep = true`, mode = autopilot
+- `tier_recommended: fast`, `tier: deep`. No question asked, no pause. Required Deep sections without real content are written as `Not applicable — <reason>`.
 
 ## Error Handling
 
@@ -165,10 +210,12 @@ Record the user's choice as the selected **`tier`** in the final plan frontmatte
 | `risk_level` missing from Research      | Default to MEDIUM; log warning                  |
 | User provides invalid preference value  | Treat as `auto`; log warning                    |
 | Selected tier conflicts with risk floor | Enforce risk floor; inform user of the override |
+| Design's `tier_recommended` differs from `recommend_tier(complexity, risk_level)` | Recompute in Generate; the recomputed value is authoritative; log warning |
+| `--deep` given but the phase artifact lacks the rollout/alternatives material | Generate writes `Not applicable — <reason>` for items that do not apply; never invents content |
 
 ## Notes
 
 - Tier choice is recorded in the final plan's frontmatter as `tier: fast | standard | deep`
 - The tier also influences the Tasks phase: Fast tier often produces 1–3 tasks; Standard 4–8; Deep 8+
-- If the user overrides the tier, preserve the algorithm's recommendation in a `tier_recommended` field for audit
+- If the user overrides the tier (explicit choice or `--deep`), preserve the algorithm's recommendation in a `tier_recommended` field for audit
 - Tier selection is the primary "right-sizing" mechanism — Small tasks → short plans; complex work → more structure (per Plan Skill core principles)

package/skills/plan/references/templates/artifacts/design.md

@@ -98,7 +98,7 @@ tier_recommended: fast | standard | deep
 - [Gap name] — [Follow-up action via /learn]
 ```
 
-Also save the design artifact to `docs/plans/.design/<design-id>.md` for future reference or reuse. The `interactionMode` and `complexity` values flow into the Generate artifact for tier selection.
+In `detailed` mode only, also save the design artifact to `docs/plans/.design/<design-id>.md` for future reference or reuse. The `interactionMode` and `complexity` values flow into the Generate artifact for tier selection. In `smart`/`autopilot` mode, do not write it; pass it to the next phase in context.
 
 ## Validation Rules
 

package/skills/plan/references/templates/artifacts/scoped-context.md

@@ -50,4 +50,4 @@ action: resume | review | archive | delete | create-new | none
 - (Empty list if none found)
 ```
 
-Also save the scoped context to `docs/plans/.scope/<scope-id>.md` for future reference or reuse. The `interactionMode` value flows into `research`, `design`, and `generate` artifacts.
+In `detailed` mode only, also save the scoped context to `docs/plans/.scope/<scope-id>.md` for future reference or reuse. The `interactionMode` value flows into `research`, `design`, and `generate` artifacts. In `smart`/`autopilot` mode, do not write it; pass it to the next phase in context.

package/skills/review/SKILL.md

@@ -35,6 +35,8 @@ Store in the context object:
 interactionMode: detailed | smart | autopilot
 ```
 
+**Artifact persistence:** intermediate phase artifacts are written to disk **only in `detailed` mode**. In `smart`/`autopilot` they are passed between phases in context and never written (see `references/interaction-mode-propagation.md#artifact-persistence`). Final deliverables are always written.
+
 **Propagation:** `interactionMode` flows into the `scope`, `prepare`, `analyze`, and `report` artifacts; each downstream phase reads it to adjust confirmation behaviour (detailed = pause every transition; autopilot = run all; smart = pause only on `blocker`/`major` findings or detected scope creep).
 
 ## Orchestration Implementation
@@ -58,7 +60,8 @@ Each phase runs sequentially: the orchestrator calls the phase module, receives
 
 Before starting the review pipeline, the orchestrator verifies that required folders exist:
 
-- `docs/review/.scope/`, `docs/review/.prepare/`, `docs/review/.analyze/`, `docs/review/.report/` — must exist for saving the four phase artifacts
+- `docs/review/.report/` — must exist for saving the Review Report (always written)
+- `docs/review/.scope/`, `docs/review/.prepare/`, `docs/review/.analyze/` — **`detailed` mode only**, for saving the intermediate phase artifacts; do not create them in `smart`/`autopilot`
 - `docs/review/index.md` — must exist as the review registry (Report appends to it)
 
 **Self-Healing:** If any are missing, the orchestrator automatically creates them (`mkdir -p`, and a seed `index.md` with a registry header). This allows the Review skill to run even if `arreio-init` wasn't explicitly run.
@@ -73,9 +76,9 @@ For **task-in-review** input, verify the `work-id` exists and contains at least
 
 | Phase | Phase Module                  | Output Artifact                                                  | Saved to                              |
 | ----- | ----------------------------- | ---------------------------------------------------------------- | ------------------------------------- |
-| 1     | [Scope](modules/scope.md)     | [Review scope](references/templates/artifacts/review-scope.md)   | `docs/review/.scope/<id>.md`   |
-| 2     | [Prepare](modules/prepare.md) | [Review kit](references/templates/artifacts/review-kit.md)       | `docs/review/.prepare/<id>.md` |
-| 3     | [Analyze](modules/analyze.md) | [Findings](references/templates/artifacts/findings.md)           | `docs/review/.analyze/<id>.md` |
+| 1     | [Scope](modules/scope.md)     | [Review scope](references/templates/artifacts/review-scope.md)   | `docs/review/.scope/<id>.md` _(detailed only)_ |
+| 2     | [Prepare](modules/prepare.md) | [Review kit](references/templates/artifacts/review-kit.md)       | `docs/review/.prepare/<id>.md` _(detailed only)_ |
+| 3     | [Analyze](modules/analyze.md) | [Findings](references/templates/artifacts/findings.md)           | `docs/review/.analyze/<id>.md` _(detailed only)_ |
 | 4     | [Report](modules/report.md)   | [Review report](references/templates/artifacts/review-report.md) | `docs/review/.report/<id>.md`  |
 
 ### Quality Gates
@@ -143,6 +146,17 @@ Artifact templates live in [references/templates/artifacts/](references/template
 | [findings.md](references/templates/artifacts/findings.md)           | Analyze      |
 | [review-report.md](references/templates/artifacts/review-report.md) | Report       |
 
+## Execution Rules
+
+Follow these literally; they exist to keep runs consistent across agents.
+
+1. **Run each module's steps in order**, starting with its Step 0 verification. Do not skip, merge, or reorder steps.
+2. **Never invent values.** If a required input is missing, apply the recovery in [error-handling.md](references/error-handling.md) or ask the user; do not fill it with a plausible guess.
+3. **Compute, don't copy.** Values defined by a rule (finding severity, `approval-status`, scope-creep flag) must be derived from the cited rubric and the real findings — never judged by feel, and never copied from an example. Example values in references and templates are illustrations, never defaults.
+4. **One question at a time**, with 2–4 concrete options; build the question text from the current values.
+5. **Announce phase transitions in one line** (e.g., "Phase 2/4 Analyze complete: <key result>") so the user can follow progress, even in Autopilot.
+6. **Honor write rules:** intermediate phase artifacts only in `detailed` mode; final deliverables always.
+
 ## Core Principles
 
 - **Deterministic Pipeline:** Phases always execute in sequence (no agent switching, no fallback paths).
@@ -155,6 +169,7 @@ Artifact templates live in [references/templates/artifacts/](references/template
 - **Test the Tests:** Reviewing changes includes evaluating the tests that accompany them — coverage, correctness of assertions, and whether they assert the intended Acceptance Criterion — not just production code.
 - **Read-Only Review:** Review analyzes and reports; it never edits the code under review. Required changes become a follow-up task (a new `/plan` + `/work`, or manual edits) — never applied inline here.
 - **Single Source of Truth:** This skill defines all its own rules; it does not depend on any external agent rule file. Category, severity, and approval definitions live once in their authoritative references and are never re-encoded inline in the modules.
+- **Lean Persistence:** Phase artifacts hit disk only in `detailed` mode; `smart`/`autopilot` pass them in context to save tokens and time.
 - **Transparent Artifacts:** Each phase produces an explicit output artifact for the next phase.
 - **Behavior-Described, Tool-Agnostic:** Steps describe required capabilities ("read the diff", "run the test suite", "update the index"), not specific tool names; each agent maps to its native tools.
 - **Interaction Mode Propagation:** `interactionMode` is read at the start of each subsequent phase and determines whether confirmation steps execute.

package/skills/review/modules/analyze.md

@@ -90,7 +90,7 @@ Apply the **[phase confirmation behavior](../references/interaction-mode-propaga
 - **Smart:** pause only when a pause trigger above is true; otherwise auto-proceed.
 - **Autopilot:** auto-proceed (no confirmation).
 
-Then save the artifact to `docs/review/.analyze/<analyze-id>.md` (ensure `interactionMode` included) and return it, with the `interactionMode` value, to the Orchestrator for the transition to Phase 4 (Report).
+Then, **in `detailed` mode only**, save the artifact to `docs/review/.analyze/<analyze-id>.md` (ensure `interactionMode` included) and return it, with the `interactionMode` value, to the Orchestrator for the transition to Phase 4 (Report). In `smart` and `autopilot` mode, do **not** write the file; pass the artifact to the next phase in context (see [Artifact Persistence](../references/interaction-mode-propagation.md#artifact-persistence)).
 
 ## Output: Findings Artifact
 
@@ -99,6 +99,6 @@ Then save the artifact to `docs/review/.analyze/<analyze-id>.md` (ensure `intera
 - Verify the **scope-creep** category either ran (with `spec-content` not `none`) or is recorded `skipped (no requirements)` — never silently absent, never inventing requirements.
 - Verify severities were **assigned from** [severity-rubric.md](../references/severity-rubric.md) rather than re-defined inline (no second rubric contradicting the authoritative reference).
 - Verify the category checks were **run from** [review-categories.md](../references/review-categories.md) rather than re-encoded inline.
-- Verify that the artifact is saved to `docs/review/.analyze/<analyze-id>.md`.
+- Verify that, in `detailed` mode, the artifact is saved to `docs/review/.analyze/<analyze-id>.md`; in `smart`/`autopilot` mode, verify that **no** file was written and the artifact was passed to the next phase in context.
 
 > Pass the Findings to `report` (Phase 4) for the approval-status derivation, the report write, and the registry / work-index cross-link.

package/skills/review/modules/prepare.md

@@ -90,7 +90,7 @@ Apply the **[phase confirmation behavior](../references/interaction-mode-propaga
 - **Smart:** pause only when a pause trigger above is true; otherwise auto-proceed.
 - **Autopilot:** auto-proceed (no confirmation).
 
-Then save the artifact to `docs/review/.prepare/<prepare-id>.md` (ensure `interactionMode` included) and return it, with the `interactionMode` value, to the Orchestrator for the transition to Phase 3 (Analyze).
+Then, **in `detailed` mode only**, save the artifact to `docs/review/.prepare/<prepare-id>.md` (ensure `interactionMode` included) and return it, with the `interactionMode` value, to the Orchestrator for the transition to Phase 3 (Analyze). In `smart` and `autopilot` mode, do **not** write the file; pass the artifact to the next phase in context (see [Artifact Persistence](../references/interaction-mode-propagation.md#artifact-persistence)).
 
 ## Output: Review Kit Artifact
 
@@ -98,6 +98,6 @@ Then save the artifact to `docs/review/.prepare/<prepare-id>.md` (ensure `intera
 - Verify that every `required` file has a diff entry (or is recorded as deleted / `current-contents`) and that `context` is separated from `required`.
 - Verify that `test-context` records covering tests per changed file and whether the change ships its own tests.
 - Verify that `requirements-source: none` propagated as `spec: none` (so Analyze skips the requirements-vs-scope-creep category rather than guessing).
-- Verify that the artifact is saved to `docs/review/.prepare/<prepare-id>.md`.
+- Verify that, in `detailed` mode, the artifact is saved to `docs/review/.prepare/<prepare-id>.md`; in `smart`/`autopilot` mode, verify that **no** file was written and the artifact was passed to the next phase in context.
 
 > Pass the Review Kit to `analyze` (Phase 3) for the categorized, severity-graded review of the diffs.

package/skills/review/modules/scope.md

@@ -89,7 +89,7 @@ Search `docs/learn/index.md` for entries relevant to the review domains (the cha
 
 ### Step 6: Allocate review-id and Generate the Review Scope Artifact
 
-1. **Allocate a `review-id`** of the form `YYYY-MM-DD-NNN` per [id-generation.md](../references/id-generation.md), counting existing `docs/review/.scope/YYYY-MM-DD-NNN-scope.md` files (or registry rows) for today. This is the pipeline umbrella id (distinct from any Work `review-id` for work-linked input — the two skills produce independent artifacts; the `work-id` is carried alongside for traceability).
+1. **Allocate a `review-id`** of the form `YYYY-MM-DD-NNN` per [id-generation.md](../references/id-generation.md), counting existing `docs/review/.scope/YYYY-MM-DD-NNN-scope.md` files (or registry rows) for today in `detailed` mode, or existing `docs/review/.report/` files in `smart`/`autopilot` (no scope file is written; see id-generation.md). This is the pipeline umbrella id (distinct from any Work `review-id` for work-linked input — the two skills produce independent artifacts; the `work-id` is carried alongside for traceability).
 
 2. **Assign a `scope-id`** per [id-generation.md](../references/id-generation.md) (format `YYYY-MM-DD-NNN-scope`, saved to `docs/review/.scope/`). Reuse it if the user later picks **Edit & Retry**.
 
@@ -113,7 +113,7 @@ Apply the **[phase confirmation behavior](../references/interaction-mode-propaga
 - **Smart:** pause only when a pause trigger above is true; otherwise auto-proceed.
 - **Autopilot:** auto-proceed (no confirmation).
 
-Then save the artifact to `docs/review/.scope/<scope-id>.md` (ensure `interactionMode`, `input-shape`, and `review-id` are included) and return it, with the `interactionMode` value, to the Orchestrator for the transition to Phase 2 (Prepare).
+Then, **in `detailed` mode only**, save the artifact to `docs/review/.scope/<scope-id>.md` (ensure `interactionMode`, `input-shape`, and `review-id` are included) and return it, with the `interactionMode` value, to the Orchestrator for the transition to Phase 2 (Prepare). In `smart` and `autopilot` mode, do **not** write the file; pass the artifact to the next phase in context (see [Artifact Persistence](../references/interaction-mode-propagation.md#artifact-persistence)).
 
 ## Output: Review Scope Artifact
 
@@ -121,6 +121,6 @@ Then save the artifact to `docs/review/.scope/<scope-id>.md` (ensure `interactio
 - Verify that the change boundary is in **dependency-safe** form: `required` files are repository-relative and carry a status; `context` is separated from `required`.
 - Verify that `review-id` was allocated (scope is the allocating phase) and that `work-id` is carried for work-linked input.
 - Verify that scope-creep detection was run only when requirements were present (else explicitly skipped with a note), per [scope-creep-detection.md](../references/scope-creep-detection.md).
-- Verify that the artifact is saved to `docs/review/.scope/<scope-id>.md`.
+- Verify that, in `detailed` mode, the artifact is saved to `docs/review/.scope/<scope-id>.md`; in `smart`/`autopilot` mode, verify that **no** file was written and the artifact was passed to the next phase in context.
 
 > Pass the Review Scope to `prepare` (Phase 2) to gather the diffs, spec content, test context, and tool inventory.

package/skills/review/references/id-generation.md

@@ -12,7 +12,7 @@ Shared ID algorithm for the `scope`, `prepare`, `analyze`, and `report` phases,
 
 ## ID Format by Phase
 
-| Phase    | ID format                            | Saved to                            |
+| Phase    | ID format                            | Saved to (detailed only)                            |
 | -------- | ----------------------------------- | ----------------------------------- |
 | Scope    | `YYYY-MM-DD-NNN-scope`              | `docs/review/.scope/<id>.md`    |
 | Prepare  | `YYYY-MM-DD-NNN-prepare`            | `docs/review/.prepare/<id>.md`  |
@@ -29,6 +29,8 @@ The `review-id` is the umbrella key that ties all four phase artifacts together
 
 > **Distinct from a Work `review-id`.** When Review is invoked over a `/work` run (`input-shape: work-linked`), the Work skill's own `review-id` (`docs/plans/.work/.review/...`) **already exists**. The Review skill allocates its **own** `review-id` (`docs/review/...`) — the two skills produce independent artifacts and never share an id. The `work-id` is carried alongside in the Review artifacts for traceability and the work-index cross-link, but `review-id` ≠ Work `review-id`.
 
+> **Persistence by mode.** The "Saved to" column and the directory-listing algorithm below apply **only in `detailed` mode**. In `smart`/`autopilot` mode phase artifacts are not written, so no directory is listed: Allocate `review-id` NNN by counting today's files in `docs/review/.report/` (+1); `scope-id`/`prepare-id`/`analyze-id` reuse that NNN as in-memory labels. See [Artifact Persistence](interaction-mode-propagation.md#artifact-persistence).
+
 ## Algorithm (new phase artifact)
 
 ```

package/skills/review/references/interaction-mode-propagation.md

@@ -77,4 +77,24 @@ Review deliberately has **no** `executionMode`:
 | Invalid mode value          | Reject; re-prompt Orchestrator        |
 | Artifact missing mode field | Assume "smart"; log warning; continue |
 | User selects "Abort"        | Stop immediately; inform Orchestrator |
-| Timeout/connection lost     | Pause; ask user to retry or abort     |
+| Timeout/connection lost     | Pause; ask user to retry or abort     |
+
+## Artifact Persistence
+
+Phase artifacts (Scope, Prepare, Analyze) are **handoff data between phases**, not deliverables. Whether they are written to disk depends on `interactionMode`:
+
+| Mode          | Phase artifacts (`docs/review/.scope/`, `.prepare/`, `.analyze/`)          | Phase handoff                                  |
+| ------------- | ---------------------------------------- | ---------------------------------------------- |
+| **Detailed**  | Written to the hidden directories (audit trail; creating the directory on first use) | Artifact is written, shown, then passed on     |
+| **Smart**     | **Not written**                          | Artifact is held in context and passed in-memory to the next phase |
+| **Autopilot** | **Not written**                          | Artifact is held in context and passed in-memory to the next phase |
+
+**Always written, in every mode:** the Review Report in `docs/review/.report/<report-id>.md` and its row in `docs/review/index.md` (a cross-skill handoff read by `/learn`).
+
+**Rules:**
+
+- The artifact schema, quality gates, cross-phase ID checks, and pause triggers are **unchanged** — only the disk write is skipped. Validate and pass the in-memory artifact exactly as you would the file.
+- Never create the hidden directories in `smart`/`autopilot`; no placeholder or empty files.
+- **ID allocation without files:** Allocate `review-id` NNN by counting today's files in `docs/review/.report/` (+1); `scope-id`/`prepare-id`/`analyze-id` reuse that NNN as in-memory labels.
+- If the user switches to `detailed` mid-run, write the artifacts produced so far, then continue writing.
+- Because nothing is on disk, **Edit & Retry** reuses the in-memory artifact and its id (no file to overwrite).

package/skills/review/references/templates/artifacts/findings.md

@@ -53,7 +53,7 @@ scope-creep-ran: true | "skipped (no requirements)"   # false only via the skipp
 work-id: YYYY-MM-DD-NNN | null          # work-linked only; null otherwise
 ```
 
-Also save the Findings to `docs/review/.analyze/<analyze-id>.md`.
+In `detailed` mode only, also save the Findings to `docs/review/.analyze/<analyze-id>.md`. In `smart`/`autopilot` mode, do not write it; pass it to the next phase in context.
 
 ## Validation Rules
 

package/skills/review/references/templates/artifacts/review-kit.md

@@ -60,7 +60,7 @@ tool-inventory:
 work-id: YYYY-MM-DD-NNN | null    # work-linked only; null otherwise
 ```
 
-Also save the Review Kit to `docs/review/.prepare/<prepare-id>.md`.
+In `detailed` mode only, also save the Review Kit to `docs/review/.prepare/<prepare-id>.md`. In `smart`/`autopilot` mode, do not write it; pass it to the next phase in context.
 
 ## Validation Rules
 

package/skills/review/references/templates/artifacts/review-scope.md

@@ -56,7 +56,7 @@ learning-gaps:
 work-id: YYYY-MM-DD-NNN | null             # work-linked only, for the index cross-link; null otherwise
 ```
 
-Also save the Review Scope to `docs/review/.scope/<scope-id>.md`.
+In `detailed` mode only, also save the Review Scope to `docs/review/.scope/<scope-id>.md`. In `smart`/`autopilot` mode, do not write it; pass it to the next phase in context.
 
 ## Validation Rules
 

package/skills/work/SKILL.md

@@ -35,6 +35,8 @@ Store in the context object:
 interactionMode: detailed | smart | autopilot
 ```
 
+**Artifact persistence:** intermediate phase artifacts are written to disk **only in `detailed` mode**. In `smart`/`autopilot` they are passed between phases in context and never written (see `references/interaction-mode-propagation.md#artifact-persistence`). Final deliverables are always written.
+
 **Propagation:** `interactionMode` flows into the `triage`, `prepare`, `execute`, and `review` artifacts; each downstream phase reads it to adjust confirmation behaviour (detailed = pause every transition; autopilot = run all; smart = pause only on HIGH-risk).
 
 > **Interaction mode is distinct from execution mode.** `interactionMode` governs _when to pause for the user_ (the same three modes as the `/plan` skill). **Execution mode** (inline / serial / parallel) governs _how multiple tasks are run_ and is selected in the Prepare phase. The two are carried independently through the pipeline.
@@ -59,7 +61,8 @@ Each phase runs sequentially: the orchestrator calls the phase module, receives
 Before starting the work pipeline, the orchestrator verifies that required folders exist:
 
 - `docs/tasks/` — must exist for reading (plan-based) or creating (ad-hoc) the task list
-- `docs/plans/.work/.triage/`, `docs/plans/.work/.prepare/`, `docs/plans/.work/.execute/`, `docs/plans/.work/.review/` — must exist for saving the four phase artifacts
+- `docs/plans/.work/.review/` — must exist for saving the Work Report (always written)
+- `docs/plans/.work/.triage/`, `docs/plans/.work/.prepare/`, `docs/plans/.work/.execute/` — **`detailed` mode only**, for saving the intermediate phase artifacts; do not create them in `smart`/`autopilot`
 
 **Self-Healing:** If any are missing, the orchestrator automatically creates them (`mkdir -p`). This allows the work skill to run even if `arreio-init` wasn't explicitly run.
 
@@ -82,9 +85,9 @@ Every new feature or plan runs on its own git branch:
 
 | Phase | Phase Module                  | Output Artifact                                                    | Saved to                            |
 | ----- | ----------------------------- | ------------------------------------------------------------------ | ----------------------------------- |
-| 1     | [Triage](modules/triage.md)   | [Work manifest](references/templates/artifacts/work-manifest.md) + `work/<slug>` branch | `docs/plans/.work/.triage/<id>.md`  |
-| 2     | [Prepare](modules/prepare.md) | [Execution plan](references/templates/artifacts/execution-plan.md) | `docs/plans/.work/.prepare/<id>.md` |
-| 3     | [Execute](modules/execute.md) | [Execution log](references/templates/artifacts/execution-log.md)   | `docs/plans/.work/.execute/<id>.md` |
+| 1     | [Triage](modules/triage.md)   | [Work manifest](references/templates/artifacts/work-manifest.md) + `work/<slug>` branch | `docs/plans/.work/.triage/<id>.md` _(detailed only)_ |
+| 2     | [Prepare](modules/prepare.md) | [Execution plan](references/templates/artifacts/execution-plan.md) | `docs/plans/.work/.prepare/<id>.md` _(detailed only)_ |
+| 3     | [Execute](modules/execute.md) | [Execution log](references/templates/artifacts/execution-log.md)   | `docs/plans/.work/.execute/<id>.md` _(detailed only)_ |
 | 4     | [Review](modules/review.md)   | [Work report](references/templates/artifacts/work-report.md)       | `docs/plans/.work/.review/<id>.md`  |
 
 ### Quality Gates
@@ -143,6 +146,17 @@ Artifact templates live in [references/templates/artifacts/](references/template
 | [execution-log.md](references/templates/artifacts/execution-log.md)   | Execute      |
 | [work-report.md](references/templates/artifacts/work-report.md)       | Review       |
 
+## Execution Rules
+
+Follow these literally; they exist to keep runs consistent across agents.
+
+1. **Run each module's steps in order**, starting with its Step 0 verification. Do not skip, merge, or reorder steps.
+2. **Never invent values.** If a required input is missing, apply the recovery in [error-handling.md](references/error-handling.md) or ask the user; do not fill it with a plausible guess.
+3. **Compute, don't copy.** Values defined by an algorithm or reference (`executionMode`, per-task risk floor, task status transitions, baseline result) must be evaluated with the real inputs; a recommendation is never `serial` just because it is the fallback. Example values in references and templates are illustrations, never defaults.
+4. **One question at a time**, with 2–4 concrete options; build the question text from the current values.
+5. **Announce phase transitions in one line** (e.g., "Phase 2/4 Prepare complete: <key result>") so the user can follow progress, even in Autopilot.
+6. **Honor write rules:** intermediate phase artifacts only in `detailed` mode; final deliverables always.
+
 ## Core Principles
 
 - **Deterministic Pipeline:** Phases always execute in sequence (no agent switching, no fallback paths).
@@ -156,6 +170,7 @@ Artifact templates live in [references/templates/artifacts/](references/template
 - **Error Handling:** Fail explicitly, not silently; each phase has clear error handling with recovery suggestions.
 - **Be Concrete:** Use specific files, components, and dependencies from the task artifacts.
 - **Stay Portable:** Use repository-relative paths only.
+- **Lean Persistence:** Phase artifacts hit disk only in `detailed` mode; `smart`/`autopilot` pass them in context to save tokens and time.
 - **Transparent Artifacts:** Each phase produces an explicit output artifact for the next phase.
 - **Interaction Mode Propagation:** `interactionMode` is read at the start of each subsequent phase and determines whether confirmation steps execute.
 - **Single Source of Truth:** This skill defines all its own rules; it does not depend on any external agent rule file.

package/skills/work/modules/execute.md

@@ -95,7 +95,7 @@ Apply the **[phase confirmation behavior](../references/interaction-mode-propaga
 - **Smart:** pause only when a pause trigger above is true; otherwise auto-proceed.
 - **Autopilot:** auto-proceed (no confirmation).
 
-Then save the artifact to `docs/plans/.work/.execute/<execute-id>.md` (ensure `interactionMode` and `executionMode` are included) and return it, with both mode values, to the Orchestrator for the transition to Phase 4 (Review).
+Then, **in `detailed` mode only**, save the artifact to `docs/plans/.work/.execute/<execute-id>.md` (ensure `interactionMode` and `executionMode` are included) and return it, with both mode values, to the Orchestrator for the transition to Phase 4 (Review). In `smart` and `autopilot` mode, do **not** write the file; pass the artifact to the next phase in context (see [Artifact Persistence](../references/interaction-mode-propagation.md#artifact-persistence)).
 
 ## Output: Execution Log Artifact
 
@@ -104,6 +104,6 @@ Then save the artifact to `docs/plans/.work/.execute/<execute-id>.md` (ensure `i
 - Verify that each `completed` task has its `## Acceptance Criteria` checkbox flipped to `- [x]` and the index ticked `- [ ] → - [x]` (forward only — never reset).
 - Verify that every `completed` task's single AC test is green with no new regression beyond the recorded baseline snapshot.
 - Verify that the gate/transition behavior was **enforced from** [task-execution-rules.md](../references/task-execution-rules.md) and [execution-mode-selection.md](../references/execution-mode-selection.md) rather than re-defined inline.
-- Verify that the artifact is saved to `docs/plans/.work/.execute/<execute-id>.md`.
+- Verify that, in `detailed` mode, the artifact is saved to `docs/plans/.work/.execute/<execute-id>.md`; in `smart`/`autopilot` mode, verify that **no** file was written and the artifact was passed to the next phase in context.
 
 > Pass the Execution Log to `review` (Phase 4) for the simplification, consolidation, and learnings-capture pass.

package/skills/work/modules/prepare.md

@@ -79,7 +79,7 @@ Select how `execution-list` is run. The three modes are defined canonically in *
 1. **Compute the default** from the table above, reading each task's `priority` and any HIGH-risk flag carried from the manifest.
 2. **Apply the risk floor (authoritative in [execution-mode-selection.md](../references/execution-mode-selection.md)):** any HIGH-risk task forces `inline` for that task; the user may not downgrade a HIGH-risk task below `inline`.
 3. **Determine user preference:**
-   - **Detailed:** ask the user which mode to run, presenting the recommendation.
+   - **Detailed:** ask the user which mode to run using the question template in [execution-mode-selection.md](../references/execution-mode-selection.md), filled with the computed values (including `Auto`).
    - **Smart:** auto-select, unless a pause trigger fires (Step 7).
    - **Autopilot:** auto-select; never ask.
 4. **Honor user preference** unless it violates the risk floor; on violation, ask the user to accept `inline` instead.
@@ -126,7 +126,7 @@ Apply the **[phase confirmation behavior](../references/interaction-mode-propaga
 - **Smart:** pause only when a pause trigger above is true; otherwise auto-proceed.
 - **Autopilot:** auto-proceed (no confirmation).
 
-Then save the artifact to `docs/plans/.work/.prepare/<prepare-id>.md` (ensure `interactionMode` and `executionMode` are included) and return it, with both mode values, to the Orchestrator for the transition to Phase 3 (Execute).
+Then, **in `detailed` mode only**, save the artifact to `docs/plans/.work/.prepare/<prepare-id>.md` (ensure `interactionMode` and `executionMode` are included) and return it, with both mode values, to the Orchestrator for the transition to Phase 3 (Execute). In `smart` and `autopilot` mode, do **not** write the file; pass the artifact to the next phase in context (see [Artifact Persistence](../references/interaction-mode-propagation.md#artifact-persistence)).
 
 ## Output: Execution Plan Artifact
 
@@ -135,6 +135,6 @@ Then save the artifact to `docs/plans/.work/.prepare/<prepare-id>.md` (ensure `i
 - Verify that the gate/policy details were **read from** [task-execution-rules.md](../references/task-execution-rules.md) rather than re-encoded inline (no second formula contradicting the authoritative reference).
 - Verify that `execution-list` preserves the manifest's dependency order (no task before its dependencies) and that wave-grouping (if `parallel`) respects dependency layers.
 - Verify that the `baseline` policy is recorded (a red baseline was surfaced, not hidden).
-- Verify that the artifact is saved to `docs/plans/.work/.prepare/<prepare-id>.md`.
+- Verify that, in `detailed` mode, the artifact is saved to `docs/plans/.work/.prepare/<prepare-id>.md`; in `smart`/`autopilot` mode, verify that **no** file was written and the artifact was passed to the next phase in context.
 
 > Pass the Execution Plan to `execute` (Phase 3) for the test-first execution run.

package/skills/work/modules/triage.md

@@ -166,7 +166,7 @@ Apply the **[phase confirmation behavior](../references/interaction-mode-propaga
 - **Smart:** pause only when a pause trigger above is true; otherwise auto-proceed.
 - **Autopilot:** auto-proceed (no confirmation).
 
-Then save the artifact to `docs/plans/.work/.triage/<triage-id>.md` (ensure `interactionMode` and `input-shape` are included) and return it, with the `interactionMode` value, to the Orchestrator for the transition to Phase 2 (Prepare).
+Then, **in `detailed` mode only**, save the artifact to `docs/plans/.work/.triage/<triage-id>.md` (ensure `interactionMode` and `input-shape` are included) and return it, with the `interactionMode` value, to the Orchestrator for the transition to Phase 2 (Prepare). In `smart` and `autopilot` mode, do **not** write the file; pass the artifact to the next phase in context (see [Artifact Persistence](../references/interaction-mode-propagation.md#artifact-persistence)).
 
 ## Output: Work Manifest Artifact
 
@@ -176,6 +176,6 @@ Then save the artifact to `docs/plans/.work/.triage/<triage-id>.md` (ensure `int
 - Verify that `work-id` is correct for the shape (inherited `plan-id` for plan-based/task-file; freshly allocated for ad-hoc).
 - Verify that `work-branch` is recorded in the manifest and, unless `null`, the repository is checked out on that branch.
 - Verify that for `ad-hoc` input, the task files and `docs/tasks/<work-id>/index.md` were created.
-- Verify that the artifact is saved to `docs/plans/.work/.triage/<triage-id>.md`.
+- Verify that, in `detailed` mode, the artifact is saved to `docs/plans/.work/.triage/<triage-id>.md`; in `smart`/`autopilot` mode, verify that **no** file was written and the artifact was passed to the next phase in context.
 
 > Pass the Work Manifest to `prepare` (Phase 2) for execution-mode selection and sequencing.

package/skills/work/references/execution-mode-selection.md

@@ -2,8 +2,8 @@
 title: Execution Mode Selection
 description: Authoritative reference for the Prepare phase. Defines the three execution modes (inline/serial/parallel), their selection defaults, the risk floor (HIGH-risk forces inline, non-downgradable), and the per-mode flows Execute follows.
 type: reference
-version: 1.0
-timestamp: "2026-08-07"
+version: 1.1
+timestamp: "2026-10-01"
 ---
 
 # Execution Mode Selection
@@ -41,6 +41,25 @@ Authoritative reference for the **Prepare** phase (Step 3). Defines the three ex
      parallel  -> waves: [Wave0, Wave1, ...]
 ```
 
+**Evaluation rules:**
+
+- The `default_mode` branches are checked **in the order written**; the first match wins. `serial` is the result **only** when neither earlier branch matches — it is a fallback, not a neutral default.
+- Evaluate with the real manifest data (task count, priorities, HIGH-risk flags, wave count). Do not copy a mode from an example.
+- The recommendation shown to the user is `default_mode` after the risk floor.
+
+**Detailed-mode question** — build it from computed values; replace every `<…>`:
+
+```
+This run has <N> tasks in <W> wave(s); <H> HIGH-risk, <P0> P0. I recommend <default_mode>.
+Which execution mode would you like?
+  - Inline: one task at a time, pause between tasks
+  - Serial: ordered list, no per-task pause
+  - Parallel: concurrent waves
+  - Auto: use the recommendation (result: <default_mode>)
+```
+
+Append ` [Recommended]` to the option equal to `default_mode`; if the risk floor makes an option unsafe, say so on that option.
+
 ## Risk Floor (authoritative, non-downgradable)
 
 - **Any HIGH-risk task forces `inline` treatment for that task**, regardless of the selected `executionMode`.