ralph-lisa-loop 0.3.10 → 0.3.12

package/dist/policy.d.ts

@@ -21,6 +21,7 @@ export declare function checkRalph(tag: string, content: string): PolicyViolatio
  * Check Lisa's submission for policy violations.
  */
 export declare function checkLisa(tag: string, content: string): PolicyViolation[];
+export declare function checkNeedsWorkResponse(ralphTag: string, lastLisaTag: string): PolicyViolation[];
 /**
  * Run policy checks based on mode.
  * Returns { proceed, violations } so callers can format output clearly (IMP-4).

package/dist/policy.js

@@ -12,6 +12,7 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.getPolicyMode = getPolicyMode;
 exports.checkRalph = checkRalph;
 exports.checkLisa = checkLisa;
+exports.checkNeedsWorkResponse = checkNeedsWorkResponse;
 exports.runPolicyCheck = runPolicyCheck;
 function getPolicyMode() {
     const mode = process.env.RL_POLICY_MODE || "warn";
@@ -24,6 +25,15 @@ function getPolicyMode() {
  */
 function checkRalph(tag, content) {
     const violations = [];
+    // [PLAN] must include test plan (step42: mandatory test execution)
+    if (tag === "PLAN") {
+        if (!content.match(/测试计划|[Tt]est [Pp]lan|测试命令|[Tt]est [Cc]ommand/)) {
+            violations.push({
+                rule: "plan-test-plan",
+                message: `[PLAN] submission missing test plan (test command + coverage scope).`,
+            });
+        }
+    }
     // [CODE] or [FIX] must include Test Results and file:line references
     if (tag === "CODE" || tag === "FIX") {
         if (!content.includes("Test Results") &&
@@ -34,12 +44,42 @@ function checkRalph(tag, content) {
                 message: `[${tag}] submission missing "Test Results" section.`,
             });
         }
+        // step42: Test Results must include concrete execution evidence (exit code or pass/fail count)
+        // Exception: explicit "Skipped:" line inside the Test Results section only
+        // Section is bounded: from "Test Results" heading to next heading (## or blank-line-then-heading) or EOF
+        const testResultsMatch = content.match(/[Tt]est [Rr]esults[^\n]*\n([\s\S]*?)(?=\n##\s|\n\n[A-Z]|\n\n\*\*[A-Z]|$)/);
+        if (testResultsMatch) {
+            const testResultsBody = testResultsMatch[1];
+            const hasSkipLine = /^[\s\-*]*[Ss]kip(ped)?\s*:.*\S/m.test(testResultsBody);
+            const hasExecutionEvidence = /[Ee]xit code|退出码|\d+\/\d+\s*(pass|通过|passed)|(\d+)\s*tests?\s*pass/i.test(testResultsBody);
+            if (!hasSkipLine && !hasExecutionEvidence) {
+                violations.push({
+                    rule: "test-results-detail",
+                    message: `[${tag}] Test Results must include exit code or pass/fail count (e.g., "Exit code: 0" or "42/42 passed"), or explicit "Skipped:" with justification.`,
+                });
+            }
+        }
         if (!/\w+\.\w+:\d+/.test(content)) {
             violations.push({
                 rule: "file-line-ref",
                 message: `[${tag}] submission must include at least one file:line reference (e.g., commands.ts:42).`,
             });
         }
+        // New tests count check (Proposal §3.6)
+        // Warn if "New tests: 0" without valid justification
+        const lc = content.toLowerCase();
+        const hasNewTests = /new tests?:\s*[1-9]/i.test(content);
+        const hasZeroTests = /new tests?:\s*0/i.test(content);
+        if (hasZeroTests && !hasNewTests) {
+            // Check for valid justification keywords
+            const hasJustification = /\b(ui.only|layout.only|config.only|no.testable.logic|template.only|documentation)\b/i.test(content);
+            if (!hasJustification) {
+                violations.push({
+                    rule: "new-tests-required",
+                    message: `[${tag}] reports 0 new tests without valid justification. Add unit tests or explain why (e.g., "config-only change").`,
+                });
+            }
+        }
     }
     // [RESEARCH] must have substance
     if (tag === "RESEARCH") {
@@ -58,6 +98,17 @@ function checkRalph(tag, content) {
                 message: "[RESEARCH] submission needs at least 2 fields (reference/key types/data structure/verification) or equivalent summary with evidence.",
             });
         }
+        // RESEARCH verification markers (Proposal §3.9)
+        // Checks for at least one global Verified:/Evidence: marker per submission.
+        // Per-claim enforcement is not mechanically feasible — Lisa reviews claim-level rigor.
+        const hasVerifiedMarker = /\bverified\s*:/i.test(content);
+        const hasEvidenceMarker = /\bevidence\s*:/i.test(content);
+        if (!hasVerifiedMarker && !hasEvidenceMarker) {
+            violations.push({
+                rule: "research-verification",
+                message: '[RESEARCH] submission should include at least one "Verified:" or "Evidence:" marker to support factual claims.',
+            });
+        }
     }
     return violations;
 }
