abelworkflow 0.9.2 → 1.0.0

package/lib/templates/codex/agents/explorer.toml

@@ -20,6 +20,13 @@ developer_instructions = """
 Your only job is to map. You produce a structured evidence report that the
 orchestrator or a worker agent uses to plan safe changes.
 
+## Development Context
+
+Development context: work is currently in the development phase, and this is a development repository.
+Do not retain runtime user state in the repository or shipped artifacts, and do not preserve compatibility layers for unreleased behavior.
+Prefer deleting obsolete code paths; keep code and prompts concise and avoid over-engineering.
+This context does not by itself authorize destructive changes to user files or credentials outside the repository.
+
 ## Rules
 
 - Do not edit any file, ever.

package/lib/templates/codex/agents/planner.toml

@@ -25,6 +25,13 @@ safely, not like someone writing a design essay.
 Your job is to turn an implementation request into an execution-ready plan
 that minimizes ambiguity, unnecessary searching, and accidental scope growth.
 
+## Development Context
+
+Development context: work is currently in the development phase, and this is a development repository.
+Do not retain runtime user state in the repository or shipped artifacts, and do not preserve compatibility layers for unreleased behavior.
+Prefer deleting obsolete code paths; keep code and prompts concise and avoid over-engineering.
+This context does not by itself authorize destructive changes to user files or credentials outside the repository.
+
 ## Priorities (in order)
 
 1. Scope clarity — what is actually being changed and what is not

package/lib/templates/codex/agents/reviewer.toml

@@ -20,6 +20,13 @@ developer_instructions = """
 Review code like an owner who will be on-call for what ships.
 Your job is to find real problems, not to demonstrate thoroughness.
 
+## Development Context
+
+Development context: work is currently in the development phase, and this is a development repository.
+Do not retain runtime user state in the repository or shipped artifacts, and do not preserve compatibility layers for unreleased behavior.
+Prefer deleting obsolete code paths; keep code and prompts concise and avoid over-engineering.
+This context does not by itself authorize destructive changes to user files or credentials outside the repository.
+
 
 ## Priorities (in order)
 

package/lib/templates/codex/agents/worker.toml

@@ -18,6 +18,13 @@ developer_instructions = """
 You are a local implementation sub-agent. Execute bounded tasks with
 precision and minimal footprint. You are not alone in the codebase.
 
+## Development Context
+
+Development context: work is currently in the development phase, and this is a development repository.
+Do not retain runtime user state in the repository or shipped artifacts, and do not preserve compatibility layers for unreleased behavior.
+Prefer deleting obsolete code paths; keep code and prompts concise and avoid over-engineering.
+This context does not by itself authorize destructive changes to user files or credentials outside the repository.
+
 ## Boundaries
 
 - Work only within the file set and module boundary authorized by the

package/lib/templates/codex/config-base.toml

@@ -12,10 +12,17 @@ developer_instructions = """
 Act as the default orchestrator for specialized subagents.
 
 This is a fallback orchestration policy, not the primary workflow definition.
-If an active custom command or workflow prompt is present (for example `/oc:*`),
+If an active custom command or workflow prompt is present (for example `/abel-*`),
 its phase rules, guardrails, write scope, tool requirements, and stop/go gates
 take precedence over the default routing below.
 
+## Development Context
+
+Development context: work is currently in the development phase, and this is a development repository.
+Do not retain runtime user state in the repository or shipped artifacts, and do not preserve compatibility layers for unreleased behavior.
+Prefer deleting obsolete code paths; keep code and prompts concise and avoid over-engineering.
+This context does not by itself authorize destructive changes to user files or credentials outside the repository.
+
 ## Global Precedence
 
 - Active workflow or command instructions override default orchestration
@@ -42,8 +49,8 @@ take precedence over the default routing below.
 - During research or discovery phases, do not dispatch implementation workers.
 - During planning phases, do not generate or apply code changes.
 - During implementation or diagnose phases, respect command-specific
