@codyswann/lisa 2.314.0 → 2.316.0

package/plugins/lisa-copilot/rules/eager/settled-decisions.md

@@ -0,0 +1,55 @@
+# 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-copilot/rules/eager/stale-state-claims.md

@@ -0,0 +1,26 @@
+# Stale State Claims — "Not Yet" Expires, the Note Does Not (load-bearing)
+
+A comment, docstring, config annotation, or work-item note that records a **temporary** state — "not yet", "pending", "waiting on X", "human-gated", "will flip once Y ships" — was accurate the day it was written and is believed long after it stopped being true. Nobody revisits prose when the condition clears.
+
+It then misdirects with full authority: work gets skipped as blocked when nothing blocks it, re-planned as undone when it already shipped, or escalated to a person who made that exact decision weeks ago.
+
+This is the sibling of `falsifiable-checks`. That rule is about **instruments that cannot fail**; this one is about **assertions of state that have expired**. Both read as authoritative and neither announces its own decay.
+
+## The four ways a recorded state outlives its truth
+
+Each has been observed; each was believed long after it went false:
+
+1. **Expired blocker note** — prose asserting a not-yet condition that has since cleared. An endpoint left unset under a comment saying its routing was "not yet promoted" had been serving live for days; an agent planned work to enable what was already enabled.
+2. **Stale gate marker** — a "pending human approval / not provisioned yet" annotation whose precondition is satisfied. One held for twelve days after the thing it waited on existed, and the decision was escalated to a person surprised to be asked.
+3. **Prediction buried by closure** — a warning recorded in a comment on an item that then closes. Closure deletes the warning: one correctly predicted a defect, the item closed 25 minutes later, and the defect sat unnoticed for eight days while a dependent item was parked waiting on it.
+4. **Silent waiting gate** — a queue or approval state with no surfacing mechanism, which holds work for exactly as long as nobody happens to look. One held a security-relevant fix undeployed for two days.
+
+## Mandatory
+
+- **A recorded blocker is a claim about the past — check the present before acting on it.** Before planning around it, escalating it, or reporting it as a blocker, probe the live state (`empirical-inquiry`). One command is cheap; inheriting a false premise is not.
+- **Whoever clears the condition deletes the claim.** Removing the block is not done until the note describing it is gone. A cleared gate whose comment survives is the next reader's false premise, and you are the last person who knows it is false.
+- **Prefer expiry-resistant forms.** State what **is** true rather than what is pending. Where a temporal claim is unavoidable, anchor it to something that fails when it goes stale — a check, a linked work item — never to prose nobody re-reads.
+- **A prediction on a closing item becomes tracked work or is retracted.** If the warning is real it is a work item with an explicit blocking link (`tracked-work`); if it is not real, retract it. Prose on a closed item is neither, and the one-way lifecycle means only `claim-archaeology` can recover it.
+- **A gate that can hold work silently is a defect in the gate.** Any waiting state needs a surfacing mechanism — notification, dashboard, scheduled sweep. Fix the gate; do not resolve to look more often.
+
+Full prose, worked examples, and the rewrite patterns: [reference/stale-state-claims.md](../reference/stale-state-claims.md).

package/plugins/lisa-copilot/rules/reference/falsifiable-checks.md

@@ -89,3 +89,4 @@ Concretely:
 - **`verification`** — proves the software behaves as a user needs. This rule proves the proof is real. Codified regression tests added under `codify-verification` are subject to this rule: a codified spec that cannot fail is not a regression gate.
 - **`empirical-inquiry`** — settles an uncertain fact with the cheapest probe. A probe is a check, so it inherits the falsification requirement, including deliberate bite controls (cases that MUST report a problem) when the probe's job is to detect problems.
 - **`claim-evidence-mapping`** — an unfalsified gate cannot back a claim.
+- **`stale-state-claims`** — the sibling failure from the opposite direction: an assertion of state that *could* fail but is never re-evaluated, because nothing re-runs prose. Binding a temporal claim to a check is the recommended fix there, which puts that check under this rule.

