@codyswann/lisa 4.49.0 → 4.50.1

package/plugins/lisa-cursor/rules/factory-model.mdc

@@ -1,46 +0,0 @@
----
-description: "The Factory Model (load-bearing)"
-alwaysApply: true
----
-
-# The Factory Model (load-bearing)
-
-This project runs as a set of **software factories** — agent-operated production lines with as few
-humans as possible. You are factory machinery, not a chat assistant. Four factories: **Research**
-(creates PRDs) → **Plan** (PRDs → work units) → **Implement** (work units → quality software) →
-**Verify** (go/no-go by using the software like a human; failures become build-ready tickets that
-flow straight back into Implement).
-
-The rules that follow from this:
-
-1. **Humans are not inside the factories.** Never pause mid-flow to ask a human whether to proceed.
-   All handoff happens at the **gates** — the ready-role flips (`prd-ready`, `status:ready`) plus
-   intake's adversarial validation.
-2. **The gate is adversarial.** An input enters a factory only when it is high-quality,
-   unambiguous, and the factory has the tooling *and provable access to that tooling* to execute it
-   (validator gate F5). Try to discover the answers to gaps first; what you genuinely cannot
-   resolve, reject to `blocked` and raise to a human with the exact missing thing named.
-3. **Everything runs on schedule.** The intake, QA, Product Planning, and Monitoring loops run as
-   native automations (Claude Routines / Codex Automations). Every flow must therefore work
-   headless: no interactive prompts, idempotent re-runs, clean exits on empty queues.
-4. **Quality is enforced, not requested.** The skills, hooks, quality checks, and guardrails exist
-   to keep the software enterprise-grade and maintainable. Never weaken a gate to get work through
-   it — fix the work.
-5. **Write outward for a non-technical operator.** The goal of the factory setup is to let
-   non-technical people create scalable software. Everything that crosses a gate outward — blocked
-   reasons, clarifying questions, ticket descriptions, verification reports — must be readable by
-   someone who does not code; they own product intent, the factories own the engineering.
-6. **Every supported coding agent is a first-class operator.** Claude Code, Codex, Cursor,
-   OpenCode, Antigravity, Copilot — behavior must stay in parity, and anything persisted for
-   agents must be visible to all of them.
-
-Brownfield on-ramp: an existing codebase becomes agent-ready **before** the fleet runs unattended
-— `/lisa:agent-ready` converges human knowledge through read-only, redacted source ingestion (every
-source must be complete and the gaps loop must reach none), then standards adoption refactors to
-conformance without behavior change.
-
-End state: end users have zero direct contact with coding agents — they interact with the tracker,
-the PRD source, and the shipped software.
-
-Full reference (factory ↔ Lisa surface mapping, loop details, human exterior gates):
-[reference/factory-model.md](factory-model-reference.mdc).

package/plugins/lisa-cursor/rules/leaf-only-lifecycle.mdc

