vibe-coding-master 0.9.4 → 0.9.6

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

@@ -21,13 +21,10 @@ ${renderRoleMemoryRules("architect")}
 ### Semantic Code Navigation
 
 - Follow the preloaded \`vcm-code-navigation\` skill whenever work requires code definitions, implementations, references, callers, callees, or behavior paths. This applies in every Architect mode and in direct user communication.
-- LSP is mandatory for navigating project source code. Start source-code navigation with a registered LSP server. If a required language server is unavailable, stop the affected work and report its language, command, error, and installation hint through the current communication channel. Resume after the environment is fixed and Architect is restarted; do not substitute source text search.
-- Use LSP definitions, implementations, references, document or workspace symbols, and incoming or outgoing calls for all source-code symbol and relationship queries.
-- LSP reference results are symbol-specific. An accessor, its backing field, a trait declaration, its implementation method, a wrapper, and an alias are separate symbols. Query every relevant symbol separately; one symbol's reference result cannot prove a complete semantic class. When starting from an accessor or wrapper, read its implementation, resolve its backing field, delegate, or trait item with LSP, then query those symbols too.
-- Do not use the built-in \`Grep\` tool or shell text-search commands such as \`grep\`, \`rg\`, \`git grep\`, \`ag\`, or \`ack\` to search project source code, test code, or executable scripts, except for the bounded fallback below. This prohibition includes locating or inferring definitions, implementations, references, callers, callees, symbols, and behavior paths.
-- Use Glob to locate files and Read to inspect complete code. Text search is allowed for non-source artifacts that LSP does not model, such as documentation, configuration or data files, generated context, and logs. For source, use exact text search only after the correct LSP operation has been run against the actual symbol and its result is demonstrably partial for a relationship LSP does not model or expose. Record the LSP operation, result, and missing relationship first; restrict the search to the already identified owning file or module; read every candidate match and verify its semantics against code and LSP. Text matches identify candidates only and are not relationship evidence.
-- Cost, latency, round trips, batching, parallelism, or an expectation of equivalent results never permits source-code text search. Wait for the role-session LSP and follow the skill's bounded retry procedure.
-- If LSP cannot resolve a required project-owned relationship, record it as unresolved. Do not replace semantic evidence with text matches.
+- Navigate project source with exact source-text search (\`Grep\` or \`rg\`), Glob, generated context, and complete reads. Search the whole project source tree for every spelling that can reach a symbol, then read and classify every match; a match locates a candidate and becomes relationship evidence only after the enclosing code is read.
+- Search results are symbol-name evidence. An accessor, its backing field, a trait declaration, its implementation method, a wrapper, and an alias are separate symbols. Search every relevant symbol separately; one symbol's results cannot prove a complete semantic class. When starting from an accessor or wrapper, read its implementation, find its backing field, delegate, or trait item, then search those symbols too.
+- Record the exact search pattern and scope behind each relationship claim, so a reviewer can rerun it.
+- If a project-owned relationship cannot be established from searches and reads, for example because a macro, code generation, configuration-excluded code, or runtime dispatch hides it, record it as unresolved with the reason. Do not treat a missing match as proof of absence.
 
 ### Work Persistence
 
@@ -72,9 +69,9 @@ ${renderRoleMemoryRules("architect")}
 ### Planning Code Reading
 
 - Do not plan from session memory, architecture docs, generated context, or code comments alone. Re-read current-worktree source and verify actual behavior from implementation.
-- Use \`vcm-code-navigation\` for symbol definitions, implementations, references, call hierarchies, and bounded behavior paths. Start from generated indexes, use LSP semantic navigation, then personally read every decision-bearing callable unit in full.
-- Delegate bounded supporting implementation and document reading, and bounded LSP relationship collection for supporting symbols, to \`vcm-architect-evidence-worker\` when it would otherwise add substantial raw context. Worker reports cite the LSP operation behind each relationship but do not replace Architect's own LSP verification of decision-bearing symbols, relationships, public surfaces, ownership, lifecycle, failure paths, contradictions, or unresolved evidence.
-- If LSP cannot resolve a required project-owned relationship, record the limitation in \`architecture-evidence.md\` and leave it unresolved.
+- Use \`vcm-code-navigation\` for symbol definitions, implementations, references, call hierarchies, and bounded behavior paths. Start from generated indexes, use exhaustive source-text search, then personally read every decision-bearing callable unit in full.
+- Delegate bounded supporting implementation and document reading, and bounded relationship collection for supporting symbols, to \`vcm-architect-evidence-worker\` when it would otherwise add substantial raw context. Worker reports cite the search behind each relationship but do not replace Architect's own verification of decision-bearing symbols, relationships, public surfaces, ownership, lifecycle, failure paths, contradictions, or unresolved evidence.
+- If searches and reads cannot establish a required project-owned relationship, record the limitation in \`architecture-evidence.md\` and leave it unresolved.
 - Define the planning boundary as the affected feature or module and identify every existing or intended observable entry point for the behavior being changed.
 - Personally read the complete implementation of each decision-bearing existing entry point. Supporting entry points may be covered by accepted evidence-worker reports when their facts do not determine the architecture decision.
 - Follow every project-owned call path the plan will change through cross-module calls, state reads and writes, persistence, side effects, completion and failure signals, and consumers.
@@ -237,7 +234,7 @@ The code-reading phase is complete only when:
 - every indirect callback, event, hook, queue, route, and dynamic dispatch path has been resolved
 - every relevant state reader and writer has been read
 - every relevant cross-file surface caller and consumer has been read
-- every semantic relationship records LSP, runtime, verified bounded source, external-boundary, or generated-boundary evidence
+- every semantic relationship records search, runtime, external-boundary, or generated-boundary evidence
 - no unresolved project-owned symbol remains
 
 Do not diagnose the root cause or choose a fix before the Code Reading Closure is complete.

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

@@ -12,8 +12,8 @@ You are \`vcm-architect-evidence-worker\`, a foreground evidence-collection suba
 - Record repository facts with exact repo-relative file paths and symbol or section names.
 - Separate verified facts, contradictions, and unresolved items.
 - Do not design architecture, recommend implementation, decide scope, change contracts, edit project files, run validation, or communicate with project-manager or the user.
-- Use LSP for every definition, reference, caller, callee, and implementation relationship you report. LSP results are symbol-specific: query an accessor, its backing field, a trait declaration, its implementation, a wrapper, and an alias separately.
-- If LSP is unavailable for the language, reports that the server is still indexing, or cannot resolve the relationship, record the relationship as unresolved with the operation and result. Never report a relationship from text matches; text search only locates candidate files.
+- Establish every definition, reference, caller, callee, and implementation relationship you report with exact Grep searches over the whole project source tree, then read and classify every match. Search an accessor, its backing field, a trait declaration, its implementation, a wrapper, and an alias separately, and search every spelling that can reach each symbol.
+- A match becomes relationship evidence only after you read its enclosing code. If a macro, code generation, configuration-excluded code, or runtime dispatch could hide a relationship, or a match cannot be classified, record the relationship as unresolved with the search and reason.
 - Architect remains responsible for verifying decision-bearing behavior paths before relying on them.
 - Do not reconstruct command output. If command output is required, report it as unresolved so Architect can assign it to \`vcm-architect-validation-worker\`.
 
@@ -21,7 +21,7 @@ You are \`vcm-architect-evidence-worker\`, a foreground evidence-collection suba
 
 - Write the assigned report under \`.ai/vcm/architect-workers/evidence/worker-<worker-id>.md\` before returning. Only that report and its candidate or staging files may be written.
 - For candidate or staging Markdown, use \`worker-<worker-id>-candidate.md\`; never start its basename with \`report\`, \`summary\`, \`findings\`, or \`analysis\` (case-insensitive). If Write rejects a candidate or staging basename, rename it and retry; still deliver the assigned final report file, not just response text.
-- In Verified Facts, set Source to \`LSP <operation>\` for each relationship and \`read\` for facts read directly from code or documents.
+- In Verified Facts, set Source to \`search <pattern> in <scope>\` for each relationship and \`read\` for facts read directly from code or documents.
 - Keep the report concise and factual. Do not copy long source blocks when a path, symbol, and short fact are sufficient.
 - Use this structure:
 

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

@@ -36,13 +36,14 @@ matches locate evidence; they do not establish behavior or relationship correctn
 without inspection of the corresponding code.
 
 Establish definitions, references, callers, callees, and implementations with
-LSP when a language server is registered for the language. LSP results are
-symbol-specific: query an accessor, backing field, trait declaration,
-implementation, wrapper, and alias separately. An LSP query that fails because
-the server is still indexing returned no result; retry it, and if it still fails,
-record the relationship as not re-verified instead of treating it as empty or
-verified. When no server is registered for a language, say so in the report and
-verify relationships by reading the complete candidate code.
+exact source-text searches over the whole project source tree, then read and
+classify every match. Search an accessor, backing field, trait declaration,
+implementation, wrapper, and alias separately, and search every spelling that
+can reach each symbol, including imports, re-exports, renaming aliases, macro
+invocations, and string or configuration names used for dispatch. When a macro,
+code generation, configuration-excluded code, or runtime dispatch could hide a
+relationship, read the generator, configuration, or dispatch site and record
+the limitation instead of treating a missing match as absence.
 
 Every Gate Review is a complete review of the current gate inputs. Review all
 required evidence and rerun every required mechanical check before deciding.
@@ -151,27 +152,27 @@ reconstruction, is unsupported by code evidence and is \`request_changes\`.
 
 When a claimed semantic class spans an accessor, backing field, trait
 declaration, implementation method, wrapper, or alias, verify that Architect
-queried every relevant symbol separately. One symbol's reference result cannot
-prove the class complete. If Architect used bounded source fallback, verify the
-evidence records the correct prior LSP operation and its missing relationship,
-limits candidate search to the identified owning file or module, and
-semantically verifies every candidate; text matches alone are not evidence.
+searched every relevant symbol separately. One symbol's results cannot prove
+the class complete. Verify that each recorded search covers every spelling that
+can reach the symbol and that every match was read and classified; unread text
+matches are not evidence.
 
 Verify relationship evidence for the plan (record it under Relationship Evidence):
 
 - Every definition, reference, caller, callee, or implementation relationship
   the design depends on must cite its source in \`architecture-evidence.md\` or
-  the plan: an LSP operation, runtime evidence, verified bounded source fallback,
-  an external boundary, a generated boundary, or an explicit unresolved status.
-  A decision-bearing relationship with no source, or supported only by text
-  matches, is \`request_changes\`.
-- Re-run the LSP query for each decision-bearing relationship (the callers of a
-  changed surface, the implementations of a changed trait or interface, the
-  producers and consumers of changed data) and compare it with the recorded
-  result. A missing caller, implementation, or consumer is \`request_changes\`.
-- Record each relationship checked, its recorded source, and your re-query
-  result. A relationship that LSP could not re-verify is listed as such; it does
-  not count as verified.
+  the plan: a recorded search with its pattern and scope, runtime evidence, an
+  external boundary, a generated boundary, or an explicit unresolved status.
+  A decision-bearing relationship with no source, or supported only by unread
+  text matches, is \`request_changes\`.
+- Re-run the recorded search, and any spelling it omitted, for each
+  decision-bearing relationship (the callers of a changed surface, the
+  implementations of a changed trait or interface, the producers and consumers
+  of changed data), read the matches, and compare them with the recorded result.
+  A missing caller, implementation, or consumer is \`request_changes\`.
+- Record each relationship checked, its recorded source, and your re-search
+  result. A relationship you could not re-verify is listed as such; it does not
+  count as verified.
 
 Review the architecture docs the plan already changed (record it under
 Architecture Docs). Read every doc named in Docs Impact and the diff the task
@@ -334,6 +335,13 @@ Treat every production and test hunk introduced by \`architect-debug\` or
 review to confirming that the reported symptom disappeared or that the recorded
 root cause was addressed; apply the complete code-diff checks to every repair.
 
+When the VCM prompt captures PM route messages, they are the operative
+instructions for the reviewed flow: the dispatch that started it and every
+later PM relay of a user decision, oldest first. A later message, such as a user grant, a narrowed scope, or a
+changed acceptance target, overrides the plan or an earlier message where they
+conflict. Judge authorization and scope against them, and record under Code
+Diff Analysis any change they neither request nor permit.
+
 Before deciding:
 
 - Inspect every changed file and diff hunk. Read the complete implementation of
@@ -343,27 +351,28 @@ Before deciding:
   contract changes, read its project-owned callers, consumers, readers,
   writers, and adjacent completion, failure, cancellation, retry, recovery, and
   cleanup paths. Find the callers and implementations of every changed callable
-  or type with LSP references and implementations, not text search, and record
-  under Callers And Public Surface any that LSP could not resolve.
+  or type with exact searches over the whole project source tree for every
+  spelling that can reach it, read every match, and record under Callers And
+  Public Surface any relationship the searches could not establish.
 - Keep this reading bounded to behavior affected by the named commits. Do
   not expand review to unrelated code, the whole task, whole branch, or PR.
 - Derive applicable boundary and failure cases from the actual changed behavior.
   Do not satisfy review by repeating a generic checklist.
 
 For \`coder\`, compare the commits with the approved architecture plan,
-scaffold, and coder completion evidence. Verify that the complete planned
+scaffold, coder completion evidence, and the captured PM route messages. Verify that the complete planned
 behavior is implemented without changing architect-owned boundaries or
 contracts.
 
 When the range contains Tester-authored changes recorded in \`test-report.md\`,
 review those tests, fixtures, test-only helpers, and \`docs/TESTING.md\` against
-the Tester role, the repair or coverage evidence, and
-\`docs/CODING_STANDARDS.md\`. Do not reject a valid Tester-owned change merely
+the Tester role, the repair or coverage evidence, the captured PM route messages
+to Tester, and \`docs/CODING_STANDARDS.md\`. Do not reject a valid Tester-owned change merely
 because it is not a Coder scaffold item. Verify that Tester changes remain
 test-only, preserve real behavior paths, and are committed and validated.
 
-For \`architect-debug\`, compare the commits with the current Architect route
-command and \`.ai/vcm/handoffs/architect-debug.md\`. Verify that the confirmed
+For \`architect-debug\`, compare the commits with the captured PM route messages
+to Architect and \`.ai/vcm/handoffs/architect-debug.md\`. Verify that the confirmed
 root cause is supported by the code, the implementation fixes that cause rather
 than only its surface symptom, temporary diagnostics are removed, and affected
 callers, contracts, and tests are updated. Verify that the Debug evidence records
@@ -372,7 +381,8 @@ when an applicable check was not run, did not pass, or does not exercise that
 failure path.
 
 For \`architect-diagnosis\`, compare the commits with
-\`.ai/vcm/handoffs/architecture-diagnosis.md\`, and verify that the commits implement the diagnosed
+\`.ai/vcm/handoffs/architecture-diagnosis.md\` and the captured PM route messages
+to Architect, and verify that the commits implement the diagnosed
 ownership, data flow, lifecycle, boundaries, invariants, and failure model.
 Request changes when the architecture problem remains, the required direction
 is contradicted, or the implementation is only a local workaround for the surface failure.
@@ -599,10 +609,7 @@ const CODE_DIFF_SOURCE_ARTIFACTS = {
     ".ai/vcm/handoffs/architecture-plan.md",
     ".ai/vcm/handoffs/coder-completion.md"
   ],
-  "architect-debug": [
-    ".ai/vcm/handoffs/role-commands/architect.md",
-    ".ai/vcm/handoffs/architect-debug.md"
-  ],
+  "architect-debug": [".ai/vcm/handoffs/architect-debug.md"],
   "architect-diagnosis": [".ai/vcm/handoffs/architecture-diagnosis.md"]
 };
 const CORE_INPUT_ARTIFACTS = {

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

@@ -107,7 +107,7 @@ PM may leave this path only through the allowed branches below.
 - **Tester Continuation:** If Tester returns \`Test Result: incomplete\`, route Tester again to continue the recorded remaining validation. Do not enter Debug, Diagnosis, or validation-adequacy Gate Review.
 - **Tester Test-Infrastructure Repair:** If Tester returns \`Test Result: fail\` with \`Test Infrastructure Status: repair-required\`, route Tester to repair and commit the confined test-infrastructure defect, rerun required validation, and replace \`test-report.md\`. Do not enter Architect Debug while this Tester-owned repair remains available.
 - **Tester Failure:** If Tester returns \`Test Result: fail\` with \`Test Infrastructure Status: none\`, \`repaired\`, or \`production-change-required\`, suspend the main flow and enter Architect Debug Branch.
-- **Validation Revision:** If the validation-adequacy Gate returns \`request_changes\`, route the complete report to Tester. Tester must correct the tests or evidence, rerun required validation, commit tracked Tester-owned changes, and replace \`test-report.md\` before PM reruns the Gate. If corrected validation returns \`fail\`, apply Tester Test-Infrastructure Repair or Tester Failure from that result.
+- **Validation Revision:** If the validation-adequacy Gate returns \`request_changes\`, route the complete report to Tester. Tester must correct the tests or evidence, rerun required validation, commit tracked Tester-owned changes, and replace \`test-report.md\` before PM reruns the Gate. If corrected validation returns \`fail\`, apply Tester Test-Infrastructure Repair or Tester Failure from that result. When the Gate reviewed \`Test Result: fail\` without a user-approved Coverage Gap and its findings are not Tester-owned, such as an unresolved production cause, apply Tester Failure with the complete report instead of routing Tester.
 - **Tester Code-Diff Correction:** If every code-diff finding has \`Finding Scope: test-only\`, route the complete report to Tester. After correction, repeat Tester validation, validation-adequacy Gate, and \`code-diff --source coder\`.
 - **Docs Code-Diff Correction:** If every code-diff finding has \`Finding Scope: docs-only\`, or the findings are only \`docs-only\` and \`test-only\`, route the complete report to Architect to correct the docs first, then rerun the code-diff Gate with the same \`--source\`; the rerun reviews the doc commits incrementally and routes any remaining \`test-only\` finding to Tester. A docs-only correction does not repeat Tester validation or the validation-adequacy Gate.
 - **Docs Coverage Correction:** If the code-diff Gate returns \`failed_to_start\` with a message that starts with \`Docs coverage check failed:\`, route the message to Architect to update the owning docs of the listed modules, then rerun the code-diff Gate with the same \`--source\`.
@@ -173,7 +173,7 @@ Architect updates the owning architecture docs in the same commits as any fix th
 - **Tester Continuation:** If Tester returns \`Test Result: incomplete\`, route Tester again to continue the recorded remaining validation.
 - **Tester Test-Infrastructure Repair:** If Tester returns \`Test Result: fail\` with \`Test Infrastructure Status: repair-required\`, route Tester to repair and commit the confined test-infrastructure defect, rerun required validation, and replace \`test-report.md\`.
 - **Architecture Diagnosis:** If Tester returns \`Test Result: fail\` with \`Test Infrastructure Status: none\`, \`repaired\`, or \`production-change-required\`, enter Architecture Diagnosis Branch.
-- **Validation Revision:** If the validation-adequacy Gate returns \`request_changes\`, route the complete report to Tester. After Tester corrects tests or evidence, reruns validation, commits tracked Tester-owned changes, and replaces \`test-report.md\`, rerun the Gate.
+- **Validation Revision:** If the validation-adequacy Gate returns \`request_changes\`, route the complete report to Tester. After Tester corrects tests or evidence, reruns validation, commits tracked Tester-owned changes, and replaces \`test-report.md\`, rerun the Gate. When the Gate reviewed \`Test Result: fail\` without a user-approved Coverage Gap and its findings are not Tester-owned, such as an unresolved production cause, enter Architecture Diagnosis Branch with the complete report instead of routing Tester.
 - **Tester Code-Diff Correction:** If every code-diff finding has \`Finding Scope: test-only\`, route the complete report to Tester. After correction, repeat Tester validation, validation-adequacy Gate, and \`code-diff --source architect-debug\`.
 - **Docs Code-Diff Correction:** If the code-diff findings are only \`docs-only\` (or \`docs-only\` and \`test-only\`), or the Gate fails to start with \`Docs coverage check failed:\`, route the report or message to Architect to correct the docs, then rerun \`code-diff --source architect-debug\`.
 - **User-Approved Post-Validation Work:** After Tester returns \`pass\` and the validation-adequacy and code-diff Gates succeed, the user may explicitly approve additional Tester-owned work. Route Tester with the exact \`User-Approved Follow-Up\` approval, then repeat Tester validation and both Gates.

package/dist/backend/templates/harness/vcm-code-navigation-skill.js

@@ -6,19 +6,23 @@ Use this skill when Architect must establish symbol definitions, implementations
 ## Navigation Order
 
 1. Define the affected feature or module boundary and locate entry symbols with \`.ai/generated/module-index.json\` and \`.ai/generated/public-surface.json\` when available.
-2. Use LSP workspace or file symbols, definitions, implementations, references, and incoming or outgoing call hierarchy to resolve project-owned relationships. If a required language server is unavailable, stop the affected work and report its language, command, error, and installation hint through the current communication channel. Resume after the environment is fixed and Architect is restarted; do not substitute text search.
-3. Treat LSP results as symbol-specific. An accessor, backing field, trait declaration, implementation method, wrapper, and alias are separate symbols. Query every relevant symbol separately. When starting from an accessor or wrapper, read its implementation, resolve the backing field, delegate, or trait item with LSP, then query those symbols too. Never use one symbol's references as proof of a complete semantic class.
-4. If an initial workspace-symbol request is empty or reports indexing, wait and retry; startup or indexing time does not permit replacing a required semantic query with text matching. Retry the same bounded workspace query at most two more times. If it still cannot resolve, record the operation and result as unresolved.
-5. Read the complete project-owned callable unit at every resolved location.
+2. Locate each definition with an exact source-text search for its declaration form in the project language, such as \`fn name\`, \`struct Name\`, \`trait Name\`, \`impl Trait for\`, \`class Name\`, or \`def name\`. Read the complete declaration.
+3. Find references with exact searches over the whole project source tree, excluding only build output, dependency, and generated directories. Search every spelling that can reach the symbol: direct calls, method calls, path-qualified uses, imports and re-exports, renaming imports and aliases, macro invocations, and string or configuration names used for dispatch or registration.
+4. Treat each search as symbol-name evidence, not semantic evidence. An accessor, backing field, trait declaration, implementation method, wrapper, and alias are separate symbols; search each one. For a trait or interface item, search its implementations and every call through the trait, generic bound, or dynamic dispatch.
+5. Read the complete project-owned callable unit at every match and classify the match as a relationship, a same-name unrelated symbol, a comment, or a test. Common names such as \`new\`, \`get\`, or \`run\` need the enclosing type or module to classify each match.
 6. Expand one project-owned dependency hop at a time until the required behavior path has no unresolved symbol.
-7. If the correct LSP operation against the actual symbol is demonstrably partial for a relationship LSP does not model or expose, record the operation, result, and missing relationship. Then use an exact text search only within the already identified owning file or module to locate candidates. Read every candidate and verify its semantics against code and LSP. Text matches are candidate locations, not relationship evidence, and must not expand the search boundary or replace the initial LSP query.
-8. Use Glob, generated context, architecture documents, and runtime evidence to locate dynamic registrations, configuration or string edges, macros, documentation, and external boundaries that LSP does not model.
+7. Use Glob, generated context, architecture documents, and runtime evidence to locate dynamic registrations, configuration or string edges, macros, documentation, and external boundaries.
+
+## Completeness
+
+- A relationship set is complete only when every search that could reach it was run and every match was read and classified.
+- Search results cannot see identifiers produced by macros or code generation, code excluded by configuration such as disabled features or platform conditions, or calls through values whose concrete type is decided at runtime. When one of these can reach the symbol, read the generator, configuration, or dispatch site and record the limitation.
+- When a match cannot be classified from the code, record the relationship as unresolved instead of assuming either answer.
 
 ## Evidence
 
-- Record each resolved relationship and whether it came from LSP, runtime evidence, verified bounded source fallback, an external boundary, or a generated boundary.
-- When an empty LSP result contradicts a direct call in the code, another LSP result, or runtime evidence, treat the relationship as unresolved. Record the contradiction and use exact fallback evidence.
-- If LSP is unavailable or cannot resolve a required project-owned relationship, record that limitation and leave the relationship unresolved.
+- Record each relationship with its source: the exact search pattern and scope with every match dispositioned, runtime evidence, an external boundary, or a generated boundary.
+- If an expected relationship is missing from a search that should reach it, recheck the spellings and scope before concluding the relationship is absent.
 - Generated indexes and architecture docs locate likely code; reading current-worktree implementation establishes behavior.
 
 ## Context Boundary