vibe-coding-master 0.7.32 → 0.7.33

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

@@ -46,6 +46,9 @@ ${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.
+- When a plan would add a file-local override, normalization, or bypass of a shared default, constant, or documented contract, search the current worktree for the same mechanism. If it already exists in at least two other files, treat the new occurrence as evidence of an upstream ownership or contract problem.
+- For every existing code site the plan or scaffold will change, inspect the complete callable unit or site and verify its current comments, contracts, preconditions, configuration scope, lifecycle assumptions, and safety assumptions against implementation and runtime configuration. Record the verified assumptions in \`architecture-evidence.md\`.
+- When the plan newly handles one member of an existing persisted structure, gate, invariant, or other semantic class, reconstruct the complete directly related member set and record its completeness basis in \`architecture-evidence.md\`.
 - 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 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.
@@ -69,13 +72,16 @@ ${renderRoleMemoryRules("architect")}
 
 #### 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, Scaffold Build Evidence, Tester Coverage Hints, Docs Impact, Known Risks, and Coder Handoff Notes.
+- \`architecture-plan.md\` must start with \`Planning Result: complete|incomplete|user clarification required\` and use these sections: Accepted Scope, Current Code Reality, Existing Assumptions And Class Coverage, 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\`: 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.
+- \`Existing Assumptions And Class Coverage\`: include a \`Touched Site | Verified Assumption Or Contract | Evidence | Plan Effect | Disposition\` table and a \`Class Source | Completeness Basis | Member | Plan Disposition\` table. Cover every existing code site named by the Module/File Plan or Scaffold Manifest, including assumptions the plan preserves, updates, or invalidates. When the plan newly handles one member of an existing persisted structure, gate, invariant, or other semantic class, list every directly related member and its disposition. A bare \`None.\` is allowed only when the plan changes no existing code site and handles no member of an existing class.
 - \`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.
+- Correct every verified existing assumption that the plan invalidates through the Architecture Decision, affected callable surfaces, scaffold, and docs impact. Do not leave Coder to discover or reconcile the contradiction.
+- When the repeated-workaround threshold is met, \`Architecture Decision\` must explicitly fix the owning behavior, confirm that local handling is intended and correct the owning documentation, or record the unresolved issue and affected call sites through Known Issues Sync. Extracting the workaround into a helper is not an upstream disposition.
 - \`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. Use columns in the exact order \`ID | Action | File | ...\`; use an ID matching \`AA-1\` through \`AAAAAA-9999\`, an Action of exactly \`create\`, \`change\`, or \`delete\`, and a backticked repo-relative File path. An item is one created body or surface, one required change site — one contiguous edit region inside an existing body or surface — or one deletion of a body, site, or file. An item not in the ledger is not in the plan; coder must not implement it.

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

@@ -117,6 +117,26 @@ 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\`.
 
+Run a backward-impact pass over the plan:
+
+- For every existing code site named by the Module/File Plan or Scaffold
+  Manifest, inspect the complete callable unit or site and verify its current
+  comments, contracts, preconditions, configuration scope, lifecycle
+  assumptions, and safety assumptions against implementation and runtime
+  configuration.
+- Identify which verified assumptions the plan preserves, updates, or
+  invalidates. Request changes when the plan omits a touched site, misstates an
+  assumption, or invalidates one without correcting the architecture, affected
+  surfaces, scaffold, and docs impact.
+- When the plan newly handles one member of an existing persisted structure,
+  gate, invariant, or other semantic class, independently reconstruct the
+  complete directly related member set from its declaration, catalogue,
+  adjacent contract, or repository search. Verify that every member has an
+  evidence-backed plan disposition.
+- Keep this pass bounded to plan-cited or scaffold-touched existing sites and
+  their directly related semantic classes. Do not expand it into an unrelated
+  whole-repository review.
+
 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
@@ -272,6 +292,18 @@ Verify that the Diagnosis evidence records applicable L2/L3 validation for the
 diagnosed failure path. Request changes when an applicable check was not run,
 did not pass, or does not exercise that failure path.
 
+When a changed production or test hunk adds a file-local override,
+normalization, or bypass of a shared default, constant, or documented contract,
+search the current worktree for the same mechanism. If it already exists in at
+least two other files, request changes unless the accepted architecture
+explicitly fixes the owning behavior, confirms that local handling is intended
+and corrects the owning documentation, or records the unresolved issue and
+affected call sites through the Architect-owned known-issue flow. A documented
+post-validation Architect docs sync satisfies the documentation timing; the
+correct disposition must already be explicit. Extracting the workaround into a
+helper is not an upstream disposition. Classify the finding as \`implementation\`
+unless the owning behavior and contract are entirely test-only.
+
 Check every source for project coding-standard compliance, unnecessary
 duplication or abstraction, inconsistent error handling, unhandled fallible
 paths, debug/task-only artifacts, \`VCM:CODE\`, task-process comments or labels,
@@ -313,6 +345,8 @@ Use this findings structure:
 - End-To-End Flow:
 - Scope Fit:
 - Code Reality:
+- Invalidated Assumptions:
+- Existing-Class Completeness:
 - Ownership:
 - Data Flow:
 - Lifecycle:

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

@@ -18,6 +18,8 @@ Project-specific rules may be added outside the VCM managed block when they make
 - Do not derive logic from visible test fixtures, fixed sample values, snapshot text, or special branches that only satisfy known tests.
 - Coder and Coder Worker keep the diff inside the approved plan. In Debug Mode or Architecture Diagnosis Mode, Architect owns the technical change boundary after confirming the root cause.
 - Preserve existing behavior unless the approved plan or a confirmed Debug/Diagnosis root cause changes it.
+- Do not introduce the same file-local override, normalization, or bypass of a shared default, constant, or documented contract into a third file unless the accepted architecture explicitly fixes the owning behavior, confirms local handling is intended and corrects the owning documentation, or records the unresolved issue and affected call sites through the Architect-owned known-issue flow.
+- Extracting the repeated local workaround into a helper is not an upstream disposition.
 
 ## Comments
 

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

@@ -18,6 +18,8 @@ During an active Architect Interview, handle the user's answers and final confir
 - 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.
+- For every existing code site the drafted mechanism may change, record the site's verified safety, configuration, lifecycle, state, data, and contract assumptions. Treat comments and docs as claims to verify against implementation and runtime configuration, not as authority or text to ignore.
+- When the draft newly handles one member of an existing persisted structure, gate, invariant, or other semantic class, reconstruct and record the complete directly related member set and the evidence basis for its completeness.
 
 ## Feasibility Draft
 
@@ -89,6 +91,10 @@ Architecture Evidence Status: incomplete|complete
 
 ## Callers And Consumers
 
+## Existing Assumptions
+
+## Related Class Inventories
+
 ## External Boundaries
 
 ## Code And Docs Conflicts
@@ -96,7 +102,7 @@ Architecture Evidence Status: incomplete|complete
 ## 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.
+Identify inspected files and symbols, callers or consumers, state and side effects, verified behavior, existing assumptions and their scope, related class members and their completeness basis, and the worktree revision. Replace stale evidence instead of appending history.
 
 ## Completion
 

package/package.json

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