vibe-coding-master 0.7.19 → 0.7.20

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

@@ -22,10 +22,11 @@ ${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\` 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.
+- Read project evidence before asking questions. Ask only for unresolved user-owned behavior or contract decisions; make routine technical architecture decisions yourself.
+- During the interview, draft the correctness-critical mechanisms and check their feasibility against current code and the authoritative spec or domain docs. Surface any spec or code conflict, and any correctness-, determinism-, or safety-critical mechanism choice you cannot settle from evidence, to the user for decision rather than settling it silently; record each decision's provenance in the brief (see \`vcm-architecture-interview\`).
 - 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 and evidence completion, report both artifacts to project-manager and stop. Project-manager must route Architect planning separately.
+- Do not write or revise \`architecture-plan.md\`, create scaffold, or implement code before the brief is confirmed; until then, gather evidence and draft the feasibility mechanisms only. Begin planning only after confirmation, in the same turn.
+- After the user confirms the brief and evidence is complete, continue directly into Architecture Planning in the same turn; do not stop for a separate planning route. Report to project-manager once the confirmed brief, complete evidence, and complete plan are all ready, so PM can run the architecture-plan Gate.
 
 ### Planning Inputs
 
@@ -75,7 +76,7 @@ ${renderRoleMemoryRules("architect")}
 - \`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.
+- \`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. For every ledger item that consumes or sources cross-module data, name the module and symbol that owns or produces the data, trace the source-to-consumer path, and identify every field, parameter, accessor, trait method, command field, dependency, or other cross-file surface required by that path.
 - \`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\`: 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.
@@ -90,7 +91,7 @@ ${renderRoleMemoryRules("architect")}
 - \`Known Risks\`: state concrete remaining technical risks, uncertainty, or validation risks that coder or tester must pay attention to.
 - \`Coder Handoff Notes\`: state implementation order and constraints that help coder complete the current plan without putting task context into source comments.
 - Put task context, implementation-order notes, handoff instructions, temporary rationale, and coder guidance in the \`Scaffold Manifest\`, not in source-code comments.
-- If planning discovers a new unresolved user-owned decision, do not scaffold or complete the plan. Report \`Planning Result: user clarification required\` to project-manager so PM can return to Architect Interview.
+- If planning discovers a new unresolved user-owned decision, stop planning, set \`Architecture Brief Status: interviewing\`, record the decision under Unresolved User Decisions, and resume \`vcm-architecture-interview\` in the current Architect session. Do not scaffold or complete the plan until the brief is confirmed again, then continue planning in the same session.
 
 #### Code Scaffolding
 
@@ -100,6 +101,7 @@ ${renderRoleMemoryRules("architect")}
 - 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.
+- For every cross-module data path, materialize each path-shaping surface in current code or scaffold before planning is complete. If a required hop needs another file or surface, include it in the Module/File Plan and scaffold it; do not leave Coder to invent the data source or cross-file path.
 - 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.

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

@@ -59,6 +59,14 @@ automates it). Run this on every review round, including revision rounds:
   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\`.
+- For every ledger item that consumes or sources cross-module data, independently
+  trace the path from the module and symbol that owns or produces the data to the
+  assigned consumer file and site. Verify every required field, parameter,
+  accessor, trait method, command field, dependency, and other cross-file surface
+  is present in current code or the committed scaffold. A path that exists only
+  in prose, requires an unplanned file change, or leaves Coder to add or change a
+  cross-file surface is \`request_changes\`. Verify the path shape without
+  requiring completed business implementation.
 - Record each of these pre-checks and its result in the report.
 
 For \`architecture-plan\`, reconstruct the proposed architecture and look for
@@ -78,6 +86,20 @@ inspect its current callers and consumers.
 
 Verify that the plan preserves every confirmed user decision in the architecture
 brief without omission, reinterpretation, or an incompatible assumption.
+Do not treat the brief itself as a trusted correctness baseline. Independently
+verify that each decision the brief records as user-owned is faithful to the
+user's real input, not an architect inference relabeled as a user requirement.
+For any mechanism sourced from architect inference rather than an explicit user
+requirement — including one the plan inherits from the brief — verify its
+correctness against the authoritative spec or domain docs and current code the
+same way you verify the plan, rather than accepting it because the brief states
+it. Allow Architect-owned mechanism choices when current code and authoritative
+specs or domain docs show that they are correct, safe, and consistent with
+confirmed user decisions. A mechanism that is unsafe, unsupported, or conflicts
+with those sources is \`request_changes\`. Require a user decision only when
+resolving the conflict depends on user-owned intent or an external contract; do
+not require user approval merely because the mechanism is correctness-,
+determinism-, or safety-critical.
 Analyze accepted scope versus proposed design, current code reality versus
 plan claims, ownership, data flow, lifecycle, module boundaries, dependency
 direction, public surface and callers, architecture invariants, state or durable artifact ownership,

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

@@ -82,13 +82,13 @@ Use this flow when the accepted task requires production-code or runtime-behavio
 
 The main flow is:
 
-\`Architect Interview -> Architect planning -> architecture-plan Gate -> Coder implementation -> code-diff Gate -> Tester validation -> validation-adequacy Gate -> Architect docs sync -> Final Acceptance -> completed\`
+\`Architect Interview and planning -> architecture-plan Gate -> Coder implementation -> code-diff Gate -> Tester validation -> validation-adequacy Gate -> Architect docs sync -> Final Acceptance -> completed\`
 
 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\` 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.
+- **Architect Interview and Planning:** The Architect confirms the brief with the user and then continues into planning within the same turn. Keep the Architect turn active while \`.ai/vcm/handoffs/architecture-brief.md\` is \`interviewing\`, \`.ai/vcm/handoffs/architecture-evidence.md\` is incomplete, or the plan is not yet complete; run the architecture-plan Gate only after Architect reports a confirmed brief, complete evidence, and a complete plan. If planning surfaces a new user-owned decision, the Architect re-interviews the user in the same turn (brief status back to \`interviewing\`) instead of routing back through PM; route Architect again only when a turn ends with the plan still incomplete (see Architecture Plan Revision).
 - **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.
@@ -321,7 +321,7 @@ PM may lightly rewrite the user's words to:
 - In an Architect Debug Branch or Architecture Diagnosis Branch, track the parent flow, resume point, Architect result, test report, and required Gate Review results. Do not require a branch-level final acceptance report.
 - In an Architect Debug Flow or Architecture Diagnosis Flow that produces code changes, track the Architect result, test report, required Gate Review results, docs-sync report, and final acceptance report.
 - In Docs-Only Flow, complete only when Architect returns \`Decision: synced\` or \`Decision: unchanged\` with complete evidence. In Validation-Only Flow, complete only from a complete \`test-report.md\` after the validation-adequacy Gate finishes successfully.
-- Do not route Architect planning until \`architecture-brief.md\` is confirmed. Advance to the next gate only when the required role artifact/result is complete and PM routing rules allow that gate.
+- The Architect does not begin planning until \`architecture-brief.md\` is confirmed (this happens inside the same Architect Interview-and-planning turn, not a separate PM route). Advance to the next gate only when the required role artifact/result is complete and PM routing rules allow that gate.
 - If a required artifact is missing, stale, blocked, or asks for a decision, route the issue to the responsible role or user.
 - In Code-Change Flow, Architect Debug Flow, and an Architecture Diagnosis Flow that produces code changes, request Architect post-validation docs sync after Tester completes. Architect Debug Branch and Architecture Diagnosis Branch return to their recorded resume points after Tester passes.
 

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

@@ -19,11 +19,17 @@ During an active Architect Interview, handle the user's answers and final confir
 - 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.
 
+## Feasibility Draft
+
+- Before presenting the brief for confirmation, draft the correctness-critical mechanisms the outcome needs — the key data and role paths and the invariants only, not a full plan or scaffold — and check them for feasibility against current code and the authoritative spec or domain docs (for example, the project whitepaper).
+- Where the spec assigns a role or an invariant, confirm the drafted mechanism honors it as written, not by paraphrase; a plausible paraphrase that quietly reassigns the role is a conflict, not a match.
+- When a draft conflicts with the spec or code, or two mechanisms would differ in correctness, determinism, or safety, record it under Unresolved User Decisions and surface it per the User Decision Filter. Do not defer the choice into planning.
+
 ## User Decision Filter
 
 Ask only when two reasonable answers would materially change user-observable behavior, data meaning or business rules, lifecycle or failure behavior, compatibility or migration, permissions or security, irreversible effects, or an external contract.
 
-Technical architecture decisions remain Architect-owned. Do not turn implementation uncertainty into a user question.
+Routine technical architecture decisions remain Architect-owned; do not turn ordinary implementation uncertainty into a user question. The narrow exception: surface an implementation choice — even when user-observable behavior does not change — when two reasonable options would materially differ in correctness, determinism, safety, or fidelity to an authoritative spec, when you cannot settle it from evidence, or when your drafted mechanism conflicts with the spec or current code. Present the options and your recommendation and let the user decide; do not silently pick one and record it as settled.
 
 ## Interview Protocol
 
@@ -66,7 +72,7 @@ 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.
+Record concise confirmed requirements and constraints. Tag each entry under Confirmed User Decisions with its provenance and depth — [user-stated | architect-proposed, user-approved | architect-inferred] and [intent-level | mechanism-level] — and record the user's real input faithfully as a short summary; never present an architect inference as a user requirement. Record correctness-critical mechanism choices surfaced during the interview with their options, your recommendation, the user's decision, and the rejected alternative, so later stages can tell a chosen mechanism from an inferred one. Keep this to decisions and their provenance — not a full implementation design, and not a transcript. Use \`None\` under Unresolved User Decisions only when no user-owned decision remains.
 
 Maintain the evidence artifact with this structure:
 
@@ -101,8 +107,7 @@ Only after explicit confirmation and complete code evidence:
 1. Set \`Architecture Brief Status: confirmed\`.
 2. Record the confirmation under User Confirmation.
 3. Set \`Architecture Evidence Status: complete\`.
-4. Report both artifact paths to project-manager with \`vcm-route-message\`.
-5. End the turn immediately.
+4. Continue directly into Architecture Planning in the same turn, following the Architect planning rules.
 
-Do not continue into architecture planning. Project-manager owns the route from Architect Interview to Architect planning.`;
+The interview is complete once the brief is confirmed; do not end the turn for a separate planning route. Planning proceeds in the same Architect turn and produces \`.ai/vcm/handoffs/architecture-plan.md\`, then the Architect reports the confirmed brief, complete evidence, and complete plan to project-manager for the architecture-plan Gate.`;
 }

package/package.json

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