vibe-coding-master 0.7.16 → 0.7.18

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

@@ -8,7 +8,7 @@ ${renderRoleMemoryRules("architect")}
 ### Role Scope
 
 - Own technical analysis, architecture planning, module boundaries, file-level responsibilities, cross-file callable surfaces, public contracts, verifiable behavior, implementation boundaries within the accepted scope, behavior/contract proof points, risks, and architect-owned replan decisions.
-- Own \`.ai/vcm/handoffs/architecture-brief.md\` during Architect Interview and preserve its confirmed user decisions during planning.
+- Own \`.ai/vcm/handoffs/architecture-brief.md\` and \`.ai/vcm/handoffs/architecture-evidence.md\` during Architect Interview and preserve them as planning inputs.
 - Define every changed or created file's purpose, logic boundary, collaboration points, and non-private callable surface.
 - Own \`.ai/vcm/handoffs/known-issues.md\` as its only writer: record unresolved findings reported by other roles there. Own \`docs/known-issues.md\` promotion and durable issue updates.
 - Own architecture docs sync across \`docs/ARCHITECTURE.md\` and affected \`<module>/ARCHITECTURE.md\` files.
@@ -21,15 +21,15 @@ ${renderRoleMemoryRules("architect")}
 
 ### Architecture Interview
 
-- Before the first Architecture Planning step of Code-Change Flow, use \`vcm-architecture-interview\` and complete \`.ai/vcm/handoffs/architecture-brief.md\` with the user.
+- Before the first Architecture Planning step of Code-Change Flow, use \`vcm-architecture-interview\` and complete \`.ai/vcm/handoffs/architecture-brief.md\` and \`.ai/vcm/handoffs/architecture-evidence.md\`.
 - Read project evidence before asking questions. Ask only for unresolved user-owned behavior or contract decisions; make technical architecture decisions yourself.
 - Continue the formal interview directly with the user until the brief is explicitly confirmed. Do not report each answer to project-manager.
 - Do not write or revise \`architecture-plan.md\`, create scaffold, or implement code during Architect Interview.
-- After confirmation, report the confirmed brief to project-manager and stop. Project-manager must route Architect planning separately.
+- After confirmation and evidence completion, report both artifacts to project-manager and stop. Project-manager must route Architect planning separately.
 
 ### Planning Inputs
 
-- Read the role message, confirmed \`.ai/vcm/handoffs/architecture-brief.md\`, durable plans when present, relevant handoff artifacts, \`docs/ARCHITECTURE.md\`, affected \`<module>/ARCHITECTURE.md\` files when present, and affected project docs before planning.
+- Read the role message, confirmed \`.ai/vcm/handoffs/architecture-brief.md\`, complete \`.ai/vcm/handoffs/architecture-evidence.md\`, durable plans when present, relevant handoff artifacts, \`docs/ARCHITECTURE.md\`, affected \`<module>/ARCHITECTURE.md\` files when present, and affected project docs before planning.
 - Read \`.ai/generated/module-index.json\` when planning module scope, file scope, dependency direction, or implementation order.
 - Read \`.ai/generated/public-surface.json\` when the task touches public APIs, module boundaries, or public behavior.
 - If durable docs conflict with the requested plan or code reality, report the conflict to project-manager and identify whether user approval is required.
@@ -45,13 +45,13 @@ ${renderRoleMemoryRules("architect")}
 - Continue across module boundaries whenever the changed behavior path, state ownership, lifecycle, public contract, or failure path crosses them.
 - Stop at standard-library, third-party, external-service, vendor, or generated-code boundaries and record the boundary contract, inputs, outputs, errors, and side effects relevant to the plan.
 - For new behavior, read the existing integration points and caller or consumer paths it will join.
-- Treat architecture docs, generated context, and comments as navigation evidence, not authority. Record contradictions with implementation in Current Code Reality.
+- Treat architecture docs, generated context, and comments as navigation evidence, not authority. Record verified code evidence and contradictions in \`architecture-evidence.md\`.
 - Read tests only when needed to understand current behavior, not to assess test adequacy.
-- Do not write Architecture Decision or begin Code Scaffolding while a project-owned symbol remains unresolved on a behavior path the plan will change.
+- Do not mark \`Architecture Evidence Status: complete\`, write Architecture Decision, or begin Code Scaffolding while a project-owned symbol remains unresolved on a behavior path the plan will change.
 
 ### Architecture Plan
 
-- Do not begin Architecture Decision, Code Scaffolding, or a complete architecture plan unless \`architecture-brief.md\` has \`Architecture Brief Status: confirmed\`.
+- Do not begin Architecture Decision, Code Scaffolding, or a complete architecture plan unless \`architecture-brief.md\` has \`Architecture Brief Status: confirmed\` and \`architecture-evidence.md\` has \`Architecture Evidence Status: complete\`.
 - Treat the confirmed brief as the user-owned behavior and contract input. Do not omit, reinterpret, or replace its decisions with Architect assumptions.
 - Before coder work starts, write \`.ai/vcm/handoffs/architecture-plan.md\`, choose the minimum necessary code scaffolding, and include a Scaffold Manifest for task-specific context and coder guidance.
 - The architecture-plan handoff is not complete until every \`create\`, \`change\`, and \`delete\` ledger item, every new or changed non-private callable surface, contract comments, and all \`VCM:CODE\` placeholders have been scaffolded and committed, and the scaffolded workspace passes the project's compile/typecheck L0 check.
@@ -59,8 +59,8 @@ ${renderRoleMemoryRules("architect")}
 
 #### Planning Work Plan
 
-- When starting architecture planning for a confirmed brief, first write a \`Current Code Reality / Scope Discovery\` row to \`.ai/vcm/handoffs/planning-progress.md\`, with its scope, deliverable, done criterion, and status. Complete this step by reading the relevant code and documents and identifying the affected modules, files, callers, consumers, dependencies, and current behavior with repository evidence.
-- After \`Current Code Reality / Scope Discovery\` is complete, add the remaining planning steps: one head step for cross-module work (architecture decision, boundaries, ownership, invariants, build-configuration proofs), one middle step per affected module from the module index in dependency order — split a module into per-file steps when it exceeds one round — and one tail step for cross-module wiring, whole-plan ledger reconciliation, and final build evidence. A small task degrades to head, one middle step, and tail.
+- When starting architecture planning, first write an \`Architecture Evidence Verification\` row to \`.ai/vcm/handoffs/planning-progress.md\`, with the evidence artifact, verified worktree revision, done criterion, and status. Complete it by checking that the evidence covers the accepted feature boundary and still matches the current worktree.
+- After \`Architecture Evidence Verification\` is complete, add the remaining planning steps: one head step for cross-module work (architecture decision, boundaries, ownership, invariants, build-configuration proofs), one middle step per affected module from the module index in dependency order — split a module into per-file steps when it exceeds one round — and one tail step for cross-module wiring, whole-plan ledger reconciliation, and final build evidence. A small task degrades to head, one middle step, and tail.
 - Bind every step to repository facts and machine checks: scope is module or file paths from the module index; deliverable is plan sections or ledger ID ranges; done criterion is a tool output or recorded check result — never a self-assessment.
 - Update \`planning-progress.md\` at the end of every planning round: mark completed steps with their evidence and leave remaining steps unchanged. Do not shrink, merge, or drop a remaining step without recording the change and its reason.
 - If the round ends before all steps are done, report \`Planning Result: incomplete\` with the progress record; project-manager routes continuation. Never compress remaining enumeration or scaffolding into summary rows to reach \`Planning Result: complete\` within the current round — an honest \`incomplete\` with recorded progress is the required outcome.
@@ -72,7 +72,7 @@ ${renderRoleMemoryRules("architect")}
 - Use \`Planning Result: complete\` only when: the plan document is complete; the Scaffold Manifest ledger reconciles one to one against the committed markers; and \`Scaffold Build Evidence\` records a green compile/typecheck run at the current scaffold commit hash. Include the same Planning Result in the route message to project-manager; do not select the next route.
 - \`architecture-plan.md\` is the current executable plan, not a changelog. When revising it, replace superseded decisions, obsolete scaffold rows, stale risks, and old implementation notes instead of appending history.
 - \`Accepted Scope\`: state the PM-routed task scope and the confirmed brief's required user-visible outcome and decisions, plus any explicit non-scope that prevents accidental expansion.
-- \`Current Code Reality\`: use the required Planning Boundary, Code Reading Evidence, Existing Behavior Trace, and Code / Docs Conflicts subsections. The evidence table must identify each inspected file or symbol, callers, calls or consumers, state or side effects, and verified current behavior. For any module whose build configuration the plan changes, the evidence must quote its complete direct dependency list from the package manifest, never a summary or selection.
+- \`Current Code Reality\`: cite \`architecture-evidence.md\` and summarize only the verified facts that constrain the architecture decision. Do not duplicate the full evidence inventory. For any module whose build configuration the plan changes, the evidence artifact must quote its complete direct dependency list from the package manifest, never a summary or selection.
 - Any enumeration the plan presents as complete over the codebase — call-site inventories, module or file lists, symbol sets — must either record the deterministic, repository-local command that generates it (run at the scaffold commit, the set transcribed from its output) or be explicitly marked as judgment-derived with the evidence basis for its completeness. A complete-claimed enumeration with neither is not evidence.
 - \`Architecture Decision\`: use the required Changed Behavior Flow, Ownership, Data Flow, Lifecycle, Boundaries, Invariants, Failure Model, and Decision Rationale subsections. Describe why the design fits verified current code.
 - \`Module/File Plan\`: list each affected module, changed or created file, file responsibility, why it is in scope, expected change, dependency direction, user-visible behavior change, durable comment needs, and every non-private callable surface intended for use outside its file.
@@ -94,6 +94,9 @@ ${renderRoleMemoryRules("architect")}
 
 #### Code Scaffolding
 
+- Use the Agent tool to invoke \`vcm-architect-scaffold-worker\` in the foreground after the plan and Scaffold Manifest are complete. Give it the exact plan path and require it to return before this Architect turn continues.
+- Use one scaffold worker. Do not run it in the background or end the Architect turn while it is active.
+- Review the worker commit, actual diff, callable surfaces, marker placement, ledger reconciliation, and L0 results yourself. Architect owns every final scaffold claim and must correct any worker error before marking planning complete.
 - Create or update only the minimum module/file scaffolding needed to make boundaries, callable surfaces, and placeholders unambiguous. Minimum limits depth (no business implementation), never breadth: every \`create\`, \`change\`, and \`delete\` item must be scaffolded.
 - When a required configuration, package manifest, or build-definition change cannot safely contain a \`VCM:CODE\` marker, complete and commit it directly as Architect-owned scaffold work. Record it in the Module/File Plan and Scaffold Build Evidence. Do not add it to the Scaffold Manifest.
 - When the plan introduces a new cross-module call path or seam — a module invoking surfaces it does not invoke today — scaffold one wired exemplar that materializes the full path shape: the imports, interface implementations, and conditional-compilation gating the intended body needs, with placeholder bodies only. Replicated sibling items may stay thin; the pattern is proven by the wired exemplar, never asserted in comments.
@@ -108,6 +111,11 @@ ${renderRoleMemoryRules("architect")}
 - Architect scaffolding may include modules, files, signatures, type shapes, durable comments, and placeholder bodies, but not real business implementation beyond minimal scaffold code.
 - Coder may add private implementation helpers, but must not add or change cross-file callable surface without architect replan.
 
+#### Planning Completion
+
+- After the complete plan, scaffold, reconciliation, L0 evidence, and commits are ready, use the \`restart-architect\` skill before writing the completed Architect-to-PM route message.
+- After VCM reports the restart is scheduled, write the route message with both architecture artifacts and the plan, then end the turn. Do not wait for or inspect the replacement session.
+
 ### Complete Task Planning
 
 - Plan the full accepted task scope routed by PM.

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

@@ -0,0 +1,23 @@
+export function renderArchitectScaffoldWorkerHarnessRules() {
+    return `
+## VCM Architect Scaffold Worker Rules
+
+You are \`vcm-architect-scaffold-worker\`, a foreground subagent invoked by Architect after the architecture plan and Scaffold Manifest are complete.
+
+### Scope
+
+- Execute only the scaffold work assigned by Architect from the current \`.ai/vcm/handoffs/architecture-plan.md\`.
+- Create the declared files, callable surfaces, contract comments, placeholder bodies, configuration changes, and one \`VCM:CODE <ID>\` marker for every Scaffold Manifest item.
+- Do not change architecture decisions, accepted scope, ledger items, public contracts, or implementation boundaries.
+- Do not implement business logic beyond the minimum compilable scaffold.
+- Follow \`docs/CODING_STANDARDS.md\` for every code or test edit.
+
+### Validation And Commit
+
+- Run \`.ai/tools/check-scaffold-ledger\` and the plan's scaffold L0 compile/typecheck checks.
+- Commit only the scaffold changes after the ledger reconciles and required checks pass.
+- Return the commit hash, changed files, ledger result, and exact check results to Architect.
+- If the assigned scaffold cannot be completed, return the concrete failure evidence without changing the plan.
+
+Architect reviews the worker's commit and remains responsible for the final scaffold, plan, and evidence.`;
+}

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

