abelworkflow 0.9.2 → 1.0.0

package/commands/abel-implement.md

@@ -1,157 +0,0 @@
----
-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**
-
-**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.
-
-**Skill Integration**: See `Stage Skill Matrix` (Implement column)
-
-**Tool Routing**:
-- **TDD Cycle**: Autonomous refactoring
-- **Final Review** (after all tasks):
-  - Backend refactor (subagents)
-  - 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.
-
-**TDD Cycle (per task)**
-
-```
-┌─────────────────────────────────────────────────────────┐
-│ Step 0: Pre-Check                                       │
-│   └─ /confidence-check → require ≥90% to proceed        │
-├─────────────────────────────────────────────────────────┤
-│ 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}        │
-│   │            Context: {code_context}                  │
-│   │            Output: unified diff patch               │
-│   │            FORBIDDEN: implementation code"          │
-│   ├─ Apply test code (after review)                     │
-│   ├─ Run test → MUST FAIL                               │
-│   └─ If passes → test invalid, regenerate               │
-├─────────────────────────────────────────────────────────┤
-│ Step 2: 🟢 Green Phase - Minimal Implementation         │
-│   ├─ Generate minimal implementation                    │
-│   │   PROMPT: "Generate minimal code to pass test:      │
-│   │            Test: {test_code}                        │
-│   │            Context: {code_context}                  │
-│   │            Output: unified diff patch               │
-│   │            FORBIDDEN: over-engineering"             │
-│   ├─ Apply implementation (after review & rewrite)      │
-│   ├─ Run test → 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 test → MUST STILL PASS                         │
-│   └─ If fails → rollback refactoring                    │
-└─────────────────────────────────────────────────────────┘
-```
-
-6. Before applying any change, perform mandatory side-effect review.
-
-7. After TDD cycle completes for a task, mark as `- [x]` in `tasks.md`.
-
-**Final Review & Refactor** (after all tasks complete)
-
-8. Run all tests to ensure everything passes.
-
-9. 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. Run `openspec archive <change_name>` or `/opsx:archive`.
-
-**TDD Output Format**
-
-```
-## /oc:implementation (TDD Mode)
-
-### Task 1/N: {task_description}
-
-📋 Confidence Check: {score}% {status}
-
-🔴 Red Phase
-├─ Generated: tests/{test_file}
-├─ Run: {test_command}
-└─ Result: {count} failed ✓ (expected)
-
-🟢 Green Phase
-├─ Generated: src/{impl_file}
-├─ Run: {test_command}
-└─ Result: {count} passed ✓
-
-🔵 Refactor Phase (Agent autonomous)
-├─ Optimized: {description}
-├─ Run: {test_command}
-└─ Result: {count} passed ✓
-
-✓ 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}
-├─ Tests: {count} passed ✓
-└─ Ready for archive
-
-✓ Implementation complete
-```
-<!-- ABEL:END -->

package/commands/abel-plan.md