package/plugins/lisa-copilot/rules/reference/settled-decisions.md

@@ -0,0 +1,29 @@
+# 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-copilot/rules/reference/stale-state-claims.md

@@ -0,0 +1,88 @@
+# Stale State Claims — Reference
+
+Eager head: [eager/stale-state-claims.md](../eager/stale-state-claims.md).
+
+## Why this rule exists
+
+Most bad documentation is *wrong*. This kind was **right** — and that is what makes it dangerous. A note saying "not wired up yet" earned its credibility honestly, so the next reader has no reason to doubt it. There is no defect to find, no test that goes red, no reviewer who objects. The claim simply keeps being read after the world moved.
+
+The cost is not confusion, it is confident misdirection in a specific direction: **toward doing nothing**. An expired blocker never causes someone to break production. It causes work to be skipped, re-planned, or escalated — outcomes that look like caution and are indistinguishable from good judgment at the moment they happen.
+
+The `falsifiable-checks` rule covers instruments that cannot fail. This one covers assertions that *could* fail but are never re-evaluated, because nothing re-runs prose. Both produce the same end state — a confident answer with no live evidence behind it — from opposite directions.
+
+## The four failure modes, in detail
+
+### 1. Expired blocker note
+
+A comment, docstring, config value, or README line records that something is not available yet. The condition clears. The note does not.
+
+Observed: a deployment stage's endpoint was left unset with an adjacent comment explaining that its routing had "not yet been promoted." The routing had been live for days. An agent read the comment, believed it, and planned work to enable a capability that was already enabled — then reported the capability as pending.
+
+Countermeasures:
+- Treat any not-yet claim as a **hypothesis with an expiry you cannot see**. Resolve it with one live probe (a request, a query, a status read) before it enters a plan, a status report, or an escalation.
+- Cite the probe, not the comment: "verified live at <time>" is evidence; "the comment says" is hearsay about the past.
+- When you are the one who promotes/enables/provisions the thing, the note describing its absence is part of the change. Grep for it.
+
+### 2. Stale gate marker
+
+A config entry, flag, or checklist item is annotated as awaiting a human decision or an unfulfilled prerequisite. The prerequisite arrives, or the decision gets made elsewhere. The marker persists and keeps routing work to a gate that is no longer closed.
+
+Observed: an entry marked human-gated because no client had been provisioned. The client had existed for twelve days. The gate was honored anyway and the question escalated to a person who had already decided it and was surprised to be asked.
+
+This mode is corrosive twice over: it wastes the human's attention, and it teaches the agent that gates are noise — which is exactly the wrong lesson to carry into a gate that is still real.
+
+Countermeasures:
+- Before honoring a gate, verify the condition that justifies it still holds. A gate whose stated reason is falsifiable and false is not a gate.
+- Record gates as **conditions**, not as verdicts: "gated until <checkable condition>" can be evaluated; "human-gated" cannot.
+- When escalating, state the evidence that the gate is still live. If you cannot, you are escalating a comment.
+
+### 3. Prediction buried by closure
+
+Someone records a correct warning — "this will fail until X is fixed", "this leaves Y broken" — as a comment on a work item, and the item then closes. Closure is a filter: closed items are not read. The prediction is deleted in every practical sense while feeling like it was recorded.
+
+Observed: a comment correctly predicted a defect. The item closed 25 minutes later with no follow-up filed. The defect sat unnoticed for **eight days**, blocking a dependent item that was itself parked waiting for it — two items, both stalled, and the explanation was already written down in a place nobody would look.
+
+Countermeasures:
+- A prediction is either **real work or a retraction**. If real, it is a tracked leaf with an explicit blocking link to what it blocks (`tracked-work`), created **before** the parent item closes. If not real, say so in the same thread so the next reader is not left holding an unresolved warning.
+- Never let closing be the last action on an item that carries an open prediction. Check the comment thread as part of closing.
+- Blocking links are the mechanism that makes the parked dependent item legible. A prediction with no link is invisible from the side that is actually waiting.
+
+### 4. Silent waiting gate
+
+An approval, queue, or review state holds work and emits nothing. Its duration is therefore set by how often somebody happens to look, which is not a property of the work's urgency.
+
+Observed: a deploy approval gate held a security-relevant fix undeployed for two days. Nothing was broken, nobody was wrong, and nothing surfaced that the gate was waiting.
+
+Countermeasures:
+- Every waiting state needs a surfacing mechanism proportional to what it can hold: notification, dashboard row, scheduled sweep, or an automatic expiry.
+- **Fix the gate, not your habits.** "Remember to check" is not a mechanism; it is the same failure with a person's name on it.
+- When you add a gate, state how long it may silently hold work and what surfaces it. If the answer is "indefinitely" and "nothing", the gate is not finished.
+
+## Expiry-resistant forms
+
+Prefer, in order:
+
+1. **State what is true.** "Serves from <path>" outlives "not yet serving from <path>", because it stays wrong-detectably wrong instead of quietly-stale.
+2. **Bind the claim to a check.** A test, guard, or assertion that fails when the temporal claim goes false converts a silent expiry into a red build. (That check is itself subject to `falsifiable-checks` — a guard that cannot fail re-creates the problem it was added to solve.)
+3. **Bind the claim to a work item.** "Blocked by <ref>" is resolvable by anyone; "waiting on the migration" is resolvable only by whoever wrote it.
+4. **Timestamp and scope it.** If prose is genuinely the only option, write "as of <date>" and name the condition that ends it. A dated claim at least advertises its own age.
+
+Avoid: bare "not yet", "TODO once", "temporarily", "for now", "pending" with no owner, condition, date, or link. Each is a claim that can only be falsified by someone who already knows the truth — which is the one person who does not need to read it.
+
+## How to apply
+
+1. Reading a note that asserts a pending/blocked/not-yet state: **do not act on it yet.**
+2. Identify the cheapest live probe that settles the underlying fact.
+3. Run it. Report the observation, not the note.
+4. If the note is stale, **delete or correct it in the same change** — leaving it is handing the next reader the trap you just escaped.
+5. If the note is accurate, upgrade it while you are there: attach the condition, the link, or the check that will make it self-expiring.
+
+And when you are the one clearing a condition: sweep for the notes that described it. The change is not complete while the repository still asserts the old state.
+
+## Interaction with other rules
+
+- **`falsifiable-checks`** — the sibling failure. That rule prevents an instrument that cannot fail; this one prevents an assertion that never gets re-evaluated. A check bound to a temporal claim (form 2 above) sits under both rules at once.
+- **`empirical-inquiry`** — supplies the discipline this rule depends on: settle the fact with the cheapest probe rather than reasoning from what is written down. A stale note is exactly the "confident-sounding answer from a prior assumption" that rule forbids.
+- **`verification`** — a status derived from a comment is not runtime evidence. Reporting "still blocked" on the strength of a note is the same error as reporting "works" on the strength of the code looking correct.
+- **`tracked-work`** — the destination for any prediction that survives its item's closure: one live leaf, explicit blocking link, carried on the branch and PR.
+- **`claim-archaeology`** — the recovery path once mode 3 has already happened. Lifecycles are one-way, so a warning lost to closure resurfaces only as a fresh item whose ancestry has to be reconstructed. Archaeology is the cleanup; this rule is the prevention.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.314.0",
+  "version": "2.316.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cursor/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/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/empirical-inquiry.mdc