-  requirements such as TDD, confidence gates, verification order, and patch or
-  report format.
+  requirements such as TDD, root-cause verification, verification order, and
+  patch or report format.
 - Respect command-specific write boundaries and required tools.
 - If the active workflow requires explicit user confirmation before advancing
   to the next phase, do not advance automatically.
@@ -55,6 +62,7 @@ take precedence over the default routing below.
 - Prefer parallel subagents only when they do not violate workflow ordering or
   gates.
 - Assign concrete ownership with explicit scope and disjoint write sets.
+- Copy this development context into every subagent task.
 - Do not duplicate work across agents. Avoid overlapping exploration,
   planning, implementation, or review tasks.
 - Do not hand off blocked or underspecified work without enough context for

package/lib/templates/workflow/AGENTS.md

@@ -0,0 +1,50 @@
+# Configuration
+
+## Language
+
+- Tool/model interactions: **English**
+- User-facing output: **Chinese**
+
+## Code Style
+
+- Concise, efficient, no redundancy
+- Minimal comments/docs (only when necessary)
+- Targeted changes only; never touch unrelated functionality
+
+## Development Context
+
+Development context: work is currently in the development phase, and this is a development repository.
+Do not retain runtime user state in the repository or shipped artifacts, and do not preserve compatibility layers for unreleased behavior.
+Prefer deleting obsolete code paths; keep code and prompts concise and avoid over-engineering.
+This context does not by itself authorize destructive changes to user files or credentials outside the repository.
+
+## Context Rules
+
+- Use local codebase retrieval with `rg`, `rg --files`, `git grep`, and direct file reads.
+- Rely only on project code plus `grok/context7` results
+- If information is insufficient or uncertain, state it explicitly
+
+## Workflow
+
+```
+/abel-init → /abel-design → /abel-implement(TDD)
+                           ↘ /abel-diagnose (bug fix)
+```
+
+## Universal Constraints
+
+1. Use `unified diff patch` format for proposed/applied changes
+2. Before applying changes, state assumptions and unknowns explicitly; stop and ask the user on any critical unknown
+
+## Stage Skill Matrix
+
+| Skill | Design | Implement | Diagnose | Capability & Triggers |
+| --- | :---: | :---: | :---: | --- |
+| /grok-search | ✅ | ❌ | ✅ | Deep research, concept understanding. Trigger: architectural patterns, best practices |
+| /context7-auto-research | ✅ | ✅ | ✅ | Official docs retrieval. Trigger: framework/library usage, APIs |
+| /dev-browser | ○ | ✅ | ✅ | Browser automation. Trigger: E2E testing, UI verification |
+| /time | ○ | ✅ | ○ | Time/timezone operations. Trigger: scheduling logic |
+
+Legend: ✅ Primary, ○ Optional, ❌ Forbidden
+
+OpenSpec commands: `/opsx:propose` `/opsx:explore` `/opsx:apply` `/opsx:update` `/opsx:sync` `/opsx:archive` `openspec view` `openspec status`

package/lib/templates/workflow/commands/abel-design.md

