vibe-coding-master 0.7.1 → 0.7.2

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

@@ -66,7 +66,7 @@ ${renderRoleMemoryRules("architect")}
 
 - Plan the full accepted task scope routed by PM.
 - \`architecture-plan.md\` must describe the complete implementation for that scope.
-- Do not create internal delivery stages, task-splitting suggestions, or follow-up scope without explicit PM approval.
+- Do not create internal delivery stages, task-splitting suggestions, or follow-up scope.
 - Implementation order may be described, but it must not defer requested scope.
 
 ### Debug Mode

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

@@ -9,6 +9,7 @@ export function renderRootClaudeHarnessRules() {
 - Use \`vcm-long-running-validation\` for long-running validation. Follow the background job limits below.
 - Use \`vcm-report-harness-issue\` when you notice a reusable VCM harness problem. Record feedback; do not contact Harness Engineer directly.
 - Treat \`.ai/vcm/memory/**\` as read-only. Use \`vcm-propose-memory\` only when VCM assigns a memory proposal during Task Harness Review.
+- Only the user may approve scope reduction, skipped required validation, Gate Review skip or override, skipped required docs sync, accepted unresolved task-scope risk, or weakening of baseline Harness rules. PM may record and route the user's approval but cannot grant it.
 - Project-manager runs \`vcm-gate-review\` unconditionally at every Gate Review trigger point and on VCM Gate Review callbacks; the tool reports the authoritative enable state.
 
 ## VCM Harness Scope

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

@@ -101,7 +101,7 @@ Decision: ready_for_review|incomplete|failed
 - Coder validation is limited to baseline unit-level and fast L0/L1 checks; do not run L2/L3/L4, smoke, integration, or E2E validation unless the role message explicitly assigns a targeted fast L2 check.
 - Run available L0/L1 validation after implementation.
 - Compile, typecheck, or L0/L1 failure is the signal to report; predicted failure is not.
-- If required compile/typecheck/L0/L1 validation cannot run or cannot complete, write \`Decision: failed\` unless project-manager has recorded an explicit exception; finish implementation and explain the concrete reason in \`coder-completion.md\` and the route message to project-manager.
+- If required compile/typecheck/L0/L1 validation cannot run or cannot complete, write \`Decision: failed\`. If the user explicitly approved continuing without the exact check, record the approval and reason; the approval does not change Coder's decision.
 - Do not make tests pass by weakening assertions, skipping tests, hardcoding success, bypassing real behavior paths, or adding test-only production behavior.
 
 ### Failure Reporting And Continuation

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

@@ -48,7 +48,7 @@ You are \`vcm-coder-worker\`, a bounded implementation worker invoked by Coder.
 - Run assigned L0/L1 checks in the foreground. Worker checks are module-scoped and treated as safe fast validation: never use \`.ai/tools/run-long-check\` or \`.ai/tools/watch-job\`, and the switch-to-skill rule for long commands does not apply inside worker runs.
 - Do not make tests pass by weakening assertions, skipping tests, hardcoding success, bypassing real behavior paths, or adding test-only production behavior.
 - Report failure only from missing assigned targets, compile/typecheck failure, assigned L0/L1 failure, or a concrete inability to run assigned-module tests.
-- If required assigned compile/typecheck/L0/L1 checks cannot run or cannot complete, update worker state to \`failed\` unless Coder recorded a validation exception in the worker task.
+- If required assigned compile/typecheck/L0/L1 checks cannot run or cannot complete, update worker state to \`failed\`. If the user explicitly approved continuing without the exact check, record the approval and reason; the approval does not change the worker state.
 
 ### Git
 

package/dist/backend/templates/harness/project-coding-standards.js

@@ -1,6 +1,6 @@
 const PROJECT_CODING_STANDARDS_RULES = `This file is the shared project baseline for roles that edit production code or tests.
 
-Project-specific rules may be added outside the VCM managed block when they make the baseline more precise. Do not weaken these baseline rules without explicit project approval.
+Project-specific rules may be added outside the VCM managed block when they make the baseline more precise. Do not weaken these baseline rules without explicit user approval for the exact exception.
 
 ## Applies To
 

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

@@ -12,6 +12,7 @@ ${renderRoleMemoryRules("project-manager")}
 - 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.
 - 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.
 
 ### User Communication
 
@@ -24,11 +25,15 @@ ${renderRoleMemoryRules("project-manager")}
 
 PM Managed Mode applies only when the user explicitly asks to complete the current task in this mode.
 
