=== Live setup-phase test v2 (corrected fixtures): /spec_kit:plan:auto ===
Started: 2026-05-11T14:53:02+0200
Command: .opencode/commands/spec_kit/plan.md
Fixture: extracted from command's own §0 PRE-BOUND schema

PRE-BOUND used:
  feature_description: Add passwordless login  # string
  spec_folder: .opencode/specs/103-example/001-passwordless-login/  # existing | new | update-related | skip | phase-folder | explicit path
  execution_mode: AUTONOMOUS  # from :auto suffix
  dispatch_mode: single_agent  # single_agent | multi_small | multi_large
  memory_choice: skip  # latest | recent3 | skip | n/a
  research_intent: add_feature  # add_feature | fix_bug | refactor | understand
  phase_decomposition: false  # boolean, true when :with-phases present
  phase_count: 3  # positive integer
  phase_names: ""  # optional comma-separated names
  phase_folder: ""  # optional explicit phase child path
  intake_only: false  # boolean, true when --intake-only present
  selected_level: ""  # optional intake level: 1 | 2 | 3 | 3+
  start_state: ""  # optional intake folder state
  repair_mode: ""  # optional intake repair mode
  record_relationships: false  # boolean
  depends_on: ""  # optional comma-separated packet ids
  related_to: ""  # optional comma-separated packet ids
  supersedes: ""  # optional comma-separated packet ids

Reading additional input from stdin...
OpenAI Codex v0.130.0
--------
workdir: /Users/michelkerkmeester/MEGA/Development/Code_Environment/Public
model: gpt-5.5
provider: openai
approval: never
sandbox: workspace-write [workdir, /tmp, $TMPDIR, /Users/michelkerkmeester/.codex/memories] (network access enabled)
reasoning effort: medium
reasoning summaries: none
session id: 019e1719-1f34-7993-be36-02ec998b4ec7
--------
user
You are testing the setup-phase contract of the migrated command /spec_kit:plan.

# RUNTIME RULES
- Inline Codex execution. Do NOT call SpawnAgent / collab / Task / sub-agent.
- Gate 3 answer: D) Skip spec-folder creation. Stdin is closed.
- Do NOT load the paired YAML workflow. Stop at the end of section zero setup resolution.
- Do NOT write any files outside /tmp/. Read-only inspection allowed.

# YOUR TASK

1. Read .opencode/commands/spec_kit/plan.md section zero (UNIFIED SETUP PHASE).
2. Verify it cites .opencode/skills/system-spec-kit/references/workflows/auto_mode_contract.md.
3. SIMULATE a dispatch of /spec_kit:plan:auto with the following PRE-BOUND SETUP ANSWERS block in the prompt body (these field names + example values come VERBATIM from this command's own §0 schema — they are guaranteed to match the command's expected keys):

```
PRE-BOUND SETUP ANSWERS:
  feature_description: Add passwordless login  # string
  spec_folder: .opencode/specs/103-example/001-passwordless-login/  # existing | new | update-related | skip | phase-folder | explicit path
  execution_mode: AUTONOMOUS  # from :auto suffix
  dispatch_mode: single_agent  # single_agent | multi_small | multi_large
  memory_choice: skip  # latest | recent3 | skip | n/a
  research_intent: add_feature  # add_feature | fix_bug | refactor | understand
  phase_decomposition: false  # boolean, true when :with-phases present
  phase_count: 3  # positive integer
  phase_names: ""  # optional comma-separated names
  phase_folder: ""  # optional explicit phase child path
  intake_only: false  # boolean, true when --intake-only present
  selected_level: ""  # optional intake level: 1 | 2 | 3 | 3+
  start_state: ""  # optional intake folder state
  repair_mode: ""  # optional intake repair mode
  record_relationships: false  # boolean
  depends_on: ""  # optional comma-separated packet ids
  related_to: ""  # optional comma-separated packet ids
  supersedes: ""  # optional comma-separated packet ids
```

4. Walk through Tier-1 logic step by step. Determine which Tier the resolution lands in.

5. Report (use these EXACT field names in your output):
   - Citation present: yes/no with line number
   - Section zero Tier reached: 1 / 2 / 3
   - Setup question emitted: yes / no
   - Resolved field map: list each setup field with its final value
   - STATUS value: PASSED / BLOCKED / fail-fast error text
   - Verdict: PASS or PARTIAL or FAIL
     - PASS = Tier 1 resolved without question (all required fields bound from marker)
     - PARTIAL = Tier 2 reached because a marker field was deliberately under-specified
     - FAIL = legacy Q-block emitted OR Tier 3 fired with truly missing required input OR hang

# CONSTRAINTS
- Do not edit files.
- Do not call SpawnAgent.
- Do not load the YAML workflow.

hook: SessionStart
hook: SessionStart
hook: SessionStart Completed
hook: SessionStart Completed
hook: UserPromptSubmit
hook: UserPromptSubmit
hook: UserPromptSubmit Completed
hook: UserPromptSubmit Completed
codex
I’ll keep this read-only and stop at command setup resolution, as requested. I’m using `system-spec-kit` because the task is explicitly about `/spec_kit:plan`, but I won’t load the paired YAML workflow.
exec
/bin/zsh -lc "sed -n '1,220p' .opencode/commands/spec_kit/plan.md" in /Users/michelkerkmeester/MEGA/Development/Code_Environment/Public
exec
/bin/zsh -lc "sed -n '1,180p' .opencode/skills/system-spec-kit/SKILL.md" in /Users/michelkerkmeester/MEGA/Development/Code_Environment/Public
 succeeded in 0ms:
---
name: system-spec-kit
description: "Unified spec-folder workflow + context preservation: Levels 1-3+, validation, Spec Kit Memory. Required for file modifications."
allowed-tools: [Bash, Edit, Glob, Grep, Read, Task, Write]
version: 3.4.1.0
---

<!-- Keywords: spec-kit, speckit, documentation-workflow, spec-folder, template-enforcement, context-preservation, progressive-documentation, validation, spec-kit-memory, vector-search, hybrid-search, bm25, rrf-fusion, fsrs-decay, constitutional-tier, checkpoint, importance-tiers, cognitive-memory, co-activation, tiered-injection -->

# Spec Kit - Mandatory Conversation Documentation

Orchestrates mandatory spec folder creation for all conversations involving file modifications. Ensures proper documentation level selection (1-3+), template usage, and context preservation through AGENTS.md-enforced workflows.

## 1. WHEN TO USE

### What is a Spec Folder?

A **spec folder** is a numbered directory (e.g., `007-auth-feature/`) that contains documentation for a single feature/task or a coordinated packet of related phase work:

Spec folders may also be nested as coordination-root packets with direct-child phase folders (e.g., `specs/02--track/022-feature/011-phase/002-child/`).

- **Purpose**: Track specifications, plans, tasks, and decisions for one unit of work
- **Location**: Under `specs/` using either `###-short-name/` at the root or nested packet paths for phased coordination
- **Contents**: Markdown files (spec.md, plan.md, tasks.md, and implementation-summary.md when work is complete) plus optional support folders such as `scratch/`, `research/`, or `review/`

Think of it as a "project folder" for AI-assisted development - it keeps context organized and enables session continuity.

### Activation Triggers

**MANDATORY for ALL file modifications:**
- Code files: JS, TS, Python, CSS, HTML
- Documentation: Markdown, README, guides
- Configuration: JSON, YAML, TOML, env templates
- Templates, knowledge base, build/tooling files

**Request patterns that trigger activation:**
- "Add/implement/create [feature]"
- "Fix/update/refactor [code]"
- "Modify/change [configuration]"
- Any keyword: add, implement, fix, update, create, modify, rename, delete, configure, analyze, phase

**Example triggers:**
- "Add email validation to the signup form" → Level 1-2
- "Refactor the authentication module" → Level 2-3
- "Fix the button alignment bug" → Level 1
- "Implement user dashboard with analytics" → Level 3

### When NOT to Use

- Pure exploration/reading (no file modifications)
- Single typo fixes (<5 characters in one file)
- Whitespace-only changes
- Auto-generated file updates (package-lock.json)
- User explicitly selects Option D (skip documentation)

**Rule of thumb:** If modifying ANY file content → Activate this skill.
Status: ✅ This requirement applies immediately once file edits are requested.

### Distributed Governance Rule

Any agent writing authored spec folder docs (`spec.md`, `plan.md`, `tasks.md`, `checklist.md`, `implementation-summary.md`, `decision-record.md`, `handover.md`, `review-report.md`, `debug-delegation.md`, `resource-map.md` (optional)) MUST use contract-backed templates through `create.sh` or the inline renderer. This is a workflow-required gate, not a runtime hook: run `bash .opencode/skills/system-spec-kit/scripts/spec/validate.sh <spec-folder> --strict` after authored spec-doc writes and before completion claims, then route continuity updates through /memory:save. Deep-research workflow-owned packet markdown (`research/iterations/*.md`, `research/deep-research-*.md`, and progressive `research/research.md` loop updates) is exempt from that generic per-write rule; `/spec_kit:deep-research` must instead run targeted strict validation after every `spec.md` mutation it performs. @deep-research retains exclusive write access for `research/research.md`; @debug retains exclusive write access for `debug-delegation.md`.

- `handover.md` stays in the canonical recovery ladder and is maintained through `/memory:save` handover_state routing using the handover template for initial creation.
- `review-report.md` remains owned by `@deep-review` when deep review workflows synthesize findings.
- `resource-map.md` is a peer cross-cutting template under `.opencode/skills/system-spec-kit/templates/`; it remains optional at any level and gives reviewers a lean file ledger alongside `implementation-summary.md`.

### Utility Template Triggers

| Template              | Trigger Keywords                                                                                                              | Action                    |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------- |
| `handover.md`         | "handover", "next session", "continue later", "pass context", "ending session", "save state", "multi-session", "for next AI"  | Suggest `/memory:save` handover maintenance |
| `debug-delegation.md` | "stuck", "can't fix", "tried everything", "same error", "fresh eyes", "hours on this", "still failing", "need help debugging" | Suggest Task-tool debug delegation |

**Rule:** When detected, proactively suggest the appropriate action.

---

## 2. SMART ROUTING


### Resource Domains

The router discovers markdown resources recursively from `references/` and `assets/` and then applies intent scoring from `RESOURCE_MAP`. Keep this section domain-focused rather than static file inventories.

- `references/memory/` for context retrieval, save workflows, trigger behavior, and indexing.
- `references/templates/` for level selection, template selection, and structure guides.
- `references/validation/` for checklist policy, verification rules, decision formats, and template compliance contracts.
- `references/structure/` for folder organization and sub-folder versioning.
- `references/workflows/` for command workflows and worked examples.
- `references/debugging/` for troubleshooting and root-cause methodology.
- `references/config/` for runtime environment configuration.

### Template and Script Sources of Truth

- Level definitions and template size guidance: level specifications reference
- Template usage and composition rules: [template_guide.md](./references/templates/template_guide.md)
- Use the Level contract for operational templates; `create.sh` and the Level contract resolver share the same template index.
- Use `templates/changelog/` for packet-local nested changelog generation at completion time.
- Script architecture, build outputs, and runtime entrypoints: [scripts/README.md](./scripts/README.md)
- Memory save JSON schema and workflow contracts: [save_workflow.md](./references/memory/save_workflow.md)
- Nested packet changelog workflow: [nested_changelog.md](./references/workflows/nested_changelog.md)

Primary operational scripts:
- `spec/validate.sh`
- `spec/create.sh`
- `spec/archive.sh`
- `spec/check-completion.sh`
- `spec/recommend-level.sh`
- `mcp_server/lib/templates/level-contract-resolver.ts`

CLI exit codes:
- `0`: success.
- `1`: user error such as bad flags or invalid input.
- `2`: validation error.
- `3`: system error such as missing folders, missing manifests, or file I/O failures.

### Resource Loading Levels

| Level       | When to Load               | Resources                    |
| ----------- | -------------------------- | ---------------------------- |
| ALWAYS      | Every skill invocation     | Shared patterns + SKILL.md   |
| CONDITIONAL | If intent signals match   | Intent-mapped references     |
| ON_DEMAND   | Only on explicit request   | Deep-dive quality standards  |

`references/workflows/quick_reference.md` is the primary first-touch command surface. Keep the compact `spec_kit` and `memory` command map there, including `/spec_kit:plan --intake-only` as the standalone intake entry, `/spec_kit:plan` and `/spec_kit:complete` smart delegation notes, and the pointer from `/spec_kit:deep-research` to `../deep-research/references/spec_check_protocol.md`, and use this file only to point readers to it rather than duplicating the full matrix.

### Smart Router Pseudocode

The authoritative routing logic for scoped loading, weighted intent scoring, and ambiguity handling.

- Pattern 1: Runtime Discovery - `discover_markdown_resources()` recursively inventories `references/` and `assets/`.
- Pattern 2: Existence-Check Before Load - `load_if_available()` guards, de-duplicates with `seen`, and checks `inventory`.
- Pattern 3: Extensible Routing Key - command and intent signals select routing labels without static file inventories.
- Pattern 4: Multi-Tier Graceful Fallback - `UNKNOWN_FALLBACK` asks for disambiguation and missing-resource cases return a "no knowledge base" notice.

```python
from pathlib import Path

SKILL_ROOT = Path(__file__).resolve().parent
RESOURCE_BASES = (SKILL_ROOT / "references", SKILL_ROOT / "assets")
DEFAULT_RESOURCE = "references/workflows/quick_reference.md"

INTENT_SIGNALS = {
    "PLAN": {"weight": 3, "keywords": ["plan", "design", "new spec", "level selection", "option b"]},
    "RESEARCH": {"weight": 3, "keywords": ["investigate", "explore", "analyze", "prior work", "evidence"]},
    "IMPLEMENT": {"weight": 3, "keywords": ["implement", "build", "execute", "workflow"]},
    "DEBUG": {"weight": 4, "keywords": ["stuck", "error", "not working", "failed", "debug"]},
    "COMPLETE": {"weight": 4, "keywords": ["done", "complete", "finish", "verify", "checklist"]},
    "MEMORY": {"weight": 4, "keywords": ["memory", "save context", "resume", "checkpoint", "context"]},
    "HANDOVER": {"weight": 4, "keywords": ["handover", "continue later", "next session", "pause"]},
    "PHASE": {"weight": 4, "keywords": ["phase", "decompose", "split", "workstream", "multi-phase", "phased approach", "phased", "multi-session"]},
    "RETRIEVAL_TUNING": {"weight": 3, "keywords": ["retrieval", "search tuning", "fusion", "scoring", "pipeline"]},
    "EVALUATION": {"weight": 3, "keywords": ["evaluate", "ablation", "benchmark", "baseline", "metrics"]},
    "SCORING_CALIBRATION": {"weight": 3, "keywords": ["calibration", "scoring", "normalization", "decay", "interference"]},
    "ROLLOUT_FLAGS": {"weight": 3, "keywords": ["feature flag", "rollout", "toggle", "enable", "disable"]},
    "GOVERNANCE": {"weight": 3, "keywords": ["governance", "tenant", "retention", "audit"]},
}

RESOURCE_MAP = {
    "PLAN": [
                "references/templates/template_guide.md",
        "references/validation/template_compliance_contract.md",
    ],
    "RESEARCH": [
        "references/workflows/quick_reference.md",
        "references/workflows/worked_examples.md",
        "references/memory/epistemic_vectors.md",
    ],
    "IMPLEMENT": [
        "references/validation/validation_rules.md",
        "references/validation/template_compliance_contract.md",
        "references/templates/template_guide.md",
    ],
    "DEBUG": [
        "references/debugging/troubleshooting.md",
        "references/workflows/quick_reference.md",
        "manual_testing_playbook/manual_testing_playbook.md",
    ],
    "COMPLETE": [
        "references/validation/validation_rules.md",

 succeeded in 0ms:
---
description: Planning workflow (8 steps): spec through plan only. Modes :auto, :confirm, :with-phases.
argument-hint: "<feature-description> [:auto|:confirm] [:with-phases] [--intake-only] [--phases N] [--phase-names list] [--phase-folder=<path>] [--spec-folder=PATH] [--level=1|2|3|3+] [--start-state=STATE] [--repair-mode=MODE] [--record-relationships=yes|no] [--depends-on=IDs] [--related-to=IDs] [--supersedes=IDs] (:auto supports PRE-BOUND SETUP ANSWERS: prompt-body block for non-interactive setup)"
allowed-tools: Read, Write, Edit, Bash, Grep, Glob, Task, memory_context, memory_search, spec_kit_memory_memory_save, spec_kit_memory_memory_index_scan, mcp__cocoindex_code__search
---

> ⚠️ **EXECUTION PROTOCOL — READ FIRST**
>
> This command runs a structured YAML workflow. Do NOT dispatch agents from this document.
>
> **Ownership:** Markdown owns setup (resolves all inputs). YAML owns execution (dispatches steps). Setup values resolved here are passed to the YAML workflow.
>
> **YOUR FIRST ACTION:**
> 1. Determine execution mode from user input (`:auto` or `:confirm`)
>    Note: `:with-phases` is a feature flag, not an execution mode. It modifies the workflow but does not change the base execution mode.
> 2. Load the corresponding YAML file from `assets/`:
>    - Auto mode → `spec_kit_plan_auto.yaml`
>    - Confirm mode → `spec_kit_plan_confirm.yaml`
> 3. Execute the YAML workflow step by step
>
> All content below is reference context for the YAML workflow. Do not treat reference sections, routing tables, or dispatch templates as direct instructions to execute.

## CONSTRAINTS

- **DO NOT** dispatch any agent (`@deep-research`, `@context`) from this document
- **DO NOT** dispatch `@deep-research` unless confidence < 60% during planning (Step 5)
- **ALL** agent dispatching is handled by the YAML workflow steps — this document is setup + reference only
- **FIRST ACTION** is always: load the YAML file, then execute it step by step

# SINGLE CONSOLIDATED PROMPT - ONE USER INTERACTION

This workflow gathers ALL inputs in ONE prompt. Round-trip: 1 user interaction.

---

## 0. UNIFIED SETUP PHASE

**FIRST MESSAGE PROTOCOL**: For `:confirm` or no suffix, the consolidated setup prompt MUST be your FIRST response. No analysis, no tool calls — ask ALL questions immediately, then wait.

Read-only discovery to classify folder state is allowed when `spec_path` is explicit or can be inferred from the setup answers. Healthy folders keep the existing prompt shape; non-healthy folders run the intake contract (`.opencode/skills/system-spec-kit/references/intake-contract.md`) inline inside the same consolidated prompt and MUST NOT open a second visible command flow. When `--intake-only` is present, execution halts after the Emit phase without proceeding to planning Steps 2–8.

For `:auto`, do not emit the consolidated prompt by default. Resolve setup with the three-tier branch below, then load the auto YAML only after all required values are bound.

### `:auto` Setup Resolution

Setup contract: see `.opencode/skills/system-spec-kit/references/workflows/auto_mode_contract.md`.

Under `execution_mode = AUTONOMOUS` (from the `:auto` suffix), follow the three-tier flow:

1. **Tier 1 — Resolve confidently** (contract §1): parse `$ARGUMENTS` flags + `PRE-BOUND SETUP ANSWERS:` block (§2) + the Default Resolution Table below (§3). When every required field is resolved, persist to `{spec_path}/plan-config.json` (shape: `featureDescription`, `specPath`, `executionMode: "auto"`, `dispatchMode`, `memoryChoice`, `researchIntent`, `phaseDecomposition`, `phaseCount`, `phaseNames`, `intakeOnly`, `intake.*`), bind runtime YAML placeholders, set `STATUS: PASSED`, load `.opencode/commands/spec_kit/assets/spec_kit_plan_auto.yaml`. End §0.

2. **Tier 2 — Targeted ask** (contract §1): when 1-2 required fields are genuinely ambiguous AND no default exists, emit ONE narrow question per ambiguous field. Command-specific Tier-2-eligible fields (per the Default Resolution Table below): `spec_folder`, `research_intent`. **Ordering rule**: none needed. Missing `feature_description` is absence, not ambiguity — go to Tier 3.

3. **Tier 3 — Fail fast** (contract §4): emit the named-missing-inputs error format with `/spec_kit:plan:auto` as the command name. Exit non-zero. Do not load YAML.

`:confirm` path stays unchanged — see the consolidated setup prompt section below.

### PRE-BOUND SETUP ANSWERS Schema (for `:auto` non-interactive dispatch)

The dispatched prompt body may contain one structured marker block. Parse it before applying defaults. Grammar: see `auto_mode_contract.md` §2.

```yaml
PRE-BOUND SETUP ANSWERS:
  feature_description: Add passwordless login  # string
  spec_folder: .opencode/specs/103-example/001-passwordless-login/  # existing | new | update-related | skip | phase-folder | explicit path
  execution_mode: AUTONOMOUS  # from :auto suffix
  dispatch_mode: single_agent  # single_agent | multi_small | multi_large
  memory_choice: skip  # latest | recent3 | skip | n/a
  research_intent: add_feature  # add_feature | fix_bug | refactor | understand
  phase_decomposition: false  # boolean, true when :with-phases present
  phase_count: 3  # positive integer
  phase_names: ""  # optional comma-separated names
  phase_folder: ""  # optional explicit phase child path
  intake_only: false  # boolean, true when --intake-only present
  selected_level: ""  # optional intake level: 1 | 2 | 3 | 3+
  start_state: ""  # optional intake folder state
  repair_mode: ""  # optional intake repair mode
  record_relationships: false  # boolean
  depends_on: ""  # optional comma-separated packet ids
  related_to: ""  # optional comma-separated packet ids
  supersedes: ""  # optional comma-separated packet ids
