vibe-coding-master 0.6.20 → 0.6.22

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

@@ -7,6 +7,7 @@ This skill is an operating procedure. It does not replace the deterministic VCM
 
 ## Boundaries
 
+- Work only in the active task worktree named by VCM.
 - Read the repository before drafting project-specific harness content.
 - Do not edit product source, product tests, package manifests, lockfiles, deployment config, or secrets.
 - Do not own managed-block writes, hook merging, manifest migrations, uninstall behavior, or deterministic skeleton creation; VCM backend owns those.
@@ -17,7 +18,7 @@ This skill is an operating procedure. It does not replace the deterministic VCM
 1. Generate context when supported: run \`.ai/tools/generate-module-index\`, then run \`.ai/tools/generate-public-surface\` after \`module-index.json\` exists.
 2. Inspect the project:  read \`README.md\`, read \`CLAUDE.md\`, durable project docs, project manifests/config, source layout, tests, and existing validation commands.
 3. Fill project context: add or update non-managed project facts in \`CLAUDE.md\` above the VCM managed block.
-4. Fill durable docs: update \`docs/ARCHITECTURE.md\`, module-level \`ARCHITECTURE.md\` files for clear non-root module boundaries, and \`docs/TESTING.md\` with detailed project-specific content.
+4. Fill durable docs: update \`docs/GLOSSARY.md\`, \`docs/CODING_STANDARDS.md\`, \`docs/ARCHITECTURE.md\`, module-level \`ARCHITECTURE.md\` files for clear non-root module boundaries, and \`docs/TESTING.md\` with detailed project-specific content.
 5. Preserve user-authored content and VCM managed blocks.
 6. Review \`git status\` and \`git diff\`.
 7. Stage only allowed bootstrap harness changes and create a commit in the active task worktree.
@@ -26,6 +27,8 @@ This skill is an operating procedure. It does not replace the deterministic VCM
 ## Typical Outputs
 
 - \`CLAUDE.md\` project context and project constraints outside the VCM managed block
+- \`docs/GLOSSARY.md\`
+- \`docs/CODING_STANDARDS.md\`
 - \`docs/ARCHITECTURE.md\`
 - \`docs/TESTING.md\`
 - \`docs/known-issues.md\` only for confirmed durable issues
@@ -47,6 +50,20 @@ This skill is an operating procedure. It does not replace the deterministic VCM
 - Run \`.ai/tools/generate-public-surface\` only after \`.ai/generated/module-index.json\` exists.
 - If generation fails or the project is unsupported, report the reason. Do not invent generated artifacts.
 
+### \`docs/GLOSSARY.md\`
+
+- Keep the project abbreviation allowlist current.
+- Include abbreviations that are allowed in durable comments and documentation.
+- Remove or avoid project-invented shorthand that is not useful as durable terminology.
+- If an abbreviation is not listed here, roles must write the full term instead.
+
+### \`docs/CODING_STANDARDS.md\`
+
+- The shared baseline lives inside the VCM managed block and is installer-maintained; do not edit it.
+- Add project-specific implementation rules outside the managed block (for example under \`Project Coding Standards\`) only when they make the shared baseline more precise.
+- Do not weaken the baseline rules without explicit project approval.
+- Keep role workflow rules out of this file; role routing, Gate Review, Final Acceptance, and role-specific handoff rules belong in role definitions or skills.
+
 ### \`docs/ARCHITECTURE.md\`
 
 - Document the project-level module overview, module responsibilities, module relationships, dependency direction, and project-wide constraints.
@@ -65,7 +82,7 @@ This skill is an operating procedure. It does not replace the deterministic VCM
 - 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.
+- Keep tester ownership of validation strategy and testing documentation clear.
 
 ### Commit
 

package/dist/backend/templates/harness/vcm-long-running-validation-skill.js

@@ -7,7 +7,7 @@ Never run the Bash tool with \`run_in_background: true\`, and never detach a pro
 
 The only sanctioned long-running mechanism is \`.ai/tools/run-long-check\` plus \`.ai/tools/watch-job\` through this skill.
 
-The hard ceiling is 60 minutes per job, enforced by the job worker itself. Do not run or suggest operations expected to exceed 60 minutes without user approval; split larger work first.
+The hard ceiling is 60 minutes per job, enforced by the job worker itself. No approval can raise this ceiling; split larger operations into jobs that each fit within it.
 
 ## Protocol
 

package/dist/backend/templates/harness/vcm-report-harness-issue-skill.js

@@ -11,7 +11,9 @@ Write one markdown file under:
 \${VCM_BASE_REPO_ROOT}/.ai/vcm/harness-feedback/pending/
 \`\`\`
 
-If \`VCM_BASE_REPO_ROOT\` is not set, use the current git root as a fallback.
+If \`VCM_BASE_REPO_ROOT\` is not set, do not guess a fallback path. Report the
+environment problem to project-manager so VCM can retry with the correct base
+repository root.
 
 Use a filename like:
 
@@ -23,17 +25,21 @@ Use only safe filename characters: letters, numbers, dot, dash, and underscore.
 
 ## Required Content
 
-The file must include:
-
-- reporter role
-- task slug when known
-- summary
-- observed problem
-- expected behavior
-- evidence, with relevant file paths, command names, logs, or repeated failure pattern
-- suspected harness area
-- impact
-- urgency
+Use this structure:
+
+\`\`\`md
+# <short problem title>
+
+- Reporter role: <role>
+- Task slug: <slug or unknown>
+- Summary: <one line>
+- Observed problem: <what happened>
+- Expected behavior: <what the harness should have done>
+- Evidence: <file paths, command names, logs, or repeated failure pattern>
+- Suspected harness area: <skill, role definition, tool, routing, validation, bootstrap, or managed instruction>
+- Impact: <who is affected and how>
+- Urgency: low | medium | high
+\`\`\`
 
 ## Constraints
 

package/dist/backend/templates/harness/vcm-route-message-skill.js

@@ -1,13 +1,24 @@
 export function renderVcmRouteMessageSkillRules() {
     return `## Purpose
 
