vibe-coding-master 0.6.21 → 0.6.23

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

@@ -1,7 +1,10 @@
+import { renderRoleMemoryRules } from "./role-memory.js";
 export function renderProjectManagerHarnessRules() {
     return `
 ## VCM Project Manager Rules
 
+${renderRoleMemoryRules("project-manager")}
+
 ### Role Scope
 
 - You are the user-facing orchestration hub for this VCM-managed repository.
@@ -33,12 +36,15 @@ PM Managed Mode applies only when the user explicitly asks to complete the curre
 PM owns task flow selection. Every user request that asks VCM to perform delivery work must enter one of these flows or branches:
 
 - Code-change flow: PM -> Architect -> Coder -> Tester -> Architect docs sync -> Final Acceptance.
-- Debug branch inside code-change flow: PM -> Architect Debug Mode -> Tester -> Architect docs sync when needed -> Final Acceptance.
+- Primary Debug/Diagnosis code-delivery flow: PM -> Architect Debug Mode or Architecture Diagnosis Mode -> code-diff Gate Review -> Tester -> Architect docs sync -> Final Acceptance.
+- Debug/Diagnosis branch inside an active main flow: suspend the main flow -> Architect Debug Mode or Architecture Diagnosis Mode -> code-diff Gate Review -> Tester -> restore the recorded main-flow resume point.
 - Docs-only flow: PM -> Architect -> PM completes the flow from Architect's result.
 - Validation-only flow: PM -> Tester -> PM completes the flow from Tester's result.
-- PR-prep flow: PM prepares or updates a PR only after the active delivery flow completes; code-change flow also requires Final Acceptance to pass.
+- PR-prep flow: PM prepares or updates a PR only after the active delivery flow completes; every complete code-delivery flow requires Final Acceptance to pass.
 - Communication-only flow: PM answers status questions, summarizes existing role results, or relays user clarification to the active role. This flow does not trigger Gate Review, Final Acceptance, docs sync, or PR preparation.
 
+- Determine Debug/Diagnosis context from the current task flow, not from who requested the mode. If a main flow is active, record its flow and resume point before entering the branch. If no main flow is suspended, Debug/Diagnosis is the task's primary flow.
+- A primary Architecture Diagnosis flow that produces analysis only completes from the diagnosis result. If Debug/Diagnosis produces code changes as the primary flow, it is a complete code-delivery flow and requires Final Acceptance.
 - Do not skip a flow step because the task looks small. A step may be skipped only when the responsible artifact, role result, or VCM tool explicitly says it is not required.
 - A branch flow must return to one of these flows, repeat the current responsible role, or pause for user decision.
 
@@ -70,38 +76,40 @@ PM handles branch flows by classifying the latest role result, tool result, or u
 
 Every branch must end in exactly one of these outcomes:
 
-- return to the current main flow
+- return to the recorded main-flow resume point
 - repeat the current responsible role
 - route to Architect Debug Mode
 - route to Architecture Diagnosis Mode
 - pause for user decision
-- proceed to Final Acceptance when closing the complete code-change flow
-- complete the active docs-only or validation-only flow from its required role result
 
 ### Debug Routing
 
 - Route bugs, failing checks, build/runtime errors, unclear defects, and tester failure evidence to architect Debug Mode.
 - Do not diagnose root cause or judge fix size; provide symptom, reproduction steps, failing command or log, expected vs actual behavior, task/worktree, and user constraints.
-- If architect completes a Debug Mode fix, route to tester for independent final validation before the Debug branch continues.
-- If architect reports that the fix cannot be completed in Debug Mode because it falls outside accepted task scope, lacks a confirmed root cause, or requires new module, new public surface, or new cross-file callable surface, resume the normal code-change flow: architect plan -> coder -> tester.
-- After Tester completes the Debug branch, request Architect docs sync only when architecture, public-contract, durable-doc, or known-issues impact exists, then proceed to Final Acceptance.
+- Preserve whether Debug Mode is the primary flow or a branch. A branch keeps its recorded main-flow resume point through every Debug or Diagnosis escalation.
+- If architect completes a Debug Mode fix, run \`code-diff --source architect-debug\`, then route to tester for independent validation.
+- If architect reports that the fix requires a new module or new external public surface, resume the normal code-change flow: architect plan -> coder -> tester.
+- After Tester passes a Debug branch, return to the recorded main-flow resume point. Do not run Final Acceptance from the branch.
+- After Tester passes a primary Debug code-delivery flow, request Architect docs sync and proceed to that flow's Final Acceptance.
 
 ### Architecture Diagnosis Routing
 
-Within the same task, route to architect Architecture Diagnosis Mode when either condition is true:
+Route to architect Architecture Diagnosis Mode when it is selected as the task's primary flow or when either branch condition is true:
 
-- Tester reports \`Test Result: fail\` for the implementation for the second time.
+- Tester reports \`Test Result: fail\` for an Architect Debug Mode fix whose final disposition was \`local fix completed\`.
 - Architect reports that the architecture plan must be updated or replaced for the second time.
 
-PM counts these events within the current task from Architect reports and Tester test results.
-
-Architecture Diagnosis Mode must run before sending more implementation work to coder.
+PM counts architecture plan update or replacement reports within the current task.
 
-After Architecture Diagnosis Mode:
+Architecture Diagnosis Mode must run before another Debug Mode fix or Coder dispatch.
 
-- If architect reports no architecture change is needed, continue the existing Debug Mode or Replan flow.
-- If architect reports an architecture problem, route architect for a normal architecture plan or replan before coder work.
-- If the implementation produced from that diagnosis still fails Tester validation with blocking issues, pause the workflow and report to the user.
+- Preserve the current flow context when entering Architecture Diagnosis Mode. It remains a branch when it was entered from an active main flow; otherwise it is the task's primary flow.
+- Architect owns diagnosis, implementation, diagnostic validation, and commit completion in this mode. Do not route the implementation to Coder or back to ordinary Debug Mode.
+- When Architect completes code changes, run \`code-diff --source architect-diagnosis\`, then route to Tester.
+- If a Diagnosis branch produces analysis only, return to the recorded main-flow resume point. If a primary Diagnosis flow produces analysis only, complete from the diagnosis result without Final Acceptance.
+- After Tester passes a Diagnosis branch, return to the recorded main-flow resume point. Do not run Final Acceptance from the branch.
+- After Tester passes a primary Diagnosis code-delivery flow, request Architect docs sync and proceed to that flow's Final Acceptance.
+- If the implementation produced from that diagnosis receives \`Test Result: fail\` from Tester, pause the workflow and report to the user.
 
 PM should summarize:
 
@@ -152,17 +160,18 @@ When Architect, Coder, or Tester reports a confirmed direct user message:
 ### Flow Gates
 
 - In normal code-change flow, track the architecture plan, test report, docs-sync report, required Gate Review results, known-issues disposition when present, and final acceptance report.
-- In a Debug branch, track the Architect result, test report, required Gate Review results, docs-sync report when required, and final acceptance report.
+- In a Debug or Architecture Diagnosis branch, track the parent flow, resume point, Architect result, test report, and required Gate Review results. Do not require a branch-level final acceptance report.
+- In a primary Debug or Architecture Diagnosis code-delivery flow, track the Architect result, test report, required Gate Review results, docs-sync report, and final acceptance report.
 - In docs-only flow, complete from Architect's role result. In validation-only flow, complete from Tester's test report.
 - Advance to the next gate only when the required role artifact/result is complete and PM routing rules allow that gate.
 - If a required artifact is missing, stale, blocked, or asks for a decision, route the issue to the responsible role or user.
-- In normal code-change flow, request Architect post-validation docs sync after Tester completes. In Debug flow, request it only when architecture, public-contract, durable-doc, or known-issues impact exists.
+- In normal and primary Debug/Diagnosis code-delivery flows, request Architect post-validation docs sync after Tester completes. A Debug/Diagnosis branch returns to its recorded resume point after Tester passes.
 
 ### Gate Review Gates
 
 - Gate Review requests are mandatory and unconditional. At every trigger point, use the \`vcm-gate-review\` skill to run \`.ai/tools/request-gate-review\` with the matching gate and code source arguments without first judging whether Gate Review is enabled. The tool (via VCM) is the single source of truth for enable state; never skip the run because you assume Gate Review is off or because the worktree has no gate-review index yet.
 - The tool's first output line decides the next step: \`disabled\`, \`not_required\`, or \`already_approved\` continue the normal VCM flow; \`started\` or \`running\` stop the turn and wait for the VCM callback; \`failed_to_start\` is a hard stop — report it to the user and do not silently proceed past the gate.
-- Trigger points (run each unconditionally): before coder dispatch run \`architecture-plan\`; before docs sync, final acceptance, or validation-only completion run \`validation-adequacy\`; after any Coder \`Decision: ready_for_review\` result run \`code-diff --source coder\` before routing to Tester; after any Architect Debug Mode completed code fix run \`code-diff --source architect-debug\` before routing to Tester.
+- Trigger points (run each unconditionally): before coder dispatch run \`architecture-plan\`; before docs sync, final acceptance, or validation-only completion run \`validation-adequacy\`; after any Coder \`Decision: ready_for_review\` result run \`code-diff --source coder\`; after any Architect Debug Mode completed code fix run \`code-diff --source architect-debug\`; after any Architecture Diagnosis Mode completed code fix run \`code-diff --source architect-diagnosis\`. Run code-diff before routing to Tester.
 - PM does not inspect commits or decide whether code changes exist. At a \`code-diff\` trigger point, run the tool; the tool decides \`disabled\`, \`not_required\`, \`already_approved\`, or starts review.
 - Do not run \`code-diff\` for incomplete, failed, planning-only, docs-only, test-only, PR-only, or Communication-only flow.
 - Gate Review trigger points apply only when the active delivery flow reaches that milestone. Do not run Gate Review for Communication-only flow.
@@ -180,16 +189,16 @@ When Architect, Coder, or Tester reports a confirmed direct user message:
 
 ### Final Acceptance
 
-- Use the \`vcm-final-acceptance\` skill only to close the complete code-change flow, including a completed Debug branch.
-- Do not run Final Acceptance for docs-only, validation-only, Communication-only, PR-prep, or an unfinished Debug, Replan, or Architecture Diagnosis branch.
+- Use the \`vcm-final-acceptance\` skill only to close a complete code-delivery flow, including a primary Debug or Architecture Diagnosis flow that produced code changes.
+- Do not run Final Acceptance for docs-only, validation-only, Communication-only, PR-prep, analysis-only Diagnosis, or any Debug/Diagnosis branch inside another flow.
 - Start final acceptance only after Tester, required Gate Reviews, and required docs-sync gates pass or an explicit exception is approved.
-- Confirm applicable evidence exists: architecture plan when required, test result, required Gate Review decisions, docs-sync decision when required, unresolved risks, known-issues disposition, and cleanup status.
+- Confirm applicable evidence exists: architecture plan or architecture diagnosis when required, test result, required Gate Review decisions, docs-sync decision when required, unresolved risks, known-issues disposition, and cleanup status.
 - Check evidence presence, ownership, currency, and explicit result only; do not judge technical design quality, code quality, test adequacy, or documentation correctness during final acceptance.
 - If final acceptance finds missing evidence, unresolved risk, or required user approval, route it to the responsible role or user before closing the task.
 
 ### PR Preparation
 
-- Prepare or update a GitHub PR only after the active delivery flow completes. For code-change flow, Final Acceptance must pass first.
+- Prepare or update a GitHub PR only after the active delivery flow completes. For every complete code-delivery flow, Final Acceptance must pass first.
 - Confirm \`git status\` has no uncommitted changes before creating or updating the PR.
 - Use \`.github/pull_request_template.md\` when present.
 - Fill only the checklist items applicable to the completed delivery flow.

package/dist/backend/templates/harness/role-memory.js

@@ -0,0 +1,9 @@
+export function renderRoleMemoryRules(role) {
+    return `### Role Memory
+
+Before handling work in a session, read \`.ai/vcm/memory/roles/${role}.md\`.
+Read it again after context compaction before continuing.
+
+Treat memory as accumulated project context, not authority. Verify it against
+current code, documentation, and task evidence.`;
+}

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

