@codyswann/lisa 4.48.0 → 4.50.0

package/plugins/lisa-copilot/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/lisa-copilot/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/lisa-copilot/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/lisa-copilot/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/lisa-copilot/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/lisa-copilot/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/lisa-copilot/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/lisa-copilot/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).

package/plugins/lisa-copilot/rules/eager/dependency-decision-records.md

@@ -1,32 +0,0 @@
-# Dependency Decisions (load-bearing)
-
-Material dependencies are recorded as decisions, not lockfile trivia. The
-governed record is `.lisa/DEPENDENCY_DECISIONS.md`, seeded once by `lisa apply`
-from the `all/create-only` template surface and never overwritten afterward.
-
-A *material* dependency is one that owns a user-visible capability or would cost
-real time to replace. Each record entry must name, in this order: why we keep it
-in plain language, what it is, its owned capability, trust basis, exposure,
-replacement cost, detection evidence, owner/review cadence, and last-reviewed
-date. Field labels lead with the operator's question and keep the technical term
-in parentheses. "Why we keep it" comes first on purpose — an entry that opens
-with a version range opens with the trivia the record exists to replace.
-
-When you add, upgrade across a major version, or remove a material dependency,
-update its entry in the same change. When you cannot name the detection evidence
-that would fail if an update broke the owned capability, write "nothing would
-catch it" rather than inventing a check — the gap is the finding.
-
-Write every entry so a non-technical operator can tell why the dependency is
-kept and what evidence would detect a bad update. Lead with the outcome it
-protects, not the mechanism.
-
-Entries are repeatable blocks appended under `## Records`, so a seeding script
-can add one without rewriting the file. An honest gap is written as
-`_Not yet decided_` — never left blank.
-
-Escalate, rather than just recording, when detection evidence says "nothing
-would catch it", when `Last reviewed` predates the dependency's last major
-upgrade, or when the trust basis names no maintainer or owner.
-
-Full prose: [reference/dependency-decision-records.md](../reference/dependency-decision-records.md).

package/plugins/lisa-copilot/rules/eager/dependency-internalization-kit.md

@@ -1,42 +0,0 @@
-# Dependency Internalization Kit (load-bearing)
-
-When a work item **removes, replaces, or internalizes** a material dependency,
-ownership of that capability moves in-house. The risk moves with it: we stop
-trusting an upstream project and start having to **prove we rebuilt the
-capability correctly**. The confidence-rebuild kit is the standing acceptance
-bar for that proof, so internalization work never has to guess at its own tests.
-
-The kit is seven required evidence types. Each leads with the plain question it
-answers:
-
-1. **Real corpus** — did we test it on real inputs, not toy examples?
-2. **Conformance fixtures** — does the new code do what the dependency did?
-3. **Negative fixtures** — does it still reject what it should reject?
-4. **Coverage as a gap detector** — what behavior is still untested?
-5. **Provenance and license review** — where did this code come from, and are we
-   allowed to use it?
-6. **Migration and update plan** — how do existing call sites move, and how does
-   the new code stay current?
-7. **Rollback or replacement criteria** — what would make us go back, and to
-   what?
-
-All seven are required. A partial kit is the finding: dropping the corpus leaves
-a toy-example pass, dropping negative fixtures leaves code that accepts garbage,
-and dropping rollback criteria leaves nobody able to say the internalization
-failed.
-
-**When the kit applies:** ownership moves in-house — the dependency is removed,
-replaced with our own code, vendored, or forked and maintained by us. That is
-usually a move into the `thin wrapper suitable for in-house ownership` trust
-class, or out of the dependency set entirely.
-
-**When the kit does NOT apply:** a routine version bump of a trusted dependency
-**within its existing trust class**. Ownership does not move, so there is no
-rebuilt capability to prove. Applying the kit there is over-application — it
-buys no confidence and makes ordinary upkeep expensive.
-
-A work item that removes, replaces, or internalizes a material dependency
-inherits all seven criteria unless it explicitly justifies why the dependency is
-**non-material**. Silence is not a justification.
-
-Full prose: [reference/dependency-internalization-kit.md](../reference/dependency-internalization-kit.md).

package/plugins/lisa-copilot/rules/eager/dependency-trust-classes.md