@@ -1,75 +0,0 @@
----
-description: "Leaf-Only Build-Ready Invariant (load-bearing)"
-alwaysApply: true
----
-
-# Leaf-Only Build-Ready Invariant (load-bearing)
-
-**Build-ready means a directly implementable leaf work unit.** Containers never carry build-ready.
-
-A leaf is structurally defined: **no open children** AND not an Epic — the by-design leaf types (Bug, Task, Sub-task, Improvement) plus a childless Story or Spike. A container is an **Epic**, or any item of any type that has acquired open child work.
-
-## Invariant
-
-- **At decomposition/write time** — only leaves receive the `ready` role. Parent containers are created in their non-ready state.
-- **At validate time** — `*-validate-*` FAILs any container carrying the build-ready role. The parent-declared gate (S7) does **not** FAIL a build-ready leaf with no parent (flat Task/Improvement or childless Story/Spike); a Sub-task is the one exception and always needs a parent.
-- **At claim time** — build-intake claims leaves only. A container with a stale build-ready role is rolled up or safe-blocked, NEVER implemented.
-
-## Childless-parent exception
-
-A childless item is structurally a leaf — and may be build-ready **unless its type is Epic**:
-
-- **Task, Bug, Story, Spike, or Improvement with no children** → leaf → may be build-ready. A Story ships directly as one increment and a Spike *is* the investigation unit; neither needs sub-items to be implementable, so a childless one must not be stranded.
-- **Epic with no children** → still NOT build-ready. An Epic is a pure rollup container by design — its body is a high-level summary, never directly implementable — so a childless build-ready Epic is an incomplete decomposition or a mis-applied role. Repair: decompose into leaves, or reclassify to a leaf type.
-
-## Parent state rollup (priority order, first match wins)
-
-Evaluate over the env ladder `in-progress < dev < staging < production` (the ordered keys of the project's env-keyed `done` map; single-env projects have only the production rung):
-
-1. Any leaf is **blocked** → parent rolls up to **blocked / attention-needed**.
-2. Else **every** required leaf has shipped to some env → parent rolls up to the **least-advanced** env among them (all `On Stg` → `On Stg`; mixed `On Dev`+`On Stg` → `On Dev`; all production → terminal `done`).
-3. Else any leaf has **started** (claimed/in review, or shipped while a sibling has not) → parent is **in-progress** (`claimed`).
-4. Else (leaves exist but none started) → parent unchanged.
-
-**Blocked dominates — but it must say which leaf and which kind.** A parent that rolls up to `blocked` names the blocking leaf (with the path to it) and the **class** of the hold, derived by `rollup-blocker-classification` from recorded signals only:
-
-| Class | Recorded signal on the leaf | Who must act |
-|---|---|---|
-| `spec-defect` | the `spec_defect` marker (human-applied only) | a person rewrites the acceptance criteria — nothing external will ever clear it |
-| `human-input` | the `human_needed` marker | a person supplies the input (access, credential, product decision) |
-| `hard-blocker` | an open `is blocked by` link | nobody — it clears when that work closes |
-| `unknown` | none of the above | a person says which kind it is, and records it |
-
-Never infer a class from prose, and never auto-apply `spec_defect`: judging a criterion unbuildable is a human call, and `unknown` is the honest answer. A rollup that examined nothing — unreadable tracker, no children, no readable child — **fails**; it never reports not-blocked.
-
-**Blocked dominates.** A parent reaches an env only once all required leaves have reached at least that env. Intermediate-env rollup (`On Dev`/`On Stg`) happens, but native closure fires only at production `done`. Optional/won't-do children do not hold a parent open. Rollup is recursive — bottom-up. The parent never carries `ready`; a container found in `ready` is reconciled by rolling it up from its children.
-
-## Terminal native closure
-
-When a leaf reaches the true terminal `done` (the production / final-env value), also finalize via the tracker's native completion mechanism:
-
-- **GitHub** — `gh issue close <n> --reason completed` after the terminal label.
-- **Linear** — move workflow `state` to the team's Done.
-- **JIRA** — transition to terminal Done/Resolved/Closed; verify `statusCategory = Done`.
-
-Intermediate env-keyed states (`status:on-dev`, `On Stg`, etc.) remain open. Idempotent — if already closed, report and continue.
-
-### Exactly one lifecycle role survives closure
-
-The terminal transition retires **every** other lifecycle role the item carries, not only the one it was last known to hold. Resolve the complete configured set — `ready`, `claimed`, `review` where bound, `blocked`, and every env-keyed `done` value — and remove each one that is present, except the terminal role being applied. Type, component, priority, and provenance labels are untouched.
-
-Retiring only the claimed role assumes the item travelled the happy path, and items skip stages: one reaches completion straight from `ready` having never been claimed, another is unblocked and closed still carrying `blocked`. Measured on a live tracker: 34 closed issues carried an active lifecycle role, six of them carrying `ready` and the terminal role at once.
-
-**This is not cosmetic.** A queue scan filters on the synthesized role, not the native closed state, so a closed item still reading `ready` is handed back out — one already-shipped fix was independently rebuilt end to end before a push-time gate caught it.
-
-Three constraints on how it is done:
-
-- **Remove only roles the item actually carries.** Naming an absent label is a 404, which fails a clean closure and makes a repeat run fail where the first one succeeded.
-- **Verify by re-reading.** Confirm the final closed state and the unique terminal role from a **fresh read of the item**, never from the write's own response. A write that reports success is not evidence of the state it intended to produce — asserting otherwise is the same defect as the drift being repaired, one layer up.
-- **Never re-complete an abandoned item.** Applying a terminal `done` role to an item someone already closed as not-planned rewrites their decision that the work would not be done, and afterwards the two are indistinguishable. Refuse and say so. This does not restrict the duplicate closeout below, which is a flow deliberately closing an open item as not-planned rather than overwriting a closure that already exists.
-
-Trackers with a native lifecycle field (JIRA, Linear) get exclusivity for free: the field that closes the item is the field a queue scan filters on, so the two cannot disagree. GitHub Issues has no lifecycle beyond open/closed, so Lisa synthesizes one in labels and inherits a reconciliation duty the others do not have. That asymmetry is tracked separately in `CodySwannGT/lisa#3479`; this section is the obligation, not the redesign.
-
-Duplicate closeout is a narrow terminal exception: build intake may close a claimed item without a PR only when `ticket-triage` returns `DUPLICATE_ALREADY_FIXED` with a canonical item reference and empirical base-branch proof. Close it through provider duplicate semantics, not as completed build work. `BLOCKED`, ambiguous, duplicate-of-open, and other human-owned dispositions are not auto-closed.
-
-Full vendor mechanics + the state machine in prose: [reference/leaf-only-lifecycle.md](leaf-only-lifecycle-reference.mdc).

package/plugins/lisa-cursor/rules/observability-audit.mdc

@@ -1,20 +0,0 @@
----
-description: "Observability Audit (load-bearing)"
-alwaysApply: true
----
-
-# Observability Audit (load-bearing)
-
-The **audit + file** arm of `lisa-monitor`. On top of its existing live-signal sweep, `monitor` audits how well the **current repo** is instrumented and files build-ready tickets for what it finds. `monitor` is **manual** (no cron) and **files only** — it never fixes; the `intake` / `tracker-build-intake` cron implements what it files.
-
-## Invariants
-
-- **Repo-scoped two ways.** Audit only the rubric dimensions in scope for the repo's detected profile (`frontend` / `backend` / `infra` — a frontend repo never evaluates backend tracing), and stamp every filed ticket `repo:<CURRENT_REPO>` as a single-repo leaf (resolve the repo via the `config-resolution` ladder; cannot resolve → report, do not file).
-- **Two finding types → build-ready leaves.** A live signal over the conservative bar → a `Bug` leaf; an in-scope MISSING instrumentation dimension (gap, e.g. "no DB/query analytics") → a `Task`/`Improvement` leaf. Always via `lisa-tracker-write` with `build_ready: true` (never a vendor write skill directly); never an Epic/container (gate S15).
-- **Conservative by default.** Only high-signal anomalies (over the documented thresholds) and `core` missing dimensions are filed. `--all-gaps` widens gap filing to `recommended` tiers; nothing lowers the anomaly bar.
-- **Idempotent.** Every ticket carries a `<!-- lisa:monitor-finding: <fingerprint> -->` sentinel; search-before-create (including closed tickets) means a re-run never duplicates a live or just-resolved finding.
-- **Capped.** At most `monitor.maxCandidates` tickets per run (default 20), highest-severity first; report filed-vs-dropped (and list the dropped) — never silently truncate.
-- **Gate-passing.** Each ticket is a real authored artifact: three-audience description, Gherkin AC, single-repo, Target Backend Environment, and a Validation Journey with a typed `[EVIDENCE: <artifact-type>: <name>]` marker (unique kebab-case name) — so `tracker-validate` (S1–S15) accepts it. A finding that cannot be made into a credible ticket is reported, not filed.
-- **Verify guard.** When `monitor` is the post-deploy step of `lisa-verify` it runs **report-only** — Verify invokes it as `lisa-monitor <env> --report-only`, so it never files there. Filing is a standalone-only action.
-
-Full reference (profile detection, the rubric table, anomaly thresholds, ticket templates, idempotency contract, the cap, dry-run/report-only semantics): [reference/observability-audit.md](observability-audit-reference.mdc).

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

@@ -1,37 +0,0 @@
----
-description: "PRD Definition of Ready (requirement atoms)"
-alwaysApply: true
----
-
-# PRD Definition of Ready (requirement atoms)
-
-**A requirements document is ready when a planner can decompose it mechanically and a verifier can check the result against it.** Both properties come from the shape of the requirements, not the prose around them. Modeled on ISO/IEC/IEEE 29148's requirement quality characteristics and the EARS sentence patterns; the fit criterion is Volere's.
-
-## The atom
-
-Every requirement is an **identified atom**:
-
-- **Identified** — carries an id (`R1`, `R2`, …). Ids are per-generation; the verbatim text is the durable anchor (same convention as the `*-to-tracker` Requirement Register).
-- **Singular** — one behavior per atom. "The system shall X and Y when Z" is two atoms.
-- **Unambiguous** — no vagueness lexicon: *as appropriate, user-friendly, fast, robust, handle gracefully, etc., and/or, optimize, seamless, intuitive, support* (unbounded). Each is a word no test can check.
-- **Verifiable** — carries a **fit criterion**: the measurable test of satisfaction ("p95 upload completes < 4s for files ≤ 25 MB"). A requirement no test could check is a wish.
-- **Pattern-shaped (SHOULD)** — one of the EARS patterns, which decompose into Gherkin mechanically:
-  - Ubiquitous: *The `<system>` shall `<response>`*
-  - Event-driven: *When `<trigger>`, the `<system>` shall `<response>`*
-  - State-driven: *While `<state>`, the `<system>` shall `<response>`*
-  - Unwanted behavior: *If `<condition>`, then the `<system>` shall `<response>`*
-  - Optional feature: *Where `<feature>` is present, the `<system>` shall `<response>`*
-
-## The document
-
-Beyond the atoms, a ready PRD carries: problem statement · solution outline · user stories grouping their atoms · an explicit **non-functional checklist** (walk the ISO 25010 axes — performance, security, reliability, usability, compatibility, maintainability — and either state the requirement as an atom or state "no requirement"; silence is not a decision) · out of scope · open questions (the honest home for what is NOT ready).
-
-## Enforcement points
-
-- **Write time** — `lisa-research` authors to this shape; `*-write-prd` skills carry it as a body rule.
-- **Intake time (the universal gate)** — `*-to-tracker` Phase 1.45 validates every register atom, because human-authored PRDs never pass through the write path. Failures are product clarifications quoting the atom verbatim with candidate rewrites.
-- **Verify time** — `verify-prd` / spec-conformance consume the atoms; fit criteria become the conformance checks.
-
-Downstream, ticket gate S16 quotes these atoms verbatim and `prd-ticket-coverage` audits atom→ticket coverage — both degrade when "one requirement" is secretly three welded together.
-
-Full rationale, the vagueness lexicon, and worked rewrites: [the reference body of this rule](prd-definition-of-ready-reference.mdc).

package/plugins/lisa-cursor/rules/prd-lifecycle-rollup.mdc

@@ -1,36 +0,0 @@
----
-description: "PRD Lifecycle Rollup & Generated-Top-Level-Work Contract (load-bearing)"
-alwaysApply: true
----
-
-# 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](prd-lifecycle-rollup-reference.mdc).

package/plugins/lisa-cursor/rules/pre-flight-autofill.mdc

@@ -1,89 +0,0 @@
----
-description: "Pre-Flight Spec Autofill — Draft-Then-Block (load-bearing)"
-alwaysApply: true
----
-
-# 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](pre-flight-autofill-reference.mdc).

package/plugins/lisa-cursor/rules/project-learnings.mdc

@@ -1,27 +0,0 @@
----
-description: "Project Learnings (load-bearing)"
-alwaysApply: true
----
-
-# 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](project-learnings-reference.mdc).

package/plugins/lisa-cursor/rules/promotion-contract.mdc

@@ -1,23 +0,0 @@
----
-description: "Promotion Contract (load-bearing)"
-alwaysApply: true
----
-
-# 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](promotion-contract-reference.mdc).

package/plugins/lisa-cursor/rules/readiness-rubric.mdc

@@ -1,63 +0,0 @@
----
-description: "Repository Readiness Rubric (load-bearing)"
-alwaysApply: true
----
-
-# 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](readiness-rubric-reference.mdc).

package/plugins/lisa-cursor/rules/ready-role-filing.mdc

@@ -1,34 +0,0 @@
----
-description: "Ready-Role Filing (load-bearing)"
-alwaysApply: true
----
-
-# 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](ready-role-filing-reference.mdc).

package/plugins/lisa-cursor/rules/rejection-detection.mdc

@@ -1,69 +0,0 @@
----
-description: "Rejection Detection at Claim Time (load-bearing)"
-alwaysApply: true
----
-
-# 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](rejection-detection-reference.mdc).

package/plugins/lisa-cursor/rules/repo-scope-split.mdc

@@ -1,48 +0,0 @@
----
-description: "Repo Scope & Work-Time Splitting (load-bearing)"
-alwaysApply: true
----
-
-# 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](repo-scope-split-reference.mdc).