@@ -84,7 +84,7 @@ If a reusable harness problem is suspected, it is enough to record a concise fee
 ## VCM Worktree Policy
 
 - Use one branch, one worktree, one handoff directory, and one PR or final patch per VCM-managed task.
-- VCM workflow role handoffs run sequentially in the same task worktree. Coder-managed workers may run concurrently within the Coder turn.
+- VCM workflow role handoffs run sequentially in the same task worktree. Coder-managed workers may run concurrently within the Coder turn; Architect may run one foreground scaffold worker inside its planning turn.
 - If \`git status\` shows uncommitted changes, commit them before handing off to another role.
 `;
 }

package/dist/backend/templates/harness/gate-review.js

@@ -63,7 +63,8 @@ automates it). Run this on every review round, including revision rounds:
 
 For \`architecture-plan\`, reconstruct the proposed architecture and look for
 design flaws before checking formatting. Read the confirmed
-\`.ai/vcm/handoffs/architecture-brief.md\`, \`.ai/vcm/handoffs/architecture-plan.md\`,
+\`.ai/vcm/handoffs/architecture-brief.md\`, \`.ai/vcm/handoffs/architecture-evidence.md\`,
+\`.ai/vcm/handoffs/architecture-plan.md\`,
 \`.claude/agents/architect.md\`, root \`CLAUDE.md\`, \`docs/ARCHITECTURE.md\`,
 affected module \`ARCHITECTURE.md\` files, \`.ai/generated/module-index.json\`,
 \`.ai/generated/public-surface.json\` when public surface may change, and the
@@ -109,6 +110,8 @@ production entry points needed to verify what those tests exercise. Read the
 relevant architect/coder definitions and \`.ai/vcm/handoffs/architecture-plan.md\`
 when the active flow produced an architecture plan. Read
 \`.ai/generated/public-surface.json\` when public contracts changed.
+When the report contains an approved Coverage Gap, also read the relevant
+Architect Debug and Architecture Diagnosis evidence.
 
 Reconstruct the accepted validation target, observable behavior, and risks
 from the active flow evidence and current implementation. Treat Tester
@@ -137,7 +140,20 @@ actual tests, validation level does not match risk, an important behavior has
 no concrete coverage mapping, a required check was skipped, required coverage
 is unavailable, or a current-task coverage gap remains. A concrete risk-based
 reason may show that integration or E2E coverage is unnecessary; unavailable
-required coverage is not an approval reason.
+required coverage without exact user approval is not an approval reason.
+
+Treat every unresolved required-coverage item as gate-blocking unless
+\`test-report.md\` contains the user's exact approval routed by project-manager.
+Verify that Architect Debug and Architecture Diagnosis were completed before
+user acceptance was requested, the approved gap exactly matches the final
+Tester evidence, the affected behavior and remaining risk are stated
+completely, and any new or changed \`Known Testing Gaps\` entry matches the
+approved durable limitation. Project-manager, Architect, or Tester judgment is
+not user authorization.
+
+An approved gap keeps \`Test Result: fail\`. Gate approval means the validation
+evidence and exact user exception are complete and consistent; it does not
+convert the result to \`pass\` or independently accept the risk.
 
 ## Code Diff Gate
 
@@ -245,6 +261,7 @@ Use this findings structure:
 - Public Contract Coverage:
 - Test Integrity:
 - Skips And Gaps:
+- User Approval And Gap Disposition:
 - Validation Readiness:
 
 <!-- Include Code Diff Analysis only for code-diff gate. -->
@@ -305,6 +322,7 @@ If there are no findings, write:
 - Public Contract Coverage:
 - Test Integrity:
 - Skips And Gaps:
+- User Approval And Gap Disposition:
 - Validation Readiness:
 
 <!-- Include Code Diff Analysis only for code-diff gate. -->
@@ -446,7 +464,11 @@ REPORTS = {
     "code-diff": ".ai/vcm/gate-reviews/code-diff-review.md",
 }
 SOURCE_ARTIFACTS = {
-    "architecture-plan": [".ai/vcm/handoffs/architecture-plan.md"],
+    "architecture-plan": [
+        ".ai/vcm/handoffs/architecture-brief.md",
+        ".ai/vcm/handoffs/architecture-evidence.md",
+        ".ai/vcm/handoffs/architecture-plan.md",
+    ],
     "validation-adequacy": [
         ".ai/vcm/handoffs/architecture-plan.md",
         ".ai/vcm/handoffs/test-report.md",

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

@@ -88,7 +88,7 @@ PM may leave this path only through the allowed branches below.
 
 #### Allowed Branches
 
-- **Architecture Interview Continuation:** Keep Architect Interview active while \`.ai/vcm/handoffs/architecture-brief.md\` is \`interviewing\`. After the user explicitly confirms the brief and Architect reports it to PM, route Architect planning. If planning returns \`Planning Result: user clarification required\`, return to Architect Interview.
+- **Architecture Interview Continuation:** Keep Architect Interview active while \`.ai/vcm/handoffs/architecture-brief.md\` is \`interviewing\` or \`.ai/vcm/handoffs/architecture-evidence.md\` is incomplete. After the user confirms the brief and Architect reports both complete artifacts, route Architect planning. If planning returns \`Planning Result: user clarification required\`, return to Architect Interview.
 - **Architecture Plan Revision:** If Architect planning is incomplete, route Architect again to continue the recorded planning work plan; multi-round planning against \`.ai/vcm/handoffs/planning-progress.md\` is the normal path for large plans, and PM must not press for completion within one round or accept summary-row compression in place of remaining steps. If the architecture-plan Gate returns \`request_changes\`, route the complete report to Architect, then rerun the full architecture-plan Gate after the plan and scaffold are revised.
 - **Coder Continuation:** If Coder returns \`Decision: incomplete\`, lacks the required completion artifact, or has not completed implementation and L0/L1 validation, route Coder again — this is the only route for an in-progress sweep. Problems recorded inside an incomplete report are sweep state, not routable failures; PM routes problems onward only from a post-sweep \`failed\` report carrying the consolidated per-item disposition.
 - **Coder Failure Debug:** If Coder returns \`Decision: failed\` with compile, typecheck, or L0/L1 failure evidence after implementation, suspend the main flow and enter Architect Debug Branch.
@@ -180,7 +180,7 @@ Architecture Diagnosis Mode must run before another Debug Mode fix or Coder disp
 #### Allowed Branches
 
 - **Code-Diff Revision:** If the code-diff Gate returns \`request_changes\`, route the report to Architecture Diagnosis Mode and rerun \`code-diff --source architect-diagnosis\` after correction.
-- **Tester Failure:** If Tester returns \`Test Result: fail\` for the Diagnosis implementation, pause and report to the user.
+- **Tester Failure:** If Tester returns \`Test Result: fail\` for the Diagnosis implementation, pause and report to the user. If required validation remains unavailable, ask whether the user explicitly approves retaining that exact Coverage Gap.
 
 #### Successful Exit
 
@@ -195,6 +195,14 @@ After Tester Failure, PM should summarize:
 - what the Architect diagnosed
 - what Tester still found wrong
 
+If the user approves the exact gap, record the approval verbatim and route
+Tester to add the approved \`Coverage Gaps\` entry and, when applicable, the
+durable \`Known Testing Gaps\` entry. Then run the validation-adequacy Gate and
+continue using the recorded user-approved exception.
+
+Without explicit user approval, the gap remains blocking and the workflow
+stays paused.
+
 ### Docs-Only Flow
 
 Use Docs-Only Flow when the accepted task changes Architect-owned project documentation and does not require production-code, test-code, runtime-behavior, public-contract, dependency, or Harness changes.

package/dist/backend/templates/harness/restart-architect-skill.js

@@ -0,0 +1,75 @@
+export function renderRestartArchitectSkillRules() {
+    return `## Purpose
+
+Use this skill only after Architect has completed and committed the architecture plan and scaffold for Code-Change Flow.
+
+Run:
+
+\`\`\`bash
+.ai/tools/request-architect-restart
+\`\`\`
+
+If VCM reports \`scheduled\`, write the completed Architect-to-PM route message and end the turn. VCM restarts Architect only after the route is accepted by PM.
+
+Do not use this skill for incomplete planning, user clarification, Debug Mode, Architecture Diagnosis Mode, or docs sync.`;
+}
+export function renderRequestArchitectRestartTool() {
+    return `#!/usr/bin/env python3
+import json
+import os
+import sys
+import urllib.error
+import urllib.parse
+import urllib.request
+
+
+def emit(status, **fields):
+    payload = {"status": status, **fields}
+    print(json.dumps(payload, ensure_ascii=False))
+
+
+def main():
+    if os.environ.get("VCM_ROLE") != "architect":
+        emit("rejected", message="Only architect may schedule the post-planning restart.")
+        return 2
+
+    api_url = os.environ.get("VCM_API_URL", "").rstrip("/")
+    task_slug = os.environ.get("VCM_TASK_SLUG", "").strip()
+    if not api_url or not task_slug:
+        emit("rejected", message="VCM_API_URL or VCM_TASK_SLUG is unavailable.")
+        return 2
+
+    url = (
+        api_url
+        + "/api/tasks/"
+        + urllib.parse.quote(task_slug, safe="")
+        + "/sessions/architect/restart-after-planning"
+    )
+    request = urllib.request.Request(
+        url,
+        data=b"{}",
+        headers={"content-type": "application/json"},
+        method="POST",
+    )
+    try:
+        with urllib.request.urlopen(request, timeout=5) as response:
+            payload = json.loads(response.read().decode("utf-8"))
+        emit(payload.get("status", "scheduled"), taskSlug=task_slug, sessionId=payload.get("sessionId"))
+        return 0
+    except urllib.error.HTTPError as error:
+        try:
+            payload = json.loads(error.read().decode("utf-8"))
+            message = payload.get("error", {}).get("message", str(error))
+        except Exception:
+            message = str(error)
+        emit("rejected", message=message)
+        return 2
+    except (OSError, ValueError, urllib.error.URLError) as error:
+        emit("failed", message=str(error))
+        return 2
+
+
+if __name__ == "__main__":
+    sys.exit(main())
+`;
+}

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

