@codyswann/lisa 4.49.0 → 4.50.0

package/plugins/lisa-copilot/skills/lisa-linear-build-intake/SKILL.md

@@ -231,6 +231,10 @@ other gate's verdict — however conclusive — may promote an item a person par
 4. **Name it in the cycle summary** via `summarizeHumanGateHolds([...])`, so the record
    distinguishes "nothing was eligible" from "something eligible was held for a person". A lane
    mutation nobody can see afterwards is the same class of problem this gate exists to fix.
+   Report alongside it what the precision rule SKIPPED, via `summarizeHumanGateMentions(n)`
+   — the marker occurrences that were mentions rather than declarations (CodySwannGT/lisa#3815).
+   A rule that quietly declines to honour half the occurrences it sees reads exactly like a
+   rule that saw none, so the count is printed even when it is zero.
 5. **Continue to the next candidate.** A held item does not end the cycle.
 
 

package/plugins/lisa-copilot/skills/lisa-repair-intake/SKILL.md

@@ -994,7 +994,10 @@ with labels like `build-ready`, or with no Lisa status label at all, that are in
    instead — it says that nothing was changed and how a person resumes the item, which is the
    opposite of what the reconciliation note says and must not be substituted for it. A promotion
    declined silently is invisible, which is the quieter version of the failure this step exists to
-   prevent, so name every held item in the cycle summary via `summarizeHumanGateHolds([...])`.
+   prevent, so name every held item in the cycle summary via `summarizeHumanGateHolds([...])`. Report what the
+   precision rule skipped beside it via `summarizeHumanGateMentions(n)`: the marker
+   occurrences that were mentions rather than declarations (CodySwannGT/lisa#3815),
+   because a rule that silently drops candidates reads like one that found none.
 
 ### Ungated non-ready filing → surface as an incomplete handoff (read-only)
 

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

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

package/plugins/lisa-cursor/hooks/block-direct-issue-create.sh

@@ -494,6 +494,82 @@ project_dir = os.environ.get("LISA_GUARD_PROJECT_DIR", "")
 OVERRIDE_NAME = "LISA_ALLOW_DIRECT_ISSUE_CREATE"
 HUMAN_GATE_MARKER = "[lisa-human-gate]"
 
+# Decoration a hold declaration may sit behind, and nothing more: whitespace,
+# blockquote arrows, list bullets or numbers, emphasis, an opening HTML
+# comment. One character class plus two optional groups, deliberately not a
+# nested quantifier — this runs over untrusted issue bodies.
+HUMAN_GATE_DECORATION = re.compile(r"^[ \t>*_+#-]*(?:\d+[.)][ \t]*)?(?:<!--[ \t]*)?[ \t]*")
+HUMAN_GATE_FENCE = re.compile(r"```.*?```", re.DOTALL)
+HUMAN_GATE_CODE_SPAN = re.compile(r"`[^`\n]*`")
+
+
+def declares_human_gate(text):
+    """Whether a text DECLARES a hold rather than mentioning one.
+
+    The comment this replaces said the marker is matched anywhere because it
+    "has no other meaning, so its presence in the title or body IS the
+    declaration". That was true when written and is false now: the marker
+    acquired a second meaning -- being discussed -- the moment the feature
+    became something people file tickets about, and a ticket about the marker
+    then declares a hold on itself (CodySwannGT/lisa#3815).
+
+    A declaration is POSITIONAL: the marker leads its line, behind at most the
+    decoration above, with fenced blocks and inline code spans removed first
+    because that is how the marker is written ABOUT. The same rule the intake
+    matcher applies, so the two surfaces cannot disagree about one body.
+
+    NOTE the direction here differs from the intake matcher's. There a match
+    HOLDS an item, so a false positive parks work. Here a match ADMITS a
+    filing, so a false positive is a hole -- which makes this the tightening
+    direction on both sides at once.
+
+    Args:
+        text: Any candidate text -- one argv value, a body file, a payload.
+
+    Returns:
+        True when some line of the text declares a hold.
+    """
+    if not text:
+        return False
+    body = HUMAN_GATE_CODE_SPAN.sub("", HUMAN_GATE_FENCE.sub("", str(text)))
+    for line in body.split("\n"):
+        if HUMAN_GATE_DECORATION.sub("", line, count=1).startswith(
+            HUMAN_GATE_MARKER
+        ):
+            return True
+        if _comment_carries_marker(line):
+            return True
+    return False
+
+
+def _comment_carries_marker(line):
+    """Whether an HTML comment on this line carries the marker.
+
+    The second accepted form, and the one this guard needs most: its inputs
+    are not markdown documents. A `--body` value is a single line, and a shell
+    script writes its declaration as `# <!-- ... -->`, so a purely
+    line-leading rule would refuse two declarations people have already
+    written -- both of which are in this repository's own test corpus.
+
+    It is not a loosening. An HTML comment is invisible when rendered, so
+    nobody wraps one around the marker in order to TALK about it; a quotation
+    has to be visible to be a quotation. Measured over this repository's 42
+    matching issue bodies, adding this branch changes not one verdict.
+
+    Args:
+        line: One line of text.
+
+    Returns:
+        True when some comment on the line contains the marker.
+    """
+    segments = line.split("<!--")
+    for segment in segments[1:]:
+        close = segment.find("-->")
+        inside = segment if close == -1 else segment[:close]
+        if HUMAN_GATE_MARKER in inside:
+            return True
+    return False
+
 # ---------------------------------------------------------------------------
 # WHY THIS IS A TOKEN SCAN AND NOT A PROGRAM RESOLVER
 #
@@ -580,7 +656,7 @@ LABEL_FLAGS = {"--label", "--labels", "--add-label", "--status", "--state"}
 #   None — container: state rolls up from children
 #
 # It is a marker with no other meaning, so it is matched wherever the payload
-# reaches — exactly the asymmetry `HUMAN_GATE_MARKER` gets, and for the same
+# reaches — the asymmetry `HUMAN_GATE_MARKER` gets, and for the related
 # reason. Reading the declaration the writer already emits is also what keeps
 # the guard and the skill from drifting apart a second time: there is one
 # string, defined in one rule, and both read it.
@@ -1223,7 +1299,7 @@ def text_declares_readiness(text):
     Returns:
         True when the text declares build-ready or a human gate.
     """
-    if HUMAN_GATE_MARKER in text:
+    if declares_human_gate(text):
         return True
     for role in (ready_role, upstream_ready_role, default_ready_role):
         if not role:
@@ -1267,7 +1343,7 @@ def scope_declaration(text, state_role_ok):
     Returns:
         True when the text carries a whole-scope declaration.
     """
-    if HUMAN_GATE_MARKER in text:
+    if declares_human_gate(text):
         return True
     return bool(state_role_ok and LIFECYCLE_ROLE_READY.search(text))
 
@@ -1497,20 +1573,23 @@ def declares_readiness(raw_args, roles, extra="", state_role_ok=False):
             candidates = [part.strip().strip("'\"") for part in raw.split(",")]
             if role in candidates:
                 return True
-    # The human-gate marker is matched anywhere, and that asymmetry is
-    # deliberate: it is a marker with no other meaning, so its presence in the
-    # title or body IS the declaration. The build-ready role is an ordinary
-    # string that appears in prose about the queue all the time.
-    if HUMAN_GATE_MARKER in " ".join(args):
+    # Checked per ARGV VALUE rather than against `" ".join(args)`, and that is
+    # what makes the positional rule mean anything here. Joining first destroys
+    # position: after a join, no value's line start survives except the first
+    # argument's, so "the marker leads its line" would be decided by argument
+    # order. A `--title` value is its own single line, which is exactly the
+    # unit the rule is about -- and titles must keep being read, since this
+    # guard reads them and the intake matcher does not.
+    if any(declares_human_gate(value) for value in args):
         return True
     for path in body_file_paths(args):
         try:
             with open(path, encoding="utf-8", errors="replace") as handle:
-                if HUMAN_GATE_MARKER in handle.read():
+                if declares_human_gate(handle.read()):
                     return True
         except OSError:
             continue
-    if extra and HUMAN_GATE_MARKER in extra:
+    if declares_human_gate(extra):
         return True
     # The state-based path. Scoped by `state_role_ok` rather than checked
     # unconditionally, so this adds a compliant command where none existed and

package/plugins/lisa-cursor/hooks/discharge-work-item-gates.sh

@@ -31,8 +31,14 @@ COMMAND="$(printf '%s' "$JSON_INPUT" | jq -r '.tool_input.command // empty' 2>/d
 
 # `gh pr create` opens one; `gh pr edit` is the other way a body comes to carry
 # — or lose — its declaration. Both change the answer to gate 4.
+#
+# `gh pr reopen` is here because a work item can hold more than one pull
+# request, and a reopened one is a named case: it was closed, so nothing has
+# discharged its gates since, and it is now live again with no CI run to reveal
+# that. Its backlink no longer displaces anyone else's, so re-running the
+# discharge for it is free (CodySwannGT/lisa#3916).
 case "$COMMAND" in
-  *"gh pr create"* | *"gh pr edit"*) ;;
+  *"gh pr create"* | *"gh pr edit"* | *"gh pr reopen"*) ;;
   *) exit 0 ;;
 esac
 

