@codyswann/lisa 4.49.0 → 4.50.1

package/plugins/lisa-cursor/rules/reset-seed-coverage.mdc

@@ -1,55 +0,0 @@
----
-description: "Reset/Seed Coverage & State Classification (load-bearing)"
-alwaysApply: true
----
-
-# Reset/Seed Coverage & State Classification (load-bearing)
-
-**Every persistent entity a project owns carries exactly one declared reset policy, and a work item that adds or changes persistent state is not done until the reset/seed contract covers it.** An entity the running system holds but the contract does not classify is a contract violation, and the check that finds it **fails closed** — an unclassified entity is never treated as safe to keep and never treated as safe to delete.
-
-**One vendor-neutral contract, cited by** `lisa-research`, `lisa-acceptance-criteria`, `lisa-task-decomposition`, `lisa-test-strategy`, `lisa-implement`, `lisa-codify-verification`, `lisa-verification-lifecycle`, and `lisa-verify` (the `leaf-only-lifecycle` / `repo-scope-split` precedent: one shared slug, never divergent per-skill prose). It never names a database engine, cloud, identity provider, or test runner — those are project configuration.
-
-## Why this exists
-
-Test suites create state. Without a contract, cleanup is a habit: a flow creates a uniquely-marked record and deletes it on the happy path only, so every early failure leaks one more. Nothing sweeps it, nothing complains, and the suite degrades until someone reads a flake as a product bug. The observed shape is always the same — leaked records accumulate silently until a list view, a uniqueness constraint, or a count assertion breaks. Per-flow self-cleanup is not coverage; it is the failure mode.
-
-## Membership
-
-Membership is **state, not repo name, ticket label, or storage engine**: an entity is in scope the moment something the project writes **outlives the process that wrote it**. That includes rows and tables, but rows are only one kind of state. Also in scope: identity-provider objects (accounts, groups, memberships, sessions), object storage (buckets, prefixes, uploaded files), search indexes, queues and topics (in-flight and dead-letter), caches with a persistence tier, materialized/derived views and projections, feature-flag and configuration overrides, scheduled jobs created at runtime, and analytics or third-party side effects a run leaves behind. Out of scope: values that live only in memory for the duration of one process.
-
-A work item is in scope when it **adds** such an entity, **changes what owns or writes** one, or **changes the lifetime** of one. Renames count as changes, not as new entities plus deletions.
-
-## The four policies
-
-Every entity is classified as exactly one of:
-
-- **`fixture-owned`** — the reset may create, mutate, and delete rows here, but only those it owns. Ownership is declared as a predicate (a reserved id shape, a reserved account or namespace, a marker attribute), never as "everything in this entity."
-- **`preserve`** — the reset must leave this untouched. Catalog, reference data, anything a migration seeds, anything expensive or impossible to rebuild, and any state belonging to someone who is not the fixture.
-- **`derived-rebuild`** — not authored by anyone; recomputed from its sources after the reset (projections, materialized views, search indexes, caches). The reset rebuilds it rather than clearing or preserving it, and proves it converged.
-- **`forbidden`** — the reset must be structurally unable to touch it: ledgers, payments, wallets, withdrawals, audit trails, anything irreversible. Declaring `forbidden` obliges naming the enforcement outside the script — a least-privilege role, a revoked grant, a separate account or credential boundary — because a script-only promise dies in the refactor that drops the safe caller.
-
-**Classify by provenance, never by observation.** "The table looked empty" is not evidence it is unused; runtime statistics are approximations, and a table that has never been analyzed reports rows it holds. Ask who writes it and whether anything can put it back.
-
-## Keep-lists are a detector, not the safety model
-
-Deriving the clear-list by subtracting a keep-list from a schema listing is a **useful detector** — run it, and let it flag entities the contract has not seen. It is not the boundary. It cannot model renames, multiple schemas, framework-generated entities, views, partitions, row-level ownership, or any of the non-DB state above, and "new entities are cleared unless exempted" erases unrelated data the first time something adds one. The boundary is the classification; subtraction only tells you the classification is stale.
-
-## Required assurances
-
-A reset contract is not complete until it declares, and points at evidence for, all of: non-fixture and catalog data survive; reserved fixture identifiers are rejected on collision with anything real; foreign references into preserved entities are refused rather than cascaded; every write is **acknowledged** (a mutation reported by the caller and not confirmed by the system is a failure, not a success); a second apply converges to the same state and reports no further change; the post-state is verified by **exact expected counts**, not "at least one"; and production fails closed with no override of any kind. Where the platform can enforce a boundary with roles, grants, or constraints, it does — the in-process guard remains as defense in depth, never as the primary control.
-
-## Definition of done
-
-A work item that adds or changes persistent state is not done until: (1) every entity it introduces or changes is classified in the project's state contract with a reason and an owner; (2) `fixture-owned` entities it introduces declare their ownership predicate **and** are actually swept by the reset — an entity a suite creates but nothing removes is the leak this rule exists to prevent; (3) `preserve`/`forbidden` entities it introduces name their enforcement; (4) any seed the suite depends on covers the new state, with the verify step asserting exact counts; and (5) the state-classification check passes in the same PR. **A missing or stale classification is a verification failure, not a warning** — it blocks completion exactly as a `PARTIAL` spec-conformance verdict does, and is never demoted to "optional", "if cheap", or a follow-up without a linked build-ready ticket created before merge.
-
-## Bootstrap, noop, and degradation
-
-A project with no state contract yet is not exempt: the first work item touching persistent state scaffolds the minimum (the contract file, its own entities classified, the check wired into CI) and covers **its own** state. It never backfills the whole system — pre-existing unclassified entities are recorded as burndown with an owner and a date, not treated as this item's blocker. A project that genuinely holds no persistent state declares a **machine-readable noop** (`mode: "declared-noop"` with reason, owner, and a capability-manifest reference) which the check verifies against the repo rather than taking on faith — a bare exit 0 is indistinguishable from a successful destructive run and never satisfies this rule. A project that cannot produce a runtime inventory records the checked sources and the absence, exactly as the regression-spec absence path in `verification` does; a silent skip is never one of the exits.
-
-## Command envelope
-
-Every reset, seed, verify, inventory, and classification adapter answers the **same interface** — one validated JSON result on stdout, exit 0 only when the operation both completed **and** verified, `--dry-run` mandatory before anything destructive, and a requested stage always re-checked against server-resolved identity rather than trusted. The envelope is specified in the reference body and is what makes "every repo answers the same question the same way" checkable instead of aspirational.
-
-**The production arm of this is executable, not advisory.** `scripts/lisa-destructive-guard.mjs` ships to every adopter and is wired into the envelope itself: a destructive run against a production-resolved — or unresolvable — environment has **no representable success envelope**, so it can never exit 0, and there is no parameter, field, or environment variable anywhere in the guard that changes the answer. A dry run is not an exemption, and `--dry-run` is the default rather than an opt-in. Read this as what it is: a check at the one interface every adapter passes through, which an adapter that misreports its own environment still defeats. The end state is a destructive capability that is **not deployed to production at all** — non-existence beats refusal — and that design, with the failure modes it must still close, is recorded in `docs/design/reset-production-absence.md`.
-
-Full contract (state-contract schema, check semantics, detectors, envelope schema, enforcement patterns, bootstrap procedure): [reference/reset-seed-coverage.md](reset-seed-coverage-reference.mdc).

