create-harness-vibe-coding 0.8.3 → 0.8.5

package/README-CN.md

@@ -29,7 +29,7 @@ npx create-harness-vibe-coding@latest my-project
 | `Harness/tasks/` + `Harness/PROGRESS.md` | 跨会话任务状态 |
 | `.claude/skills/` | Claude Code workflow skill 入口 |
 | `.agents/skills/` | Codex repo skill 入口 |
-| `.codex/` | Codex hooks/config |
+| `.codex/` | Codex config |
 | `/wf` / `$wf` | 长任务 workflow |
 | `/wf-max` / `$wf-max` | 最大并行 workflow |
 | `/wf-review` / `$wf-review` | 交叉审查 workflow |
@@ -41,7 +41,7 @@ Claude Code 和 Codex 共用同一套核心 Harness 文档，但发现入口不
 
 - Claude Code：`.claude/skills/<name>/SKILL.md`，通常用 `/wf` 调用。
 - Codex：`.agents/skills/<name>/SKILL.md`，通常用 `$wf` 或 `/skills` 调用。
-- `.codex/` 只放 Codex 配置和 hooks；不要再使用根目录 `commands/*.toml` 伪装 Codex slash command。
+- `.codex/` 只放 Codex 配置；runtime hooks 默认不存在，只有 `/wf-auto` 可以显式使用 bounded tick hook 辅助长链路运行。不要再使用根目录 `commands/*.toml` 伪装 Codex slash command。
 
 ## 安装或升级路径
 

package/README.md

@@ -234,12 +234,11 @@ my-project/
 │   └── rules/                ← Universal coding rules
 ├── .agents/
 │   └── skills/               ← Codex repo skills
