@haposoft/cafekit 0.16.0-rc.6 → 0.16.0-rc.7

package/bin/phases/opencode-runtime.js

@@ -1,38 +0,0 @@
-/**
- * Phase: OpenCode runtime installation.
- *
- * Delegates to the existing opencode-install.js module (kept as-is) in the
- * exact original order. These writers manage their own files (plugins, command
- * templates, AGENTS.md, opencode.json) and honor the legacy `upgrade` option.
- * In dry-run we skip them and report intent, since they are not dry-run aware.
- */
-
-const {
-  copyOpenCodeSharedRuntimeFiles,
-  copyOpenCodePlugins,
-  copyOpenCodeCommandTemplates,
-  copyOpenCodeAgentsMdFile,
-  mergeOpenCodeConfig
-} = require('../lib/opencode-install');
-const { copyRulesDirectory } = require('./claude-runtime');
-
-function installOpenCodeRuntime(ctx, platformKey) {
-  if (platformKey !== 'opencode') return;
-
-  if (ctx.dryRun) {
-    ctx.ui.detail('  → [dry-run] OpenCode runtime (plugins, command templates, AGENTS.md, opencode.json) would be installed');
-    // rules/ is dry-run aware; still preview it.
-    copyRulesDirectory(ctx, platformKey);
-    return;
-  }
-
-  const { results, options } = ctx;
-  copyOpenCodeSharedRuntimeFiles(platformKey, results, options);
-  copyOpenCodePlugins(platformKey, results, options);
-  copyOpenCodeCommandTemplates(platformKey, results, options);
-  copyOpenCodeAgentsMdFile(platformKey, results, options);
-  copyRulesDirectory(ctx, platformKey);
-  mergeOpenCodeConfig(platformKey, results);
-}
-
-module.exports = { installOpenCodeRuntime };

package/src/claude/skills/specs/references/archive-workflow.md

@@ -1,74 +0,0 @@
-# Archive Workflow
-
-## Purpose
-
-Archive completed specs, write technical journals summarizing the work, and clean up the `specs/` directory.
-
-## Spec Resolution
-
-1. If `<feature>` argument provided → archive that specific spec
-2. If not → scan all specs in `specs/`, filter those with fully completed `progress`
-
-## 5-Step Workflow
-
-### Step 1: Read Spec Files
-- `spec.json` — metadata and status
-- Read first 20 lines of each task file to understand progress
-- Determine which specs are complete vs still in-progress
-
-### Step 2: Summarize & Write Journal
-Ask user via `AskUserQuestion`: "Would you like to write technical journal entries for these specs?"
-
-If user selects "Yes":
-- Analyze information from Step 1
-- Spawn journal-writer agent to document each spec
-- Journal entries should be concise, focusing on: key events, major changes, impact, decisions
-- Save to `./docs/journals/`
-
-If user selects "No": skip this step.
-
-### Step 3: Confirm Action
-Ask user via `AskUserQuestion`:
-- "Archive all completed specs"
-- "Select specific specs to archive"
-- "Cancel, don't archive"
-
-Then ask:
-- "Move to `specs/archive/`"
-- "Delete permanently"
-
-### Step 4: Execute Archive
-Based on user's choice:
-- **Move:** `mv specs/<feature> specs/archive/<feature>`
-- **Delete:** `rm -rf specs/<feature>` (⚠️ requires confirmation first)
-
-### Step 5: Ask About Commit
-Ask user via `AskUserQuestion`:
-- "Stage and commit changes"
-- "Commit and push"
-- "I'll handle it later"
-
-## Output
-
-After archiving, present summary:
-
-```markdown
-## Archive Results
-
-| Spec | Status | Created | Action |
-|---|---|---|---|
-| mobile-app | done | 2026-04-01 | Moved → archive |
-| auth-system | done | 2026-03-28 | Deleted permanently |
-
-**Journal entries written:**
-| Title | Path |
-|---|---|
-| Mobile App Release | docs/journals/2026-04-06-mobile-app.md |
-```
-
-## Notes
-
-- Only archive completed specs — never archive in-progress specs
-- Keep questions focused on genuine decision points
-- Be concise, prioritize efficiency
-- List unresolved questions at the end

