vibe-coding-master 0.2.10 → 0.2.12
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.md +5 -4
- package/dist/backend/cli/install-vcm-harness.js +708 -0
- package/dist/backend/services/harness-service.js +1 -1
- package/dist/backend/templates/harness/architect-agent.js +32 -4
- package/dist/backend/templates/harness/claude-root.js +2 -2
- package/dist/backend/templates/harness/coder-agent.js +19 -0
- package/dist/backend/templates/harness/project-manager-agent.js +10 -1
- package/dist/backend/templates/harness/reviewer-agent.js +10 -1
- package/dist/backend/templates/harness/vcm-harness-bootstrap-skill.js +3 -1
- package/dist-frontend/assets/{index-DDrcJLOG.js → index-CT20u9Fk.js} +38 -38
- package/dist-frontend/index.html +1 -1
- package/docs/full-harness-baseline.md +5 -5
- package/docs/product-design.md +16 -8
- package/docs/vcm-cc-best-practices.md +54 -8
- package/package.json +1 -1
- package/scripts/install-vcm-harness.mjs +37 -1418
package/dist-frontend/index.html
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
<meta charset="UTF-8" />
|
|
5
5
|
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
|
6
6
|
<title>VibeCodingMaster</title>
|
|
7
|
-
<script type="module" crossorigin src="/assets/index-
|
|
7
|
+
<script type="module" crossorigin src="/assets/index-CT20u9Fk.js"></script>
|
|
8
8
|
<link rel="stylesheet" crossorigin href="/assets/index-DC9-SB7F.css">
|
|
9
9
|
</head>
|
|
10
10
|
<body>
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Full Harness Baseline
|
|
2
2
|
|
|
3
|
-
Last updated: 2026-06-
|
|
3
|
+
Last updated: 2026-06-12
|
|
4
4
|
|
|
5
5
|
Status: Temporary working document.
|
|
6
6
|
|
|
@@ -81,9 +81,9 @@ These entries match the current `example/rust-layered/.ai/vcm-harness-manifest.j
|
|
|
81
81
|
| Claude settings | `.claude/settings.json` | json-merge | Long-term | VCM owns hook entries matching VCM command markers. |
|
|
82
82
|
| Agent directory | `.claude/agents/` | VCM-created directory | Long-term | Contains the four core VCM role agents. |
|
|
83
83
|
| Core agent | `.claude/agents/project-manager.md` | managed-block | Long-term | Project-manager role rules. |
|
|
84
|
-
| Core agent | `.claude/agents/architect.md` | managed-block | Long-term | Architect role rules. |
|
|
85
|
-
| Core agent | `.claude/agents/coder.md` | managed-block | Long-term | Coder role rules. |
|
|
86
|
-
| Core agent | `.claude/agents/reviewer.md` | managed-block | Long-term | Reviewer role rules. |
|
|
84
|
+
| Core agent | `.claude/agents/architect.md` | managed-block | Long-term | Architect role rules: plan document, code scaffolding, Debug Mode, docs sync. |
|
|
85
|
+
| Core agent | `.claude/agents/coder.md` | managed-block | Long-term | Coder role rules: scaffold implementation, coding standards, baseline unit checks. |
|
|
86
|
+
| Core agent | `.claude/agents/reviewer.md` | managed-block | Long-term | Reviewer role rules: independent validation, TESTING.md strategy, integration/E2E case lists. |
|
|
87
87
|
| Skill directory | `.claude/skills/` | VCM-created directory | Conditional long-term | Keep while repo-local VCM skills are installed. |
|
|
88
88
|
| Skill directory | `.claude/skills/vcm-route-message/` | VCM-created directory | Conditional long-term | Claude Code registration directory for the route-message skill. |
|
|
89
89
|
| Skill directory | `.claude/skills/vcm-final-acceptance/` | VCM-created directory | Conditional long-term | Claude Code registration directory for the final-acceptance skill. |
|
|
@@ -124,7 +124,7 @@ VCM-owned harness and should not appear as manifest entries.
|
|
|
124
124
|
| Project context | `CLAUDE.md` content outside VCM block | Project | Long-term | Rust-layered project facts and constraints. |
|
|
125
125
|
| Project architecture | `docs/ARCHITECTURE.md` | Architect | Long-term | Project-level module overview, responsibilities, relationships, dependency direction, and links to module docs. |
|
|
126
126
|
| Module architecture | `<module>/ARCHITECTURE.md` | Architect | Long-term | Module-level boundaries, behavior, important public surface explanations, and risks. |
|
|
127
|
-
| Testing docs | `docs/TESTING.md` | Reviewer | Long-term | Validation levels,
|
|
127
|
+
| Testing docs | `docs/TESTING.md` | Reviewer | Long-term | Validation levels, commands, selection rules, final-validation cleanup, integration/E2E case definitions, generated-context freshness checks, and testing gaps. |
|
|
128
128
|
| Known issues | `docs/known-issues.md` | Architect | Rolling durable doc | Confirmed unresolved issues and accepted limitations. Remove fixed, rejected, or obsolete entries. |
|
|
129
129
|
| Durable plans | `docs/plans/` | Project | Conditional long-term | Durable plans only when a large task needs them. Completed routine plans should be deleted after durable facts are promoted. |
|
|
130
130
|
|
package/docs/product-design.md
CHANGED
|
@@ -75,9 +75,9 @@ Recommended flow:
|
|
|
75
75
|
|
|
76
76
|
```text
|
|
77
77
|
project-manager
|
|
78
|
-
-> architect architecture plan
|
|
79
|
-
-> coder implementation and
|
|
80
|
-
-> reviewer independent
|
|
78
|
+
-> architect architecture plan and code scaffolding
|
|
79
|
+
-> coder implementation and baseline unit checks
|
|
80
|
+
-> reviewer independent validation
|
|
81
81
|
-> architect docs sync / architecture drift check
|
|
82
82
|
-> project-manager final acceptance, commit, and PR
|
|
83
83
|
```
|
|
@@ -168,12 +168,13 @@ The project manager owns:
|
|
|
168
168
|
- user communication
|
|
169
169
|
- task clarification
|
|
170
170
|
- role routing
|
|
171
|
+
- Debug Mode routing for bugs, failing checks, build/runtime errors, unclear defects, and reviewer failure evidence
|
|
171
172
|
- message dispatch
|
|
172
173
|
- handoff verification
|
|
173
174
|
- final acceptance
|
|
174
175
|
- commit and PR preparation after gates pass
|
|
175
176
|
|
|
176
|
-
The project manager must not become the architect, coder,
|
|
177
|
+
The project manager must not become the architect, coder, reviewer, or debugger for non-trivial work. PM routes debug evidence to architect and resumes normal gates after architect reports the debug disposition.
|
|
177
178
|
|
|
178
179
|
### Architect
|
|
179
180
|
|
|
@@ -182,9 +183,12 @@ The architect owns:
|
|
|
182
183
|
- architecture plan
|
|
183
184
|
- module boundaries
|
|
184
185
|
- file responsibilities
|
|
186
|
+
- cross-file callable surfaces and contract comments
|
|
187
|
+
- code scaffolding with `VCM:CODE` placeholders
|
|
185
188
|
- public contracts
|
|
186
189
|
- verifiable behavior and behavior/contract proof points
|
|
187
190
|
- Replan triggers
|
|
191
|
+
- Debug Mode for routed bug/build/test/runtime investigations
|
|
188
192
|
- post-review docs sync and architecture drift checks
|
|
189
193
|
|
|
190
194
|
Outputs:
|
|
@@ -197,8 +201,9 @@ Outputs:
|
|
|
197
201
|
The coder owns:
|
|
198
202
|
|
|
199
203
|
- implementation within the approved plan
|
|
200
|
-
-
|
|
201
|
-
-
|
|
204
|
+
- completion of architect-defined `VCM:CODE` placeholders
|
|
205
|
+
- baseline unit/contract/regression tests
|
|
206
|
+
- general coding standards and code documentation consistency
|
|
202
207
|
|
|
203
208
|
Outputs:
|
|
204
209
|
|
|
@@ -210,7 +215,9 @@ The reviewer owns:
|
|
|
210
215
|
|
|
211
216
|
- independent review
|
|
212
217
|
- test adequacy
|
|
213
|
-
-
|
|
218
|
+
- final validation confidence
|
|
219
|
+
- integration and E2E case definitions in `docs/TESTING.md`
|
|
220
|
+
- validation strategy, selection rules, and final-validation cleanup
|
|
214
221
|
- docs gap detection
|
|
215
222
|
- risk findings
|
|
216
223
|
|
|
@@ -232,7 +239,7 @@ The app has two primary areas:
|
|
|
232
239
|
|
|
233
240
|
### Sidebar
|
|
234
241
|
|
|
235
|
-
All sidebar groups are collapsible and default to collapsed. When no task is selected, `Repository Path` opens by default.
|
|
242
|
+
All sidebar groups are collapsible and default to collapsed. When no task is selected, `Repository Path` opens by default. The sidebar is a single-open accordion: opening one group closes the previous group, and clicking the open group collapses it.
|
|
236
243
|
|
|
237
244
|
Sections:
|
|
238
245
|
|
|
@@ -628,6 +635,7 @@ Display behavior:
|
|
|
628
635
|
- `prose` starts by showing the English source.
|
|
629
636
|
- while translating, panel status shows `translating <elapsed>`.
|
|
630
637
|
- when translation succeeds, the English source is replaced by Chinese translated text.
|
|
638
|
+
- when new translation events arrive, the active panel scrolls to the bottom after render so the latest entry, retry result, or conversation boundary is visible.
|
|
631
639
|
- `prose` content is rendered as Markdown, including headings, lists, code fences, tables, and links.
|
|
632
640
|
- when translation fails, panel status shows `error` and the entry keeps the visible source plus an error.
|
|
633
641
|
- `tool-output` is dim, one-line, truncated by CSS, and not translated.
|
|
@@ -192,14 +192,19 @@ VCM uses four core roles:
|
|
|
192
192
|
asks the user for product or approval decisions, and performs final evidence
|
|
193
193
|
acceptance. It does not perform technical analysis.
|
|
194
194
|
- `architect`: technical planner and docs-sync owner. It defines module/file
|
|
195
|
-
responsibilities, public contracts, phase
|
|
196
|
-
updates.
|
|
195
|
+
responsibilities, cross-file callable surfaces, public contracts, phase
|
|
196
|
+
boundaries, risks, and durable docs updates. Before coder work starts,
|
|
197
|
+
architect writes the plan and materializes it in code scaffolding with
|
|
198
|
+
contract comments and `VCM:CODE` placeholders.
|
|
197
199
|
- `coder`: implementation owner. It changes production code and baseline unit
|
|
198
|
-
tests within the approved plan. It
|
|
199
|
-
|
|
200
|
+
tests within the approved plan. It follows the architect-defined scaffold,
|
|
201
|
+
implements and removes `VCM:CODE` placeholders, follows general coding
|
|
202
|
+
standards, and does not change architecture or durable docs.
|
|
200
203
|
- `reviewer`: independent validation owner. It reads code as needed, writes or
|
|
201
204
|
updates tests, owns `docs/TESTING.md`, and decides validation sufficiency.
|
|
202
|
-
|
|
205
|
+
`docs/TESTING.md` must be current validation strategy, not a task log, and
|
|
206
|
+
must include reviewable integration/E2E case lists. Production fixes go back
|
|
207
|
+
to coder; design conflicts go back to architect.
|
|
203
208
|
|
|
204
209
|
Roles work sequentially in one task worktree. If `git status` shows uncommitted
|
|
205
210
|
changes, commit them before handing off to another role.
|
|
@@ -232,6 +237,39 @@ architect-defined phase at a time and must not split, merge, reorder, or redefin
|
|
|
232
237
|
phases. A role may return partial completed work and ask PM for continuation, but
|
|
233
238
|
workload or context size is not a valid reason to change the architect plan.
|
|
234
239
|
|
|
240
|
+
## 7.1 Architecture Plan And Code Scaffolding
|
|
241
|
+
|
|
242
|
+
For code changes, the architect plan is not only a markdown handoff. It is a
|
|
243
|
+
plan document plus code scaffolding.
|
|
244
|
+
|
|
245
|
+
The plan document defines affected modules, changed or created files, file
|
|
246
|
+
responsibilities, why each file is in scope, user-visible behavior changes,
|
|
247
|
+
non-private cross-file callable surfaces, docs impact, risks, and Replan
|
|
248
|
+
triggers.
|
|
249
|
+
|
|
250
|
+
Code scaffolding materializes that plan in the repository before coder work
|
|
251
|
+
starts:
|
|
252
|
+
|
|
253
|
+
- new modules or files are created when needed
|
|
254
|
+
- file-level responsibilities, logic boundaries, collaborators, and non-goals
|
|
255
|
+
are documented in code
|
|
256
|
+
- new or changed non-private callable surfaces are defined directly in code with
|
|
257
|
+
signature shape and contract comments
|
|
258
|
+
- incomplete implementation bodies are marked with `VCM:CODE`
|
|
259
|
+
|
|
260
|
+
Coder implements the marked placeholders and may add private helpers, but cannot
|
|
261
|
+
change file responsibilities, callable-surface signatures, or contract intent
|
|
262
|
+
without architect replan.
|
|
263
|
+
|
|
264
|
+
Architect may also enter Debug Mode when PM routes bugs, failing tests,
|
|
265
|
+
build/runtime failures, or unclear defects. Debug Mode allows architect to read
|
|
266
|
+
source/tests, edit code, add temporary diagnostics, write focused verification,
|
|
267
|
+
and run tests until the root cause is known. Architect may directly finish only
|
|
268
|
+
localized fixes that add no new module, add no new public or cross-file callable
|
|
269
|
+
surface, and stay under 500 changed production-code lines. Architect-run
|
|
270
|
+
validation is diagnostic evidence, not final acceptance; reviewer still performs
|
|
271
|
+
independent final validation.
|
|
272
|
+
|
|
235
273
|
## 8. Route Messages
|
|
236
274
|
|
|
237
275
|
Use the `vcm-route-message` skill whenever a VCM role hands off work, asks a
|
|
@@ -270,6 +308,14 @@ The current Rust example does not use fixed `check-fast`, `check-changed`, or
|
|
|
270
308
|
`cargo test`, `cargo test -p <crate>`, `cargo check`, or project-specific
|
|
271
309
|
commands documented in `docs/TESTING.md`.
|
|
272
310
|
|
|
311
|
+
Reviewer owns `docs/TESTING.md` as the current validation strategy, not as a
|
|
312
|
+
task log or diagnostic history. It must explain what is tested, why it matters,
|
|
313
|
+
how to run it, when to run it, and known gaps. Integration and E2E tests should
|
|
314
|
+
be documented as reviewable case lists with ID, scenario, entry point, what the
|
|
315
|
+
case proves, key assertions, when to run, and current limitations when relevant.
|
|
316
|
+
Superseded failures, temporary diagnostics, and per-task validation logs belong
|
|
317
|
+
in review reports, PR text, or durable known issues when they must persist.
|
|
318
|
+
|
|
273
319
|
Long-running commands use `vcm-long-running-validation`, backed by:
|
|
274
320
|
|
|
275
321
|
```text
|
|
@@ -468,8 +514,8 @@ Rules:
|
|
|
468
514
|
10. No fixed `check-*` wrappers by default.
|
|
469
515
|
11. Use native project commands for validation.
|
|
470
516
|
12. Use generated context only when it has a real generator.
|
|
471
|
-
13. Coder owns implementation
|
|
472
|
-
14. Reviewer owns independent validation and `docs/TESTING.md
|
|
473
|
-
15. Architect owns architecture planning and durable architecture docs.
|
|
517
|
+
13. Coder owns implementation, baseline unit checks, scaffold completion, and general coding standards.
|
|
518
|
+
14. Reviewer owns independent validation and `docs/TESTING.md` as current testing strategy with integration/E2E case lists.
|
|
519
|
+
15. Architect owns architecture planning, code scaffolding, Debug Mode, and durable architecture docs.
|
|
474
520
|
16. PM owns routing and final evidence acceptance, not technical analysis.
|
|
475
521
|
17. Temporary documents are deleted; durable documents are updated.
|