@@ -21,6 +21,7 @@ Do not reason your way to a confident-sounding answer from documentation, prior
 - Presenting a guess, recollection, or doc summary as established fact when it was cheap to verify and you did not.
 - "Should work" / "probably" / "the docs say" as the basis for a load-bearing decision an experiment could have settled.
 - Skipping the probe because the answer "seems obvious" — those are exactly the ones that quietly drift from reality.
+- Treating a recorded "not yet" / "pending" / "blocked" / "human-gated" note as current state. It is a claim about the day it was written; probe the live state before planning around it, escalating it, or reporting it as a blocker (`stale-state-claims`).
 
 This is the inquiry counterpart to the `verification` rule (which proves completed work behaves correctly). Both reject "it looks correct" as evidence.
 

package/plugins/lisa-cursor/rules/falsifiable-checks-reference.mdc

@@ -94,3 +94,4 @@ Concretely:
 - **`verification`** — proves the software behaves as a user needs. This rule proves the proof is real. Codified regression tests added under `codify-verification` are subject to this rule: a codified spec that cannot fail is not a regression gate.
 - **`empirical-inquiry`** — settles an uncertain fact with the cheapest probe. A probe is a check, so it inherits the falsification requirement, including deliberate bite controls (cases that MUST report a problem) when the probe's job is to detect problems.
 - **`claim-evidence-mapping`** — an unfalsified gate cannot back a claim.