package/src/claude/skills/specs/references/ask-user-question-gates.md

@@ -1,70 +0,0 @@
-# AskUserQuestion Gate Matrix
-
-Use this matrix to classify authority before pausing for user input. A workflow
-event, uncertainty, or architecture choice does not by itself justify a question.
-
-## Source Priority
-
-Resolve uncertainty in this order:
-
-1. Existing `spec.json`, `requirements.md`, `research.md`, `design.md`, and task files.
-2. Codebase evidence from targeted scout/inspect.
-3. Official/current external docs when platform/provider behavior matters.
-4. Reasonable default from CafeKit rules.
-5. `AskUserQuestion` only when the remaining decision is user-owned.
-
-Classify first:
-
-- `repository_fact`: investigate and ground it from repository or required
-  current evidence. Do not ask the user to supply a discoverable fact.
-- `reversible_assumption`: choose the simplest engineering option and record its
-  bounded reversal boundary. Do not ask unless the user explicitly requested
-  control of that choice.
-- `user_owned`: HOLD and ASK for a product, scope, security, data, or
-  irreversible decision. Never infer or self-approve it.
-
-Store only actual items in optional `spec.json.decisions`; omit it when absent.
-Every unresolved `user_owned` entry blocks readiness; facts and reversible
-assumptions do not become user questions merely because they are unresolved.
-
-## Gate Matrix
-
-| Class | Example trigger | Action | Record in |
-|---|---|---|---|
-| Repository fact | Existing behavior, path, dependency, API shape, or current constraint | Investigate and ground; if evidence remains unavailable, report the exact grounding blocker without asking the user to guess | design/research anchor |
-| Reversible assumption | Two technically valid internal approaches with bounded rollback | Select the simplest compatible option and record the reversal trigger/boundary | `spec.json.decisions` when material, otherwise design |
-| User-owned decision | Product behavior, scope expansion/reduction, security posture, data handling, or irreversible migration | HOLD and ASK; keep the exact decision unresolved until the user answers | `spec.json.decisions` and affected artifact |
-| Active-target ambiguity | Multiple plausible feature/spec targets | HOLD and ASK because target selection changes scope | `scope_lock` |
-| Validation finding | A factual defect or reversible repair | Ground and repair without approval; ASK only if resolution changes a user-owned decision | affected canonical artifact |
-| Task conflict | Shared files/contracts between parallel candidates | Serialize or merge using the simplest reversible topology | task boundaries |
-
-## Question Format
-
-Every `AskUserQuestion` must:
-
-- Ask 1-3 questions max per pause.
-- Provide 2-3 concrete options.
-- Put recommended option first and suffix label with `(Recommended)`.
-- Explain the tradeoff in one sentence per option.
-- Include an implicit free-form "Other" option when the tool supports it.
-
-## Do Not Ask
-
-Do not ask when:
-
-- The answer is discoverable via repo files, tests, docs, or official/current docs.
-- The choice is pure implementation detail with no scope/user impact.
-- The task can safely use an existing codebase convention.
-- The question exists only to avoid making a normal engineering judgment.
-- Evidence is missing for a `repository_fact`; report the grounding blocker
-  instead of asking the user to guess.
-
-## Recording Rules
-
-After a user answer:
-
-- Update the artifact that drives implementation, not only a report.
-- Keep exact selected option and custom free text when provided.
-- Add unresolved questions at the end of the affected document.
-- HOLD while any `user_owned` decision is unresolved. Do not mark
-  `ready_for_implementation = true` until the user resolves it.

package/src/claude/skills/specs/references/codebase-analysis.md