package/plugins/lisa-cursor/rules/usage-accounting.mdc

@@ -1,38 +0,0 @@
----
-description: "Usage Accounting (load-bearing)"
-alwaysApply: true
----
-
-# Usage Accounting (load-bearing)
-
-Lisa attaches AI usage and cost telemetry to every artifact it creates/updates. The format is a single canonical managed section.
-
-## Managed section
-
-Every artifact with inline body content gets exactly one section:
-
-```markdown
-## Lisa Usage
-```
-
-**Canonical. Rewrite in place; never append a second usage section.** If the host can't safely edit body, write the same section in a comment and treat that comment as the managed artifact for future rewrites.
-
-## Required field semantics
-
-Each direct entry records ONE logical Lisa run on ONE artifact. `entry_id` is the stable dedupe key — rewriting the same logical run with the same `entry_id` updates in place; a different run gets a different `entry_id`.
-
-- **`source`**: `observed` (runtime supplied) / `estimated` (derived from trustworthy metadata + pricing contract) / `measured-subset` (a trustworthy subtotal exists, but the complete run total is unknown) / `unavailable`.
-- **`measured_subset_tokens`**: optional measured subtotal for `measured-subset` entries only. Omission is normalized to `null` for backward-compatible callers. Keep `total_tokens = null` so rollups do not treat a subset as a complete total.
-- **`pricing_status`**: same trinary plus `missing` (cost not known but should be).
-- **Absence ≠ zero.** `null` means unknown; `0` means explicitly zero. Always write the entry — never silently omit.
-- Do NOT replace observed counts with estimates.
-
-## Rollup
-
-Container artifacts (Epic, PRD, etc.) roll up usage from their direct children. Roll-up is recursive — a parent's `## Lisa Usage` aggregates its descendants' direct entries. Re-writes are idempotent: re-running an intake or lifecycle skill must not duplicate entries.
-
-Measured-child incompleteness is durable across ordinary rewrites through the optional
-`lisa:usage-rollup-token-status` extension. Do not infer completeness merely because a rewrite did
-not re-fetch child ledgers.
-
-Full schema (backward-compatible 17-field primary marker, correlated measured-subset extension, pricing semantics, rollup math, idempotent-migration rules): [reference/usage-accounting.md](usage-accounting-reference.mdc).