-├── .codex/
-│   └── hooks.json             ← Codex hook bridge
+├── .codex/                    ← Codex config
 └── tests/
 ```
 
-`Harness/` holds all harness docs. Tool-discovery folders stay at root: `.claude/` for Claude Code, `.agents/skills/` for Codex repo skills, and `.codex/` for Codex config/hooks.
+`Harness/` holds all harness docs. Tool-discovery folders stay at root: `.claude/` for Claude Code, `.agents/skills/` for Codex repo skills, and `.codex/` for Codex config. Runtime hooks are absent by default; only `/wf-auto` may opt into a bounded tick hook.
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-harness-vibe-coding",
-  "version": "0.8.3",
+  "version": "0.8.5",
   "description": "Scaffold a 0-1 product harness for AI-assisted research, PRD, planning, architecture, build, test, and feedback loops",
   "type": "module",
   "bin": {
@@ -16,7 +16,6 @@
     "start": "node src/index.js",
     "build:version": "node scripts/build-version.mjs",
     "prepush": "node scripts/pre-push-check.mjs",
-    "prepush:install": "node scripts/pre-push-check.mjs --install",
     "test": "node --test tests/*.test.js",
     "test:smoke": "node --test tests/cli-smoke.test.js",
     "pack:smoke": "node --test tests/pack-smoke.test.js"

package/src/generator.js

@@ -67,11 +67,10 @@ const pkg = JSON.parse(fs.readFileSync(path.resolve(__dirname, '../package.json'
 const TEMPLATES_DIR = path.resolve(__dirname, '..', 'templates', 'common');
 const OPTIONAL_DIR = path.resolve(__dirname, '..', 'templates', 'optional');
 const OPTIONAL_CATALOG = path.join(OPTIONAL_DIR, 'catalog.json');
-const VALID_CONFLICT_POLICIES = new Set(['fail', 'skip', 'backup', 'overwrite']);
-const EMPTY_DIRS = [
-  '.claude/hooks',
-  'tests',
-];
+const VALID_CONFLICT_POLICIES = new Set(['fail', 'skip', 'backup', 'overwrite']);
+const EMPTY_DIRS = [
+  'tests',
+];
 
 export function harnessDest(file) {
   if (file === '.harness-version') return 'Harness/.harness-version';

package/templates/common/.claude/agents/context-master.md

@@ -11,8 +11,9 @@ You are a context analysis agent. You analyze the current conversation and proje
 
 Load first:
 
-- `Harness/MEMORY.md`
-- `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` when available
+- `Harness/MEMORY.md`
+- `Harness/MEMORY_PROTOCOL.md`
+- `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` when available
 - The current feature doc (if one exists)
 - `Harness/memory/` files for dedup checking
 

package/templates/common/.claude/agents/memory-master.md

@@ -11,8 +11,9 @@ You are a memory management agent for this project harness. You own durable memo
 
 Load first:
 
-- `Harness/MEMORY.md`
-- `Harness/memory/tool-usage-reflections.md`
+- `Harness/MEMORY.md`
+- `Harness/MEMORY_PROTOCOL.md`
+- `Harness/memory/tool-usage-reflections.md`
 - `Harness/memory/user-corrections-preferences.md`
 - `Harness/memory/agent-lessons-patterns.md`
 - `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` for current task context

package/templates/common/.claude/agents/tdd-guide.md

@@ -1,55 +1,81 @@
 ---
 name: tdd-guide
-description: Test-Driven Development specialist enforcing write-tests-first methodology. Use PROACTIVELY when writing new features, fixing bugs, or refactoring code. Ensures 80%+ test coverage.
+description: Test-Driven Development specialist enforcing AC-linked write-tests-first methodology. Use PROACTIVELY when writing new features, fixing bugs, refactoring code, or adding browser-visible behavior.
 tools: Read, Write, Edit, Bash, Grep, Glob
 model: sonnet
 ---
 
 # TDD Guide Agent
 
-Enforces TDD workflow. Load `Harness/TDD-GUIDE.md` first, then ECC testing rules for the project stack.
+Enforces acceptance-driven TDD. Load these before writing tests:
+
+1. `Harness/ACCEPTANCE_PROTOCOL.md`
+2. `Harness/HARNESS_BRIDGE.md`
+3. `Harness/AGENT_ISOLATION.md`
+4. `Harness/TDD-GUIDE.md`
+5. ECC testing rules for the project stack
+6. Current task `PLAN.md`
 
 ## Inputs Required
 
-- Task description and acceptance criteria from PLAN.md
-- Current test coverage status
-- Stack-specific testing tools (Jest, Pytest, Go test, etc.)
+- Task description, Mini PRD, and acceptance criteria from PLAN.md
+- UI/API/state contracts for affected behavior
+- Current test coverage status and configured threshold
+- Stack-specific testing tools such as Playwright, Jest, Vitest, Pytest, or Go test
 
 ## Workflow
 
-1. READ acceptance criteria
-2. WRITE failing test (RED)
-3. VERIFY test fails for expected reason
-4. Report test file path and expected failure to Implementer
+1. Read AC IDs, contracts, and verification commands.
+2. Choose the correct test layer for each AC.
+3. For browser-visible ACs, write Playwright/CDP or documented real-browser tests that perform real user actions.
+4. For API ACs, write request/response contract tests, including error cases.
+5. Run the target tests and verify RED for the expected product reason.
+6. Report test file paths, AC IDs, expected failures, and required evidence to the Implementer.
+
+Do NOT write implementation code. Only tests, fixtures, mocks, and test configuration.
+
+## Browser Acceptance Rules
 
-Do NOT write implementation code. Only tests.
+- Syntax checks, type checks, imports, shallow renders, and snapshots are not acceptance tests for browser-visible behavior.
+- Tests must interact through stable selectors such as `data-testid` or accessible roles.
+- Tests must click, type, submit, navigate, or otherwise exercise the real user path.
+- Tests must assert visible DOM plus relevant route/state/localStorage changes.
+- Frontend-backend flows must assert network URL, method, payload, response handling, and duplicate-request behavior when applicable.
+- Evidence must include screenshot, trace, video, log, or validation report path.
 
 ## Allowed Write Set
 
-- Test files only (`*.test.ts`, `*.test.tsx`, `test_*.py`, `*_test.go`, etc.)
-- Test fixtures and mocks
+- Test files only (`*.test.ts`, `*.test.tsx`, `*.spec.ts`, `test_*.py`, `*_test.go`, etc.)
+- Test fixtures, test data seeders, and mocks
 - Test configuration files
 
 ## Forbidden
 
 - Production/source code changes
+- Reading implementation code to reverse-engineer acceptance tests
+- Modifying PRD, acceptance criteria, UI contracts, or API contracts
 - Loosening existing test assertions
+- Replacing real UI acceptance with syntax-only assertions
 - Deleting existing tests without explicit approval
 
 ## Verification
 
-- Test MUST fail before handing off to Implementer
-- Test MUST cover acceptance criteria + error paths
-- Run `node Harness/scripts/validate-harness.mjs` after significant test additions
+- Test MUST fail before handing off to Implementer.
+- Test MUST cover AC IDs, happy path, error path, and relevant empty/loading/disabled states.
+- Browser-visible ACs MUST use real user actions through Playwright/CDP or documented real-browser validation.
+- Run the smallest target command for RED evidence, then report the broader verification command expected after implementation.
 
 ## Return Format
 
 ```text
 Agent: tdd-guide
 Task: <task-id>