+- **`stale-state-claims`** — the sibling failure from the opposite direction: an assertion of state that *could* fail but is never re-evaluated, because nothing re-runs prose. Binding a temporal claim to a check is the recommended fix there, which puts that check under this rule.

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-cursor/rules/stale-state-claims-reference.mdc

@@ -0,0 +1,93 @@
+---
+description: "Stale State Claims — Reference"
+alwaysApply: false
+---
+
+# Stale State Claims — Reference
+
+Eager head: [eager/stale-state-claims.md](stale-state-claims.mdc).
+
+## Why this rule exists
+
+Most bad documentation is *wrong*. This kind was **right** — and that is what makes it dangerous. A note saying "not wired up yet" earned its credibility honestly, so the next reader has no reason to doubt it. There is no defect to find, no test that goes red, no reviewer who objects. The claim simply keeps being read after the world moved.
+
+The cost is not confusion, it is confident misdirection in a specific direction: **toward doing nothing**. An expired blocker never causes someone to break production. It causes work to be skipped, re-planned, or escalated — outcomes that look like caution and are indistinguishable from good judgment at the moment they happen.
+
+The `falsifiable-checks` rule covers instruments that cannot fail. This one covers assertions that *could* fail but are never re-evaluated, because nothing re-runs prose. Both produce the same end state — a confident answer with no live evidence behind it — from opposite directions.
+
+## The four failure modes, in detail
+
+### 1. Expired blocker note
+
+A comment, docstring, config value, or README line records that something is not available yet. The condition clears. The note does not.
+
+Observed: a deployment stage's endpoint was left unset with an adjacent comment explaining that its routing had "not yet been promoted." The routing had been live for days. An agent read the comment, believed it, and planned work to enable a capability that was already enabled — then reported the capability as pending.
+
+Countermeasures:
+- Treat any not-yet claim as a **hypothesis with an expiry you cannot see**. Resolve it with one live probe (a request, a query, a status read) before it enters a plan, a status report, or an escalation.
+- Cite the probe, not the comment: "verified live at <time>" is evidence; "the comment says" is hearsay about the past.
+- When you are the one who promotes/enables/provisions the thing, the note describing its absence is part of the change. Grep for it.
+
+### 2. Stale gate marker
+
+A config entry, flag, or checklist item is annotated as awaiting a human decision or an unfulfilled prerequisite. The prerequisite arrives, or the decision gets made elsewhere. The marker persists and keeps routing work to a gate that is no longer closed.
+
+Observed: an entry marked human-gated because no client had been provisioned. The client had existed for twelve days. The gate was honored anyway and the question escalated to a person who had already decided it and was surprised to be asked.
+
+This mode is corrosive twice over: it wastes the human's attention, and it teaches the agent that gates are noise — which is exactly the wrong lesson to carry into a gate that is still real.
+
+Countermeasures:
+- Before honoring a gate, verify the condition that justifies it still holds. A gate whose stated reason is falsifiable and false is not a gate.
+- Record gates as **conditions**, not as verdicts: "gated until <checkable condition>" can be evaluated; "human-gated" cannot.
+- When escalating, state the evidence that the gate is still live. If you cannot, you are escalating a comment.
+
+### 3. Prediction buried by closure
+
+Someone records a correct warning — "this will fail until X is fixed", "this leaves Y broken" — as a comment on a work item, and the item then closes. Closure is a filter: closed items are not read. The prediction is deleted in every practical sense while feeling like it was recorded.
+
+Observed: a comment correctly predicted a defect. The item closed 25 minutes later with no follow-up filed. The defect sat unnoticed for **eight days**, blocking a dependent item that was itself parked waiting for it — two items, both stalled, and the explanation was already written down in a place nobody would look.
+
+Countermeasures:
+- A prediction is either **real work or a retraction**. If real, it is a tracked leaf with an explicit blocking link to what it blocks (`tracked-work`), created **before** the parent item closes. If not real, say so in the same thread so the next reader is not left holding an unresolved warning.
+- Never let closing be the last action on an item that carries an open prediction. Check the comment thread as part of closing.
+- Blocking links are the mechanism that makes the parked dependent item legible. A prediction with no link is invisible from the side that is actually waiting.
+
+### 4. Silent waiting gate
+
+An approval, queue, or review state holds work and emits nothing. Its duration is therefore set by how often somebody happens to look, which is not a property of the work's urgency.
+
+Observed: a deploy approval gate held a security-relevant fix undeployed for two days. Nothing was broken, nobody was wrong, and nothing surfaced that the gate was waiting.
+
+Countermeasures:
+- Every waiting state needs a surfacing mechanism proportional to what it can hold: notification, dashboard row, scheduled sweep, or an automatic expiry.
+- **Fix the gate, not your habits.** "Remember to check" is not a mechanism; it is the same failure with a person's name on it.
+- When you add a gate, state how long it may silently hold work and what surfaces it. If the answer is "indefinitely" and "nothing", the gate is not finished.
+
+## Expiry-resistant forms
+
+Prefer, in order:
+
+1. **State what is true.** "Serves from <path>" outlives "not yet serving from <path>", because it stays wrong-detectably wrong instead of quietly-stale.
+2. **Bind the claim to a check.** A test, guard, or assertion that fails when the temporal claim goes false converts a silent expiry into a red build. (That check is itself subject to `falsifiable-checks` — a guard that cannot fail re-creates the problem it was added to solve.)
+3. **Bind the claim to a work item.** "Blocked by <ref>" is resolvable by anyone; "waiting on the migration" is resolvable only by whoever wrote it.
+4. **Timestamp and scope it.** If prose is genuinely the only option, write "as of <date>" and name the condition that ends it. A dated claim at least advertises its own age.
+
+Avoid: bare "not yet", "TODO once", "temporarily", "for now", "pending" with no owner, condition, date, or link. Each is a claim that can only be falsified by someone who already knows the truth — which is the one person who does not need to read it.
+
+## How to apply
+
+1. Reading a note that asserts a pending/blocked/not-yet state: **do not act on it yet.**
+2. Identify the cheapest live probe that settles the underlying fact.
+3. Run it. Report the observation, not the note.
+4. If the note is stale, **delete or correct it in the same change** — leaving it is handing the next reader the trap you just escaped.
+5. If the note is accurate, upgrade it while you are there: attach the condition, the link, or the check that will make it self-expiring.
+
+And when you are the one clearing a condition: sweep for the notes that described it. The change is not complete while the repository still asserts the old state.
+
+## Interaction with other rules
+
+- **`falsifiable-checks`** — the sibling failure. That rule prevents an instrument that cannot fail; this one prevents an assertion that never gets re-evaluated. A check bound to a temporal claim (form 2 above) sits under both rules at once.
+- **`empirical-inquiry`** — supplies the discipline this rule depends on: settle the fact with the cheapest probe rather than reasoning from what is written down. A stale note is exactly the "confident-sounding answer from a prior assumption" that rule forbids.
+- **`verification`** — a status derived from a comment is not runtime evidence. Reporting "still blocked" on the strength of a note is the same error as reporting "works" on the strength of the code looking correct.
+- **`tracked-work`** — the destination for any prediction that survives its item's closure: one live leaf, explicit blocking link, carried on the branch and PR.
+- **`claim-archaeology`** — the recovery path once mode 3 has already happened. Lifecycles are one-way, so a warning lost to closure resurfaces only as a fresh item whose ancestry has to be reconstructed. Archaeology is the cleanup; this rule is the prevention.

