vibe-coding-master 0.9.1 → 0.9.3

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

@@ -55,7 +55,7 @@ PM Managed Mode applies only when the user explicitly asks to complete the curre
 - PM may defer non-blocking user-facing questions until the final user report, but only when continuing does not require user intent, external authorization, or a user-approved exception.
 - Deferred questions remain part of the current task report. They must not become follow-up scope unless the user explicitly creates a new task.
 - PM must pause and ask the user only when the task cannot proceed without user intent or real-world authorization: unclear or conflicting requested outcome, required account/secret/test environment/data access, real cost, production permission, sensitive data access, destructive or irreversible real-world action, durable-doc conflict requiring user choice, or a required user-approved exception.
-- Required user-approved exceptions include skipped required validation, Gate Review skip or override, skipped required docs sync, accepted unresolved task-scope risk, or weakening baseline Harness rules.
+- Required user-approved exceptions include skipped required validation, Gate Review skip or override, skipped required documentation updates, accepted unresolved task-scope risk, or weakening baseline Harness rules.
 - PM records user approvals exactly as given. PM must not create, broaden, infer, or reuse approval.
 
 ### Task Flow Selection
@@ -92,9 +92,9 @@ Use this flow when the accepted task requires production-code or runtime-behavio
 
 The main flow is:
 