-Use this skill when a VCM role needs to hand work, ask a question, report a result, report a blocker, or raise a finding to another VCM role.
+Use this skill when project-manager dispatches a VCM role or when a VCM role reports a question, result, blocker, or finding back to project-manager.
 
 This skill writes a route file. It does not deliver the message. VCM backend delivery is triggered later by Claude Code hooks.
 
 ## Route Policy
 
-Use only routes allowed by the current VCM role rules and task approval.
+VCM uses project-manager as the routing hub.
+
+Allowed routes:
+
+- \`project-manager -> architect\`
+- \`project-manager -> coder\`
+- \`project-manager -> tester\`
+- \`architect -> project-manager\`
+- \`coder -> project-manager\`
+- \`tester -> project-manager\`
+
+Non-PM roles must not route directly to each other. Report questions, blockers, results, findings, or validation evidence back to project-manager. PM decides the next role route.
 
 Allowed message types:
 
@@ -27,7 +38,7 @@ Write or update exactly one file:
 .ai/vcm/handoffs/messages/<from-role>-<to-role>.md
 \`\`\`
 
-The file name is authoritative. Do not put from/to in frontmatter and do not create alternate message paths.
+Use one allowed route above. The file name is authoritative. Do not put from/to in frontmatter and do not create alternate message paths.
 
 If the same route file already contains a not-yet-delivered message, update that file instead of creating a fragmented follow-up.
 
@@ -37,7 +48,7 @@ Use the smallest body that is complete. Include artifact refs instead of copying
 
 For simple user relay, use a lightweight body instead of the formal dispatch format.
 
-For formal dispatch, blocker, finding, review, or gate routing, use:
+For PM dispatch, use:
 
 \`\`\`md
 ---
@@ -56,19 +67,46 @@ Request or result:
 Evidence:
 ...
 
-Expected next action:
+Next gate:
+...
+
+Stop conditions:
 ...
 \`\`\`
 
+For non-PM reports, use:
+
+\`\`\`md
+---
+type: result
+artifact_refs:
+  - .ai/vcm/handoffs/example.md
+---
+
+Summary:
+...
+
+Result, blocker, or finding:
+...
+
+Evidence:
+...
+
+Requested PM decision:
+...
+\`\`\`
+
+For non-PM role reports, \`Requested PM decision\` is a request for PM classification, not an instruction to route, skip gates, continue, pause, or close the task.
+
 ## Formal Body Content
 
 Formal messages should include:
 
 - why this message exists
-- what the target role should do or what result is being reported
+- what the target role should do for PM dispatch, or what result/status is being reported for non-PM reports
 - source of truth or artifact references
 - validation or documentation state when relevant
-- blocker, decision needed, or next step when relevant
+- blocker, finding, status, or PM decision needed when relevant
 
 ## Turn Rule
 
@@ -81,7 +119,9 @@ Do not:
 - start a shell loop
 - wait for another role's answer
 - paste directly into another role terminal
-- use Claude Code Task/Subagent for VCM role delegation
+- use Claude Code Task/Subagent to replace VCM role routing. Coder worker
+  subagents are governed by Coder's \`vcm-coder-worker\` rules and are not
+  route-message delivery.
 
 VCM scans pending route files after the Stop hook and delivers later replies in a new turn.
 

package/dist/backend/templates/message-envelope.js

@@ -2,9 +2,6 @@ export function renderMessageEnvelope(message) {
     const artifactRefs = message.artifactRefs.length > 0
         ? message.artifactRefs.map((artifact) => `- ${artifact}`).join("\n")
         : "- none";
-    const routeFileExample = message.toRole === "project-manager"
-        ? ".ai/vcm/handoffs/messages/project-manager-<target-role>.md"
-        : `.ai/vcm/handoffs/messages/${message.toRole}-project-manager.md`;
     return `
 [VCM MESSAGE]
 id: ${message.id}