@@ -0,0 +1,175 @@
+---
+name: abel-design
+description: Transform requirements into implementation-ready, traceable specs via gated clarification.
+category: abel
+tags: [abel, design, constraints, PBT, subagents]
+argument-hint: [requirement | --change <change_name>]
+---
+
+<!-- ABEL:START -->
+
+# abel-design — Gated Design Mode (Specs Only, No Implementation)
+
+## Non-Negotiable Rules (Highest Priority)
+1. DESIGN MODE ONLY — you MUST NOT generate implementation code.
+2. WRITE SCOPE:
+   - Before Gate A: strictly read-only; persist nothing.
+   - After Gate A: write ONLY inside the resolved `changeRoot`. Create only ready artifacts; edit a done artifact only when an approved loop-back/consistency repair explicitly targets it.
+3. NEVER assume or guess — every blocking decision goes to the user (see Decision Model).
+4. Final output: a schema-valid, fully traceable OpenSpec change with BLOCKING_DECISIONS = 0, READY_TO_IMPLEMENT.
+
+**Skill Integration**: See `Stage Skill Matrix` (Design column)
+
+---
+
+## Decision Model
+- Maintain an in-session Decision Ledger with: `id`, `class`, `question`, `evidence`, `options`, `recommendation`, `resolution`, `status`, `affected_artifacts`.
+- `BLOCKING_DECISIONS` is the count of unresolved, non-mechanical decisions in that ledger.
+- Behavior decisions answer WHAT: observable outcomes, scope/non-goals, scenarios, failure behavior, data/security/privacy/compatibility policies and success criteria.
+- Technical decisions answer HOW: interfaces, data flow, dependencies, storage/algorithms, implementation error mechanisms and key technical parameters.
+- MUST be approved by the user: goal, scope, non-goals and observable success behavior; data, security, privacy, compatibility and migration rules; new dependencies, cross-module architecture, irreversible changes; any technical choice with substantive trade-offs, including key parameters.
+- MAY be decided mechanically by the agent: naming, file locations and local structure uniquely determined by existing repo conventions; easily reversible details with no external behavior change; test placement and execution order derived directly from the approved design.
+- Record mechanical decisions and never re-ask them. Two or more viable options with substantive differences → escalate to a blocking decision.
+- Do NOT create a runtime ledger or approval-state file. Materialize approved decisions only in schema artifacts.
+
+## Phase 0 — Entry, Mode & Readiness (read-only)
+- Verify an initialized OpenSpec root and the required CLI capabilities: `new change`, `list --json`, `schemas --json`, `schema which --json`, `schema validate --json`, `templates --json`, `status --json`, `instructions --json`, and `validate --strict`. If unavailable, STOP with actionable `/abel-init` remediation; do not initialize or update from this command.
+- Resolve mode:
+  - Explicit `--change <name>` → Resume. If that change does not exist, STOP and ask the user to correct the name or choose New mode.
+  - Otherwise, an exact existing-change match → Resume.
+  - Otherwise → New mode; do not silently interpret an explicit/resume-like typo as a requirement.
+- Resolve the effective schema by precedence: explicit schema choice, existing change metadata, project config, then `spec-driven`; verify it appears in `openspec schemas --json`.
+- Before creating a change, run `openspec schema which <schema> --json` and `openspec schema validate <schema> --json`, inspect its definition and `openspec templates --schema <schema> --json`, and perform a preliminary behavior/technical/mixed dependency check. Implementation compatibility also requires a non-empty concrete `apply.tracks` that matches exactly one artifact's `generates`. An incompatible schema must fail closed before creation.
+- New mode minimum intake before ANY exploration:
+  - Problem/goal statement, AND
+  - Scope anchor (which module/directory is involved).
+- If either intake item is missing, ask the user concisely before proceeding.
+- Generate a provisional kebab-case change name and check `openspec list --changes --json`. Recompute and confirm it from the final Gate A scope before creation. Persist nothing yet.
+
+## Phase 1 — Evidence Exploration (read-only)
+- Use local codebase retrieval with `rg`, `rg --files`, `git grep`, and direct file reads.
+- Single context boundary → main agent explores directly.
+- Multiple independent context boundaries, when the platform permits → dispatch parallel Explore subagents:
+  - Divide by context boundary (NOT functional role); each boundary self-contained.
+  - Each subagent receives: mandatory use of the codebase retrieval policy, a clear scope, and the mandatory JSON output schema:
+{
+  "module_name": "所探索的上下文边界",
+  "existing_structures": ["关键结构/模式"],
+  "existing_conventions": ["约定/标准"],
+  "constraints_discovered": ["硬约束"],
+  "open_questions": ["需用户输入的歧义"],
+  "dependencies": ["跨模块依赖"],
+  "risks": ["风险/阻碍"],
+  "success_criteria_hints": ["可观察的成功行为"]
+}
+- Validate every subagent JSON before aggregation; aggregate constraints, dependencies, risks, conflicts and questions into the Decision Ledger.
+- Audit existing codebase patterns:
+  Use `rg`, `rg --files`, `git grep`, and direct file reads to validate against existing codebase patterns.
+- On-demand /context7-auto-research: verify candidate libraries/APIs against official contracts.
+- On-demand /grok-search: architectural patterns and best practices for candidate directions.
+- PBT boundary screening: probe empty input, idempotency, ordering, size/value bounds, state-transition legality → feed the question list for Phase 2.
+- Reference: Inspect codebase structure with `rg --files`, `git grep`, and direct file reads.
+
+## Phase 2 — Behavior Clarification Loop (multiple rounds allowed)
+- Cover WHAT only: goal, scope, non-goals, observable scenarios/success criteria, failure behavior, and data/security/privacy/compatibility policies.
+- Do not choose libraries, protocols, algorithms, storage, topology or implementation parameters in this phase; route them to Phase 4.
+- Each round asks ONLY the current highest-impact blocking questions, grouped concisely, each with evidence, impact and a recommended default.
+- Anti-patterns (flag and reject):
+  - Observable behavior deferred to implementation ("error behavior decided while coding")
+  - Technical mechanisms smuggled in as product requirements
+- Target behavior patterns:
+  - "Lock the account for 30 minutes after 5 consecutive failed logins."
+  - "Retain audit records for 30 days and never expose secrets in responses."
+  - "For an empty query, return an empty result within the approved latency bound."
+- An answer that widens modules, scenarios or data boundaries → return to Phase 1 for INCREMENTAL exploration only.
+- Loop until unresolved behavior decisions = 0.
+
+## ⛔ Gate A — Approve Behavior Contract
+- Present the behavior contract and affected Decision Ledger entries; the user explicitly approves goal, scope/non-goals, scenarios/success criteria and policies.
+- Recompute the change name from the approved scope and recheck duplicates.
+- New mode: ONLY NOW create the change with `openspec new change <change-name>` (add `--schema <schema>` only for an explicit non-default choice).
+- Build the Artifact Plan, then materialize only behavior-class artifacts that are safe and ready.
+
+## Artifact Plan & Write Protocol
+- Before New-mode creation, build a preliminary compatibility map from the resolved schema definition/templates. After creation or in Resume mode, build the final Artifact Plan from `status --json` and available `instructions --json`. Record the schema's `apply.tracks`; for every artifact record capture id/output paths, dependencies/status, substantive decision class (`behavior|technical|mixed`), write Gate, and affected decisions. Mechanical impact information alone does not make an artifact mixed.
+- Classify by the decisions the artifact carries, never by a hardcoded artifact name:
+  - behavior → Gate A
+  - technical or mixed → Gate B
+  - behavior depending on a Gate B artifact → defer until after Gate B and then follow the DAG
+- If the schema requires a write before Gate A, a write outside `changeRoot`, or an unapproved technical decision to unlock behavior, STOP before New-mode creation and ask the user to select a compatible schema/mapping. Schema order never overrides decision approval.
+- Mandatory loop for EVERY artifact write:
+  1. Run `openspec status --change <change-name> --json`; verify `schemaName`, `changeRoot`, `artifactPaths`, status/dependencies and `applyRequires`. `existingOutputPaths` may be empty and is not a new-file target.
+  2. Run `openspec instructions <artifact-id> --change <change-name> --json`; follow its template/rules/dependencies.
+  3. Read dependencies and existing outputs; check consistency in both directions.
+  4. Prepare content in memory and show the decision summary or unified diff before the corresponding Gate. If materialization reveals a new substantive decision, return to the relevant loop and re-approve it.
+  5. After Gate approval, create exactly one ready artifact, or edit one done artifact explicitly targeted by an approved loop-back/consistency repair. Rerun status after every write and process newly unlocked artifacts topologically.
+
+## Phase 3 — Technical Derivation
+- Derive the technical design from the Gate A contract, existing codebase patterns and official API contracts.
+- Mechanical decisions → record directly in the design. Substantive trade-offs → Phase 4.
+
+## Phase 4 — Technical Decision & Verification Loop
+- Cover HOW: interfaces, data flow, implementation error mechanisms, dependencies/algorithms and key parameters. Examples include JWT vs session design and an approved bcrypt cost factor.
+- Apply the same evidence/options/recommendation format to every substantive technical decision; update the Decision Ledger.
+- PBT applicability rule (screen with the six categories: commutativity/associativity, idempotency, round-trip, invariant preservation, monotonicity, bounds):
+  - Behavior with invariants, round-trips, idempotency, ordering, bounds or state transitions → MUST extract a property + falsification strategy.
+  - Behavior unsuited to PBT → use example/E2E/static verification and record why PBT does not apply. Do NOT force every requirement through every category.
+- Give every scenario a stable reference: `<spec-path>#<requirement-heading>/<scenario-heading>` and require those headings to be unique within the spec; maintain Requirement → Scenario → Verification → Task.
+- Every task has exactly one schema checkbox and a verification contract using ordinary indented bullets, NEVER nested `- [ ]`/`- [x]` lines:
+  - Task ID / dependencies
+  - Requirement + stable Scenario reference
+  - Verification type: property | example | E2E | static
+  - Red command + expected failure reason
+  - Green expected behavior
+  - Affected-suite verification command
+  - Target scope/files
+- For a non-behavior-change task, the Red command is a pre-change executable static verification. Manual-only verification is not implementation-ready and MUST NOT pass Gate B or Exit; reshape the task until it has executable property/example/E2E/static verification.
+- Loop until unresolved technical decisions = 0; prepare proposed remaining artifact contents/unified diffs in memory.
+
+## ⛔ Gate B — Approve Implementation Contract
+- Verify Phase 3/4 faithfully expand the Gate A contract; no unapproved new decisions introduced.
+- Present substantive technical decisions, task/verification mapping and artifact materialization preview.
+- The user explicitly approves that implementation contract.
+- Write the remaining ready artifacts one at a time per the Artifact Plan & Write Protocol.
+
+## Loop-Back Rules
+- A user answer widens modules, scenarios or data boundaries → return to Phase 1.
+- Technical analysis overturns the behavior contract → return to Phase 2; re-approve ONLY the affected decisions and synchronize all affected artifacts.
+- Gate B finds the materialization unfaithful → return to Phase 3/4; unaffected Gate A decisions remain approved.
+- Strict validation, verification-contract or traceability failure → return to the earliest phase that introduced the inconsistency.
+- Never hide a late-discovered blocking question.
+
+## Resume Rules
+- Never infer user approval from artifact existence: `status` reporting `done` proves file completion only, not Gate approval.
+- Never resume by fixed file names or file existence alone; the active schema decides.
+- Algorithm:
+  1. Run `openspec status --change <change-name> --json`.
+  2. Use its `schemaName`, `changeRoot`, `artifactPaths` and statuses; read all `existingOutputPaths` and dependencies.
+  3. Check `openspec validate <change-name> --strict --type change`, template completeness, cross-artifact consistency, traceability and verification contracts.
+  4. Rebuild Gate A/B summaries and the Artifact Plan. Re-confirm every Gate approval that cannot be proven in the current conversation.
+  5. Choose the next step:
+     - Explicit Resume change not found (`change_error`) → STOP for spelling/New-mode confirmation; never create silently.
+     - Artifacts incomplete → repair/confirm the nearest safe Gate, then handle the artifacts the schema reports ready.
+     - Artifacts complete but validation/traceability fails → earliest inconsistent phase.
+     - Every artifact id listed in `applyRequires` is `done` → re-confirm any unproven Gate, then run the Exit audit.
+     - Only in-session, un-persisted analysis exists → no mid-loop resume; re-run the read-only analysis.
+- Do NOT create runtime approval-state files; re-confirming the Gate summary IS the resume mechanism.
+
+## Exit Criteria
+- [ ] `openspec validate <change-name> --strict --type change` returns zero issues
+- [ ] Every artifact id in `applyRequires` has status `done`
+- [ ] Schema `apply.tracks` resolves to the generated task artifact inside `changeRoot`
+- [ ] Artifacts are consistent and traceable; every task has a valid verification contract
+- [ ] Every task has executable property/example/E2E/static verification; no task is manual-only
+- [ ] BLOCKING_DECISIONS = 0
+- [ ] User has explicitly approved the reconstructed/current Gate A and Gate B summaries in this conversation
+- [ ] Status: READY_TO_IMPLEMENT
+
+## Reference
+- `openspec context --json` / `openspec schemas --json`
+- `openspec view` / `openspec list --changes --json` / `openspec list --specs` (conflicts with existing specs)
+- `openspec status --change <change-name> --json` / `openspec instructions <artifact-id> --change <change-name> --json`
+- `openspec new change <change-name>` (Gate A only)
+- `openspec show <change-name> --json --deltas-only` when validation fails
+- `rg -n "Constraint:|MUST|MUST NOT|INVARIANT:|PROPERTY:" openspec/` before defining new ones
+<!-- ABEL:END -->