package/plugins/lisa-cursor/rules/work-item-definition-of-ready.mdc

@@ -1,32 +0,0 @@
----
-description: "Work-Item Definition of Ready (type-keyed)"
-alwaysApply: true
----
-
-# Work-Item Definition of Ready (type-keyed)
-
-**`ready` means: a stateless agent can claim this item and drive it to its terminal state with zero human clarification.** Every readiness gate exists because its absence forces a question; the bar is type-keyed because different work types break autonomy differently.
-
-## Shared core (every leaf, enforced by `*-validate-*` S1–S16)
-
-Three-audience description · Gherkin acceptance criteria (except Spike) · Out of Scope · single-repo scope · relationship search · typed evidence manifest on runtime changes · Source Requirement traceability when PRD-sourced · provable read access to every named external surface · declared reachability for any **existing** test the item pins as a red-before-green control (`control-reachability`, gate S20 — `N/A` when the item introduces a new test instead).
-
-## Per-type additions
-
-| Type | Must additionally carry | Terminal state is |
-|---|---|---|
-| **Bug** | agent-executable reproduction (or a failing test) · expected-vs-actual with the *source* of "expected" · environment + version observed, last-known-good when known · reproducibility rate (always / intermittent + frequency) · at least one occurrence evidence link | the same repro/test fails before the fix and passes after |
-| **Story** | user-visible AC; SHOULD name non-happy-path states (error / empty / loading) for UI stories · design source precedence when artifacts exist | every AC exercised on the running product |
-| **Task** | an observable done-state and the command/check that proves it | the verification check passes |
-| **Improvement** | metric + measurement method the agent can run · measured baseline value · numeric target | measured value meets the target |
-| **Spike** | the question · the decision it enables + options weighed · a timebox · deliverable format **and location** | a deliverable at the named location that answers the question — findings, decision, options weighed |
-| **Sub-task** | a parent, always · otherwise the bar of its own type | per its type |
-| **Epic / container** | never build-ready (`leaf-only-lifecycle`) · judged on decomposition completeness, not buildability | all required children terminal |
-
-## The stateless-pickup test (S18)
-
-The final gate checks the property itself instead of proxies for it: read the item as a fresh agent with no session context, using only the item and what it links to. List every question you would have to ask a human before starting, choosing between materially different implementations, or declaring done. **Ready = zero questions.** Each question found is the FAIL remediation, verbatim.
-
-Sources this bar distills: INVEST (stories) · ISTQB / IEEE 1044 defect anatomy and minimal-reproducible-example practice (bugs) · SMART (improvements) · Scrum's Definition of Ready (the framing) · TASC AC8.6 (the normative criterion).
-
-Full rationale and worked examples: [the reference body of this rule](work-item-definition-of-ready-reference.mdc).

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