@@ -1,102 +0,0 @@
-# Codebase Analysis
-
-## Purpose
-
-Understand the current codebase before designing solutions — ensure the new spec aligns with existing architecture, patterns, contracts, tests, and runtime boundaries.
-
-## Skip Conditions
-
-- Already provided with inspector reports → skip, use directly
-- Greenfield artifact that does not integrate with existing code → record skip rationale in `research.md`
-- Internal docs/text-only spec with no runtime behavior → record skip rationale in `research.md`
-
-## Targeted Codebase Scout Gate
-
-Run a targeted scout before requirements when any of these are true:
-
-- The feature modifies existing behavior, UI, API, CLI, data flow, runtime config, hooks, settings, generated artifacts, or package exports.
-- The feature touches database schemas, migrations, auth/session, permissions, external integrations, or shared contracts.
-- The task may break existing tests, snapshots, build scripts, type checks, e2e flows, or docs generation.
-- The spec crosses monorepo boundaries such as source package → installed `.claude/`, library package → docs app, package manifest → publish/install runtime.
-- `Related Files` cannot be named precisely yet.
-- A resumed or validated spec may be stale because files, tests, dependencies, or contracts changed since the spec was created.
-
-The scout must be narrow and question-driven. Do not scan the whole repo just because the repo is available.
-
-## 4 Mandatory Files to Read First
-
-| # | File | Content | Importance |
-|---|---|---|---|
-| 1 | `./docs/development-rules.md` | Development rules, naming conventions, file size management, coding standards | **MANDATORY** |
-| 2 | `./docs/codebase-summary.md` | Architecture overview, project structure, component relationships | High |
-| 3 | `./docs/code-standards.md` | Coding conventions, language-specific patterns | High |
-| 4 | `./docs/design-guidelines.md` | Design system, branding, UI/UX conventions | If exists |
-
-### Validation & Fallback Protocol (MANDATORY)
-1. **Trust but Verify:** If `codebase-summary.md` or `code-standards.md` exists, you MUST verify their technical claims by cross-checking `package.json`, `go.mod`, etc. (e.g., if Docs say Redux but package.json only has Zustand → Flag documentation as STALE in your research).
-2. **The "Blind Flight" Halt:** If ALL 4 mandatory docs are missing in a non-empty repository:
-   - **DO NOT** blindly use `inspector` to scan the whole repo.
-   - **HALT** the spec process immediately.
-   - Ask the User: *"No codebase documentation found. Exploring blind will drain tokens and produce inaccurate specs. Shall I call the `docs-keeper` agent to generate a baseline `codebase-summary.md` first?"*
-
-## Scout Output Contract
-
-Record the concise findings in `research.md`; if inspector agents are used, save detailed output to `reports/inspect-report.md`.
-
-Required output:
-- **Project surface:** project type, package/workspace boundaries, languages, frameworks, and relevant commands.
-- **Relevant files/modules:** exact paths likely to be created, modified, deleted, or read.
-- **Existing patterns:** naming, architecture, state/data flow, error handling, testing, and docs conventions that tasks must follow.
-- **Contracts:** API/CLI/schema/auth/config/runtime/package/export contracts affected by the spec.
-- **Tests and verification:** existing tests/checks likely to pass, fail, or require updates.
-- **Blast radius:** affected modules, consumers, generated artifacts, publish/install paths, and rollback considerations.
-- **Staleness check:** docs or prior specs that conflict with source code or manifests.
-
-## Analysis Activities
-
-### 1. Environment Analysis
-- Review development environment setup
-- Analyze dotenv files and configuration
-- Identify required dependencies
-- Understand build and deployment processes
-
-### 2. Core Data Structures (MANDATORY for Enhancements)
-Before designing any logic, you must identify and read the existing schemas:
-- Tell `inspector` to grep for database schema files (`schema.ts`, `schema.prisma`, entities, migrations).
-- Identify Global State setups (Redux stores, Zustand, React Context).
-- Output the relational impact: How will the new feature alter existing tables or state structures?
-
-### 3. Pattern Recognition
-- Study existing patterns in codebase
-- Identify conventions and architectural decisions
-- Note consistency in implementation approaches
-- Understand error handling patterns
-
-### 4. Integration Planning
-- Identify how new features integrate with existing architecture
-- Map dependencies between components
-- Understand data flow and state management
-- Consider backward compatibility
-
-### 5. Blast Radius & Regression Check
-Write a "Collateral Damage" section in your `research.md`:
-- List EXACTLY which existing files will need to be modified.
-- **Test Invalidation:** Identify which existing `.test.ts` or `.spec.ts` files will break because of these modifications.
-- Ensure the mitigation for these breaking changes is passed downstream to the Task generation phase.
-
-### 6. Inspector Usage (when needed)
-- Use inspector agents for targeted file discovery in large codebases
-- Each inspector targets a specific aspect of the task
-- Wait for all inspectors to report before analysis
-- Save results to `reports/inspect-report.md`
-- If the scout cannot name exact paths/tests after inspection, stop and ask a grounded question instead of generating vague tasks
-
-## Best Practices
-
-- Start with documentation before diving into code
-- Use inspectors for targeted file discovery
-- Document patterns found for consistency
-- Note any inconsistencies or technical debt
-- Consider impact on existing features
-- Use `rg`/targeted search terms or inspector agents before broad traversal
-- Pass exact file and test findings downstream into `design.md` and task `Related Files`

