vibe-coding-master 0.7.5 → 0.7.6

package/dist/backend/templates/harness/role-memory.js

@@ -1,19 +1,16 @@
 export function renderRoleMemoryRules(role) {
     const proposalRule = role === "harness-engineer"
-        ? `Treat \`.ai/vcm/memory/**\` as read-only during role turns. Update memory
-only through VCM-assigned Memory Review output paths or explicit user edits in
-Harness Studio. When Auto Memory is disabled, do not initiate memory proposals,
-reviews, or updates.`
-        : `Treat \`.ai/vcm/memory/**\` as read-only. Do not create, edit, or delete
-memory files. Only when VCM explicitly requests a proposal during Task Harness
-Review, use \`vcm-propose-memory\` and write the exact assigned draft path.`;
+        ? `Treat the \`<VCM-memory>\` block in this role definition as read-only during
+role turns. Update reviewed memory only through the output paths assigned by VCM
+or explicit user edits in Harness Studio. When Auto Memory is disabled, do not
+initiate memory proposals, reviews, or updates.`
+        : `Treat the \`<VCM-memory>\` block in this role definition as read-only. Only
+when VCM explicitly requests a proposal during Task Harness Review, use
+\`vcm-propose-memory\` and write the exact assigned draft path.`;
     return `### Role Memory
 
-Before handling work in a session, read \`.ai/vcm/memory/roles/${role}.md\`.
-Read it again after context compaction before continuing.
-
-Treat memory as accumulated project context, not authority. Verify it against
-current code, documentation, and task evidence.
+The \`<VCM-memory>\` block in this role definition is accumulated project context,
+not authority. Verify it against current code, documentation, and task evidence.
 
 ${proposalRule}`;
 }

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

