@codyswann/lisa 2.315.0 → 2.316.0

package/plugins/lisa-cursor/rules/automation-runbook-contract.mdc

@@ -20,6 +20,31 @@ Membership is **registration, not skill-existence**: a loop is under this contra
 registered as a scheduled automation, and registering a new one pulls it in automatically. There is
 no hardcoded roster of loops anywhere.
 
+### Interactive flows are members too
+
+The outcome vocabulary is **not cron-specific** — it answers "did this need me?", which an operator
+asks of an interactive run exactly as often as of a scheduled one. Every Lisa flow that terminates
+is a member: `lisa-implement`, `lisa-verify`, `lisa-plan`, `lisa-git-submit-pr`,
+`lisa-drive-pr-to-merge`, `lisa-research`, and any skill invoked as a slash command.
+
+For an interactive flow the required run record is the **final user-facing message**, not a JSONL
+row written by `automation-run-record.mjs`. Interactive flows may also record local JSONL telemetry
+when a specific skill owns that surface, but this contract's mandatory record is the final answer.
+It opens with the outcome and the operator action, before any narrative:
+
+```
+change-proved — nothing for you. PR #6393 open, auto-merge on, CI running.
+approval-requested — need a decision: ship the 135 Regular→Bold flips, or hold for design sign-off?
+recovery-required — need you: staging E2E gate red for congestion; rerun or admin-merge.
+```
+
+The operator must learn whether they are needed **from the first line**, without reading the report.
+Findings, evidence and caveats follow; they never replace the action line and never precede it.
+
+An interactive flow that ends in prose with the action buried — or absent — is the same contract
+violation as a silent cron exit. "I flagged X, I noticed Y, worth knowing Z" is narrative, not an
+outcome. If nothing is needed, say **"nothing for you"** in those words and stop.
+
 ## The six run outcomes
 
 Exactly one per run:

package/plugins/lisa-cursor/rules/settled-decisions-reference.mdc

@@ -0,0 +1,34 @@
+---
+description: "Settled Decisions"
+alwaysApply: false
+---
+
+# Settled Decisions
+
+Do not ask the operator to decide something that is already settled by standing preference, evidence you just gathered, or a conventional default. A question is appropriate only when the answer materially changes the work and the answer cannot be derived from available artifacts.
+
+## Decision Sources
+
+Check these sources before asking:
+
+1. Standing preferences recorded in memory, project config, project rules, instruction files, or earlier in the same conversation.
+2. Evidence already gathered during the current run. If research or code inspection resolves the choice, report the decision and cite the evidence.
+3. Conventional defaults where one option is clearly standard and the alternative needs a reason.
+
+If one of those sources answers the question, act on it and state the basis briefly.
+
+## When To Ask
+
+Ask only when the answer changes the deliverable and cannot be inferred. That includes product decisions, design vocabulary that does not exist yet, destructive or unsafe assumptions, or choices that would waste substantial work if guessed wrong.
+
+When asking, ask once, plainly, with a recommended option.
+
+## Common Violations
+
+Half-applying a standing instruction is a violation. If a preference covers a multi-step behavior, apply the whole behavior instead of doing one part and asking about the rest.
+
+Asking after the research answered the question is also a violation. When gathered evidence points one way unambiguously, treat it as a decision and make the reasoning auditable in the report.
+
+## Reporting
+
+Record settled decisions in a short clause, such as "auto-merge on, per standing preference" or "scoped app-wide, because the Android finding decides it." This gives the operator a chance to correct the decision without requiring an avoidable question first.

package/plugins/lisa-cursor/rules/settled-decisions.mdc