@@ -26,21 +26,22 @@ ${renderRoleMemoryRules("tester")}
 - Do not treat "looks normal", "no error", log absence, or implementation reasoning as validation evidence.
 - Coder may write and run L0/L1 baseline tests during implementation, but Tester owns final test adequacy for all validation levels.
 - Review Coder-provided L0/L1 evidence and changed unit tests against \`docs/CODING_STANDARDS.md\`; confirm changed callable units have required success, failure, boundary, validation, branching, error-handling, lifecycle, retry, or state-transition coverage.
-- If L0/L1 coverage is missing or weak, add or update tests when possible; otherwise report the exact missing coverage in \`.ai/vcm/handoffs/test-report.md\`.
+- If required L0/L1 coverage is missing or weak, add or update the required tests. If the coverage cannot be completed, return \`Test Result: fail\` with concrete blocking evidence.
 - Own L2/L3/L4 final-validation design, execution, and acceptance evidence.
 - Targeted diagnostic L2 checks run by Coder or Architect are implementation evidence only and do not replace Tester final validation.
 - Choose validation level by risk. Unit tests are not sufficient when the change crosses module boundaries, public contracts, UI flows, CLI/tooling flows, hooks, sessions, persistence, worktrees, or external process behavior; require integration or E2E coverage, or document a concrete risk-based reason why it is unnecessary. Unavailable required coverage is a blocking validation gap.
 - For important new behavior, public workflows, cross-module behavior, UI/CLI/tooling flows, persistence/session/worktree behavior, hooks, or external process behavior, add a new integration/E2E case or extend an existing one with assertions that directly cover the new behavior.
-- Do not treat an existing integration/E2E command as sufficient unless it includes assertions for the new behavior or important regression path; otherwise add or modify the case, or record why coverage is not practical.
+- Do not treat an existing integration/E2E command as sufficient unless it includes assertions for the new behavior or important regression path. Add or modify the required case; inability to complete required coverage makes \`Test Result: fail\`.
 - When tests were changed during the task, check whether assertions were weakened, removed, over-mocked, or rewritten to match the implementation instead of the approved behavior. Report this as a validation gap unless the approved contract changed.
 - Apply \`docs/CODING_STANDARDS.md\` to changed tests, fixtures, test-only helpers, baseline-test coverage, and test integrity.
 - Before final validation, perform a full cache cleanup, then rerun validation from a clean state.
 - Do not use validation results produced before full cache cleanup as final acceptance evidence.
-- Record failed commands, observed behavior, expected behavior, reproduction steps, skipped checks, and coverage gaps.
+- Record failed commands, observed behavior, expected behavior, reproduction steps, and skipped checks. Record missing required coverage as blocking evidence until the user approves it as a Coverage Gap.
 - Report failures as validation evidence: expected behavior, actual behavior, reproduction, affected path, failed command or log, and risk.
 - Do not propose implementation fixes, architecture changes, Replan, or ownership changes.
 - If project-manager asks for clarification, clarify only the validation evidence, expected behavior, affected path, or coverage gap.
 - If validation fails or expected behavior is unclear, report the evidence to project-manager; architect owns diagnosis, and project-manager decides the next route.
+- After Architect Debug or Architecture Diagnosis changes, rerun the required validation independently. Architect validation is implementation evidence and does not replace Tester final validation.
 - Add or modify tests, test fixtures, or test-only helpers needed for validation confidence.
 - Tester changes to tests, fixtures, and test-only helpers must follow \`docs/CODING_STANDARDS.md\` and prove the approved behavior contract.
 - Do not edit production code, public contracts, runtime wiring, generated context, or shared production helpers while adding validation coverage.
@@ -52,13 +53,18 @@ ${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 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.
+- Before exact user approval is routed by project-manager, record missing required coverage under \`Blocking Validation Issues\`, keep \`Coverage Gaps\` as \`None\`, and return \`Test Result: fail\`.
+- Add a Coverage Gap only after project-manager routes the user's exact approval for that specific unresolved gap. Record the approval verbatim in \`User Approval Evidence\`.
+- User approval permits the gap to remain and the workflow to continue; it does not change the factual \`Test Result: fail\`.
+- If a required validation check is skipped or cannot complete, \`Test Result\` must be \`fail\`.
 - 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
 
 - Own \`docs/TESTING.md\` as the project's current validation strategy, not as a task log or diagnostic history.
+- Do not add or expand \`Known Testing Gaps\` without exact user approval routed by project-manager.
+- Add an approved item to \`Known Testing Gaps\` only when it is a durable project-level testing limitation. Keep task-local evidence and the user's authorization in \`test-report.md\`, not in the durable document.
+- Do not use \`Known Testing Gaps\` to defer current-task validation before Architect Debug and Architecture Diagnosis have completed.
 - Keep \`docs/TESTING.md\` useful to both tester and user: it must explain what is tested, why it matters, how to run it, when to run it, and known gaps.
 - Document integration and E2E test cases as reviewable case lists, not only command lists.
 - Each integration/E2E case should include ID, scenario, entry point, what it proves, key assertions, when to run, and current limitations when relevant.
@@ -69,14 +75,16 @@ ${renderRoleMemoryRules("tester")}
 
 ### Outputs
 
-- Write \`.ai/vcm/handoffs/test-report.md\` with \`Test Result: pass|fail\`, evidence reviewed, tests added or updated, coverage mapping, commands run or checked, validation results, failed expectations, reproduction steps, skipped checks with reasons, coverage gaps, and blocking validation issues.
+- Write \`.ai/vcm/handoffs/test-report.md\` with \`Test Result: pass|fail\`, evidence reviewed, tests added or updated, coverage mapping, commands run or checked, validation results, failed expectations, reproduction steps, skipped checks with reasons, coverage gaps, blocking validation issues, and user approval evidence.
 - In Validation-Only Flow, if tests, fixtures, test-only helpers, or \`docs/TESTING.md\` changed, commit those changes before reporting and record the changed files and commit in \`test-report.md\`. If no tracked files changed, record that no commit was required.
 - \`test-report.md\` is the current validation evidence, not a log; when rewriting it, carry forward still-unresolved findings or explicitly mark them resolved instead of dropping them.
 - In \`Coverage Mapping\`, map each accepted changed behavior or relevant risk to its validation level, actual test file and case or external evidence, exercised entry path and key assertions, result, and any remaining gap.
 - Use \`pass\` only when required validation completed and no blocking test failure, missing required coverage, unacceptable test weakness, or unresolved validation risk remains.
 - Use \`fail\` when tests fail, coverage is insufficient, important validation cannot complete, test quality is unacceptable, or validation risk needs project-manager routing.
-- When \`Test Result: pass\`, \`Blocking Validation Issues\` must be \`None\`.
+- When \`Test Result: pass\`, \`Coverage Gaps\`, \`Blocking Validation Issues\`, and \`User Approval Evidence\` must be \`None\`.
 - When \`Test Result: fail\`, \`Blocking Validation Issues\` must list concrete blocking evidence.
+- When \`Coverage Gaps\` is not \`None\`, \`Test Result\` must be \`fail\`, \`User Approval Evidence\` must contain the user's exact authorization, and every recorded gap must match that authorization.
+- When no gap has been approved, \`User Approval Evidence\` must be \`None\`.
 - For feature or cross-boundary changes, state which new or updated integration/E2E cases cover the important paths, or give the concrete risk-based reason such coverage is unnecessary. If required coverage is unavailable, report it as a blocking issue.
 - For changed or newly added tests, state why the assertions prove real behavior rather than fixture-specific, implementation-specific, or mock-only behavior.
 - Report confirmed unresolved issues that should survive current-task cleanup in \`.ai/vcm/handoffs/test-report.md\`; do not write \`.ai/vcm/handoffs/known-issues.md\` (architect-owned).

package/dist/backend/templates/harness/vcm-architecture-interview-skill.js

@@ -1,7 +1,7 @@
 export function renderVcmArchitectureInterviewSkillRules() {
     return `## Purpose
 
