@codyswann/lisa 4.49.0 → 4.50.1

package/plugins/lisa/rules/eager/prd-lifecycle-rollup.md

@@ -1,31 +0,0 @@
-# PRD Lifecycle Rollup & Generated-Top-Level-Work Contract (load-bearing)
-
-The vendor-neutral source of truth for how a PRD owns the work it generated and how its lifecycle rolls up to `shipped`. Companion to `leaf-only-lifecycle` (which governs build-lifecycle of leaves); this rule governs PRD lifecycle and rollup from generated top-level children.
-
-## Generated top-level work (the contract)
-
-A PRD owns the work units it created **at the top of the hierarchy** — the Epic(s) and any top-level Story it created directly. It does NOT own descendants (Sub-tasks, Stories under an Epic, leaves under a top-level unit) — those are owned by their top-level parent and roll up via `leaf-only-lifecycle`.
-
-Leaf Sub-tasks are **never** direct children of a PRD when a top-level Epic/Story hierarchy exists.
-
-## How each vendor records the PRD→child link
-
-**Native hierarchy first**, machine-readable fallback section always written:
-
-- **GitHub Issues** — native sub-issues when source and tracker are the same repo + supports sub-issues.
-- **Linear** — `parentId` or generated Project grouping where the PRD also lives in Linear.
-- **JIRA** — Epic link / parent field, or documented issue-link type.
-- **Confluence / Notion** — no native issue hierarchy; the documented `## Tickets` / `## Generated Work` section IS the source of truth.
-- **Cross-vendor** (e.g. Notion PRD → JIRA tracker) — always documented section in the PRD source.
-
-The documented `## Tickets` section is ALWAYS written (additive to native links) so the generated set is readable without parsing comments.
-
-## Rollup transition
-
-PRD rolls from `ticketed` to `shipped` when every required generated top-level child is terminal. The PRD remains open for `/lisa:verify-prd` after `shipped` — verified PASS performs native closure (archive/close/transition), verified FAIL re-opens to `ticketed` with build-ready fix tickets (never `blocked`).
-
-## Idempotency dedupe key
-
-Re-runs of intake/backlink must dedupe by child-ref identity (e.g. `owner/repo#number` for GitHub, Linear issue UUID, JIRA key) — never by URL string, which varies by formatting.
-
-Full vendor matrix, predicate definitions, non-goals: [reference/prd-lifecycle-rollup.md](../reference/prd-lifecycle-rollup.md).

package/plugins/lisa/rules/eager/pre-flight-autofill.md