package/src/claude/skills/specs/references/cross-spec-dependency.md

@@ -1,76 +0,0 @@
-# Cross-Spec Dependency Detection
-
-## Purpose
-
-Before creating a new spec, the system must check whether any existing in-progress spec is related — to avoid file conflicts, duplicated work, or breaking something another spec depends on.
-
-## Workflow
-
-### Step 1: Scan
-
-Read `spec.json` in each subdirectory of `specs/`. Filter specs that have any phase in `progress` not yet `done` or `cancelled`.
-
-### Step 2: Compare Scope
-
-For each incomplete spec, compare against the new spec being created:
-
-| Comparison Criteria | Example |
-|---|---|
-| Overlapping code files? | Both specs modify `src/auth/login.ts` |
-| Shared module/dependency? | Both depend on `@auth/core` |
-| Same feature area? | Both belong to "Authentication" module |
-
-### Step 3: Classify Relationship
-
-- **New spec needs results from old spec** → New spec sets `blockedBy: ["<old-spec>"]`
-- **New spec changes something old spec uses** → Old spec sets `blockedBy: ["<new-spec>"]`, new spec sets `blocks: ["<old-spec>"]`
-- **Mutual dependency** → Both reference each other
-
-### Step 4: Bidirectional Update
-
-When a relationship is detected, update `spec.json` of **BOTH** specs:
-
-```json
-// specs/auth-system/spec.json
-{
-  "dependencies": {
-    "blockedBy": [],
-    "blocks": ["user-dashboard"]
-  }
-}
-
-// specs/user-dashboard/spec.json
-{
-  "dependencies": {
-    "blockedBy": ["auth-system"],
-    "blocks": []
-  }
-}
-```
-
-### Step 5: Handle Ambiguity
-
-Treat dependency direction as a `repository_fact`: inspect owned outputs,
-consumers, typed boundaries, and current lifecycle, then ground the edge. Do not
-ask the user to guess a factual graph relationship. If no direction can be
-grounded, leave the edge absent and report the exact grounding blocker.
-
-If choosing which deliverable proceeds first changes user-owned scope, release
-ordering, data handling, or an irreversible commitment, HOLD and ASK for that
-decision; unresolved `user_owned` ordering blocks readiness.
-
-## Blocked State
-
-A spec with `blockedBy` containing a spec not yet `done`:
-- The `progress` field shows current phase as `blocked`
-- When all blocking specs complete → automatically unblock on next scan
-
-## Output Format
-
-```
-Dependency Scan:
-- Found: {N} incomplete specs
-- Related: {M} specs with overlapping scope
-- Updated: specs/{A}/spec.json ↔ specs/{B}/spec.json
-- Status: {A} blocks {B}
-```