-Use this skill only when project-manager routes the Architect Interview step of Code-Change Flow. Establish confirmed user-owned behavior before architecture planning begins.
+Use this skill only when project-manager routes the Architect Interview step of Code-Change Flow. Establish confirmed user-owned behavior and reusable current-code evidence before architecture planning begins.
 
 During an active Architect Interview, handle the user's answers and final confirmation only as defined by this skill.
 
@@ -14,9 +14,10 @@ During an active Architect Interview, handle the user's answers and final confir
 
 ## Evidence First
 
-- Read the PM route, task request, relevant durable docs, generated context, and enough current-worktree source to distinguish project facts from unresolved user decisions.
+- Read the PM route, task request, relevant durable docs, generated context, and the complete current-worktree behavior path inside the affected feature or module boundary.
 - If a fact can be established from the worktree or available tools, investigate it instead of asking the user.
 - If code, docs, and the user's requested behavior conflict, state the concrete conflict and ask which user-visible behavior is intended.
+- Maintain \`.ai/vcm/handoffs/architecture-evidence.md\` while reading. Record repository evidence, not session recollection or conversation history.
 
 ## User Decision Filter
 
@@ -67,16 +68,41 @@ Architecture Brief Status: interviewing|confirmed
 
 Record concise confirmed requirements and constraints, not implementation design. Use \`None\` under Unresolved User Decisions only when no user-owned decision remains.
 
+Maintain the evidence artifact with this structure:
+
+\`\`\`md
+# Architecture Evidence: <task>
+
+Architecture Evidence Status: incomplete|complete
+
+## Planning Boundary
+
+## Entry Points And Behavior Paths
+
+## State And Lifecycle
+
+## Callers And Consumers
+
+## External Boundaries
+
+## Code And Docs Conflicts
+
+## Evidence Commands
+\`\`\`
+
+Identify inspected files and symbols, callers or consumers, state and side effects, verified behavior, and the worktree revision. Replace stale evidence instead of appending history.
+
 ## Completion
 
 When no unresolved user decision remains, present the complete brief to the user and ask for explicit confirmation. If the user corrects it, update the brief and continue the interview.
 
-Only after explicit confirmation:
+Only after explicit confirmation and complete code evidence:
 
 1. Set \`Architecture Brief Status: confirmed\`.
 2. Record the confirmation under User Confirmation.
-3. Report the confirmed brief path to project-manager with \`vcm-route-message\`.
-4. End the turn immediately.
+3. Set \`Architecture Evidence Status: complete\`.
+4. Report both artifact paths to project-manager with \`vcm-route-message\`.
+5. End the turn immediately.
 
 Do not continue into architecture planning. Project-manager owns the route from Architect Interview to Architect planning.`;
 }

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

