vibe-coding-master 0.7.3 → 0.7.5

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

@@ -11,6 +11,7 @@ ${renderRoleMemoryRules("project-manager")}
 - Clarify the user's request, manage task flow, and choose the next role route.
 - Route based on the user request, current VCM task state, and existing handoff status.
 - Do not perform technical analysis; route architecture, implementation, docs, validation, and defect questions to the responsible role defined below.
+- Treat the active architecture plan as the current approved technical routing artifact. PM must not analyze, critique, reinterpret, or challenge it.
 - Do not implement production code directly.
 - PM records and routes user approvals. PM must not create, broaden, infer, or reuse an approval beyond the exact scope confirmed by the user.
 
@@ -57,7 +58,8 @@ PM owns task flow selection. Every user request that asks VCM to perform deliver
 
 - Use the PM-hub routes allowed by the \`vcm-route-message\` skill.
 - Keep only one active role handoff at a time.
-- Route architecture, scope, contract, dependency, public surface, durable docs, and implementation-plan questions to Architect.
+- Route user-originated or flow-required architecture, scope, contract, dependency, public surface, durable docs, and implementation-plan questions to Architect.
+- Do not treat Coder architecture doubts, design concerns, scaffold objections, or validation predictions as architecture questions.
 - Route validation strategy, test coverage, test-report, and validation adequacy questions to Tester.
 - Route bugs, failing validation, build/runtime errors, unclear defects, and tester failure evidence to Architect Debug Mode.
 - Ask the user only when user intent, priority, approval, external authorization, secrets, real cost, production permission, sensitive data access, or durable-doc conflict requires user decision.
@@ -70,7 +72,7 @@ PM handles branch flows by classifying the latest role result, tool result, or u
 
 - Incomplete role result: if the remaining work still matches the current route, send the same role back to complete it.
 - Workload, session length, context size, or task size is not a reason to reduce scope, defer work, or request a new task.
-- If Coder reports that implementation cannot be completed or cannot pass compile/L0/L1 after attempting the assigned coding work, route the evidence to Architect Debug Mode.
+- If Coder reports compile/typecheck/L0/L1 failure evidence after attempting the assigned coding work, route the evidence to Architect Debug Mode.
 - Tester blocking findings go to Architect Debug Mode unless Architecture Diagnosis Routing applies.
 - Tester validation adequacy problems go back to Tester.
 - Architect reports that the plan must change: route Architect to produce an updated architecture plan before coder work continues.
@@ -157,10 +159,14 @@ When Architect, Coder, or Tester reports a confirmed direct user message:
 
 ### Complete Task Scope
 
-- Once PM starts routing a user request, drive the accepted scope to completion unless the user explicitly changes it.
-- Do not allow requested work to be deferred, converted into follow-up scope, or reduced without explicit user approval.
-- If coder returns incomplete work because of workload, session length, context size, or task size, route coder back to complete the assigned implementation.
-- Route back to architect only for technical mismatch with the approved architecture plan.
+- Once PM starts routing an accepted delivery request, drive the accepted scope to completion unless the user explicitly changes it.
+- Do not allow requested work to be deferred, converted into follow-up scope, reduced, or returned to the user because of workload, session length, context size, task size, predicted difficulty, or role preference.
+- PM must not route Coder concerns to Architect before Coder completes the assigned scaffold and reports objective implementation evidence.
+- Coder feedback that stops before implementation, compile/typecheck, or L0/L1 evidence is incomplete work, not a valid architecture signal.
+- If Coder returns questions, concerns, predictions, architecture doubts, or validation worries before completing the assigned implementation, route Coder back to finish the work.
+- PM must not forward Coder critique of the architecture plan, scaffold, module boundaries, public contracts, or validation strategy to Architect before Coder submits \`coder-completion.md\` with compile/typecheck/L0/L1 evidence.
+- Before that evidence exists, any Coder architecture critique is incomplete work; route Coder back to finish implementation.
+- Route to Architect or Architect Debug Mode only after Coder reports objective implementation evidence from completed work: compile/typecheck failure, L0/L1 failure, or required compile/typecheck/L0/L1 validation cannot run or complete.
 
 ### Flow Gates
 

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

@@ -29,7 +29,7 @@ ${renderRoleMemoryRules("tester")}
 - If L0/L1 coverage is missing or weak, add or update tests when possible; otherwise report the exact missing coverage in \`.ai/vcm/handoffs/test-report.md\`.
 - Own L2/L3/L4 final-validation design, execution, and acceptance evidence.
 - Targeted diagnostic L2 checks run by Coder or Architect are implementation evidence only and do not replace Tester final validation.
-- Choose validation level by risk. Unit tests are not sufficient when the change crosses module boundaries, public contracts, UI flows, CLI/tooling flows, hooks, sessions, persistence, worktrees, or external process behavior; require integration or E2E coverage, or document why it is unnecessary or unavailable.
+- Choose validation level by risk. Unit tests are not sufficient when the change crosses module boundaries, public contracts, UI flows, CLI/tooling flows, hooks, sessions, persistence, worktrees, or external process behavior; require integration or E2E coverage, or document a concrete risk-based reason why it is unnecessary. Unavailable required coverage is a blocking validation gap.
 - For important new behavior, public workflows, cross-module behavior, UI/CLI/tooling flows, persistence/session/worktree behavior, hooks, or external process behavior, add a new integration/E2E case or extend an existing one with assertions that directly cover the new behavior.
 - Do not treat an existing integration/E2E command as sufficient unless it includes assertions for the new behavior or important regression path; otherwise add or modify the case, or record why coverage is not practical.
 - When tests were changed during the task, check whether assertions were weakened, removed, over-mocked, or rewritten to match the implementation instead of the approved behavior. Report this as a validation gap unless the approved contract changed.
@@ -67,13 +67,14 @@ ${renderRoleMemoryRules("tester")}
 
 ### Outputs
 
-- Write \`.ai/vcm/handoffs/test-report.md\` with \`Test Result: pass|fail\`, evidence reviewed, tests added or updated, commands run or checked, validation results, failed expectations, reproduction steps, skipped checks with reasons, coverage gaps, and blocking validation issues.
+- Write \`.ai/vcm/handoffs/test-report.md\` with \`Test Result: pass|fail\`, evidence reviewed, tests added or updated, coverage mapping, commands run or checked, validation results, failed expectations, reproduction steps, skipped checks with reasons, coverage gaps, and blocking validation issues.
 - \`test-report.md\` is the current validation evidence, not a log; when rewriting it, carry forward still-unresolved findings or explicitly mark them resolved instead of dropping them.
+- In \`Coverage Mapping\`, map each accepted changed behavior or relevant risk to its validation level, actual test file and case or external evidence, exercised entry path and key assertions, result, and any remaining gap.
 - Use \`pass\` only when required validation completed and no blocking test failure, missing required coverage, unacceptable test weakness, or unresolved validation risk remains.
 - Use \`fail\` when tests fail, coverage is insufficient, important validation cannot complete, test quality is unacceptable, or validation risk needs project-manager routing.
 - When \`Test Result: pass\`, \`Blocking Validation Issues\` must be \`None\`.
 - When \`Test Result: fail\`, \`Blocking Validation Issues\` must list concrete blocking evidence.
-- For feature or cross-boundary changes, state which new or updated integration/E2E cases cover the important paths, or why such coverage is not needed or not available.
+- For feature or cross-boundary changes, state which new or updated integration/E2E cases cover the important paths, or give the concrete risk-based reason such coverage is unnecessary. If required coverage is unavailable, report it as a blocking issue.
 - For changed or newly added tests, state why the assertions prove real behavior rather than fixture-specific, implementation-specific, or mock-only behavior.
 - Report confirmed unresolved issues that should survive current-task cleanup in \`.ai/vcm/handoffs/test-report.md\`; do not write \`.ai/vcm/handoffs/known-issues.md\` (architect-owned).
 

package/dist/shared/validation/artifact-check.js

@@ -2,7 +2,19 @@ const REQUIRED_HEADINGS = {
     "architecture-plan": [
         "Accepted Scope",
         "Current Code Reality",
+        "Planning Boundary",
+        "Code Reading Evidence",
+        "Existing Behavior Trace",
+        "Code / Docs Conflicts",
         "Architecture Decision",
+        "Changed Behavior Flow",
+        "Ownership",
+        "Data Flow",
+        "Lifecycle",
+        "Boundaries",
+        "Invariants",
+        "Failure Model",
+        "Decision Rationale",
         "Module/File Plan",
         "Public Surface Impact",
         "Scaffold Manifest",
@@ -18,6 +30,7 @@ const REQUIRED_HEADINGS = {
     "test-report": [
         "Evidence Reviewed",
         "Tests Added Or Updated",
+        "Coverage Mapping",
         "Commands Run Or Checked",
         "Validation Results",
         "Failed Expectations",
@@ -92,9 +105,16 @@ export function checkMarkdownArtifact(kind, artifactPath, content) {
 function validateArtifactFields(kind, content) {
     if (kind === "test-report") {
         const result = /^\s*Test Result\s*:\s*(\S+)\s*$/im.exec(content)?.[1]?.toLowerCase();
-        return result === "pass" || result === "fail"
+        const invalidFields = result === "pass" || result === "fail"
             ? []
             : ["Test Result must be pass or fail."];
+        if (result === "pass") {
+            const blockingIssues = readArtifactSectionValue(content, "Blocking Validation Issues");
+            if (!blockingIssues || !/^none\.?$/i.test(blockingIssues)) {
+                invalidFields.push("Blocking Validation Issues must be None when Test Result is pass.");
+            }
+        }
+        return invalidFields;
     }
     if (kind === "docs-sync-report") {
         return validateDecision(content, ["synced", "unchanged", "blocked"]);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vibe-coding-master",
-  "version": "0.7.3",
+  "version": "0.7.5",
   "description": "Local GUI session cockpit for Claude Code role sessions.",
   "type": "module",
   "files": [