package/plugins/lisa-cursor/rules/stale-state-claims.mdc

@@ -0,0 +1,31 @@
+---
+description: "Stale State Claims — \"Not Yet\" Expires, the Note Does Not (load-bearing)"
+alwaysApply: true
+---
+
+# Stale State Claims — "Not Yet" Expires, the Note Does Not (load-bearing)
+
+A comment, docstring, config annotation, or work-item note that records a **temporary** state — "not yet", "pending", "waiting on X", "human-gated", "will flip once Y ships" — was accurate the day it was written and is believed long after it stopped being true. Nobody revisits prose when the condition clears.
+
+It then misdirects with full authority: work gets skipped as blocked when nothing blocks it, re-planned as undone when it already shipped, or escalated to a person who made that exact decision weeks ago.
+
+This is the sibling of `falsifiable-checks`. That rule is about **instruments that cannot fail**; this one is about **assertions of state that have expired**. Both read as authoritative and neither announces its own decay.
+
+## The four ways a recorded state outlives its truth
+
+Each has been observed; each was believed long after it went false:
+
+1. **Expired blocker note** — prose asserting a not-yet condition that has since cleared. An endpoint left unset under a comment saying its routing was "not yet promoted" had been serving live for days; an agent planned work to enable what was already enabled.
+2. **Stale gate marker** — a "pending human approval / not provisioned yet" annotation whose precondition is satisfied. One held for twelve days after the thing it waited on existed, and the decision was escalated to a person surprised to be asked.
+3. **Prediction buried by closure** — a warning recorded in a comment on an item that then closes. Closure deletes the warning: one correctly predicted a defect, the item closed 25 minutes later, and the defect sat unnoticed for eight days while a dependent item was parked waiting on it.
+4. **Silent waiting gate** — a queue or approval state with no surfacing mechanism, which holds work for exactly as long as nobody happens to look. One held a security-relevant fix undeployed for two days.
+
+## Mandatory
+
+- **A recorded blocker is a claim about the past — check the present before acting on it.** Before planning around it, escalating it, or reporting it as a blocker, probe the live state (`empirical-inquiry`). One command is cheap; inheriting a false premise is not.
+- **Whoever clears the condition deletes the claim.** Removing the block is not done until the note describing it is gone. A cleared gate whose comment survives is the next reader's false premise, and you are the last person who knows it is false.
+- **Prefer expiry-resistant forms.** State what **is** true rather than what is pending. Where a temporal claim is unavoidable, anchor it to something that fails when it goes stale — a check, a linked work item — never to prose nobody re-reads.
+- **A prediction on a closing item becomes tracked work or is retracted.** If the warning is real it is a work item with an explicit blocking link (`tracked-work`); if it is not real, retract it. Prose on a closed item is neither, and the one-way lifecycle means only `claim-archaeology` can recover it.
+- **A gate that can hold work silently is a defect in the gate.** Any waiting state needs a surfacing mechanism — notification, dashboard, scheduled sweep. Fix the gate; do not resolve to look more often.
+
+Full prose, worked examples, and the rewrite patterns: [reference/stale-state-claims.md](stale-state-claims-reference.mdc).

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.314.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.314.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.314.0",
+  "version": "2.316.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"