package/src/claude/skills/specs/references/research-strategy.md

@@ -1,107 +0,0 @@
-# Research Strategy
-
-## Purpose
-
-Provide tools and methods to gather necessary information before writing requirements and design. The goal is evidence-backed decision-making: use the current codebase and current external knowledge before locking requirements, architecture, and tasks.
-
-## Skip Conditions
-
-- Simple one-file task with no integration point → record skip rationale in `research.md`
-- Internal text/docs-only change → record skip rationale in `research.md`
-- User already provided recent research reports → use directly, but record what was reused
-
-Skipping research does NOT mean skipping the evidence trail. Every non-trivial spec still needs an Evidence Summary in `research.md`.
-
-## Evidence Gate Triggers
-
-### Targeted Codebase Scout — Mandatory When
-
-- The spec changes existing behavior rather than creating an isolated new artifact.
-- The spec touches API routes, CLI commands, package exports, database schemas, migrations, auth/session, permissions, runtime config, hooks, generated artifacts, or settings.
-- Requirements or tasks cannot name exact affected files, modules, tests, or contracts.
-- The change may invalidate existing `.test.*`, `.spec.*`, e2e, build, or integration checks.
-- The spec is being resumed or validated after the codebase may have changed.
-- The work crosses monorepo, package source, installed runtime, docs site, or publish/install boundaries.
-
-### External / Current Research — Mandatory When
-
-- The spec depends on third-party APIs, libraries, SDKs, browser/platform policies, package manager behavior, cloud services, or external protocols.
-- The spec touches security, auth, payment, privacy, delete-data, compliance, performance, accessibility, SEO, or current framework best practices.
-- The spec involves AI providers, model behavior, agent tooling, browser automation, or fast-moving platform constraints.
-- The user asks for "best", "optimal", "latest", "recommended", "current", "modern", or equivalent.
-- Existing internal docs are stale, incomplete, or contradict package manifests/source code.
-
-## 7 Research Tools
-
-| # | Tool | Description | When to Use |
-|---|---|---|---|
-| 1 | **Researcher agents** (max 2) | Spawn in parallel, each investigates a different aspect | Complex tasks, need to explore multiple approaches |
-| 2 | **Sequential thinking** | Step-by-step reasoning, avoids context overload | Multi-step logic analysis, tangled problems |
-| 3 | **Docs seeker** | Look up framework/package docs from official sources | Need to understand external APIs/libraries, find best practices |
-| 4 | **GitHub analysis** (`gh`) | Read action logs, PRs, issues, discussions | Need context from project history, understand past decisions |
-| 5 | **Repomix remote** (`repomix --remote <url>`) | Generate codebase summary from remote repo | Reference how other repos solve similar problems. *(If not installed, use WebFetch as fallback)* |
-| 6 | **Inspector agents** | Search for files across large codebases | Find relevant files faster than grep in large projects |
-| 7 | **Debugger delegation** | Hand off to debugger agent for analysis | Investigate root cause of bugs |
-
-## Workflow
-
-### 1. Classify Evidence Needs
-Before detailing requirements, list unanswered questions:
-- Which technology is most suitable?
-- Is there an existing pattern/library that solves this?
-- How does the current codebase handle similar functionality?
-- Are there technical risks that need verification?
-- What evidence is needed from the repository?
-- What evidence requires current external sources?
-
-### 2. Run Targeted Codebase Scout
-- Read project docs first, then verify claims against source files such as `package.json`, `go.mod`, schemas, routes, tests, and runtime config.
-- Use inspector agents for large codebases or when multiple focused searches are needed.
-- Save scout details to `reports/inspect-report.md` when inspector agents are used.
-- Record the useful summary in `research.md`; do not dump raw search output.
-
-### 3. Run External / Current Research
-- Prefer official documentation, standards, release notes, package repositories, or maintained upstream examples.
-- Use broader web search only when primary sources do not answer the question.
-- Record links and explain why each source matters.
-- If sources conflict, state which source wins and why.
-
-### 4. Pick the Right Tool
-- Framework/API questions → Docs seeker
-- Current codebase questions → Inspector agents
-- Architecture/approach questions → Researcher agents
-- Complex multi-step reasoning → Sequential thinking
-- Historical decision questions → GitHub analysis
-
-### 5. Spawn Researchers (when needed)
-- Max 2 agents running in parallel
-- Each agent gets a specific aspect (e.g., agent 1 researches auth approach, agent 2 researches database schema)
-- Limit each agent to max 5 tool calls
-- Wait for all agents to complete before synthesizing
-
-### 6. Synthesize Decisions
-- Convert raw findings into decisions before writing requirements:
-  - selected approach
-  - rejected alternatives
-  - codebase fit
-  - external/current constraints
-  - downstream task and test implications
-- If evidence leaves multiple viable choices, classify authority: choose the
-  simplest reversible engineering option and record its bounded reversal;
-  HOLD/ASK only for a user-owned product, scope, security, data, or irreversible
-  decision. Missing repository facts remain grounding blockers, not questions.
-
-### 7. Record Findings
-- Write to `research.md` using template `templates/research.md`
-- Save researcher reports to `reports/researcher-{NN}.md`
-- Save inspector reports to `reports/inspect-report.md`
-
-## Best Practices
-
-- Breadth before depth
-- Record findings before synthesizing
-- Identify multiple approaches for comparison
-- Consider edge cases during research
-- Flag security concerns early
-- Do not design from memory when repository or current external evidence can settle the decision
-- Keep external research concise: source, finding, implication, decision

