@shenlee/devcrew 0.1.4 → 0.1.5

package/docs/superpowers/plans/2026-07-14-reliability-recovery.md

@@ -1,208 +0,0 @@
-# Configuration Integrity and Run Recovery Implementation Plan
-
-> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
-
-**Goal:** Reject unsafe configuration, prevent concurrent MCP mutations from overwriting one another, and make interrupted runs explicitly abortable and recoverable.
-
-**Architecture:** A strict version-1 parser validates `.devcrew/config.json` and keeps artifact paths inside the requester repository. A repository-wide atomic directory lock wraps MCP mutations while read-only calls remain available. Aborting is a persisted terminal state that preserves audit data; recovery only clears a confirmed stale lock and retries cleanup of a terminal run's residual worktree.
-
-**Tech Stack:** TypeScript, Node.js `fs/promises`, Node test runner, Git worktrees, MCP tool registry.
-
----
-
-### Task 1: Validate configuration and artifact paths
-
-**Files:**
-- Modify: `packages/core/src/config.ts`
-- Modify: `tests/core.test.ts`
-
-- [ ] **Step 1: Write failing configuration tests**
-
-Add table-driven tests that write `.devcrew/config.json`, then call
-`startWorkflow`. Cover an unknown top-level key, an unknown workflow key, an
-unknown gate, a duplicate gate, an empty command, an absolute
-`artifactDirectory`, and `../outside`. Each test asserts the error identifies
-the invalid field. Add a valid custom artifact directory assertion so the
-existing supported path remains accepted.
-
-- [ ] **Step 2: Verify RED**
-
-Run:
-
-```bash
-node --import tsx --test tests/core.test.ts
-```
-
-Expected: new invalid-config cases fail because `readConfig` currently merges
-untyped JSON and `artifactDirectory` is only joined to `cwd`.
-
-- [ ] **Step 3: Implement a strict version-1 parser**
-
-In `config.ts`, parse JSON as `unknown`, require plain objects, reject keys
-outside the documented schema, validate enum values from exported type
-constants, and validate arrays as non-empty trimmed strings with no invalid
-gate entries or duplicates. Resolve `workflow.artifactDirectory` against
-`cwd`; reject absolute values and any resolved path whose relative path leaves
-the repository. Return the normalized validated `DevCrewConfig`.
-
-- [ ] **Step 4: Verify GREEN and commit**
-
-Run:
-
-```bash
-node --import tsx --test tests/core.test.ts
-git add packages/core/src/config.ts tests/core.test.ts
-git commit -m "fix: validate DevCrew configuration strictly"
-```
-
-Expected: all core tests pass and invalid configuration fails before a run is
-created.
-
-### Task 2: Add explicit repository mutation locks
-
-**Files:**
-- Create: `packages/core/src/lock.ts`
-- Modify: `packages/core/src/paths.ts`
-- Modify: `packages/core/src/index.ts`
-- Modify: `packages/service/src/tools.ts`
-- Modify: `tests/core.test.ts`
-- Modify: `tests/service.test.ts`
-
-- [ ] **Step 1: Write failing lock tests**
-
-Add core tests that hold a repository lock while a second acquisition rejects
-with a busy error, then release the first lock and acquire again. Create a
-lock directory with metadata containing a non-running pid and assert normal
-acquisition still refuses it while explicit stale-lock recovery removes it.
-Add a service test that holds the lock, verifies `devcrew_status` still works,
-and verifies a mutating `devcrew_approve` returns a structured busy error.
-
-- [ ] **Step 2: Verify RED**
-
-Run:
-
-```bash
-node --import tsx --test tests/core.test.ts tests/service.test.ts
-```
-
-Expected: imports fail because no repository lock API exists and MCP calls do
-not serialize mutations.
-
-- [ ] **Step 3: Implement lock primitives**
-
-Add `repositoryLockPath`, then implement `withRepositoryLock(cwd, action)`
-using atomic `mkdir`. Store `{ ownerId, pid, createdAt }` in `lock.json`,
-remove only the held owner directory in `finally`, and reject existing locks
-without waiting. Implement `recoverRepositoryLock(cwd)` to remove only a
-missing/invalid/dead-local-process lock; it must reject a live owner and must
-never run automatically.
-
-- [ ] **Step 4: Wrap MCP mutation dispatch**
-
-In `callDevCrewTool`, route start, answer, approve, reject, continue,
-complete-execution, waive-verification, abort, and recovery cleanup through a
-single lock wrapper. Resolve an omitted run id inside the lock. Keep status and
-artifact calls unlocked. Ensure start creates its run and sets `active-run`
-under one lock.
-
-- [ ] **Step 5: Verify GREEN and commit**
-
-Run:
-
-```bash
-node --import tsx --test tests/core.test.ts tests/service.test.ts
-git add packages/core/src/lock.ts packages/core/src/paths.ts packages/core/src/index.ts packages/service/src/tools.ts tests/core.test.ts tests/service.test.ts
-git commit -m "fix: serialize DevCrew MCP mutations"
-```
-
-Expected: concurrent writes return a structured busy error and reads remain
-available.
-
-### Task 3: Persist terminal aborts and recover residual worktrees
-
-**Files:**
-- Modify: `packages/core/src/types.ts`
-- Modify: `packages/core/src/active-run.ts`
-- Modify: `packages/core/src/workflow.ts`
-- Modify: `packages/orchestrator/src/index.ts`
-- Modify: `packages/service/src/tools.ts`
-- Modify: `docs/workflow.md`
-- Modify: `tests/core.test.ts`
-- Modify: `tests/orchestrator.test.ts`
-- Modify: `tests/service.test.ts`
-
-- [ ] **Step 1: Write failing abort and recovery tests**
-
-Add a workflow test that aborts a nonterminal state with a reason, asserts
-`status: "aborted"`, persisted reason/timestamp, and that continue/answer/
-complete cannot resume it. Add an apply-worktree test that aborts after
-execution, confirms the requester checkout is unchanged and the isolated
-worktree is removed. Add a service test that `devcrew_abort` clears its active
-run and that a repeated abort is idempotent. Add a recovery test for an
-aborted state retaining a workspace reference: recovery cleans that worktree
-and clears the reference without running a role.
-
-- [ ] **Step 2: Verify RED**
-
-Run:
-
-```bash
-node --import tsx --test tests/core.test.ts tests/orchestrator.test.ts tests/service.test.ts
-```
-
-Expected: tests fail because `aborted` is not a run status and no abort or
-recovery tool exists.
-
-- [ ] **Step 3: Implement terminal abort state**
-
-Add `RunAbort` plus `RunStatus: "aborted"`; persist the first non-empty abort
-reason and timestamp. Add `abortWorkflow` with terminal idempotency, and make
-continuation return aborted runs unchanged. Add
-`clearActiveRunIfMatches(cwd, runId)` so an abort never clears another run's
-active pointer.
-
-- [ ] **Step 4: Implement orchestration and MCP lifecycle tools**
-
-Add `abortOrchestratedWorkflow` to persist abort audit state before attempting
-worktree cleanup. On cleanup success clear `executionWorkspace`; on failure
-leave it for recovery. Add `recoverOrchestratedWorkflow` that accepts only
-terminal runs and retries this cleanup. Register `devcrew_abort` and
-`devcrew_recover`, with schemas and structured errors, and apply the lock
-rules from Task 2. Update `docs/workflow.md` with abort/recover semantics.
-
-- [ ] **Step 5: Verify GREEN and commit**
-
-Run:
-
-```bash
-node --import tsx --test tests/core.test.ts tests/orchestrator.test.ts tests/service.test.ts
-git add packages/core/src/types.ts packages/core/src/active-run.ts packages/core/src/workflow.ts packages/orchestrator/src/index.ts packages/service/src/tools.ts docs/workflow.md tests/core.test.ts tests/orchestrator.test.ts tests/service.test.ts
-git commit -m "feat: add DevCrew abort and recovery controls"
-```
-
-Expected: aborted runs retain audit evidence, cannot resume, clean their
-worktrees when possible, and can explicitly retry residual cleanup.
-
-### Task 4: Full verification
-
-**Files:**
-- Verify: all modified files
-
-- [ ] **Step 1: Run repository validation**
-
-```bash
-npm run validate
-```
-
-Expected: TypeScript build succeeds and every test passes.
-
-- [ ] **Step 2: Inspect final state**
-
-```bash
-git diff main...HEAD --check
-git status --short
-git log --oneline main..HEAD
-```
-
-Expected: no whitespace errors, clean worktree, and only the design, plan,
-and implementation commits on the branch.

