vibe-coding-master 0.7.7 → 0.7.9

package/dist/backend/cli/install-vcm-harness.js

@@ -26,6 +26,7 @@ import { renderVcmProposeMemorySkillRules } from "../templates/harness/vcm-propo
 import { renderVcmReportHarnessIssueSkillRules } from "../templates/harness/vcm-report-harness-issue-skill.js";
 import { renderVcmRouteMessageSkillRules } from "../templates/harness/vcm-route-message-skill.js";
 import { renderUpdateTaskStateTool, renderVcmTaskStateSkillRules } from "../templates/harness/vcm-task-state-skill.js";
+import { renderCheckScaffoldLedgerTool } from "../templates/harness/check-scaffold-ledger.js";
 import { readVcmPackageVersion } from "../app-version.js";
 const CLI_DIR = path.dirname(fileURLToPath(import.meta.url));
 const APP_ROOT = path.resolve(CLI_DIR, "../../..");
@@ -295,6 +296,12 @@ const WHOLE_FILES = [
         mode: 0o755,
         content: renderUpdateTaskStateTool()
     },
+    {
+        path: ".ai/tools/check-scaffold-ledger",
+        category: "runtime-tool",
+        mode: 0o755,
+        content: renderCheckScaffoldLedgerTool()
+    },
     {
         path: ".ai/tools/run-long-check",
         category: "runtime-tool",

package/dist/backend/services/claude-hook-service.js

@@ -144,6 +144,7 @@ export function createClaudeHookService(deps) {
         }
         await deps.harnessService?.recordHarnessBootstrapHook(context.project.repoRoot, {
             eventName,
+            taskSlug: input.taskSlug,
             sessionId: session?.id,
             claudeSessionId: stringOrUndefined(input.event.session_id)
         });

package/dist/backend/services/harness-service.js

@@ -23,6 +23,7 @@ import { renderVcmProposeMemorySkillRules } from "../templates/harness/vcm-propo
 import { renderVcmReportHarnessIssueSkillRules } from "../templates/harness/vcm-report-harness-issue-skill.js";
 import { renderVcmRouteMessageSkillRules } from "../templates/harness/vcm-route-message-skill.js";
 import { renderUpdateTaskStateTool, renderVcmTaskStateSkillRules } from "../templates/harness/vcm-task-state-skill.js";
+import { renderCheckScaffoldLedgerTool } from "../templates/harness/check-scaffold-ledger.js";
 import { submitTerminalInput } from "../runtime/terminal-submit.js";
 import { VcmError } from "../errors.js";
 import { bumpHarnessRevision, readHarnessRevisionState } from "./harness-revision.js";
@@ -215,6 +216,13 @@ const HARNESS_FILES = [
         ownership: "raw-file",
         renderRules: renderUpdateTaskStateTool
     },
+    {
+        kind: "tool-check-scaffold-ledger",
+        path: ".ai/tools/check-scaffold-ledger",
+        title: "Check Scaffold Ledger Tool",
+        ownership: "raw-file",
+        renderRules: renderCheckScaffoldLedgerTool
+    },
     {
         kind: "agent-project-manager",
         path: ".claude/agents/project-manager.md",
@@ -414,7 +422,6 @@ export function createHarnessService(deps) {
             await persistHarnessBootstrapRunState(deps.fs, repoRoot, {
                 version: 1,
                 status: "running",
-                taskSlug,
                 targetRepoRoot,
                 sessionId: session.id,
                 claudeSessionId: session.claudeSessionId,
@@ -436,7 +443,7 @@ export function createHarnessService(deps) {
         async recordHarnessBootstrapHook(repoRoot, input) {
             const state = await loadPersistedHarnessBootstrapRunState(deps.fs, repoRoot);
             if (state?.status !== "running" || !matchesBootstrapRunState(state, input)) {
-                return getHarnessBootstrapStatus(deps, repoRoot, state?.targetRepoRoot ?? repoRoot, now, vcmVersion, state?.taskSlug);
+                return getHarnessBootstrapStatus(deps, repoRoot, state?.targetRepoRoot ?? repoRoot, now, vcmVersion, input.taskSlug);
             }
             const timestamp = now();
             if (input.eventName === "Stop" && state.targetRepoRoot) {
@@ -449,7 +456,7 @@ export function createHarnessService(deps) {
                 updatedAt: timestamp,
                 lastHookEvent: input.eventName
             });
-            return getHarnessBootstrapStatus(deps, repoRoot, state.targetRepoRoot ?? repoRoot, now, vcmVersion, state.taskSlug);
+            return getHarnessBootstrapStatus(deps, repoRoot, state.targetRepoRoot ?? repoRoot, now, vcmVersion, input.taskSlug);
         }
     };
 }
@@ -1498,15 +1505,13 @@ async function getHarnessBootstrapStatus(deps, repoRoot, targetRepoRoot, now, vc
         await checkFilledMarkdown(deps.fs, targetRepoRoot, "docs/TESTING.md", "Testing doc", "testing-doc")
     ];
     const persistedRunState = await loadPersistedHarnessBootstrapRunState(deps.fs, repoRoot);
-    const runState = taskSlug && persistedRunState?.taskSlug !== taskSlug
-        ? undefined
-        : persistedRunState;
+    const runState = persistedRunState;
     const session = await getCurrentHarnessEngineerBootstrapSession(deps, repoRoot, taskSlug);
     const fixedHarnessReady = checks[0]?.status === "ok";
     const projectChecks = checks.slice(1);
     const projectComplete = projectChecks.every((check) => check.status === "ok");
     const projectStarted = projectChecks.some((check) => check.status === "ok" || check.status === "incomplete");
-    const runActive = runState?.status === "running" && session?.status === "running";
+    const runActive = isActiveHarnessBootstrapRun(runState, session, targetRepoRoot);
     const status = !fixedHarnessReady
         ? "not_ready"
         : runActive
@@ -1751,7 +1756,6 @@ async function loadPersistedHarnessBootstrapRunState(fs, repoRoot) {
     return {
         version: 1,
         status,
-        taskSlug: typeof payload.taskSlug === "string" ? payload.taskSlug : undefined,
         targetRepoRoot: typeof payload.targetRepoRoot === "string" ? payload.targetRepoRoot : undefined,
         sessionId: typeof payload.sessionId === "string" ? payload.sessionId : undefined,
         claudeSessionId: typeof payload.claudeSessionId === "string" ? payload.claudeSessionId : undefined,
@@ -1779,6 +1783,13 @@ function matchesBootstrapRunState(state, input) {
     }
     return true;
 }
+function isActiveHarnessBootstrapRun(state, session, targetRepoRoot) {
+    return state?.status === "running"
+        && session?.status === "running"
+        && state.sessionId === session.id
+        && state.targetRepoRoot === targetRepoRoot
+        && (!state.claudeSessionId || state.claudeSessionId === session.claudeSessionId);
+}
 async function readOptionalText(fs, repoRoot, relativePath) {
     const absolutePath = resolveHarnessPath(repoRoot, relativePath);
     try {

package/dist/backend/services/job-guard-service.js

@@ -1,7 +1,7 @@
 import fs from "node:fs/promises";
 import path from "node:path";
 const ACTIVE_JOB_STATUSES = new Set(["queued", "starting", "running"]);
-const ACTIVE_CODER_WORKER_STATUSES = new Set(["planned", "running", "completed", "failed"]);
+const ACTIVE_CODER_WORKER_STATUSES = new Set(["running", "completed"]);
 const QUEUED_JOB_FRESH_MS = 120_000;
 export const MAX_CONSECUTIVE_STOP_BLOCKS = 3;
 export function createJobGuardService(deps = {}) {
@@ -147,7 +147,6 @@ async function findActiveCoderWorkerTasks(taskRepoRoot) {
             workerId: typeof state.workerId === "string" ? state.workerId : path.basename(entry, ".json"),
             status,
             reportPath: typeof state.reportPath === "string" ? state.reportPath : undefined,
-            error: typeof state.error === "string" ? state.error : undefined,
             stateMtimeMs
         });
     }
@@ -177,9 +176,10 @@ function buildCoderWorkerBlockReason(tasks) {
     const reports = tasks
         .map((task) => task.reportPath)
         .filter((reportPath) => Boolean(reportPath));
-    const reportHint = reports.length > 0 ? ` Test report(s): ${reports.join(", ")}.` : "";
+    const reportHint = reports.length > 0 ? ` Worker report(s): ${reports.join(", ")}.` : "";
     return `VCM: coder worker task ${listing} is still unhandled. Do not end the Coder turn while worker tasks are unhandled. `
-        + `Wait for worker subagents, test reports and commits, resolve failed or incomplete workers, set \`handled: true\` in each worker state, and continue.${reportHint}`;
+        + `Wait for running workers; inspect every completed worker report, implementation result, item disposition, and commit; `
+        + `then set \`handled: true\` in each worker state and continue.${reportHint}`;
 }
 function latestMtime(...values) {
     return values.reduce((latest, value) => value !== undefined && (latest === undefined || value > latest) ? value : latest, undefined);

package/dist/backend/templates/handoff.js

@@ -101,9 +101,15 @@ Task-specific context and coder guidance go here, not in source-code comments.
 Source-code comments should only describe durable behavior, contracts, invariants,
 error boundaries, or non-obvious logic that should remain useful after this task.
 
-| ID | File / Action | Current Evidence / Why In Scope | Coder Work | Allowed Freedom | Expected VCM:CODE | Durable Comment Needs | Behavior / Contract Proof Points |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| SCF-001 | TBD | TBD | TBD | TBD | TBD | TBD | TBD |
+| ID | Action | File | Symbol Or Site | Coder Work | Allowed Implementation Freedom | Behavior / Contract Proof Point |
+| --- | --- | --- | --- | --- | --- | --- |
+| TBD | TBD | TBD | TBD | TBD | TBD | TBD |
+
+## Scaffold Build Evidence
+
+| Check | Command | Result | Scaffold Commit |
+| --- | --- | --- | --- |
+| TBD | TBD | TBD | TBD |
 
 ## Tester Coverage Hints
 
@@ -187,11 +193,9 @@ Decision: ready_for_review|incomplete|failed
 
 ## Scaffold Completion
 
-TBD
-
-## Remaining Markers
-
-TBD
+| ID | Action | Result | Marker State | Proof Evidence |
+| --- | --- | --- | --- | --- |
+| TBD | TBD | TBD | TBD | TBD |
 
 ## Changed Files
 

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

@@ -54,20 +54,37 @@ ${renderRoleMemoryRules("architect")}
 - Do not begin Architecture Decision, Code Scaffolding, or a complete architecture plan unless \`architecture-brief.md\` has \`Architecture Brief Status: confirmed\`.
 - 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 required code scaffolding, callable surfaces, contract comments, and \`VCM:CODE\` placeholders have been written.
+- 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.
+- Do not defer scaffold creation to the coder turn anywhere in the plan: every signature, placeholder, and ledger item the plan needs must exist at \`Planning Result: complete\`. If something cannot be scaffolded yet, the plan is incomplete or needs user clarification.
+
+#### 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.
+- 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.
+- \`planning-progress.md\` is task-runtime state for continuation and routing, not part of the reviewed plan; \`architecture-plan.md\` alone remains the executable plan of record.
 
 #### Plan Document
 
-- \`architecture-plan.md\` must start with \`Planning Result: complete|incomplete|user clarification required\` and use these sections: Accepted Scope, Current Code Reality, Architecture Decision, Module/File Plan, Public Surface Impact, Scaffold Manifest, Tester Coverage Hints, Docs Impact, Known Risks, and Coder Handoff Notes.
-- Use \`Planning Result: complete\` only when the plan document and required code scaffold are complete and consistent. Include the same Planning Result in the route message to project-manager; do not select the next route.
+- \`architecture-plan.md\` must start with \`Planning Result: complete|incomplete|user clarification required\` and use these sections: Accepted Scope, Current Code Reality, Architecture Decision, Module/File Plan, Public Surface Impact, Scaffold Manifest, Scaffold Build Evidence, Tester Coverage Hints, Docs Impact, Known Risks, and Coder Handoff Notes.
+- 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.
+- \`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.
+- 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, and every non-private callable surface intended for use outside its file.
+- \`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.
 - \`Public Surface Impact\`: state changed APIs, routes, commands, events, exports, storage formats, configuration, UI behavior, visibility changes, side effects, error boundaries, expected callers, or explicitly state none.
-- \`Scaffold Manifest\`: provide one stable row per implementation unit or file context that coder must complete: row ID, file action, current code or integration-point evidence and why the file is in scope, coder work, allowed implementation freedom, expected \`VCM:CODE\` placeholders, durable code comment needs, and behavior/contract proof points.
-- Give each Scaffold Manifest row a stable ID such as \`SCF-001\`; use that ID in any related \`VCM:CODE\` marker so coder can report completion by ID.
+- \`Scaffold Manifest\`: an item ledger — one entry per implementation item. An item is one of: a created body or surface (\`create\`), one required change site — one contiguous edit region inside an existing body or surface (\`change\`), or one deletion of a body, site, or file (\`delete\`). An item not in the ledger is not in the plan; coder must not implement it.
+- Each ledger entry carries, in this column order: a unique stable ID such as \`SCF-001\`, action, exact file path, symbol or site, coder work, allowed implementation freedom, and a behavior/contract proof point. Per-file evidence, why-in-scope, and durable-comment needs live in the Module/File Plan, not in the ledger. Open-ended coverage language ("as work proceeds", "replicate", "etc.", "and others") is forbidden anywhere in the ledger.
+- IDs and markers correspond one to one: every \`create\`, \`change\`, and \`delete\` entry has exactly one \`VCM:CODE <ID>\` marker pre-placed at its declared file and site; a \`delete\` marker sits on the code to be removed and leaves with it.
+- The Scaffold Manifest is complete only when the ledger ID set and the tree's \`VCM:CODE\` ID set are equal, each ID appears exactly once on each side, and each marker sits in its declared file (\`.ai/tools/check-scaffold-ledger\` automates the check). Any mismatch means the plan is not complete.
+- \`Scaffold Build Evidence\`: the exact compile/typecheck commands run on the committed scaffold, their results, and the scaffold commit hash. A missing, red, or stale-hash result means the plan is not complete.
+- When the plan introduces or changes a build configuration — a new compilation target, a feature-gated or restricted-runtime variant, a new artifact type, or a build-environment constraint — scaffold that configuration and add to \`Scaffold Build Evidence\` one named check per configuration that fails when the claim is false, run green at the scaffold commit; choose proving checks from the project coding standards when defined there. A build-configuration claim without its named green check means the plan is not complete.
+- The compile/typecheck and build-configuration checks in \`Scaffold Build Evidence\` must cover every wired exemplar, so each new cross-module call path is proven compilable at the scaffold stage. A call path that exists only in plan prose, over stub scaffold that never names the surfaces it will invoke, is not proven and the plan is not complete.
+- Plan-stage build checks prove dependency closure and build shape only; full artifact builds and environment validation that require implemented bodies are implementation-stage proof and must be listed as proof points on the corresponding ledger items instead.
 - \`Tester Coverage Hints\`: list behavior scenarios, edge conditions, public-contract risks, or runtime paths tester should consider. Do not design test cases, validation levels, commands, coverage matrices, or final validation strategy.
 - \`Docs Impact\`: list every touched module and state whether its \`<module>/ARCHITECTURE.md\` is expected to change, stay unchanged, or require code-diff review before deciding; also state whether changes belong in \`docs/ARCHITECTURE.md\`, \`.ai/generated/public-surface.json\`, or no durable architecture doc.
 - \`Known Risks\`: state concrete remaining technical risks, uncertainty, or validation risks that coder or tester must pay attention to.
@@ -77,7 +94,9 @@ ${renderRoleMemoryRules("architect")}
 
 #### Code Scaffolding
 
-- Create or update only the minimum module/file scaffolding needed to make boundaries, callable surfaces, and placeholders unambiguous.
+- 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.
 - Source-code comments must describe durable behavior, contracts, invariants, error boundaries, or non-obvious logic that should remain useful after the task is complete.
 - Do not put task-specific context, task labels, implementation-order notes, handoff instructions, temporary plan rationale, or coder guidance in source-code comments.
 - Task labels such as \`RP<n>\`, \`SCF-<n>\`, \`KI-<n>\`, \`Phase <n>\`, or temporary task/round/PR labels must not appear in durable source comments.
@@ -85,7 +104,7 @@ ${renderRoleMemoryRules("architect")}
 - Define every new or changed non-private callable surface directly in code with its signature shape and contract comment.
 - When changing an existing non-private callable surface, update its signature and contract comment in code before coder work starts; leave \`VCM:CODE\` only where implementation must change.
 - Non-private callable surface includes any function, method, type, trait, enum, constant, re-export, or similar symbol that another file can call or depend on.
-- Mark incomplete implementation bodies with \`VCM:CODE <Scaffold Manifest ID>\`; coder must implement them and remove the markers before handoff.
+- Place exactly one \`VCM:CODE <ID>\` marker per ledger item: on each incomplete implementation body, at each required change site inside an existing body, and on each body or site to be deleted. Coder implements or deletes each item and removes its marker when it completes green; a failed item keeps its marker over the committed attempt.
 - 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.
 

package/dist/backend/templates/harness/check-scaffold-ledger.js

@@ -0,0 +1,226 @@
+export function renderCheckScaffoldLedgerTool() {
+    return `#!/usr/bin/env python3
+"""Scaffold-ledger reconciliation — machine enforcement of the Scaffold Manifest bijection.
+
+The architecture plan's Scaffold Manifest is an item ledger: one entry per implementation
+item, one unique ID per entry, and exactly one \`VCM:CODE <ID>\` marker in the tree per
+\`create\`/\`change\`/\`delete\` entry. This tool checks:
+
+  1. the ledger header follows the mandated column order (\`ID | Action | File | ...\`),
+     every ledger ID is unique, classified by its whole-cell action column
+     (create/change/delete), and bound to a declared file path in the file column;
+  2. the ledger ID set equals the tree marker ID set, each ID exactly once on each side;
+  3. every marker sits in its entry's declared file;
+  4. the manifest contains no open-ended coverage language ("as work proceeds",
+     "replicate", "etc.", "and others").
+
+Markers are scanned in git-tracked source files only (\`.md\` files and \`.ai/\` are excluded:
+prose may quote markers legitimately). Pure read; findings go to stderr; exit 0 clean,
+1 on findings. \`--plan <path>\` overrides the default plan location. No plan file at all
+means there is nothing to check (exit 0) — a docs-only or planning-free task.
+"""
+import argparse
+import re
+import subprocess
+import sys
+from pathlib import Path
+
+PLAN = ".ai/vcm/handoffs/architecture-plan.md"
+MANIFEST_HEADING = re.compile(r"^##\\s+Scaffold Manifest\\s*$")
+SECTION_HEADING = re.compile(r"^##\\s+\\S")
+ID_TOKEN = re.compile(r"\\b([A-Z]{2,6}-\\d{1,4})\\b")
+# Mandated column order: ID | action | file | symbol/site | work | freedom | proof.
+# The action is read from its own cell as a whole-cell verb — never sniffed from the
+# row text, so paths or prose containing action words cannot flip an item's class.
+ACTIONS = frozenset({"create", "change", "delete"})
+PATH_TOKEN = re.compile(r"\`([^\`\\s]+/[^\`\\s]+|[^\`\\s]+\\.[A-Za-z0-9]{1,8})\`")
+MARKER_ID = re.compile(r"VCM:CODE[:\\s]\\s*([A-Za-z]{2,6}-\\d{1,4})")
+MARKER_ANY = re.compile(r"VCM:CODE")
+FORBIDDEN = [
+    re.compile(r"as work proceeds", re.IGNORECASE),
+    re.compile(r"\\breplicate\\b", re.IGNORECASE),
+    re.compile(r"\\betc\\.", re.IGNORECASE),
+    re.compile(r"\\band others\\b", re.IGNORECASE),
+]
+
+
+def manifest_section(plan_text: str) -> tuple[int, list[str]] | None:
+    """(start line number, section lines) of the Scaffold Manifest section, or None."""
+    lines = plan_text.splitlines()
+    start = None
+    for index, line in enumerate(lines):
+        if start is None:
+            if MANIFEST_HEADING.match(line):
+                start = index + 1
+        elif SECTION_HEADING.match(line):
+            return (start, lines[start : index])
+    return None if start is None else (start, lines[start:])
+
+
+def parse_ledger(section_start: int, section: list[str], plan: str) -> tuple[dict, list[str]]:
+    """{id: {"path", "action", "line"}} plus parse findings. Positional parsing per the
+    mandated column order; the first non-entry table row is validated as the header."""
+    entries: dict[str, dict] = {}
+    findings: list[str] = []
+    header_checked = False
+    for offset, line in enumerate(section):
+        line_no = section_start + offset + 1
+        stripped = line.strip()
+        if not stripped.startswith("|"):
+            continue
+        cells = [cell.strip() for cell in stripped.strip("|").split("|")]
+        if not cells or set(cells[0]) <= {"-", ":", " "}:
+            continue  # separator row
+        id_match = ID_TOKEN.search(cells[0])
+        if not id_match:
+            if not header_checked:
+                header_checked = True
+                head = [cell.lower() for cell in cells[:3]] + ["", "", ""]
+                if not (
+                    "id" in head[0]
+                    and "action" in head[1]
+                    and ("file" in head[2] or "path" in head[2])
+                ):
+                    findings.append(
+                        f"{plan}:{line_no}  [ledger] header columns must be "
+                        f"\`ID | Action | File | ...\` -> fix the ledger column order"
+                    )
+            continue
+        entry_id = id_match.group(1)
+        if entry_id in entries:
+            findings.append(
+                f"{plan}:{line_no}  [ledger] duplicate ledger ID {entry_id} "
+                f"(first at line {entries[entry_id]['line']}) -> one entry per item"
+            )
+            continue
+        action_cell = cells[1].lower() if len(cells) > 1 else ""
+        action = action_cell if action_cell in ACTIONS else None
+        declared = None
+        if len(cells) > 2:
+            path_match = PATH_TOKEN.search(cells[2])
+            declared = path_match.group(1) if path_match else None
+        if action is None:
+            findings.append(
+                f"{plan}:{line_no}  [ledger] {entry_id} action column is not exactly "
+                f"one of create/change/delete -> classify the item in column 2"
+            )
+        if declared is None:
+            findings.append(
+                f"{plan}:{line_no}  [ledger] {entry_id} has no declared file path in "
+                f"column 3 -> bind the item to its exact file"
+            )
+        entries[entry_id] = {"path": declared, "action": action, "line": line_no}
+    return entries, findings
+
+
+def forbidden_language(section_start: int, section: list[str], plan: str) -> list[str]:
+    findings = []
+    for offset, line in enumerate(section):
+        for pattern in FORBIDDEN:
+            if pattern.search(line):
+                findings.append(
+                    f"{plan}:{section_start + offset + 1}  [ledger] open-ended coverage "
+                    f"language ({pattern.pattern}) -> enumerate every item explicitly"
+                )
+    return findings
+
+
+def tree_markers(root: Path) -> tuple[dict[str, list[tuple[str, int]]], list[str]]:
+    """{id: [(path, line)]} for tracked source markers, plus malformed-marker findings."""
+    result = subprocess.run(
+        ["git", "grep", "-In", "VCM:CODE", "--", ".", ":!*.md", ":!.ai"],
+        capture_output=True,
+        text=True,
+        cwd=root,
+    )
+    markers: dict[str, list[tuple[str, int]]] = {}
+    findings: list[str] = []
+    for raw in result.stdout.splitlines():
+        parts = raw.split(":", 2)
+        if len(parts) < 3:
+            continue
+        path, line_no, content = parts[0], int(parts[1]), parts[2]
+        id_match = MARKER_ID.search(content)
+        if id_match:
+            markers.setdefault(id_match.group(1), []).append((path, line_no))
+        elif MARKER_ANY.search(content):
+            findings.append(
+                f"{path}:{line_no}  [ledger] marker without a parseable ID -> "
+                f"use \`VCM:CODE <ID>\`"
+            )
+    return markers, findings
+
+
+def main() -> int:
+    parser = argparse.ArgumentParser(
+        description="Scaffold Manifest ledger <-> VCM:CODE marker bijection check."
+    )
+    parser.add_argument("--plan", default=None, help=f"plan path (default {PLAN})")
+    args = parser.parse_args()
+
+    root = Path(__file__).resolve().parents[2]
+    plan_path = Path(args.plan) if args.plan else root / PLAN
+    plan = str(plan_path)
+    if not plan_path.is_file():
+        print(f"no architecture plan at {plan_path}; nothing to check")
+        return 0
+
+    findings: list[str] = []
+    section = manifest_section(plan_path.read_text(errors="replace"))
+    if section is None:
+        sys.stderr.write(f"{plan_path}:1  [ledger] no \`## Scaffold Manifest\` section\\n")
+        return 1
+    entries, parse_findings = parse_ledger(*section, str(plan_path))
+    findings += parse_findings
+    findings += forbidden_language(*section, str(plan_path))
+
+    markers, marker_findings = tree_markers(root)
+    findings += marker_findings
+
+    for entry_id, sites in sorted(markers.items()):
+        if len(sites) > 1:
+            where = ", ".join(f"{p}:{n}" for p, n in sites)
+            findings.append(
+                f"[ledger] {entry_id} has {len(sites)} markers ({where}) -> exactly one per item"
+            )
+
+    ledger_ids = set(entries)
+    tree_ids = set(markers)
+    for entry_id in sorted(ledger_ids - tree_ids):
+        findings.append(
+            f"{plan}:{entries[entry_id]['line']}  [ledger] {entry_id} has no marker "
+            f"in the tree -> pre-place \`VCM:CODE {entry_id}\` in its declared file"
+        )
+    for entry_id in sorted(tree_ids - ledger_ids):
+        path, line_no = markers[entry_id][0]
+        findings.append(
+            f"{path}:{line_no}  [ledger] marker {entry_id} has no ledger entry "
+            f"-> every item must be manifested"
+        )
+    for entry_id in sorted(ledger_ids & tree_ids):
+        entry = entries[entry_id]
+        if entry["path"]:
+            declared = entry["path"]
+            for path, line_no in markers[entry_id]:
+                if not (path == declared or path.endswith("/" + declared) or declared.endswith("/" + path)):
+                    findings.append(
+                        f"{path}:{line_no}  [ledger] marker {entry_id} is outside its "
+                        f"declared file \`{declared}\`"
+                    )
+
+    for finding in findings:
+        sys.stderr.write(finding + "\\n")
+    if findings:
+        sys.stderr.write(f"ledger reconciliation failed with {len(findings)} finding(s)\\n")
+        return 1
+    print(
+        f"ledger reconciliation clean: {len(ledger_ids)} ledger item(s), "
+        f"{len(tree_ids)} marker(s)"
+    )
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())
+`;
+}

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

@@ -17,7 +17,7 @@ ${renderRoleMemoryRules("coder")}
 - Before editing production code or tests, read and follow \`docs/CODING_STANDARDS.md\`.
 - Project-specific additions in \`docs/CODING_STANDARDS.md\` are binding when they make the shared baseline more precise.
 - Keep the implementation inside the approved architecture plan, scaffold, and role message.
-- Implement every assigned \`VCM:CODE\` placeholder, track completion by Scaffold Manifest ID when present, and remove all \`VCM:CODE\` markers before handoff.
+- Implement every assigned \`VCM:CODE\` placeholder, track completion by Scaffold Manifest ID when present; remove a marker when its item completes green — a failed item keeps its marker per the failure rules.
 
 ### Inputs
 
@@ -44,21 +44,24 @@ ${renderRoleMemoryRules("coder")}
 
 - Coder may use Claude Code subagents to invoke \`vcm-coder-worker\` for parallel implementation.
 - Use workers when the task has at least 20 \`VCM:CODE\` markers and the marker distribution can form at least two worker-sized groups.
-- Before invoking workers, count \`VCM:CODE\` markers by module and create one runtime state file per worker under \`.ai/vcm/coder-workers/tasks/<worker-id>.json\`.
+- Under a complete scaffold, marker implementations are order-independent — signatures, types, and cross-item contracts are frozen by the scaffold — so never serialize worker-sized groups for presumed implementation-order dependencies. When a group's module-scoped checks need peers that are still unimplemented, narrow that worker's assigned validation scope instead of serializing.
+- An item counts as blocked only when a genuine implementation attempt has produced objective compile/check evidence already reported under the failure rules; prediction never blocks an item. A blocked marker item never exempts the remaining markers from worker dispatch.
+- Before invoking workers, count \`VCM:CODE\` markers by module and create one runtime state file per worker under \`.ai/vcm/coder-workers/tasks/<worker-id>.json\` with \`status: running\`.
 - Create one worker task for each module with more than 10 \`VCM:CODE\` markers.
 - Group modules with 10 or fewer \`VCM:CODE\` markers into one small-modules worker when their combined marker count is more than 10.
 - If the combined small-module marker count is 10 or fewer, Coder handles those modules directly after worker results return.
 - Each worker prompt must include task worktree, architecture plan path, worker state path, report path, assigned modules/files/markers, allowed implementation scope, validation scope, and commit requirement.
 - Invoke worker subagents in parallel only through \`vcm-coder-worker\`.
-- Stay in the same Coder turn until all worker subagents finish and Coder has reviewed and integrated their reports and commits. Do not end the turn to wait for worker callbacks.
-- After workers finish, inspect each report and commit for assigned completion and integration, resolve missing implementation, conflicts, invalid edits, and remaining \`VCM:CODE\` markers, then mark \`handled: true\` in each worker state.
+- Stay in the same Coder turn until every worker state is \`completed\` and Coder has reviewed and integrated all reports and commits. Do not end the turn to wait for worker callbacks.
+- A completed worker reports \`Implementation Result: success|has_failed_items\`; \`completed\` means the full assigned sweep and handoff finished, not that every item passed.
+- After workers finish, inspect each item disposition and commit, integrate successful work and committed failure scenes, resolve integration conflicts or invalid edits, and verify that every remaining marker corresponds to a failed disposition. Only then mark \`handled: true\` in each worker state.
 - Run coder-level baseline validation, summarize worker reports and commits in \`.ai/vcm/handoffs/coder-completion.md\`, and clean \`.ai/vcm/coder-workers/\`.
 
 ### Handoff
 
 - Write \`.ai/vcm/handoffs/coder-completion.md\` before routing back to project-manager. This file is the current implementation completion evidence, not a log; replace stale content instead of appending history.
 - \`coder-completion.md\` must include \`Decision: ready_for_review | incomplete | failed\`.
-- \`coder-completion.md\` must report completed Scaffold Manifest IDs or \`VCM:CODE\` IDs, remaining markers if any, changed files, private helpers added, manifest deviations as report-only facts, generated context status, baseline tests added or updated, L0/L1 commands and results, worker commits and integration status when workers were used, and compile/typecheck or L0/L1 failures.
+- \`coder-completion.md\` must report every Scaffold Manifest item disposition in the fixed Scaffold Completion table, plus changed files, private helpers added, manifest deviations as report-only facts, generated context status, baseline tests added or updated, L0/L1 commands and results, worker commits and integration status when workers were used, and compile/typecheck or L0/L1 failures.
 - Use this structure:
 
 \`\`\`md
@@ -68,7 +71,9 @@ Decision: ready_for_review|incomplete|failed
 
 ## Scaffold Completion
 
-## Remaining Markers
+| ID | Action | Result | Marker State | Proof Evidence |
+| --- | --- | --- | --- | --- |
+| <ID> | <create/change/delete> | <done/failed> | <removed/present> | <evidence> |
 
 ## Changed Files
 
@@ -88,7 +93,9 @@ Decision: ready_for_review|incomplete|failed
 \`\`\`
 
 - In the route message back to project-manager, include the \`coder-completion.md\` path, the same \`Decision\`, and a \`Scaffold Completion\` section when the architecture plan contains a Scaffold Manifest.
-- The \`Scaffold Completion\` section must report completed Scaffold Manifest IDs or \`VCM:CODE\` IDs, remaining markers if any, private helpers added, manifest deviations, and compile/typecheck or L0/L1 failures.
+- The Scaffold Completion ID set must equal the Scaffold Manifest ID set, with every ID appearing exactly once.
+- \`done\` requires \`Marker State: removed\` and green proof evidence. \`failed\` requires \`Marker State: present\` and objective failure evidence.
+- Use \`Decision: ready_for_review\` only when every item is \`done\`, \`Decision: failed\` only after the complete sweep contains at least one \`failed\` item, and \`Decision: incomplete\` when the sweep is unfinished.
 
 ### Generated Context
 
@@ -103,7 +110,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\`. If the user explicitly approved continuing without the exact check, record the approval and reason; the approval does not change Coder's decision.
+- If required compile/typecheck/L0/L1 validation cannot run or cannot complete, record it as the affected items' failure disposition; the turn-end decision follows the sweep rules. 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
@@ -111,6 +118,10 @@ Decision: ready_for_review|incomplete|failed
 - Report failure only from objective implementation evidence: compile/typecheck fails, L0/L1 fails, or required compile/typecheck/L0/L1 validation cannot run or complete.
 - Do not report failure based on predicted design failure, public-contract disagreement, architecture disagreement, or validation prediction.
 - Do not stop because of workload, session length, or context size.
+- Never revert implemented work. Commit the actual state at turn end — including failing or non-compiling attempts — as its own commit whose message names the failing checks or errors. The committed failing state is the reproduction scene the fix is verified against.
+- A blocker never ends the turn. Work every assigned ledger item to a terminal state. A completed item has green proof and its marker removed. A failed item has a genuine attempt committed with objective failure evidence and its marker retained. "Cannot proceed", "cannot compile", or "missing dependency" on one item never exempts the others — the scaffold froze every signature and contract, so every remaining item stays attemptable.
+- A failure decision is valid only after the full sweep: every assigned item in a terminal state, and the report carrying a per-item disposition — completed items, and each failed item with its objective evidence and suspected cause. Problems are reported once, consolidated, after the sweep.
+- A turn-budget interruption mid-sweep is \`Decision: incomplete\` with sweep progress for continuation; it is never a vehicle for returning a problem early.
 - Compile/typecheck/L0/L1 failure is not terminal until Coder has attempted to fix implementation-caused failures within the assigned scope.
 - \`Decision: incomplete\` is only for actual interruption or inability to continue the turn; it must not be used for architecture concerns, questions, or predicted risk.
 - If execution is interrupted or the turn must end unexpectedly before all assigned scaffold items are done, write \`coder-completion.md\` with \`Decision: incomplete\`, include completed items, remaining implementation work, validation state, and why continuation is needed. PM decides whether to continue the same route.

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

@@ -13,11 +13,11 @@ You are \`vcm-coder-worker\`, a bounded implementation worker invoked by Coder.
 
 ### Worker Runtime State
 
-- Coder assigns a worker state path and report path.
-- Before editing, read the assigned worker state file and update only that file from \`planned\` to \`running\`.
-- After implementation and assigned checks, commit the assigned files. After the commit succeeds, write the assigned report with the commit hash, then update only the assigned worker state to \`completed\` with the same \`commitHash\` as the final step.
-- If blocked or failed, update only the assigned worker state to \`failed\`, write the reason in \`error\`, and write the report with remaining work.
-- Use \`completed\` only after assigned implementation is complete, assigned markers are removed, required assigned checks pass or have a Coder-recorded exception in the worker task, the report is written, and commit succeeds.
+- Worker runtime status is only \`running\` or \`completed\`.
+- Coder creates the assigned worker state with \`status: running\` and assigns its state path and report path.
+- After the sweep of assigned items and their assigned checks, commit the assigned files. After the commit succeeds, write the assigned report with the commit hash and \`Implementation Result: success|has_failed_items\`, then update only the assigned worker state to \`completed\` with the same \`commitHash\` as the final step.
+- Use \`completed\` only after every assigned item reached a terminal state. A successful item has green assigned proof and its marker removed. A failed item has a genuine attempt committed with objective failure evidence and its marker retained. Use \`success\` only when every item succeeded; otherwise use \`has_failed_items\`.
+- If execution is interrupted before the sweep, commit, or report completes, leave the worker state as \`running\`. Coder must resume the worker or take over the remaining work.
 - Do not set \`handled: true\`; only Coder may do that after reviewing and integrating the worker result.
 
 ### Inputs
@@ -34,7 +34,8 @@ You are \`vcm-coder-worker\`, a bounded implementation worker invoked by Coder.
 ### Implementation Discipline
 
 - Follow \`docs/CODING_STANDARDS.md\`.
-- Implement the assigned \`VCM:CODE\` markers completely and remove those markers before completion.
+- Never revert implemented work; a blocker on one assigned item never ends the assignment — every remaining assigned item stays attemptable under the frozen scaffold.
+- Implement every assigned \`VCM:CODE\` marker: remove a marker when its item completes green; a failed item keeps its marker over the committed attempt, with the failing checks or errors named in the commit message and the report.
 - Preserve architect-defined file responsibilities, callable-surface signatures, visibility, exports, contracts, and error boundaries.
 - Do not add or change cross-file callable surface unless the architecture plan explicitly defines it.
 - Keep changes limited to the assigned module or files.
@@ -48,11 +49,11 @@ 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 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\`. If the user explicitly approved continuing without the exact check, record the approval and reason; the approval does not change the worker state.
+- An assigned check that fails or cannot complete on one item is that item's failure disposition, not a worker failure: record it and continue the sweep. If the user explicitly approved continuing without an exact check, record the approval and reason in the report.
 
 ### Git
 
-- Commit the worker's completed changes before returning to Coder.
+- Commit the worker's actual final state of the assigned files — including failing attempts — before returning to Coder.
 - Commit only changes made for the assigned module or files.
 - Stage only assigned files; do not use \`git add -A\`, \`git add .\`, \`git commit -a\`, or broad path staging.
 - Commit with an explicit assigned-file pathspec: \`git commit --only -m "<message>" -- <assigned-paths>\`. Do not use \`git commit\` without assigned paths.
@@ -65,7 +66,8 @@ You are \`vcm-coder-worker\`, a bounded implementation worker invoked by Coder.
 Return a concise completion report with:
 
 - assigned module/files
-- completed Scaffold Manifest IDs or \`VCM:CODE\` markers
+- implementation result: \`success\` or \`has_failed_items\`
+- per-item disposition: ID, action, result, marker state, proof evidence, and suspected cause for failures
 - files changed
 - tests added or updated
 - L0/L1 checks run
@@ -78,11 +80,12 @@ Use this structure:
 \`\`\`md
 # Coder Worker Report: <worker-id>
 
-Worker Result: completed|failed
+Worker State: completed
+Implementation Result: success|has_failed_items
 
 ## Assigned Scope
 
-## Completed Markers
+## Item Dispositions
 
 ## Files Changed
 

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

@@ -13,11 +13,54 @@ Use only these decisions:
 - \`approve\`: required gate evidence is present, current, internally consistent, sufficient for that gate, and has no gate-blocking finding.
 - \`request_changes\`: evidence is missing, stale, contradictory, incomplete, insufficient, not reviewable, or unsafe.
 
+Every Gate Review is a complete review of the current gate inputs. Review all
+required evidence and rerun every required mechanical check before deciding.
+Do not carry forward prior conclusions, closed checks, or partial verification.
+Resolving prior findings does not replace the complete review. Return \`approve\`
+or \`request_changes\` only after the review is complete.
+
 ## Architecture Plan Gate
 
 Format is necessary but not sufficient. Do not approve an architecture plan
 only because required sections exist.
 
+Treat \`architecture-plan.md\` as the complete current executable plan, not
+revision history. Review the entire current plan and scaffold, not only changed
+sections or prior findings. Return \`request_changes\` if the plan retains
+superseded decisions, obsolete ledger items, resolved findings, prior-round
+notes, stale risks, or outdated implementation guidance.
+
+Before any other architecture-plan analysis, reconcile the Scaffold Manifest
+ledger against the committed scaffold (\`.ai/tools/check-scaffold-ledger\`
+automates it). Run this on every review round, including revision rounds:
+
+- Extract the ledger ID set from \`architecture-plan.md\` and the \`VCM:CODE\` ID
+  set from the worktree. They must be equal, every ID exactly once on each
+  side, and every marker in its declared file. Every ledger item must have its
+  marker pre-placed.
+- Any set mismatch, duplicated or missing ID, marker outside its declared
+  file, deferred-placeholder or open-ended coverage language ("as work
+  proceeds", "replicate", "etc.", "and others"), or ledger entry without a
+  marker is \`request_changes\` regardless of plan prose quality. Record both
+  ID sets (or their exact diff) in the report.
+- Verify \`Scaffold Build Evidence\` names the compile/typecheck commands, a
+  green result, and the scaffold commit hash, and that the hash matches the
+  reviewed scaffold commits. Missing, red, or hash-mismatched evidence is
+  \`request_changes\`.
+- For every module whose build configuration the plan changes, open its package
+  manifest and verify the evidence table's dependency claims match it exactly,
+  and verify each claimed configuration has its own named proving check, green
+  at the scaffold hash, in \`Scaffold Build Evidence\`. A dependency claim that
+  contradicts the manifest, or a build-configuration claim without a named
+  green check, is \`request_changes\`.
+- For every new cross-module call path the plan's design describes, verify the
+  scaffold materializes it in a wired exemplar — imports, interface
+  implementations, and gating present, placeholder bodies — covered by a named
+  green check, and that every symbol the path requires is reachable from the
+  consuming module's declared dependencies. A call path that exists only in
+  prose over stub-only scaffold is \`request_changes\`.
+- Record each of these pre-checks and its result in the report.
+
 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\`,
@@ -40,6 +83,17 @@ direction, public surface and callers, architecture invariants, state or durable
 failure/retry/restart/cancellation/concurrency behavior, docs/generated-context
 impact, and whether Coder is left to make architecture decisions.
 
+For every exhaustiveness claim the design depends on — "only", "all", "none",
+"never", or an item count — reconstruct the claimed set independently. When
+the plan records a generating command, re-run it at the reviewed commit, diff
+its output against the claimed set, and then judge whether the query itself is
+adequate (what the pattern could miss); a clean diff with an adequate query
+closes the item. When the claim is marked judgment-derived, reconstruct it
+from the source (search, package manifests, or the relevant catalogue) instead
+of verifying only the cited instances. A claimed-complete enumeration with
+neither a recorded command nor a judgment-derived basis, or one that fails
+reconstruction, is unsupported by code evidence and is \`request_changes\`.
+
 Request changes when the plan is structurally complete but architecturally
 under-specified, logically inconsistent, unsupported by code evidence, unsafe
 for boundary cases, conflicts with current project architecture, or leaves key
@@ -227,6 +281,7 @@ If there are no findings, write:
 ## Architecture Analysis
 
 - Evidence Read:
+- Architecture Brief Fit:
 - End-To-End Flow:
 - Scope Fit:
 - Code Reality:

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

@@ -12,7 +12,7 @@ Project-specific rules may be added outside the VCM managed block when they make
 
 - Coder and Coder Worker follow the accepted task scope, role message, architecture plan, and scaffold. Architect Debug Mode and Architecture Diagnosis Mode follow their confirmed root cause and PM-routed evidence.
 - Coder and Coder Worker must not change file responsibilities, callable-surface signatures, visibility, exports, contracts, or architect-defined intent unless the approved plan allows it. In Debug Mode or Architecture Diagnosis Mode, Architect may change file responsibilities and callable surfaces after confirming the root cause, and must update affected callers, contracts, and tests.
-- Complete assigned \`VCM:CODE\` placeholders and remove them before handoff.
+- Remove each \`VCM:CODE\` marker when its item completes successfully. If implementation fails after a genuine attempt, keep the failed item's marker on the committed attempt and report the objective failure evidence. A successful implementation handoff must not contain remaining assigned markers.
 - Do not fake completion: no hardcoded success, disabled logic, swallowed errors, test-only shortcuts, or silent fallback that hides failure.
 - Implement behavior from the approved architecture, existing domain model, real inputs, and project runtime flow.
 - Do not derive logic from visible test fixtures, fixed sample values, snapshot text, or special branches that only satisfy known tests.

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

@@ -89,8 +89,8 @@ 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 Plan Revision:** If Architect planning is incomplete, route Architect again. If the architecture-plan Gate returns \`request_changes\`, route the report to Architect, then rerun the 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.
+- **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.
 - **Code-Diff Correction:** If the code-diff Gate returns \`request_changes\`, suspend the main flow and enter Architect Debug Branch with the Gate report.
 - **Tester Failure:** If Tester returns \`Test Result: fail\` for the original Coder implementation, enter Architect Debug Branch.
@@ -299,7 +299,9 @@ PM may lightly rewrite the user's words to:
 - Once PM starts routing an accepted delivery request, drive the accepted scope to completion unless the user explicitly changes it.
 - Do not allow requested work to be deferred, converted into follow-up scope, reduced, or returned to the user because of workload, session length, context size, task size, predicted difficulty, or role preference.
 - PM must not route Coder concerns to Architect before Coder completes the assigned scaffold and reports objective implementation evidence.
-- Coder feedback that stops before implementation, compile/typecheck, or L0/L1 evidence is incomplete work, not a valid architecture signal.
+- Coder feedback that stops before the full sweep of assigned items is incomplete work, not a valid failure or architecture signal.
+- Before acting on any Coder decision, verify that every Scaffold Manifest item appears exactly once in Scaffold Completion, each disposition is consistent with its marker state in the tree, and the reported Decision matches the dispositions.
+- Return any missing, duplicate, unswept, marker-inconsistent, or decision-inconsistent result to Coder as incomplete work regardless of the reported Decision.
 - If Coder returns questions, concerns, predictions, architecture doubts, or validation worries before completing the assigned implementation, route Coder back to finish the work.
 - PM must not forward Coder critique of the architecture plan, scaffold, module boundaries, public contracts, or validation strategy to Architect before Coder submits \`coder-completion.md\` with compile/typecheck/L0/L1 evidence.
 - Before that evidence exists, any Coder architecture critique is incomplete work; route Coder back to finish implementation.

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

@@ -25,6 +25,7 @@ const REQUIRED_HEADINGS = {
         "Module/File Plan",
         "Public Surface Impact",
         "Scaffold Manifest",
+        "Scaffold Build Evidence",
         "Tester Coverage Hints",
         "Docs Impact",
         "Known Risks",
@@ -110,6 +111,15 @@ export function checkMarkdownArtifact(kind, artifactPath, content) {
     };
 }
 function validateArtifactFields(kind, content) {
+    if (kind === "architecture-plan") {
+        const result = /^\s*Planning Result\s*:\s*(.+?)\s*$/im.exec(content)?.[1]?.trim().toLowerCase();
+        if (!result) {
+            return ["Planning Result is required and must be complete."];
+        }
+        return result === "complete"
+            ? []
+            : [`Planning Result must be complete; received "${result}".`];
+    }
     if (kind === "architecture-brief") {
         const status = /^\s*Architecture Brief Status\s*:\s*(\S+)\s*$/im.exec(content)?.[1]?.toLowerCase();
         const invalidFields = status === "interviewing" || status === "confirmed"

package/package.json

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