@@ -1,88 +0,0 @@
----
-name: abel-plan
-description: Refine approved change into a zero-decision executable plan.
-category: abel
-tags: [abel, plan, PBT]
-argument-hint: [change_name]
----
-<!-- ABEL:START -->
-**Guardrails**
-- Strictly adhere to **OpenSpec** rules when writing **standardized spec-structured projects**.
-- The goal of this phase is to eliminate ALL decision points from the task flow—implementation should be pure mechanical execution.
-- Do not proceed to implementation until every ambiguity is resolved and every constraint is explicitly documented.
-- Every requirement must have Property-Based Testing (PBT) properties defined—focus on invariants, not just example-based tests.
-- If constraints cannot be fully specified, escalate back to the user or return to the research phase rather than making assumptions.
-- Refer to `openspec/AGENTS.md` for additional conventions; run `openspec update` if the file is missing.
-
-**Skill Integration**: See `Stage Skill Matrix` (Plan column)
-
-**FORBIDDEN**: Direct implementation code generation
-
-**Steps**
-1. Run `openspec view` to display all **Active Changes**, then confirm with the user which change folder (`<change_name>`) they wish to refine into a zero-decision plan.
-
-2. Navigate to `openspec/changes/<change_name>/` and review existing artifacts:
-   - Check `openspec status --change <change_name>` for artifact completion
-   - Use `openspec instructions specs --change <change_name>` for specs guidance
-
-3. **Implementation Analysis**: Invoke skills to perform systematic analysis to derive a plan:
-   ```
-   # First, invoke /sequential-think skill for systematic analysis if proposal has 3+ interconnected requirements
-
-   /sequential-think: "Analyze change <change_name> systematically: Break down into components, identify dependencies, evaluate architectural trade-offs, and surface potential conflicts."
-   
-   # Then invoke /context7-auto-research skill to validate framework/library choices
-
-   /context7-auto-research: "For each technology mentioned in change <change_name>, retrieve official documentation patterns and best practices."
-   ```
-   Produce a consolidated, constraint-complete plan and list any missing constraints as questions to the user.
-
-4. **Uncertainty Elimination Audit**: Invoke skills to detect and eliminate remaining ambiguities:
-   ```
-   # First, validate against existing codebase patterns
-   {{CODEBASE_RETRIEVAL_PATTERN_AUDIT}}
-   # Then audit for ambiguities directly and list them explicitly
-   Review change <change_name> for decision points that remain unspecified. For each: [AMBIGUITY] <description> → [REQUIRED CONSTRAINT] <what must be specified>.
-   Identify implicit assumptions in change <change_name>. For each: [ASSUMPTION] <description> → [EXPLICIT CONSTRAINT NEEDED] <concrete specification>.
-   ```
-   
-   **Anti-Pattern Detection** (flag and reject):
-   - Information collection without decision boundaries (e.g., "JWT vs OAuth2 vs session—all viable")
-   - Technical comparisons without selection criteria
-   - Deferred decisions marked as "to be determined during implementation"
-   
-   **Target Pattern** (required for approval):
-   - Explicit technology choices with parameters (e.g., "JWT with accessToken TTL=15min, refreshToken TTL=7days")
-   - Concrete algorithm selections with configurations (e.g., "bcrypt with cost factor=12")
-   - Precise behavioral rules (e.g., "Lock account for 30min after 5 failed login attempts")
-   
-   Iterate with user until ALL ambiguities are resolved into explicit constraints.
-
-5. **PBT Property Extraction**: Invoke skills to derive testable invariants:
-   ```
-   "Extract Property-Based Testing properties from change <change_name>. For each requirement: [INVARIANT] <must always hold> → [FALSIFICATION STRATEGY] <how to generate counterexamples>."
-   "Define system properties for change <change_name>: [PROPERTY] <name> | [DEFINITION] <formal description> | [BOUNDARY CONDITIONS] <edge cases> | [COUNTEREXAMPLE GENERATION] <approach>."
-   ```
-   
-   **PBT Property Categories to Extract**:
-   - **Commutativity/Associativity**: Order-independent operations
-   - **Idempotency**: Repeated operations yield same result
-   - **Round-trip**: Encode→Decode returns original
-   - **Invariant Preservation**: State constraints maintained across operations
-   - **Monotonicity**: Ordering guarantees (e.g., timestamps always increase)
-   - **Bounds**: Value ranges, size limits, rate constraints
-
-**Reference**
-- Use `openspec show <change_name> --json --deltas-only` to inspect proposal structure when validation fails.
-- Use `openspec list --specs` to check for conflicts with existing specifications.
-- Search existing patterns with `rg -n "INVARIANT:|PROPERTY:|Constraint:" openspec/` before defining new ones.
-- For complex proposals, consider running steps 2-4 iteratively on sub-components.
-- Ask the user directly for ANY ambiguity—do not assume or guess.
-
-**Exit Criteria**
-A proposal is ready to exit the Plan phase only when:
-- [ ] Zero ambiguities remain (verified by step 4 audit)
-- [ ] All PBT properties documented with falsification strategies
-- [ ] `openspec validate <change_name> --strict` returns zero issues
-- [ ] User has explicitly approved all constraint decisions
-<!-- ABEL:END -->

package/commands/abel-research.md