-\`Architect Interview and planning -> architecture-plan Gate -> Coder implementation -> Tester validation -> validation-adequacy Gate -> code-diff Gate -> Architect docs sync -> Final Acceptance -> completed\`
+\`Architect Interview and planning -> architecture-plan Gate -> Coder implementation -> Tester validation -> validation-adequacy Gate -> code-diff Gate -> Final Acceptance -> completed\`
 
-Require \`.ai/vcm/handoffs/docs-sync-report.md\` from the current Architect docs-sync dispatch. \`docs-update-report.md\` cannot replace it.
+Architect writes the architecture docs during planning, and the architecture-plan Gate reviews them with the plan. Any later Architect change to a durable architecture fact updates the owning doc in the same commits, and the code-diff Gate reviews the docs against the final code.
 
 PM may leave this path only through the allowed branches below.
 
@@ -109,12 +109,13 @@ PM may leave this path only through the allowed branches below.
 - **Tester Failure:** If Tester returns \`Test Result: fail\` with \`Test Infrastructure Status: none\`, \`repaired\`, or \`production-change-required\`, suspend the main flow and enter Architect Debug Branch.
 - **Validation Revision:** If the validation-adequacy Gate returns \`request_changes\`, route the complete report to Tester. Tester must correct the tests or evidence, rerun required validation, commit tracked Tester-owned changes, and replace \`test-report.md\` before PM reruns the Gate. If corrected validation returns \`fail\`, apply Tester Test-Infrastructure Repair or Tester Failure from that result.
 - **Tester Code-Diff Correction:** If every code-diff finding has \`Finding Scope: test-only\`, route the complete report to Tester. After correction, repeat Tester validation, validation-adequacy Gate, and \`code-diff --source coder\`.
-- **User-Approved Post-Validation Work:** After Tester returns \`pass\` and both post-implementation Gates succeed, route Tester again only when the user explicitly approves additional Tester-owned work in the current task. Submit the user's exact approval through \`User-Approved Follow-Up\`, not Workflow Override. After Tester completes and commits the work, repeat Tester validation, validation-adequacy Gate, and \`code-diff --source coder\`.
+- **Docs Code-Diff Correction:** If every code-diff finding has \`Finding Scope: docs-only\`, or the findings are only \`docs-only\` and \`test-only\`, route the complete report to Architect to correct the docs first, then rerun the code-diff Gate with the same \`--source\`; the rerun reviews the doc commits incrementally and routes any remaining \`test-only\` finding to Tester. A docs-only correction does not repeat Tester validation or the validation-adequacy Gate.
+- **Docs Coverage Correction:** If the code-diff Gate returns \`failed_to_start\` with a message that starts with \`Docs coverage check failed:\`, route the message to Architect to update the owning docs of the listed modules, then rerun the code-diff Gate with the same \`--source\`.
+- **User-Approved Post-Validation Work:** After Tester returns \`pass\` and the validation-adequacy and code-diff Gates succeed, before Final Acceptance, route Tester again only when the user explicitly approves additional Tester-owned work in the current task. Submit the user's exact approval through \`User-Approved Follow-Up\`, not Workflow Override. After Tester completes and commits the work, repeat Tester validation, validation-adequacy Gate, and \`code-diff --source coder\`.
 - **Code-Diff Correction:** If any code-diff finding has \`Finding Scope: implementation\`, suspend the main flow and enter Architect Debug Branch with the complete Gate report.
-- **Docs Sync Correction:** \`Decision: synced\` or \`unchanged\` continues to Final Acceptance only with \`Correction Owner: none\`. For \`Decision: blocked\`, route the exact \`Correction Owner\`: Architect repeats docs sync; Coder corrects Coder-owned documentation and returns through Tester and both post-implementation Gates; Tester corrects Tester-owned tests or \`docs/TESTING.md\`, reruns validation, and returns through both Gates. Then rerun Architect docs sync.
-- **Final Acceptance Follow-Up:** Route \`needs-coder-follow-up\` to Coder, \`needs-architect-follow-up\` to Architect, \`needs-docs-sync\` to Architect docs sync, and \`blocked-by-user-decision\` to the user. After follow-up work, resume from the earliest affected Code-Change Flow step and repeat every downstream Gate.
+- **Final Acceptance Follow-Up:** Route \`needs-coder-follow-up\` to Coder, \`needs-architect-follow-up\` to Architect (including documentation and known-issues follow-up), and \`blocked-by-user-decision\` to the user. After Coder follow-up, repeat Tester validation and both Gates. After an Architect documentation follow-up, rerun the code-diff Gate with the same \`--source\`; Architect work that changes code or tests returns through Tester validation and both Gates. Then repeat Final Acceptance.
 - **User Decision:** Pause only when the flow requires user intent, external authorization, or an exact user-approved exception. Resume from the suspended step after the user's decision is recorded.
-- **Gate Runtime:** \`started\` or \`running\` waits for the VCM callback. \`failed_to_start\` stops the flow for VCM retry, skip, or override handling. Other successful tool results continue according to the main flow.
+- **Gate Runtime:** \`started\` or \`running\` waits for the VCM callback. Apart from Docs Coverage Correction, \`failed_to_start\` stops the flow for VCM retry, skip, or override handling. Other successful tool results continue according to the main flow.
 
 #### Completion
 
@@ -164,6 +165,8 @@ The shared path is:
 
 \`Architect Debug Mode -> Tester -> validation-adequacy Gate -> code-diff --source architect-debug\`
 
+Architect updates the owning architecture docs in the same commits as any fix that changes a durable architecture fact.
+
 #### Allowed Branches
 
 - **Normal Plan Required:** If Architect returns \`normal architecture plan required\`, enter Code-Change Flow at Architect planning. When Debug is a branch of Code-Change Flow, resume that parent flow at Architect planning.
@@ -172,13 +175,14 @@ The shared path is:
 - **Architecture Diagnosis:** If Tester returns \`Test Result: fail\` with \`Test Infrastructure Status: none\`, \`repaired\`, or \`production-change-required\`, enter Architecture Diagnosis Branch.
 - **Validation Revision:** If the validation-adequacy Gate returns \`request_changes\`, route the complete report to Tester. After Tester corrects tests or evidence, reruns validation, commits tracked Tester-owned changes, and replaces \`test-report.md\`, rerun the Gate.
 - **Tester Code-Diff Correction:** If every code-diff finding has \`Finding Scope: test-only\`, route the complete report to Tester. After correction, repeat Tester validation, validation-adequacy Gate, and \`code-diff --source architect-debug\`.
-- **User-Approved Post-Validation Work:** After Tester returns \`pass\` and both Gates succeed, the user may explicitly approve additional Tester-owned work. Route Tester with the exact \`User-Approved Follow-Up\` approval, then repeat Tester validation and both Gates.
+- **Docs Code-Diff Correction:** If the code-diff findings are only \`docs-only\` (or \`docs-only\` and \`test-only\`), or the Gate fails to start with \`Docs coverage check failed:\`, route the report or message to Architect to correct the docs, then rerun \`code-diff --source architect-debug\`.
+- **User-Approved Post-Validation Work:** After Tester returns \`pass\` and the validation-adequacy and code-diff Gates succeed, the user may explicitly approve additional Tester-owned work. Route Tester with the exact \`User-Approved Follow-Up\` approval, then repeat Tester validation and both Gates.
 - **Code-Diff Revision:** If any code-diff finding has \`Finding Scope: implementation\`, route the complete report to Architect Debug Mode. After correction, repeat Tester validation, validation-adequacy Gate, and \`code-diff --source architect-debug\`.
 
 #### Successful Exit
 
-- For Architect Debug Flow, code-diff approval continues to \`Architect docs sync -> Final Acceptance\`. Require \`.ai/vcm/handoffs/docs-sync-report.md\` from this docs-sync dispatch with \`Decision: synced\` or \`unchanged\` and \`Correction Owner: none\`; handle \`blocked\` through Docs Sync Correction.
-- For Architect Debug Branch, code-diff approval returns to the recorded parent-flow resume point after the parent flow's validation and code-diff milestones. The branch does not run its own docs sync or Final Acceptance.
+- For Architect Debug Flow, code-diff approval continues to Final Acceptance.
+- For Architect Debug Branch, code-diff approval returns the run to its parent flow, which has then passed its validation and code-diff milestones: run the parent flow's Final Acceptance next, and route its follow-ups in the parent flow. The branch never runs its own Final Acceptance.
 
 Architect Debug Flow or Branch never routes implementation to Coder. Architect executes Architect Debug Mode; PM owns whether the current context is a Flow or Branch and where it continues afterward.
 
@@ -197,6 +201,8 @@ The code-delivery path is:
 
 \`Architecture Diagnosis Mode -> Tester -> validation-adequacy Gate -> code-diff --source architect-diagnosis\`
 
+Architect updates the owning architecture docs in the same commits as any fix that changes a durable architecture fact.
+
 Architecture Diagnosis Mode must run before another Debug Mode fix or Coder dispatch. Architect owns diagnosis, implementation, validation, and commit completion. Do not route Diagnosis implementation to Coder.
 
 #### Allowed Branches
@@ -206,15 +212,16 @@ Architecture Diagnosis Mode must run before another Debug Mode fix or Coder disp
 - **Tester Failure:** If Tester returns \`Test Result: fail\` with \`Test Infrastructure Status: none\`, \`repaired\`, or \`production-change-required\`, pause and report to the user. If required validation remains unavailable, ask whether the user explicitly approves retaining that exact Coverage Gap.
 - **Validation Revision:** If the validation-adequacy Gate returns \`request_changes\`, route the complete report to Tester. After Tester corrects tests or evidence, reruns validation, commits tracked Tester-owned changes, and replaces \`test-report.md\`, rerun the Gate.
 - **Tester Code-Diff Correction:** If every code-diff finding has \`Finding Scope: test-only\`, route the complete report to Tester. After correction, repeat Tester validation, validation-adequacy Gate, and \`code-diff --source architect-diagnosis\`.
-- **User-Approved Post-Validation Work:** After Tester returns \`pass\` and both Gates succeed, the user may explicitly approve additional Tester-owned work. Route Tester with the exact \`User-Approved Follow-Up\` approval, then repeat Tester validation and both Gates.
+- **Docs Code-Diff Correction:** If the code-diff findings are only \`docs-only\` (or \`docs-only\` and \`test-only\`), or the Gate fails to start with \`Docs coverage check failed:\`, route the report or message to Architect to correct the docs, then rerun \`code-diff --source architect-diagnosis\`.
+- **User-Approved Post-Validation Work:** After Tester returns \`pass\` and the validation-adequacy and code-diff Gates succeed, the user may explicitly approve additional Tester-owned work. Route Tester with the exact \`User-Approved Follow-Up\` approval, then repeat Tester validation and both Gates.
 - **Code-Diff Revision:** If any code-diff finding has \`Finding Scope: implementation\`, route the complete report to Architecture Diagnosis Mode. After correction, repeat Tester validation, validation-adequacy Gate, and \`code-diff --source architect-diagnosis\`.
 
 #### Successful Exit
 
 - An analysis-only Architecture Diagnosis Flow completes from the diagnosis result.
 - An analysis-only Architecture Diagnosis Branch returns to the recorded parent-flow resume point.
-- A code-producing Architecture Diagnosis Flow continues after code-diff approval to \`Architect docs sync -> Final Acceptance\`. Require \`.ai/vcm/handoffs/docs-sync-report.md\` from this docs-sync dispatch with \`Decision: synced\` or \`unchanged\` and \`Correction Owner: none\`; handle \`blocked\` through Docs Sync Correction.
-- A code-producing Architecture Diagnosis Branch returns after code-diff approval to the recorded parent-flow resume point after the parent flow's validation and code-diff milestones. It does not run its own docs sync or Final Acceptance.
+- A code-producing Architecture Diagnosis Flow continues after code-diff approval to Final Acceptance.
+- A code-producing Architecture Diagnosis Branch returns after code-diff approval to its root flow, which has then passed its validation and code-diff milestones: run the root flow's Final Acceptance next, and route its follow-ups in that flow. The branch never runs its own Final Acceptance.
 
 After Tester Failure, PM should summarize:
 
@@ -259,7 +266,7 @@ PM may leave this path only through the allowed branches below.
 
 The flow completes when the latest assigned role submits an accepted \`.ai/vcm/handoffs/docs-update-report.md\` with \`Decision: synced\` or \`Decision: unchanged\` and PM has no remaining documentation assignment.
 
-Docs-Only Flow does not run architecture-plan Gate Review, code-diff Gate Review, Tester validation, validation-adequacy Gate Review, separate post-validation docs sync, or Final Acceptance.
+Docs-Only Flow does not run architecture-plan Gate Review, code-diff Gate Review, Tester validation, validation-adequacy Gate Review, or Final Acceptance.
 
 ### Validation-Only Flow
 
@@ -295,7 +302,7 @@ The flow completes when:
 
 PM reports the Tester result to the user. A \`fail\` result remains a validation finding unless the accepted task outcome requires implementation repair.
 
-Validation-Only Flow does not run architecture-plan Gate Review, code-diff Gate Review, Architect docs sync, or Final Acceptance.
+Validation-Only Flow does not run architecture-plan Gate Review, code-diff Gate Review, or Final Acceptance.
 
 ### Communication-Only Flow
 
@@ -305,7 +312,7 @@ PM responds directly or relays the clarification to the active role.
 
 If the user confirms a new delivery request, PM selects the matching delivery flow.
 
-Communication-Only Flow does not run Gate Review, validation, docs sync, Final Acceptance, or PR-Preparation Flow.
+Communication-Only Flow does not run Gate Review, validation, Final Acceptance, or PR-Preparation Flow.
 
 ### Worktree
 
@@ -346,24 +353,24 @@ PM may lightly rewrite the user's words to:
 
 ### Flow Gates
 
-- In normal code-change flow, track the confirmed architecture brief, architecture plan, test report, docs-sync report, required Gate Review results, known-issues disposition when present, and final acceptance report.
-- In an Architect Debug Branch 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 an Architect Debug Flow or Architecture Diagnosis Flow that produces code changes, track the Architect result, test report, required Gate Review results, docs-sync report, and final acceptance report.
+- In normal code-change flow, track the confirmed architecture brief, architecture plan, test report, required Gate Review results, known-issues disposition when present, and final acceptance report.
+- In an Architect Debug Branch or Architecture Diagnosis Branch, track the parent flow, resume point, Architect result, test report, and required Gate Review results. The parent flow's final acceptance report follows the branch's code-diff approval; there is no branch-level final acceptance report.
+- In an Architect Debug Flow or Architecture Diagnosis Flow that produces code changes, track the Architect result, test report, required Gate Review results, and final acceptance report.
 - In Docs-Only Flow, complete only from an accepted \`docs-update-report.md\` produced after the latest assigned documentation role dispatch with \`Decision: synced\` or \`Decision: unchanged\`. In Validation-Only Flow, complete only from a complete \`test-report.md\` after the validation-adequacy Gate finishes successfully.
 - A Tester \`Test Result: incomplete\` is continuation state, not failure evidence. Route Tester again and do not run validation-adequacy Gate Review or Final Acceptance from it.
 - The Architect does not begin planning until \`architecture-brief.md\` is confirmed (this happens inside the same Architect Interview-and-planning turn, not a separate PM route). 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 Code-Change Flow, Architect Debug Flow, and an Architecture Diagnosis Flow that produces code changes, request Architect post-validation docs sync only after Tester validation, validation-adequacy Gate, and code-diff Gate complete. Architect Debug Branch and Architecture Diagnosis Branch return to their recorded resume points only after those same milestones complete.
+- In Code-Change Flow, Architect Debug Flow, and an Architecture Diagnosis Flow that produces code changes, request the code-diff Gate only after Tester validation and the validation-adequacy Gate complete, and start Final Acceptance only after the code-diff Gate approves. Architect Debug Branch and Architecture Diagnosis Branch return to their parent flow only after those same milestones complete.
 
 ### 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.
+- 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 — except a code-diff docs coverage failure, which follows the flow's docs correction branch.
 - Trigger points (run each unconditionally): after the architecture brief is confirmed and Architect completes planning, before coder dispatch run \`architecture-plan\`; after Tester returns a terminal \`Test Result: pass|fail\` that the active flow permits to reach the gate, run \`validation-adequacy\`; after that validation-adequacy Gate completes successfully, run \`code-diff --source coder\` for Coder implementation, \`code-diff --source architect-debug\` for an Architect Debug fix, or \`code-diff --source architect-diagnosis\` for an Architecture Diagnosis fix. A test report with \`Test Infrastructure Status: repair-required\` or \`production-change-required\` does not reach a Gate; route the matching allowed branch first. Validation-Only Flow stops after validation-adequacy and does not run code-diff. Never run either post-implementation Gate for \`Test Result: incomplete\`.
 - 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\` before Tester completes, while validation-adequacy is unresolved, or for incomplete, unresolved failed, planning-only, Docs-Only Flow, Validation-Only Flow, PR-Preparation Flow, or Communication-Only Flow. A terminal \`fail\` with the exact required user-approved testing gap may proceed only through the recorded validation-adequacy disposition.
 - Gate Review trigger points apply only when the active delivery flow reaches that milestone. Do not run Gate Review for Communication-Only Flow.
-- On a callback, accept only \`approve\` or \`request_changes\`. Apply \`request_changes\` through the allowed branch defined by the active flow; for code-diff, use Tester Code-Diff Correction only when every finding is \`test-only\`, otherwise use the flow's Architect correction branch.
+- On a callback, accept only \`approve\` or \`request_changes\`. Apply \`request_changes\` through the allowed branch defined by the active flow; for code-diff, use Tester Code-Diff Correction only when every finding is \`test-only\`, Docs Code-Diff Correction when the findings are only \`docs-only\` (or \`docs-only\` and \`test-only\`), and otherwise the flow's Architect correction branch.
 - Do not ask Reviewer to choose owners, fixes, Replan, or user-intervention needs.
 - Record gate decision, report path, and any skip or override reason.
 
@@ -377,10 +384,9 @@ PM may lightly rewrite the user's words to:
 ### Final Acceptance
 
 - Use the \`vcm-final-acceptance\` skill only to close a complete code-delivery flow, including Architect Debug Flow or an Architecture Diagnosis Flow that produced code changes.
-- Do not run Final Acceptance for Docs-Only Flow, Validation-Only Flow, Communication-Only Flow, PR-Preparation Flow, analysis-only Diagnosis, Architect Debug Branch, or Architecture Diagnosis Branch.
-- Start final acceptance only after Tester, required Gate Reviews, and required docs-sync gates pass, or explicit user approval is recorded for each exact exception. Gate Review skip or override is valid only when recorded by VCM from the user's action.
-- In any complete delivery flow, a blocked docs-sync report routes its exact Correction Owner before Final Acceptance; after that owner completes the correction, repeat every invalidated validation, Gate, and docs-sync step.
-- 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.
+- Do not run Final Acceptance for Docs-Only Flow, Validation-Only Flow, Communication-Only Flow, PR-Preparation Flow, analysis-only Diagnosis, or a Debug or Diagnosis Branch before its code-diff Gate approves; after that approval, run it for the parent flow.
+- Start final acceptance only after Tester and required Gate Reviews pass, with the code-diff approval covering the current HEAD commit, or explicit user approval is recorded for each exact exception. Gate Review skip or override is valid only when recorded by VCM from the user's action.
+- Confirm applicable evidence exists: architecture plan or architecture diagnosis when required, test result, required Gate Review decisions, 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.
 - In Code-Change Flow, handle every non-accepted decision through Final Acceptance Follow-Up. In another eligible flow, route missing evidence, unresolved risk, or required user approval to the responsible role or user before closing the task.
 
@@ -392,7 +398,7 @@ PM confirms the worktree is clean, prepares or updates the PR from existing task
 
 If required work or evidence is incomplete, return to the responsible flow or role before preparing the PR.
 
-PR-Preparation Flow does not perform technical review, validation, docs sync, Gate Review, or Final Acceptance.
+PR-Preparation Flow does not perform technical review, validation, documentation updates, Gate Review, or Final Acceptance.
 
 - Create a draft PR by default unless the user requests a ready PR.
 

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

@@ -3,9 +3,9 @@ export function renderVcmFinalAcceptanceSkillRules() {
 
 Use this skill only when project-manager is ready to close a complete VCM code-delivery flow, including Architect Debug Flow or an Architecture Diagnosis Flow that produced code changes.
 
-Do not use it for Docs-Only Flow, Validation-Only Flow, Communication-Only Flow, PR-Preparation Flow, analysis-only Diagnosis, Architect Debug Branch, or Architecture Diagnosis Branch.
+Do not use it for Docs-Only Flow, Validation-Only Flow, Communication-Only Flow, PR-Preparation Flow, or analysis-only Diagnosis. After an Architect Debug Branch or Architecture Diagnosis Branch passes its code-diff Gate, use it for the parent flow the branch returned to, auditing the whole task; never for a branch that has not passed its code-diff Gate.
 
-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.
+This skill is a final evidence audit. It does not replace architect documentation ownership, tester validation acceptance, coder implementation responsibility, or user approval for high-risk decisions.
 
 Project-manager must not use this skill to perform technical design review, implementation review, source-code analysis, or test adequacy analysis. Missing or conflicting evidence must be routed to the responsible role.
 
@@ -17,11 +17,10 @@ Read the relevant task evidence before deciding:
 - \`.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
 - \`.ai/vcm/gate-reviews/index.json\` and referenced Gate Review reports when Gate Reviews were required, skipped, or overridden
 - current \`git status\` and changed file list
-- relevant long-term docs only when needed to confirm that a docs-sync artifact exists and names the correct durable docs
+- the architecture plan's Docs Impact and the code-diff Gate's Documentation Fit result when durable docs could be affected
 
 ## Evidence Audit
 
@@ -29,7 +28,7 @@ Check whether the required role evidence exists, is current, and gives a clear r
 
 Acceptable evidence must show:
 
-- architect plan, architecture diagnosis, or docs-sync decision when required by the completed flow
+- architect plan or architecture diagnosis when required by the completed flow
 - tester terminal \`Test Result: pass|fail\` and validation evidence when code, behavior, tests, or generated context changed; \`incomplete\` is not acceptance evidence
 - required Gate Review decisions, skip reasons, or override reasons when Gate Reviews were enabled
 - known-issues disposition when unresolved findings were recorded
@@ -43,7 +42,7 @@ Review the changed file list only, then classify files:
 
 - 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 approval
+- approved deviations: files explained by Replan, a Debug or Diagnosis fix, tester follow-up, a post-validation docs correction, or explicit user approval
 - unexplained files: files with no traceable reason in the task evidence
 - high-risk unexpected files: auth, permissions, payment, billing, schema, migrations, data deletion, secrets, dependencies, lockfiles, broad generated artifacts, or broad formatting churn
 
@@ -61,9 +60,10 @@ Check:
 - tester report records terminal \`Test Result: pass|fail\`, validation commands, results, and skipped checks with reasons; do not accept \`Test Result: incomplete\`
 - required Gate Reviews are approved, or skipped/overridden through a VCM-recorded user action
 - 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 VCM-recorded user skip/override
-- docs-sync report records docs updated, docs intentionally left unchanged, or required follow-up when docs sync was required
-- when durable docs changed, docs-sync or tester evidence records a passing \`.ai/tools/check-durable-docs\` result and any cross-document inconsistency was resolved by the owning role
-- known issues are either resolved, promoted to durable docs by architect, or explicitly accepted by the user
+- the code-diff Gate approval covers the current HEAD commit, so every doc correction and follow-up commit was reviewed; a commit made after the approval requires rerunning the code-diff Gate before acceptance
+- \`.ai/tools/check-durable-docs\` passes when durable docs changed
+- any cross-document inconsistency was resolved by the owning role
+- known issues are either resolved, promoted to durable docs by architect, or explicitly accepted by the user; when \`docs/known-issues.md\` still needs a promotion or removal, decide \`needs-architect-follow-up\`
 - temporary task state is ready to clean after durable facts are promoted
 
 ## Decisions
@@ -74,10 +74,9 @@ Choose exactly one:
 - accepted-with-known-risks
 - needs-coder-follow-up
 - needs-architect-follow-up
-- needs-docs-sync
 - blocked-by-user-decision
 
-Do not accept when required role evidence is missing, required Gate Review evidence is missing, tester findings are unresolved, docs sync is missing for durable changes, the durable-doc audit failed or is missing after durable-doc changes, known-issues disposition is missing, or unexplained high-risk files remain.
+Do not accept when required role evidence is missing, required Gate Review evidence is missing, tester findings are unresolved, the code-diff approval does not cover the current HEAD, the durable-doc audit failed or is missing after durable-doc changes, known-issues disposition is missing, or unexplained high-risk files remain.
 
 ## Output
 
@@ -94,7 +93,7 @@ Use this structure:
 
 ## Decision
 
-accepted|accepted-with-known-risks|needs-coder-follow-up|needs-architect-follow-up|needs-docs-sync|blocked-by-user-decision
+accepted|accepted-with-known-risks|needs-coder-follow-up|needs-architect-follow-up|blocked-by-user-decision
 
 ## Evidence Reviewed
 
@@ -112,7 +111,7 @@ accepted|accepted-with-known-risks|needs-coder-follow-up|needs-architect-follow-
 
 ## Validation Summary
 
-## Review And Docs Sync
+## Review And Documentation
 
 ## Known Issues Disposition
 
@@ -123,7 +122,7 @@ accepted|accepted-with-known-risks|needs-coder-follow-up|needs-architect-follow-
 ## Final User Summary
 \`\`\`
 
-Each rewrite must be a complete, self-contained snapshot of the current acceptance decision and supporting evidence. Restate every still-relevant evidence result, file classification, validation result, Gate decision, docs-sync result, known-issues disposition, cleanup result, risk, and next action; do not rely on a prior acceptance revision, route message, Session, or transcript.
+Each rewrite must be a complete, self-contained snapshot of the current acceptance decision and supporting evidence. Restate every still-relevant evidence result, file classification, validation result, Gate decision, documentation result, known-issues disposition, cleanup result, risk, and next action; do not rely on a prior acceptance revision, route message, Session, or transcript.
 
 The final user summary should be concise and include files changed, validation, docs updates, open risks, and next action.
 `;

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