@@ -86,6 +137,26 @@ function checkLisa(tag, content) {
     }
     return violations;
 }
+/**
+ * NEEDS_WORK response enforcement (Proposal §3.2).
+ * When Lisa's last review was [NEEDS_WORK], Ralph must respond with
+ * [FIX], [CHALLENGE], [DISCUSS], or [QUESTION] — not unrelated [CODE]/[RESEARCH]/[PLAN].
+ */
+const NEEDS_WORK_ALLOWED_TAGS = new Set(["FIX", "CHALLENGE", "DISCUSS", "QUESTION"]);
+const NEEDS_WORK_BLOCKED_TAGS = new Set(["CODE", "RESEARCH", "PLAN", "CONSENSUS"]);
+function checkNeedsWorkResponse(ralphTag, lastLisaTag) {
+    if (lastLisaTag !== "NEEDS_WORK")
+        return [];
+    if (NEEDS_WORK_ALLOWED_TAGS.has(ralphTag))
+        return [];
+    if (NEEDS_WORK_BLOCKED_TAGS.has(ralphTag)) {
+        return [{
+                rule: "needs-work-response",
+                message: `[${ralphTag}] submitted after Lisa's [NEEDS_WORK]. You must respond with [FIX], [CHALLENGE], [DISCUSS], or [QUESTION] first. If the task scope changed, run: ralph-lisa scope-update "new scope"`,
+            }];
+    }
+    return [];
+}
 /**
  * Run policy checks based on mode.
  * Returns { proceed, violations } so callers can format output clearly (IMP-4).

package/dist/state.d.ts

@@ -10,10 +10,28 @@ export declare function findProjectRoot(startDir?: string): string | null;
  * Reset the cached project root. Used in tests.
  */
 export declare function resetProjectRootCache(): void;