@@ -1,84 +0,0 @@
-# Pre-Flight Spec Autofill — Draft-Then-Block (load-bearing)
-
-When the pre-flight gate (`*-agent` Step 2) returns `FAIL` on **ticket-quality**
-gaps, do **not** bounce a raw checklist back to the reporter. Most "missing
-required spec content" gaps are **authorable** from material already on the work
-item (title, description, screenshots, design links, repro steps) plus the
-codebase. **Draft** a best-effort version of every authorable gap, write it into
-the item as clearly-labeled **assumptions/recommendations**, and only **then**
-block — turning the human ask from *"author all this"* into *"confirm or correct
-my draft, then flip back to Ready."* Same shape as `repo-scope-split`: the agent
-does the work it can; the human decides only what only a human can.
-
-This does **not** widen the gate — every required section must still exist
-before build. It replaces an empty demand with a defensible first draft, and it
-breaks the `Ready ↔ Blocked` ping-pong loop that a raw checklist causes (the
-information was already on the ticket; only the structure was missing).
-
-## Two tiers
-
-- **Tier A — authorable (always draft):** Technical Approach, Out of Scope,
-  Gherkin Acceptance Criteria (one scenario per fix), expected-vs-actual +
-  environment, Repository, Relationship Search (actually run the git+tracker
-  search — don't fabricate "none found"), Validation Journey **draft** (via the
-  vendor `*-add-journey` skill), Target Backend Environment. Preserve a bare
-  configured key or `Confirmed: <env>` as human-confirmed. Automation writes
-  `Inferred: <env> — evidence: <title|body|reproduction|hostname>` or
-  `Assumption: <env> — remote default branch <branch>`. Without a unique
-  reverse-map use `Assumption: remote default branch <branch>`; human confirmation
-  replaces the annotation with a bare key or `Confirmed: <env>`. For legacy bare
-  values, use managed draft markers and current ticket content only; provider
-  edit history is not required. A marker proves automation and requires
-  re-annotation; otherwise unknown provenance plus conflicting evidence stops.
-  Human-confirmed wins, then validated `Inferred:`
-  evidence. Otherwise use one unambiguous exact `deploy.branches` key from the
-  title, body, and reproduction steps or a URL hostname, excluding the complete
-  `Target Backend Environment` section and other machine-authored metadata/draft
-  blocks so annotations cannot become evidence. Evidence supersedes only
-  `Assumption:`. Normalize only built-in
-  `prod` ↔ `production` when exactly one is configured; no other aliases exist.
-  Never infer from arbitrary branch text, URL paths/query strings, or substrings.
-  Conflicting signals **stop** autofill. With no environment signal, use the
-  remote default and record the applicable `Assumption:` form; a non-unique
-  reverse-map alone never blocks. Require any selected mapping and remote branch.
-  Never overwrite human prose.
-- **Tier B — irreducibly human:** real credentials/access that exist nowhere on
-  the item or in repo test-user docs; a genuine product/scoping decision with no
-  defensible default. Still propose a recommended default where one exists; ask
-  a specific question only where none does.
-
-## Procedure
-
-1. Enumerate FAIL categories from `*-verify`. If S10 failed, run
-   `repo-scope-split` first (split, not autofill).
-2. Draft each Tier-A gap grounded in item material + codebase; tag every
-   inference as an assumption. **Never overwrite human prose** — add/augment
-   sections only.
-3. Write the draft via the vendor write skill (`jira-write-ticket` /
-   `github-write-issue` / `linear-write-issue`); draft the Validation Journey
-   via `*-add-journey`.
-4. Re-run `*-verify`. Structural gates should now PASS; anything still failing
-   is Tier B — name it in the comment.
-5. Block as usual (`blocked` status + `human_needed` marker + reassign to
-   Reporter) but post the **confirmation comment**, not a checklist: disclose
-   it's a Claude draft, one line per drafted section + its key assumption,
-   Tier-B items as specific questions with defaults, and close with *"correct
-   anything wrong, then flip back to Ready and it builds — or reply with
-   corrections."*
-6. **Loop-safety:** if the item already carries the agent's draft, refine only
-   the still-failing gaps; don't redraft. Re-readying after review is the
-   human's approval — the next claim's `*-verify` PASSes and build proceeds.
-
-## When you genuinely cannot autofill
-
-If drafting would be fabrication (no fix/expected behavior described, no usable
-design ref, uninformative title, no codebase anchor), block as before — but
-phrase each gap as a specific question with a default where defensible. Never a
-bare checklist when a defensible draft is possible.
-
-The agent writes **spec/criteria, never code**, at this gate — authoring AC and
-a validation journey is explicitly permitted here (this supersedes the older
-"the build agent does not author the missing spec content" stance).
-
-Full procedure, tier detail, confirmation-comment template, and vendor mechanics:
-[reference/pre-flight-autofill.md](../reference/pre-flight-autofill.md).

package/plugins/lisa/rules/eager/project-learnings.md

@@ -1,22 +0,0 @@
-# Project Learnings (load-bearing)
-
-Before normal task work, resolve this repository's committed `.lisa.config.json`
-and derive the machine-managed learnings ledger: the optional `learnings.file`
-override, else the default `.lisa/PROJECT_LEARNINGS.md`. The ledger lives cold in
-`.lisa/`, NOT in an auto-loaded rules tree — so it is never injected raw into the
-session.
-
-Consume it ONLY through the executable Lisa learnings contract exported by
-`@codyswann/lisa/learnings`: parse and validate with `parseLearningsFile`, then
-take the bounded serving slice from `projectLearnings` (the highest-priority
-entries within the token/entry budget). **Never read the raw ledger file
-wholesale into context** — the whole point of the relocation is that sessions
-receive the contract's bounded projection, not the full file.
-
-Missing learnings are a silent no-op. Malformed, non-canonical, unsafe, or
-over-budget learnings produce one readable warning, apply no entry, and must not
-block unrelated task work. Never append automated learnings to host rules
-(`.agents/rules/`, or a surviving legacy `PROJECT_RULES.md`); project learnings
-are a separate machine-managed document.
-
-Full prose: [reference/project-learnings.md](../reference/project-learnings.md).