+AC IDs covered: <AC-001, AC-002, ...>
 Tests written: <file paths>
-Coverage before: X%
-Expected coverage after: Y%
-Failing tests: <list of test names and expected failure reasons>
-Next: Dispatch Implementer to make tests pass
+Coverage before: <value or unknown>
+Expected coverage after: <value or threshold>
+Failing tests: <test names and expected failure reasons>
+UI evidence required: <screenshot/trace/video/log paths or N/A>
+Network assertions required: <URL/method/payload/response assertions or N/A>
+Next: Dispatch Implementer to make AC-linked tests pass without modifying truth files
 ```

package/templates/common/.claude/agents/test-writer.md

@@ -1,38 +1,52 @@
----
-name: test-writer
-description: Use to define or write failing tests and manual verification steps before implementation.
-tools: Read, Grep, Glob, Write, Edit, MultiEdit, Bash
-model: sonnet
----
-
-# Test Writer
-
-You are a test-first agent for this project harness.
-
-Load first:
-
-- current PRD or feature doc
-- `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` when available
-- `Harness/agent-workflow.md`
-
-Inputs you must receive:
-
-- acceptance criteria
-- test write set
-- forbidden scope
-- verification command or manual check target
-
-Rules:
-
-- Write only inside the declared test write set.
-- Do not write production code.
-- Prefer the smallest failing test that proves the required behavior.
-- If automation is not feasible yet, write a concrete manual check.
-- Do not weaken existing tests.
-
-Return:
-
-- changed test files or manual check
-- expected failure before implementation
-- verification command
-- risks or gaps
+---
+name: test-writer
+description: Use to define or write AC-linked failing tests and manual verification steps before implementation.
+tools: Read, Grep, Glob, Write, Edit, MultiEdit, Bash
+model: sonnet
+---
+
+# Test Writer
+
+You are a test-first agent for this project harness. You write tests from PRD-derived Acceptance Criteria, not from implementation code.
+
+Load first:
+
+- current PRD or feature doc
+- `Harness/ACCEPTANCE_PROTOCOL.md`
+- `Harness/HARNESS_BRIDGE.md` for UI/API/browser flows
+- `Harness/AGENT_ISOLATION.md`
+- `Harness/TDD-GUIDE.md`
+- `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md` when available
+- `Harness/agent-workflow.md`
+
+Inputs you must receive:
+
+- AC IDs and acceptance criteria
+- UI/API/state contracts, if behavior crosses those boundaries
+- test write set
+- forbidden scope
+- verification command or manual check target
+
+Rules:
+
+- Write only inside the declared test write set.
+- Do not write production code.
+- Do not read implementation code to reverse-engineer expected behavior.
+- Prefer the smallest failing test that proves the AC.
+- Include AC IDs in test names, comments, or the validation matrix.
+- For browser-visible behavior, syntax checks, imports, shallow renders, snapshots, and type/lint/build checks are not acceptance tests.
+- For browser-visible behavior, write a real user-path test: open the page, click/type/select/submit through stable selectors, then assert visible DOM plus route/state/storage changes.
+- For frontend-backend behavior, assert network URL, method, payload, response handling, and duplicate-request behavior with Playwright request capture, CDP, or Harness Bridge.
+- If automation is not feasible yet, write a concrete manual browser check with selectors, user actions, expected DOM/state/API evidence, and screenshot/trace requirements.
+- Do not weaken existing tests.
+- Do not modify PRD, acceptance criteria, UI contracts, or API contracts.
+
+Return:
+
+- AC IDs covered
+- changed test files or manual check
+- expected RED failure before implementation
+- verification command
+- required evidence paths: screenshot, trace, video, log, or report
+- network assertions, if applicable
+- risks or gaps

package/templates/common/.claude/commands/wf-help.md

@@ -0,0 +1,21 @@
+# /wf-help
+
+Return this help table directly. Do not invoke a skill, do not start WF mode,
+do not dispatch agents, and do not edit files.
+
+| Command | Type | Usage | Purpose |
+| --- | --- | --- | --- |
+| `/wf-help` | direct command | `/wf-help` | Show this command table. |
+| `/wf <task>` | workflow skill | `/wf fix failing login flow` | Standard acceptance-driven workflow for long, uncertain, multi-file, browser/API, or recovery work. |
+| `/wf-max <task>` | workflow skill | `/wf-max refactor auth module` | Maximum-parallelism workflow with CEO -> Manager -> Worker dispatch, write-set coloring, independent review, and validation. |
+| `/wf-auto` | workflow skill | `/wf-auto` | Perpetual auto-optimization loop using bounded cycles, 8-angle exhaustion, evidence ledger, and optional wf-auto-only tick hook. |
+| `/wf-auto-spark` | workflow skill | `/wf-auto-spark` | Perpetual inspiration mode with roadmap anchoring and external spark search. |
+| `/wf-review <focus>` | workflow skill | `/wf-review security and test coverage` | Cross-model peer review through the other CLI; use for second opinions and risk checks. |
+| `/wf-learn` | workflow skill | `/wf-learn` | Force context-master -> memory-master learning cycle after repeated failures or closeout. |
+| `/wf-browser <task>` | optional workflow skill | `/wf-browser verify checkout flow` | Browser automation/E2E workflow with real UI interaction, screenshots, traces, and CDP/network evidence when installed. |
+| `/wf-readme <task>` | workflow skill | `/wf-readme polish quickstart` | Preserve, merge, or improve README docs without trampling existing project documentation. |
+| `/wf-update` | workflow skill | `/wf-update` | Check/apply Harness scaffold updates with safe file classification and conflict handling. |
+| `/wf-remove` | workflow skill | `/wf-remove` | Safely remove Harness files while preserving project/user data unless explicitly purged. |
+
+Source of truth: `Harness/README.md#Skill Commands` plus installed skills under
+`.claude/skills/`.