@@ -124,9 +124,9 @@ Do not:
 - start a shell loop
 - wait for another role's answer
 - paste directly into another role terminal
-- 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.
+- use Claude Code Task/Subagent to replace VCM role routing. Coder workers and
+  Architect's foreground \`vcm-architect-scaffold-worker\` are internal role work,
+  not route-message delivery.
 
 VCM scans pending route files after the Stop hook and delivers later replies in a new turn.
 

package/dist/shared/types/app-settings.js

@@ -32,3 +32,17 @@ export function createDefaultLaunchTemplate() {
         autoOrchestration: true
     };
 }
+export function createDefaultToolSessionDefaults() {
+    return {
+        translator: {
+            permissionMode: "bypassPermissions",
+            model: "default",
+            effort: "medium"
+        },
+        "harness-engineer": {
+            permissionMode: "bypassPermissions",
+            model: "default",
+            effort: "medium"
+        }
+    };
+}

package/dist/shared/types/usage-analytics.js

@@ -0,0 +1 @@
+export {};

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

@@ -45,7 +45,8 @@ const REQUIRED_HEADINGS = {
         "Reproduction Steps",
         "Skipped Checks With Reasons",
         "Coverage Gaps",
-        "Blocking Validation Issues"
+        "Blocking Validation Issues",
+        "User Approval Evidence"
     ],
     "docs-sync-report": [
         "Summary",
@@ -138,11 +139,36 @@ function validateArtifactFields(kind, content) {
         const invalidFields = result === "pass" || result === "fail"
             ? []
             : ["Test Result must be pass or fail."];
+        const coverageGaps = readArtifactSectionValue(content, "Coverage Gaps");
+        const blockingIssues = readArtifactSectionValue(content, "Blocking Validation Issues");
+        const userApproval = readArtifactSectionValue(content, "User Approval Evidence");
+        const hasCoverageGaps = Boolean(coverageGaps && !/^none\.?$/i.test(coverageGaps));
+        const hasBlockingIssues = Boolean(blockingIssues && !/^none\.?$/i.test(blockingIssues));
+        const hasUserApproval = Boolean(userApproval && !/^none\.?$/i.test(userApproval));
         if (result === "pass") {
-            const blockingIssues = readArtifactSectionValue(content, "Blocking Validation Issues");
-            if (!blockingIssues || !/^none\.?$/i.test(blockingIssues)) {
+            if (!coverageGaps || hasCoverageGaps) {
+                invalidFields.push("Coverage Gaps must be None when Test Result is pass.");
+            }
+            if (!blockingIssues || hasBlockingIssues) {
                 invalidFields.push("Blocking Validation Issues must be None when Test Result is pass.");
             }
+            if (!userApproval || hasUserApproval) {
+                invalidFields.push("User Approval Evidence must be None when Test Result is pass.");
+            }
+        }
+        if (result === "fail" && !hasBlockingIssues) {
+            invalidFields.push("Blocking Validation Issues must contain concrete evidence when Test Result is fail.");
+        }
+        if (hasCoverageGaps) {
+            if (result !== "fail") {
+                invalidFields.push("Test Result must be fail when Coverage Gaps are recorded.");
+            }
+            if (!hasUserApproval) {
+                invalidFields.push("User Approval Evidence is required when Coverage Gaps are recorded.");
+            }
+        }
+        else if (hasUserApproval) {
+            invalidFields.push("User Approval Evidence must be None when no Coverage Gaps are recorded.");
         }
         return invalidFields;
     }