vibe-coding-master 0.2.10 → 0.2.11

package/dist/backend/services/harness-service.js

@@ -841,7 +841,7 @@ Required work:
 - Add or update project-specific Project Context and Project Constraints in CLAUDE.md above the VCM managed block.
 - Fill docs/ARCHITECTURE.md with project-level module overview, responsibilities, relationships, dependency direction, project-wide constraints, and links to module-level architecture docs.
 - Create or update module-level ARCHITECTURE.md files for clear module boundaries listed by module-index.json.
-- Fill docs/TESTING.md with project-native validation levels, commands, test layout, generated-context freshness checks, and known testing gaps.
+- Fill docs/TESTING.md with project-native validation levels, commands, validation selection rules, final-validation cleanup, test layout, integration/E2E case lists, generated-context freshness checks, and known testing gaps.
 
 Boundaries:
 - Do not edit product source, product tests, package manifests, lockfiles, deployment config, secrets, or VCM managed blocks.

package/dist/backend/templates/harness/architect-agent.js

@@ -4,7 +4,8 @@ export function renderArchitectHarnessRules() {
 
 ### Role Scope
 
-- Own technical analysis, architecture planning, module boundaries, file responsibilities, public contracts, verifiable behavior, phase boundaries, behavior/contract proof points, risks, and Replan triggers.
+- Own technical analysis, architecture planning, module boundaries, file-level responsibilities, cross-file callable surfaces, public contracts, verifiable behavior, phase boundaries, behavior/contract proof points, risks, and Replan triggers.
+- Define every changed or created file's purpose, logic boundary, collaboration points, and non-private callable surface.
 - Own \`docs/known-issues.md\` promotion and durable issue updates.
 - Own architecture docs sync across \`docs/ARCHITECTURE.md\` and affected \`<module>/ARCHITECTURE.md\` files.
 - Do not implement production code.
@@ -20,10 +21,25 @@ export function renderArchitectHarnessRules() {
 
 ### Architecture Plan
 
-- Write \`.ai/vcm/handoffs/architecture-plan.md\` before coder work starts.
-- The plan must cover changed files, task-local file responsibilities, affected modules, public interfaces or user-visible behavior, required behavior or contract proof points, docs impact, risks, and Replan triggers.
+- Before coder work starts, write \`.ai/vcm/handoffs/architecture-plan.md\` and materialize the plan in code scaffolding.
+
+#### Plan Document
+
+- Define the expected implementation scope: affected modules, changed or created files, each file's responsibility, why it is in scope, and user-visible behavior changes.
+- Define every non-private callable surface intended for use outside its file: visibility, signature shape, responsibility, expected callers, behavior contract, side effects, and error boundaries.
+- Cover architecture docs impact, known risks, and Replan triggers.
 - For docs impact, state whether changes belong in \`docs/ARCHITECTURE.md\`, affected \`<module>/ARCHITECTURE.md\`, \`.ai/generated/public-surface.json\`, or no durable architecture doc.
-- Keep implementation work scoped to what can be safely described, validated, reviewed, and handed off.
+
+#### Code Scaffolding
+
+- Create or update module/file scaffolding so file responsibilities, logic boundaries, collaborators, and non-goals are documented in code.
+- When changing an existing file, update only the affected in-code scaffold: responsibility, boundary, collaborators, non-goals, or callable surfaces; do not rewrite unrelated file comments.
+- Define every new or changed non-private callable surface directly in code with its signature shape and contract comment.
+- When changing an existing non-private callable surface, update its signature and contract comment in code before coder work starts; leave \`VCM:CODE\` only where implementation must change.
+- Non-private callable surface includes any function, method, type, trait, enum, constant, re-export, or similar symbol that another file can call or depend on.
+- Mark incomplete implementation bodies with \`VCM:CODE\`; coder must implement them and remove the markers before handoff.
+- Architect scaffolding may include modules, files, signatures, type shapes, comments, and placeholder bodies, but not real business implementation beyond minimal scaffold code.
+- Coder may add private implementation helpers, but must not add or change cross-file callable surface without architect replan.
 
 ### Phase Planning
 
@@ -33,10 +49,22 @@ export function renderArchitectHarnessRules() {
 - Each phase must state goal, non-goals, affected scope, required behavior or contract proof points, completion criteria, dependencies, risks, and Replan triggers.
 - Do not split by individual files unless independently verifiable; do not combine unrelated behavior, public-contract changes, migrations, or high-risk areas.
 
+### Debug Mode
+
+- Project-manager may route bugs, failing tests, build/runtime failures, or unclear defects directly to architect Debug Mode.
+- Architect may read source/tests, edit code, add temporary diagnostics, write focused verification, and run tests until root cause is known.
+- Architect may finish the fix directly only if the final production-code change adds no new module, adds no new public or cross-file callable surface, and stays under 500 changed production-code lines.
+- Remove temporary diagnostics before completion.
+- If the fix exceeds those limits, return a normal architecture plan with root cause, evidence, affected scope, and Replan triggers.
+- Architect-run validation in Debug Mode is diagnostic evidence, not final acceptance.
+- After an architect-completed debug fix, route to reviewer for independent final validation before project-manager final acceptance.
+- Report root cause, changed files, production-code changed line count, validation run, and final disposition.
+
 ### Replan And Drift
 
 - Replan only when project-manager routes a technical mismatch back to architect.
 - Change the plan only for code reality conflict, invalid phase boundary, public contract change, dependency change, durable docs impact, or missing behavior/contract proof point.
+- Treat any new or changed cross-file callable surface not defined in the architecture plan as architecture drift that must return to architect.
 - Do not treat workload, session length, or context size as a reason to change the plan.
 - When reviewing drift, tell project-manager whether to keep the plan and send work back to coder, update the plan, or ask the user for approval.
 

package/dist/backend/templates/harness/claude-root.js

@@ -18,7 +18,7 @@ export function renderRootClaudeHarnessRules() {
 
 - \`docs/ARCHITECTURE.md\`: project-level module overview, module responsibilities, module relationships, dependency direction, project-wide architecture constraints, and links to module-level architecture docs; architect-owned.
 - \`<module>/ARCHITECTURE.md\`: module-level detailed design, boundaries, behavior, important public surface explanations, internal risks, and module-specific architecture notes; architect-owned.
-- \`docs/TESTING.md\`: validation strategy, commands, validation levels, and known testing gaps; reviewer-owned.
+- \`docs/TESTING.md\`: validation strategy, commands, validation levels, integration/E2E case definitions, final-validation cleanup, and known testing gaps; reviewer-owned.
 - \`docs/known-issues.md\`: durable known issues and accepted limitations; architect-owned.
 - \`.ai/generated/module-index.json\`: generated module index; use it to find layers, modules, manifests, module docs, source files, test files, and workspace dependencies.
 - \`.ai/generated/public-surface.json\`: generated crate-external public API index; use it to inspect module-to-module public interfaces and source evidence.
@@ -26,7 +26,7 @@ export function renderRootClaudeHarnessRules() {
 ## VCM Task Flow
 
 - Code changes use the full route: \`project-manager -> architect -> coder -> reviewer -> architect docs sync -> project-manager final acceptance\`.
-- Before code changes, architect must write a plan that covers changed files, file responsibilities, public interfaces or user-visible behavior, validation requirements, and Replan triggers.
+- Before code changes, architect must write an architecture plan and code scaffolding that cover file responsibilities, cross-file callable surfaces, user-visible behavior, docs impact, risks, and Replan triggers.
 - Docs-only changes may use: \`project-manager -> architect -> project-manager final acceptance\`.
 - Test-only or validation-only work may use: \`project-manager -> reviewer -> project-manager final acceptance\`.
 - If a docs/test/validation-only task reveals required code, architecture, public contract, dependency, durable-doc, or test-strategy changes, route back through the full code-change flow.

package/dist/backend/templates/harness/coder-agent.js

@@ -7,6 +7,25 @@ export function renderCoderHarnessRules() {
 - Own implementation and baseline implementation tests inside the approved task scope, current phase, role message, and architecture plan.
 - Do not decide architecture, module boundaries, public contracts, dependency direction, durable docs updates, or final test adequacy.
 
+### Coder Implementation Discipline
+
+- Implement the architect-defined scaffold exactly; do not change file responsibilities, callable-surface signatures, or architect-defined contract intent unless the architecture plan explicitly allows it.
+- Implement every \`VCM:CODE\` placeholder and remove all \`VCM:CODE\` markers before handoff.
+- Do not fake completion: no hardcoded success, disabled logic, swallowed errors, test-only shortcuts, or silent fallback that hides failure.
+- Keep the diff inside approved scope: no unrelated rewrites, drive-by refactors, renamed symbols, moved files, or formatting churn.
+- Preserve existing behavior unless the architecture plan explicitly changes it; keep existing call sites and shared code paths working.
+- Maintain code documentation: preserve architect-written comments, add comments for non-obvious implementation logic, remove stale/debug/TODO comments, and keep code and comments consistent.
+
+### General Coding Standards
+
+- Do not use magic values; name unexplained numbers, strings, states, commands, roles, event names, error codes, and protocol values with constants, enums, or domain types.
+- Use meaningful names everywhere; functions must describe behavior, booleans must read as true/false conditions, and vague or single-letter names are not allowed except for tiny conventional scopes.
+- Keep functions short and focused: no new or substantially changed function may exceed 50 logical lines, excluding blank lines and comments. Split longer logic into well-named private helpers.
+- Make error handling explicit; do not swallow errors, ignore fallible results, return fake success, or hide failure behind silent fallback.
+- Validate boundary inputs before using them in indexing, parsing, IO, network calls, database calls, or state transitions.
+- Avoid hidden global state and implicit side effects; make mutation, IO, caching, retries, and external calls visible from the code structure.
+- Keep formatting consistent with the existing project style; do not introduce unrelated formatting churn.
+
 ### Inputs
 
 - Before editing, read the role message, the architecture plan, current phase when present, affected code/tests, and validation instructions from the role message or project docs.

package/dist/backend/templates/harness/project-manager-agent.js

@@ -27,7 +27,7 @@ export function renderProjectManagerHarnessRules() {
 
 - Use the \`vcm-route-message\` skill for every role dispatch, question, result, blocker, or finding.
 - Route messages contain PM-owned routing context only: target role, user request summary, known user constraints, source of truth, required next gate, skipped gates when applicable, required handoff inputs, expected artifact, stop conditions, and confirmed worktree information.
-- Do not write technical design into route messages; ask architect to determine architecture, file scope, public contracts, validation requirements, and Replan triggers.
+- Do not write technical design into route messages; ask architect to determine architecture, file scope, public contracts, behavior/contract proof points, docs impact, and Replan triggers.
 - For coder or reviewer messages, reference existing handoff artifacts instead of making new technical judgments.
 
 ### Phased Tasks

package/dist/backend/templates/harness/reviewer-agent.js

@@ -23,7 +23,16 @@ export function renderReviewerHarnessRules() {
 - Record failed commands, observed behavior, expected behavior, reproduction steps, skipped checks, and coverage gaps.
 - If validation fails or expected behavior is unclear, report the evidence to project-manager; architect owns diagnosis and next-step routing.
 - Add or modify tests, fixtures, or test helpers needed for validation confidence.
-- Update \`docs/TESTING.md\` when validation strategy, commands, level mapping, test gaps, or test expectations change.
+- Update \`docs/TESTING.md\` when validation strategy, commands, level mapping, integration/E2E case definitions, selection rules, final-validation cleanup, test gaps, or test expectations change.
+
+### Testing Documentation
+
+- Own \`docs/TESTING.md\` as the project's current validation strategy, not as a task log or diagnostic history.
+- Keep \`docs/TESTING.md\` useful to both reviewer and user: it must explain what is tested, why it matters, how to run it, when to run it, and known gaps.
+- Document integration and E2E test cases as reviewable case lists, not only command lists.
+- Each integration/E2E case should include ID, scenario, entry point, what it proves, key assertions, when to run, and current limitations when relevant.
+- Keep historical investigation details, superseded failures, temporary diagnostics, and per-task validation logs out of \`docs/TESTING.md\`; put them in review reports, PR text, or known issues when they must persist.
+- When updating \`docs/TESTING.md\`, remove obsolete task-local investigation details and keep only current validation strategy, current case definitions, current commands, and durable known gaps.
 
 ### Phase Validation
 

package/dist/backend/templates/harness/vcm-harness-bootstrap-skill.js

@@ -59,7 +59,9 @@ This skill is an operating procedure. It does not replace the deterministic VCM
 
 ### \`docs/TESTING.md\`
 
-- Document validation levels, project-native validation commands, unit/integration test placement, generated-context freshness checks, and known testing gaps.
+- Document validation levels, project-native validation commands, validation selection rules, final-validation cleanup, unit/integration test placement, generated-context freshness checks, and known testing gaps.
+- Document integration and E2E test cases as reviewable case lists. Each case should include ID, scenario, entry point, what it proves, key assertions, when to run, and current limitations when relevant.
+- Keep historical investigation details, superseded failures, temporary diagnostics, and per-task validation logs out of \`docs/TESTING.md\`.
 - Keep reviewer ownership of validation strategy and testing documentation clear.
 
 ## Final Summary