package/templates/common/.claude/rules/ecc/common.md

@@ -25,7 +25,7 @@ alwaysApply: true
 - Use `Harness/subagents.md` before orchestrating multiple agents.
 - Use `Harness/context-loading.md` before spawning.
 - Use `Harness/dispatch.md` before parallel or multi-agent work.
-- Use `Harness/extension.md` before adding stack-specific agents, skills, rules, or hooks.
+- Use `Harness/extension.md` before adding stack-specific agents, skills, or rules.
 - Every subagent needs role, task, read boundary, write boundary, and return format.
 - Writing agents must run serially unless write sets are disjoint.
 - If the runtime cannot spawn subagents, emulate the same role pack in a separate bounded pass.

package/templates/common/.claude/settings.json

@@ -1,90 +1,33 @@
-{
-  "$schema": "https://json.schemastore.org/claude-code-settings.json",
-  "permissions": {
-    "allow": [
-      "Bash(git *)",
-      "Bash(npm *)",
-      "Bash(npx *)",
-      "Bash(python *)",
-      "Bash(pytest *)",
-      "Bash(pip *)",
-      "Bash(go *)",
-      "Bash(cargo *)",
-      "Bash(node *)",
-      "Read",
-      "Glob",
-      "Grep",
-      "WebFetch",
-      "WebSearch"
-    ],
-    "deny": [
-      "EnterPlanMode",
-      "Bash(rm -rf *)",
-      "Bash(sudo *)",
-      "Bash(curl *)",
-      "Bash(wget *)",
-      "Bash(> *)",
-      "Read(.env*)",
-      "Read(**/secrets/**)",
-      "Read(**/*.key)",
-      "Read(**/*.pem)"
-    ]
-  },
-  "hooks": {
-    "SessionStart": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node Harness/scripts/wf-mode-hook.mjs"
-          }
-        ]
-      }
-    ],
-    "UserPromptSubmit": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node Harness/scripts/wf-mode-hook.mjs"
-          }
-        ]
-      }
-    ],
-    "PreToolUse": [
-      {
-        "matcher": "Edit|Write|MultiEdit|Bash",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node Harness/scripts/wf-mode-hook.mjs"
-          }
-        ]
-      }
-    ],
-    "PostToolUse": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node Harness/scripts/wf-mode-hook.mjs"
-          }
-        ]
-      }
-    ],
-    "Stop": [
-      {
-        "matcher": "",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "node Harness/scripts/wf-mode-hook.mjs"
-          }
-        ]
-      }
-    ]
-  }
-}
+{
+  "$schema": "https://json.schemastore.org/claude-code-settings.json",
+  "permissions": {
+    "allow": [
+      "Bash(git *)",
+      "Bash(npm *)",
+      "Bash(npx *)",
+      "Bash(python *)",
+      "Bash(pytest *)",
+      "Bash(pip *)",
+      "Bash(go *)",
+      "Bash(cargo *)",
+      "Bash(node *)",
+      "Read",
+      "Glob",
+      "Grep",
+      "WebFetch",
+      "WebSearch"
+    ],
+    "deny": [
+      "EnterPlanMode",
+      "Bash(rm -rf *)",
+      "Bash(sudo *)",
+      "Bash(curl *)",
+      "Bash(wget *)",
+      "Bash(> *)",
+      "Read(.env*)",
+      "Read(**/secrets/**)",
+      "Read(**/*.key)",
+      "Read(**/*.pem)"
+    ]
+  }
+}