@@ -0,0 +1,60 @@
+---
+description: "Settled Decisions (load-bearing)"
+alwaysApply: true
+---
+
+# Settled Decisions (load-bearing)
+
+**Never ask the operator a question that a standing preference or your own gathered evidence has
+already answered.** Re-asking a settled decision is not caution — it hands back a choice the
+operator already made and makes them make it twice.
+
+## The test
+
+Before asking anything, check the three sources that may already hold the answer:
+
+1. **A standing preference** — something the operator has told you once and expects to hold:
+   recorded in project memory, `.lisa.config.json`, a project rule, `CLAUDE.md`/`AGENTS.md`, or
+   stated earlier in this conversation. "Every PR gets auto-merge and gets watched to merge" is a
+   standing preference; asking "want me to watch this PR?" violates it.
+2. **Evidence you already gathered** — if the research, measurement or code read you just performed
+   resolves the question, the question is answered. Report the decision and the evidence for it.
+3. **A convention with an obvious default** — where one option is clearly conventional and the other
+   needs a reason, take the conventional one and say so in one line.
+
+If any source answers it: **act, and state the decision in a clause.** Do not convert it into a
+question.
+
+## When asking IS right
+
+Ask when the answer would change the work *and* you genuinely cannot derive it:
+
+- The options lead to materially different deliverables and nothing in scope decides between them.
+- Proceeding on a wrong assumption would be unsafe, destructive, or waste substantial work.
+- The answer is a human judgement the artifacts do not contain — a product decision, a design
+  vocabulary that does not exist yet, a risk the operator owns.
+
+That kind of question is load-bearing and should be asked plainly, once, with a recommendation.
+
+## The failure mode this rule exists to stop
+
+Asking feels collaborative, so it gets over-applied — especially at the end of a report, where a
+trailing question reads as deference. It is not deference when the answer was already given; it is
+work handed back. Two specific tells:
+
+- **Half-applying an instruction.** Doing the first half of a standing preference automatically and
+  asking permission for the second half of the same preference.
+- **Asking after the research answered it.** Completing an investigation that points one direction
+  unambiguously, then presenting the conclusion as an open question.
+
+## Partial application is worse than either extreme
+
+If a standing preference covers a multi-step behavior, apply **all** of it. Applying part and asking
+about the rest produces the worst outcome: the operator is interrupted *and* the instruction was not
+honored.
+
+## Recording, not asking
+
+When you take a settled decision, make it auditable in one clause — "auto-merge on, per your standing
+preference", "scoped app-wide, because the Android finding decides it". That gives the operator the
+chance to correct it without requiring them to answer first.

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.315.0",
+  "version": "2.316.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/hooks/enforce-verification-gate.sh

@@ -132,6 +132,7 @@ STATE_DIR="${TMPDIR:-/tmp}/lisa-verification-gate"
 mkdir -p "$STATE_DIR" 2>/dev/null || exit 0
 
 ARM_FLAG="${STATE_DIR}/${SESSION_ID}.armed"
+ARM_PLAN_FILE="${STATE_DIR}/${SESSION_ID}.plan"
 SUBAGENT_FLAG="${STATE_DIR}/${SESSION_ID}.subagent"
 COUNT_FILE="${STATE_DIR}/${SESSION_ID}.blocks"
 
@@ -149,6 +150,19 @@ arm_once() {
   [ -f "$ARM_FLAG" ] || touch "$ARM_FLAG" 2>/dev/null || true
 }
 
+record_current_plan() {
+  local plan="$1"
+  [ -n "$plan" ] || return 0
+  [ -f "$ARM_PLAN_FILE" ] && return 0
+  printf '%s\n' "$plan" > "$ARM_PLAN_FILE" 2>/dev/null || true
+}
+
+plan_from_prompt() {
+  printf '%s' "$1" |
+    sed -nE '1{s/^[[:space:]]*\/(lisa:implement|implement)[[:space:]]+([^[:space:]]+).*$/\2/p;}' |
+    tr '[:upper:]' '[:lower:]'
+}
+
 case "$HOOK_EVENT" in
   SubagentStart)
     touch "$SUBAGENT_FLAG" 2>/dev/null || true
@@ -162,6 +176,7 @@ case "$HOOK_EVENT" in
       case "$LEADING" in
         /lisa:implement*|/implement*)
           arm_once
+          record_current_plan "$(plan_from_prompt "$LEADING")"
           ;;
       esac
     fi
@@ -175,6 +190,8 @@ case "$HOOK_EVENT" in
       case "$SKILL_NAME" in
         lisa-implement|implement)
           arm_once
+          SKILL_ARGUMENTS=$(printf '%s' "$INPUT" | jq -r '.tool_input.arguments // .tool_input.input // empty' 2>/dev/null || true)
+          record_current_plan "$(printf '%s' "$SKILL_ARGUMENTS" | awk '{print tolower($1)}')"
           ;;
       esac
     fi
@@ -205,6 +222,39 @@ fi
 PROJECT_DIR="${CLAUDE_PROJECT_DIR:-.}"
 VERDICT_FILE="${PROJECT_DIR}/.lisa/verification-status.json"
 
