@hanzlaa/rcode 3.6.16 → 4.0.0

package/rihal/workflows/plan-prd-express.md

@@ -1,108 +0,0 @@
-<purpose>
-Sub-step of plan.md — Step 3.5 PRD Express Path. Handles the --prd flag: parses a PRD document and auto-generates CONTEXT.md from it, bypassing manual discussion.
-</purpose>
-
-## 3.5. Handle PRD Express Path
-
-**Skip if:** No `--prd` flag in arguments.
-
-**If `--prd <filepath>` provided:**
-
-1. Read the PRD file:
-```bash
-PRD_CONTENT=$(cat "$PRD_FILE" 2>/dev/null)
-if [ -z "$PRD_CONTENT" ]; then
-  echo "Error: PRD file not found: $PRD_FILE"
-  exit 1
-fi
-```
-
-2. Display banner:
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- Rihal ► PRD EXPRESS PATH
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Using PRD: {PRD_FILE}
-Generating CONTEXT.md from requirements...
-```
-
-3. Parse the PRD content and generate CONTEXT.md. The orchestrator should:
-   - Extract all requirements, user stories, acceptance criteria, and constraints from the PRD
-   - Map each to a locked decision (everything in the PRD is treated as a locked decision)
-   - Identify any areas the PRD doesn't cover and mark as "Claude's Discretion"
-   - **Extract canonical refs** from ROADMAP.md for this phase, plus any specs/ADRs referenced in the PRD — expand to full file paths (MANDATORY)
-   - Create CONTEXT.md in the phase directory
-
-4. Write CONTEXT.md:
-```markdown
-# Phase [X]: [Name] - Context
-
-**Gathered:** [date]
-**Status:** Ready for planning
-**Source:** PRD Express Path ({PRD_FILE})
-
-<domain>
-## Phase Boundary
-
-[Extracted from PRD — what this phase delivers]
-
-</domain>
-
-<decisions>
-## Implementation Decisions
-
-{For each requirement/story/criterion in the PRD:}
-### [Category derived from content]
-- [Requirement as locked decision]
-
-### Claude's Discretion
-[Areas not covered by PRD — implementation details, technical choices]
-
-</decisions>
-
-<canonical_refs>
-## Canonical References
-
-**Downstream agents MUST read these before planning or implementing.**
-
-[MANDATORY. Extract from ROADMAP.md and any docs referenced in the PRD.
-Use full relative paths. Group by topic area.]
-
-### [Topic area]
-- `path/to/spec-or-adr.md` — [What it decides/defines]
-
-[If no external specs: "No external specs — requirements fully captured in decisions above"]
-
-</canonical_refs>
-
-<specifics>
-## Specific Ideas
-
-[Any specific references, examples, or concrete requirements from PRD]
-
-</specifics>
-
-<deferred>
-## Deferred Ideas
-
-[Items in PRD explicitly marked as future/v2/out-of-scope]
-[If none: "None — PRD covers phase scope"]
-
-</deferred>
-
----
-
-*Phase: XX-name*
-*Context gathered: [date] via PRD Express Path*
-```
-
-5. Commit:
-```bash
-node ".rihal/bin/rihal-tools.cjs" commit "docs(${padded_phase}): generate context from PRD" --files "${phase_dir}/${padded_phase}-CONTEXT.md"
-```
-
-6. Set `context_content` to the generated CONTEXT.md content and continue to step 5 (Handle Research).
-
-**Effect:** This completely bypasses step 4 (Load CONTEXT.md) since we just created it. The rest of the workflow (research, planning, verification) proceeds normally with the PRD-derived context.
-

package/rihal/workflows/plan-research-validation.md

@@ -1,313 +0,0 @@
-<purpose>
-Sub-steps of plan.md — Steps 5 through 5.7. Handles research, validation architecture, security threat model gate, UI design contract gate, and schema push detection.
-</purpose>
-
-## 5. Handle Research
-
-**Skip if:** `--gaps` flag or `--skip-research` flag or `--reviews` flag.
-
-**If `has_research` is true (from init) AND no `--research` flag:** Use existing, skip to step 6.
-
-**If RESEARCH.md missing AND `has_context` is true AND no `--research` flag:** Skip research silently and proceed to step 6. CONTEXT.md already captures the user's design decisions — re-researching adds tokens without new signal. Display: `Research skipped — CONTEXT.md found (use --research to force)`. This closes #588.
-
-**If RESEARCH.md missing OR `--research` flag:**
-
-**If no explicit flag (`--research` or `--skip-research`) and not `--auto`:**
-Ask the user whether to research, with a contextual recommendation based on the phase:
-
-If `TEXT_MODE` is true, present as a plain-text numbered list:
-```
-Research before planning Phase {X}: {phase_name}?
-
-1. Research first (Recommended) — Investigate domain, patterns, and dependencies before planning. Best for new features, unfamiliar integrations, or architectural changes.
-2. Skip research — Plan directly from context and requirements. Best for bug fixes, simple refactors, or well-understood tasks.
-
-Enter number:
-```
-
-Otherwise use AskUserQuestion:
-```
-AskUserQuestion([
-  {
-    question: "Research before planning Phase {X}: {phase_name}?",
-    header: "Research",
-    multiSelect: false,
-    options: [
-      { label: "Research first (Recommended)", description: "Investigate domain, patterns, and dependencies before planning. Best for new features, unfamiliar integrations, or architectural changes." },
-      { label: "Skip research", description: "Plan directly from context and requirements. Best for bug fixes, simple refactors, or well-understood tasks." }
-    ]
-  }
-])
-```
-
-If user selects "Skip research": skip to step 6.
-
-**If `--auto` and `research_enabled` is false:** Skip research silently (preserves automated behavior).
-
-Display banner:
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- Rihal ► RESEARCHING PHASE {X}
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-◆ Spawning researcher...
-```
-
-### Spawn rihal-phase-researcher
-
-```bash
-PHASE_DESC=$(node ".rihal/bin/rihal-tools.cjs" roadmap get-phase "${PHASE}" --pick section)
-```
-
-Research prompt:
-
-```markdown
-<objective>
-Research how to implement Phase {phase_number}: {phase_name}
-Answer: "What do I need to know to PLAN this phase well?"
-</objective>
-
-<files_to_read>
-- {context_path} (USER DECISIONS from /rihal-discuss-phase)
-- {requirements_path} (Project requirements)
-- {state_path} (Project decisions and history)
-</files_to_read>
-
-${AGENT_SKILLS_RESEARCHER}
-
-<additional_context>
-**Phase description:** {phase_description}
-**Phase requirement IDs (MUST address):** {phase_req_ids}
-
-**Project instructions:** Read ./CLAUDE.md if exists — follow project-specific guidelines
-**Project skills:** Check .claude/skills/ or .agents/skills/ directory (if either exists) — read SKILL.md files, research should account for project skill patterns
-</additional_context>
-
-<output>
-Write to: {phase_dir}/{phase_num}-RESEARCH.md
-
-**MANDATORY section — include even if brief:**
-
-```markdown
-## Validation Architecture
-
-| Concern | Test File | Command | When (Wave) |
-|---------|-----------|---------|-------------|
-| {feature} | {path/to/test.ts} | {run command} | Wave {N} |
-```
-
-This section is required to enable Dimension 8 (Nyquist Compliance) in the plan checker. If no automated tests are feasible for this phase, write:
-
-```markdown
-## Validation Architecture
-
-Manual verification only — no automated test files planned for this phase.
-Reason: {explain why}
-```
-</output>
-```
-
-```
-Task(
-  prompt=research_prompt,
-  subagent_type="rihal-phase-researcher",
-  model="{model}",
-  model="{researcher_model}",
-  description="Research Phase {phase}"
-)
-```
-
-### Handle Researcher Return
-
-- **`## RESEARCH COMPLETE`:** Display confirmation, continue to step 6
-- **`## RESEARCH BLOCKED`:** Display blocker, offer: 1) Provide context, 2) Skip research, 3) Abort
-
-## 5.5. Create Validation Strategy
-
-Skip if `nyquist_validation_enabled` is false OR `research_enabled` is false.
-
-If `research_enabled` is false and `nyquist_validation_enabled` is true: warn "Nyquist validation enabled but research disabled — VALIDATION.md cannot be created without RESEARCH.md. Plans will lack validation requirements (Dimension 8)." Continue to step 6.
-
-**But Nyquist is not applicable for this run** when all of the following are true:
-- `research_enabled` is false
-- `has_research` is false
-- no `--research` flag was provided
-
-In that case: **skip validation-strategy creation entirely**. Do **not** expect `RESEARCH.md` or `VALIDATION.md` for this run, and continue to Step 6.
-
-```bash
-grep -l "## Validation Architecture" "${PHASE_DIR}"/*-RESEARCH.md 2>/dev/null || true
-```
-
-**If found:**
-1. Read template: `.rihal/templates/VALIDATION.md`
-2. Write to `${PHASE_DIR}/${PADDED_PHASE}-VALIDATION.md` (use Write tool)
-3. Fill frontmatter: `{N}` → phase number, `{phase-slug}` → slug, `{date}` → current date
-4. Verify:
-```bash
-test -f "${PHASE_DIR}/${PADDED_PHASE}-VALIDATION.md" && echo "VALIDATION_CREATED=true" || echo "VALIDATION_CREATED=false"
-```
-5. If `VALIDATION_CREATED=false`: STOP — do not proceed to Step 6
-6. If `commit_docs`: `commit "docs(phase-${PHASE}): add validation strategy"`
-
-**If not found:** Warn and continue — plans may fail Dimension 8.
-
-## 5.55. Security Threat Model Gate
-
-> Skip if `workflow.security_enforcement` is explicitly `false`. Absent = enabled.
-
-```bash
-SECURITY_CFG=$(node ".rihal/bin/rihal-tools.cjs" config-get workflow.security_enforcement --raw 2>/dev/null || echo "true")
-SECURITY_ASVS=$(node ".rihal/bin/rihal-tools.cjs" config-get workflow.security_asvs_level --raw 2>/dev/null || echo "1")
-SECURITY_BLOCK=$(node ".rihal/bin/rihal-tools.cjs" config-get workflow.security_block_on --raw 2>/dev/null || echo "high")
-```
-
-**If `SECURITY_CFG` is `false`:** Skip to step 5.6.
-
-**If `SECURITY_CFG` is `true`:** Display banner:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- Rihal ► SECURITY THREAT MODEL REQUIRED (ASVS L{SECURITY_ASVS})
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Each SPRINT.md must include a <threat_model> block.
-Block on: {SECURITY_BLOCK} severity threats.
-Opt out: set security_enforcement: false in .planning/config.json
-```
-
-Continue to step 5.6. Security config is passed to the planner in step 8.
-
-## 5.6. UI Design Contract Gate
-
-> Skip if `workflow.ui_phase` is explicitly `false` AND `workflow.ui_safety_gate` is explicitly `false` in `.planning/config.json`. If keys are absent, treat as enabled.
-
-```bash
-UI_PHASE_CFG=$(node ".rihal/bin/rihal-tools.cjs" config-get workflow.ui_phase 2>/dev/null || echo "true")
-UI_GATE_CFG=$(node ".rihal/bin/rihal-tools.cjs" config-get workflow.ui_safety_gate 2>/dev/null || echo "true")
-```
-
-**If both are `false`:** Skip to step 6.
-
-Check if phase has frontend indicators:
-
-```bash
-PHASE_SECTION=$(node ".rihal/bin/rihal-tools.cjs" roadmap get-phase "${PHASE}" 2>/dev/null)
-echo "$PHASE_SECTION" | grep -iE "UI|interface|frontend|component|layout|page|screen|view|form|dashboard|widget" > /dev/null 2>&1
-HAS_UI=$?
-```
-
-**If `HAS_UI` is 0 (frontend indicators found):**
-
-Check for existing UI-SPEC:
-```bash
-UI_SPEC_FILE=$(ls "${PHASE_DIR}"/*-UI-SPEC.md 2>/dev/null | head -1)
-```
-
-**If UI-SPEC.md found:** Set `UI_SPEC_PATH=$UI_SPEC_FILE`. Display: `Using UI design contract: ${UI_SPEC_PATH}`
-
-**If UI-SPEC.md missing AND `UI_GATE_CFG` is `true`:**
-
-Read auto-chain state:
-```bash
-AUTO_CHAIN=$(node ".rihal/bin/rihal-tools.cjs" config-get workflow._auto_chain_active 2>/dev/null || echo "false")
-```
-
-**If `AUTO_CHAIN` is `true` (running inside a `--chain` or `--auto` pipeline):**
-
-Auto-generate UI-SPEC without prompting:
-```
-Skill(skill="rihal-ui-phase", args="${PHASE} --auto ${Rihal_WS}")
-```
-After `rihal-ui-phase` returns, re-read:
-```bash
-UI_SPEC_FILE=$(ls "${PHASE_DIR}"/*-UI-SPEC.md 2>/dev/null | head -1)
-UI_SPEC_PATH="${UI_SPEC_FILE}"
-```
-Continue to step 6.
-
-**If `AUTO_CHAIN` is `false` (manual invocation):**
-
-If `TEXT_MODE` is true, present as a plain-text numbered list:
-```
-Phase {N} has frontend indicators but no UI-SPEC.md. Generate a design contract before planning?
-
-1. Generate UI-SPEC first — Run /rihal-ui-phase {N} then re-run /rihal-plan {N}
-2. Continue without UI-SPEC
-3. Not a frontend phase
-
-Enter number:
-```
-
-Otherwise use AskUserQuestion:
-- header: "UI Design Contract"
-- question: "Phase {N} has frontend indicators but no UI-SPEC.md. Generate a design contract before planning?"
-- options:
-  - "Generate UI-SPEC first" → Display: "Run `/rihal-ui-phase {N} ${Rihal_WS}` then re-run `/rihal-plan {N} ${Rihal_WS}`". Exit workflow.
-  - "Continue without UI-SPEC" → Continue to step 6.
-  - "Not a frontend phase" → Continue to step 6.
-
-**If `HAS_UI` is 1 (no frontend indicators):** Skip silently to step 5.7.
-
-## 5.7. Schema Push Detection Gate
-
-> Detects schema-relevant files in the phase scope and injects a mandatory `[BLOCKING]` schema push task into the plan. Prevents false-positive verification where build/types pass because TypeScript types come from config, not the live database.
-
-Check if any files in the phase scope match schema patterns:
-
-```bash
-PHASE_SECTION=$(node ".rihal/bin/rihal-tools.cjs" roadmap get-phase "${PHASE}" --pick section 2>/dev/null)
-```
-
-Scan `PHASE_SECTION`, `CONTEXT.md` (if loaded), and `RESEARCH.md` (if exists) for file paths matching these ORM patterns:
-
-| ORM | File Patterns |
-|-----|--------------|
-| Payload CMS | `src/collections/**/*.ts`, `src/globals/**/*.ts` |
-| Prisma | `prisma/schema.prisma`, `prisma/schema/*.prisma` |
-| Drizzle | `drizzle/schema.ts`, `src/db/schema.ts`, `drizzle/*.ts` |
-| Supabase | `supabase/migrations/*.sql` |
-| TypeORM | `src/entities/**/*.ts`, `src/migrations/**/*.ts` |
-
-Also check if any existing SPRINT.md files for this phase already reference these file patterns in `files_modified`.
-
-**If schema-relevant files detected:**
-
-Set `SCHEMA_PUSH_REQUIRED=true` and `SCHEMA_ORM={detected_orm}`.
-
-Determine the push command for the detected ORM:
-
-| ORM | Push Command | Non-TTY Workaround |
-|-----|-------------|-------------------|
-| Payload CMS | `npx payload migrate` | `CI=true PAYLOAD_MIGRATING=true npx payload migrate` |
-| Prisma | `npx prisma db push` | `npx prisma db push --accept-data-loss` (if destructive) |
-| Drizzle | `npx drizzle-kit push` | `npx drizzle-kit push` |
-| Supabase | `supabase db push` | Set `SUPABASE_ACCESS_TOKEN` env var |
-| TypeORM | `npx typeorm migration:run` | `npx typeorm migration:run -d src/data-source.ts` |
-
-Inject the following into the planner prompt (step 8) as an additional constraint:
-
-```markdown
-<schema_push_requirement>
-**[BLOCKING] Schema Push Required**
-
-This phase modifies schema-relevant files ({detected_files}). The planner MUST include
-a `[BLOCKING]` task that runs the database schema push command AFTER all schema file
-modifications are complete but BEFORE verification.
-
-- ORM detected: {SCHEMA_ORM}
-- Push command: {push_command}
-- Non-TTY workaround: {env_hint}
-- If push requires interactive prompts that cannot be suppressed, flag the task for
-  manual intervention with `autonomous: false`
-
-This task is mandatory — the phase CANNOT pass verification without it. Build and
-type checks will pass without the push (types come from config, not the live database),
-creating a false-positive verification state.
-</schema_push_requirement>
-```
-
-Display: `Schema files detected ({SCHEMA_ORM}) — [BLOCKING] push task will be injected into plans`
-
-**If no schema-relevant files detected:** Skip silently to step 6.
-

package/rihal/workflows/plan-spawn-planner.md

@@ -1,257 +0,0 @@
-<purpose>
-Sub-step of plan.md — Step 8 Spawn rihal-planner Agent. Spawns rihal-planner with full context to generate SPRINT.md plans. Includes deep-work rules and downstream consumer spec.
-</purpose>
-
-<filename_convention>
-Issue #657 — every SPRINT.md, including the first plan in a phase, uses the
-sequence-numbered form `{phase}-{plan}-SPRINT.md` (no leading zeros per #652).
-Examples: `8-1-SPRINT.md`, `8-2-SPRINT.md`. Do NOT emit a bare `{phase}-SPRINT.md`
-or `{phase}-PLAN.md` for the first plan — that creates an inconsistent series
-when a second plan is added later. The plan-number computation in plan.md uses
-`NEXT_PLAN_NUMBER=$((EXISTING_PLAN_COUNT + 1))` and starts at 1 for new phases.
-</filename_convention>
-
-## 8. Spawn rihal-planner Agent
-
-Display banner:
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- Rihal ► PLANNING PHASE {X}
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-◆ Spawning planner...
-```
-
-**Gap-closure planner prompt (when `GAPS_MODE=true`):**
-
-When `GAPS_MODE=true`, use the prompt below in place of the standard planner prompt. The planner must emit **exactly one** new plan file at `${GAP_PLAN_PATH}` that closes the listed gaps. Do not create CONTEXT.md or RESEARCH.md references — gaps are grounded in already-shipped code.
-
-```markdown
-<planning_context>
-**Phase:** {phase_number}
-**Mode:** gap_closure
-**Phase goal:** {goal from ROADMAP.md}
-
-<files_to_read>
-- {VERIFICATION_FILE} (Authoritative verification report — source of truth for gaps)
-- {state_path} (Project State)
-- {roadmap_path} (Roadmap)
-- {requirements_path} (Requirements)
-- Existing plan files in this phase: {EXISTING_PLAN_FILES}
-- Existing summary files in this phase: {EXISTING_SUMMARY_FILES}
-</files_to_read>
-
-${AGENT_SKILLS_PLANNER}
-
-<gap_list>
-{Serialized GAP_LIST — for each gap include id, title, expected behavior, actual behavior, status (gap_found|partial), and source section.}
-</gap_list>
-
-<output>
-Write a single new plan file to: {GAP_PLAN_PATH}
-
-Frontmatter MUST include:
----
-phase: {phase_number}
-plan_number: {NEXT_PLAN_NUMBER}
-gap_closure: true
-wave: 1
-depends_on: []
-files_modified: [...]
-autonomous: true|false
----
-
-Each gap in the list MUST be addressed by at least one task. Use the anti-shallow execution rules below.
-</output>
-</planning_context>
-```
-
-Proceed to the standard planner Task invocation below, but pass the gap-closure prompt above. After the planner returns, the normal plan-checker / revision loop (step 10+) runs unchanged.
-
----
-
-**Standard planner prompt (when `GAPS_MODE=false`):**
-
-Planner prompt:
-
-```markdown
-<planning_context>
-**Phase:** {phase_number}
-**Mode:** {standard | gap_closure | reviews}
-
-<files_to_read>
-- {state_path} (Project State)
-- {roadmap_path} (Roadmap)
-- {requirements_path} (Requirements)
-- {context_path} (USER DECISIONS from /rihal-discuss-phase — read `<decisions>` for locked choices AND `<code_context>` for existing code patterns, reusable assets, and architectural notes gathered during discuss-phase)
-- {research_path} (Technical Research)
-- {verification_path} (Verification Gaps - if --gaps)
-- {uat_path} (UAT Gaps - if --gaps)
-- {reviews_path} (Cross-AI Review Feedback - if --reviews)
-- {UI_SPEC_PATH} (UI Design Contract — visual/interaction specs, if exists)
-${CONTEXT_WINDOW >= 500000 ? `
-**Cross-phase context (1M model enrichment — most recent 5 phases only to avoid context overflow):**
-- Prior phase CONTEXT.md files (locked decisions from earlier phases — maintain consistency). Cap: read the 5 most recent phases by phase number only.
-- Prior phase SUMMARY.md files (what was actually built — reuse patterns, avoid duplication). Cap: read the 5 most recent phases by phase number only. Specifically check **Provides** sections: these list functions, APIs, and models from earlier phases that this phase can reuse without rebuilding.
-` : ''}
-</files_to_read>
-
-${AGENT_SKILLS_PLANNER}
-
-**Phase requirement IDs (every ID MUST appear in a plan's `requirements` field):** {phase_req_ids}
-
-**Project instructions:** Read ./CLAUDE.md if exists — follow project-specific guidelines
-**Project skills:** Check .claude/skills/ or .agents/skills/ directory (if either exists) — read SKILL.md files, plans should account for project skill rules
-
-</planning_context>
-
-<downstream_consumer>
-Output consumed by /rihal-execute. Plans need:
-- Frontmatter (wave, depends_on, autonomous, **files_modified** — aggregated list of all file paths from `<files>` blocks across every task; used by executor for intra-wave parallel-safety overlap detection)
-- Tasks in XML format with read_first, files, acceptance_criteria, verify (with `<automated>` child), and done fields (MANDATORY on every task)
-- Verification criteria
-- must_haves for goal-backward verification
-</downstream_consumer>
-
-<deep_work_rules>
-## File Structure Map (REQUIRED — before task decomposition)
-
-Before writing any task, produce a file structure map listing every file this plan will create or modify:
-
-```
-FILES_TO_CREATE:
-  - exact/path/to/new/file.ts  — responsibility: [one sentence]
-FILES_TO_MODIFY:
-  - exact/path/to/existing.ts  — what changes: [one sentence]
-FILES_FOR_TESTS:
-  - tests/exact/path/test.ts   — tests for: [one sentence]
-```
-
-Rules:
-- Each file has one clear responsibility — if you can't describe it in one sentence, split the file
-- Files that change together should live together (split by responsibility, not layer)
-- This map is what informs task decomposition — each task should produce self-contained changes
-- In existing codebases: follow established patterns; only restructure files if a file is genuinely unwieldy and the split is included as its own task
-
-## No-Placeholders Rule (HARD BLOCKER)
-
-Every step must contain the actual content the executor needs. These are **plan failures** — never write them:
-- "TBD", "TODO", "implement later", "fill in details"
-- "Add appropriate error handling" / "add validation" / "handle edge cases" (without code)
-- "Write tests for the above" (without actual test code)
-- "Similar to Task N" — copy the code; executor may read tasks out of order
-- Steps that describe what to do without showing how (code blocks required for code steps)
-- References to types, functions, or methods not yet defined in any task in this plan
-
-If a step would require TBD content, either: (a) do the research now and fill it in, or (b) split into a research task that outputs a decision, followed by an implementation task that consumes it.
-
-## Anti-Shallow Execution Rules (MANDATORY)
-
-Every task MUST include these fields — they are NOT optional:
-
-1. **`<read_first>`** — Files the executor MUST read before touching anything. Always include:
-   - The file being modified (so executor sees current state, not assumptions)
-   - Any "source of truth" file referenced in CONTEXT.md (reference implementations, existing patterns, config files, schemas)
-   - Any file whose patterns, signatures, types, or conventions must be replicated or respected
-
-2. **`<files>`** — Exact files this task will modify or create. One path per line. Used by:
-   - Wave conflict checker (detects parallel tasks touching the same file)
-   - Verifier (confirms per-task file changes were actually made)
-   - Executor checkpoint (knows what to stage after each task)
-   - Example: `src/auth/auth.service.ts`, `tests/auth/auth.service.test.ts`
-
-3. **`<acceptance_criteria>`** — Verifiable conditions that prove the task was done correctly. Rules:
-   - Every criterion must be checkable with grep, file read, test command, or CLI output
-   - NEVER use subjective language ("looks correct", "properly configured", "consistent with")
-   - ALWAYS include exact strings, patterns, values, or command outputs that must be present
-   - Examples:
-     - Code: `auth.py contains def verify_token(` / `test_auth.py exits 0`
-     - Config: `.env.example contains DATABASE_URL=` / `Dockerfile contains HEALTHCHECK`
-     - Docs: `README.md contains '## Installation'` / `API.md lists all endpoints`
-     - Infra: `deploy.yml has rollback step` / `docker-compose.yml has healthcheck for db`
-
-4. **`<verify>`** — Shell commands that PROVE the acceptance criteria are met. Run by executor after task completes and by verifier during post-execution check. The block MUST contain an `<automated>` child with the exact commands to run (Dimension 8 hard-blocks without it). Rules:
-   - `<automated>` commands must exit 0 on success, non-zero on failure
-   - Prefer `grep -q` for presence checks, `test -f` for file existence, project test runner for behavior
-   - Keep commands short and composable — one check per line
-   - If test file doesn't exist yet (TDD tasks), write `<automated>MISSING</automated>` and add a Wave 0 task to create the test
-   - Example structure:
-     ```xml
-     <verify>
-       <automated>
-         grep -q 'def verify_token' src/auth.py
-         python -m pytest tests/test_auth.py -x -q 2>&1 | grep -q 'passed'
-         test -f src/components/Button.tsx
-       </automated>
-     </verify>
-     ```
-
-5. **`<done>`** — Observable acceptance state: a single sentence describing what is TRUE when this task is complete. Must be user/output-observable, not implementation-focused. Examples:
-   - `auth.py exports verify_token() and tests pass`
-   - `Button.tsx renders with correct className, no inline styles`
-   - `.env.example contains DATABASE_URL and REDIS_URL entries`
-
-6. **`<action>`** — Must include CONCRETE values, not references. Rules:
-   - NEVER say "align X with Y", "match X to Y", "update to be consistent" without specifying the exact target state
-   - ALWAYS include the actual values: config keys, function signatures, SQL statements, class names, import paths, env vars, etc.
-   - If CONTEXT.md has a comparison table or expected values, copy them into the action verbatim
-   - The executor should be able to complete the task from the action text alone, without needing to read CONTEXT.md or reference files (read_first is for verification, not discovery)
-
-**Optional — use when the task extends or implements existing code:**
-
-7. **`<interfaces>`** — Relevant class/function/type signatures from existing code that this task must implement, extend, or call. Embed the actual signatures here so the executor does not burn tool calls re-reading files.
-   - Extract from `<read_first>` files during planning (planner already reads them)
-   - Include only what the executor needs: method signatures, interface definitions, relevant types
-   - Do NOT include full file contents — only the contract boundary
-   - Example:
-     ```typescript
-     // src/services/auth.service.ts
-     interface AuthService {
-       verifyToken(token: string): Promise<User>
-       refreshSession(userId: string): Promise<Session>
-     }
-     ```
-
-**Why this matters:** Executor agents work from the plan text. Vague instructions like "update the config to match production" produce shallow one-line changes. Concrete instructions with `<files>`, `<verify>` commands, and embedded `<interfaces>` give the executor everything needed to do complete, correct work without extra tool calls.
-</deep_work_rules>
-
-<quality_gate>
-- [ ] File structure map written before first task (files_to_create / files_to_modify / files_for_tests)
-- [ ] No placeholder patterns: no TBD/TODO/implement-later, no "similar to Task N", no code steps without code
-- [ ] SPRINT.md files created in phase directory
-- [ ] Each plan has valid frontmatter including `files_modified:` array aggregating all `<files>` paths across tasks (consumed by execute.md intra-wave overlap checker)
-- [ ] Tasks are specific and actionable
-- [ ] Every task has `<read_first>` with at least the file being modified
-- [ ] Every task has `<files>` listing exact files this task will modify or create
-- [ ] Every task has `<acceptance_criteria>` with grep-verifiable conditions
-- [ ] Every task has `<verify>` with an `<automated>` child containing at least one shell command (Dimension 8 blocker)
-- [ ] Every task has `<done>` with a single observable acceptance sentence (Dimension 2 requirement)
-- [ ] Every `<action>` contains concrete values (no "align X with Y" without specifying what)
-- [ ] Tasks extending existing code have `<interfaces>` with relevant signatures
-- [ ] Type/name consistency: function names, types, and method signatures match across all tasks (no rename drift)
-- [ ] Dependencies correctly identified
-- [ ] Waves assigned for parallel execution
-- [ ] must_haves derived from phase goal
-</quality_gate>
-
-<self_review>
-After writing the complete plan, review the spec with fresh eyes before handing off:
-
-1. **Spec coverage** — skim each requirement in the phase goal / CONTEXT.md decisions. Can you point to a task that implements it? List any gaps; add tasks if needed.
-2. **Placeholder scan** — search the plan for the no-placeholder patterns listed above. Fix any found inline.
-3. **Type consistency** — check that function names, types, and method signatures used in later tasks match what earlier tasks define. A method called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.
-
-Fix issues inline. No sub-agent needed — this is a quick self-check before the sprint-checker runs.
-</self_review>
-```
-
-```
-Task(
-  prompt=filled_prompt,
-  subagent_type="rihal-planner",
-  model="{model}",
-  model="{planner_model}",
-  description="Plan Phase {phase}"
-)
-```
-