+export declare function _setTmuxStateDirOverride(value: string | null | undefined): void;
+/**
+ * Try to read RL_STATE_DIR from tmux session environment.
+ * Returns null if not in tmux or env var not set.
+ */
+export declare function getTmuxStateDir(): string | null;
+/**
+ * Resolve state directory with priority (Proposal §3.10):
+ *   1. tmux show-environment RL_STATE_DIR  (authoritative in auto mode)
+ *   2. $RL_STATE_DIR environment variable  (manual mode / override)
+ *   3. findProjectRoot() upward search     (fallback)
+ *
+ * Returns { dir, source } for diagnostics.
+ */
+export declare function resolveStateDir(): {
+    dir: string;
+    source: "tmux" | "env" | "auto-detect";
+};
 /**
  * Get the .dual-agent/ state directory path.
  * When projectDir is explicitly given, uses that path directly.
- * When omitted, searches upward from CWD to find .dual-agent/ (like git).
+ * When omitted, uses priority resolution: tmux env → shell env → upward search.
  */
 export declare function stateDir(projectDir?: string): string;
 /**

package/dist/state.js

@@ -40,6 +40,9 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.VALID_TAGS = exports.ARCHIVE_DIR = exports.STATE_DIR = void 0;
 exports.findProjectRoot = findProjectRoot;
 exports.resetProjectRootCache = resetProjectRootCache;
+exports._setTmuxStateDirOverride = _setTmuxStateDirOverride;
+exports.getTmuxStateDir = getTmuxStateDir;
+exports.resolveStateDir = resolveStateDir;
 exports.stateDir = stateDir;
 exports.checkSession = checkSession;
 exports.readFile = readFile;
@@ -59,6 +62,7 @@ exports.appendHistory = appendHistory;
 exports.updateLastAction = updateLastAction;
 const fs = __importStar(require("node:fs"));
 const path = __importStar(require("node:path"));
+const node_child_process_1 = require("node:child_process");
 exports.STATE_DIR = ".dual-agent";
 exports.ARCHIVE_DIR = ".dual-agent-archive";
 exports.VALID_TAGS = "PLAN|RESEARCH|CODE|FIX|PASS|NEEDS_WORK|CHALLENGE|DISCUSS|QUESTION|CONSENSUS";
@@ -111,17 +115,72 @@ function resetProjectRootCache() {
     _cachedStartDir = undefined;
     _cachedProjectRoot = undefined;
 }
+/**
+ * Test-only override for getTmuxStateDir(). When set to a string, that value
+ * is returned instead of querying tmux. Set to undefined to restore real behavior.
+ */
+let _tmuxStateDirOverride;
+function _setTmuxStateDirOverride(value) {
+    _tmuxStateDirOverride = value;
+}
+/**
+ * Try to read RL_STATE_DIR from tmux session environment.
+ * Returns null if not in tmux or env var not set.
+ */
+function getTmuxStateDir() {
+    // Test override takes precedence
+    if (_tmuxStateDirOverride !== undefined)
+        return _tmuxStateDirOverride;
+    try {
+        const tmuxEnv = process.env.TMUX;
+        if (!tmuxEnv)
+            return null;
+        const result = (0, node_child_process_1.execSync)("tmux show-environment RL_STATE_DIR 2>/dev/null", {
+            encoding: "utf-8",
+            stdio: ["pipe", "pipe", "pipe"],
+            timeout: 3000,
+        }).trim();
+        // Format: "RL_STATE_DIR=/path" or "-RL_STATE_DIR" (unset)
+        if (result.startsWith("RL_STATE_DIR=")) {
+            return result.slice("RL_STATE_DIR=".length);
+        }
+        return null;
+    }
+    catch {
+        return null;
+    }
+}
+/**
+ * Resolve state directory with priority (Proposal §3.10):
+ *   1. tmux show-environment RL_STATE_DIR  (authoritative in auto mode)
+ *   2. $RL_STATE_DIR environment variable  (manual mode / override)
+ *   3. findProjectRoot() upward search     (fallback)
+ *
+ * Returns { dir, source } for diagnostics.
+ */
+function resolveStateDir() {
+    // 1. tmux env (authoritative in auto mode)
+    const tmuxDir = getTmuxStateDir();
+    if (tmuxDir)
+        return { dir: tmuxDir, source: "tmux" };
+    // 2. Shell env var
+    const envDir = process.env.RL_STATE_DIR;
+    if (envDir)
+        return { dir: envDir, source: "env" };
+    // 3. Fallback: upward search
+    const root = findProjectRoot();
+    return { dir: path.join(root || process.cwd(), exports.STATE_DIR), source: "auto-detect" };
+}
 /**
  * Get the .dual-agent/ state directory path.
  * When projectDir is explicitly given, uses that path directly.
- * When omitted, searches upward from CWD to find .dual-agent/ (like git).
+ * When omitted, uses priority resolution: tmux env → shell env → upward search.
  */
 function stateDir(projectDir) {
     if (projectDir !== undefined) {
         return path.join(projectDir, exports.STATE_DIR);
     }
-    const root = findProjectRoot();
-    return path.join(root || process.cwd(), exports.STATE_DIR);
+    return resolveStateDir().dir;
 }
 /**
  * Check that a session exists. Searches upward from CWD when no explicit dir given.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ralph-lisa-loop",
-  "version": "0.3.10",
+  "version": "0.3.12",
   "description": "Turn-based dual-agent collaboration: Ralph codes, Lisa reviews, consensus required.",
   "bin": {
     "ralph-lisa": "dist/cli.js"

package/templates/claude-commands/check-turn.md

@@ -13,6 +13,6 @@ ralph-lisa whose-turn
 ## Rules
 
 - If output is `ralph`: You can proceed with your work
-- If output is `lisa`: STOP immediately and wait for Lisa's response
+- If output is `lisa`: Wait for Lisa's feedback — do not take further action until your turn
 
 **NEVER skip this check before working.**

package/templates/claude-commands/submit-work.md

@@ -36,4 +36,4 @@ Detailed content here...
 
 ## After Submission
 
-The turn automatically passes to Lisa. You must STOP and wait.
+The turn automatically passes to Lisa. Wait for her feedback — do not take further action until it is your turn again.

package/templates/codex-skills/check-turn.md

@@ -11,6 +11,6 @@ Check whose turn it is before taking any action.
 ## Rules
 
 - If output is `lisa`: You can proceed with your review
-- If output is `ralph`: STOP immediately and wait for Ralph's submission
+- If output is `ralph`: Wait for Ralph's feedback — do not take further action until your turn
 
-**NEVER skip this check before working.**
+**NEVER skip this check. When it's not your turn, do not submit work. You may use subagents for preparatory tasks (research, environment checks). If triggered by the user but it's not your turn, suggest checking watcher status: `cat .dual-agent/.watcher_heartbeat` and `ralph-lisa status`.**

package/templates/roles/lisa.md

@@ -16,16 +16,16 @@ Then based on result:
   ```bash
   ralph-lisa read work.md
   ```
-- `ralph` → Say "Waiting for Ralph" and STOP
+- `ralph` → Say "Waiting for Ralph's feedback" and wait — do not take further action until your turn
 
 **Do NOT wait for user to tell you to check. Check automatically.**
 
 ## CRITICAL: Turn-Based Rules
 
-- Output `lisa` → You can review
-- Output `ralph` → STOP immediately, tell user "Waiting for Ralph"
+- Output `lisa` → You can review. If it's your turn but you cannot complete work (missing input, environment error, etc.), tell the user the specific reason and wait — do not retry repeatedly.
+- Output `ralph` → Tell user it's not your turn. You may use subagents for preparatory work, but do not submit until it is your turn.
 
-**NEVER skip this check. NEVER work when it's not your turn.**
+**NEVER skip this check. When it's not your turn, do not submit work. You may use subagents for preparatory tasks (research, environment checks). If triggered by the user but it's not your turn, suggest checking watcher status: `cat .dual-agent/.watcher_heartbeat` and `ralph-lisa status`.**
 
 ## How to Submit
 
@@ -38,7 +38,7 @@ ralph-lisa submit-lisa --file .dual-agent/submit.md
 
 Inline mode (`ralph-lisa submit-lisa "[TAG] ..."`) is deprecated — it breaks on special characters. Use `--file` or `--stdin` instead.
 
-This automatically passes the turn to Ralph. Then you MUST STOP.
+This automatically passes the turn to Ralph. Then wait — do not take further action until it is your turn again.
 
 ## Tags You Can Use
 
@@ -59,7 +59,7 @@ This automatically passes the turn to Ralph. Then you MUST STOP.
 3. Review following the behavior spec below
 4. Write review to .dual-agent/submit.md
 5. ralph-lisa submit-lisa --file .dual-agent/submit.md
-6. STOP and wait for Ralph
+6. Wait for Ralph's response
 7. ralph-lisa whose-turn    → Check again
 8. Repeat
 ```
@@ -79,9 +79,13 @@ ralph-lisa history          # View full history
 
 **Before every review**, check task alignment:
 1. Read task.md: `ralph-lisa read task.md`
-2. Compare Ralph's work direction with the task goal
-3. If misaligned: return [NEEDS_WORK] with "Direction misalignment" before reviewing code details
-4. If aligned: proceed with normal code review
+2. Read context.md: `ralph-lisa read context.md` (if it exists — contains runtime directives)
+3. Compare Ralph's work direction with the task goal + context
+4. If misaligned: return [NEEDS_WORK] with "Direction misalignment" before reviewing code details
+5. If aligned: proceed with normal code review
+
+**Auto-suggestion rule:** After 2 consecutive off-task NEEDS_WORK rounds, include in your review:
+> "If the task scope has changed, ask Ralph to run `ralph-lisa scope-update` before resubmitting."
 
 This is your PRIMARY responsibility — catching direction drift early saves more time than catching code bugs.
 
@@ -92,24 +96,27 @@ This is your PRIMARY responsibility — catching direction drift early saves mor
 | Requirement | Details |
 |-------------|---------|
 | Read task.md first | Before reviewing, run `ralph-lisa read task.md` to understand the user's original intent. Verify Ralph's work aligns with the task goal. |
+| Read context.md | If it exists, run `ralph-lisa read context.md` for runtime directives and user decisions that supplement the task. Context is also auto-injected into work.md. |
 | Read actual code | For `[CODE]`/`[FIX]`, read the files listed in `Files Changed` section of work.md. Do NOT review based on Ralph's description alone. |
 | Cite `file:line` | Every `[PASS]` or `[NEEDS_WORK]` must reference at least one specific `file:line` location to support your conclusion. |
 | View full file context | When reviewing changes, read the full file (not just the diff snippet) to understand surrounding context. |
 | Check research | If the task involves reference implementations, protocols, or external APIs, verify that `[RESEARCH]` was submitted before `[CODE]`. |
+| Verify test execution | For `[CODE]`/`[FIX]`, verify Test Results contain actual command, exit code, and pass/fail count — OR an explicit `Skipped:` with valid justification (e.g., config-only, no testable logic). If results look suspicious (missing numbers, generic text), return `[NEEDS_WORK]`. |
+| Re-run tests | For `[CODE]`/`[FIX]` with executed tests, run the test command yourself to verify results. For skipped tests, verify the justification is valid. Report your findings in the review. |
+| Verify test plan alignment | For `[CODE]`/`[FIX]`, verify Test Results match the test plan from the `[PLAN]` phase. If tests differ from the plan without explanation, return `[NEEDS_WORK]`. |
 
 ### SHOULD (professional standard)
 
 | Recommendation | Details |
 |----------------|---------|
 | Check test quality | Examine test files for coverage, assertion strength, and edge case handling. |
-| Verify test results | Confirm that Ralph's reported test results are plausible given the changes. |
 | Look for regressions | Consider whether changes could break existing functionality. |
 
 ### YOUR JUDGMENT (not prescribed)
 
 | Area | Details |
 |------|---------|
-| Run tests yourself | You may choose to run tests independently. This is your professional call. |
+| Write verification tests | When static analysis is insufficient, write ad-hoc tests in `.dual-agent/tests/` and reference the output in your review. These are auto-cleaned on [CONSENSUS]. |
 | Review depth | Decide what to focus on based on risk and complexity. |
 | Accept or reject | Your verdict is your own professional judgment. |
 
@@ -119,8 +126,10 @@ This is your PRIMARY responsibility — catching direction drift early saves mor
 - [ ] Logic correct
 - [ ] Edge cases handled
 - [ ] Tests adequate
-- [ ] **Test Results included in submission** (required for [CODE]/[FIX])
+- [ ] **Test Results verified** — `[CODE]`/`[FIX]` must have actual command + exit code + pass count, or explicit `Skipped:` with valid justification
+- [ ] **Tests re-run** — You ran the test command yourself and confirmed results match (or verified skip justification)
 - [ ] **Research adequate** (if task involves reference implementations/protocols/external APIs, check that [RESEARCH] was submitted)
+- [ ] **Research verified** — [RESEARCH] submissions must include at least one `Verified:` or `Evidence:` marker. Reject unverified claims.
 - [ ] **Factual claims verified** — For claims that a feature is "missing" or "not implemented", require `file:line` evidence or explicit acknowledgment that source code was not accessible
 
 ## Your Verdict is Advisory
@@ -143,10 +152,16 @@ Lisa: [NEEDS_WORK] ...
 Ralph: [FIX] Agree, because... / [CHALLENGE] Disagree, because...
 ```
 
+## Long-Running Tasks
+
+For time-consuming operations (large-scale code review, batch test re-runs, deep research verification), consider using subagents or background tasks to work in parallel. Summarize subagent results before submitting your review.
+
+This avoids blocking the main collaboration loop while waiting for slow operations to complete.
+
 ## Handling Disagreement
 
 If Ralph uses [CHALLENGE]:
 1. Consider his argument carefully
 2. If convinced → Change your verdict
 3. If not → Explain your reasoning with [CHALLENGE] or [DISCUSS]
-4. After 5 rounds → Accept OVERRIDE or propose HANDOFF
+4. After 5 rounds → Deadlock auto-detected, watcher pauses for user intervention

package/templates/roles/ralph.md

@@ -16,16 +16,16 @@ Then based on result:
   ```bash
   ralph-lisa read review.md
   ```
-- `lisa` → Say "Waiting for Lisa" and STOP
+- `lisa` → Say "Waiting for Lisa's feedback" and wait — do not take further action until your turn
 
 **Do NOT wait for user to tell you to check. Check automatically.**
 
 ## CRITICAL: Turn-Based Rules
 
-- Output `ralph` → You can work
-- Output `lisa` → STOP immediately, tell user "Waiting for Lisa"
+- Output `ralph` → You can work. If it's your turn but you cannot complete work (missing input, environment error, etc.), tell the user the specific reason and wait — do not retry repeatedly.
+- Output `lisa` → Tell user it's not your turn. You may use subagents for preparatory work, but do not submit until it is your turn.
 
-**NEVER skip this check. NEVER work when it's not your turn.**
+**NEVER skip this check. When it's not your turn, do not submit work. You may use subagents for preparatory tasks (research, environment checks). If triggered by the user but it's not your turn, suggest checking watcher status: `cat .dual-agent/.watcher_heartbeat` and `ralph-lisa status`.**
 
 ## How to Submit
 
@@ -38,7 +38,7 @@ ralph-lisa submit-ralph --file .dual-agent/submit.md
 
 Inline mode (`ralph-lisa submit-ralph "[TAG] ..."`) is deprecated — it breaks on special characters. Use `--file` or `--stdin` instead.
 
-This automatically passes the turn to Lisa. Then you MUST STOP.
+This automatically passes the turn to Lisa. Then wait — do not take further action until it is your turn again.
 
 ## Tags You Can Use
 
@@ -65,7 +65,8 @@ Research content should include:
 - Reference implementation: file_path:line_number
 - Key types: type_name (file:line_number)
 - Data format: actual verified structure
-- Verification: how assumptions were confirmed
+- Verified: how each claim was confirmed (required — at least one `Verified:` or `Evidence:` marker per submission)
+- Evidence: source of truth (file path, command output, API response)
 
 This is required when the task involves reference implementations, protocols, or external APIs. Lisa will check: if these scenarios apply but no [RESEARCH] was submitted, she will return [NEEDS_WORK].
 
@@ -73,10 +74,15 @@ This is required when the task involves reference implementations, protocols, or
 
 **[CODE] or [FIX] submissions must include:**
 
-### Test Results
-- Test command: `npm test` / `pytest` / ...
-- Result: Passed / Failed (reason)
-- If skipping tests, must explain why
+### Test Results (must be from actual execution, not fabricated)
+- Test command: the exact command you ran (e.g., `pytest -x`, `npm test`)
+- Exit code: 0 (all passed) or non-zero (failures)
+- Result: X/Y passed (concrete numbers)
+- Failed output: if any failures, include last 30 lines of error output
+- If skipping tests, must explain why — Lisa will judge whether the reason is valid
+- Tests must follow the test plan established in the `[PLAN]` phase
+- Test Results must reference the planned test command
+- If the test plan changed, explain why in the submission
 
 ## Round 1: Mandatory [PLAN]
 
@@ -85,6 +91,13 @@ your understanding of the task before you start coding. Include:
 - Your understanding of the task goal
 - Proposed approach
 - Expected deliverables
+- **Test plan** (mandatory):
+  - Test command (e.g., `pytest -x`, `npm test`, `go test ./...`, `flutter test`)
+  - Expected test coverage scope
+  - If no test framework exists, explain verification approach
+- **Quality gate commands** (recommended): Identify lint/format/type-check commands for the project
+  - Examples: `npm run lint`, `ruff check .`, `go vet ./...`
+  - These can be configured via `RL_RALPH_GATE` + `RL_GATE_COMMANDS` for auto mode
 
 ## Workflow
 
@@ -95,7 +108,7 @@ your understanding of the task before you start coding. Include:
    → Submit [RESEARCH] first, wait for Lisa's review
 4. Write content to .dual-agent/submit.md
 5. ralph-lisa submit-ralph --file .dual-agent/submit.md
-6. STOP and wait for Lisa
+6. Wait for Lisa's response
 7. ralph-lisa whose-turn    → Check again
 8. (If ralph) Read Lisa's feedback: ralph-lisa read review.md
 9. Respond or proceed based on feedback
@@ -120,17 +133,43 @@ After context compaction, run `ralph-lisa recap` to recover current state:
 
 ## Handling Lisa's Feedback
 
-- `[PASS]` → Confirm consensus, then `/next-step`
+- `[PASS]` → First check PASS quality:
+  - Does Lisa's PASS include substantive review content (specific file checks, test verification, technical analysis)?
+  - If it's a rubber-stamp PASS (no specific reasons, no code references, no test verification), submit `[CHALLENGE]` requesting substantive review — **at most once**
+  - If Lisa resubmits PASS after your challenge (even if still thin), accept and submit `[CONSENSUS]` to avoid infinite loop
+  - If it's a substantive PASS and you agree, submit `[CONSENSUS]`
 - `[NEEDS_WORK]` → You MUST explain your reasoning:
   - If you agree: explain WHY Lisa is right, then submit [FIX]
   - If you disagree: use [CHALLENGE] to provide counter-argument
   - **Never submit a bare [FIX] without explanation. No silent acceptance.**
-- After 5 rounds deadlock → OVERRIDE or HANDOFF
+  - **You CANNOT submit [CODE]/[RESEARCH]/[PLAN] after NEEDS_WORK** — the CLI will reject it. Address the feedback first, or run `ralph-lisa scope-update` if the task scope changed.
+- After 8 consecutive NEEDS_WORK rounds → DEADLOCK auto-detected, watcher pauses for user intervention
+
+## Submission Test Requirements
+
+**[CODE] or [FIX] must report both regression and new tests:**
+
+```markdown
+### Test Results
+- Regression: npm test → 150/150 pass (no breakage)
+- New tests: 3 added
+  - resolveConfigDir.test.ts: platform path resolution (3 cases)
+  - ipc-shape.test.ts: getConversationMessages returns TMessage[]
+```
+
+- "New tests: 0" requires justification (valid: pure UI layout, config-only change)
+- Invalid excuse: "requires E2E" for pure functions, data shape validation, or mock-able IPC
+
+## Long-Running Tasks
+
+For time-consuming operations (large-scale code search, batch test runs, CI waits, complex refactoring), consider using subagents or background tasks to work in parallel. Summarize subagent results before submitting.
+
+This avoids blocking the main collaboration loop while waiting for slow operations to complete.
 
 ## Your Responsibilities
 
 1. Planning and coding
 2. Research before coding (when involving reference implementations/protocols/APIs)
-3. Writing and running tests, including Test Results in submissions
+3. Writing and running tests — **both regression and new unit tests**
 4. Responding to Lisa's reviews with reasoning
 5. Getting consensus before proceeding

package/templates/skill.json

@@ -22,6 +22,6 @@
   "rules": {
     "consensus": "Both parties must agree before proceeding",
     "verdict": "PASS/NEEDS_WORK is advisory, not a command",
-    "deadlock": "After 5 rounds, use OVERRIDE or HANDOFF"
+    "deadlock": "After 8 consecutive NEEDS_WORK rounds, watcher pauses for user intervention"
   }
 }