abelworkflow 1.0.0-rc.1 → 1.0.0

package/lib/templates/workflow/AGENTS.md

@@ -20,15 +20,15 @@ This context does not by itself authorize destructive changes to user files or c
 
 ## Context Rules
 
-- {{CODEBASE_RETRIEVAL_POLICY}}
+- 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-research → /abel-plan → /abel-implement(TDD)
-                                      ↘ /abel-diagnose (bug fix)
+/abel-init → /abel-design → /abel-implement(TDD)
+                           ↘ /abel-diagnose (bug fix)
 ```
 
 ## Universal Constraints
@@ -38,13 +38,13 @@ This context does not by itself authorize destructive changes to user files or c
 
 ## Stage Skill Matrix
 
-| Skill | Research | Plan | 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 |
+| 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:new` `/opsx:ff` `/opsx:archive` `openspec view` `openspec status`
+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/lib/templates/workflow/commands/abel-implement.md

@@ -12,21 +12,31 @@ argument-hint: [change_name]
 
 **Guardrails**
 
-**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**: Generate failing tests ONLY; implementation code is FORBIDDEN.
-- **Green Phase**: Write MINIMAL code to pass tests; over-engineering is FORBIDDEN.
-- **Refactor Phase**: Optimize code quality while keeping ALL tests passing.
-- **Mandatory**: Run tests after EVERY code change; never skip verification.
-- **Test-First**: Each task MUST have a failing test before implementation begins.
+- **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):
@@ -34,39 +44,44 @@ argument-hint: [change_name]
   - Frontend refactor (subagents)
 - **E2E tasks** → `/dev-browser`
 
-1. Run `openspec view` to inspect current project status and review `Active Changes`; ask the user to confirm which change folder (`<change_name>`) they want to implement.
-2. Check artifact status: `openspec status --change <change_name>`
-3. Get apply instructions: `openspec instructions apply --change <change_name>`
-4. Detect test framework: identify project's testing setup (pytest/jest/vitest/etc.)
-5. Work through tasks sequentially; for each task, execute the **TDD Cycle** below.
+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 - Generate Failing Test            │
-│   ├─ Analyze task → determine test type                 │
-│   │   ├─ Backend → pytest/jest                          │
-│   │   ├─ Frontend → vitest/jest                         │
-│   │   └─ E2E → dev-browser                              │
-│   ├─ Generate test via                                  │
-│   │   PROMPT: "Generate failing test for: {task}        │
+│ 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 test code (after review)                     │
-│   ├─ Run test → MUST FAIL                               │
-│   └─ If passes → test invalid, regenerate               │
+│   ├─ 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 to pass test:      │
-│   │            Test: {test_code}                        │
+│   │   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 test → MUST PASS                               │
+│   ├─ Run Red command → MUST PASS                        │
 │   └─ If fails → analyze error, fix, retry               │
 ├─────────────────────────────────────────────────────────┤
 │ Step 3: 🔵 Refactor Phase                               │
@@ -77,28 +92,29 @@ argument-hint: [change_name]
 │   │   ├─ Enhance readability                            │
 │   │   └─ Simplify logic where possible                  │
 │   ├─ Apply refactoring changes                          │