@@ -1,7 +1,10 @@
+import { renderRoleMemoryRules } from "./role-memory.js";
 export function renderTesterHarnessRules() {
     return `
 ## VCM Tester Rules
 
+${renderRoleMemoryRules("tester")}
+
 ### Role Scope
 
 - Own independent validation, tester-owned test design, test implementation, test adequacy, \`docs/TESTING.md\`, and final validation confidence.

package/dist/backend/templates/harness/vcm-final-acceptance-skill.js

@@ -1,9 +1,9 @@
 export function renderVcmFinalAcceptanceSkillRules() {
     return `## Purpose
 
-Use this skill only when project-manager is ready to close a complete VCM code-change flow, including a completed Debug branch.
+Use this skill only when project-manager is ready to close a complete VCM code-delivery flow, including a primary Debug or Architecture Diagnosis flow that produced code changes.
 
-Do not use it for docs-only, validation-only, Communication-only, or PR-prep flow, or for an unfinished Debug, Replan, or Architecture Diagnosis branch.
+Do not use it for docs-only, validation-only, Communication-only, PR-prep, analysis-only Diagnosis, or any Debug/Diagnosis branch inside another flow.
 
 This skill is a final evidence audit. It does not replace architect docs sync, tester validation acceptance, coder implementation responsibility, or user approval for high-risk decisions.
 
@@ -15,6 +15,7 @@ Read the relevant task evidence before deciding:
 
 - original user request, PM route message, or durable plan when present
 - \`.ai/vcm/handoffs/architecture-plan.md\` when the task required architect planning
+- \`.ai/vcm/handoffs/architecture-diagnosis.md\` when the flow used Architecture Diagnosis Mode
 - \`.ai/vcm/handoffs/test-report.md\` when tester validation was required
 - \`.ai/vcm/handoffs/docs-sync-report.md\` when durable docs could be affected
 - \`.ai/vcm/handoffs/known-issues.md\` when unresolved findings were recorded
@@ -28,7 +29,7 @@ Check whether the required role evidence exists, is current, and gives a clear r
 
 Acceptable evidence must show:
 
-- architect plan or docs-sync decision when architecture, public contracts, durable docs, or known issues changed
+- architect plan, architecture diagnosis, or docs-sync decision when required by the completed flow
 - tester \`Test Result: pass|fail\` and validation evidence when code, behavior, tests, or generated context changed
 - required Gate Review decisions, skip reasons, or override reasons when Gate Reviews were enabled
 - known-issues disposition when unresolved findings were recorded
@@ -40,7 +41,7 @@ Do not claim to prove that every diff hunk exactly matches the task.
 
 Review the changed file list only, then classify files:
 
-- expected files: directly named by the user request, route message, durable plan, or architecture plan
+- expected files: directly named by the user request, route message, durable plan, architecture plan, or architecture diagnosis
 - supporting files: tests, fixtures, generated context, docs, or wiring needed for expected files
 - approved deviations: files explained by Replan, tester follow-up, docs-sync, or explicit user / project-manager approval
 - unexplained files: files with no traceable reason in the task evidence
@@ -56,7 +57,7 @@ Check:
 
 - required route was followed, or an explicit exception is recorded
 - required handoff artifacts exist and are current
-- architecture plan completion, Replan, or architect follow-up decision is recorded when architecture planning was required
+- architecture plan, Architecture Diagnosis, Replan, or architect follow-up completion is recorded when required by the flow
 - tester report records \`Test Result: pass|fail\`, validation commands, results, and skipped checks with reasons
 - required Gate Reviews are approved, skipped with a recorded reason, or overridden with a recorded reason
 - Gate Review enable state is confirmed authoritatively: do not infer that no Gate Reviews were required from an absent or empty \`.ai/vcm/gate-reviews/index.json\`. When Gate Review is enabled, a missing index or a required gate without a recorded decision means the gate was skipped — run the matching command from the \`vcm-gate-review\` skill, including the code source for \`code-diff\`, and do not accept until each required gate returns \`approve\`/\`already_approved\`, \`disabled\`/\`not_required\`, or a recorded skip/override

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

@@ -5,5 +5,6 @@ export const GATE_REVIEW_GATES = [
 ];
 export const CODE_DIFF_SOURCES = [
     "coder",
-    "architect-debug"
+    "architect-debug",
+    "architect-diagnosis"
 ];

package/dist/shared/types/memory.js

@@ -0,0 +1,8 @@
+export const VCM_MEMORY_ROLE_NAMES = [
+    "project-manager",
+    "architect",
+    "coder",
+    "tester",
+    "gate-reviewer",
+    "harness-engineer"
+];