@@ -1,43 +0,0 @@
-# Dependency Trust Classes (load-bearing)
-
-Every material dependency belongs to exactly one **trust class**. The class is
-the answer to the decision record's "Why we believe it's safe (trust basis)"
-field in `.lisa/DEPENDENCY_DECISIONS.md` — it says why we can trust a *kind* of
-dependency, so each entry does not re-argue trust from scratch.
-
-The six classes, from most to least self-evidently trustworthy:
-
-1. **Mature ecosystem primitive** — so widely used that other people hit the
-   breakage first.
-2. **Fast-moving standard implementation** — the standard implementation of
-   something we refuse to own, but it changes faster than we do.
-3. **Build/development tool** — never runs in production; a bad update costs
-   developer time, not users.
-4. **Runtime-critical service client** — reaches users, data, or money directly,
-   so it is the least trusted regardless of how mature it is.
-5. **Thin wrapper suitable for in-house ownership** — small enough that we could
-   own the code, so the question is whether it earns its keep, not whether it is
-   safe.
-6. **Temporary/experimental dependency** — not trusted at all; admitted on a
-   clock with a written expiry date and a named exit.
-
-Each class fixes five review inputs: capability owner, update cadence, detection
-evidence, replacement-cost threshold, and whether product/human ratification is
-required. Higher exposure and lower trust buy stronger evidence and mandatory
-ratification, not weaker: runtime-critical service clients always need human
-ratification to add or major-upgrade; temporary dependencies need it to live
-past their expiry date; thin wrappers need it to be kept rather than in-housed.
-
-Every class also names one **human-review trigger** — the observable event that
-takes the decision away from the agent. A class definition that cannot say what
-would trigger human review is not finished.
-
-A work item that proposes adding a new material dependency must name the
-dependency's trust class and update its `.lisa/DEPENDENCY_DECISIONS.md` entry in
-the same change. A proposal with no named class is not ready to build.
-
-Reclassify — do not quietly re-trust — when a dependency's exposure changes: a
-build tool that gains runtime reach or reads CI credentials becomes a
-runtime-critical service client, and its stronger requirements apply immediately.
-
-Full prose: [reference/dependency-trust-classes.md](../reference/dependency-trust-classes.md).

package/plugins/lisa-copilot/rules/eager/deployed-state-readback.md

@@ -1,47 +0,0 @@
-# Deployed-State Readback (load-bearing)
-
-**A build ticket asserts that something is missing from a running system. That assertion must come from reading the running system, never from reading the source.** Source tells you what the code says; only the environment tells you what is deployed. A ticket authored from source alone specifies work against a system it has not observed.
-
-**One vendor-neutral contract, cited by** the Phase 2 research step of `lisa-notion-to-tracker`, `lisa-github-to-tracker`, `lisa-linear-to-tracker`, and `lisa-confluence-to-tracker` (the `leaf-only-lifecycle` / `repo-scope-split` precedent: one shared slug, never four divergent forks).
-
-## The waiver this replaces was scoped to the wrong axis
-
-Phase 2 has two halves — codebase research and a live product walkthrough — and the walkthrough was waived for work that is *"purely backend with no user-visible surface."*
-
-"Is it user-facing?" is a question about the **observation method**: browser, API client, or resource readback. It was being used to answer a different question — **"should we observe live state at all?"** Backend, infrastructure, CI, and dependency work all have live state. It simply is not visible through a browser. Waiving the browser step correctly, and live grounding along with it, is what let tickets be authored for work that had already shipped.
-
-So the skip is **not** "no live check". It is **a different probe**.
-
-## Routing
-
-| The work | Probe |
-|---|---|
-| User-facing surface | `lisa-product-walkthrough` against the running app |
-| HTTP / API backend | Call the deployed endpoint and read the response |
-| Infrastructure / IaC | **Describe the deployed resource in the account** |
-| CI / workflow config | Read the config the running pipeline actually used |
-| Dependency / package pin | Read the **installed** artifact, and the registry |
-| Screen that does not exist yet | No probe; record why |
-
-## What is never accepted as evidence of deployment
-
-**Git ancestry, a merge check, and `cdk synth` are not deployment evidence.** A commit can be an ancestor of the default branch and never have shipped: a pipeline running `executionMode: SUPERSEDED` discards queued executions, so an intermediate commit's deploy is silently dropped. `git log`, a merge check, and a synth all report "present" while the environment does not have it.
-
-Read the deployed thing back. Do not infer it from anything upstream of the deploy.
-
-**This does not conflict with `blocker-containment`, which requires exactly the ancestry test this rule rejects.** The two answer different questions and both are right:
-
-- `blocker-containment` asks a **development** question — *is the blocker's code on the branch I will build from?* Ancestry is the correct and sufficient test.
-- This rule asks a **deployment** question — *is this live?* Ancestry is provably insufficient, per the discarded-execution case above.
-
-Neither may be used to answer the other's question.
-
-## An unanswerable probe is not a "no"
-
-If the deployed state cannot be read back — no credentials, no such environment, the resource is not addressable — **record that the check could not be performed**. Absence of evidence is not evidence of absence, and defaulting an unreadable probe to "not deployed" reintroduces the whole defect while appearing to satisfy the rule.
-
-## Record the readback on the ticket
-
-Write what was probed, how, and what came back. Claim-time triage then inherits evidence instead of re-deriving it from source — which is the same mistake one stage later.
-
-Full contract (per-lane probe definitions, the discarded-execution hazard, the doctrine this applies, and worked examples): [reference/deployed-state-readback.md](../reference/deployed-state-readback.md).