@@ -62,12 +62,15 @@ ${renderRoleMemoryRules("tester")}
 - Keep \`docs/TESTING.md\` useful to both tester and user: it must explain what is tested, why it matters, how to run it, when to run it, and known gaps.
 - Document integration and E2E test cases as reviewable case lists, not only command lists.
 - Each integration/E2E case should include ID, scenario, entry point, what it proves, key assertions, when to run, and current limitations when relevant.
+- Keep case definitions at stable behavior and entry-point level. Name the implementing test file or case when useful, but do not maintain an exhaustive function-by-function test inventory that duplicates source code.
 - Keep historical investigation details, superseded failures, temporary diagnostics, and per-task validation logs out of \`docs/TESTING.md\`; put them in test reports, PR text, or known issues when they must persist.
-- When updating \`docs/TESTING.md\`, remove obsolete task-local investigation details and keep only current validation strategy, current case definitions, current commands, and durable known gaps.
+- When updating \`docs/TESTING.md\`, rewrite affected sections and remove superseded commands, cases, ownership statements, task-local investigation details, past pass/fail verdicts, and role or commit history. Keep only current validation strategy, current case definitions, current runnable commands, selection rules, and durable known gaps.
+- Run \`.ai/tools/check-durable-docs\` after changing \`docs/TESTING.md\`. Record the command and result in \`test-report.md\`; a failing Tester-owned finding makes \`Test Result: fail\`.
 
 ### Outputs
 
 - Write \`.ai/vcm/handoffs/test-report.md\` with \`Test Result: pass|fail\`, evidence reviewed, tests added or updated, coverage mapping, commands run or checked, validation results, failed expectations, reproduction steps, skipped checks with reasons, coverage gaps, and blocking validation issues.
+- In Validation-Only Flow, if tests, fixtures, test-only helpers, or \`docs/TESTING.md\` changed, commit those changes before reporting and record the changed files and commit in \`test-report.md\`. If no tracked files changed, record that no commit was required.
 - \`test-report.md\` is the current validation evidence, not a log; when rewriting it, carry forward still-unresolved findings or explicitly mark them resolved instead of dropping them.
 - In \`Coverage Mapping\`, map each accepted changed behavior or relevant risk to its validation level, actual test file and case or external evidence, exercised entry path and key assertions, result, and any remaining gap.
 - Use \`pass\` only when required validation completed and no blocking test failure, missing required coverage, unacceptable test weakness, or unresolved validation risk remains.

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

@@ -0,0 +1,82 @@
+export function renderVcmArchitectureInterviewSkillRules() {
+    return `## Purpose
+
+Use this skill only when project-manager routes the Architect Interview step of Code-Change Flow. Establish confirmed user-owned behavior before architecture planning begins.
+
+During an active Architect Interview, handle the user's answers and final confirmation only as defined by this skill.
+
+## Boundaries
+
+- Do not write or revise \`.ai/vcm/handoffs/architecture-plan.md\`.
+- Do not create code scaffold, \`VCM:CODE\` markers, production code, tests, or implementation commits.
+- Do not ask the user to choose technical implementation, modules, files, dependencies, callable surfaces, task splitting, workload, validation commands, or test strategy.
+- Do not create \`CONTEXT.md\`, ADRs, or durable documentation during the interview.
+
+## Evidence First
+
+- Read the PM route, task request, relevant durable docs, generated context, and enough current-worktree source to distinguish project facts from unresolved user decisions.
+- 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.
+
+## 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.
+
+## Interview Protocol
+
+- Ask one question per turn and wait for the user's answer.
+- Explain why the decision affects the task and give the Architect's recommended answer with a concise rationale.
+- Offer alternatives only when they represent a real user-owned trade-off.
+- Treat exploratory, tentative, or hypothetical answers as discussion, not confirmation.
+- After each resolved answer, update \`.ai/vcm/handoffs/architecture-brief.md\` immediately. Replace superseded content; do not append a transcript or decision history.
+- During this formal interview, continue directly with the user across turns. Do not report each answer to project-manager.
+- On every resumed interview turn, read the current brief before asking the next question.
+- If planning returns to this interview with a newly discovered user-owned decision, set the brief status to \`interviewing\` and record that decision under Unresolved User Decisions before asking it.
+
+## Artifact
+
+Maintain exactly this structure:
+
+\`\`\`md
+# Architecture Brief: <task>
+
+Architecture Brief Status: interviewing|confirmed
+
+## Accepted Outcome
+
+...
+
+## Confirmed User Decisions
+
+...
+
+## Existing Constraints
+
+...
+
+## Unresolved User Decisions
+
+...
+
+## User Confirmation
+
+...
+\`\`\`
+
+Record concise confirmed requirements and constraints, not implementation design. Use \`None\` under Unresolved User Decisions only when no user-owned decision remains.
+
+## Completion
+
+When no unresolved user decision remains, present the complete brief to the user and ask for explicit confirmation. If the user corrects it, update the brief and continue the interview.
+
+Only after explicit confirmation:
+
+1. Set \`Architecture Brief Status: confirmed\`.
+2. Record the confirmation under User Confirmation.
+3. Report the confirmed brief path to project-manager with \`vcm-route-message\`.
+4. End the turn immediately.
+
+Do not continue into architecture planning. Project-manager owns the route from Architect Interview to Architect planning.`;
+}

package/dist/backend/templates/harness/vcm-final-acceptance-skill.js