package/docs/superpowers/plans/2026-07-14-structured-role-results.md

@@ -1,231 +0,0 @@
-# Structured Role Results Implementation Plan
-
-> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
-
-**Goal:** Accept validated, versioned role-result envelopes while preserving Markdown-only SDK outputs and expose structured evidence through run state, artifacts, and MCP.
-
-**Architecture:** The core package owns envelope types and state migration. The adapter recognizes one explicitly marked JSON block, validates role-specific data, and returns Markdown with the protocol block removed. The orchestrator uses the normalized result without changing gates; artifacts render a human-readable appendix, and MCP continues returning the persisted state.
-
-**Tech Stack:** TypeScript strict mode, Node.js built-in test runner, `tsx`.
-
----
-
-### Task 1: Define normalized envelope types and old-state migration
-
-**Files:**
-- Modify: `packages/core/src/types.ts:91-100`
-- Modify: `packages/core/src/store.ts:24-70`
-- Test: `tests/core.test.ts`
-
-- [ ] **Step 1: Write the failing migration test**
-
-Append this test to `tests/core.test.ts`:
-
-```ts
-test("loadState marks pre-envelope role results as legacy", async () => {
-  const cwd = await tempProject();
-  const started = await startWorkflow({ cwd, host: "codex", mode: "feature", request: "Migrate roles" });
-  const path = runDir(cwd, started.runId);
-  const raw = JSON.parse(await readFile(join(path, "state.json"), "utf8")) as Record<string, unknown>;
-  raw.roles = [{ role: "pm", backend: "codex", summary: "old", markdown: "# Old", usedFallback: false }];
-  await writeFile(join(path, "state.json"), JSON.stringify(raw));
-
-  const role = (await loadState(cwd, started.runId)).roles[0] as unknown as { format?: string };
-  assert.equal(role.format, "legacy");
-});
-```
-
-- [ ] **Step 2: Verify it fails**
-
-Run: `npm test -- --test-name-pattern="pre-envelope role"`
-
-Expected: FAIL because `RoleResult.format` does not exist.
-
-- [ ] **Step 3: Add the smallest normalized types and migration**
-
-Add these exports in `packages/core/src/types.ts` and make `format` mandatory on `RoleResult`:
-
-```ts
-export interface CommandEvidence {
-  command: string;
-  exitCode: number;
-  output?: string;
-}
-
-export interface RoleQuestion {
-  id: string;
-  prompt: string;
-  context?: string;
-}
-
-export interface StructuredRoleData {
-  schemaVersion: 1;
-  role: Exclude<RoleResult["role"], "conductor">;
-  summary: string;
-  risks: string[];
-  evidence: CommandEvidence[];
-  questions?: RoleQuestion[];
-  decisions?: string[];
-  reviewDecision?: ArchitectureReviewDecision;
-  changedFiles?: string[];
-  testCases?: Array<{ id: string; scenario: string; type: "happy" | "edge" | "failure" | "regression"; expected: string }>;
-}
-```
-
-In `loadState`, map each persisted role missing a valid `format` to `{ ...role, format: "legacy" }`, leaving all prior persisted fields intact.
-
-- [ ] **Step 4: Verify it passes**
-
-Run: `npm test -- --test-name-pattern="pre-envelope role"`
-
-Expected: PASS.
-
-- [ ] **Step 5: Commit**
-
-```bash
-git add packages/core/src/types.ts packages/core/src/store.ts tests/core.test.ts
-git commit -m "feat: normalize persisted role results"
-```
-
-### Task 2: Parse and validate the marked envelope in adapters
-
-**Files:**
-- Modify: `packages/adapters/src/index.ts:69-102,143-162,424-459`
-- Test: `tests/adapters.test.ts`
-
-- [ ] **Step 1: Write failing parser tests**
-
-Export `parseRoleResultOutput` and add tests that call it with this valid PM output and each invalid variation:
-
-```ts
-const output = `<!-- devcrew-role-result -->
-\`\`\`json
-{"schemaVersion":1,"role":"pm","summary":"Need scope","risks":[],"evidence":[],"questions":[{"id":"format","prompt":"Which formats?"}]}
-\`\`\`
-# Requirements
-
-## Functional Scope
-`;
-const result = parseRoleResultOutput("pm", "requirements", output);
-assert.equal(result.format, "structured");
-assert.deepEqual(result.questions, ["Which formats?"]);
-assert.doesNotMatch(result.markdown, /devcrew-role-result/);
-```
-
-Add separate `assert.throws` tests for malformed marked JSON, two marked blocks, `schemaVersion: 2`, role mismatch, duplicate/blank PM question IDs, and a non-integer command exit code. Add a Markdown-only test proving `format === "legacy"` and existing PM/review parsing remain unchanged.
-
-- [ ] **Step 2: Verify they fail**
-
-Run: `npm test -- --test-name-pattern="role result output"`
-
-Expected: FAIL because `parseRoleResultOutput` is not exported.
-
-- [ ] **Step 3: Implement the protocol parser and prompt contract**
-
-Implement a parser that finds exactly one `<!-- devcrew-role-result -->` followed by a `json` fenced block. When no marker exists, return the original Markdown and `format: "legacy"`; when a marker exists, reject malformed or invalid data. Require all common fields, role-matching field sets, unique PM question IDs, nonempty strings, and integer command exit codes. Return the Markdown with only the marked block removed.
-
-Add this exact prompt guidance before `Required Sections`:
-
-```ts
-"Return this protocol block first:",
-"<!-- devcrew-role-result -->",
-"```json",
-"{\"schemaVersion\":1,\"role\":\"<current role>\",\"summary\":\"...\",\"risks\":[],\"evidence\":[]}",
-"```",
-"Then return the required Markdown H2 sections. Do not include a second marked result block.",
-```
-
-Replace direct Markdown extraction in `runRole` with the parser's normalized result. For legacy output, keep `extractOpenQuestions` and `extractArchitectureReviewDecision`; for structured output, derive those compatibility fields from validated structured data.
-
-- [ ] **Step 4: Verify adapter tests pass**
-
-Run: `npm test -- tests/adapters.test.ts`
-
-Expected: PASS.
-
-- [ ] **Step 5: Commit**
-
-```bash
-git add packages/adapters/src/index.ts tests/adapters.test.ts
-git commit -m "feat: parse structured role result envelopes"
-```
-
-### Task 3: Persist and render structured implementation and test evidence
-
-**Files:**
-- Modify: `packages/orchestrator/src/index.ts:317-344,456-481`
-- Test: `tests/orchestrator.test.ts`
-
-- [ ] **Step 1: Write failing workflow tests**
-
-Add a structured PM runner result with a question and assert `awaiting_input`. Add an implementation result with `format: "structured"` and `structured.changedFiles` plus command evidence, then assert the persisted role retains them and `implementation-review.md` contains `## Structured Role Result` and the command/exit code. Add an analogous tester assertion for `test-report.md` risks and evidence.
-
-- [ ] **Step 2: Verify they fail**
-
-Run: `npm test -- --test-name-pattern="structured (PM|implementation|tester)"`
-
-Expected: FAIL because artifacts do not render structured role data.
-
-- [ ] **Step 3: Render the structured appendix without changing workflow evidence sources**
-
-Add an orchestrator artifact helper used by `appendExecutionSections` that renders `state.roles.at(-1)?.structured` only when `format === "structured"`. It must show schema version, summary, changed files, command evidence, test cases, risks, and questions when present, escaping no data and preserving the role's Markdown body as the primary artifact.
-
-Keep the existing captured Git diff and configured verification as authoritative promotion evidence. Structured implementation `changedFiles` and tester commands are supplemental role assertions, not a way to overwrite `state.changedFiles`, `state.implementationDiff`, or `state.verification`.
-
-In the orchestrator, use structured PM question prompts for `pendingQuestions` and structured review decisions for `architectureReview`; preserve the existing compatibility fields so legacy runners and callers continue to work.
-
-- [ ] **Step 4: Verify workflow tests pass**
-
-Run: `npm test -- tests/orchestrator.test.ts`
-
-Expected: PASS.
-
-- [ ] **Step 5: Commit**
-
-```bash
-git add packages/orchestrator/src/index.ts tests/orchestrator.test.ts
-git commit -m "feat: render structured role evidence"
-```
-
-### Task 4: Surface format and results through MCP and complete regression checks
-
-**Files:**
-- Modify: `packages/service/src/tools.ts:215-320`
-- Test: `tests/service.test.ts`
-- Modify: `docs/codex.md`
-- Modify: `docs/claude-code.md`
-
-- [ ] **Step 1: Write the failing MCP test**
-
-Start a workflow with a structured PM runner, invoke `devcrew_status`, and assert its text includes `role_format=structured` plus `structuredContent.state.roles.at(-1).structured.questions[0].id === "format"`. The test must use `callDevCrewTool`, not inspect the state file directly.
-
-- [ ] **Step 2: Verify it fails**
-
-Run: `npm test -- --test-name-pattern="MCP.*structured role"`
-
-Expected: FAIL until the state summary exposes the normalized role format.
-
-- [ ] **Step 3: Keep MCP state safe and document the migration**
-
-Return the existing state object unchanged except for its newly persisted normalized role fields; do not create a second incompatible tool response shape. Extend `summarizeState` with `role_format=<legacy|structured|none>`.
-
-Document the marker, schema version, legacy fallback rule, and the rule that malformed marked output is rejected rather than downgraded in both host guides.
-
-- [ ] **Step 4: Verify the focused service test passes**
-
-Run: `npm test -- tests/service.test.ts`
-
-Expected: PASS.
-
-- [ ] **Step 5: Run complete validation and inspect the patch**
-
-Run: `npm run validate && npm test && git diff main...HEAD --check`
-
-Expected: validation and all tests pass; whitespace check prints no output.
-
-- [ ] **Step 6: Commit**
-
-```bash
-git add packages/service/src/tools.ts tests/service.test.ts docs/codex.md docs/claude-code.md
-git commit -m "docs: describe structured role result migration"
-```