@@ -9,11 +9,11 @@ The only sanctioned long-running mechanism is \`.ai/tools/run-long-check\` plus
 
 Each run-long-check or watch-job invocation must be the only top-level command in its Bash tool call. Do not pipe it, append or prepend another command, place it in a conditional chain or subshell, capture it with command substitution, or invoke it through a shell command string. Ordinary redirection is allowed. A directly passed script such as \`-- bash /tmp/check.sh\` is allowed; \`-- bash -c '...'\` is not.
 
-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.
+The hard ceiling is 100 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
 
-1. Start the command with an explicit ceiling: \`.ai/tools/run-long-check --timeout <duration> -- <command>\`. Pass the validation executable and its arguments directly. Do not use a shell command-string wrapper, pipeline its output, or append another command: run-long-check already captures stdout/stderr, and shell wrappers can hide the validation exit code. Pick the ceiling from \`docs/TESTING.md\` guidance or a realistic estimate, never above 60m. The tool prints the job id and creates job state under \`.ai/vcm/jobs/<job-id>/\`.
+1. Start the command with an explicit ceiling: \`.ai/tools/run-long-check --timeout <duration> -- <command>\`. Pass the validation executable and its arguments directly. Do not use a shell command-string wrapper, pipeline its output, or append another command: run-long-check already captures stdout/stderr, and shell wrappers can hide the validation exit code. Pick the ceiling from \`docs/TESTING.md\` guidance or a realistic estimate, never above 100m. The tool prints the job id and creates job state under \`.ai/vcm/jobs/<job-id>/\`.
 2. In the same turn, run \`.ai/tools/watch-job <job-id>\` as its own Bash tool call. The default watch window is 8 minutes.
 3. If watch-job exits 125, the job is still running and a bounded handoff is active for the next watcher: run \`.ai/tools/watch-job <job-id>\` again immediately. Do not end the turn between windows.
 4. Repeat until watch-job reports a terminal result.

package/dist/backend/templates/harness/vcm-workflow-review-skill.js

@@ -65,7 +65,7 @@ VCM binds that authorization to this exact task state, flow, target role, eviden
 
 ## User-Approved Post-Validation Work
 
-When Tester has returned \`pass\`, validation-adequacy and code-diff are both successful, and the user explicitly approves additional Tester-owned work in the current task, propose Tester again with:
+When Tester has returned \`pass\`, the validation-adequacy and code-diff Gates are successful, Final Acceptance has not routed a follow-up, and the user explicitly approves additional Tester-owned work in the current task, propose Tester again with:
 
 \`\`\`text
 Authorization Text: none
@@ -73,7 +73,7 @@ Violated Rule: none
 Approval Text: <user's exact approval>
 \`\`\`
 
-This is a normal one-time follow-up approval, not a Workflow Override. Do not use it before both Gates are successful, for required unresolved coverage, for another owner, or without the user's exact approval. After Tester completes the approved work, rerun Tester validation and every invalidated Gate.
+This is a normal one-time follow-up approval, not a Workflow Override. Do not use it before those Gates are successful, for required unresolved coverage, for another owner, or without the user's exact approval. After Tester completes the approved work, rerun Tester validation and every invalidated Gate.
 
 ## Completion
 

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

@@ -5,6 +5,7 @@ export const GATE_REVIEW_GATES = [
 ];
 export const CODE_DIFF_FINDING_SCOPES = [
     "test-only",
+    "docs-only",
     "implementation"
 ];
 export const CODE_DIFF_SOURCES = [
@@ -12,3 +13,6 @@ export const CODE_DIFF_SOURCES = [
     "architect-debug",
     "architect-diagnosis"
 ];
+// Prefixes the code-diff error recorded when the Docs Impact coverage check
+// refuses to start the Gate; Workflow Control routes it to Architect.
+export const CODE_DIFF_DOCS_COVERAGE_ERROR_PREFIX = "Docs coverage check failed:";

package/dist/shared/types/workflow.js

@@ -12,7 +12,6 @@ export const WORKFLOW_EVIDENCE_ARTIFACTS = [
     "architect-debug.md",
     "architecture-diagnosis.md",
     "docs-update-report.md",
-    "docs-sync-report.md",
     "final-acceptance.md"
 ];
 export const WORKFLOW_EVIDENCE_GATES = [

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

@@ -1,4 +1,4 @@
-import { ARCHITECT_DEBUG_DISPOSITIONS, ARCHITECT_DEBUG_STATUSES, ARCHITECTURE_BRIEF_STATUSES, ARCHITECTURE_DIAGNOSIS_DISPOSITIONS, ARCHITECTURE_EVIDENCE_STATUSES, ARCHITECTURE_PLAN_RESULTS, CODER_COMPLETION_DECISIONS, DOCS_REPORT_DECISIONS, DOCS_UPDATE_COMMIT_PATTERN, DOCS_UPDATE_COMMIT_RULE, DOCS_SYNC_CORRECTION_OWNERS, FINAL_ACCEPTANCE_DECISIONS, L3_ACTIONS, L3_REQUIRED_VALUES, PLANNING_PROGRESS_STATUSES, STRICT_NONE_VALUE, TEST_INFRASTRUCTURE_STATUSES, TEST_RESULTS } from "./artifact-contract.js";
+import { ARCHITECT_DEBUG_DISPOSITIONS, ARCHITECT_DEBUG_STATUSES, ARCHITECTURE_BRIEF_STATUSES, ARCHITECTURE_DIAGNOSIS_DISPOSITIONS, ARCHITECTURE_EVIDENCE_STATUSES, ARCHITECTURE_PLAN_RESULTS, CODER_COMPLETION_DECISIONS, DOCS_REPORT_DECISIONS, DOCS_UPDATE_COMMIT_PATTERN, DOCS_UPDATE_COMMIT_RULE, FINAL_ACCEPTANCE_DECISIONS, L3_ACTIONS, L3_REQUIRED_VALUES, PLANNING_PROGRESS_STATUSES, STRICT_NONE_VALUE, TEST_INFRASTRUCTURE_STATUSES, TEST_RESULTS } from "./artifact-contract.js";
 import { getArtifactDefinition } from "./artifact-registry.js";
 const PLACEHOLDER_PATTERN = /(^|\n)\s*(TBD|Not run yet\.?|status:\s*draft)\s*(\n|$)/i;
 export function checkMarkdownArtifact(kind, artifactPath, content, options = {}) {
@@ -260,32 +260,6 @@ function validateArtifactFields(kind, content, mode) {
         }
         return invalidFields;
     }
-    if (kind === "docs-sync-report") {
-        const invalidFields = validateDecision(content, DOCS_REPORT_DECISIONS);
-        const decision = readArtifactSectionContent(content, "Decision")?.trim().toLowerCase();
-        const owner = readArtifactSectionContent(content, "Correction Owner")?.trim().toLowerCase();
-        const evidence = readArtifactSectionContent(content, "Correction Evidence");
-        if (!isAllowedValue(owner, DOCS_SYNC_CORRECTION_OWNERS)) {
-            invalidFields.push(renderExactSectionError("Correction Owner", DOCS_SYNC_CORRECTION_OWNERS.join("|"), owner));
-        }
-        if (decision === "synced" || decision === "unchanged") {
-            if (owner !== "none") {
-                invalidFields.push(renderExactSectionError("Correction Owner", "none", owner, `when Decision is ${decision}`));
-            }
-            if (!isExactNone(evidence)) {
-                invalidFields.push(renderExactSectionError("Correction Evidence", STRICT_NONE_VALUE, evidence, `when Decision is ${decision}`));
-            }
-        }
-        if (decision === "blocked") {
-            if (!owner || owner === "none") {
-                invalidFields.push("Correction Owner must be architect, coder, or tester when Decision is blocked.");
-            }
-            if (!hasSubstantiveSectionValue(evidence)) {
-                invalidFields.push("Correction Evidence must identify the unresolved documentation correction when Decision is blocked.");
-            }
-        }
-        return invalidFields;
-    }
     if (kind === "final-acceptance") {
         return validateDecision(content, FINAL_ACCEPTANCE_DECISIONS);
     }

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

@@ -32,13 +32,11 @@ export const L3_ACTIONS = ["run-existing", "updated", "added"];
 export const DOCS_REPORT_DECISIONS = ["synced", "unchanged", "blocked"];
 export const DOCS_UPDATE_COMMIT_PATTERN = /^[0-9a-f]{7,40}$/;
 export const DOCS_UPDATE_COMMIT_RULE = "When Decision is synced, Commit must contain only one bare lowercase hexadecimal commit hash (7-40 characters, for example abc1234) on a single line. No backticks, bullets, links, subjects, or extra lines; put explanations in Evidence Reviewed. An unchanged result does not require a new commit.";
-export const DOCS_SYNC_CORRECTION_OWNERS = ["none", "architect", "coder", "tester"];
 export const FINAL_ACCEPTANCE_DECISIONS = [
     "accepted",
     "accepted-with-known-risks",
     "needs-coder-follow-up",
     "needs-architect-follow-up",
-    "needs-docs-sync",
     "blocked-by-user-decision"
 ];
 export function renderArtifactOptions(values) {

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

@@ -172,23 +172,6 @@ export const ARTIFACT_DEFINITIONS = [
             "Decision"
         ]
     },
-    {
-        kind: "docs-sync-report",
-        fileName: "docs-sync-report.md",
-        owner: "architect",
-        requiredHeadings: [
-            "Summary",
-            "Architecture Drift Check",
-            "Docs Updated",
-            "Docs Reviewed And Left Unchanged",
-            "Public Contract / Module Boundary Notes",
-            "Remaining Documentation Risks",
-            "Known Issues Disposition",
-            "Correction Owner",
-            "Correction Evidence",
-            "Decision"
-        ]
-    },
     {
         kind: "workflow-progress",
         fileName: "workflow-progress.md",
@@ -209,7 +192,7 @@ export const ARTIFACT_DEFINITIONS = [
             "Evidence Reviewed",
             "Scope Traceability",
             "Validation Summary",
-            "Review And Docs Sync",
+            "Review And Documentation",
             "Known Issues Disposition",
             "Gate Review Gates",
             "Cleanup Readiness",

package/package.json

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