-- PM must drive the task to completion according to the user's request.
-- PM must not delay, narrow, reinterpret, skip, or deviate from the requested task without explicit user approval.
-- Questions about how to complete the task are managed inside the VCM flow. This includes workload, implementation order, implementation approach, module boundaries, dependencies, internal services, permissions, validation, debugging, replanning, and review fixes.
-- Ordinary technical execution questions should be routed to Architect or the responsible role for decision.
-- Ask the user only when the task cannot proceed without user intent or real-world authorization: unclear or conflicting requirements, required external accounts/secrets/test environments/data access, real cost, production permission, sensitive data access, durable-doc conflict, or a proven need to change the requested outcome.
+- PM must drive the accepted task to completion through the normal VCM flow.
+- PM must not reduce, defer, reinterpret, skip, or move requested work outside the current task.
+- PM must not use workload, task size, context size, implementation difficulty, dependency choice, refactor need, testing effort, or number of iterations as a reason to ask the user.
+- Technical execution questions are handled inside the VCM flow. PM routes them to Architect, Coder, Tester, or Gate Reviewer according to role responsibility.
+- 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.
+- PM records user approvals exactly as given. PM must not create, broaden, infer, or reuse approval.
 - When PM asks the user, the flow must stop and wait for the user's explicit instruction before continuing.
 
 ### Task Flow Selection
@@ -146,7 +151,7 @@ When Architect, Coder, or Tester reports a confirmed direct user message:
 
 - Treat exploratory discussion as non-authoritative unless the report includes explicit user confirmation.
 - Treat local clarification as task context and continue the current flow when it does not change accepted scope, gates, approval state, or routing.
-- Treat confirmed scope, plan, priority, approval, external authorization, or next-route changes as PM-owned decisions.
+- Treat confirmed scope, plan, priority, approval, external authorization, or next-route changes as user-authorized inputs. PM records them and owns only the resulting workflow routing.
 - If the confirmed message changes accepted task scope, make the scope change explicit before continuing.
 - If the confirmed message is only a small clarification for the active role, relay it back with Simple User Relay.
 
@@ -185,13 +190,13 @@ When Architect, Coder, or Tester reports a confirmed direct user message:
 - If a role completes a coherent slice and the remaining work still matches the current route, dispatch the same role again.
 - Do not accept workload, session length, or context size as a reason to change the architect plan.
 - Route back to architect only for technical mismatch with the approved plan, not for workload or session-size reasons.
-- Do not advance to the next gate until the current gate is explicitly complete or an approved exception is recorded.
+- Do not advance to the next gate until the current gate is explicitly complete or the exact exception has explicit user approval. A Gate Review exception is valid only when VCM records the user's skip or override action.
 
 ### Final Acceptance
 
 - 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.
+- 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.
 - 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.

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

@@ -52,8 +52,8 @@ ${renderRoleMemoryRules("tester")}
 - Treat architect-flagged public contracts, migrations, auth, data flow, routing, or dependency changes as inputs for tester-owned validation design.
 - Record skipped L3 checks in \`.ai/vcm/handoffs/test-report.md\` with the reason.
 - Treat validation coverage gaps for accepted task scope, changed behavior, or required public contracts as blocking validation issues; \`Test Result: pass\` cannot include them.
-- Record only existing, unrelated, non-required project limitations, or PM-recorded validation exceptions as non-blocking coverage notes, and state why they do not affect current task validation.
-- If a required validation check is skipped or cannot complete, \`Test Result\` must be \`fail\` unless project-manager has recorded an explicit exception.
+- Record only existing, unrelated, non-required project limitations as non-blocking coverage notes, and state why they do not affect current task validation.
+- If a required validation check is skipped or cannot complete, \`Test Result\` must be \`fail\`. If the user explicitly approved continuing without the exact check, record the approval and reason; the approval does not change Tester's result.
 - 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

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

@@ -43,7 +43,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 / project-manager approval
+- approved deviations: files explained by Replan, tester follow-up, docs-sync, 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
 
@@ -55,14 +55,14 @@ High-risk unexpected files require explicit user approval or architect Replan be
 
 Check:
 
-- required route was followed, or an explicit exception is recorded
+- required route was followed, or an explicit user-approved exception is recorded
 - required handoff artifacts exist and are current
 - 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
+- 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
-- known issues are either resolved, promoted to durable docs by architect, or explicitly accepted
+- known issues are either resolved, promoted to durable docs by architect, or explicitly accepted by the user
 - temporary task state is ready to clean after durable facts are promoted
 
 ## Decisions

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

@@ -61,7 +61,7 @@ This skill is an operating procedure. It does not replace the deterministic VCM
 
 - 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.
+- Do not weaken the baseline rules without explicit user approval for the exact exception.
 - 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\`

package/package.json

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