package/docs/superpowers/specs/2026-07-10-p0-foundation-repair-design.md

@@ -1,182 +0,0 @@
-# DevCrew P0 Foundation Repair Design
-
-## Objective
-
-Repair the P0 workflow and execution-safety defects identified in the 0.1.1 review without expanding into the P1 role-model, semantic architecture review, or configurable workflow work.
-
-The repaired workflow must guarantee that requester approval happens before code changes, apply-mode changes remain isolated until final approval, malformed MCP input cannot poison the server, gate mutations are valid and idempotent, local fallback cannot impersonate apply execution, and the checked-in plugin cannot drift from the package version.
-
-## Scope
-
-This design includes:
-
-- Move real implementation after the existing `implementation` gate.
-- Execute apply-mode implementation and verification in a run-owned Git worktree.
-- Capture committed, staged, unstaged, renamed, deleted, binary, and new-file changes as one reviewable patch.
-- Apply the reviewed patch to the requester's repository only after the `testing` gate is approved.
-- Keep rejected testing work isolated and allow the implementer to revise it.
-- Enforce legal, idempotent `approve`, `reject`, and `answer` transitions.
-- Validate JSON-RPC request shape and recover the stdio queue after handler failures.
-- Reject `executionMode=apply` with the `local` backend.
-- Synchronize package, generated plugin, checked-in plugin, and MCP runtime versions.
-
-This design does not include:
-
-- Real architect-driven semantic diff review.
-- Structured PM questions and machine-readable role verdicts.
-- Host-native role/subagent integration.
-- Configurable gates or artifact directories.
-- Claude marketplace packaging or smoke coverage.
-- Cross-process run locking or HTTP transport.
-
-## Workflow Model
-
-The public gate names remain unchanged for MCP compatibility:
-
-1. `requirements`
-2. `architecture`
-3. `implementation`
-4. `testing`
-
-The internal phase sequence becomes:
-
-```text
-requirements
-  -> architecture
-  -> implementation
-  -> execution (apply only)
-  -> testing
-  -> acceptance
-  -> complete
-```
-
-The existing `implementation` phase becomes plan-only in both execution modes. The implementer receives a read-only role prompt and writes `implementation-plan.md`. Approving the `implementation` gate advances plan mode directly to `testing`, while apply mode advances to the new nongated `execution` phase.
-
-The `execution` phase runs the implementer in an isolated worktree, writes `implementation-review.md`, and advances to `testing` with status `ready`. The next `continue` runs the tester and verification commands in the same worktree, then opens the `testing` gate.
-
-Approving the `testing` gate applies the captured patch to the original repository, removes the worktree, and advances to acceptance. Rejecting the testing gate leaves the worktree isolated. The rejection feedback can be answered, after which the run returns to `execution` so the implementer can revise the existing isolated changes.
-
-## Apply Isolation
-
-### Workspace creation
-
-Before the first execution attempt DevCrew must:
-
-1. Confirm the requester repository is a Git repository with a clean working tree, excluding DevCrew runtime and artifact paths.
-2. Record the current `HEAD` as `baseCommit`.
-3. Create a detached worktree under `.devcrew/worktrees/<run-id>`.
-4. Persist the worktree path and base commit before invoking the SDK role.
-
-All implementation, lint, test, and coverage commands run with the worktree as their working directory. Artifacts and state remain in the original repository.
-
-### Capturing all changes
-
-After the implementer returns DevCrew must normalize any commits created by the role back into worktree changes relative to `baseCommit`. This is safe because the worktree is owned by the run and has not been promoted.
-
-DevCrew then marks untracked files as intent-to-add inside the worktree and captures:
-
-- `git status --porcelain=v1 -z -uall` for changed paths.
-- `git diff --binary --no-ext-diff <baseCommit> --` for the complete patch.
-
-Using the base commit includes staged and unstaged changes. Intent-to-add makes new files visible in the patch. NUL-delimited status parsing avoids filename quoting and rename parsing bugs.
-
-### Promotion
-
-Before applying an approved patch DevCrew must re-check that the requester repository is clean and still points at `baseCommit`. If either condition changed, approval fails without deleting the worktree or mutating the requester repository.
-
-Promotion writes the captured patch under the run directory, applies it to the requester repository with `git apply --binary`, verifies the resulting requester diff matches the reviewed patch, and then removes the worktree. The promoted files remain uncommitted so the requester retains normal review and commit control.
-
-An empty apply patch is an error. Apply mode must never report successful implementation when no repository change was produced.
-
-## State Changes
-
-`RunState` gains optional execution workspace metadata:
-
-```ts
-interface ExecutionWorkspace {
-  path: string;
-  baseCommit: string;
-}
-```
-
-The `execution` phase is added to `PHASES`. Older state files without execution workspace metadata continue to load.
-
-Gate mutations use these rules:
-
-- Approving an already approved gate returns the unchanged state and does not append another approval.
-- Rejecting an already rejected gate returns the unchanged state and does not append duplicate feedback.
-- A pending gate can only be approved or rejected when it is the current phase gate and status is `awaiting_approval`.
-- `answer` is only legal while status is `awaiting_input` and the current gate is rejected.
-- Calls against `acceptance` or `complete` cannot move the run backwards.
-
-The service uses a new orchestrated approval entry point so testing approval can promote the patch before the core state advances.
-
-## Backend Rules
-
-After host/config backend resolution, workflow creation rejects this combination:
-
-```text
-executionMode=apply, backend=local
-```
-
-Plan mode keeps deterministic local fallback. Apply mode requires a real Codex or Claude SDK backend at every role phase.
-
-The implementation-plan role is forced to read-only behavior even when the run execution mode is apply. Only the new execution phase and apply-mode tester receive write/Bash capabilities.
-
-## Stdio Reliability
-
-The line processor validates that parsed JSON is a non-array object with `jsonrpc: "2.0"` and a string `method`. Invalid request objects receive JSON-RPC error `-32600` with `id: null` and do not enter the request queue.
-
-For queued requests, each returned task may reject to its caller, but the internal queue stores a recovered promise. One handler failure therefore cannot prevent later requests from executing.
-
-Existing parse error behavior remains `-32700`. Notifications without an ID remain response-free.
-
-## Version Discipline
-
-The next implementation version is `0.1.2`. The following must agree:
-
-- `package.json`
-- `package-lock.json`
-- `DEVCREW_VERSION`
-- generated Codex and Claude manifests
-- checked-in Codex manifest
-- checked-in Codex MCP npm package specifier
-- smoke client metadata and version assertions
-
-CI adds a checked-in plugin drift test that generates a fresh Codex plugin in a temporary directory and compares all generated text files with the checked-in bundle. Binary assets are checked by hash. Publication order is npm `0.1.2` first, then marketplace push, so the public plugin never references an unavailable npm version.
-
-## Error Handling
-
-- Worktree creation failure leaves the run in `execution/ready` with no role result recorded.
-- SDK failure leaves the isolated worktree available for diagnosis and retry.
-- Empty implementation patch fails before testing.
-- Verification failures remain visible in the testing artifact; automatic test verdict blocking remains P1.
-- Promotion precondition failure leaves the worktree and state intact for manual resolution.
-- Worktree cleanup runs only after successful promotion or explicit run rejection cleanup added in a later lifecycle feature.
-
-## Testing Strategy
-
-Tests are added before implementation and must demonstrate the original failures:
-
-- Implementation-plan approval occurs before the first writable role invocation.
-- Local apply start is rejected.
-- An implementer-created commit is converted into a complete reviewed patch.
-- Staged, unstaged, renamed, deleted, binary, and untracked files appear in review evidence.
-- Rejecting testing keeps changes outside the requester repository and supports revision.
-- Approving testing promotes exactly the reviewed patch.
-- Changed requester `HEAD` or dirty requester worktree blocks promotion.
-- Empty apply output fails.
-- Duplicate approvals/rejections are idempotent.
-- Complete runs cannot be reopened.
-- Answer outside `awaiting_input` fails.
-- JSON `null`, arrays, missing methods, and wrong JSON-RPC versions return `-32600`.
-- A rejected request handler does not block the next stdio request.
-- Checked-in plugin version and generated bundle match `DEVCREW_VERSION`.
-
-The final verification command remains `npm run validate`, followed by the isolated Codex marketplace smoke after `@shenlee/devcrew@0.1.2` is published.
-
-## Compatibility
-
-MCP tool names and gate names remain stable. Existing plan-mode callers continue using the same approve/continue sequence. Apply-mode sequencing gains one additional `continue` call for the execution phase before testing.
-
-Existing 0.1.1 run files remain loadable. Runs already in the old `implementation` phase are treated as implementation planning and cannot write code until their implementation gate is approved under the new state transition.