create-harness-vibe-coding 0.8.3 → 0.8.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README-CN.md +2 -2
- package/README.md +2 -3
- package/package.json +1 -2
- package/src/generator.js +4 -5
- package/templates/common/.claude/agents/context-master.md +3 -2
- package/templates/common/.claude/agents/memory-master.md +3 -2
- package/templates/common/.claude/agents/tdd-guide.md +45 -19
- package/templates/common/.claude/agents/test-writer.md +52 -38
- package/templates/common/.claude/commands/wf-help.md +21 -0
- package/templates/common/.claude/rules/ecc/common.md +1 -1
- package/templates/common/.claude/settings.json +33 -90
- package/templates/common/.claude/skills/tdd/SKILL.md +18 -11
- package/templates/common/.claude/skills/wf-auto/SKILL.md +1 -1
- package/templates/common/.codex/config.toml +0 -2
- package/templates/common/.harness-version +55 -37
- package/templates/common/AGENTS.md +7 -6
- package/templates/common/CLAUDE.md +3 -4
- package/templates/common/Harness/ACCEPTANCE_PROTOCOL.md +170 -0
- package/templates/common/Harness/AGENT_ISOLATION.md +73 -0
- package/templates/common/Harness/DEBUG_PROTOCOL.md +64 -0
- package/templates/common/Harness/ECC-GUIDE.md +4 -4
- package/templates/common/Harness/HARNESS_BRIDGE.md +128 -0
- package/templates/common/Harness/MEMORY_PROTOCOL.md +114 -0
- package/templates/common/Harness/README.md +31 -16
- package/templates/common/Harness/TDD-GUIDE.md +138 -56
- package/templates/common/Harness/WF-AUTO.md +77 -16
- package/templates/common/Harness/WF-MAX.md +81 -22
- package/templates/common/Harness/WF.md +38 -18
- package/templates/common/Harness/agent-workflow.md +47 -22
- package/templates/common/Harness/context-loading.md +33 -32
- package/templates/common/Harness/dispatch.md +10 -4
- package/templates/common/Harness/extension.md +3 -3
- package/templates/common/Harness/lifecycle.md +19 -13
- package/templates/common/Harness/research/PRD.md +18 -9
- package/templates/common/Harness/subagents.md +41 -14
- package/templates/common/Harness/tasks/_template/NAMING.md +2 -2
- package/templates/common/Harness/tasks/_template/PLAN.md +53 -11
- package/templates/common/Harness/templates/ACCEPTANCE.template.md +20 -0
- package/templates/common/Harness/templates/API_CONTRACT.template.md +40 -0
- package/templates/common/Harness/templates/PLAYWRIGHT_SPEC.template.ts +21 -0
- package/templates/common/Harness/templates/PRD.template.md +45 -0
- package/templates/common/Harness/templates/TEST_PLAN.template.md +14 -0
- package/templates/common/Harness/templates/UI_CONTRACT.template.md +11 -0
- package/templates/common/Harness/templates/VALIDATION_REPORT.template.md +20 -0
- package/templates/common/MEMORY.md +14 -3
- package/templates/common/README.md +1 -1
- package/templates/common/SETUP.md +24 -20
- package/templates/common/scripts/validate-harness.mjs +134 -41
- package/templates/common/scripts/wf-remove.mjs +6 -2
- package/templates/optional/skills/browser-e2e/Harness/workflows/browser-e2e.md +11 -3
- package/templates/optional/skills/ts-react-frontend/Harness/workflows/ts-react-frontend.md +1 -1
- package/templates/common/.codex/hooks.json +0 -59
- package/templates/common/scripts/wf-mode-hook.mjs +0 -642
- package/templates/common/scripts/wf-statusline.ps1 +0 -62
- package/templates/common/scripts/wf-statusline.sh +0 -67
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Extension Contract
|
|
2
2
|
|
|
3
|
-
Purpose: keep stack-specific agents, skills,
|
|
3
|
+
Purpose: keep stack-specific agents, skills, and rules compatible with this harness.
|
|
4
4
|
|
|
5
5
|
Use during setup whenever adding assets from ECC, SuperClaude, toolboxes, or local project conventions.
|
|
6
6
|
|
|
@@ -8,9 +8,9 @@ Use during setup whenever adding assets from ECC, SuperClaude, toolboxes, or loc
|
|
|
8
8
|
|
|
9
9
|
Extensions must preserve project and harness ownership boundaries.
|
|
10
10
|
|
|
11
|
-
- Preserve existing `.claude/`, `CLAUDE.md`, `AGENTS.md`, `.gitignore`, `Harness/README.md`, `Harness/workflows/*.md`, settings,
|
|
11
|
+
- Preserve existing `.claude/`, `CLAUDE.md`, `AGENTS.md`, `.gitignore`, `Harness/README.md`, `Harness/workflows/*.md`, settings, and local rules unless the user explicitly requests an overwrite.
|
|
12
12
|
- Treat existing project config as project fact. Read it before adding assets, then adapt new assets to the project instead of replacing the project.
|
|
13
|
-
- Register added agents, skills, workflows,
|
|
13
|
+
- Register added agents, skills, workflows, and rules in `Harness/MEMORY.md` and this docs router where applicable.
|
|
14
14
|
- Added assets may extend `.claude/skills/`, `.claude/agents/`, `.claude/rules/`, or `Harness/workflows/`, but they must not replace core harness docs.
|
|
15
15
|
- Core harness docs are `Harness/README.md`, `Harness/PROGRESS.md`, `Harness/subagents.md`, `Harness/context-loading.md`, `Harness/dispatch.md`, `Harness/agent-workflow.md`, and this file.
|
|
16
16
|
- If an optional workflow needs a new command or tool, document the command and fallback in `Harness/workflows/<name>.md` instead of changing core harness behavior.
|
|
@@ -7,21 +7,26 @@ Use when starting a new product, clarifying a vague idea, or deciding the next p
|
|
|
7
7
|
| Phase | Input | Output | Gate |
|
|
8
8
|
| --- | --- | --- | --- |
|
|
9
9
|
| Idea | user intent | problem, target user, non-goals | unclear points asked or assumptions recorded |
|
|
10
|
-
| Research | problem and constraints | `research/research-results.md` | `research/README.md` followed; at least 3 references or explicit reason not possible |
|
|
11
|
-
| PRD | research decision | `research/PRD.md` |
|
|
12
|
-
|
|
|
13
|
-
|
|
|
14
|
-
|
|
|
15
|
-
|
|
|
16
|
-
|
|
|
10
|
+
| Research | problem and constraints | `research/research-results.md` | `research/README.md` followed; at least 3 references or explicit reason not possible |
|
|
11
|
+
| PRD | research decision | `research/PRD.md` or task Mini PRD | goal, scope, non-scope, user flow, and verification commands are explicit |
|
|
12
|
+
| Acceptance | PRD | AC IDs in `ACCEPTANCE.md` section, feature doc, or task PLAN | every user-visible behavior has Given/When/Then and evidence method |
|
|
13
|
+
| Contract | acceptance criteria | UI/API/state contract tables | UI selectors, API payloads, state changes, and negative assertions are testable |
|
|
14
|
+
| Test Plan | contracts | `TEST_PLAN.md` section or task PLAN verification matrix | tests map to AC IDs before implementation starts |
|
|
15
|
+
| Architecture | PRD and contracts | `Harness/architecture.md` | boundaries and first ports are defined |
|
|
16
|
+
| Plan | PRD, AC, contracts, architecture | `Harness/tasks/<task-id>/PLAN.md`, optional `Harness/dispatch.md` | tasks have owners, write sets, forbidden truth files, and verification |
|
|
17
|
+
| Build | plan and tests | minimal vertical slice | implementation satisfies AC IDs without modifying truth files |
|
|
18
|
+
| Independent Validation | running slice | acceptance result matrix, screenshots/traces/logs | validator is not implementer; no unresolved critical/high findings |
|
|
19
|
+
| Debug | failed AC evidence | root-cause handoff and smallest fix | failing layer identified before edits |
|
|
20
|
+
| Memory | verified or repeated failure | concise memory entry or no-op rationale | durable lessons recorded without secrets |
|
|
17
21
|
|
|
18
22
|
## Operating Rules
|
|
19
23
|
|
|
20
24
|
- Move one phase at a time unless the user explicitly asks for a fast lane.
|
|
21
|
-
- Start coding only after PRD and minimum architecture gates pass.
|
|
22
|
-
- Prefer one thin vertical slice over broad scaffolding.
|
|
23
|
-
- If feedback changes scope, update PRD before implementation.
|
|
24
|
-
- If implementation reveals a boundary problem, update architecture or ports before continuing.
|
|
25
|
+
- Start coding only after PRD-GATE, AC-GATE, CONTRACT-GATE, TEST-GATE, and minimum architecture gates pass.
|
|
26
|
+
- Prefer one thin vertical slice over broad scaffolding.
|
|
27
|
+
- If feedback changes scope, update PRD and acceptance criteria before implementation.
|
|
28
|
+
- If implementation reveals a boundary problem, update architecture or ports before continuing.
|
|
29
|
+
- If implementation reveals incorrect acceptance criteria or contracts, stop and use Change Request from `ACCEPTANCE_PROTOCOL.md`; do not let the implementer rewrite truth files directly.
|
|
25
30
|
|
|
26
31
|
## Fast Lane
|
|
27
32
|
|
|
@@ -29,5 +34,6 @@ Small edits may skip full lifecycle when all are true:
|
|
|
29
34
|
|
|
30
35
|
- user intent is clear
|
|
31
36
|
- one file or one narrow behavior
|
|
32
|
-
- no architecture, permission, or public API change
|
|
33
|
-
- one verification command or one manual check is enough
|
|
37
|
+
- no architecture, permission, or public API change
|
|
38
|
+
- one verification command or one manual check is enough
|
|
39
|
+
- Mini PRD, AC IDs, and verification evidence still fit inside the task PLAN
|
|
@@ -42,11 +42,19 @@
|
|
|
42
42
|
| {{USER_ROLE_1}} | {{SCENARIO}} | {{FREQUENCY}} | {{PAIN}} |
|
|
43
43
|
| {{USER_ROLE_2}} | {{SCENARIO}} | {{FREQUENCY}} | {{PAIN}} |
|
|
44
44
|
|
|
45
|
-
## 5. Acceptance Criteria
|
|
46
|
-
|
|
47
|
-
- [ ] {{
|
|
48
|
-
- [ ] {{
|
|
49
|
-
- [ ] {{
|
|
45
|
+
## 5. Acceptance Criteria
|
|
46
|
+
|
|
47
|
+
- [ ] AC-001: {{GIVEN_WHEN_THEN_SUMMARY_1}}
|
|
48
|
+
- [ ] AC-002: {{GIVEN_WHEN_THEN_SUMMARY_2}}
|
|
49
|
+
- [ ] AC-003: {{GIVEN_WHEN_THEN_SUMMARY_3}}
|
|
50
|
+
|
|
51
|
+
## 5a. UI/API Contract Requirements
|
|
52
|
+
|
|
53
|
+
| Surface | Requirement | AC IDs |
|
|
54
|
+
| --- | --- | --- |
|
|
55
|
+
| UI | Critical controls have `data-testid` or stable accessible roles. | AC-001 |
|
|
56
|
+
| API | Endpoint method, URL, payload, success, and failure behavior are explicit. | AC-002 |
|
|
57
|
+
| State | URL, DOM, store, localStorage, database, or side effects are observable. | AC-003 |
|
|
50
58
|
|
|
51
59
|
## 6. Non-Functional Requirements
|
|
52
60
|
|
|
@@ -59,7 +67,8 @@
|
|
|
59
67
|
|
|
60
68
|
## Fill Completion Standard
|
|
61
69
|
|
|
62
|
-
- [ ] MVP and Non-goals are project facts; no `{{...}}` placeholders remain.
|
|
63
|
-
- [ ] Decision priorities guide tradeoffs, not generic platitudes.
|
|
64
|
-
- [ ] Every acceptance criterion is verifiable by test, command, or manual step.
|
|
65
|
-
- [ ]
|
|
70
|
+
- [ ] MVP and Non-goals are project facts; no `{{...}}` placeholders remain.
|
|
71
|
+
- [ ] Decision priorities guide tradeoffs, not generic platitudes.
|
|
72
|
+
- [ ] Every acceptance criterion has an AC ID and is verifiable by test, command, or manual step.
|
|
73
|
+
- [ ] UI/API contracts exist for any UI/API acceptance criterion.
|
|
74
|
+
- [ ] If implementation diverges from the PRD, update this file before changing code.
|
|
@@ -4,7 +4,12 @@ Purpose: coordinate subagents for speed without losing control of scope, evidenc
|
|
|
4
4
|
|
|
5
5
|
Use this file when work needs multiple roles, parallel reading, independent review, broad context, repeated failures, or `/wf`.
|
|
6
6
|
|
|
7
|
-
project files are the only durable communication channel; chat/subagent transcript state is non-authoritative. Important assumptions, decisions, blockers, evidence, and handoffs must be written to `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md`, the current feature doc, `Harness/MEMORY.md`, or `Harness/memory/*` as appropriate.
|
|
7
|
+
project files are the only durable communication channel; chat/subagent transcript state is non-authoritative. Important assumptions, decisions, blockers, evidence, and handoffs must be written to `Harness/tasks/<task-id>/PROGRESS.md` and `Harness/tasks/<task-id>/PLAN.md`, the current feature doc, `Harness/MEMORY.md`, or `Harness/memory/*` as appropriate.
|
|
8
|
+
|
|
9
|
+
Subagent work is acceptance-driven. Use [AGENT_ISOLATION.md](AGENT_ISOLATION.md)
|
|
10
|
+
for role/context isolation and [ACCEPTANCE_PROTOCOL.md](ACCEPTANCE_PROTOCOL.md)
|
|
11
|
+
for PRD-GATE, AC-GATE, CONTRACT-GATE, TEST-GATE, VALIDATION-GATE, and
|
|
12
|
+
REVIEW-GATE.
|
|
8
13
|
|
|
9
14
|
## Source Attribution
|
|
10
15
|
|
|
@@ -49,8 +54,26 @@ Use the installed roster under `.claude/agents/` before inventing ad hoc roles.
|
|
|
49
54
|
| `reviewer` | spec compliance, code quality, maintainability, security, missing tests |
|
|
50
55
|
| `debugger` | reproduced failures, root cause isolation, smallest safe fix |
|
|
51
56
|
| `verifier` | command execution, real browser/API checks, final evidence |
|
|
52
|
-
| `memory-master` | write/consolidate memory entries, dedup, cross-project extraction; dispatched on repeated failures, user corrections, and WF closeout |
|
|
53
|
-
| `context-master` | analyze context usage, recommend compression at ~85% window, extract durable session knowledge during closeout |
|
|
57
|
+
| `memory-master` | write/consolidate memory entries, dedup, cross-project extraction; dispatched on repeated failures, user corrections, and WF closeout |
|
|
58
|
+
| `context-master` | analyze context usage, recommend compression at ~85% window, extract durable session knowledge during closeout |
|
|
59
|
+
|
|
60
|
+
## Acceptance Role Passes
|
|
61
|
+
|
|
62
|
+
These are role passes that may be handled by the built-in roster above or by
|
|
63
|
+
project-specific agents. They define context boundaries even when no dedicated
|
|
64
|
+
agent file exists.
|
|
65
|
+
|
|
66
|
+
| Role Pass | Default Agent | Reads | Writes |
|
|
67
|
+
| --- | --- | --- | --- |
|
|
68
|
+
| PRD Planner | `planner` | user request, memory, research | Mini PRD/task PLAN only |
|
|
69
|
+
| Acceptance Agent | `planner` or `test-writer` | PRD, user scenarios, UI requirements | AC section only |
|
|
70
|
+
| Contract Agent | `architect` or `test-writer` | PRD, AC, API/schema/UI requirements | UI/API/state contract section only |
|
|
71
|
+
| Test Architect | `test-writer` | AC, contracts, test utilities | tests or test plan only |
|
|
72
|
+
| Implementer | `implementer` | PRD, AC, contracts, tests, relevant code | assigned implementation write set only |
|
|
73
|
+
| Independent Validator | `verifier` | PRD, AC, contracts, running app/API, commands | validation report/evidence only |
|
|
74
|
+
| Debugger | `debugger` | failed AC, logs, trace, screenshot, diff | smallest assigned fix set |
|
|
75
|
+
|
|
76
|
+
Hard rule: implementer may not be the independent validator for the same AC ID.
|
|
54
77
|
|
|
55
78
|
## WF Default Fan-Out
|
|
56
79
|
|
|
@@ -83,7 +106,7 @@ Choose the cheapest coordination level that is safe.
|
|
|
83
106
|
| Solo pass | one file, low risk, clear intent | no subagent |
|
|
84
107
|
| Single reviewer | small change with meaningful risk | implement, then reviewer |
|
|
85
108
|
| Parallel read-only | broad reading, research, architecture, multiple independent failures | 2-3 read-only agents |
|
|
86
|
-
| Serial build lane | normal feature or fix | test-writer -> implementer ->
|
|
109
|
+
| Serial build lane | normal feature or fix | acceptance/contract -> test-writer -> implementer -> independent validator -> reviewers |
|
|
87
110
|
| Isolated lanes | disjoint write sets or competing approaches | separate worktrees, then review and merge |
|
|
88
111
|
| Max parallelism | 5+ disjoint files, fan-out benefit > coordination cost | /wf max: write-set coloring -> wave dispatch -> parallel review |
|
|
89
112
|
|
|
@@ -96,12 +119,12 @@ controller intake
|
|
|
96
119
|
-> parallel planner/researcher/docs-researcher/architect subagents
|
|
97
120
|
-> controller synthesis
|
|
98
121
|
-> second plan with dependencies and write sets
|
|
99
|
-
-> test-writer
|
|
100
|
-
-> implementer
|
|
101
|
-
->
|
|
102
|
-
->
|
|
103
|
-
->
|
|
104
|
-
-> if failed: debugger/fixer -> review -> verify -> loop
|
|
122
|
+
-> acceptance/contract/test-writer
|
|
123
|
+
-> implementer
|
|
124
|
+
-> independent validator
|
|
125
|
+
-> spec reviewer
|
|
126
|
+
-> code/architecture reviewer
|
|
127
|
+
-> if failed: debugger/fixer -> review -> verify -> loop
|
|
105
128
|
-> close with evidence
|
|
106
129
|
```
|
|
107
130
|
|
|
@@ -138,8 +161,11 @@ Use the canonical dispatch input and handoff format in `Harness/dispatch.md`. Ev
|
|
|
138
161
|
|
|
139
162
|
Implementation is not complete until both gates pass:
|
|
140
163
|
|
|
141
|
-
1. **Spec review**: confirms the result matches the user request, PRD, feature doc, acceptance criteria, and non-goals. Extra features are failures.
|
|
142
|
-
2. **Code-quality review**: checks correctness, maintainability, architecture, tests, security, and integration risk.
|
|
164
|
+
1. **Spec review**: confirms the result matches the user request, PRD, feature doc, acceptance criteria, contracts, and non-goals. Extra features are failures.
|
|
165
|
+
2. **Code-quality review**: checks correctness, maintainability, architecture, tests, security, and integration risk.
|
|
166
|
+
|
|
167
|
+
Validation is separate from review. Validator must produce an AC-by-AC result
|
|
168
|
+
matrix from running behavior and evidence, not from the implementer's summary.
|
|
143
169
|
|
|
144
170
|
If either reviewer finds issues, the implementer or debugger fixes them and the same gate runs again. Do not move to verifier with open critical/high findings.
|
|
145
171
|
|
|
@@ -173,8 +199,9 @@ Findings rejected:
|
|
|
173
199
|
Conflicts:
|
|
174
200
|
Decisions:
|
|
175
201
|
Next write set:
|
|
176
|
-
Verification path:
|
|
177
|
-
|
|
202
|
+
Verification path:
|
|
203
|
+
Acceptance/contract traceability:
|
|
204
|
+
Residual risk:
|
|
178
205
|
```
|
|
179
206
|
|
|
180
207
|
Only the synthesis and named files enter main context. Do not replay full subagent conversations.
|
|
@@ -15,7 +15,7 @@ All task directories MUST have the `task-` prefix. This distinguishes tasks from
|
|
|
15
15
|
| `task-` prefix required | `task-fix-ceo-inheritance` | `fix-ceo-inheritance` |
|
|
16
16
|
| kebab-case (lowercase, hyphens) | `task-fix-ceo-inheritance` | `task-fix_ceo_inheritance` |
|
|
17
17
|
| Verb-first after prefix | `task-add-goal-persistence` | `task-goal-persistence-add` |
|
|
18
|
-
| 2-5 words after prefix,
|
|
18
|
+
| 2-5 words after prefix, <=46 total chars | `task-refactor-role-contract` | `task-refactor-the-entire-role-contract-model` |
|
|
19
19
|
| No abbreviations unless domain-standard | `task-fix-auth-middleware` | `task-fx-ath-mdw` |
|
|
20
20
|
|
|
21
21
|
## Reserved Names
|
|
@@ -28,7 +28,7 @@ All task directories MUST have the `task-` prefix. This distinguishes tasks from
|
|
|
28
28
|
## Task ID Lifecycle
|
|
29
29
|
|
|
30
30
|
1. Created by copying `_template/` → `task-<verb>-<noun>/`
|
|
31
|
-
2. Directory name IS the task ID
|
|
31
|
+
2. Directory name IS the task ID - used in `Harness/PROGRESS.md` and dispatch packets
|
|
32
32
|
3. Directory archived (not renamed) when task completes
|
|
33
33
|
4. Task ID is immutable after creation (changing it breaks cross-references)
|
|
34
34
|
5. Existing tasks without `task-` prefix are grandfathered — rename is optional but recommended
|
|
@@ -2,19 +2,56 @@
|
|
|
2
2
|
|
|
3
3
|
Task-level implementation plan and evidence. Main agent writes after second planning; implementer reads before coding.
|
|
4
4
|
|
|
5
|
-
## Goal
|
|
6
|
-
|
|
7
|
-
##
|
|
8
|
-
|
|
9
|
-
|
|
5
|
+
## Goal
|
|
6
|
+
|
|
7
|
+
## Mini PRD
|
|
8
|
+
|
|
9
|
+
Scope:
|
|
10
|
+
-
|
|
11
|
+
|
|
12
|
+
Non-scope:
|
|
13
|
+
-
|
|
14
|
+
|
|
15
|
+
User flow:
|
|
16
|
+
1.
|
|
17
|
+
|
|
18
|
+
UI elements:
|
|
19
|
+
-
|
|
20
|
+
|
|
21
|
+
API behavior:
|
|
22
|
+
-
|
|
23
|
+
|
|
24
|
+
## Acceptance Criteria
|
|
25
|
+
|
|
26
|
+
| AC ID | Given / When / Then | Verification | Evidence |
|
|
27
|
+
|-------|----------------------|--------------|----------|
|
|
28
|
+
| AC-001 | | | |
|
|
29
|
+
|
|
30
|
+
## UI Contract
|
|
31
|
+
|
|
32
|
+
| Element | Selector / Role | States | AC IDs |
|
|
33
|
+
|---------|-----------------|--------|--------|
|
|
34
|
+
|
|
35
|
+
## API Contract
|
|
36
|
+
|
|
37
|
+
| Endpoint | Method | Payload / Response | AC IDs |
|
|
38
|
+
|----------|--------|--------------------|--------|
|
|
39
|
+
|
|
40
|
+
## Test Plan
|
|
41
|
+
|
|
42
|
+
For browser-visible ACs, include real user actions and evidence. Syntax-only checks, import tests, shallow renders, typecheck, lint, and build success are not acceptance evidence for UI behavior.
|
|
43
|
+
|
|
44
|
+
| AC ID | Test Level | User Action / API Request | Command / File | Evidence | Status |
|
|
45
|
+
|-------|------------|---------------------------|----------------|----------|--------|
|
|
10
46
|
|
|
11
47
|
## Scope
|
|
12
48
|
|
|
13
49
|
Allowed write set:
|
|
14
50
|
-
|
|
15
51
|
|
|
16
|
-
Forbidden:
|
|
17
|
-
-
|
|
52
|
+
Forbidden:
|
|
53
|
+
-
|
|
54
|
+
- PRD / acceptance criteria / UI contract / API contract / test plan / validation report unless Change Request is recorded
|
|
18
55
|
|
|
19
56
|
## Loaded Context
|
|
20
57
|
|
|
@@ -34,7 +71,12 @@ Conflicts:
|
|
|
34
71
|
Decisions:
|
|
35
72
|
Residual risk:
|
|
36
73
|
|
|
37
|
-
## Verification
|
|
38
|
-
|
|
39
|
-
| Check | Result | Notes |
|
|
40
|
-
|-------|--------|-------|
|
|
74
|
+
## Verification
|
|
75
|
+
|
|
76
|
+
| Check | Result | Notes |
|
|
77
|
+
|-------|--------|-------|
|
|
78
|
+
|
|
79
|
+
## Acceptance Result
|
|
80
|
+
|
|
81
|
+
| AC ID | Result | Evidence | Notes |
|
|
82
|
+
|-------|--------|----------|-------|
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
# Acceptance Criteria: {{FEATURE_NAME}}
|
|
2
|
+
|
|
3
|
+
## AC-001: {{TITLE}}
|
|
4
|
+
|
|
5
|
+
Given {{CONTEXT}}
|
|
6
|
+
When {{ACTION}}
|
|
7
|
+
Then {{EXPECTED_RESULT}}
|
|
8
|
+
And {{SIDE_EFFECT_OR_NEGATIVE_ASSERTION}}
|
|
9
|
+
|
|
10
|
+
Verification:
|
|
11
|
+
- UI: {{PLAYWRIGHT_STEP_OR_NA}}
|
|
12
|
+
- API: {{API_ASSERTION_OR_NA}}
|
|
13
|
+
- State: {{STATE_ASSERTION_OR_NA}}
|
|
14
|
+
- Evidence: {{SCREENSHOT_TRACE_OR_LOG_PATH}}
|
|
15
|
+
|
|
16
|
+
## Acceptance Result
|
|
17
|
+
|
|
18
|
+
| AC ID | Result | Evidence | Notes |
|
|
19
|
+
| --- | --- | --- | --- |
|
|
20
|
+
| AC-001 | NOT RUN | | |
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
# API Contract: {{FEATURE_NAME}}
|
|
2
|
+
|
|
3
|
+
## {{METHOD}} {{PATH}}
|
|
4
|
+
|
|
5
|
+
Purpose: {{PURPOSE}}
|
|
6
|
+
|
|
7
|
+
Request:
|
|
8
|
+
|
|
9
|
+
```json
|
|
10
|
+
{
|
|
11
|
+
"{{FIELD}}": "{{VALUE}}"
|
|
12
|
+
}
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
Success:
|
|
16
|
+
|
|
17
|
+
```json
|
|
18
|
+
{
|
|
19
|
+
"ok": true
|
|
20
|
+
}
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
Failure:
|
|
24
|
+
|
|
25
|
+
```json
|
|
26
|
+
{
|
|
27
|
+
"ok": false,
|
|
28
|
+
"message": "{{ERROR_MESSAGE}}"
|
|
29
|
+
}
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
AC IDs: AC-001
|
|
33
|
+
|
|
34
|
+
Assertions:
|
|
35
|
+
|
|
36
|
+
- method and URL match
|
|
37
|
+
- payload shape matches
|
|
38
|
+
- success response updates expected state
|
|
39
|
+
- failure response shows expected UI/API error
|
|
40
|
+
- duplicate submission behavior is defined
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
import { test, expect } from "@playwright/test";
|
|
2
|
+
|
|
3
|
+
test.describe("{{FEATURE_NAME}} acceptance", () => {
|
|
4
|
+
test("AC-001 {{TITLE}}", async ({ page }) => {
|
|
5
|
+
const requests: Array<{ url: string; method: string; postData: string | null }> = [];
|
|
6
|
+
|
|
7
|
+
page.on("request", request => {
|
|
8
|
+
requests.push({
|
|
9
|
+
url: request.url(),
|
|
10
|
+
method: request.method(),
|
|
11
|
+
postData: request.postData()
|
|
12
|
+
});
|
|
13
|
+
});
|
|
14
|
+
|
|
15
|
+
await page.goto("{{ROUTE}}");
|
|
16
|
+
await page.getByTestId("{{TEST_ID}}").click();
|
|
17
|
+
|
|
18
|
+
await expect(page.getByTestId("{{EXPECTED_TEST_ID}}")).toBeVisible();
|
|
19
|
+
expect(requests.some(request => request.url.includes("{{API_PATH}}"))).toBe(false);
|
|
20
|
+
});
|
|
21
|
+
});
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# PRD: {{FEATURE_NAME}}
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
{{USER_GOAL}}
|
|
6
|
+
|
|
7
|
+
## Scope
|
|
8
|
+
|
|
9
|
+
- {{IN_SCOPE_1}}
|
|
10
|
+
- {{IN_SCOPE_2}}
|
|
11
|
+
|
|
12
|
+
## Non-scope
|
|
13
|
+
|
|
14
|
+
- {{OUT_OF_SCOPE_1}}
|
|
15
|
+
- {{OUT_OF_SCOPE_2}}
|
|
16
|
+
|
|
17
|
+
## User Flow
|
|
18
|
+
|
|
19
|
+
1. {{USER_STEP_1}}
|
|
20
|
+
2. {{USER_STEP_2}}
|
|
21
|
+
3. {{USER_STEP_3}}
|
|
22
|
+
|
|
23
|
+
## UI Elements
|
|
24
|
+
|
|
25
|
+
| Element | Purpose | Required Selector |
|
|
26
|
+
| --- | --- | --- |
|
|
27
|
+
| {{ELEMENT}} | {{PURPOSE}} | `data-testid="{{TEST_ID}}"` |
|
|
28
|
+
|
|
29
|
+
## API Behavior
|
|
30
|
+
|
|
31
|
+
| Endpoint | Method | Purpose | AC IDs |
|
|
32
|
+
| --- | --- | --- | --- |
|
|
33
|
+
| {{ENDPOINT}} | {{METHOD}} | {{PURPOSE}} | AC-001 |
|
|
34
|
+
|
|
35
|
+
## Acceptance Criteria
|
|
36
|
+
|
|
37
|
+
- AC-001: {{GIVEN_WHEN_THEN_SUMMARY}}
|
|
38
|
+
- AC-002: {{GIVEN_WHEN_THEN_SUMMARY}}
|
|
39
|
+
|
|
40
|
+
## Verification Commands
|
|
41
|
+
|
|
42
|
+
```bash
|
|
43
|
+
{{COMMAND_1}}
|
|
44
|
+
{{COMMAND_2}}
|
|
45
|
+
```
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
# Test Plan: {{FEATURE_NAME}}
|
|
2
|
+
|
|
3
|
+
| AC ID | Test Level | File/Command | Evidence |
|
|
4
|
+
| --- | --- | --- | --- |
|
|
5
|
+
| AC-001 | Playwright + CDP | `npx playwright test {{SPEC_FILE}} --trace on` | trace + screenshot |
|
|
6
|
+
|
|
7
|
+
Required checks:
|
|
8
|
+
|
|
9
|
+
- unit tests for pure logic
|
|
10
|
+
- API/integration tests for API contracts
|
|
11
|
+
- Playwright for user-visible paths
|
|
12
|
+
- CDP/network assertions for frontend-backend side effects
|
|
13
|
+
- screenshot/trace/video on browser validation failure
|
|
14
|
+
- syntax-only checks, shallow renders, imports, typecheck, lint, and build success do not satisfy browser-visible ACs
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
# UI Contract: {{FEATURE_NAME}}
|
|
2
|
+
|
|
3
|
+
| Element | data-testid | Accessible Role/Label | States | AC IDs |
|
|
4
|
+
| --- | --- | --- | --- | --- |
|
|
5
|
+
| {{ELEMENT}} | `{{TEST_ID}}` | {{ROLE_OR_LABEL}} | default, loading, error, disabled | AC-001 |
|
|
6
|
+
|
|
7
|
+
Rules:
|
|
8
|
+
|
|
9
|
+
- Prefer `data-testid` for critical automation selectors.
|
|
10
|
+
- Accessible role/label may supplement but must not be unstable.
|
|
11
|
+
- Cover inputs, buttons, rows/items, empty state, loading state, and error state.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
# Validation Report: {{FEATURE_NAME}}
|
|
2
|
+
|
|
3
|
+
Validator: {{VALIDATOR_ROLE}}
|
|
4
|
+
Date: {{DATE}}
|
|
5
|
+
|
|
6
|
+
## Commands
|
|
7
|
+
|
|
8
|
+
| Command | Result | Notes |
|
|
9
|
+
| --- | --- | --- |
|
|
10
|
+
| `{{COMMAND}}` | {{PASS_FAIL_BLOCKED}} | {{NOTES}} |
|
|
11
|
+
|
|
12
|
+
## Acceptance Result
|
|
13
|
+
|
|
14
|
+
| AC ID | Result | Evidence | Notes |
|
|
15
|
+
| --- | --- | --- | --- |
|
|
16
|
+
| AC-001 | {{PASS_FAIL_BLOCKED}} | {{EVIDENCE_PATH}} | {{NOTES}} |
|
|
17
|
+
|
|
18
|
+
## Residual Risk
|
|
19
|
+
|
|
20
|
+
- {{RISK_OR_NONE}}
|
|
@@ -10,6 +10,7 @@
|
|
|
10
10
|
- [planner](../.claude/agents/planner.md) — task split, dependencies, write sets, and dispatch table.
|
|
11
11
|
- [architect](../.claude/agents/architect.md) — boundaries, ports, data-flow, and state impact.
|
|
12
12
|
- [test-writer](../.claude/agents/test-writer.md) — failing tests or manual verification before implementation.
|
|
13
|
+
- [tdd-guide](../.claude/agents/tdd-guide.md) - AC-linked RED tests, browser UI acceptance, and Playwright/CDP evidence before implementation.
|
|
13
14
|
- [implementer](../.claude/agents/implementer.md) — bounded implementation inside declared write set.
|
|
14
15
|
- [debugger](../.claude/agents/debugger.md) — smallest fix for a reproduced failure.
|
|
15
16
|
- [reviewer](../.claude/agents/reviewer.md) — read-only diff review and closeout risk.
|
|
@@ -33,13 +34,17 @@ Stack-specific agents can be added after the product shape is known.
|
|
|
33
34
|
- [wf-update](../.claude/skills/wf-update/SKILL.md) — GitHub-based incremental harness update, checksum comparison, and safe in-place updates.
|
|
34
35
|
- [wf-learn](../.claude/skills/wf-learn/SKILL.md) — force memory learning cycle: context-master -> memory-master -> project + global memory.
|
|
35
36
|
- [wf-max](../.claude/skills/wf-max/SKILL.md) — maximum-parallelism workflow: write-set coloring, wave dispatch, parallel review per dimension.
|
|
36
|
-
- [wf-auto](../.claude/skills/wf-auto/SKILL.md)
|
|
37
|
+
- [wf-auto](../.claude/skills/wf-auto/SKILL.md) - perpetual auto-optimization: bounded ticks, 8-angle internal scan, intent checkpoints, evidence ledger.
|
|
37
38
|
- [wf-auto-spark](../.claude/skills/wf-auto-spark/SKILL.md) — perpetual inspiration mode: external spark search, long-term roadmap with staged milestones, ≤50% deviation guard.
|
|
38
|
-
- [tdd](../.claude/skills/tdd/SKILL.md)
|
|
39
|
-
|
|
39
|
+
- [tdd](../.claude/skills/tdd/SKILL.md) - acceptance-driven TDD: AC-linked RED tests, real UI clicks for browser-visible behavior, Playwright/CDP evidence, and configured coverage gate.
|
|
40
|
+
- [wf-remove](../.claude/skills/wf-remove/SKILL.md) - safely remove Harness framework files (SAFE/MODIFIED/USER classes), auto-prune empty directories, backup option.
|
|
40
41
|
|
|
41
42
|
Codex repo-skill mirrors live under `../.agents/skills/` with the same skill names.
|
|
42
43
|
|
|
44
|
+
## Direct Commands
|
|
45
|
+
|
|
46
|
+
- [wf-help](../.claude/commands/wf-help.md) - direct `/wf-help` command that returns a WF command table without invoking a skill.
|
|
47
|
+
|
|
43
48
|
Stack-specific skills can be added after the product shape is known.
|
|
44
49
|
|
|
45
50
|
- [browser-e2e](workflows/browser-e2e.md)
|
|
@@ -56,6 +61,11 @@ Located under `.claude/rules/ecc/`, auto-loaded by the CC engine:
|
|
|
56
61
|
## Harness (Runtime)
|
|
57
62
|
|
|
58
63
|
- [Docs router](README.md)
|
|
64
|
+
- [Acceptance protocol](ACCEPTANCE_PROTOCOL.md)
|
|
65
|
+
- [Agent isolation protocol](AGENT_ISOLATION.md)
|
|
66
|
+
- [Harness Bridge](HARNESS_BRIDGE.md)
|
|
67
|
+
- [Debug protocol](DEBUG_PROTOCOL.md)
|
|
68
|
+
- [Memory protocol](MEMORY_PROTOCOL.md)
|
|
59
69
|
- [WF mode](WF.md)
|
|
60
70
|
- [WF Max mode](WF-MAX.md)
|
|
61
71
|
- [0-1 lifecycle](lifecycle.md)
|
|
@@ -66,6 +76,7 @@ Located under `.claude/rules/ecc/`, auto-loaded by the CC engine:
|
|
|
66
76
|
- [Extension contract](extension.md)
|
|
67
77
|
- [Architecture docs](architecture.md)
|
|
68
78
|
- [Agent workflow](agent-workflow.md)
|
|
79
|
+
- [Acceptance templates](templates/)
|
|
69
80
|
- [Harness validator](scripts/validate-harness.mjs)
|
|
70
81
|
- [Version file](.harness-version)
|
|
71
82
|
|
|
@@ -45,4 +45,4 @@ The agentic engineering harness lives in `Harness/`.
|
|
|
45
45
|
Tool discovery files stay at the repository root:
|
|
46
46
|
|
|
47
47
|
- Claude Code: `.claude/settings.json`, `.claude/agents/`, and `.claude/skills/`.
|
|
48
|
-
- Codex: `.agents/skills/` for repo skills and `.codex
|
|
48
|
+
- Codex: `.agents/skills/` for repo skills and `.codex/` for config placeholders. Runtime hooks are absent by default; only `/wf-auto` may opt into a bounded tick hook.
|