package/{commands → lib/templates/workflow/commands}/abel-diagnose.md

@@ -12,7 +12,7 @@ argument-hint: <problem-description>
 **Guardrails**
 - Root cause first; never fix symptoms only
 - Verify root cause hypothesis with evidence before fix
-- Confidence gate: ≥90% before applying fixes
+- Only fixes with evidence-verified root cause may be applied
 - Every fix must include a regression test
 - Keep changes minimal and scoped
 - If verification fails, rollback and iterate
@@ -32,9 +32,9 @@ argument-hint: <problem-description>
 **Steps**
 1. Parse input, infer scope, and split into issue list (single or multiple).
 2. For each issue in parallel: collect logs/traces and locate code via the configured codebase retrieval policy.
-3. For each issue in parallel: perform root cause analysis; use `/sequential-think` for multi-component chains.
+3. For each issue in parallel: perform root cause analysis; for multi-component chains, decompose the failure chain step by step with evidence.
 4. Build dependency/conflict graph across issues and compute safe fix order.
-5. Run `/confidence-check` per issue; only issues with score ≥90% can move to fix generation.
+5. Verify each issue's root cause against collected evidence; only issues with a verified root cause can move to fix generation.
 6. Spawn one subagent per READY issue to generate `unified diff patch` and regression test with minimal scoped context.
 7. Main agent reviews/merges subagent outputs by dependency order and outputs one batch report with all issue statuses and patches.
 8. Apply merged patches strictly sequentially by dependency order.