@@ -21,8 +18,8 @@ ${artifactRefs}
 Instructions:
 - Read the message and execute only within this VCM task.
 - If you write or update a VCM route file, use the vcm-route-message skill.
-- If you need to send a VCM message after handling this, write or update .ai/vcm/handoffs/messages/<your-role>-<target-role>.md.
-- Non-PM roles reply only to project-manager, for example ${routeFileExample}.
+- If PM sends a VCM message after handling this, write or update .ai/vcm/handoffs/messages/project-manager-<target-role>.md.
+- If a non-PM role sends a VCM message after handling this, reply only to project-manager with .ai/vcm/handoffs/messages/<your-role>-project-manager.md.
 - After writing a route file, end this Claude Code turn immediately.
 - Do not poll, loop, or wait for another role in this turn. VCM scans route files after your Stop hook and delivers later replies in a new turn.
 [/VCM MESSAGE]

package/dist/shared/constants.js

@@ -20,9 +20,9 @@ export const CORE_VCM_ROLE_DEFINITIONS = [
         dispatchable: true
     },
     {
-        name: "reviewer",
-        label: "Reviewer",
-        commandAgent: "reviewer",
+        name: "tester",
+        label: "Tester",
+        commandAgent: "tester",
         dispatchable: true
     }
 ];

package/dist/shared/types/gate-review.js

@@ -1,5 +1,10 @@
 export const GATE_REVIEW_GATES = [
     "architecture-plan",
     "validation-adequacy",
-    "final-diff"
+    "code-diff"
+];
+export const CODE_DIFF_SOURCES = [
+    "coder",
+    "architect-debug",
+    "architect-diagnosis"
 ];

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