package/plugins/lisa-cursor/hooks/parity-safety-net.sh

@@ -26,6 +26,11 @@
 #     divergence: upstream blocks unconditionally; Lisa allows clean-tree resets.
 #     Residual risk (documented, accepted): the dirty check runs in the hook's
 #     cwd at hook time, so a `cd elsewhere && git reset --hard` evades it.
+#   - `git read-tree` with an update flag AND `--reset` while the working tree
+#     is dirty (issue #3978): the plumbing spelling of the same discard, on the
+#     same condition, printing the same remedy. Index-only `read-tree`, and
+#     `read-tree -m -u` without `--reset` (which git itself refuses rather than
+#     clobber a modified file), stay allowed. Lisa-only guard.
 #   - `git rebase --abort`/`--quit` while the in-progress rebase holds
 #     human-made conflict resolutions (AUTO_MERGE discriminator; issue #1956).
 #     Clean or untouched rebase state stays abortable; the apply backend and a
@@ -1819,6 +1824,45 @@ $DESTRUCTIVE_GUIDANCE"
   fi
 fi
 
+# 3a. `git read-tree` with BOTH an update flag and `--reset`, on the same dirty
+#     tree — the plumbing spelling of guard 3 (issue #3978). It resets the index
+#     and writes the result into the working tree, discarding tracked
+#     modifications: the identical destruction, reached through a command that
+#     carries no `--hard` and no `reset` subcommand, so every pattern in
+#     guard 3 misses it. A guard an agent can walk around is a guard that stops
+#     the honest caller and not the one looking for a way through, and this
+#     spelling is strictly worse than the blocked one — it discards WITHOUT
+#     preserving, which is exactly the property guard 3's remedy supplies. Both
+#     refusals therefore print the same $PRESERVE_GUIDANCE, so what they teach
+#     cannot drift apart.
+#
+#     `--reset` is the discriminator, not `-u`, and the pairing is deliberate:
+#
+#     - `read-tree` with no update flag touches the INDEX only and destroys
+#       nothing in the working tree, so a blanket `read-tree` block would be
+#       over-broad.
+#     - `read-tree -m -u` (a merge without `--reset`) is safe by git's own
+#       construction: it REFUSES rather than overwrite a locally modified file
+#       ("entry would be overwritten by merge"). `--reset` is precisely the flag
+#       that switches that refusal off.
+#
+#     So the destructive combination is an update flag AND `--reset` together,
+#     in either order. The update flag is matched in the checkout guard's idiom
+#     so a bundled short option (`-iu`) cannot dodge the anchor, with leading
+#     whitespace required so a `--index-output=/tmp/out-u` style value cannot
+#     read as the flag. Same conditional dirty-tree shape and same accepted
+#     residual risk as guard 3: the probe runs in the hook's cwd at hook time.
+readonly GIT_READ_TREE="${GIT_CMD}read-tree"
+if matches "${GIT_READ_TREE}"'[^;&|]*[[:space:]]--reset([[:space:]]|$)' \
+  && matches "${GIT_READ_TREE}"'[^;&|]*[[:space:]](-[[:alnum:]]*u[[:alnum:]]*|--update)([[:space:]]|=|$)'; then
+  if git rev-parse --is-inside-work-tree >/dev/null 2>&1 \
+    && [ -n "$(git status --porcelain 2>/dev/null)" ]; then
+    block "git read-tree -u --reset on a dirty working tree would discard uncommitted changes (commit first, or preserve as below)" "$PRESERVE_GUIDANCE
+
+$DESTRUCTIVE_GUIDANCE"
+  fi
+fi
+
 # 3b. `git rebase --abort` / `--quit` ONLY while human/agent conflict
 #     resolutions exist (issue #1956). `--abort` restores the pre-rebase branch
 #     and discards every resolution; `--quit` deletes the rebase bookkeeping