-│   ├─ Run test → MUST STILL PASS                         │
+│   ├─ Run affected-suite command → MUST STILL PASS       │
 │   └─ If fails → rollback refactoring                    │
 └─────────────────────────────────────────────────────────┘
 ```
 
-6. Before applying any change, perform mandatory side-effect review.
+Before applying any change, perform mandatory side-effect review.
 
-7. After TDD cycle completes for a task, mark as `- [x]` in `tasks.md`.
+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)
 
-8. Run all tests to ensure everything passes.
+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.
 
-9. Execute global code review via subagents:
+3. Execute global code review via subagents:
 
-10. Wait for background tasks to complete; review diff patches.
-11. Rewrite patches into production-grade code (per rewriting principle).
-12. Apply refactoring changes.
-13. Run all tests → MUST ALL PASS.
-14. If any test fails → analyze root cause, fix or rollback.
-15. Perform final side-effect review.
-16. Report that the change is ready for archive; do not archive until the user explicitly authorizes `/opsx:archive`.
+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**
 
@@ -108,19 +124,20 @@ argument-hint: [change_name]
 ### Task 1/N: {task_description}
 
 🔴 Red Phase
-├─ Generated: tests/{test_file}
-├─ Run: {test_command}
-└─ Result: {count} failed ✓ (expected)
+├─ Type: {verification_type}
+├─ Generated: {verification_files_or_none}
+├─ Run: {red_command}
+└─ Result: failed for {expected_failure_reason} ✓
 
 🟢 Green Phase
-├─ Generated: src/{impl_file}
-├─ Run: {test_command}
-└─ Result: {count} passed ✓
+├─ Generated: {implementation_files}
+├─ Run: {red_command}
+└─ Result: {green_expected_behavior} ✓
 
 🔵 Refactor Phase (Agent autonomous)
 ├─ Optimized: {description}
-├─ Run: {test_command}
-└─ Result: {count} passed ✓
+├─ Run: {affected_suite_command}
+└─ Result: target verification green ✓
 
 ✓ Task complete → Next task
 
@@ -144,7 +161,8 @@ Frontend Review
 
 ✓ Reviews complete
 ├─ Applied: {refactoring_summary}
-├─ Tests: {count} passed ✓
+├─ Target tests: green ✓
+├─ Full suite: no failures beyond baseline ✓
 └─ Ready for user-authorized archive
 
 ✓ Implementation complete

package/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:
+5. Verify required skills:
    - Skills: `/dev-browser` `/context7-auto-research` `/grok-search`
-7. Output summary with ✓/✗:
+6. Output summary with ✓/✗:
    - OpenSpec installation
    - Project initialization
-   - MCP availability if enabled
    - Required skills availability
 <!-- ABEL:END -->

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "abelworkflow",
-  "version": "1.0.0-rc.1",
+  "version": "1.0.0",
   "description": "Install AbelWorkflow into ~/.agents and create Claude/Codex symlinks.",
   "type": "module",
   "scripts": {
@@ -41,14 +41,8 @@
     "skills/grok-search/scripts/_dotenv.py",
     "skills/grok-search/scripts/groksearch_cli.py",
     "skills/grok-search/scripts/groksearch_entry.py",
-    "skills/prompt-enhancer/.env.example",
-    "skills/prompt-enhancer/ADVANCED.md",
     "skills/prompt-enhancer/SKILL.md",
     "skills/prompt-enhancer/TEMPLATE.md",
-    "skills/prompt-enhancer/requirements.txt",
-    "skills/prompt-enhancer/scripts/_dotenv.py",
-    "skills/prompt-enhancer/scripts/enhance.py",
-    "skills/prompt-enhancer/scripts/prompt_enhancer_entry.py",
     "skills/time/SKILL.md",
     "skills/time/scripts/time_cli.py"
   ],

package/skills/grok-search/.env.example

@@ -6,9 +6,9 @@ GROK_API_URL=
 # 必填项：你的 API 密钥
 GROK_API_KEY=
 
-# 可选项：使用的 Grok 模型（默认：grok-4.20-auto）
-# 常用选项：grok-4.20-auto, grok-4-fast
-GROK_MODEL=grok-4.20-auto
+# 可选项：使用的 Grok 模型（默认：grok-4.20-non-reasoning）
+# 常用选项：grok-4.20-non-reasoning, grok-4.20-auto, grok-4-fast
+GROK_MODEL=grok-4.20-non-reasoning
 
 # 可选项：启用调试模式（true/false）
 GROK_DEBUG=false

package/skills/grok-search/SKILL.md

@@ -24,7 +24,7 @@ Use this skill for web search, webpage retrieval, and current-information lookup
 ```bash
 cp "<SKILL_DIR>/.env.example" "<SKILL_DIR>/.env"
 
-python "<SKILL_DIR>/scripts/groksearch_entry.py" web_search --query "search terms" [--platform "GitHub"] [--min-results 3] [--max-results 10] [--model "grok-4.20-auto"] [--extra-sources 3]
+python "<SKILL_DIR>/scripts/groksearch_entry.py" web_search --query "search terms" [--platform "GitHub"] [--min-results 3] [--max-results 10] [--model "grok-4.20-non-reasoning"] [--extra-sources 3]
 
 python "<SKILL_DIR>/scripts/groksearch_entry.py" web_fetch --url "https://..." [--out file.md] [--fallback-grok]
 

package/skills/grok-search/defaults.json

@@ -1,3 +1,3 @@
 {
-  "model": "grok-4.20-auto"
+  "model": "grok-4.20-non-reasoning"
 }

package/skills/prompt-enhancer/SKILL.md

@@ -2,7 +2,6 @@
 name: prompt-enhancer
 description: |
   Rewrite a raw prompt into a clearer prompt for a coding agent. Use only when the user explicitly asks to improve, optimize, rewrite, or structure a prompt for Codex, Claude Code, Gemini CLI, or another AI agent. Triggers: "improve this prompt", "rewrite this prompt", "optimize this prompt for Codex", "make this prompt better for an AI agent".
-allowed-tools: Bash(python:*), Bash(python3:*), Bash(uv:*), Read, Grep
 ---
 
 # Prompt Enhancer
@@ -19,31 +18,7 @@ Do not use this for general writing edits like email, docs, or PR copy.
 
 ## Do
 