+# A completed flow's verdict is a shipped record. The next flow in the same
+# worktree writes the SAME path and destroys it — losing the evidence that
+# proved the earlier work, and gating the new run against a verdict whose
+# `plan` names something else entirely. Preserve any verdict belonging to a
+# different plan before this run can overwrite it.
+#
+# Keyed on `.plan`, so re-running the same plan still overwrites in place and
+# no archive accumulates.
+preserve_foreign_verdict() {
+  [ -f "$VERDICT_FILE" ] || return 0
+  command -v jq >/dev/null 2>&1 || return 0
+
+  local prior_plan current_plan archive
+  prior_plan=$(jq -r '.plan // empty' "$VERDICT_FILE" 2>/dev/null || true)
+  [ -n "$prior_plan" ] || return 0
+  case "$prior_plan" in
+    *[!A-Za-z0-9._-]*)
+      return 0
+      ;;
+  esac
+  current_plan=$(cat "$ARM_PLAN_FILE" 2>/dev/null || true)
+  [ -z "$current_plan" ] || [ "$prior_plan" != "$current_plan" ] || return 0
+
+  # Only archive a verdict written BEFORE this flow armed — anything newer
+  # belongs to the current run.
+  [ "$VERDICT_FILE" -ot "$ARM_FLAG" ] || return 0
+
+  archive="${PROJECT_DIR}/.lisa/verification-status.${prior_plan}.json"
+  [ -f "$archive" ] || cp -p "$VERDICT_FILE" "$archive" 2>/dev/null || true
+}
+
+preserve_foreign_verdict
+
 # Set by the v2 path when a claim/evidence violation is what closed the gate,
 # so the block message can state the real reason instead of the v1 fallback.
 V2_BLOCK_REASON=""
@@ -387,7 +437,7 @@ verdict_is_terminal() {
 if verdict_is_terminal; then
   # Gate satisfied — disarm so a follow-up stop in the same session is not
   # re-gated against the now-consumed verdict, and allow the stop.
-  rm -f "$ARM_FLAG" "$COUNT_FILE" 2>/dev/null || true
+  rm -f "$ARM_FLAG" "$ARM_PLAN_FILE" "$COUNT_FILE" 2>/dev/null || true
   exit 0
 fi
 
@@ -400,7 +450,7 @@ COUNT=$((COUNT + 1))
 echo "$COUNT" > "$COUNT_FILE" 2>/dev/null || true
 
 if [ "$COUNT" -gt "$MAX_BLOCKS" ]; then
-  rm -f "$ARM_FLAG" "$COUNT_FILE" 2>/dev/null || true
+  rm -f "$ARM_FLAG" "$ARM_PLAN_FILE" "$COUNT_FILE" 2>/dev/null || true
   cat >&2 <<EOF
 Verification gate: still no passing verdict after ${MAX_BLOCKS} attempts.
 Releasing the stop gate to avoid an infinite loop. The /lisa:implement Verify

package/plugins/src/base/rules/eager/automation-runbook-contract.md

@@ -15,6 +15,31 @@ Membership is **registration, not skill-existence**: a loop is under this contra
 registered as a scheduled automation, and registering a new one pulls it in automatically. There is
 no hardcoded roster of loops anywhere.
 
+### Interactive flows are members too
+
+The outcome vocabulary is **not cron-specific** — it answers "did this need me?", which an operator
+asks of an interactive run exactly as often as of a scheduled one. Every Lisa flow that terminates
+is a member: `lisa-implement`, `lisa-verify`, `lisa-plan`, `lisa-git-submit-pr`,
+`lisa-drive-pr-to-merge`, `lisa-research`, and any skill invoked as a slash command.
+
+For an interactive flow the required run record is the **final user-facing message**, not a JSONL
+row written by `automation-run-record.mjs`. Interactive flows may also record local JSONL telemetry
+when a specific skill owns that surface, but this contract's mandatory record is the final answer.
+It opens with the outcome and the operator action, before any narrative:
+
+```
+change-proved — nothing for you. PR #6393 open, auto-merge on, CI running.
+approval-requested — need a decision: ship the 135 Regular→Bold flips, or hold for design sign-off?
+recovery-required — need you: staging E2E gate red for congestion; rerun or admin-merge.
+```
+
+The operator must learn whether they are needed **from the first line**, without reading the report.
+Findings, evidence and caveats follow; they never replace the action line and never precede it.
+
+An interactive flow that ends in prose with the action buried — or absent — is the same contract
+violation as a silent cron exit. "I flagged X, I noticed Y, worth knowing Z" is narrative, not an
+outcome. If nothing is needed, say **"nothing for you"** in those words and stop.
+
 ## The six run outcomes
 
 Exactly one per run: