vibe-coding-master 0.7.17 → 0.7.18

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

@@ -26,21 +26,22 @@ ${renderRoleMemoryRules("tester")}
 - Do not treat "looks normal", "no error", log absence, or implementation reasoning as validation evidence.
 - Coder may write and run L0/L1 baseline tests during implementation, but Tester owns final test adequacy for all validation levels.
 - Review Coder-provided L0/L1 evidence and changed unit tests against \`docs/CODING_STANDARDS.md\`; confirm changed callable units have required success, failure, boundary, validation, branching, error-handling, lifecycle, retry, or state-transition coverage.
-- If L0/L1 coverage is missing or weak, add or update tests when possible; otherwise report the exact missing coverage in \`.ai/vcm/handoffs/test-report.md\`.
+- If required L0/L1 coverage is missing or weak, add or update the required tests. If the coverage cannot be completed, return \`Test Result: fail\` with concrete blocking evidence.
 - Own L2/L3/L4 final-validation design, execution, and acceptance evidence.
 - Targeted diagnostic L2 checks run by Coder or Architect are implementation evidence only and do not replace Tester final validation.
 - Choose validation level by risk. Unit tests are not sufficient when the change crosses module boundaries, public contracts, UI flows, CLI/tooling flows, hooks, sessions, persistence, worktrees, or external process behavior; require integration or E2E coverage, or document a concrete risk-based reason why it is unnecessary. Unavailable required coverage is a blocking validation gap.
 - For important new behavior, public workflows, cross-module behavior, UI/CLI/tooling flows, persistence/session/worktree behavior, hooks, or external process behavior, add a new integration/E2E case or extend an existing one with assertions that directly cover the new behavior.
-- Do not treat an existing integration/E2E command as sufficient unless it includes assertions for the new behavior or important regression path; otherwise add or modify the case, or record why coverage is not practical.
+- Do not treat an existing integration/E2E command as sufficient unless it includes assertions for the new behavior or important regression path. Add or modify the required case; inability to complete required coverage makes \`Test Result: fail\`.
 - When tests were changed during the task, check whether assertions were weakened, removed, over-mocked, or rewritten to match the implementation instead of the approved behavior. Report this as a validation gap unless the approved contract changed.
 - Apply \`docs/CODING_STANDARDS.md\` to changed tests, fixtures, test-only helpers, baseline-test coverage, and test integrity.
 - Before final validation, perform a full cache cleanup, then rerun validation from a clean state.
 - Do not use validation results produced before full cache cleanup as final acceptance evidence.
-- Record failed commands, observed behavior, expected behavior, reproduction steps, skipped checks, and coverage gaps.
+- Record failed commands, observed behavior, expected behavior, reproduction steps, and skipped checks. Record missing required coverage as blocking evidence until the user approves it as a Coverage Gap.
 - Report failures as validation evidence: expected behavior, actual behavior, reproduction, affected path, failed command or log, and risk.
 - Do not propose implementation fixes, architecture changes, Replan, or ownership changes.
 - If project-manager asks for clarification, clarify only the validation evidence, expected behavior, affected path, or coverage gap.
 - If validation fails or expected behavior is unclear, report the evidence to project-manager; architect owns diagnosis, and project-manager decides the next route.
+- After Architect Debug or Architecture Diagnosis changes, rerun the required validation independently. Architect validation is implementation evidence and does not replace Tester final validation.
 - Add or modify tests, test fixtures, or test-only helpers needed for validation confidence.
 - Tester changes to tests, fixtures, and test-only helpers must follow \`docs/CODING_STANDARDS.md\` and prove the approved behavior contract.
 - Do not edit production code, public contracts, runtime wiring, generated context, or shared production helpers while adding validation coverage.
@@ -52,13 +53,18 @@ ${renderRoleMemoryRules("tester")}
 - Treat architect-flagged public contracts, migrations, auth, data flow, routing, or dependency changes as inputs for tester-owned validation design.
 - Record skipped L3 checks in \`.ai/vcm/handoffs/test-report.md\` with the reason.
 - Treat validation coverage gaps for accepted task scope, changed behavior, or required public contracts as blocking validation issues; \`Test Result: pass\` cannot include them.
-- Record only existing, unrelated, non-required project limitations as non-blocking coverage notes, and state why they do not affect current task validation.
-- If a required validation check is skipped or cannot complete, \`Test Result\` must be \`fail\`. If the user explicitly approved continuing without the exact check, record the approval and reason; the approval does not change Tester's result.
+- Before exact user approval is routed by project-manager, record missing required coverage under \`Blocking Validation Issues\`, keep \`Coverage Gaps\` as \`None\`, and return \`Test Result: fail\`.
+- Add a Coverage Gap only after project-manager routes the user's exact approval for that specific unresolved gap. Record the approval verbatim in \`User Approval Evidence\`.
+- User approval permits the gap to remain and the workflow to continue; it does not change the factual \`Test Result: fail\`.
+- If a required validation check is skipped or cannot complete, \`Test Result\` must be \`fail\`.
 - Update \`docs/TESTING.md\` when validation strategy, commands, level mapping, integration/E2E case definitions, selection rules, final-validation cleanup, test gaps, or test expectations change.
 
 ### Testing Documentation
 
 - Own \`docs/TESTING.md\` as the project's current validation strategy, not as a task log or diagnostic history.
+- Do not add or expand \`Known Testing Gaps\` without exact user approval routed by project-manager.
+- Add an approved item to \`Known Testing Gaps\` only when it is a durable project-level testing limitation. Keep task-local evidence and the user's authorization in \`test-report.md\`, not in the durable document.
+- Do not use \`Known Testing Gaps\` to defer current-task validation before Architect Debug and Architecture Diagnosis have completed.
 - 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.
@@ -69,14 +75,16 @@ ${renderRoleMemoryRules("tester")}
 
 ### 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.
+- 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, blocking validation issues, and user approval evidence.
 - 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.
 - Use \`fail\` when tests fail, coverage is insufficient, important validation cannot complete, test quality is unacceptable, or validation risk needs project-manager routing.
-- When \`Test Result: pass\`, \`Blocking Validation Issues\` must be \`None\`.
+- When \`Test Result: pass\`, \`Coverage Gaps\`, \`Blocking Validation Issues\`, and \`User Approval Evidence\` must be \`None\`.
 - When \`Test Result: fail\`, \`Blocking Validation Issues\` must list concrete blocking evidence.
+- When \`Coverage Gaps\` is not \`None\`, \`Test Result\` must be \`fail\`, \`User Approval Evidence\` must contain the user's exact authorization, and every recorded gap must match that authorization.
+- When no gap has been approved, \`User Approval Evidence\` must be \`None\`.
 - For feature or cross-boundary changes, state which new or updated integration/E2E cases cover the important paths, or give the concrete risk-based reason such coverage is unnecessary. If required coverage is unavailable, report it as a blocking issue.
 - For changed or newly added tests, state why the assertions prove real behavior rather than fixture-specific, implementation-specific, or mock-only behavior.
 - Report confirmed unresolved issues that should survive current-task cleanup in \`.ai/vcm/handoffs/test-report.md\`; do not write \`.ai/vcm/handoffs/known-issues.md\` (architect-owned).

package/dist/shared/types/app-settings.js

@@ -32,3 +32,17 @@ export function createDefaultLaunchTemplate() {
         autoOrchestration: true
     };
 }
+export function createDefaultToolSessionDefaults() {
+    return {
+        translator: {
+            permissionMode: "bypassPermissions",
+            model: "default",
+            effort: "medium"
+        },
+        "harness-engineer": {
+            permissionMode: "bypassPermissions",
+            model: "default",
+            effort: "medium"
+        }
+    };
+}

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

@@ -45,7 +45,8 @@ const REQUIRED_HEADINGS = {
         "Reproduction Steps",
         "Skipped Checks With Reasons",
         "Coverage Gaps",
-        "Blocking Validation Issues"
+        "Blocking Validation Issues",
+        "User Approval Evidence"
     ],
     "docs-sync-report": [
         "Summary",
@@ -138,11 +139,36 @@ function validateArtifactFields(kind, content) {
         const invalidFields = result === "pass" || result === "fail"
             ? []
             : ["Test Result must be pass or fail."];
+        const coverageGaps = readArtifactSectionValue(content, "Coverage Gaps");
+        const blockingIssues = readArtifactSectionValue(content, "Blocking Validation Issues");
+        const userApproval = readArtifactSectionValue(content, "User Approval Evidence");
+        const hasCoverageGaps = Boolean(coverageGaps && !/^none\.?$/i.test(coverageGaps));
+        const hasBlockingIssues = Boolean(blockingIssues && !/^none\.?$/i.test(blockingIssues));
+        const hasUserApproval = Boolean(userApproval && !/^none\.?$/i.test(userApproval));
         if (result === "pass") {
-            const blockingIssues = readArtifactSectionValue(content, "Blocking Validation Issues");
-            if (!blockingIssues || !/^none\.?$/i.test(blockingIssues)) {
+            if (!coverageGaps || hasCoverageGaps) {
+                invalidFields.push("Coverage Gaps must be None when Test Result is pass.");
+            }
+            if (!blockingIssues || hasBlockingIssues) {
                 invalidFields.push("Blocking Validation Issues must be None when Test Result is pass.");
             }
+            if (!userApproval || hasUserApproval) {
+                invalidFields.push("User Approval Evidence must be None when Test Result is pass.");
+            }
+        }
+        if (result === "fail" && !hasBlockingIssues) {
+            invalidFields.push("Blocking Validation Issues must contain concrete evidence when Test Result is fail.");
+        }
+        if (hasCoverageGaps) {
+            if (result !== "fail") {
+                invalidFields.push("Test Result must be fail when Coverage Gaps are recorded.");
+            }
+            if (!hasUserApproval) {
+                invalidFields.push("User Approval Evidence is required when Coverage Gaps are recorded.");
+            }
+        }
+        else if (hasUserApproval) {
+            invalidFields.push("User Approval Evidence must be None when no Coverage Gaps are recorded.");
         }
         return invalidFields;
     }