package/templates/common/.claude/skills/tdd/SKILL.md

@@ -14,17 +14,24 @@ Thin tool adapter. Authoritative guide: `Harness/TDD-GUIDE.md`.
 
 ## Load
 
-1. `Harness/TDD-GUIDE.md`
-2. ECC stack-specific testing rules (e.g., `typescript/testing.md`, `python/testing.md`)
-3. Current task `PLAN.md`
+1. `Harness/ACCEPTANCE_PROTOCOL.md`
+2. `Harness/HARNESS_BRIDGE.md`
+3. `Harness/AGENT_ISOLATION.md`
+4. `Harness/TDD-GUIDE.md`
+5. ECC stack-specific testing rules (for example `typescript/testing.md`, `python/testing.md`)
+6. Current task `PLAN.md`
 
 ## Rules
 
-1. **RED first**: Write failing test before ANY implementation code.
-2. **GREEN minimal**: Write only enough code to pass the test.
-3. **REFACTOR safe**: Improve code while keeping all tests green.
-4. **Coverage gate**: ≥80% before marking task complete.
-5. **Test names**: Describe behavior — `test('returns X when Y')`.
-6. **AAA structure**: Arrange → Act → Assert.
-7. **Error paths**: Test failure cases, not just happy path.
-8. **WF-MAX**: Test Writer agent dispatched BEFORE Implementer in every wave.
+1. **AC first**: Tests are derived from PRD acceptance criteria and must reference AC IDs.
+2. **RED first**: Write failing tests before ANY implementation code.
+3. **UI means real user path**: Browser-visible behavior requires Playwright/CDP or documented real-browser clicks, typing, navigation, and visible assertions.
+4. **No syntax-only acceptance**: Typecheck, lint, build, import tests, shallow renders, and snapshots cannot satisfy browser-visible ACs by themselves.
+5. **Network-aware**: Frontend-backend ACs require URL, method, payload, response, and duplicate-request assertions when applicable.
+6. **GREEN minimal**: Write only enough implementation to pass the AC-linked tests.
+7. **REFACTOR safe**: Improve code while keeping all tests green.
+8. **Coverage gate**: Meet the configured project coverage threshold before marking task complete.
+9. **AAA structure**: Arrange -> Act -> Assert.
+10. **Role isolation**: Test Writer must not reverse-engineer tests from implementation code. Implementer must not modify PRD, AC, UI contract, or API contract except through Change Request.
+11. **Evidence required**: Record RED, GREEN, full-check output, and for UI flows screenshot/trace/video/log evidence plus an AC-by-AC result matrix.
+12. **WF-MAX**: Acceptance/Test Writer wave completes before any Implementer wave starts.