package/plugins/lisa-cursor/hooks/threshold-ratchet-families.mjs

@@ -72,6 +72,18 @@ export const FAMILIES = [
     match: /(^|\/)\.github\/k6\/thresholds\/[^/]+\.json$/,
     kind: "k6",
   },
+  {
+    // #3992. The always-on eager rule tier is concatenated into every session
+    // AND every subagent start, so its byte ceiling is a quality threshold like
+    // any other. `max` because the number is a ceiling: lowering it tightens the
+    // gate and is free, raising it re-authorises context the cleanup removed and
+    // is the change a human has to see. The tier was cut to 26,540 bytes once
+    // and regrew to 201,083 in fourteen weeks with nothing watching it.
+    id: "eager-rules",
+    match: /(^|\/)eager-rules\.thresholds\.json$/,
+    kind: "json-num",
+    direction: "max",
+  },
   {
     id: "lisa-config",
     match: /(^|\/)\.lisa\.config\.json$/,

package/plugins/lisa-cursor/rules/00-rule-index.mdc

@@ -0,0 +1,84 @@
+---
+description: "Rule Index — What Exists, and Where to Read It"
+alwaysApply: true
+---
+
+# Rule Index — What Exists, and Where to Read It
+
+The rules below are **not loaded**. Each is a full contract that other rules,
+skills, and work items cite **by slug** ("per the `bdd-e2e-coverage` rule").
+When you meet a slug and need the contract behind it, read that file — do not
+re-derive the contract, and do not restate it where you cite it.
+
+Read one when you are doing the thing it governs. Reading none of them is the
+normal case for a session, which is why they are here rather than in your
+context: the eager tier was cut to 26,540 bytes in May 2026 and had regrown to
+201,083 by September, at which point every session and **every subagent** paid
+~50,000 tokens before its first tool call (CodySwannGT/lisa#3992).
+
+Paths are relative to this file.
+
+## Work-item authoring, validation, and lifecycle
+
+| Slug | Read it when | Body |
+|---|---|---|
+| `work-item-definition-of-ready` | authoring or validating a leaf; gates S1–S16 | [../reference/work-item-definition-of-ready.md](work-item-definition-of-ready-reference.mdc) |
+| `leaf-only-lifecycle` | applying a lifecycle role, or rolling a parent up | [../reference/leaf-only-lifecycle.md](leaf-only-lifecycle-reference.mdc) |
+| `ready-role-filing` | filing any work item (enforced by `block-direct-issue-create.sh`) | [../reference/ready-role-filing.md](ready-role-filing-reference.mdc) |
+| `repo-scope-split` | a leaf spans repos; gate S10, decomposition step 1.5 | [../reference/repo-scope-split.md](repo-scope-split-reference.mdc) |
+| `derived-branch-plan` | rendering or validating a Branch Plan; gate S19 | [../reference/derived-branch-plan.md](derived-branch-plan-reference.mdc) |
+| `control-reachability` | an item names an existing test as a red-before-green control; gate S20 | [../reference/control-reachability.md](control-reachability-reference.mdc) |
+| `pre-flight-autofill` | the pre-flight gate returned FAIL on ticket quality | [../reference/pre-flight-autofill.md](pre-flight-autofill-reference.mdc) |
+| `blocker-containment` | deciding whether an `is blocked by` dependency is cleared | [../reference/blocker-containment.md](blocker-containment-reference.mdc) |
+| `deployed-state-readback` | authoring a ticket asserting something is missing from a running system | [../reference/deployed-state-readback.md](deployed-state-readback-reference.mdc) |
+| `prd-definition-of-ready` | authoring or validating a PRD's requirement atoms | [../reference/prd-definition-of-ready.md](prd-definition-of-ready-reference.mdc) |
+| `prd-lifecycle-rollup` | rolling a PRD up from its generated top-level work | [../reference/prd-lifecycle-rollup.md](prd-lifecycle-rollup-reference.mdc) |
+| `usage-accounting` | writing the managed `## Lisa Usage` section on an artifact | [../reference/usage-accounting.md](usage-accounting-reference.mdc) |
+
+## Build-intake claim time
+
+| Slug | Read it when | Body |
+|---|---|---|
+| `rejection-detection` | claiming a ready item (step 3b, before the relabel) | [../reference/rejection-detection.md](rejection-detection-reference.mdc) |
+| `claim-archaeology` | claiming a ready item, after rejection detection | [../reference/claim-archaeology.md](claim-archaeology-reference.mdc) |
+| `claim-time-guards` | claiming a ready item: already-implemented, two-failed-attempts | [../reference/claim-time-guards.md](claim-time-guards-reference.mdc) |
+
+## Coverage and evidence contracts
+
+| Slug | Read it when | Body |
+|---|---|---|
+| `bdd-e2e-coverage` | the work item adds or changes a user-observable surface | [../reference/bdd-e2e-coverage.md](bdd-e2e-coverage-reference.mdc) |
+| `reset-seed-coverage` | the work item adds or changes persistent state | [../reference/reset-seed-coverage.md](reset-seed-coverage-reference.mdc) |
+| `claim-evidence-mapping` | citing evidence for a claim, or reviewing evidence someone cited | [../reference/claim-evidence-mapping.md](claim-evidence-mapping-reference.mdc) |
+| `observability-audit` | running the `lisa-monitor` audit-and-file arm | [../reference/observability-audit.md](observability-audit-reference.mdc) |
+| `readiness-rubric` | judging whether an unattended fleet may run in a repository | [../reference/readiness-rubric.md](readiness-rubric-reference.mdc) |
+
+## Design
+
+| Slug | Read it when | Body |
+|---|---|---|
+| `design-value-binding` | implementing a UI surface in a project with a configured design source | [../reference/design-value-binding.md](design-value-binding-reference.mdc) |
+| `design-source-of-truth` | a change touches any UI surface | [../reference/design-source-of-truth.md](design-source-of-truth-reference.mdc) |
+
+## Dependencies
+
+| Slug | Read it when | Body |
+|---|---|---|
+| `dependency-trust-classes` | adding or major-upgrading a material dependency | [../reference/dependency-trust-classes.md](dependency-trust-classes-reference.mdc) |
+| `dependency-decision-records` | adding, upgrading, or removing a material dependency | [../reference/dependency-decision-records.md](dependency-decision-records-reference.mdc) |
+| `dependency-internalization-kit` | removing, replacing, or internalizing a dependency | [../reference/dependency-internalization-kit.md](dependency-internalization-kit-reference.mdc) |
+
+## Process, review, and access
+
+| Slug | Read it when | Body |
+|---|---|---|
+| `automation-runbook-contract` | registering a loop, or ending any flow with its run outcome | [../reference/automation-runbook-contract.md](automation-runbook-contract-reference.mdc) |
+| `convergent-review` | reviewing a PR or resolving review findings | [../reference/convergent-review.md](convergent-review-reference.mdc) |
+| `credential-substrate-precedence` | writing or editing an `*-access` skill | [../reference/credential-substrate-precedence.md](credential-substrate-precedence-reference.mdc) |
+| `promotion-contract` | implementing a learnings-ladder promotion ticket | [../reference/promotion-contract.md](promotion-contract-reference.mdc) |
+| `documentation-source-paths` | moving, absorbing, or deleting a docs-like directory | [../reference/documentation-source-paths.md](documentation-source-paths-reference.mdc) |
+| `project-learnings` | you need the learnings ledger's entry schema and field semantics | [../reference/project-learnings.md](project-learnings-reference.mdc) |
+| `factory-model` | you need the shape of the factory model, not its obligations | [../reference/factory-model.md](factory-model-reference.mdc) |
+
+The obligations that follow from `factory-model` are in `base-rules`, which is
+eager. This entry is the exposition behind them.

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

@@ -5,6 +5,103 @@ alwaysApply: false
 
 # Automation Runbook Contract
 
+> Demoted from the always-on eager tier by CodySwannGT/lisa#3992. The
+> section below is the former eager head, preserved verbatim; the full
+> contract follows it. Reachable on demand via `rules/eager/00-rule-index.md`.
+
+## Automation Runbook Contract (load-bearing)
+
+**Every registered automation loop carries a checked-in runbook, and every run of that loop ends in
+exactly one of six run outcomes** with a one-line, operator-readable summary. A registered loop with
+no runbook, or a run that stops without naming its outcome, is a contract violation.
+
+**One vendor-neutral contract, to be cited by (wired in the loop-conformance ticket)
+`lisa-setup-automations`, `lisa-automation-status`, `lisa-tear-down-automations`, and every
+registered loop skill** (the `leaf-only-lifecycle` / `repo-scope-split` precedent: one shared slug,
+never divergent per-loop prose).
+
+## Membership
+
+Membership is **registration, not skill-existence**: a loop is under this contract the moment it is
+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:
+**`nothing-needed | candidate-proposed | change-proved | approval-requested | recovery-required | policy-obsolete`**
+
+Health and operator action are **orthogonal** — a healthy run can still need an answer:
+
+- `nothing-needed` — the loop ran and found nothing to act on. **Healthy.** Operator action: none.
+  A queue scanner's `nothing-needed` summary must name the lanes it swept and the total open — a dry
+  queue and a wrong denominator are otherwise indistinguishable. See the reference body.
+- `candidate-proposed` — the loop proposed work (ticket, PRD, recommendation). **Healthy.** Operator
+  action: review the proposed item and flip it ready when you want it built.
+- `change-proved` — the loop made a change and proved it with evidence. **Healthy.** Operator
+  action: none (informational).
+- `approval-requested` — the loop reached a boundary it may not cross alone. **Healthy.** Operator
+  action: answer the approval question.
+- `recovery-required` — the loop itself could not complete (access, tooling, or substrate broken)
+  and escalated a decision-ready packet. **Not healthy.** Operator action: restore the named
+  capability, then close the escalation item.
+- `policy-obsolete` — the loop's own retirement policy (the retirement condition written in its
+  runbook) tripped, so it proposed its own teardown. **Healthy.** Operator action: approve the
+  teardown, decline it (close the proposal as **Not planned**; the loop keeps running at cadence),
+  or re-cadence it.
+
+## A run outcome is NOT a work-item lifecycle terminal state (CRITICAL)
+
+A **run outcome** describes the LOOP ITERATION. A **terminal state** describes a TICKET — Lisa
+already uses that phrase for work-item lifecycles (`lisa-intake`: "`Blocked` is a valid terminal
+state of the downstream lifecycles"). The two vocabularies never merge in an operator-facing report.
+A healthy cycle that routes a work item to `Blocked` with clarifying questions is
+`candidate-proposed` — it produced something — so it is **never `nothing-needed`**, which is
+reserved for runs that found nothing at all, and **never `recovery-required`**, which means the
+loop itself is broken, not that a work item was blocked.
+
+## No silent exit
+
+Every run — including a trivial early termination — ends by naming exactly one run outcome plus a
+one-line operator summary of what happened, recorded where the status surface can read it —
+there is no silent exit. The shared local substrate is
+`plugins/src/base/scripts/automation-run-record.mjs`, which writes bounded JSONL records under
+`.lisa/automations/runs/<loop-id>.jsonl`. Silence and health must never look identical to an
+operator.
+
+## Never block, always degrade
+
+A missing runbook, an unreadable record surface, or an absent optional dependency **degrades** the
+run — say so in the summary and finish with an outcome — it never crashes the loop, never blocks
+other work, and never leaves the run unreported.
+
+---
+
 Scheduled loops are the busiest machinery in the factory and historically the least explicitly
 contracted: what a loop maintains, what it may do on its own, what it must escalate, and when it
 should stop existing all lived implicitly in each loop's prose. The cost lands on the operator — a

package/plugins/lisa-cursor/rules/base-rules.mdc

@@ -7,6 +7,16 @@ alwaysApply: true
 
 These are mandatory disciplines that apply to every session. Full prose, JIRA dev-status query, ADF templates, etc. live in [reference/base-rules.md](base-rules-reference.mdc).
 
+## Factory Operating Mode
+
+You are factory machinery, not a chat assistant. Three consequences bind every session:
+
+- **Do not pause mid-flow to ask a human whether to proceed.** Handoff happens at the gates — the ready-role flips and intake's adversarial validation — never in the middle of a flow.
+- **Every flow must work headless**: no interactive prompts, idempotent re-runs, clean exits on empty queues. Flows run under native schedulers as often as under a human.
+- **Never weaken a gate to get work through it — fix the work.**
+
+The model these follow from (the four factories, the gate, the loops, the brownfield on-ramp) is [reference/factory-model.md](factory-model-reference.mdc); read it when you need the shape rather than the obligations.
+
 ## Requirement Verification
 
 Treat every request as potentially underspecified. Before starting any work:

package/plugins/lisa-cursor/rules/bdd-e2e-coverage-reference.mdc

@@ -5,6 +5,62 @@ alwaysApply: false
 
 # BDD Behavior Contract & E2E Coverage
 
+> Demoted from the always-on eager tier by CodySwannGT/lisa#3992. The
+> section below is the former eager head, preserved verbatim; the full
+> contract follows it. Reachable on demand via `rules/eager/00-rule-index.md`.
+
+## BDD Behavior Contract & E2E Coverage (load-bearing)
+
+**Every frontend work item ships its behavior as Gherkin scenarios with stable IDs, and seals each required scenario-platform obligation with aligned e2e automation in the project's configured runner for that platform.** A frontend change that adds no scenario, or a required scenario-platform obligation with neither a mapped test nor a dated waiver, is a contract violation.
+
+**One vendor-neutral contract, cited by** `lisa-research`, `lisa-acceptance-criteria`, `lisa-task-decomposition`, `lisa-test-strategy`, `lisa-tdd-implementation`, `lisa-implement`, `lisa-codify-verification`, `lisa-verification-lifecycle`, `lisa-spec-conformance`, and `lisa-verify` (the `leaf-only-lifecycle` / `repo-scope-split` precedent: one shared slug, never divergent per-skill prose).
+
+## Membership
+
+Membership is **surface, not repo name or ticket label**: a work item is frontend-type the moment it adds or changes something a user can observe — a screen, route, component, interaction, visual state, empty/error/loading state, navigation path, or copy a user reads. It applies on every platform the project ships. Backend-only, infrastructure, docs, tooling, and refactors with no user-observable delta are out; a refactor that changes what the user sees is in.
+
+## The contract lives in the repo
+
+Default locations (a project that already has an equivalent contract keeps its own paths and records them in `.lisa.config.json`):
+
+| Artifact | Default path | What it is |
+|---|---|---|
+| Scenarios | `bdd/features/*.feature` | Gherkin, the product-level behavior contract |
+| Coverage map | `bdd/coverage-map.json` | scenario → runner/platform/file/evidence mappings, plus waivers, per-runner test-discovery roots, and exclusions |
+| Generated matrix | `docs/bdd-scenario-matrix.md` | regenerated, never hand-edited |
+| Burndown | `docs/e2e-bdd-coverage.md` | current coverage per platform |
+
+## Scenario shape
+
+Every scenario carries **one stable `@BDD-<DOMAIN>-<NNN>` ID**, the platforms it requires (`@web`, `@ios`, `@android`, … as the project declares them), provenance (design node, ratified decision), and a tracker tag tying it to the work item that introduced or changed it. IDs are never renumbered or reused: behavior that stays user-observably the same keeps its ID through a rewrite; genuinely different behavior gets a new ID and the old one is marked `@superseded`.
+
+Lifecycle tag, exactly one or none:
+
+- **no tag** — ratified and required; it is in the coverage denominator.
+- **`@blocked`** — specified but awaiting a decision or dependency; the *product* does not do this yet.
+- **`@reference-only`** — intentionally not authoritative.
+- **`@superseded`** — replaced by a ratified rule or a newer scenario.
+
+The last three are out of the denominator. Deleting a committed capability to make coverage look better is a violation; mark it, do not drop it.
+
+## What seals a scenario
+
+Coverage is counted per **required scenario-platform obligation**, and an obligation is sealed only by **aligned e2e automation in the project's configured runner for that platform** — the runner→platform mapping is project configuration (e.g. a web runner covering `web`, a device runner covering `ios`/`android`), never named by this contract. A unit test, a route boot, a screenshot, a fixture, an API test, or a passing test on a *different* platform never seals an obligation: they prove something else. Each mapping names the runner, the platforms, the file, and the evidence string inside it, so the gate can prove the mapping still resolves.
+
+**The gate reads in both directions.** It also walks the test roots the project declares per runner, so an e2e test that exists but that the contract never mentions is a violation — map it to a scenario, or record an exclusion stating why it aligns to no product behavior. Roots are configuration: a subflow or helper directory left undeclared is structurally invisible, which is the same failure as having no gate for it.
+
+**Waivers are dated IOUs, never coverage.** An obligation whose runner genuinely cannot decide it today (no camera on the simulator, no request interception, no provisioned provider credential) is recorded with scenario, platforms, reason, and `recordedAt`. It leaves the denominator; it never counts as covered, and nothing about it asserts the behavior works. A waiver is invalid — and fails the gate — when it names a nonexistent scenario or an undeclared platform, covers an already-excluded scenario, or masks a scenario-platform that already has a mapping. Revisit a waiver when its reason dies.
+
+## Definition of done
+
+A frontend work item is not done until: (1) every user-facing behavior it adds or changes exists as a Gherkin scenario with a stable ID in the project's behavior contract, traceable to the work item; (2) every required scenario-platform obligation it introduces is either mapped to aligned e2e automation in the project's configured runner for that platform, or carries a dated waiver naming the runner limitation; and (3) the coverage gate passes and the generated matrix and burndown are regenerated and committed in the same PR. **Missing BDD coverage is a verification failure, not a warning** — it blocks completion exactly as a `PARTIAL` spec-conformance verdict does, and it is never demoted to "optional", "if cheap", or a follow-up without a linked build-ready ticket created before merge.
+
+## Bootstrap and degradation
+
+A project with no `bdd/` contract yet is not exempt — the first frontend work item scaffolds the minimum (features dir, coverage map with the project's detected runner→platform mapping, gate + matrix scripts) and covers **its own** behavior. It never backfills the whole app: pre-existing uncovered behavior is recorded as burndown, not treated as this item's blocker. If no e2e runner exists for a required platform at all, record the checked locations and the absence as the reason, exactly as the regression-spec absence path in `verification` does — a silent skip is never one of the exits.
+
+---
+
 Frontend behavior has historically been specified twice and owned nowhere: once as prose acceptance
 criteria on a ticket that closes and disappears, and once as whatever e2e tests someone had time to
 write. Neither survives the work item. The cost lands at verification time — nobody can answer "what

package/plugins/lisa-cursor/rules/blocker-containment-reference.mdc

@@ -5,6 +5,64 @@ alwaysApply: false
 
 # Blocker Containment
 
+> Demoted from the always-on eager tier by CodySwannGT/lisa#3992. The
+> section below is the former eager head, preserved verbatim; the full
+> contract follows it. Reachable on demand via `rules/eager/00-rule-index.md`.
+
+## Blocker Containment (load-bearing)
+
+**An `is blocked by` dependency is cleared by one fact only: the blocker's code is present on the branch the dependent will be built from.** A lifecycle status name — `done`, `on-stg`, `on-dev`, `code-review`, or any configured equivalent — is never that fact. It is a label that correlates with the fact in a single-trunk workflow and comes apart from it in a promotion workflow.
+
+**One vendor-neutral contract, cited by** `lisa-repair-intake` (Class A dependency clearing), `lisa-intake-explain` (dependency hold gate), and `lisa-ticket-triage` (Phase 1.5 open-blocker gate) — the `leaf-only-lifecycle` / `repo-scope-split` precedent: one shared slug, never divergent per-consumer prose.
+
+## Why a status name is the wrong test
+
+Where promotion runs `dev → staging → main`, `main` is the **trailing** branch. A blocker at `On Stg` is merged to `staging` and absent from `main`, so a dependent that builds from `main` does not have it. A blocker in `Code Review` is merged to nothing at all. The two failures are symmetric and both are live in the tree:
+
+- Test too **loosely** (any env-staged `done` clears) and a dependent is dispatched into work whose prerequisite is not on its branch. Nothing goes red; the item moves to `ready`, which is indistinguishable from a repair that worked.
+- Test too **strictly** (only the production terminal clears) and every dependent strands behind a blocker that is already merged where it matters.
+
+Containment is the one predicate that gets both right, because it asks the question the status name was standing in for.
+
+## The predicate
+
+1. **Resolve the dependent's base branch.** Take the dependent's `## Target Backend Environment` and map that exact key forward through `.lisa.config.json` `deploy.branches`, per `derived-branch-plan` and `config-resolution`. **Never read the rendered `Branch Plan` section as input** — `derived-branch-plan` forbids it; a surface needing the base branch derives it again.
+2. **Resolve the blocker's merge commit** — the commit that landed the blocker's PR.
+3. **Test ancestry on the remote:** is that commit an ancestor of the resolved base branch (`git merge-base --is-ancestor <sha> origin/<base>`)?
+4. **Cleared** iff the answer is yes. Otherwise **still blocking**.
+
+## Fail closed
+
+**Never fail open on an unresolvable ancestry check.** Any step that cannot be positively resolved leaves the dependency **blocking**, and the run record says which step failed:
+
+- no linked PR, or a PR that is not merged;
+- the blocker is inaccessible (deleted, cross-org, permission denied) — containment across repositories is not defined;
+- the dependent's environment is not derivable, maps non-uniquely, or maps to a branch absent from the remote;
+- the ancestry query itself fails.
+
+A false negative (left blocked) costs a cycle and is visible. A false positive (dispatched into a missing prerequisite) is invisible and surfaces days later as work begun before its dependency existed. Prefer the visible failure.
+
+## The one carve-out: a blocker with no code
+
+A dependency need not deliver code. A blocker **closed as completed** that positively declares no code deliverable — `Target Backend Environment: None — no runtime behavior change` (doc-only / config-only / type-only), no linked PR, no merge commit — is **cleared**, because there is no artifact whose location could matter.
+
+This requires a **positive determination**, never an absence. "I could not find a PR" is fail-closed under the rule above; "the item declares it ships no code" is this carve-out. Collapsing the two turns the carve-out into a universal bypass.
+
+## Ancestry answers a development question, not a deployment one
+
+This rule requires an ancestry test. `deployed-state-readback` says ancestry is **never** evidence of deployment. Both are correct — they answer different questions:
+
+- **Here:** *is the blocker's code on the branch I will build from?* An `is blocked by` link is a **development** dependency, satisfied once the code is on your base branch. Ancestry is the right test, and waiting for production strands dependents.
+- **There:** *is this thing live?* A commit can be an ancestor of the default branch and never have shipped — a discarded pipeline execution leaves it merged and undeployed. Ancestry is provably insufficient.
+
+Never use this rule's test to answer a "does it already exist in the environment?" question.
+
+## Human override
+
+A human statement on the item that the dependency is satisfied clears it, and outranks a failed containment check. Record it as the reason in the run record. This is the escape hatch for cross-repo and untracked dependencies, and it is the only one. An automation may never synthesize one on its own behalf.
+
+---
+
 An `is blocked by` link is a **development** dependency. It asks one question: *does the dependent have the blocker's code on the branch it will be built from?* This rule makes that the test, replacing the lifecycle-status-name checks that three Lisa surfaces had each grown independently.
 
 It is a **single vendor-neutral contract** consumed by `lisa-repair-intake` (Class A dependency clearing), `lisa-intake-explain` (dependency hold gate), and `lisa-ticket-triage` (Phase 1.5 open-blocker gate). Each cites this slug rather than re-implementing the test, exactly as they cite `leaf-only-lifecycle` and `repo-scope-split`. That is what keeps the three from drifting apart again.