create-harness-vibe-coding 0.1.7 → 0.1.8
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/package.json +1 -1
- package/templates/common/SETUP.md +54 -0
package/package.json
CHANGED
|
@@ -44,6 +44,60 @@ Claude must follow this order:
|
|
|
44
44
|
10. Run `node scripts/validate-harness.mjs --strict`.
|
|
45
45
|
11. Record final verification and next feedback step in `docs/harness/PLAN.md`.
|
|
46
46
|
|
|
47
|
+
### Template Fill Guide
|
|
48
|
+
|
|
49
|
+
Each template doc contains `{{PLACEHOLDER}}` markers. Below is what every placeholder expects. Replace all markers in the doc before moving to the next doc. If a section does not apply yet, leave the `{{...}}` but record why in `docs/harness/PLAN.md`.
|
|
50
|
+
|
|
51
|
+
**`docs/research/PRD.md`** — Product scope. Fill with product facts from user input, not guesses:
|
|
52
|
+
- `{{WHY_THIS_PROJECT_EXISTS}}`: one-sentence motivation
|
|
53
|
+
- `{{MUST_1..3}}`: concrete, testable MVP items (checkbox form)
|
|
54
|
+
- `{{NON_GOAL_1..3}}`: explicitly out-of-scope items
|
|
55
|
+
- `{{USER_ROLE}}`, `{{SCENARIO}}`, `{{FREQUENCY}}`, `{{PAIN}}`: one row per user type
|
|
56
|
+
- `{{ACCEPTANCE_1..3}}`: verifiable project-level acceptance criteria
|
|
57
|
+
- `{{DIMENSION}}`, `{{TARGET}}`, `{{MEASUREMENT}}`: non-functional requirements (perf, security, etc.)
|
|
58
|
+
|
|
59
|
+
**`docs/research/research-results.md`** — Tech decisions. Research before filling:
|
|
60
|
+
- Use `docs/research/README.md` as the research protocol.
|
|
61
|
+
- `{{CANDIDATE_1..3}}`: each candidate (framework, library, architecture style) with Purpose/Strength/Weakness/Decision/Link.
|
|
62
|
+
- `{{Architecture Style}}`: the chosen architectural style (e.g., Hexagonal, Modular Monolith).
|
|
63
|
+
- `{{CONSTRAINT_1..3}}`: hard technical constraints derived from research.
|
|
64
|
+
- `{{ALTERNATIVE_1..2}}`: rejected candidates worth watching for future.
|
|
65
|
+
|
|
66
|
+
**`docs/harness/architecture.md`** — Layer structure. Derive from research-results:
|
|
67
|
+
- Fill the ASCII layer diagram with actual layer names. Do NOT add layers without a proven need.
|
|
68
|
+
- `2.1–2.5`: describe each harness core component (Runner, Permission Policy, Event Bus, State Store, Tool Registry) in project-specific terms.
|
|
69
|
+
- `3. Architectural Constraints`: add project-specific non-negotiables. Keep the domain/harness purity rules.
|
|
70
|
+
|
|
71
|
+
**`docs/domain/ports.md`** — Cross-layer contracts. One driving port + one driven port from the first slice:
|
|
72
|
+
- `{{INBOUND_PORT_1}}`: the first inbound port (e.g., "CreateOrderPort").
|
|
73
|
+
- `{{OUTBOUND_PORT_1}}`: the first outbound port (e.g., "OrderRepository").
|
|
74
|
+
- For each port: fill Purpose, Preconditions, Postconditions, Error Semantics, Idempotency.
|
|
75
|
+
- Leave remaining rows as `{{...}}` until more slices add ports.
|
|
76
|
+
|
|
77
|
+
**`docs/harness/PLAN.md`** — Active execution state. Update continuously:
|
|
78
|
+
- `## Current Goal`: one sentence, what this iteration achieves.
|
|
79
|
+
- `## Phase`: current lifecycle phase (Idea/Research/PRD/Architecture/Plan/Build/Verify/Feedback).
|
|
80
|
+
- `## Success Criteria`: verifiable outcomes for this iteration.
|
|
81
|
+
- `## Tasks`: numbered tasks with owner, write set, and verify command.
|
|
82
|
+
- `## Parallel Dispatch`: only when spawning subagents — fill agent roles, read/write boundaries.
|
|
83
|
+
- `## Verification`: record test results, review findings, docs sync checklist.
|
|
84
|
+
|
|
85
|
+
**`docs/harness/data-flow.md`** — Runtime event paths (only when first slice has async/multi-step flow):
|
|
86
|
+
- `{{EVENT_1}}`: the first event type with producer, consumers, payload fields, delivery semantics.
|
|
87
|
+
- Happy Path: fill the Mermaid sequence diagram with actual ports and actions.
|
|
88
|
+
- Failure Paths: for each failure point, document trigger, system behavior, event, caller perception, recovery.
|
|
89
|
+
- If the first slice is synchronous and stateless, leave this doc as `{{...}}` and note in PLAN.md.
|
|
90
|
+
|
|
91
|
+
**`docs/harness/state-machines.md`** — State transitions (only when first slice has stateful entities):
|
|
92
|
+
- Define states, transitions, guards, and illegal transitions for the first stateful entity.
|
|
93
|
+
- If no stateful entity exists in the first slice, leave as `{{...}}` and note in PLAN.md.
|
|
94
|
+
|
|
95
|
+
**General rules for all templates**:
|
|
96
|
+
- Replace `{{projectName}}` with the actual project name immediately.
|
|
97
|
+
- Never invent content for a `{{...}}` marker. If you lack facts, ask the user or leave the marker.
|
|
98
|
+
- `<!-- HTML comments -->` in templates are instructions to you. Read them. Delete them after filling the section.
|
|
99
|
+
- After filling all templates in a phase, run `node scripts/validate-harness.mjs --strict`. Any remaining `{{...}}` in project-fact files will be flagged.
|
|
100
|
+
|
|
47
101
|
## Architecture Research (Dynamic)
|
|
48
102
|
|
|
49
103
|
Do not guess the architecture. Use `docs/research/README.md` as the protocol and the high-star repos below as seed references. Search within them; do not read them whole.
|