package/templates/common/.claude/skills/wf-auto/SKILL.md

@@ -7,7 +7,7 @@ description: Perpetual auto-optimization mode. Never stops — continuously impr
 
 ## Load (authoritative specs)
 
-- `Harness/WF-AUTO.md` — full spec: perpetual loop, state machine, 8-angle exhaustion gate, cross-model oracle, spark candidate provider, Value Gate scoring, evidence ledger, Intent Checkpoints, anti-patterns, safety controls
+- `Harness/WF-AUTO.md` — full spec: perpetual loop, state machine, 8-angle exhaustion gate, cross-model oracle, spark candidate provider, Value Gate scoring, evidence ledger, Intent Checkpoints, anti-patterns, safety controls
 - `Harness/subagents.md` — agent roster, controller role, efficiency ladder
 - `Harness/dispatch.md` — handoff format, File claim, Concurrency group fields
 - `Harness/agent-workflow.md` — build/review/test loop, cohesion rule, completion gate

package/templates/common/.claude/skills/wf-remove/SKILL.md

@@ -1,14 +1,17 @@
----
-name: wf-remove
-description: Use for /wf-remove in Claude Code, $wf-remove or /skills wf-remove in Codex, or any request to uninstall Harness safely.
----
-
-# WF Remove Adapter
-
+---
+name: wf-remove
+description: Use for /wf-remove in Claude Code, $wf-remove or /skills wf-remove in Codex, or any request to uninstall Harness safely.
+---
+
+# WF Remove Adapter
+
 ## Invocation
 
 - Claude Code: use `/wf-remove` or select the `wf-remove` skill.
 - Codex CLI or IDE: use `$wf-remove` or `/skills` then choose `wf-remove`.
+- User-facing removal is the slash/skill command. The Node commands below are
+  agent-internal execution steps; do not ask the user to copy/paste them unless
+  the agent has no shell/tool access.
 
 ## Load
 
@@ -17,21 +20,31 @@ description: Use for /wf-remove in Claude Code, $wf-remove or /skills wf-remove
 
 ## Flow
 
-1. Run `node Harness/scripts/wf-remove.mjs --json` for the machine-readable
-   plan.
-2. Auto-remove only SAFE files that still match stored checksums.
+1. On plain `/wf-remove`, run `node Harness/scripts/wf-remove.mjs --json` for
+   the machine-readable plan, then run the safe default apply command yourself.
+2. Auto-remove only SAFE files that still match stored checksums or exact
+   built-in Harness discovery files recognized by the script.
 3. Ask the user before every MODIFIED or uncertain file.
 4. Preserve USER DATA by default. For an explicit thorough uninstall, use
    `--purge-user-data` (alias `--purge`); add `--keep-tasks` when the user wants task records
    retained while project-fact Harness docs are removed.
-5. Run the script, not manual deletes:
+5. Run the script yourself, not manual deletes and not user-side command copy:
    - safe default: `node Harness/scripts/wf-remove.mjs --apply --yes`
    - thorough but keep tasks: `node Harness/scripts/wf-remove.mjs --apply --yes --purge-user-data --keep-tasks`
    - exact modified decisions: add `--delete-modified <path>` for each
      user-approved MODIFIED file.
+6. After apply, verify residual discovery folders:
+   - `.claude/agents`
+   - `.claude/skills`
+   - `.claude/commands`
+   - `.claude/rules`
+   - `.agents/skills`
+   - `.codex`
+   Built-in Harness files in these locations should be gone. Custom user skills
+   or user-owned files may remain and must be reported, not blindly deleted.
 
 ## Return
 
 Report SAFE removals, MODIFIED keep/delete decisions, preserved USER DATA,
-PURGE removals, directory cleanup, CLAUDE/AGENTS status, `.harness-version`
-status, and `git status` guidance.
+PURGE removals, directory cleanup, `.claude` / `.agents` / `.codex` residual
+status, `.harness-version` status, and `git status` guidance.

package/templates/common/.codex/config.toml

@@ -1,2 +0,0 @@
-[features]
-hooks = true