@@ -42,13 +42,13 @@ argument-hint: <problem-description>
 
 **Batch Output**
 ```text
-## /oc:diagnose Batch Report
+## /abel-diagnose Batch Report
 
 ### Batch Summary
 Total: {n} | ReadyToFix: {n_ready} | Blocked: {n_blocked}
 
 ### Issue Results
-- [{id}] Classification: {category}/{severity} | Root Cause: {summary} | Confidence: {score} | Subagent: {agent_id|none} | Status: {READY|BLOCKED}
+- [{id}] Classification: {category}/{severity} | Root Cause: {summary} | Verified: {yes|no} | Subagent: {agent_id|none} | Status: {READY|BLOCKED}
 
 ### Patch Queue (dependency order)
 1. [{id}] [subagent:{agent_id}] {file_list}

package/lib/templates/workflow/commands/abel-implement.md

@@ -0,0 +1,170 @@
+---
+name: abel-implement
+description: Implement approved changes with mandatory TDD.
+category: abel
+tags: [abel, implementation, TDD]
+argument-hint: [change_name]
+---
+
+<!-- ABEL:START -->
+**Arguments**
+- Requested: `<change_name>`
+
+**Guardrails**
+
+- Keep changes tightly scoped to the requested outcome; enforce side-effect review before applying any modification.
+- Minimize documentation—avoid unnecessary comments; prefer self-explanatory code.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) for additional OpenSpec conventions or clarifications.
+
+**TDD Guardrails (mandatory)**
+- **Red Phase**: Create or execute the task's failing executable verification ONLY; implementation code is FORBIDDEN.
+- **Green Phase**: Write MINIMAL code to satisfy the verification; over-engineering is FORBIDDEN.
+- **Refactor Phase**: Optimize code quality while keeping target and affected verification green and introducing no new full-suite failures.
+- **Mandatory**: Run the task's executable verification after EVERY code change; never skip verification.
+- **Test-First**: Each task MUST have a failing executable verification before implementation begins.
+
+**Skill Integration**: See `Stage Skill Matrix` (Implement column)
+
+**Readiness Preflight (before any code or test write)**
+
+1. Explicit argument takes precedence. Resolve it directly; ask only when the argument is missing or cannot be resolved uniquely. Never require unconditional `openspec view` confirmation.
+2. Run `openspec status --change <change-name> --json`; read `schemaName`, `changeRoot`, `artifactPaths`, `applyRequires`, and `artifacts`.
+3. Run `openspec schema which <schemaName> --json`, read the resolved `schema.yaml`, and extract `apply.tracks`. Resolve `apply.tracks` relative to `changeRoot`; it must name one concrete existing regular file inside `changeRoot`. Missing, null, non-concrete, or escaping paths fail closed; do not infer the tracking path from apply-instruction `contextFiles` or `tasks`.
+4. Every artifact id in `applyRequires` must have status `done`; array presence or a general completion flag is insufficient.
+5. Run `openspec validate <change-name> --strict --type change`; require zero issues.
+6. Read every planning artifact reported by `artifactPaths`, then run `openspec instructions apply --change <change-name> --json` and follow the returned apply contract.
+7. Verify stable Requirement and Scenario references, the Requirement → Scenario → Verification → Task chain, and every task verification contract. Rebuild the Gate A and Gate B summaries; if approval cannot be proven in the current conversation, show the summaries and require explicit user confirmation.
+8. Run and record affected baseline tests and the full test suite before any write. Record each command, exit status, and normalized failure identities/reasons. Keep existing failures from the full suite separate from the target Red; an existing failure never counts as Red.
+9. If any preflight item fails, STOP and return `/abel-design --change <change-name>`. Do not invent or repair product, behavior, or architecture decisions here.
+
+**Tool Routing**:
+- **TDD Cycle**: Autonomous refactoring
+- **Final Review** (after all tasks):
+  - Backend refactor (subagents)
+  - Frontend refactor (subagents)
+- **E2E tasks** → `/dev-browser`
+
+After preflight, detect the project's verification tooling and work through the tracked tasks sequentially.
+
+**TDD Cycle (per task)**
+
+Consume these ordinary indented bullets from the task verification contract, never Markdown checkboxes:
+- verification type: property | example | E2E | static
+- Red command and expected failure reason
+- Green expected behavior
+- affected-suite command
+- target scope/files
+
+- Red must fail because of the target defect described by the contract.
+- If the failure reason differs or the command is invalid, STOP and return `/abel-design --change <change-name>`; do not improvise a replacement contract.
+- A non-behavior-change task starts with its specified failing executable static verification.
+- A manual-only task is not implementation-ready; STOP and return `/abel-design --change <change-name>`.
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ Step 1: 🔴 Red Phase - Execute Contract Verification    │
+│   ├─ Use the contract's verification type and scope     │
+│   ├─ Generate the required failing verification via     │
+│   │   PROMPT: "Generate failing verification for: {task}│
+│   │            Context: {code_context}                  │
+│   │            Output: unified diff patch               │
+│   │            FORBIDDEN: implementation code"          │
+│   ├─ Apply verification code (after review)             │
+│   ├─ Run Red command → MUST FAIL for expected reason    │
+│   └─ If it passes or fails differently → STOP           │
+├─────────────────────────────────────────────────────────┤
+│ Step 2: 🟢 Green Phase - Minimal Implementation         │
+│   ├─ Generate minimal implementation                    │
+│   │   PROMPT: "Generate minimal code for verification:  │
+│   │            Verification: {verification_context}     │
+│   │            Context: {code_context}                  │
+│   │            Output: unified diff patch               │
+│   │            FORBIDDEN: over-engineering"             │
+│   ├─ Apply implementation (after review & rewrite)      │
+│   ├─ Run Red command → MUST PASS                        │
+│   └─ If fails → analyze error, fix, retry               │
+├─────────────────────────────────────────────────────────┤
+│ Step 3: 🔵 Refactor Phase                               │
+│   ├─ Analyzes code quality                              │
+│   ├─ Apply standard refactoring techniques:             │
+│   │   ├─ Eliminate code duplication                     │
+│   │   ├─ Improve naming and structure                   │
+│   │   ├─ Enhance readability                            │
+│   │   └─ Simplify logic where possible                  │
+│   ├─ Apply refactoring changes                          │
+│   ├─ Run affected-suite command → MUST STILL PASS       │
+│   └─ If fails → rollback refactoring                    │
+└─────────────────────────────────────────────────────────┘
+```
+
+Before applying any change, perform mandatory side-effect review.
+
+After a task's TDD cycle completes, locate the task ID's checkbox in the concrete tracking file resolved from schema `apply.tracks`; require exactly one match and update only it. Zero or multiple matches must STOP and return `/abel-design --change <change-name>`. Never hardcode an artifact filename or infer the tracking path from apply instructions.
+
+**Final Review & Refactor** (after all tasks complete)
+
+1. Require all target tests to be green, then run the affected suites.
+2. Re-run the same full-suite command (the full test suite), compare normalized failure identities with the recorded full-suite baseline, and require no new failures.
+
+3. Execute global code review via subagents:
+
+4. Wait for background tasks to complete; review diff patches.
+5. Rewrite patches into production-grade code (per rewriting principle).
+6. Apply refactoring changes.
+7. Re-run target, affected, and full-suite verification against the baseline.
+8. If a target test fails or the full suite has a new failure, analyze the root cause and fix or roll back.
+9. Perform final side-effect review.
+10. Report that the change is ready for archive; do not archive until the user explicitly authorizes `/opsx:archive`.
+
+**TDD Output Format**
+
+```
+## /abel-implement (TDD Mode)
+
+### Task 1/N: {task_description}
+
+🔴 Red Phase
+├─ Type: {verification_type}
+├─ Generated: {verification_files_or_none}
+├─ Run: {red_command}
+└─ Result: failed for {expected_failure_reason} ✓
+
+🟢 Green Phase
+├─ Generated: {implementation_files}
+├─ Run: {red_command}
+└─ Result: {green_expected_behavior} ✓
+
+🔵 Refactor Phase (Agent autonomous)
+├─ Optimized: {description}
+├─ Run: {affected_suite_command}
+└─ Result: target verification green ✓
+
+✓ Task complete → Next task
+
+---
+
+### All Tasks Complete
+
+🔍 Final Review & Refactor
+
+Backend Review
+├─ Files: {backend_files}
+├─ Status: Running in background...
+└─ Task ID: {task_id}
+
+Frontend Review
+├─ Files: {frontend_files}
+├─ Status: Running in background...
+└─ Task ID: {task_id}
+
+[Waiting for completion...]
+
+✓ Reviews complete
+├─ Applied: {refactoring_summary}
+├─ Target tests: green ✓
+├─ Full suite: no failures beyond baseline ✓
+└─ Ready for user-authorized archive
+
+✓ Implementation complete
+```
+<!-- ABEL:END -->

package/{commands → lib/templates/workflow/commands}/abel-init.md

@@ -16,12 +16,10 @@ tags: [openspec, init, setup]
 2. Verify `openspec` availability via `openspec --version`.
 3. If missing, `npm install -g @fission-ai/openspec@latest`, then re-check version.
 4. Run `openspec init` (or `openspec update` for existing projects).
-5. {{AUGMENT_CONTEXT_ENGINE_VALIDATION}}
-6. Verify required skills:
-   - Skills: `/dev-browser` `/sequential-think` `/context7-auto-research` `/grok-search` `/confidence-check`
-7. Output summary with ✓/✗:
+5. Verify required skills:
+   - Skills: `/dev-browser` `/context7-auto-research` `/grok-search`
+6. Output summary with ✓/✗:
    - OpenSpec installation
    - Project initialization
-   - MCP availability if enabled
    - Required skills availability
 <!-- ABEL:END -->

package/{.gitignore → lib/templates/workflow/gitignore.template}

@@ -14,5 +14,3 @@ skills/dev-browser/.cache/
 .claude/
 .codex/
 *pycache*/
-openspec/
-package-lock.json