@@ -1,21 +1,30 @@
 const REQUIRED_HEADINGS = {
     "architecture-plan": [
-        "Context",
+        "Accepted Scope",
+        "Current Code Reality",
         "Architecture Decision",
+        "Module/File Plan",
+        "Public Surface Impact",
         "Scaffold Manifest",
-        "Implementation Plan",
-        "Risks",
-        "Stop Conditions"
+        "Tester Coverage Hints",
+        "Docs Impact",
+        "Known Risks",
+        "Coder Handoff Notes"
     ],
     "known-issues": [
         "Task Issues",
         "Escalation To Docs"
     ],
-    "review-report": [
-        "Summary",
-        "Findings",
-        "Validation",
-        "Decision"
+    "test-report": [
+        "Evidence Reviewed",
+        "Tests Added Or Updated",
+        "Commands Run Or Checked",
+        "Validation Results",
+        "Failed Expectations",
+        "Reproduction Steps",
+        "Skipped Checks With Reasons",
+        "Coverage Gaps",
+        "Blocking Validation Issues"
     ],
     "docs-sync-report": [
         "Summary",
@@ -34,6 +43,7 @@ const REQUIRED_HEADINGS = {
         "Validation Summary",
         "Review And Docs Sync",
         "Known Issues Disposition",
+        "Gate Review Gates",
         "Cleanup Readiness",
         "Final User Summary"
     ]
@@ -48,6 +58,7 @@ export function checkMarkdownArtifact(kind, artifactPath, content) {
             isEmpty: true,
             hasPlaceholder: false,
             missingHeadings: [...REQUIRED_HEADINGS[kind]],
+            invalidFields: [],
             status: "missing"
         };
     }
@@ -60,11 +71,13 @@ export function checkMarkdownArtifact(kind, artifactPath, content) {
             isEmpty: true,
             hasPlaceholder: false,
             missingHeadings: [...REQUIRED_HEADINGS[kind]],
+            invalidFields: [],
             status: "empty"
         };
     }
     const missingHeadings = REQUIRED_HEADINGS[kind].filter((heading) => !hasHeading(trimmed, heading));
     const hasPlaceholder = PLACEHOLDER_PATTERN.test(trimmed);
+    const invalidFields = validateArtifactFields(kind, trimmed);
     return {
         kind,
         path: artifactPath,
@@ -72,9 +85,50 @@ export function checkMarkdownArtifact(kind, artifactPath, content) {
         isEmpty: false,
         hasPlaceholder,
         missingHeadings,
-        status: missingHeadings.length === 0 && !hasPlaceholder ? "ok" : "incomplete"
+        invalidFields,
+        status: missingHeadings.length === 0 && !hasPlaceholder && invalidFields.length === 0 ? "ok" : "incomplete"
     };
 }
+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"
+            ? []
+            : ["Test Result must be pass or fail."];
+    }
+    if (kind === "docs-sync-report") {
+        return validateDecision(content, ["synced", "unchanged", "blocked"]);
+    }
+    if (kind === "final-acceptance") {
+        return validateDecision(content, [
+            "accepted",
+            "accepted-with-known-risks",
+            "needs-coder-follow-up",
+            "needs-architect-follow-up",
+            "needs-docs-sync",
+            "blocked-by-user-decision"
+        ]);
+    }
+    return [];
+}
+function validateDecision(content, allowed) {
+    const decision = readArtifactSectionValue(content, "Decision")?.toLowerCase();
+    return decision && allowed.includes(decision)
+        ? []
+        : [`Decision must be one of: ${allowed.join(", ")}.`];
+}
+export function readArtifactSectionValue(content, heading) {
+    const match = new RegExp(`^#{1,6}\\s+${escapeRegExp(heading)}\\s*$`, "im").exec(content);
+    if (!match || match.index === undefined) {
+        return undefined;
+    }
+    const afterHeading = content.slice(match.index + match[0].length);
+    const nextHeading = /\n#{1,6}\s+\S/.exec(afterHeading);
+    const section = nextHeading?.index === undefined
+        ? afterHeading
+        : afterHeading.slice(0, nextHeading.index);
+    return section.split(/\r?\n/).map((line) => line.trim()).find(Boolean);
+}
 function hasHeading(content, heading) {
     const pattern = new RegExp(`^#{1,6}\\s+${escapeRegExp(heading)}\\s*$`, "im");
     return pattern.test(content);