@@ -1,92 +0,0 @@
-# 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.
-
-Full contract (template, outcome definitions, escalation packet, retirement): [reference/automation-runbook-contract.md](../reference/automation-runbook-contract.md).

package/plugins/src/base/rules/eager/bdd-e2e-coverage.md

@@ -1,51 +0,0 @@
-# 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.
-
-Full contract (coverage-map schema, gate semantics, bootstrap procedure, per-flow obligations): [reference/bdd-e2e-coverage.md](../reference/bdd-e2e-coverage.md).

package/plugins/src/base/rules/eager/blocker-containment.md

@@ -1,53 +0,0 @@
-# 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.
-
-Full contract (resolution steps, per-vendor merge-commit bindings, the fail-closed reason-key table, the no-code carve-out's three conditions, and what this rule deliberately does not do): [reference/blocker-containment.md](../reference/blocker-containment.md).

package/plugins/src/base/rules/eager/claim-archaeology.md

@@ -1,37 +0,0 @@
-# Claim-Time Archaeology (load-bearing)
-
-Lisa lifecycles are one-way — a done issue never reopens, so a residual failure comes back as a **new** issue with no visible link to the issue that shipped it. Archaeology recovers that link at claim time: the claiming agent learns it is working on round 2 of a past failure, and what specifically went wrong the first time.
-
-**One vendor-neutral contract, cited by every build-intake arm** (the `leaf-only-lifecycle` / `repo-scope-split` / `rejection-detection` precedent: one shared slug, never three divergent implementations).
-
-## When it runs
-
-In build-intake step 3b, **AFTER the rejection-detection classification and BEFORE the relabel/transition** `$READY → $CLAIMED`. Rejection detection runs first; its classification is an **input** to archaeology — a detected `rejection-reclaim` passes straight through, never re-derived.
-
-## Classify the claimed item
-
-Return exactly one of:
-
-- **`rejection-reclaim`** — taken directly from the `rejection-detection` result. Reuse it; do not re-derive.
-- **`retry-of-done-issue`** — an ancestry signal names a closed done issue whose shipped work this issue exists to fix.
-- **`fresh`** — no ancestor found, signals weak/inconclusive, budget exhausted, or the pass errored. The default and the safe degrade.
-
-## Ancestry signals (summary — full bindings in the reference body)
-
-1. **Tracker metadata** — the typed relations the read skills already parse (Blocks / Blocked by / Relates to / Duplicates / Cloned from, `closingIssuesReferences`, cross-references).
-2. **Text similarity** — tracker search primitives over recently-closed issues touching the same implicated files, ranked by title/label overlap. Lexical only; no embedding machinery exists.
-3. **Git ancestry** — deterministic `git log --follow` / `git blame` / merge-commit queries yielding a parseable `{file, sha, pr, date}` result. Never delegate this to the prose-report `git-history-analyzer` agent.
-
-## Learning-loop exclusion (scan-side)
-
-An artifact this flow produced is **never** an ancestor. Exclude anything carrying `[lisa-learning-drop]`, `[lisa-learning-pr]`, `[lisa-learning-upstream-handoff]`, `[lisa-rejection-candidate]`, or `[lisa-archaeology-candidate]` markers, or the `learning:needs-triage` label.
-
-## Cost budget — never block the claim
-
-The pass runs inside a hard budget: `.lisa.config.json` `archaeology.maxSteps` (default **8** tracker/git queries; optional `archaeology.maxSeconds`). Budget exhausted, weak signals, or an exception → classify `fresh` and proceed. Archaeology is a bonus layered on the claim; it **never blocks the claim**. Exceeding the budget degrades to `fresh` — a normal outcome, not an error.
-
-## On `retry-of-done-issue`
-
-Reconstruct what the ancestor's PR shipped (merged PR, review threads, evidence comments) and derive **ONE** candidate learning citing the **delta** between what was done and what this issue proves was needed — routed to `lisa-persist-learning` exactly like the rejection-reflection path. Fallback when that skill is absent: a comment with a visible prose line plus `<!-- [lisa-archaeology-candidate] key=<issue>::<ancestor> -->` (marker-dedupe; re-claims produce no duplicate). `fresh` → no candidate, zero comments.
-
-Full contract (signal bindings, classification table, candidate derivation, budget mechanics): [reference/claim-archaeology.md](../reference/claim-archaeology.md).

package/plugins/src/base/rules/eager/claim-evidence-mapping.md

@@ -1,78 +0,0 @@
-# Claim → Evidence Mapping Contract (load-bearing)
-
-**Every claim about the software declares a boundary, and a claim is established only by evidence of
-a kind that reaches that boundary.** Unit tests are a quality prerequisite, not a claim discharger:
-a passing unit `test-run-log` reaches only the **code-unit** boundary. Citing evidence whose *kind*
-does not reach a claim's *boundary* — a unit log offered as proof that a button works in the browser
-— is a contract violation, and a review-rejectable defect.
-
-## The claim-boundary taxonomy (closed set)
-
-Every claim binds to exactly one boundary, and each boundary is discharged only by evidence of the
-kind(s) that reach it. The boundaries and their establishing evidence kinds are seeded verbatim from
-the `verification` rule's artifact-type taxonomy — no new vocabulary is invented here:
-
-- **`code-unit`** — pure-logic behavior in isolation → unit `test-run-log`. Reaches no boundary
-  below it.
-- **`browser`** — user-visible UI behavior → `screenshot`, `recording`. **Never** a unit
-  `test-run-log`.
-- **`http-api`** — request/response contract → `http-transcript`. **Never** a unit `test-run-log`.
-- **`cli`** — command behavior → `cli-output`.
-- **`data`** — persisted state → `db-query-output`, `state-dump`.
-- **`deploy-health`** — a healthy running deployment → `deploy-log`. **Never** any pre-deploy
-  artifact.
-- **`performance`** — latency/throughput/frame timing → `perf-trace` (with methodology).
-- **`standards-compat`** — conformance to an external standard → `cli-output` / `test-run-log` from
-  the compat runner.
-
-## The core inequality
-
-**unit tests ≠ browser behavior ≠ healthy deployment ≠ standards compatibility.** Each is a distinct
-boundary; evidence at one never discharges a claim at another. "Verified" must name the boundary its
-evidence actually reaches, so a report read at the gate states its own limits (`factory-model`
-rule 5).
-
-## Field names (fixed here, made executable later)
-
-A claim carries three fields — `claim_id`, `boundary`, and `required_evidence_kinds` — named here so
-every downstream surface uses one spelling. This ticket only writes the contract down; the schema and
-gate that make these fields executable ship with **BCE-2 (#1836)** — do not assume that surface is
-present in this branch.
-
-## Security buckets (conservative by default)
-
-A security finding is **proven** only with both a reproducer of a reaching kind and a bounded
-impact/exploitability statement; missing either, it renders **unproven** with its reason and **stays
-in the security section** — never auto-demoted to maintenance. The label is one policy point,
-`security.review.unprovenBucket` (default `security-unproven`); the procedure lives in the
-`lisa-security-review` skill.
-
-## Artifact identity (pinned, never assumed)
-
-A claim applies only to the artifact its evidence was collected against. Every verdict pins
-`artifact.head_sha` — the commit the run observed — and every evidence entry pins the
-`artifact_head_sha` in force when it was captured, its `sha256` content digest, and `captured_at`.
-Evidence collected on a pre-merge head is valid for the merge commit **only** when that head is a
-parent of the merge, per the ancestry + deploy-run definition of "what shipped" that
-`lisa-drive-pr-to-merge` already owns — cite it, never write a second one. A mismatched SHA or a
-recomputed digest that disagrees fails loudly, naming both SHAs / the evidence id, and verification
-re-runs against the merged head before completion is declared. Full definition: the reference body.
-
-## Not established (required, never omitted)
-
-A claim with no reaching evidence is **Not established**, and every report says so out loud. Each
-evidence comment and verdict carries a `Not established` section listing what was *not* proved —
-boundaries not exercised, environments not tested, behavior consciously out of scope. It is never
-omitted and never blank: with nothing outstanding it still renders `None outstanding — reviewed`, and
-`not_established_reviewed` attests the list was reviewed even when the list itself is empty. This
-generalizes the required, never-empty `Known limits` field of `lisa-improve-harness`. Full definition
-and operator-voice exemplars: the reference body.
-
-## No behavior change; degrade, never block
-
-This rule is documentation, not a gate: it changes no schema, no skill, and no check. Where a later
-surface it names is not yet installed, cite the boundary a claim reaches and continue — never block
-on the absent surface. Read the contract to someone who has never seen Lisa and they should be able
-to say why a unit-test log does not prove a button works in the browser.
-
-Full contract (claim-boundary taxonomy, core inequality, worked example, field names): [reference/claim-evidence-mapping.md](../reference/claim-evidence-mapping.md).

package/plugins/src/base/rules/eager/claim-time-guards.md

@@ -1,32 +0,0 @@
-# Claim-Time Guards (load-bearing)
-
-Two guards that run when build-intake claims a ready item, both from failures observed in the fleet: an item built twice because it had already shipped, and a loop burning cycles re-attempting an item that was never going to succeed.
-
-**One vendor-neutral contract, cited by every build-intake arm** (the `leaf-only-lifecycle` / `repo-scope-split` / `rejection-detection` / `claim-archaeology` precedent: one shared slug, never three divergent implementations).
-
-## When they run
-
-Inside build-intake step `3b`, after `rejection-detection` and `claim-archaeology`, still before the `$READY → $CLAIMED` transition. The `two-failed-attempts` valve runs first — it is cheaper and it is the only pass that can stop the claim outright.
-
-## `already-implemented` → `verify-and-close`
-
-A ready item may already be implemented, because agents ship without transitioning. Before implementing, probe for the item's **own** key:
-
-```bash
-git log --all --grep "<key>" --format='%H %aI %s' -n 10
-gh pr list --repo <org>/<repo> --state all --search "<key>" --json number,state,mergedAt,url
-```
-
-On a hit, do not build it twice — switch `3c` to **verify-and-close**: verify what shipped against this item's acceptance criteria, post evidence naming the shipping PR/commit, then run the ordinary `3d` transition and rollup. If the shipped change only partially satisfies the criteria, implement the remaining gap instead of closing.
-
-Distinct from `claim-archaeology` (finds a **different** ancestor issue) and from `DUPLICATE_ALREADY_FIXED` (a **different** canonical issue). Unreadable history degrades to "no hit"; the guard never blocks the claim.
-
-## `two-failed-attempts` → blocked
-
-Every non-success terminal outcome records a durable marker on the item — a visible line plus `<!-- [lisa-build-attempt] n=<N> outcome=<outcome> measures=<work|machine> -->` (match on the marker, never the title). A cron holds no memory between cycles, so the item carries the count.
-
-**Two filters before counting.** Count a marker only when it is `measures=work` — a run terminated by a signal, or whose outcome was `recovery-required`, measures the box and not the item — and only when it was recorded **after the item most recently entered the ready lane**. An unlabelled marker counts as `work`; an unreadable lane history falls back to counting every `work` marker. Both defaults keep the valve shut rather than open (CodySwannGT/lisa#3854).
-
-With **two or more** surviving markers at claim time: do not claim. Move the item to the configured `blocked` role (resolved per `config-resolution`, never hardcoded), post an operator-readable comment naming both attempts and what a human must decide or supply, and **stop the loop** for this cycle. Recovery is deliberate and it works — a human or a `lisa-repair-intake` cycle with the blocker provably cleared returns it to the queue, which ends the period the old markers describe without deleting them.
-
-Full contract (probe bounds, verify-and-close steps, partial-hit handling, marker mechanics): [reference/claim-time-guards.md](../reference/claim-time-guards.md).

package/plugins/src/base/rules/eager/control-reachability.md

@@ -1,39 +0,0 @@
-# Control Reachability — A Prescribed Control Must Reach the Changed Path (load-bearing)
-
-A work item may hand the implementer a falsifiable stopping rule: *"make the change; `<named existing test>` must go red. If it still passes, the fix did nothing."* That is good practice — it replaces eyeballing with an observation. It is also **only valid if that test's fixture exercises the path the change touches.**
-
-When it does not, the test stays green **for a reason unrelated to the change**: execution never reached the changed code. The stopping rule then instructs the implementer to revert a correct fix, and the more faithfully the implementer follows the item, the more reliably it happens. Measured once in the portfolio: a pinned test's fixture omitted the field the fix read, execution fell through to a default branch, the test stayed green, and the fix had worked.
-
-This is the specification-side sibling of `falsifiable-checks`, which governs a check *you authored*. Here the check is **prescribed by the work item** and the defect is in the prose, not the code.
-
-## Authoring obligation — checkable, not advisory
-
-**A work item that names an existing test as a red-before-green control must say what makes that test reach the code the change touches.** Naming the code is not enough; the item names the *input*.
-
-Declare it in `## Validation Journey`, one marker per named control:
-
-```text
-[CONTROL: <test-identifier> | reaches: <input-or-field>]
-```
-
-- `<test-identifier>` — non-empty: the test file path, the test name, or both.
-- `reaches:` — the literal key, then the **input, field, fixture key, argument, or state** that carries execution into the changed code. `reaches: the fix` and `reaches: the changed code` restate the assertion and do not satisfy it.
-
-Enforced by gate **S20** in `lisa-jira-validate-ticket`, `lisa-github-validate-issue`, and `lisa-linear-validate-issue`; rendered by `lisa-jira-write-ticket`, `lisa-github-write-issue`, and `lisa-linear-write-issue`; read at claim time by `lisa-ticket-triage` and `lisa-implement`.
-
-**An item that prescribes no existing-test control is exempt.** Introducing a *new* test carries no reachability obligation — the gate is `N/A` and the item is never reported as incomplete on this basis.
-
-## Implementer obligation — a green control is two facts, not one
-
-`lisa-tdd-implementation` and `lisa-reproduce-bug` bind this arm: **when a prescribed control does not change state as the item predicted, stop. Establish which cause holds before acting on the stopping rule.**
-
-| Cause | Correct action |
-|---|---|
-| The change had no effect on behaviour | Revisit the change |
-| The fixture never reaches the changed code path | Fix or extend the control — do **not** revert |
-
-They demand opposite actions, and the cheaper reading ("the fix did nothing") wins by default when nothing forces the distinction. So force it: **prove reachability by execution, never by reading the fixture.** Put a temporary throw, log line, or counter in the changed code and run that one test; or run coverage scoped to it and read whether the changed lines were hit. Reasoning that the fixture *looks like* it reaches the path is the same move `falsifiable-checks` rejects as "mentally reverting".
-
-**Never revert on an unexplained green.** An unexplained control is a blocked observation, not a verdict — and a reachable-but-still-green control is the only form of it that licenses revisiting the change.
-
-Full prose, the worked instance, and the reporting template: [reference/control-reachability.md](../reference/control-reachability.md).

package/plugins/src/base/rules/eager/convergent-review.md

@@ -1,24 +0,0 @@
-# Convergent Review
-
-Review exists to get correct work merged, not to keep a PR in review orbit.
-
-- Block only concrete correctness, security, data-loss, or contract-violation
-  failures. Lint-owned style, formatting, taste, and speculative improvements
-  are non-blocking unless the work item or repository rules make them release
-  criteria.
-- Every finding must state severity, blocking yes/no, a concrete failure
-  scenario, evidence, and the smallest actionable fix — plus
-  `invariant_violated` (the property at risk) and `machinery_to_remove` (what
-  becomes deletable, or `none`), required for `readiness-rubric` findings and
-  recommended elsewhere.
-- Present findings highest-consequence first, by severity and blast radius, not
-  by discovery order. Report section order stays stable.
-- A blocking finding without a concrete failure scenario is malformed by
-  contract; downgrade it to non-blocking and ask for evidence.
-- Resolve each finding as `fixed`, `deferred`, or `pushed-back`. If the reviewer
-  cannot refute a pushback with fresh evidence, the author's disposition stands.
-- After suggestion implementation completes and gates pass, review does not
-  reopen absent new evidence: a relevant new commit, a failed gate, a newly cited
-  failure scenario, or a scope change.
-- Irreconcilable blocking disagreement becomes a blocked work item with both
-  positions summarized for the operator, not an endless loop.

package/plugins/src/base/rules/eager/credential-substrate-precedence.md

@@ -1,54 +0,0 @@
-# Credential-Substrate Precedence (load-bearing)
-
-**When more than one substrate can reach an external system, the configured credentials
-provider's token/CLI path goes first and the interactive MCP is the fallback — and
-identity-match verification is mandatory on every substrate, at every tier.**
-
-**One shared, vendor-neutral contract cited by every `*-access` skill** (the
-`leaf-only-lifecycle` / `repo-scope-split` precedent: one shared slug, never divergent
-per-skill prose). An access skill states its per-vendor mechanics — which token, which
-CLI, which identity anchor — and cites this rule for the ordering. It never restates,
-narrows, or locally overrides that ordering.
-
-Settled by decision record `2026-08-12-credential-substrate-precedence` (D6), and
-settled in the `settled-decisions` sense: re-arguing MCP-first inside a skill is out of
-scope for that skill's work.
-
-## The ladder
-
-1. **Tier 1 — configured-provider substrate.** The token or CLI path fed by
-   `lisa-secrets-access`, chosen whenever its bootstrap credential is available **and**
-   the resolved substrate identity-matches the configured tenant/workspace/site.
-   `lisa-secrets-access` is the single chokepoint — never read an OS keychain a second
-   time. The two legacy OS-keychain rungs that remain (`lisa-atlassian-access`,
-   `lisa-notion-access`) are a dated migration ramp with a **removal date of
-   2026-11-01**, not a standing exemption; no new access skill may add one.
-2. **Tier 2 — interactive MCP**, used only when tier 1 is *genuinely* unavailable:
-   no bootstrap, no adapter for the operation (per-operation, not per-session), or a
-   provider outage. "The MCP happens to be authenticated" and "tier 1 is slower" are
-   **not** qualifying reasons.
-3. **Tier 3 — loud, actionable failure** naming the exact credential to set and the exact
-   remediation. Never silently no-op, never blind-retry a failed or absent substrate,
-   never fall through to one that failed identity-match.
-
-## Identity-match is mandatory on every substrate
-
-Verified **in both directions** before any operation: the substrate must claim the
-configured tenant, and the configured tenant must be one the substrate can reach. A
-substrate authenticated as a different account is **skipped, never used — including at
-tier 1**. A credential is not an identity claim; the identity claim is what the provider
-says when asked. Skipping the check because "the user obviously meant this workspace" is
-forbidden.
-
-## Mutating operations: fallback is guarded, never routine
-
-Falling back to an ambient-bound substrate for a **write** requires: switch profile and
-assert identity immediately before the write → write → re-read the affected objects →
-assert the tenant **from the response** (self URL host, cloudId in the path, response
-metadata), not from the pre-flight check → on mismatch, stop, report a cross-tenant
-hazard, and best-effort roll back. A successful pre-flight switch is not sufficient:
-another process can mutate global state between the check and the write.
-
-Full contract (per-vendor identity anchors and probes, the provider-first rationale, MCP's
-first-class fallback role, consequences, and the checklist for adding or editing an access
-skill): [reference/credential-substrate-precedence.md](../reference/credential-substrate-precedence.md).