package/plugins/lisa-copilot/rules/eager/derived-branch-plan.md

@@ -1,47 +0,0 @@
-# Derived Branch Plan (load-bearing)
-
-**Every applicable leaf work item shows the branch it will be built from and the branch its PR lands in, as a generated `Branch Plan` section — and that section is derived data, not a second authority.** The authority is `## Target Backend Environment` resolved forward through `.lisa.config.json` `deploy.branches`. A work item that displays branches nobody can trace back to that mapping, or a flow that reads the displayed branches instead of recomputing them, is a contract violation.
-
-**One vendor-neutral contract, cited by** `lisa-jira-write-ticket`, `lisa-github-write-issue`, `lisa-linear-write-issue`, `lisa-jira-validate-ticket`, `lisa-github-validate-issue`, `lisa-linear-validate-issue`, and `lisa-implement` (the `leaf-only-lifecycle` / `repo-scope-split` precedent: one shared slug, never divergent per-vendor prose).
-
-## Why derived, and not two branch fields
-
-The operator need is real: reading a ticket should not require resolving a config file to learn where the work starts and where it lands. But Lisa already owns that fact. Adding independent literal branch fields would create **a second source of truth that can drift** — and the failure mode of that drift is not a cosmetic mismatch, it is code silently shipped to the wrong environment. So the branches are rendered for humans and recomputed for machines. The rendered branches are **never read as input** by any flow, at any phase — a surface that needs the base branch derives it again from the environment.
-
-## The rendered section
-
-Exactly three lines, identical across vendors (`h2. Branch Plan` in JIRA wiki markup, `## Branch Plan` in GitHub/Linear markdown):
-
-```
-Branch from: <branch>
-PR into: <branch>
-Derived from: Target Backend Environment <env> via .lisa.config.json deploy.branches
-```
-
-The third line is the **derivation provenance line**. It is what marks the section machine-authored: a `Branch Plan` without it is treated as hand-authored, and hand-authored branches are never obeyed.
-
-`Branch from` and `PR into` name the **same branch by construction** — implementation checks the feature branch out of `origin/<base>` and targets the PR back into `<base>`. A plan naming two different branches is malformed and fails validation. (A fix that genuinely lands on one branch and must reach another travels as a linked follow-up work item with its own branch plan, never as a divergence inside one plan.)
-
-## Derivation
-
-1. Resolve the environment under the existing `Target Backend Environment` grammar (`config-resolution`, `pre-flight-autofill`) — human-confirmed wins, then validated `Inferred:`, then `Assumption:`.
-2. Map that exact configured key forward through `deploy.branches`. The key must map uniquely and the mapped branch must exist on the remote.
-3. Render both fields to that branch plus the provenance line.
-
-A missing or **ambiguous** mapping, a key that is **not unique**, or a branch absent from the remote **stops** the flow — exactly as `lisa-implement` already stops. **Never default independently to `main`, to the remote default branch, or to any other branch** to keep a write from failing. The remote default is a legitimate input only through the `Assumption:` fallback the environment grammar already defines, and it must be recorded as such.
-
-## Exemption
-
-Work that declares no runtime behavior change — `runtime_behavior_change = false`, i.e. doc-only, config-only, and type-only items — has nothing to derive from and **requires no branch plan**. Its **absence is correct**, not a missing section, and no gate may demand one. Containers (an Epic, or a Story/Spike still holding child work) are exempt for the same reason: they are not built directly.
-
-But the exemption is **declared, never inferred from an absent section**. `Target Backend Environment` is rendered on every leaf, because it is where `runtime_behavior_change` is persisted: an exact configured environment key means `true`, `None — no runtime behavior change: doc-only` (or `config-only` / `type-only`) means `false`, `None — container: state rolls up from children` marks a container, and an **absent section is underivable — never `false`**. On a live item the stored declaration beats any caller assertion, and a contradicting assertion fails S8 rather than being believed. Absence used to be the only signal, which meant the flag every one of S8, S11, S14, and S19 turns on could not be checked against the item at all.
-
-The exemption is one-way. Exempt work that *carries* a branch plan fails validation — branches asserted for work that declared it has no runtime target are hand-authored by definition, which is the second-authority failure this rule exists to prevent.
-
-## Conflict, legacy, and drift
-
-- **Conflict** — a present plan that disagrees with the recomputed plan **fails**; the flow never silently picks a side. The remediation is always to correct the environment, never to edit the branches.
-- **Legacy** — an item written before this rule has no plan. At claim time the implementing agent derives it, **writes the assumption onto the item as a comment**, and proceeds. Never a silent guess.
-- **Drift** — config changed after the plan was rendered. Current config wins; the stale plan is re-rendered and never followed.
-
-Full derivation table, gate S19 semantics, the claim-time arms, and the vendor rendering details: [reference/derived-branch-plan.md](../reference/derived-branch-plan.md).