@@ -1,9 +1,9 @@
 export function renderVcmFinalAcceptanceSkillRules() {
     return `## Purpose
 
-Use this skill only when project-manager is ready to close a complete VCM code-delivery flow, including a primary Debug or Architecture Diagnosis flow that produced code changes.
+Use this skill only when project-manager is ready to close a complete VCM code-delivery flow, including Architect Debug Flow or an Architecture Diagnosis Flow that produced code changes.
 
-Do not use it for docs-only, validation-only, Communication-only, PR-prep, analysis-only Diagnosis, or any Debug/Diagnosis branch inside another flow.
+Do not use it for Docs-Only Flow, Validation-Only Flow, Communication-Only Flow, PR-Preparation Flow, analysis-only Diagnosis, Architect Debug Branch, or Architecture Diagnosis Branch.
 
 This skill is a final evidence audit. It does not replace architect docs sync, tester validation acceptance, coder implementation responsibility, or user approval for high-risk decisions.
 
@@ -62,6 +62,7 @@ Check:
 - required Gate Reviews are approved, or skipped/overridden through a VCM-recorded user action
 - Gate Review enable state is confirmed authoritatively: do not infer that no Gate Reviews were required from an absent or empty \`.ai/vcm/gate-reviews/index.json\`. When Gate Review is enabled, a missing index or a required gate without a recorded decision means the gate was skipped — run the matching command from the \`vcm-gate-review\` skill, including the code source for \`code-diff\`, and do not accept until each required gate returns \`approve\`/\`already_approved\`, \`disabled\`/\`not_required\`, or a VCM-recorded user skip/override
 - docs-sync report records docs updated, docs intentionally left unchanged, or required follow-up when docs sync was required
+- when durable docs changed, docs-sync or tester evidence records a passing \`.ai/tools/check-durable-docs\` result and any cross-document inconsistency was resolved by the owning role
 - known issues are either resolved, promoted to durable docs by architect, or explicitly accepted by the user
 - temporary task state is ready to clean after durable facts are promoted
 
@@ -76,7 +77,7 @@ Choose exactly one:
 - needs-docs-sync
 - blocked-by-user-decision
 
-Do not accept when required role evidence is missing, required Gate Review evidence is missing, tester findings are unresolved, docs sync is missing for durable changes, known-issues disposition is missing, or unexplained high-risk files remain.
+Do not accept when required role evidence is missing, required Gate Review evidence is missing, tester findings are unresolved, docs sync is missing for durable changes, the durable-doc audit failed or is missing after durable-doc changes, known-issues disposition is missing, or unexplained high-risk files remain.
 
 ## Output
 

package/dist/backend/templates/harness/vcm-harness-bootstrap-skill.js

@@ -20,9 +20,10 @@ This skill is an operating procedure. It does not replace the deterministic VCM
 3. Fill project context: add or update non-managed project facts in \`CLAUDE.md\` above the VCM managed block.
 4. Fill durable docs: update \`docs/GLOSSARY.md\`, \`docs/CODING_STANDARDS.md\`, \`docs/ARCHITECTURE.md\`, module-level \`ARCHITECTURE.md\` files for clear non-root module boundaries, and \`docs/TESTING.md\` with detailed project-specific content.
 5. Preserve user-authored content and VCM managed blocks.
-6. Review \`git status\` and \`git diff\`.
-7. Stage only allowed bootstrap harness changes and create a commit in the active task worktree.
-8. Report evidence, commit hash, final git status, unknowns, confirmation-needed areas, generation failures, and recommended deterministic VCM actions.
+6. Run \`.ai/tools/check-durable-docs\` and correct every bootstrap-owned finding.
+7. Review \`git status\` and \`git diff\`.
+8. Stage only allowed bootstrap harness changes and create a commit in the active task worktree.
+9. Report evidence, durable-doc audit result, commit hash, final git status, unknowns, confirmation-needed areas, generation failures, and recommended deterministic VCM actions.
 
 ## Typical Outputs
 
@@ -49,6 +50,7 @@ This skill is an operating procedure. It does not replace the deterministic VCM
 - Run \`.ai/tools/generate-module-index\` when the generator exists and the project is supported.
 - Run \`.ai/tools/generate-public-surface\` only after \`.ai/generated/module-index.json\` exists.
 - If generation fails or the project is unsupported, report the reason. Do not invent generated artifacts.
+- Treat generated context as the source of truth for module inventories, manifests, dependencies, source/test file inventories, and complete public-surface listings. Durable prose may explain those facts but must not maintain separate counts or exhaustive lists that can drift.
 
 ### \`docs/GLOSSARY.md\`
 
@@ -69,6 +71,7 @@ This skill is an operating procedure. It does not replace the deterministic VCM
 - Document the project-level module overview, module responsibilities, module relationships, dependency direction, and project-wide constraints.
 - Link to module-level \`ARCHITECTURE.md\` files when present.
 - Explain generated-context ownership, especially that \`.ai/generated/public-surface.json\` is the machine index for public APIs, routes, and externally consumed surfaces.
+- Describe current architecture only. Do not import task history, implementation chronology, validation results, commit history, or completed-work reports from existing project material.
 
 ### Module-Level \`ARCHITECTURE.md\`
 
@@ -76,14 +79,22 @@ This skill is an operating procedure. It does not replace the deterministic VCM
 - Do not create a root-level \`ARCHITECTURE.md\` only because the root package exists.
 - Document module boundaries, responsibilities, allowed dependencies, important behavior, important public surface explanations, risks, and update triggers.
 - Keep complete public API listings in \`.ai/generated/public-surface.json\`; module docs should explain meaning and design intent, not duplicate the full generated index.
+- Keep source-file inventories, exhaustive callables, and implementation walkthroughs out of module architecture docs.
 
 ### \`docs/TESTING.md\`
 
 - Document validation levels, project-native validation commands, validation selection rules, final-validation cleanup, unit/integration test placement, generated-context freshness checks, and known testing gaps.
 - Document integration and E2E test cases as reviewable case lists. Each case should include ID, scenario, entry point, what it proves, key assertions, when to run, and current limitations when relevant.
 - Keep historical investigation details, superseded failures, temporary diagnostics, and per-task validation logs out of \`docs/TESTING.md\`.
+- Keep current strategy, runnable commands, behavior-level integration/E2E cases, selection rules, cleanup requirements, and current gaps; do not create an exhaustive test-function inventory.
 - Keep tester ownership of validation strategy and testing documentation clear.
 
+### Active Plans And Known Issues
+
+- Keep \`docs/plans/**\` limited to active or planned work. Remove completed or superseded plans from that collection; Git and PR history preserve them.
+- Keep \`docs/known-issues.md\` limited to current unresolved durable issues and accepted limitations. Remove resolved entries and rewrite partially resolved entries around the remaining current gap.
+- Do not preserve task chronology, role verdicts, validation history, or commit history in either collection.
+
 ### Commit
 
 - Create the bootstrap commit yourself after the allowed files are updated.

package/dist/backend/templates/harness/vcm-propose-memory-skill.js

@@ -4,8 +4,8 @@ Harness Review and provides an exact draft path.
 
 ## Rules
 
-- Treat \`.ai/vcm/memory/**\` as read-only. This skill creates a proposal; it
-  never edits active memory.
+- Treat every \`<VCM-memory>\` block as read-only. This skill creates a proposal;
+  it never edits active memory.
 - Write only to the exact draft path assigned by VCM. The path must be under
   \`.ai/vcm/memory-review/runs/<run-id>/drafts/\` in the active task worktree.
 - If VCM did not provide a draft path, do not create a proposal.

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

@@ -53,6 +53,9 @@ For PM dispatch, use:
 \`\`\`md
 ---
 type: task
+workflow_flow: code-change
+workflow_step: coder-implementation
+workflow_status: active
 artifact_refs:
   - .ai/vcm/handoffs/architecture-plan.md
   - docs/plans/example.md
@@ -74,6 +77,8 @@ Stop conditions:
 ...
 \`\`\`
 
+PM route files should declare the workflow checkpoint fields defined by the \`vcm-task-state\` skill. Non-PM reports must not declare workflow state.
+
 For non-PM reports, use:
 
 \`\`\`md

package/dist/backend/templates/harness/vcm-task-state-skill.js

@@ -0,0 +1,110 @@
+export function renderVcmTaskStateSkillRules() {
+    return `## Purpose
+
+Use this skill only as project-manager to declare the current task workflow checkpoint to VCM.
+
+The declaration is recoverable context, not a workflow controller. It does not authorize a transition, replace handoff artifacts, or decide the next role.
+
+## Declaration
+
+For a PM role dispatch, put the current declaration in the route-file frontmatter:
+
+\`\`\`yaml
+workflow_flow: code-change
+workflow_step: coder-implementation
+workflow_branch: none
+workflow_resume_point: none
+workflow_status: active
+workflow_evidence_refs: .ai/vcm/handoffs/architecture-plan.md
+\`\`\`
+
+For a checkpoint without a role route, run:
+
+\`\`\`bash
+.ai/tools/update-task-state --flow code-change --step awaiting-user --status awaiting-user
+\`\`\`
+
+Supply only fields that changed. Use \`none\` to clear branch or resume point. Repeat \`--evidence\` for evidence paths.
+
+Declare the selected flow before its first dispatch, update the step on later PM dispatches, and update no-route checkpoints such as waiting for the user, waiting for Gate Review, or completion.
+
+If declaration fails, report the warning when relevant and continue the existing workflow. Never delay routing, Gate Review, final acceptance, or task close because task state is unavailable.
+`;
+}
+export function renderUpdateTaskStateTool() {
+    return `#!/usr/bin/env python3
+import argparse
+import json
+import os
+import sys
+import urllib.error
+import urllib.parse
+import urllib.request
+
+
+def emit(status, message=None, state=None):
+    payload = {"status": status}
+    if message:
+        payload["message"] = message
+    if state is not None:
+        payload["state"] = state
+    print(json.dumps(payload, ensure_ascii=False))
+
+
+def main():
+    parser = argparse.ArgumentParser(description="Declare advisory VCM task workflow state.")
+    parser.add_argument("--flow")
+    parser.add_argument("--step")
+    parser.add_argument("--branch")
+    parser.add_argument("--resume-point")
+    parser.add_argument("--status")
+    parser.add_argument("--evidence", action="append", default=[])
+    args = parser.parse_args()
+
+    if os.environ.get("VCM_ROLE") != "project-manager":
+        emit("warning", "Only project-manager may declare VCM task workflow state.")
+        return 0
+
+    api_url = os.environ.get("VCM_API_URL", "").rstrip("/")
+    task_slug = os.environ.get("VCM_TASK_SLUG", "").strip()
+    if not api_url or not task_slug:
+        emit("warning", "VCM_API_URL or VCM_TASK_SLUG is unavailable; task state was not updated.")
+        return 0
+
+    payload = {}
+    for key, value in (
+        ("flow", args.flow),
+        ("step", args.step),
+        ("branch", args.branch),
+        ("resumePoint", args.resume_point),
+        ("status", args.status),
+    ):
+        if value is not None:
+            payload[key] = value
+    if args.evidence:
+        payload["evidenceRefs"] = args.evidence
+
+    if not payload:
+        emit("warning", "No task workflow fields were supplied.")
+        return 0
+
+    url = f"{api_url}/api/tasks/{urllib.parse.quote(task_slug, safe='')}/workflow-state"
+    request = urllib.request.Request(
+        url,
+        data=json.dumps(payload).encode("utf-8"),
+        headers={"content-type": "application/json"},
+        method="POST",
+    )
+    try:
+        with urllib.request.urlopen(request, timeout=3) as response:
+            state = json.loads(response.read().decode("utf-8"))
+        emit("updated", state=state)
+    except (OSError, ValueError, urllib.error.URLError, urllib.error.HTTPError) as error:
+        emit("warning", f"Task state was not updated: {error}")
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())
+`;
+}