package/src/claude/skills/specs/references/scope-inquiry.md

@@ -1,107 +0,0 @@
-# Scope Inquiry
-
-## Purpose
-
-Before investing time in planning, select the smallest scope consistent with the
-request and evidence. Scope inquiry is an analysis step, not a mandatory user
-question.
-
-## Skip Conditions
-
-Skip Scope Inquiry when:
-- Task is clearly trivial (1 file, typo fix, config change)
-- Description is under 20 words and unambiguous
-- User signals urgency ("just do it", "quick", etc.)
-
-## 5-Dimension Complexity Assessment
-
-Evaluate complexity across **5 dimensions** to avoid blind spots. A task may be architecturally small but extremely risky, or seemingly simple but with a huge blast radius.
-
-### Dimension 1: Semantic Intent & Current State
-- What is the core business or technical meaning of the request?
-- How does the system currently behave in this area? What existing patterns, services, or infrastructure can be leveraged?
-- Would this spec rebuild something that already exists? If yes, warn before proceeding.
-
-### Dimension 2: High-Level Implementation Hypothesis
-- Conceptually, how must the architecture adapt to fulfill the semantic intent?
-- Hypothesize the structural impact: Does this require new database models, API contracts, third-party integrations, or is it strictly localized logic/UI changes?
-
-### Dimension 3: Gap Analysis & Sizing
-Evaluate the gap between Current State and Hypothesis:
-- **Small**: No architectural changes. Extending existing patterns, adding UI components, or patching localized logic.
-- **Medium**: Modifying data flows, adding new API endpoints, or bridging two previously unconnected modules.
-- **Large**: New persistence models, security/auth changes, cross-system migrations, or touching core system foundations.
-- **Scope check**: Separate aspirational goals (nice-to-haves) from what is strictly necessary to bridge the core gap.
-
-### Dimension 4: Risk & Uncertainty (Cynefin-inspired)
-Classify the *knowability* of the solution path:
-- **Clear**: Well-understood problem with established patterns and documentation (e.g., CRUD endpoints, standard auth flows). Proceed with confidence.
-- **Complicated**: Solution exists but requires expert analysis or research (e.g., payment gateway integration, complex query optimization). Plan carefully, may need `researcher` subagent.
-- **Complex**: Outcome is uncertain; solution emerges through experimentation (e.g., AI/ML tuning, novel UX interactions, performance bottleneck with unknown root cause). Requires prototyping or spike tasks before committing to a full spec.
-- **Chaotic**: No clear path; urgent stabilization needed first (e.g., production outage, data corruption). Skip spec workflow entirely — use `hapo:hotfix` instead.
-
-> **Rule**: If Dimension 4 = Complex, record the uncertainty and add a bounded
-> spike only when it is a real dependency. Chaotic tasks exit to `hapo:hotfix`.
-> Ask only when the response requires a user-owned scope or irreversible choice.
-
-### Dimension 5: Dependency & Blast Radius
-Assess how many other parts of the system are affected if this change breaks or behaves unexpectedly:
-- **Isolated**: Change is self-contained within a single module or feature. No shared interfaces touched.
-- **Moderate**: Change touches shared utilities, common components, or API contracts consumed by 2-3 other modules.
-- **Critical Path**: Change affects core infrastructure (auth, data layer, routing, state management) or shared libraries used system-wide. A bug here cascades everywhere.
-
-> **Rule**: If Blast Radius = Critical Path, the spec MUST include rollback strategy and explicit test coverage requirements in the task files.
-
-### Complexity Smell Check (by numbers)
-
-After the qualitative 5-Dimension pass, run a quick quantitative gut-check. These are YAGNI tripwires, not hard limits — when one trips, pause and justify or simplify before locking scope:
-
-- **> 8 files touched** → challenge whether the same goal is reachable with fewer; flag accidental scope creep.
-- **> 2 new classes / services / modules** → smell; justify each new abstraction (could an existing module absorb it?).
-- **> 12 task files** → the spec is large; consider splitting by deliverable boundary into sibling specs (cross-spec `blockedBy`) rather than one mega-spec.
-- **> 15 task files** → strong signal to split. A single mega-spec is slow to generate, prone to mid-run failure, and hard to review. Prefer 2-3 focused specs unless the work is genuinely one indivisible slice.
-
-If a tripwire fires, first reduce or split using the simplest reversible boundary.
-HOLD and ASK only when that change would alter user-owned deliverables or scope.
-Do not silently build the mega-version.
-
-## Level Selection
-
-After the assessment, classify the remaining choice:
-
-- Ground current size, dependencies, and blast radius as `repository_fact`.
-- Choose the smallest `reversible_assumption` and record its bounded reversal.
-- For a `user_owned` Expand/Hold/Reduce/Split decision, HOLD and present via
-  `AskUserQuestion`; unresolved scope blocks readiness.
-
-When a user-owned choice exists, use:
-
-**Title:** "Scope Inquiry"
-**Question:** "Based on analysis, what scope level do you want?"
-
-| Option | Description | Impact |
-|---|---|---|
-| **Expand** | Deep research, explore multiple approaches, add stretch features | More research, stretch requirements, more tasks |
-| **Hold** | Keep scope as described, prioritize quality | Focus on edge cases, test coverage, failure modes |
-| **Reduce** | Core only, defer everything non-essential | Fewer tasks, simpler architecture, defer non-blocking parts |
-
-## Immutable Rule
-
-**Once user picks a level, respect it throughout the entire workflow:**
-- Don't silently shrink when user chose Expand or Hold
-- Don't silently expand when user chose Reduce
-- Raise scope concerns ONCE at this step. Then commit and optimize within the chosen scope.
-
-## Output Format
-
-```
-Scope Inquiry:
-- Semantic Intent: [Core meaning of request]
-- Hypothesis: [High-level architectural adaptation needed]
-- Gap Size: [Small/Medium/Large] — [reason]
-- Risk Level: [Clear/Complicated/Complex/Chaotic] — [reason]
-- Blast Radius: [Isolated/Moderate/Critical Path] — [affected modules]
-- Complexity smells: [none | >8 files | >2 new services | >12 tasks → consider split | >15 tasks → split]
-- Minimum Change: [Essential gap vs Niceties]
-- Decision: [grounded fact | reversible default + reversal boundary | user choice]
-```

