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.
@@ -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-DDrcJLOG.js"></script>
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-08
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, Rust commands, generated-context freshness checks, and testing gaps. |
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
 
@@ -75,9 +75,9 @@ Recommended flow:
75
75
 
76
76
  ```text
77
77
  project-manager
78
- -> architect architecture plan
79
- -> coder implementation and validation
80
- -> reviewer independent review
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, and reviewer for non-trivial work.
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
- - direct unit/contract/regression tests
201
- - validation evidence
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
- - scope and architecture compliance
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 boundaries, risks, and durable docs
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 does not change architecture or durable
199
- docs.
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
- Production fixes go back to coder; design conflicts go back to architect.
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 and baseline unit checks.
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.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "vibe-coding-master",
3
- "version": "0.2.10",
3
+ "version": "0.2.12",
4
4
  "description": "Local GUI session cockpit for Claude Code role sessions.",
5
5
  "type": "module",
6
6
  "files": [