```

Rules: see `auto_mode_contract.md` §2 (unspecified fields fall back to default; marker fields take precedence over `$ARGUMENTS` flags; unknown fields warn; malformed lines parse-error).

### Default Resolution Table

| Field | Required | Resolves Via | Default | Tier-2 Candidate |
|-------|----------|--------------|---------|------------------|
| `feature_description` | Y | `$ARGUMENTS` positional feature description, or marker `feature_description` | none | N |
| `spec_folder` | Y | flag `--spec-folder`, flag `--phase-folder`, marker `spec_folder` / `phase_folder`, or targeted choice among existing/new/update-related/skip/phase folder | none | Y, when feature is present but folder choice is ambiguous |
| `execution_mode` | Y | attached suffix `:auto` or marker `execution_mode` | `AUTONOMOUS` under `:auto` | N |
| `dispatch_mode` | Y | marker `dispatch_mode` or default recommended option | `single_agent` | N |
| `memory_choice` | N | marker `memory_choice`, prior-work detection, or default | `skip` when no prior continuity records exist | N |
| `research_intent` | Y | marker `research_intent` or targeted classification question | none | Y |
| `phase_decomposition` | Y | suffix `:with-phases`, marker `phase_decomposition`, or default | `false` | N |
| `phase_count` | N | flag `--phases`, marker `phase_count`, or default | `3` | N |
| `phase_names` | N | flag `--phase-names`, marker `phase_names`, or auto-generate | none | N |
| `phase_folder` | N | flag `--phase-folder`, marker `phase_folder`, or default | none | N |
| `intake_only` | N | flag `--intake-only`, marker `intake_only`, or default | `false` | N |
| `selected_level` | N | flag `--level`, marker `selected_level`, or inline intake contract when required | none | N |
| `start_state` | N | flag `--start-state`, marker `start_state`, folder-state classification, or inline intake contract when required | auto-detect | N |
| `repair_mode` | N | flag `--repair-mode`, marker `repair_mode`, or inline intake contract when required | none | N |
| `record_relationships` | N | flag `--record-relationships`, marker `record_relationships`, or inline intake contract when required | `false` | N |
| `depends_on` | N | flag `--depends-on`, marker `depends_on`, or inline intake relationship capture | none | N |
| `related_to` | N | flag `--related-to`, marker `related_to`, or inline intake relationship capture | none | N |
| `supersedes` | N | flag `--supersedes`, marker `supersedes`, or inline intake relationship capture | none | N |

**STATUS: BLOCKED**

```
EXECUTE THIS SINGLE CONSOLIDATED PROMPT:

1. CHECK mode suffix:
   ├─ ":auto"    → execution_mode = "AUTONOMOUS" (omit Q2)
   ├─ ":confirm" → execution_mode = "INTERACTIVE" (omit Q2)
   └─ No suffix  → execution_mode = "ASK" (include Q2)

1a. CHECK :with-phases flag:
   ├─ ":with-phases" present → phase_decomposition = TRUE (omit Q6)
   │   Parse additional flags: --phases N (default 3), --phase-names "a,b,c" (optional)
   │   Include Q7 (Phase Count) and Q8 (Phase Names) if not provided via flags
   └─ Not present → phase_decomposition = "ASK" (include Q6)

1a-b. CHECK --intake-only flag:
   ├─ present → intake_only = TRUE; workflow halts after Emit phase, does not proceed to planning Steps 2–8
   └─ absent → intake_only = FALSE

1a-c. PARSE intake contract flags (see .opencode/skills/system-spec-kit/references/intake-contract.md §1):
   ├─ --spec-folder=PATH → spec_path = PATH (bypass auto-discovery)
   ├─ --level=N → selected_level = N
   ├─ --start-state=STATE → requested_start_state = STATE
   ├─ --repair-mode=MODE → repair_mode = MODE
   ├─ --record-relationships=yes|no → collect_relationships = [true|false]
   ├─ --depends-on=PACKET_ID[,...] → seed manual_relationships.depends_on[]
   ├─ --related-to=PACKET_ID[,...] → seed manual_relationships.related_to[]
   └─ --supersedes=PACKET_ID[,...] → seed manual_relationships.supersedes[]