package/src/claude/skills/specs/references/translation-mirror.md

@@ -1,83 +0,0 @@
-# Translation Mirror
-
-Optional, reference-only duplicate of a spec in the user's configured language. The English spec is always the canonical source of truth; the mirror exists only for human cross-reading.
-
-## When To Offer
-
-1. Read the configured language from `.claude/settings.json` → `language` (a freeform label written at install time, e.g. `Tiếng Việt`, `日本語`, `Korean`, `English`).
-2. If the label resolves to English (`English` / `en`) → **do not** offer a mirror; there is nothing to duplicate.
-3. If it is any other language AND the run is interactive (no `--auto`) → ask once via `AskUserQuestion`:
-   - "Generate a `<language>` reference copy of this spec? (kept in sync, read-only)" → `Yes` / `No`.
-4. `--auto` runs are non-interactive → **skip** the offer (an `--auto` create makes no mirror). If `translation.enabled` is already `true` from an earlier run, always-sync still applies during an `--auto` resume.
-5. Persist the choice in `spec.json.translation` (see Fields).
-
-## Language Code
-
-Map the freeform label to a short folder code:
-
-| Label | Code |
-|---|---|
-| Tiếng Việt | `vi` |
-| 日本語 / Japanese | `ja` |
-| 한국어 / Korean | `ko` |
-| 中文 / Chinese | `zh` |
-| Français / French | `fr` |
-| (anything else) | kebab-case slug of the label |
-
-## Layout
-
-The mirror lives under the spec, never replacing canonical files:
-
-```
-specs/<feature>/
-├── spec.json              # canonical state — NOT mirrored
-├── requirements.md        # English canonical
-├── design.md
-├── research.md
-├── tasks/task-R*.md
-└── i18n/<code>/           # mirror (reference only)
-    ├── requirements.md
-    ├── design.md
-    ├── research.md
-    └── tasks/task-R*.md
-```
-
-- Mirror **only** the human-readable docs: `requirements.md`, `design.md`, `research.md`, and every `tasks/task-*.md`.
-- Do **not** mirror `spec.json` (machine state is language-agnostic and lives only at the root).
-- Keep file names and the `tasks/` substructure identical to canonical so they line up 1:1.
-
-## Mirror File Marker
-
-Every generated mirror file MUST begin with this HTML comment so no one mistakes it for a source:
-
-```
-<!-- TRANSLATION MIRROR — generated from English canonical. Reference only. Do not edit; regenerated on sync. -->
-```
-
-EARS trigger keywords and fixed phrases stay in English even inside the mirror (`When`, `If`, `While`, `Where`, `The system shall`); only the variable parts are translated — same rule as `rules/ears-format.md`.
-
-## Always-Sync
-
-`spec.json.translation.sync` is `always`:
-
-- Whenever a canonical doc is written or updated (Step 5 requirements/research, Step 6 design, Step 7 tasks, or any later edit), regenerate the matching mirror file from the new canonical content.
-- After regenerating, set `spec.json.translation.last_synced_at` to the current time.
-- If a canonical task file is added/removed, add/remove the matching mirror file so the two trees stay 1:1.
-
-## Not A Source Of Truth
-
-- The deterministic validator (`validate-spec-output.cjs`) runs on **canonical only**. The `i18n/` tree is never validated and never blocks `ready_for_implementation`.
-- `task_files` and `task_registry` reference canonical paths only.
-- `hapo:develop` implements from canonical English; it must ignore `i18n/`.
-- If the mirror and canonical ever disagree, canonical wins; re-sync the mirror.
-
-## Fields (`spec.json.translation`)
-
-| Field | Meaning |
-|---|---|
-| `enabled` | `true` once the user opts in |
-| `language` | freeform label from settings (e.g. `Tiếng Việt`) |
-| `language_code` | folder code (e.g. `vi`) |
-| `dir` | relative mirror dir (e.g. `i18n/vi`) |
-| `sync` | `always` |
-| `last_synced_at` | ISO 8601 timestamp of the last regeneration |