package/plugins/lisa/rules/eager/promotion-contract.md

@@ -1,18 +0,0 @@
-# Promotion Contract (load-bearing)
-
-When implementing a learnings-ladder **promotion ticket** — turning prose
-knowledge into an executable control (lint / ast-grep / type / test / hook /
-`package.lisa.json` force) — the change must be **atomic**: one PR that
-**enables the control**, **fixes the existing violation population**, **ships a
-remediation-teaching diagnostic** (violated invariant + why + concrete fix),
-and **deletes the superseded prose**. A PR missing any of the four is
-**rejected by rule** — promote-without-remove double-pays forever;
-remove-without-diagnostic strands agents.
-
-Eager-tier admission is **demotion-biased** and earned only by repeated-miss
-evidence; the gardener audits the eager tier every run, including Lisa's own
-shipped eager rules.
-
-Full contract, diagnostic-quality bar, and the AC template the gardener embeds
-in EXECUTABLE-CONTROL promotion tickets:
-[reference/promotion-contract.md](../reference/promotion-contract.md).

package/plugins/lisa/rules/eager/readiness-rubric.md

@@ -1,58 +0,0 @@
-# Repository Readiness Rubric (load-bearing)
-
-**"Lisa is installed correctly" and "an agent fleet may run here unattended" are two different
-questions.** Doctor's shipped grouped checks answer the first — *installation readiness*. This rubric
-answers the second — *repository readiness* — and it is the only place that question is written down.
-A green test suite is not an answer to it.
-
-## Eight ownership dimensions
-
-Repository readiness is assessed across exactly eight dimensions, never fewer, and a dimension with
-no applicable evidence renders `SKIP` **with a reason** rather than a blank:
-
-1. **context/routing** — can an agent recover the real job from what is written down?
-2. **capabilities/tools** — is every tool the work needs *provably* reachable, not merely installed?
-3. **domain ownership** — are the business rules, glossary, and danger zones owned and written down?
-4. **execution/proof** — can the claimed user-visible outcome be proved by running the system?
-5. **feedback/guardrails** — does a failing loop produce a named outcome and a runbook?
-6. **dependencies/supply chain** — is there a confidence model for what the repo depends on?
-7. **delivery/authority** — does the thing that ships equal the thing that was validated, and does
-   the credential that ships it carry only the authority it needs?
-8. **proportionality** — is the machinery proportional to the job, or is there scaffolding to
-   subtract?
-
-## Seven ship blockers (closed set, v1)
-
-A **ship blocker** is a condition that, standing alone, means the answer to "may an unattended fleet
-run here?" is no. The set is closed in v1 — seven, no more — and extended only by editing this rule:
-
-- **B1** a realistic path causes **silent data loss**
-- **B2** a **release path bypasses the validated artifact**
-- **B3** **credentials carry material unintended authority**
-- **B4** a **consequential operation has no gate and no recovery**
-- **B5** an **owned compatibility or security surface has no confidence model**
-- **B6** **documentation overstates enforced guarantees**
-- **B7** there is **no way to prove the claimed user-visible outcome**
-
-## Verdict and narrowed claim
-
-The verdict reuses the shipped `READY` / `READY_WITH_WARNINGS` / `NOT_READY` ladder — cite doctor's
-ladder, never fork a parallel enum. **A standing blocker is `NOT_READY`**, and the report must also
-state the **narrowed claim**: what the repository *is* ready for, in operator language ("ready for
-supervised single-ticket work; not ready for unattended fleet operation, because …").
-
-## Ordering
-
-**Report section order stays stable and never silently omits a section; findings are ordered by
-consequence** — highest-consequence first — within and across sections. The two contracts do not
-collide: sections are fixed, findings are ranked.
-
-## Warn-only
-
-This rubric **gates a claim, not a process**. No Lisa surface hard-blocks on the verdict: a standing
-blocker narrows what may be claimed and files tracker work; it never stops `lisa apply`, intake
-dispatch, or cron registration. Where a surface this rule names is not installed in a given branch,
-name what you can and continue — degrade, never block. Written to be read by someone who does not
-code (`factory-model` rule 5).
-
-Full rubric (eight-dimension table, seven ship blockers, consequence ordering, worked example): [reference/readiness-rubric.md](../reference/readiness-rubric.md).

package/plugins/lisa/rules/eager/ready-role-filing.md

@@ -1,29 +0,0 @@
-# Ready-Role Filing (load-bearing)
-
-Filing a work item without the ready role is an **incomplete handoff** — build-intake scans the ready lane and nothing else, so the item is never picked up. A correct write plus a missing role still loses the work.
-
-## Omitted means NOT ready — on every tracker
-
-**An omitted `build_ready` is NOT build-ready on JIRA, GitHub, and Linear alike.** Ready is an explicit claim, never an accident of which tracker a project configured. This is a **breaking change** for GitHub and Linear callers, which previously treated omission as ready; `lisa-github-validate-issue` F4's compensating omitted → `true` normalization is removed with it.
-
-## Every filing declares one of three things
-
-- **`build_ready: true`** — complete enough to build; enters the ready lane for auto-pickup. Required for any complete defect found during other work, so it is claimable next cycle with no human flipping status.
-- **`human_gate: "<why a human must judge this first>"`** — deliberately held outside the queue. The writer stamps a visible line plus `<!-- [lisa-human-gate] reason=<short-slug> -->` so the hold is auditable.
-- **The container declaration** — `None — container: state rolls up from children`, the canonical line `derived-branch-plan` defines and every writer stamps in place of a Target Backend Environment. A container is never build-ready (`leaf-only-lifecycle`) and needs no gate, so it declares the third thing instead. Deliberately **not** keyed on `--label type:Epic`: a declared type is a claim that costs a leaf nothing and leaves it looking buildable, where the container line costs the item the environment and Branch Plan a leaf needs to be built. It is refused alongside a by-design leaf type (`type:Bug` / `type:Task` / `type:Sub-task` / `type:Improvement`) — an item cannot be a container and a leaf at once.
-
-Filed, not ready, and no `human_gate` is the **incomplete handoff** case — writers reject it and name both ways to resolve it. `build_ready: false` with no reason is the same omission with a value attached. `build_ready` stays subordinate to `leaf-only-lifecycle`: a container is never build-ready and needs no gate.
-
-## The named exception
-
-`lisa-exploratory-qa` files findings not-ready **by design** — its findings are candidate defects whose product significance a human should judge. It is the named human-gate exception, not drift: it pairs `ready=false` with an explicit `human_gate` reason. The sibling `e2e-coverage-gaps` skills are the contrast (a missing test is not a product question, so they file build-ready).
-
-`lisa-repair-intake` sweeps for open items that are neither in the ready role nor marked `[lisa-human-gate]`, and surfaces them rather than promoting them.
-
-## This rule is enforced
-
-The PreToolUse guard `block-direct-issue-create.sh` refuses a direct tracker-creation command (`gh issue create`, `gh api` POST to an issues endpoint, `linear`/`jira`/`acli` creates, equivalent `curl` posts) that carries **none of the three declarations** — no configured build-ready role, no `[lisa-human-gate]` marker, and no container declaration. It shipped because this rule as prose did not bind: 13 of 13 issues filed during the session that merged it bypassed it, several by the agent that wrote it, while the one obligation backed by a git hook was honored 50 of 50 times. It stands down where no tracker is configured, and for an operator who set `LISA_ALLOW_DIRECT_ISSUE_CREATE` **in the ambient environment** — never from an inline assignment on the refused command.
-
-**The role is the TARGET repository's, not the caller's.** A creation addressed at another repository — `--repo` / `-R`, or a `repos/<org>/<repo>/issues` endpoint — is judged against that repository's build-ready role: `hardening.upstreamReadyRole` (default `status:ready`) when the target is `hardening.upstreamRepo`, and the stock `status:ready` otherwise. A creation naming no repository, or naming the project's own `github.org`/`github.repo`, is judged against the project's own role exactly as before. A declaration is required either way; only its vocabulary changes.
-
-Full contract (the per-vendor before/after table, marker format, and recovery sweep): [reference/ready-role-filing.md](../reference/ready-role-filing.md).

package/plugins/lisa/rules/eager/rejection-detection.md

@@ -1,64 +0,0 @@
-# Rejection Detection at Claim Time (load-bearing)
-
-A QA rejection — an item that reached a `review`/`done`-ward state and is now back in the build-ready lane — is a **teaching signal**, not fresh work. Detect it at claim time so the re-claim can reflect on the rejection instead of repeating it.
-
-**One vendor-neutral contract, cited by every build-intake arm** (the `leaf-only-lifecycle` / `repo-scope-split` precedent: one shared slug, never three divergent implementations).
-
-## When it runs
-
-At the **top of build-intake step 3b (Claim), BEFORE the relabel** `$READY → $CLAIMED`. After the relabel the current-lane signal is gone, so detection must read history first. Detection is a pure read — idempotent, headless-safe, no side effects.
-
-## Classify the claimed item
-
-Return exactly one of:
-
-- **`rejection-reclaim`** — history shows the item reached a `review`/`done`-ward lane and is now back in `$READY`.
-- **`forward-only`** — history shows only forward moves (never returned to `$READY` from a later lane).
-- **`never-left-ready`** — history shows the item never left `$READY`.
-- **`unknown`** — the vendor history query failed, was inconclusive, or is absent.
-
-## Vendor history sources (through the access layers only — `integration-access-layer`)
-
-- **GitHub** — `LABELED` / `UNLABELED` timeline events on the configured **ready** label (the Label-Event History surface from `lisa-github-read-issue`).
-- **JIRA** — the `changelog` operation on `lisa-atlassian-access` (`?expand=changelog`, status items).
-- **Linear** — the `history` operation on `lisa-linear-access`, keyed on **workflow-state** history (`fromState.name` / `toState.name`, inlined on each node — no label-ID resolution needed).
-
-**Lane names ALWAYS come from `.lisa.config.json` lanes** (`github.labels.build.{ready,claimed,done}` for GitHub, `jira.workflow.*` and `linear.workflow.*` for the status/state trackers; `src/sync/registry.ts` `BUILD_LABEL_DEFAULTS` and `LINEAR_WORKFLOW_DEFAULTS`). **Never hardcode** `status:ready`, `Ready`, `Todo`, etc.
-
-## Never block the build
-
-`unknown` is a first-class result, not an error. A failing/absent history yields `unknown` and **the build proceeds** to implement the item. Detection never stops a claim.
-
-## Learning-loop exclusion (no learning about learning)
-
-An artifact this flow produced is **never** a rejection-reflection trigger, no matter how it moves. Before classifying as `rejection-reclaim`, exclude items carrying any learning marker — `[lisa-learning-drop]`, `[lisa-learning-pr]`, `[lisa-learning-upstream-handoff]` — or the `learning:needs-triage` label. Such items short-circuit to `forward-only` (treated as normal work) so the detector never fires on the flow's own learning PRs/issues.
-
-## Reflect on a `rejection-reclaim`
-
-On `rejection-reclaim` only, before re-implementing: read the rejection evidence (comments after the backward transition, review threads on the rejected PR) through the access layers, assemble **one** candidate learning with the rejection linked as provenance, and route it to the `lisa-persist-learning` skill. If that skill is absent, record the candidate as a comment that carries a **visible prose line** plus the marker (a bare marker renders as an empty comment bubble) — `Recorded a candidate learning from this rejection (queued for the judgment gate): <one-line candidate rule>.` followed by `<!-- [lisa-rejection-candidate] key=<issue>-<transition-ts> -->` — and proceed. **Marker-dedupe** on `<issue>-<backward-transition-timestamp>`: re-claiming twice produces no duplicate. Unreadable/absent evidence → proceed without a candidate, never block.
-
-## Proposal rejection memory (proposal-side — orthogonal to the reclaim path above)
-
-A **loop-proposed** item that a human **closed as _not planned_** is a durable decline. Every *proposing* loop (`lisa-exploratory-qa`, `lisa-project-ideation`, `lisa-monitor`, `lisa-repair-intake`; `lisa-learnings-audit` is the shipped precedent) MUST consult it **before filing a candidate**. This is orthogonal to the `rejection-reclaim` path above — that classification and its reflection are untouched. The memory lives in the **tracker, not a new state file**.
-
-- **Signal:** the prior item is closed *not planned* (GitHub `stateReason == "not_planned"`; the JIRA/Linear equivalent resolved via `config-resolution` — never hardcode). The GitHub compare is **case-insensitive** — raw `gh --json stateReason` returns `NOT_PLANNED` UPPERCASE, so normalize to lowercase (or read via `lisa-github-read-issue`) before comparing, never string-match raw `gh` JSON. Closed as **completed** is NOT a decline — a recurrence after a completed fix is a regression and may file.
-- **Marker:** `<!-- [<loop-marker>] key=<candidate-key> -->`, key computed deterministically `printf '%s' "$normalized" | shasum -a 256 | cut -c1-12`. Search **open AND closed** items for the marker before filing (body-enumeration fallback on search-index lag); **match on the marker, never the title.**
-- **Rule:** a hit on a closed-**not-planned** item **suppresses** the proposal. Re-file **only** with evidence postdating the decline, carrying BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`).
-- **Operator footer:** every loop-filed proposal ticket MUST carry, as visible prose, `To stop this from being raised again, close it as **Not planned**. Close it as **Completed** if it was fixed — a later recurrence may be re-filed as a regression.` — so the operator knows which close-reason produces which outcome.
-- **Outcomes:** an all-suppressed cycle ends `nothing-needed` naming the **suppression count**; a memory check that cannot read the tracker ends `recovery-required`, never a silent `nothing-needed` (e.g. `Tracker unreachable during the decline check — restore credentials; nothing was filed this run.`).
-- **Concurrency:** search-then-write = convergence, not mutual exclusion — a transient duplicate is closed by the next run; no cross-run lock.
-
-## Automation-reversal memory (repair-side — orthogonal to both halves above)
-
-A human who **undoes a lifecycle transition this flow made** is correcting the flow, not supplying new state. Every loop that writes a lifecycle role as a **repair** (`lisa-repair-intake`) consults this before re-making a transition. It is a third classification, never merged into `rejection-reclaim`: that one is anchored on the ready lane and answers a rejection with re-implementation; this one lands in `$BLOCKED` and answers a correction by withdrawing a decision.
-
-- **Seam:** top of the repair walk for each item, **before any lifecycle write** — after the write the current-lane signal is gone.
-- **Classify:** `automation-reversal` — a role change **authored by** this flow, then a later **backward** move of that role **authored by** a human, with no automation move after it. Otherwise `no-reversal`. Authorship unavailable or history unreadable → `unknown`.
-- **Authorship is the signal, not the backward move.** An item can return to `$BLOCKED` because a real new blocker appeared — that is the world moving on. Read the `actor` (GitHub timeline, Linear history) or `author` (JIRA changelog) through the access layers; an unexposed actor is `unknown`, never an assumed human. **A marker and a transition on the same item say nothing until you know their order** — compare timestamps, and treat an unorderable pair as `unknown`.
-- **Lanes from config** (`github.labels.build.blocked` + the JIRA/Linear equivalents, `config-resolution`) — never hardcode.
-- **Degrade:** `unknown` is **neither a reversal nor a clearance** — the item is judged by the loop's normal rules and detection **never blocks the sweep**. The learning-loop exclusion above applies unchanged.
-- **Rule:** on `automation-reversal`, do not re-apply the reversed classification; leave the item where the human put it, ensure `human_needed`, and **name the reversed transition in the run record**. Re-attempt **only** on evidence that **postdates the reversal**, cited in the run record — mirroring the re-proposal rule the proposal half enforces.
-- **A changed lifecycle role is no longer a sufficient warrant on its own.** A consuming loop's recurrence brake must carry **authorship and an overturn bit**, not state alone.
-- **Signed per path.** Apply the inversion only where the loop decides whether to re-make a transition. A staleness/keep-alive path where a human comment already *suppresses* action is protective — leave it. One global sign reads as tightening and removes that protection.
-
-Full contract (classification table, per-vendor bindings, reflection & evidence handoff, Proposal rejection memory, Automation-reversal memory): [reference/rejection-detection.md](../reference/rejection-detection.md).

package/plugins/lisa/rules/eager/repo-scope-split.md

@@ -1,43 +0,0 @@
-# Repo Scope & Work-Time Splitting (load-bearing)
-
-**Leaf work units are single-repo.** A leaf is an individually implementable ticket with no open children — the by-design leaf types **Bug, Task, Sub-task, Improvement**, plus a childless **Story** or **Spike** (structurally a leaf per `leaf-only-lifecycle`). Each names exactly one repo. An **Epic**, and any **Story/Spike that still holds child work**, are coordination containers and may span repos.
-
-Enforced at four points: gate **S10** (`*-validate-*`, write time), `task-decomposition` step 1.5 (PRD-decomposition time), claim-time repo scoping (`*-build-intake`), and the work-time split procedure (an existing ticket about to be implemented).
-
-## Choose the right strategy
-
-- **Decomposition-time (no tickets exist yet):** use `task-decomposition` step 1.5 — one work unit per repo under a parent Story.
-- **Work-time (a ticket already exists):** narrow the original to one repo, spin off a sibling per additional repo, link by dependency. Do NOT invent a new parent — siblings inherit the original's existing parent.
-
-## Work-time split (pre-flight gate, agent-performed)
-
-1. **Detect repos.** Parse description + AC + approach, confirm against actual code surfaces. If single-repo, no split.
-2. **Pick the keeper.** Default: the original keeps the consumer / user-facing repo.
-3. **Create one sibling per extra repo**, cloning metadata (re-prefix summary, scope AC, carry parent, env, sign-in).
-4. **Link by dependency.** Producer **blocks** consumer (`is blocked by` on consumer / `blocks` on producer). No clear direction → `relates to`.
-5. **Narrow the original.** Edit summary prefix, Repository section, AC; remove cross-repo references.
-6. **Comment** on the original noting the split, linking each sibling.
-7. **Re-validate.** Run `tracker-verify` (S10) on the original and every sibling. All must PASS single-repo.
-8. **Proceed in dependency order.** Producer siblings first.
-
-## When to BLOCK instead of split
-
-Fall back to the standard BLOCK + reassign-to-Reporter path when:
-
-- Repos cannot be determined confidently from ticket + code.
-- Splitting would strand stakeholder context only the reporter can re-scope.
-- Required clone metadata (parent, env, credentials) is itself missing.
-
-## Claim-time repo scoping (build-intake)
-
-A tracker can oversee multiple repos. Build-intake claims only current-repo tickets. Resolve current repo per `config-resolution` (config `repo` → `github.repo` → git remote basename).
-
-**Query-time pre-filter (do this first, where expressible).** Scope the candidate query to the current repo so sibling-repo tickets never enter the set — on JIRA, append `AND (labels = "repo:<current>" OR labels IS EMPTY)`. This pre-applies only the unambiguous wrong-repo → skip arm; `labels IS EMPTY` keeps unlabeled tickets visible so the per-candidate gate below can still determine + stamp them. Skip it (broad scan) when the current repo can't be resolved or the query already constrains repo. Apply only where the query layer can express `OR labels IS EMPTY`: JIRA does (applied); GitHub issues are inherently single-repo (not needed); Linear's label filter can't, so it keeps the broad query and relies on the per-candidate gate.
-
-Then, for each ready candidate:
-
-1. **Read `repo:<name>` label.** Wrong repo → skip. Current repo → leaf-only gate + claim. Unlabeled → determine + stamp + re-apply.
-2. **Multi-repo leaf → split, never claim.** Each split sibling is created build-ready and stamped with its own `repo:<name>`.
-3. **Wrong-repo single-repo leaf → skip** (label keeps it cheap next cycle).
-
-Vendor mechanics (JIRA/GitHub/Linear) and full procedure: [reference/repo-scope-split.md](../reference/repo-scope-split.md).

package/plugins/lisa/rules/eager/reset-seed-coverage.md

@@ -1,50 +0,0 @@
-# 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](../reference/reset-seed-coverage.md).

package/plugins/lisa/rules/eager/usage-accounting.md

@@ -1,33 +0,0 @@
-# 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](../reference/usage-accounting.md).

package/plugins/lisa/rules/eager/work-item-definition-of-ready.md

@@ -1,27 +0,0 @@
-# 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](../reference/work-item-definition-of-ready.md).

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