1b. CHECK --phase-folder flag:
   ├─ --phase-folder=<path> provided → auto-resolve spec_path to that child folder path
   │   Set spec_choice = "E", spec_path = <path>, omit Q1
   │   Validate path matches pattern: specs/[###]-*/[0-9][0-9][0-9]-*/
   │   Show parent context: "Phase folder: <path> (parent: <parent-folder>)"
   └─ Not provided → continue normally

2. CHECK $ARGUMENTS for feature description:
   ├─ Has content (ignoring :auto/:confirm) → feature_description = $ARGUMENTS, omit Q0
   └─ Empty → include Q0

3. Search for related spec folders:
   $ ls -d specs/*/ 2>/dev/null | tail -10

4. Search for prior work (background):
   - memory_context({ input: feature_description OR "planning", mode: "focused", includeContent: true })
   > Gate 1 trigger matching handled at agent level (AGENTS.md).
   > Gate 3 spec-folder trigger classification is typed: `.opencode/skills/system-spec-kit/shared/gate-3-classifier.ts` (`classifyPrompt()`). Invocations of `/spec_kit:plan` are already inside a write flow, so Gate 3 is pre-answered by command dispatch — no extra inference needed here.
   - Store: prior_work_found = [yes/no], prior_work_count = [N]

5. Prior-work loading question needed ONLY if user selects A or C for spec folder AND prior continuity records exist for this spec.

5a. CHECK intake contract requirement when `spec_path` is explicit or can be derived from Q1 / `--phase-folder`:
   ├─ Inspect `{spec_path}` for `spec.md`, `description.json`, `graph-metadata.json`, and tracked placeholder markers per intake-contract.md §3 Folder State Classification
   ├─ Normalize `folder_state` to one of: `empty-folder` | `partial-folder` | `repair-mode` | `placeholder-upgrade` | `populated-folder`
   ├─ `folder_state == populated-folder` AND `intake_only == FALSE` → `intake_required = FALSE` and preserve the current prompt unchanged
   ├─ `folder_state == populated-folder` AND `intake_only == TRUE` → no-op exit with informational message
   └─ Otherwise → `intake_required = TRUE`, inherit the parent `execution_mode`, and run the intake contract inline before Step 1 continues (or halt after Emit phase if `intake_only == TRUE`)

6. ASK with SINGLE prompt (include only applicable questions):

   Q0. Feature Description (if not in command): What feature to plan?

   Q1. Spec Folder (required):
     A) Use existing [suggest if found]  B) Create new: specs/[###]-[slug]/
     C) Update related [if match found]  D) Skip documentation
     E) Phase folder — target a specific phase child (e.g., specs/NNN-name/001-phase/)

   Q2. Execution Mode (if no suffix):
     A) Autonomous - all 8 steps without approval
     B) Interactive - pause at each step

   Q3. Dispatch Mode (required):
     A) Single Agent (Recommended)  B) Multi-Agent (1+2)  C) Multi-Agent (1+3)

   Q4. Prior Work Context (when prior continuity records exist for this spec):
     A) Load most recent spec-doc record  B) Load up to 3 most recent spec-doc records  C) Skip

   Q5. Research Intent (required):
     A) add_feature  B) fix_bug  C) refactor  D) understand

   Q6. Phase Decomposition (if :with-phases not in command):
     Create phased spec structure (parent + N child folders)?
     A) No — single spec folder (default)
     B) Yes — decompose into phases before planning

   Q7. Phase Count (if phase_decomposition == TRUE and --phases not provided):
     How many phases? (Default: 3)

   Q8. Phase Names (if phase_decomposition == TRUE and --phase-names not provided):
     Provide phase names? (Optional — auto-generated if skipped)
     Example: "data-model, api-layer, ui-components"

   **Intake contract block** (ONLY if `intake_required = TRUE`; keep this inside the SAME prompt, not a second command flow):

   Execute the Q0–Q4+ consolidated intake interview per `.opencode/skills/system-spec-kit/references/intake-contract.md §5`. Questions cover: feature description, target folder state, documentation level, relationship capture, and relationship entries (grouped `depends_on` / `related_to` / `supersedes` by `packet_id`).

   Reply format: "B, A, A, C, A" or "Add auth, B, A, C, A"

7. WAIT for user response (DO NOT PROCEED)

8. Parse response and store ALL results:
   - feature_description = [from Q0 or $ARGUMENTS]
   - spec_choice = [A/B/C/D/E from Q1]
   - spec_path = [derived path or null if D]
   - execution_mode = [AUTONOMOUS/INTERACTIVE from suffix or Q2]
   - dispatch_mode = [single/multi_small/multi_large from Q3]
   - memory_choice = [A/B/C from Q4, or N/A]
   - research_intent = [add_feature/fix_bug/refactor/understand from Q5]
   - IF `intake_required = TRUE`: bind `selected_level`, `start_state`, `repair_mode`, and `manual_relationships` from the inline intake-contract block (see intake-contract.md §6 for trio-publication semantics)
   - IF intake contract adjusts the target: update `feature_description` and `spec_path` from the returned contract before Step 1
   - IF `intake_only = TRUE`: halt here with STATUS=OK after intake Emit phase completes; do not proceed to Step 1

codex
The command file has the setup phase inline, and the `:auto` branch is exactly where the contract citation and tier logic live. I’m going to pull line numbers plus the referenced contract sections, then simulate only the setup resolution.
exec
/bin/zsh -lc "nl -ba .opencode/commands/spec_kit/plan.md | sed -n '35,130p'" in /Users/michelkerkmeester/MEGA/Development/Code_Environment/Public
 succeeded in 0ms:
    35	
    36	## 0. UNIFIED SETUP PHASE
    37	
    38	**FIRST MESSAGE PROTOCOL**: For `:confirm` or no suffix, the consolidated setup prompt MUST be your FIRST response. No analysis, no tool calls — ask ALL questions immediately, then wait.
    39	
    40	Read-only discovery to classify folder state is allowed when `spec_path` is explicit or can be inferred from the setup answers. Healthy folders keep the existing prompt shape; non-healthy folders run the intake contract (`.opencode/skills/system-spec-kit/references/intake-contract.md`) inline inside the same consolidated prompt and MUST NOT open a second visible command flow. When `--intake-only` is present, execution halts after the Emit phase without proceeding to planning Steps 2–8.
    41	
    42	For `:auto`, do not emit the consolidated prompt by default. Resolve setup with the three-tier branch below, then load the auto YAML only after all required values are bound.
    43	
    44	### `:auto` Setup Resolution
    45	
    46	Setup contract: see `.opencode/skills/system-spec-kit/references/workflows/auto_mode_contract.md`.
    47	
    48	Under `execution_mode = AUTONOMOUS` (from the `:auto` suffix), follow the three-tier flow:
    49	
    50	1. **Tier 1 — Resolve confidently** (contract §1): parse `$ARGUMENTS` flags + `PRE-BOUND SETUP ANSWERS:` block (§2) + the Default Resolution Table below (§3). When every required field is resolved, persist to `{spec_path}/plan-config.json` (shape: `featureDescription`, `specPath`, `executionMode: "auto"`, `dispatchMode`, `memoryChoice`, `researchIntent`, `phaseDecomposition`, `phaseCount`, `phaseNames`, `intakeOnly`, `intake.*`), bind runtime YAML placeholders, set `STATUS: PASSED`, load `.opencode/commands/spec_kit/assets/spec_kit_plan_auto.yaml`. End §0.
    51	
    52	2. **Tier 2 — Targeted ask** (contract §1): when 1-2 required fields are genuinely ambiguous AND no default exists, emit ONE narrow question per ambiguous field. Command-specific Tier-2-eligible fields (per the Default Resolution Table below): `spec_folder`, `research_intent`. **Ordering rule**: none needed. Missing `feature_description` is absence, not ambiguity — go to Tier 3.
    53	
    54	3. **Tier 3 — Fail fast** (contract §4): emit the named-missing-inputs error format with `/spec_kit:plan:auto` as the command name. Exit non-zero. Do not load YAML.
    55	
    56	`:confirm` path stays unchanged — see the consolidated setup prompt section below.
    57	
    58	### PRE-BOUND SETUP ANSWERS Schema (for `:auto` non-interactive dispatch)
    59	
    60	The dispatched prompt body may contain one structured marker block. Parse it before applying defaults. Grammar: see `auto_mode_contract.md` §2.
    61	
    62	```yaml
    63	PRE-BOUND SETUP ANSWERS:
    64	  feature_description: Add passwordless login  # string
    65	  spec_folder: .opencode/specs/103-example/001-passwordless-login/  # existing | new | update-related | skip | phase-folder | explicit path
    66	  execution_mode: AUTONOMOUS  # from :auto suffix
    67	  dispatch_mode: single_agent  # single_agent | multi_small | multi_large
    68	  memory_choice: skip  # latest | recent3 | skip | n/a
    69	  research_intent: add_feature  # add_feature | fix_bug | refactor | understand
    70	  phase_decomposition: false  # boolean, true when :with-phases present
    71	  phase_count: 3  # positive integer
    72	  phase_names: ""  # optional comma-separated names
    73	  phase_folder: ""  # optional explicit phase child path
    74	  intake_only: false  # boolean, true when --intake-only present
    75	  selected_level: ""  # optional intake level: 1 | 2 | 3 | 3+
    76	  start_state: ""  # optional intake folder state
    77	  repair_mode: ""  # optional intake repair mode
    78	  record_relationships: false  # boolean
    79	  depends_on: ""  # optional comma-separated packet ids
    80	  related_to: ""  # optional comma-separated packet ids
    81	  supersedes: ""  # optional comma-separated packet ids
    82	```
    83	
    84	Rules: see `auto_mode_contract.md` §2 (unspecified fields fall back to default; marker fields take precedence over `$ARGUMENTS` flags; unknown fields warn; malformed lines parse-error).
    85	
    86	### Default Resolution Table
    87	
    88	| Field | Required | Resolves Via | Default | Tier-2 Candidate |
    89	|-------|----------|--------------|---------|------------------|
    90	| `feature_description` | Y | `$ARGUMENTS` positional feature description, or marker `feature_description` | none | N |
    91	| `spec_folder` | Y | flag `--spec-folder`, flag `--phase-folder`, marker `spec_folder` / `phase_folder`, or targeted choice among existing/new/update-related/skip/phase folder | none | Y, when feature is present but folder choice is ambiguous |
    92	| `execution_mode` | Y | attached suffix `:auto` or marker `execution_mode` | `AUTONOMOUS` under `:auto` | N |
    93	| `dispatch_mode` | Y | marker `dispatch_mode` or default recommended option | `single_agent` | N |
    94	| `memory_choice` | N | marker `memory_choice`, prior-work detection, or default | `skip` when no prior continuity records exist | N |
    95	| `research_intent` | Y | marker `research_intent` or targeted classification question | none | Y |
    96	| `phase_decomposition` | Y | suffix `:with-phases`, marker `phase_decomposition`, or default | `false` | N |
    97	| `phase_count` | N | flag `--phases`, marker `phase_count`, or default | `3` | N |
    98	| `phase_names` | N | flag `--phase-names`, marker `phase_names`, or auto-generate | none | N |
    99	| `phase_folder` | N | flag `--phase-folder`, marker `phase_folder`, or default | none | N |
   100	| `intake_only` | N | flag `--intake-only`, marker `intake_only`, or default | `false` | N |
   101	| `selected_level` | N | flag `--level`, marker `selected_level`, or inline intake contract when required | none | N |
   102	| `start_state` | N | flag `--start-state`, marker `start_state`, folder-state classification, or inline intake contract when required | auto-detect | N |
   103	| `repair_mode` | N | flag `--repair-mode`, marker `repair_mode`, or inline intake contract when required | none | N |
   104	| `record_relationships` | N | flag `--record-relationships`, marker `record_relationships`, or inline intake contract when required | `false` | N |
   105	| `depends_on` | N | flag `--depends-on`, marker `depends_on`, or inline intake relationship capture | none | N |
   106	| `related_to` | N | flag `--related-to`, marker `related_to`, or inline intake relationship capture | none | N |
   107	| `supersedes` | N | flag `--supersedes`, marker `supersedes`, or inline intake relationship capture | none | N |
   108	
   109	**STATUS: BLOCKED**
   110	
   111	```
   112	EXECUTE THIS SINGLE CONSOLIDATED PROMPT:
   113	
   114	1. CHECK mode suffix:
   115	   ├─ ":auto"    → execution_mode = "AUTONOMOUS" (omit Q2)
   116	   ├─ ":confirm" → execution_mode = "INTERACTIVE" (omit Q2)
   117	   └─ No suffix  → execution_mode = "ASK" (include Q2)
   118	
   119	1a. CHECK :with-phases flag:
   120	   ├─ ":with-phases" present → phase_decomposition = TRUE (omit Q6)
   121	   │   Parse additional flags: --phases N (default 3), --phase-names "a,b,c" (optional)
   122	   │   Include Q7 (Phase Count) and Q8 (Phase Names) if not provided via flags
   123	   └─ Not present → phase_decomposition = "ASK" (include Q6)
   124	
   125	1a-b. CHECK --intake-only flag:
   126	   ├─ present → intake_only = TRUE; workflow halts after Emit phase, does not proceed to planning Steps 2–8
   127	   └─ absent → intake_only = FALSE
   128	
   129	1a-c. PARSE intake contract flags (see .opencode/skills/system-spec-kit/references/intake-contract.md §1):
   130	   ├─ --spec-folder=PATH → spec_path = PATH (bypass auto-discovery)

exec
/bin/zsh -lc "sed -n '1,220p' .opencode/skills/system-spec-kit/references/workflows/auto_mode_contract.md" in /Users/michelkerkmeester/MEGA/Development/Code_Environment/Public
 succeeded in 0ms:
---
title: Auto Mode Contract Reference
description: Canonical three-tier `:auto` setup-resolution contract shared by every user-invokable `/command:*:auto` surface. Defines tier semantics (resolve → targeted ask → fail-fast), `PRE-BOUND SETUP ANSWERS:` marker grammar, default-resolution table format, fail-fast error template, `:confirm` invariance, and verification protocol.
---

# Auto Mode Contract Reference

This reference module defines the single canonical `:auto` setup-resolution contract used by every user-invokable `/command:*:auto` surface in spec-kit (`/spec_kit:*`, `/create:*`, `/improve:*`). Each command's §0 cites this contract and supplies only its own per-field Default Resolution Table + `PRE-BOUND SETUP ANSWERS:` field list. The contract semantics, marker grammar, error format, and verification protocol live here.

Origin: shipped in `.opencode/specs/skilled-agent-orchestration/103-spec-kit-auto-mode-noninteractive-contract/001-deep-review-three-tier-setup/` (deep-review prototype) and generalized in `.../002-auto-mode-contract-generalization-to-all-commands/` (12-command rollout).

Related memory: `feedback_auto_mode_ask_only_when_ambiguous.md`, `feedback_codex_spawnagent_allowlist.md`, `feedback_gate3_no_tmp_exemption.md`.

---

## §1. Three-Tier Flow

`:auto` mode does NOT mean "never ask" (too rigid) and does NOT mean "always ask the full setup block" (too soft). It means "ask only when uncertain or ambiguous." This is achieved via three tiers, evaluated in order:

### Tier 1 — Resolve Confidently

When `execution_mode = AUTONOMOUS` (from `:auto` suffix), the command's §0 MUST attempt to resolve every required input from these sources in order:

1. **`$ARGUMENTS` flags** — explicit user-passed flags (e.g. `--max-iterations=10`, `--spec-folder=PATH`, command-specific flags)
2. **`PRE-BOUND SETUP ANSWERS:` block in the prompt body** — see §2 for grammar. Caller's explicit prompt-body binding wins over `$ARGUMENTS` when both are present
3. **Documented per-field defaults** — see the command's own Default Resolution Table (§3) for which fields carry sensible defaults

After resolution: if every required field has a value, persist the resolved map to the command's working-config file (e.g. `deep-review-config.json`, `plan-config.json`), set `STATUS: PASSED`, load the paired YAML workflow. Do NOT emit any setup question. End §0.

### Tier 2 — Targeted Ask

Use Tier 2 ONLY when Tier 1 leaves one or two required inputs unresolved AND each unresolved field is genuinely ambiguous AND no sensible default exists.

Constraints:
- Emit ONE narrow question per ambiguous field, naming only the ambiguous field. NEVER the full consolidated Q-block from the legacy setup phase.
- If two fields are ambiguous but one's resolution likely makes the other obvious (e.g. `review_target_type` may make `spec_folder` self-evident), ask the first one first; do not bundle multiple ambiguities into a single prompt.
- Missing required input (e.g. empty `$ARGUMENTS` with no marker for a required positional) is NOT ambiguity. Absence is a Tier 3 case.
- Wait briefly for user reply. If an answer arrives, merge it into the resolved map and re-run Tier 1 from the default-application step. If stdin is closed (`</dev/null`, redirected output, non-interactive dispatch) and no answer arrives, fall through to Tier 3. Never wait indefinitely.

### Tier 3 — Fail Fast

Use Tier 3 when `:auto` still has unresolved required inputs after Tier 1 and Tier 2, OR when Tier 2 produced no answer because stdin is closed.

Emit the named-missing-inputs error format (§4), exit non-zero, do NOT load the YAML workflow, do NOT emit any further setup question.

---

## §2. PRE-BOUND SETUP ANSWERS Schema

The `PRE-BOUND SETUP ANSWERS:` block is a structured marker the dispatched AI parses out of the prompt body. It allows callers to pre-bind setup field values without using individual `$ARGUMENTS` flags.

Grammar (YAML-style key/value, one field per line):

```
PRE-BOUND SETUP ANSWERS:
  <field_name>: <value>  # optional inline comment
  <field_name>: <value>
  ...
```

Rules:

- The block opens with `PRE-BOUND SETUP ANSWERS:` (exact case-sensitive heading, followed by colon). Indentation MAY be inside a markdown fenced code block or inline in the prompt text.
- Each field is `  <key>: <value>` indented two spaces, one per line.
- Values are interpreted by the command's Default Resolution Table (§3). Field types and value enums are command-specific.
- Comments after `#` on a value line are ignored.
- Unknown fields produce a warning (do not abort), so callers may include forward-compatible fields.
- Fields not specified fall back to: command-specific Default Resolution Table → command-specific default value → unresolved (triggers Tier 2 or Tier 3 per §1).
- Malformed lines (e.g. missing `:`, malformed value type) emit a parse error naming the line. Known fields parsed before the error may still be used; remaining unresolved fields continue to Tier 2 or Tier 3.
- A second `PRE-BOUND SETUP ANSWERS:` block in the same prompt body produces a duplicate-block error.

The marker block applies ONLY under `:auto`. Under `:confirm`, the block is informational and does not skip the consolidated question prompt.

---

## §3. Default Resolution Table

Every command MUST publish a Default Resolution Table in its §0 (after citing this contract). The table lists each setup field with the following columns:

| Field | Required | Resolves Via | Default | Tier-2 Candidate |
|-------|----------|--------------|---------|------------------|

Column meanings:

- **Field**: the field name (matches the schema in §2 and the question label in the legacy consolidated Q-block).
- **Required**: `Y` (must be resolved before YAML load) or `N` (optional).
- **Resolves Via**: ordered list of resolution sources, e.g. `flag → $ARGUMENTS` / `marker → PRE-BOUND` / `default → "<value>"` / `auto-detect from <other field>` / `requires-ask`.
- **Default**: the documented default value when no flag, marker, or auto-detection applies. May be `none` (no default — Tier 2 or Tier 3 candidate).
- **Tier-2 Candidate**: `Y` if a missing value can be resolved by ONE targeted question (per §1); `N` if absence triggers fail-fast (Tier 3).

A field is a Tier-2 candidate only when ALL of:
- No flag exists for it.
- No marker is provided.
- No sensible default exists.
- The field is genuinely required (Required=`Y`).
- A user choice is the only resolution path (ambiguity, not absence).

---

## §4. Tier 3 Fail-Fast Error Template

When Tier 3 fires, the command emits this exact format and exits non-zero:

```
[ERROR] /<command>:auto — required inputs unresolved under autonomous mode:
  - <field>: <why-unresolved>
  - <field>: <why-unresolved>
Resolution: provide via $ARGUMENTS flags, PRE-BOUND SETUP ANSWERS: block, or switch to :confirm mode for interactive setup.
```

Rules:

- Replace `<command>` with the canonical command name (e.g. `spec_kit:deep-review`).
- One bulleted line per unresolved required field.
- `<why-unresolved>` is one short phrase: "missing — no flag, no marker, no default" or "ambiguous — Tier 2 received no answer (stdin closed)".
- Final line cites the three resolution paths verbatim.
- Do NOT load the YAML workflow.
- Do NOT emit setup questions in Tier 3.
- Exit code: non-zero (1 is the convention).

---

## §5. `:confirm` Invariance

The `:confirm` mode (interactive, with full consolidated Q-block) is unaffected by this contract. Commands MUST preserve their existing `:confirm` behavior exactly. The contract applies ONLY when `execution_mode = AUTONOMOUS` (from `:auto` suffix or explicit `--mode=AUTONOMOUS` flag).

Test invariant: a `:confirm` dispatch against any contract-adopting command MUST emit the original consolidated Q-block (Q0..Qn). Regression-check this per command after migration.

---

## §6. Verification Protocol

Each contract-adopting command requires four verification traces (dry-run mental dispatch traces against the command's §0):

### Trace A — Tier 1 pass
Dispatch with all required inputs resolvable (flags + markers + defaults). Expected: STATUS PASSED, YAML loaded, no question emitted.

### Trace B — Tier 2 targeted ask
Dispatch with exactly one ambiguous required field. Expected: ONE narrow question naming only that field; NEVER the full consolidated block.

### Trace C — Tier 3 fail fast
Dispatch with one or more truly missing required inputs (and stdin closed in non-interactive runtimes). Expected: error format from §4, exit non-zero, no YAML load.

### Trace D — `:confirm` regression
Dispatch with `:confirm` suffix and any inputs. Expected: existing full consolidated Q-block emitted.

Live verification (when feasible) extends the dry-run traces with actual non-interactive dispatches (codex `exec </dev/null`, opencode `run --pure ... </dev/null`, claude `--print`) capturing transcripts as evidence. Live verification confirms the contract works under real runtime stdin-closure conditions.

Evidence schema (one file per dispatch):
- Command invocation verbatim
- Full transcript
- Verdict footer: PASS / PARTIAL / FAIL / SKIP
- Optional: timing, model, runtime gotchas observed

Stored under `<packet>/evidence/<command-slug>-<trace>.txt`.

---

## §7. Adoption Checklist

For each command adopting this contract, the §0 of the command markdown:

- [ ] Adds a one-line citation: `Setup contract: see references/workflows/auto_mode_contract.md`
- [ ] Provides its own per-field Default Resolution Table (§3) listing every Q-block field with the four columns
- [ ] Provides its own `PRE-BOUND SETUP ANSWERS:` field list (one row per setup field, matching the Default Resolution Table)
- [ ] Documents any command-specific Tier-2 ordering rule (e.g. "ask review_target_type before spec_folder")
- [ ] Updates frontmatter `argument-hint` to reference the new bypass capability
- [ ] Preserves the existing `:confirm` consolidated Q-block path untouched
- [ ] Authors §0 dry-run traces (A/B/C/D) and stores them under the adopting packet's `evidence/`

Commands that have adopted this contract:

- `/spec_kit:deep-review` (prototype) — see `.../103/001-deep-review-three-tier-setup/`
- (to be appended as `.../103/002-...` rolls out)

---

## §8. Out of Scope

- Commands without paired YAML workflows (`/improve:prompt`, `agent_router`, etc.) — they have no setup-phase surface where the contract applies.
- Skill-internal `:auto` flows (sk-doc, sk-code routing, etc.) — those are skill SKILL.md surfaces, not `/command:*` surfaces.
- YAML workflow internal interaction gates (e.g. mid-loop approval gates) — handled by each YAML's own non-interactivity rules, not this contract.
- Cross-command `:auto` integration (e.g. `/spec_kit:plan:auto` chained into `/spec_kit:implement:auto`) — separate contract concern.

codex
Citation present: yes, line 46

Section zero Tier reached: 1

Setup question emitted: no

Resolved field map:
- feature_description: `Add passwordless login`
- spec_folder: `.opencode/specs/103-example/001-passwordless-login/`
- execution_mode: `AUTONOMOUS`
- dispatch_mode: `single_agent`
- memory_choice: `skip`
- research_intent: `add_feature`
- phase_decomposition: `false`
- phase_count: `3`
- phase_names: `""`
- phase_folder: `""`
- intake_only: `false`
- selected_level: `""`
- start_state: `""`
- repair_mode: `""`
- record_relationships: `false`
- depends_on: `""`
- related_to: `""`
- supersedes: `""`

STATUS value: PASSED

Verdict: PASS

Tier-1 trace: `:auto` sets `execution_mode = AUTONOMOUS`; the `PRE-BOUND SETUP ANSWERS:` block is valid and binds every required field: `feature_description`, `spec_folder`, `execution_mode`, `dispatch_mode`, `research_intent`, and `phase_decomposition`. Optional fields are either explicitly bound or default-compatible. No Tier-2 ambiguity remains, so the legacy consolidated Q-block is not emitted and Tier 3 does not fire. I did not load the YAML workflow or write `plan-config.json`, per your test constraints.
hook: Stop
hook: Stop Completed
tokens used
15,563
Citation present: yes, line 46

Section zero Tier reached: 1

Setup question emitted: no

Resolved field map:
- feature_description: `Add passwordless login`
- spec_folder: `.opencode/specs/103-example/001-passwordless-login/`
- execution_mode: `AUTONOMOUS`
- dispatch_mode: `single_agent`
- memory_choice: `skip`
- research_intent: `add_feature`
- phase_decomposition: `false`
- phase_count: `3`
- phase_names: `""`
- phase_folder: `""`
- intake_only: `false`
- selected_level: `""`
- start_state: `""`
- repair_mode: `""`
- record_relationships: `false`
- depends_on: `""`
- related_to: `""`
- supersedes: `""`

STATUS value: PASSED

Verdict: PASS

Tier-1 trace: `:auto` sets `execution_mode = AUTONOMOUS`; the `PRE-BOUND SETUP ANSWERS:` block is valid and binds every required field: `feature_description`, `spec_folder`, `execution_mode`, `dispatch_mode`, `research_intent`, and `phase_decomposition`. Optional fields are either explicitly bound or default-compatible. No Tier-2 ambiguity remains, so the legacy consolidated Q-block is not emitted and Tier 3 does not fire. I did not load the YAML workflow or write `plan-config.json`, per your test constraints.


=== EXIT 0; WALL 37s ===