-- Default path: rewrite the prompt directly with the current agent using the structure from [TEMPLATE.md](TEMPLATE.md).
-- Third-party path: use the Python entrypoint only when the user explicitly provides `url`, `apiKey`, and `model`, or when all three are already configured in `<SKILL_DIR>/.env`.
-
-```bash
-python "<SKILL_DIR>/scripts/prompt_enhancer_entry.py" "user's raw prompt here"
-```
-
-- Do not call `scripts/enhance.py` directly.
-- Use the installed skill directory for `<SKILL_DIR>`.
-- If any of `url`, `apiKey`, or `model` is missing, do not invoke the script. Use the current agent directly instead.
-- Optional setup: `cp "<SKILL_DIR>/.env.example" "<SKILL_DIR>/.env"`
-
-## Output
-
-- Read the enhanced prompt from `stdout`.
-- Keep `stderr` for usage or optional debug output only.
+- Rewrite the prompt directly with the current agent, following the structure from [TEMPLATE.md](TEMPLATE.md).
 - Preserve the user's intent and explicit constraints.
 - Add structure and missing execution context only when it helps the agent act.
-- When running directly in the current agent, use placeholders for unknown context instead of inventing new requirements.
-
-## Notes
-
-- Local config file: `<SKILL_DIR>/.env`
-- The entrypoint auto-loads `<SKILL_DIR>/.env` before bootstrap and dependency install.
-- Optional debug flag: `PE_DEBUG=1`
-- Bootstrap controls: `PROMPT_ENHANCER_VENV_DIR`, `PROMPT_ENHANCER_PYTHON`, `AGENTS_SKILLS_PYTHON`
-- Setup and troubleshooting: [ADVANCED.md](ADVANCED.md)
-- Prompt template reference: [TEMPLATE.md](TEMPLATE.md)
+- Use placeholders for unknown context instead of inventing new requirements.

package/lib/installer/render.mjs

@@ -1,46 +0,0 @@
-const augmentContextEngineRetrievalTool = "mcp__augment-context-engine__codebase-retrieval";
-const localCodebaseRetrievalPolicy = "Use local codebase retrieval with `rg`, `rg --files`, `git grep`, and direct file reads. Do not require augment-context-engine MCP.";
-const augmentCodebaseRetrievalPolicy = `Use \`${augmentContextEngineRetrievalTool}\` as the primary codebase search tool.`;
-
-function resolveAugmentContextEngineFeature(options = {}, previousMetadata = {}) {
-  if (typeof options.augmentContextEngine === "boolean") return options.augmentContextEngine;
-  if (typeof previousMetadata?.features?.augmentContextEngine === "boolean") {
-    return previousMetadata.features.augmentContextEngine;
-  }
-  return false;
-}
-
-function getWorkflowRenderValues(augmentContextEngine) {
-  return {
-    CODEBASE_RETRIEVAL_POLICY: augmentContextEngine ? augmentCodebaseRetrievalPolicy : localCodebaseRetrievalPolicy,
-    AUGMENT_CONTEXT_ENGINE_VALIDATION: augmentContextEngine
-      ? `Verify MCP availability:\n   - \`${augmentContextEngineRetrievalTool}\``
-      : "Skip augment-context-engine MCP validation; use local retrieval tools.",
-    CODEBASE_RETRIEVAL_MANDATORY_RULE: augmentContextEngine
-      ? `Mandatory use of \`${augmentContextEngineRetrievalTool}\``
-      : "Mandatory use of configured codebase retrieval policy.",
-    CODEBASE_RETRIEVAL_STRUCTURE_REFERENCE: augmentContextEngine
-      ? `Inspect codebase structure: \`${augmentContextEngineRetrievalTool}\` with \`file list --recursive\`.`
-      : "Inspect codebase structure with `rg --files`, `git grep`, and direct file reads.",
-    CODEBASE_RETRIEVAL_PATTERN_AUDIT: augmentContextEngine
-      ? `Use augment-context-engine to validate against existing codebase patterns.\n   ${augmentContextEngineRetrievalTool}: "Search for existing implementations similar to change <change_name>. Keywords: [key concepts from proposal]"`
-      : "Use `rg`, `rg --files`, `git grep`, and direct file reads to validate against existing codebase patterns."
-  };
-}
-
-function renderWorkflowTemplate(content, { augmentContextEngine = false } = {}) {
-  let nextContent = content;
-  for (const [key, value] of Object.entries(getWorkflowRenderValues(augmentContextEngine))) {
-    nextContent = nextContent.replaceAll(`{{${key}}}`, value);
-  }
-  if (nextContent.includes("{{") || nextContent.includes("}}")) {
-    throw new Error("工作流模板包含未解析占位符");
-  }
-  return nextContent;
-}
-
-export {
-  getWorkflowRenderValues,
-  renderWorkflowTemplate,
-  resolveAugmentContextEngineFeature
-};