package/dist/backend/templates/message-envelope.js

@@ -27,5 +27,5 @@ Instructions:
 }
 export function renderManualStagePrompt(message) {
     const target = message.bodyPath ?? `VCM message ${message.id}`;
-    return `Read and handle VCM message ${message.id} at ${target}`;
+    return `[VCM MESSAGE]\nid: ${message.id}\nRead and handle the VCM message at ${target}.\n[/VCM MESSAGE]`;
 }

package/dist/shared/constants.js

@@ -84,16 +84,6 @@ export function isHarnessEngineerToolRoleName(value) {
 export function isDispatchableRole(value) {
     return DISPATCHABLE_ROLES.includes(value);
 }
-/**
- * Roles that address the human operator. When a role in this set ends its turn
- * with no onward route message, the flow is treated as awaiting a user decision
- * (see the `awaiting-user` flow-pause reason). Single source of truth for that
- * predicate.
- */
-export const USER_FACING_ROLES = ["project-manager"];
-export function isUserFacingRole(value) {
-    return USER_FACING_ROLES.includes(value);
-}
 export function getRoleDefinition(role) {
     const definition = ROLE_DEFINITIONS.find((candidate) => candidate.name === role);
     if (!definition) {

package/dist/shared/types/workflow.js

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

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

@@ -1,4 +1,11 @@
 const REQUIRED_HEADINGS = {
+    "architecture-brief": [
+        "Accepted Outcome",
+        "Confirmed User Decisions",
+        "Existing Constraints",
+        "Unresolved User Decisions",
+        "User Confirmation"
+    ],
     "architecture-plan": [
         "Accepted Scope",
         "Current Code Reality",
@@ -103,6 +110,19 @@ export function checkMarkdownArtifact(kind, artifactPath, content) {
     };
 }
 function validateArtifactFields(kind, content) {
+    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"
+            ? []
+            : ["Architecture Brief Status must be interviewing or confirmed."];
+        if (status === "confirmed") {
+            const unresolved = readArtifactSectionValue(content, "Unresolved User Decisions");
+            if (!unresolved || !/^none\.?$/i.test(unresolved)) {
+                invalidFields.push("Unresolved User Decisions must be None when Architecture Brief Status is confirmed.");
+            }
+        }
+        return invalidFields;
+    }
     if (kind === "test-report") {
         const result = /^\s*Test Result\s*:\s*(\S+)\s*$/im.exec(content)?.[1]?.toLowerCase();
         const invalidFields = result === "pass" || result === "fail"