@@ -1,126 +0,0 @@
----
-name: abel-research
-description: Transform user requirements into constraint sets via structured exploration (NO implementation)
-category: abel
-tags: [abel, research, constraints, exploration, subagents]
----
-
-<!-- ABEL:RESEARCH:START -->
-
-# abel-research — Operating Mode (Constraints & Specs Only)
-
-## Non‑Negotiable Rules (Highest Priority)
-1. RESEARCH MODE ONLY.
-   - You MUST NOT generate code.
-2. WRITE SCOPE IS RESTRICTED.
-   - You MAY create/edit files ONLY under: openspec/changes/<change-name>/** (and only after passing the confirmation gates).
-   - You MUST NOT write anywhere else.
-3. Output must be constraint sets + verifiable success criteria, not an information dump.
-
-## Goal
-Produce constraint sets that narrow the solution space, plus measurable success criteria.
-
----
-
-
-
-## Phase 0 — Requirement Intake Gate (MANDATORY)
-- **MUST** confirm the user’s requirement exists and is clear **before** any research/action.
-- If missing/unclear, **MUST** ask the user directly in a concise grouped message to collect: goal, in-scope area, top scenarios, non-goals, known constraints, success signals.
-- **MUST NOT** run `/opsx:new`, any codebase retrieval, spawn subagents, or generate artifacts until the user confirms a brief requirement summary.
-
----
-
-## Phase 1 — Initialize OpenSpec Change Folder
-1) Run: /opsx:new <change-name>
-2) From now on, you may write ONLY under openspec/changes/<change-name>/**.
-
----
-
-## Phase 2 — Initial Codebase Assessment (Read‑Only)
-- {{CODEBASE_RETRIEVAL_POLICY}}
-- If technical research needed (architectural patterns, best practices), invoke `/grok-search` skill
-- If the codebase spans multiple modules/directories, dispatch parallel explore subagents by context boundary.
-
----
-
-## Phase 3 — Define Exploration Boundaries (Context-Based Division Only)
-- Identify natural context boundaries in the codebase (NOT functional roles).
-- Example divisions:
-  * Subagent 1: User domain code (user models, user services, user UI)
-  * Subagent 2: Authentication & authorization code (auth middleware, session, tokens)
-  * Subagent 3: Configuration & infrastructure (configs, deployments, build scripts)
-- Each boundary should be self-contained: no cross-communication needed between subagents.
-- Define exploration scope and expected output for each subagent.
-
----
-
-## Phase 4 — Subagent Output Template (MANDATORY JSON)
-All explore subagents MUST return valid JSON using this schema:
-{
-  "module_name": "字符串 - 所探索的上下文边界",
-  "existing_structures": ["发现的关键结构/模式列表"],
-  "existing_conventions": ["当前使用的约定/标准列表"],
-  "constraints_discovered": ["限制解决方案空间的硬约束列表"],
-  "open_questions": ["需要用户输入的歧义问题列表"],
-  "dependencies": ["对其他模块/系统的依赖列表"],
-  "risks": ["潜在风险或阻碍列表"],
-  "success_criteria_hints": ["指示成功的可观察行为列表"]
-}
-
----
-
-## Phase 5 — Parallel Subagent Dispatch
-- Monitor subagent execution and collect structured reports.
-- For each boundary, spawn an Explore subagent with:
-  - {{CODEBASE_RETRIEVAL_MANDATORY_RULE}}
-  - Clear scope
-  - self-contained with independent output
-  - Required output template (from Phase 4)
-  - If boundary involves 3+ interconnected components, invoke `/sequential-think` skill
-  - Clear success criteria: complete analysis of assigned boundary
-
-
----
-
-## Phase 6 — Aggregate & Synthesize
-- Collect all subagent JSON outputs.
-- Merge findings into unified constraint sets:
-  * **Hard constraints**: Technical limitations, existing patterns that cannot be violated.
-  * **Soft constraints**: Conventions, preferences, style guides.
-  * **Dependencies**: Cross-module relationships that affect implementation order.
-  * **Risks**: Potential blockers that need mitigation.
-- Identify **open questions** from all reports that require user clarification.
-- Synthesize **success criteria** from scenario hints across all contexts.
-
----
-
-## Phase 7 — User Interaction for Ambiguity Resolution
-- Compile prioritized list of open questions from aggregated reports.
-- Present questions directly to the user in a concise grouped message:
-  * Group related questions together.
-  * Provide context for each question.
-  * Suggest default answers when applicable.
-- Capture user responses as additional constraints.
-- Update constraint sets with confirmed decisions.
-
----
-
-## Phase 8 — Generate OpenSpec Artifacts
-- Transform finalized constraint sets into OpenSpec proposal/specs/design/tasks.
-- Every requirement MUST have a verifiable scenario and success criteria.
-- Keep all writes inside openspec/changes/<change-name>/**.
-
-## Reference
-- Review existing constraints: `rg -n "Constraint:|MUST|MUST NOT" openspec/specs`
-- {{CODEBASE_RETRIEVAL_STRUCTURE_REFERENCE}}
-
-- Check prior research outputs: `ls openspec/changes/*/`
-- OpenSpec CLI commands:
-  - `openspec view` - Interactive dashboard to browse changes
-  - `openspec list --changes` - List all active changes
-  - `openspec status --change <name>` - Check artifact completion status
-  - `openspec instructions proposal --change <name>` - Get proposal instructions
-- Validate subagent outputs conform to template before aggregation.
-- Ask the user directly for ANY ambiguity—do not assume or guess.
-<!-- ABEL:RESEARCH:END -->

package/lib/cli/logic.mjs

@@ -1,213 +0,0 @@
-import * as p from "@clack/prompts";
-
-const interactiveMenuDescriptors = [
-  { value: "full-init", label: "完整初始化", hint: "同步 + 安装 + 配置", group: "main" },
-  { value: "install", label: "仅同步工作流", group: "main" },
-  { value: "grok-search", label: "配置 grok-search", hint: "技能", group: "skill" },
-  { value: "context7", label: "配置 context7-auto-research", hint: "技能", group: "skill" },
-  { value: "prompt-enhancer", label: "配置 prompt-enhancer", hint: "技能", group: "skill" },
-  { value: "pi-cli", label: "安装/配置 Pi", hint: "CLI", group: "cli" },
-  { value: "codex-cli", label: "安装/配置 Codex", hint: "CLI", group: "cli" },
-  { value: "claude-cli", label: "安装/配置 Claude Code", hint: "CLI", group: "cli" },
-  { value: "exit", label: "退出", group: "exit" }
-];
-
-const interactiveMenuDefaultValue = "full-init";
-const cliToolMenuDescriptorMap = {
-  pi: [
-    { value: "pi-install", label: "安装/更新 Pi" },
-    { value: "pi-api", label: "配置 Pi API" },
-    { value: "back", label: "返回上一级" }
-  ],
-  codex: [
-    { value: "codex-install", label: "安装/更新 Codex" },
-    { value: "codex-api", label: "配置 Codex API" },
-    { value: "back", label: "返回上一级" }
-  ],
-  claude: [
-    { value: "claude-install", label: "安装/更新 Claude Code" },
-    { value: "claude-api", label: "配置 Claude Code API" },
-    { value: "back", label: "返回上一级" }
-  ]
-};
-
-function buildCliToolMenuDescriptors(tool) {
-  const descriptors = cliToolMenuDescriptorMap[tool];
-  if (!descriptors) {
-    throw new Error(`Unknown CLI tool: ${tool}`);
-  }
-  return descriptors.map((descriptor) => ({ ...descriptor }));
-}
-
-class CancelledError extends Error {
-  constructor(message = "用户取消") {
-    super(message);
-    this.name = "CancelledError";
-  }
-}
-
-function required(message = "此项不能为空") {
-  return (value) => {
-    if (value === undefined || value === null || (typeof value === "string" && value.trim() === "")) {
-      return message;
-    }
-  };
-}
-
-function requiredUnlessExisting(existingValue, message = "此项不能为空") {
-  return (value) => {
-    if ((value === undefined || value === null || (typeof value === "string" && value.trim() === "")) && !existingValue) {
-      return message;
-    }
-  };
-}
-
-/**
- * 回退逻辑：用户输入非空则用新值，否则用旧值。
- * 输入 "-" 表示清除已有值（返回 undefined）。
- * existingValue 可能来自 dotenv / JSON 读取，会传入空字符串；
- * 空字符串将被净化为 undefined，避免写入无意义的空配置。
- * 注意：本函数仅适用于字符串类型的配置值，不适用于可能为 0/false 的数字或布尔值。
- */
-function resolvePasswordValue(userInput, existingValue) {
-  if (typeof userInput === "string") {
-    const trimmed = userInput.trim();
-    if (trimmed === "") {
-      if (typeof existingValue === "string" && existingValue.trim() === "") {
-        return undefined;
-      }
-      return existingValue || undefined;
-    }
-    return trimmed === "-" ? undefined : trimmed;
-  }
-  if (typeof existingValue === "string" && existingValue.trim() === "") {
-    return undefined;
-  }
-  return existingValue || undefined;
-}
-
-function assertNotCancelled(value) {
-  if (p.isCancel(value)) {
-    throw new CancelledError();
-  }
-}
-
-async function confirmOrCancel({ message, initialValue = false }) {
-  const value = await p.confirm({ message, initialValue, active: "是", inactive: "否" });
-  assertNotCancelled(value);
-  return value;
-}
-
-async function selectOrCancel(options) {
-  const value = await p.select(options);
-  assertNotCancelled(value);
-  return value;
-}
-
-function parseArgs(argv, { defaultAgentsDir, resolvePath }) {
-  const options = {
-    agentsDir: defaultAgentsDir,
-    force: false,
-    relinkOnly: false,
-    nonInteractive: false,
-    command: "menu"
-  };
-  const positional = [];
-  let helpRequested = false;
-
-  for (let i = 0; i < argv.length; i += 1) {
-    const arg = argv[i];
-    if (arg === "--force" || arg === "-f") {
-      options.force = true;
-      continue;
-    }
-    if (arg === "--link-only") {
-      options.relinkOnly = true;
-      continue;
-    }
-    if (arg === "--agents-dir") {
-      const value = argv[i + 1];
-      if (!value) {
-        throw new Error("--agents-dir requires a path");
-      }
-      options.agentsDir = resolvePath(value);
-      i += 1;
-      continue;
-    }
-    if (arg === "--non-interactive") {
-      options.nonInteractive = true;
-      continue;
-    }
-    if (arg === "--help" || arg === "-h" || arg === "help") {
-      helpRequested = true;
-      options.command = "help";
-      continue;
-    }
-    if (arg.startsWith("-")) {
-      throw new Error(`Unknown argument: ${arg}`);
-    }
-    positional.push(arg);
-  }
-
-  if (positional.length > 1) {
-    throw new Error(`Unknown argument: ${positional.slice(1).join(" ")}`);
-  }
-
-  if (positional[0]) {
-    if (["menu", "init"].includes(positional[0])) {
-      if (!helpRequested) {
-        options.command = "menu";
-      }
-    } else if (["install", "sync"].includes(positional[0])) {
-      if (!helpRequested) {
-        options.command = "install";
-      }
-    } else {
-      throw new Error(`Unknown command: ${positional[0]}`);
-    }
-  }
-
-  if (options.command !== "install" && (options.force || options.relinkOnly || options.agentsDir !== defaultAgentsDir)) {
-    throw new Error("`--force`、`--link-only`、`--agents-dir` 仅能与 `install` 命令一起使用");
-  }
-
-  if (!options.nonInteractive && process.env.CI) {
-    options.nonInteractive = true;
-  }
-
-  return options;
-}
-
-function assertInteractiveMenuSupported({ command, inputIsTTY, outputIsTTY, nonInteractive }) {
-  // 防御性检查（死代码守护）：main() 已在调用前将非交互 menu 降级为 install，
-  // 此处仅防止外部直接调用 assertInteractiveMenuSupported 时漏掉判断。
-  if (command === "menu" && nonInteractive) {
-    throw new Error("非交互模式已启用；请显式使用 `npx abelworkflow install` 进行安装");
-  }
-  if (command === "menu" && (!inputIsTTY || !outputIsTTY)) {
-    throw new Error("交互式菜单需要 TTY 终端；非交互场景请显式使用 `npx abelworkflow install`");
-  }
-}
-
-function getRunCommandSpawnOptions(platform = process.env.ABELWORKFLOW_TEST_PLATFORM || process.platform) {
-  return {
-    stdio: "inherit",
-    shell: platform === "win32"
-  };
-}
-
-export {
-  assertInteractiveMenuSupported,
-  assertNotCancelled,
-  buildCliToolMenuDescriptors,
-  CancelledError,
-  confirmOrCancel,
-  getRunCommandSpawnOptions,
-  interactiveMenuDefaultValue,
-  interactiveMenuDescriptors,
-  parseArgs,
-  required,
-  requiredUnlessExisting,
-  resolvePasswordValue,
-  selectOrCancel
-};