@codyswann/lisa 2.345.0 → 2.346.0

package/plugins/lisa-copilot/rules/reference/reset-seed-coverage.md

@@ -0,0 +1,231 @@
+# Reset/Seed Coverage & State Classification
+
+Automated suites create state, and the state outlives them. The historical pattern is per-flow
+self-cleanup: a flow creates a uniquely-marked record at the top and deletes it as its last step, so
+the record survives every failure that happens in between. Nothing sweeps the survivors and nothing
+reports them, so the leak is invisible until a list view, a uniqueness constraint, a pagination
+boundary, or an exact-count assertion breaks — at which point it presents as a product bug or an
+unreproducible flake. The same story has now played out on several entity types in several
+codebases, always with the same three ingredients: state a suite creates, cleanup that only runs on
+the happy path, and no inventory that would have noticed.
+
+This contract removes the discipline requirement. Instead of asking every author to remember to
+sweep what they created, it makes the *absence* of a decision a failing check.
+
+It is a **single vendor-neutral contract** consumed by `lisa-research` (specs state what persistent
+state the work introduces), `lisa-acceptance-criteria` and `lisa-task-decomposition` (the
+classification and the sweep are explicit deliverables on the work item, not implied work),
+`lisa-test-strategy` and `lisa-implement` (building the item includes both),
+`lisa-codify-verification` (the verify step asserts the post-reset baseline), and
+`lisa-verification-lifecycle` / `lisa-verify` (the check is run, and a miss fails the item). Those
+skills cite this slug; they do not restate it.
+
+## Vendor neutrality is the point
+
+This contract never names a database engine, a cloud, an identity provider, an object store, a
+search engine, a queue, or a test runner. Projects use different ones, several at once, and change
+them without touching this contract. What is fixed is the *obligation*: every entity that holds
+state across process boundaries carries exactly one policy, and the running system's inventory is
+compared against that declaration.
+
+The words "table" and "row" appear in this document only as examples. An entity is anything with a
+durable identity and a lifetime: a table, a collection, a bucket prefix, an index, a topic, a
+user-pool group, a materialized view, a scheduled job.
+
+## Why "new entities are cleared by default" is the wrong safety model
+
+An earlier version of this pattern derived the clear-list by subtracting a hand-maintained keep-list
+from a schema listing: anything new is cleared unless someone deliberately exempts it. It is
+attractive because it fails toward action, and the failure it prevents (a new entity silently
+accumulating) is real. It is still wrong as the *boundary*, for reasons that are structural rather
+than stylistic:
+
+- **It erases unrelated data on first contact.** The first change that adds an entity nobody has
+  classified deletes its contents on the next run, in whatever non-production environment happened
+  to run first. "Non-production" is not "worthless" — shared development environments hold hand-built
+  scenarios, support reproductions, and partner sandboxes.
+- **A migrations-directory diff does not model reality.** It cannot see renames (which read as one
+  deletion plus one unclassified addition), multiple schemas or namespaces, framework- or
+  ORM-generated entities that no migration file names, views, partitions and inheritance children,
+  entities created by a deploy rather than a migration, or row-level ownership — the common case
+  where an entity holds both fixture rows and rows that must survive.
+- **It only sees the database.** Identity-provider accounts, object-storage prefixes, search indexes,
+  queue backlogs, and third-party side effects are invisible to it, and those are precisely where
+  leaked test state is most expensive.
+
+Subtraction survives in this contract as a **detector**: run it, and treat every entity it finds
+that the contract has not classified as a finding. The safety decision is the classification.
+
+## The state contract
+
+Default location `state/state-contract.json` (a project with an equivalent artifact keeps its own
+path and records it in `.lisa.config.json`). It is checked in, reviewed like code, and versioned:
+
+| Field | Meaning |
+|---|---|
+| `schemaVersion` | The schema this document conforms to. Pinned; a bump is a deliberate migration. |
+| `contractVersion` | The project's own version for *its* declared state. Bumped whenever policies or ownership predicates change, so evidence from one run cannot be read as evidence for a different contract. |
+| `mode` | `contract` (the normal case) or `declared-noop`. |
+| `owner` | Who answers questions about this file. A team or role, not an individual's personal account. |
+| `environments` | The environments a reset may target, and the identity source each is resolved from. Never a list the caller can extend at runtime. |
+| `fixtureIdentity` | How fixture-owned records are recognized: reserved id shape, reserved account/namespace, marker attribute. This is the ownership predicate the whole model rests on. |
+| `entities[]` | One entry per persistent entity. |
+| `assurances` | The required properties below, each with a pointer to the evidence that proves it. |
+| `waivers[]` | Dated IOUs for entities that genuinely cannot be classified yet. |
+
+Each `entities[]` entry carries `id` (stable, fully qualified — namespace plus name), `kind` (the
+project's own vocabulary for what sort of state it is), `policy` (one of the four), `reason` (why,
+in one sentence a reviewer can check), `owner`, and policy-specific obligations:
+
+- `fixture-owned` → `ownership` (the predicate identifying rows/objects the reset may delete) and
+  `sweptBy` (the routine that removes them). An entity classified `fixture-owned` with no sweep is
+  the exact leak this rule exists to catch and fails the check.
+- `preserve` → `reason` must name the provenance (migration-seeded, ingested catalog, human-authored,
+  belongs to a real person) and, where available, `enforcedBy`.
+- `derived-rebuild` → `rebuiltFrom` (the sources) and `rebuiltBy` (the routine). The reset rebuilds
+  and proves convergence rather than clearing.
+- `forbidden` → `enforcedBy` is **required** and must name a control outside the reset process: a
+  least-privilege role, a revoked grant, a separate credential or account boundary, a database
+  constraint. "The script does not touch it" is not an enforcement.
+
+### Waivers are dated IOUs, never classifications
+
+An entity nobody can classify today is recorded with its id, a reason, an owner, a ticket, and a
+`recordedAt` date. It stays visible in the report, it never counts as classified, and it never
+authorizes the reset to touch the entity — a waived entity is treated as `preserve` for safety while
+remaining a finding. A waiver is invalid, and fails the check, when it names an entity that is not in
+the inventory, duplicates an existing classification, or carries no owner, ticket, or date.
+
+## The check
+
+The check compares a **runtime inventory** — what the system actually holds, enumerated from the
+running environment — against the contract. Static sources are inputs to discovery, never a
+substitute for the inventory: the whole point is to catch what the repository does not describe.
+
+Semantics, in order:
+
+1. **Contract absent** → `not-adopted`. Reported visibly, exits 0, and the context is not required.
+   Adoption is an explicit act; a not-yet-adopted repo is not silently passing a gate it never wired.
+2. **Contract malformed, unparseable, or failing schema validation** → fail. A broken contract is
+   never treated as an empty one.
+3. **`mode: "declared-noop"`** → the noop must carry a reason, an owner, and a capability-manifest
+   reference, **and** the detectors must find no persistence signals in the repository. A repo with
+   persistence cannot declare a reset noop; the check rejects it rather than trusting the
+   declaration.
+4. **Entity in the inventory with no classification and no waiver** → **fail closed**, naming the
+   entity. This is the primary failure this contract exists to produce.
+5. **Entity classified but absent from the inventory** → fail as stale, unless the entry is marked
+   retired with a date. A contract that describes a system that no longer exists is not protection.
+6. **Policy obligations unmet** — `fixture-owned` with no ownership predicate or no sweep,
+   `forbidden` with no external enforcement, `derived-rebuild` with no rebuild routine → fail.
+7. **A required assurance missing or unevidenced** → fail.
+8. **Detector findings that the inventory did not surface** (a schema or migration source naming an
+   entity the inventory did not return) → fail, because it means the inventory is incomplete and
+   every other conclusion is unsound.
+9. **No inventory available** → `detection-only`. The detectors run, findings are reported, and the
+   result is explicitly labeled non-authoritative. It never reports the same status as a verified
+   run, and it never satisfies the definition of done on its own.
+
+Every exit path emits the standard command envelope, so a caller can tell "verified clean" from
+"could not look" without parsing prose.
+
+### Non-database discovery
+
+The inventory is only complete when it enumerates every kind of state the project holds. At minimum,
+discovery asks each of these and records either the enumeration or a documented absence: identity
+provider (accounts, groups, memberships, long-lived sessions and devices), object storage (buckets
+and prefixes written by the app or by tests), search indexes and their aliases, queues and topics
+including dead-letter backlogs, caches with a persistence tier, derived views and projections,
+runtime-created scheduled jobs and webhooks, feature-flag and configuration overrides, and outbound
+side effects (email, SMS, billing, analytics events, third-party records). "We checked and there is
+none" is an acceptable answer and must be written down; not asking is not.
+
+## Required assurances
+
+These are the properties a reset must have. Each is declared in `assurances` with a pointer to the
+test, guard, or role that proves it — a declaration with no evidence pointer fails the check.
+
+| Assurance | What it means | Why |
+|---|---|---|
+| `preserves-non-fixture-data` | Catalog, reference, and any non-fixture data survive a reset unchanged. | The expensive-to-rebuild data is usually the data a blunt reset destroys, and it is often not restorable by re-running any seed in the repo. |
+| `rejects-reserved-id-collision` | A reserved fixture identifier that collides with a real record aborts rather than overwriting. | The ownership predicate is the entire safety boundary; a collision means it is no longer identifying. |
+| `rejects-foreign-references` | A fixture record referencing a preserved record it does not own is refused, never cascaded. | Cascades are how a fixture-scoped delete reaches outside its scope. |
+| `requires-write-acknowledgment` | Every mutation is confirmed by the system, not assumed from a returned status. | An unacknowledged write is an unknown state, and "unknown" reported as success is how a half-applied reset becomes a mystery failure downstream. |
+| `converges-on-second-apply` | Applying twice produces the same state and the second run reports no further change. | Convergence is what makes the reset safe to re-run, and re-running is what makes partial failure recoverable. |
+| `verifies-exact-counts` | Verification asserts the exact expected count per fixture entity. | "At least one" passes against a leak. Exact counts are what detect one. |
+| `production-fails-closed` | Production is refused with no override, escape hatch, or environment variable that changes the answer. | A single variable that authorizes production mutation will eventually be set by something that is not a person. |
+| `guard-at-the-choke-point` | The environment check runs immediately before every outbound mutation, not only at startup. | A startup-only check does not survive a refactor that adds a second code path. |
+| `enumerates-before-mutating` | `--dry-run` enumerates exactly what would change and fails on anything whose ownership it cannot establish. | Unknown ownership must block, not default to delete. |
+
+Prefer platform enforcement over process enforcement wherever it exists: a role that cannot see the
+forbidden entities, grants revoked rather than merely unused, constraints that make a cross-boundary
+reference impossible, separate credentials per environment. A test proves the code behaves today; a
+revoked grant makes the behavior unavailable.
+
+## Standard command envelope
+
+Every adapter in this family — reset, seed, verify, inventory, classification check — returns **one**
+JSON object on stdout and nothing else. Human-readable narration goes to stderr, redacted of secrets
+and personal data.
+
+```json
+{
+  "schemaVersion": "lisa-command-envelope-v1",
+  "capability": "<reset|seed|reset-verify|state-inventory|state-classification|...>",
+  "mode": "<real|declared-noop|not-applicable>",
+  "operation": "<the operation performed>",
+  "environment": "<server-resolved environment identity>",
+  "contractVersion": "<the project's state-contract version>",
+  "dryRun": true,
+  "status": "<completed|no-op|denied|invalid|failed|verification-mismatch|not-adopted|detection-only>",
+  "correlationId": "<stable id joining logs, audit records, and CI output>",
+  "summary": { "deleted": 0, "created": 0, "preserved": 0 }
+}
+```
+
+Rules that make the envelope load-bearing rather than decorative:
+
+- **Exit 0 means completed *and* verified.** Any nonzero exit means denied, invalid, failed, or
+  verification-mismatch, and the envelope's `status` says which. An adapter that mutated successfully
+  but could not verify exits nonzero.
+- **`--dry-run` is mandatory for every destructive adapter**, enumerates the intended mutations, and
+  fails on any entity whose ownership it cannot establish.
+- **`--stage` (or equivalent) is a *request*, never the source of truth.** The adapter resolves the
+  environment from server-side deployment identity and fails if the request disagrees. A
+  caller-supplied stage, URL, host, or public build-time variable never authorizes a destructive
+  operation.
+- **`--idempotency-key` is required in CI**, so a retried invocation is recognized rather than
+  repeated.
+- **A noop returns `mode: "declared-noop"`** with a reason, an owner, and a capability-manifest
+  reference. A bare exit 0 with no envelope is indistinguishable from a successful destructive run
+  and is never an acceptable noop.
+- **`correlationId` appears in the envelope, the audit record, and the CI log**, so a run can be
+  reconstructed after the fact.
+- The audit record for a destructive run additionally names the actor, the CI run, the resolved
+  environment and account, the contract version, and before/after counts — and contains no secrets
+  or personal data.
+
+## Bootstrap procedure
+
+1. Enumerate the runtime inventory from a non-production environment, including the non-database
+   sources listed above. Record what could not be enumerated and why.
+2. Classify every entity. Start from provenance: who writes it, and can anything put it back? Prefer
+   `preserve` when unsure — an over-preserved entity leaks; an over-cleared one destroys.
+3. Declare `fixtureIdentity` and the ownership predicate before classifying anything as
+   `fixture-owned`.
+4. Write the assurances with pointers to the tests or roles that prove them. Missing evidence is a
+   work item, not a field to leave blank.
+5. Wire the check into CI so the next unclassified entity fails the pull request that introduces it.
+6. Record everything still unclassified as dated waivers with owners, and burn them down.
+
+The first work item does not backfill the whole system. It classifies what it touches, scaffolds the
+file, and turns the check on; everything else is burndown that stays visible.
+
+## What this contract does not do
+
+It does not decide *how* a reset is executed, where it runs, or what invokes it. It does not
+prescribe intra-run isolation. It does not replace a threat model for a destructive control plane —
+where a reset is reachable from CI, that control plane has its own security obligations (identity,
+least privilege, leases, audit) which this contract assumes rather than specifies. What it
+guarantees is narrower and load-bearing: **no persistent state exists in the system that nobody has
+decided about, and no work item adds some without saying so.**

package/plugins/lisa-copilot/skills/lisa-acceptance-criteria/SKILL.md

@@ -65,6 +65,7 @@ For each acceptance criterion:
 - Every user flow must include at least one error path
 - Use Gherkin format (Given/When/Then) for user flows to enable direct translation into test cases
 - For frontend work, the `bdd-e2e-coverage` rule applies: name the scenario IDs the item will add or change in the project's behavior contract and the platforms each must hold on, and list the contract update plus the aligned e2e automation as explicit acceptance criteria -- they are deliverables, not implied work. List the passing coverage gate and the regenerated matrix and burndown as explicit acceptance criteria too -- the item is not done on a code-complete mapping alone
+- For work that adds or changes persistent state, the `reset-seed-coverage` rule applies: name the persistent entities the item introduces or changes and the reset policy each takes (`fixture-owned` / `preserve` / `derived-rebuild` / `forbidden`), and list the state-contract update, the sweep for anything `fixture-owned`, and the passing state-classification check as explicit acceptance criteria -- they are deliverables, not implied work. Rows are only one kind of state: identity-provider objects, object storage, search indexes, queues, caches and derived views count too
 - When verifying, always run the feature -- never review by only reading code
 - If you cannot run the feature (missing dependencies, services unavailable), report as a blocker -- do not guess
 - If the changes are purely internal (refactoring, config, tooling), report "No user-facing impact" and explain why

package/plugins/lisa-copilot/skills/lisa-codify-verification/SKILL.md

@@ -83,6 +83,10 @@ For **frontend work** — any verification whose validation journey exercised a
 
 Every artifact encodes the SAME verified journey against a different platform. One is never a substitute for another, and a passing test on one platform never seals another platform's obligation.
 
+### 2b. Codifying persistent state (non-demotable)
+
+When the verified journey **created, changed, or depended on persistent state**, the `reset-seed-coverage` rule governs what else this codification owes. Classify every entity the work touched in the project's state contract, give anything `fixture-owned` an ownership predicate and a sweep, and run the project's state-classification check the same way the coverage gate is run above — a contract edited but never checked is not proof. Where the journey depended on seeded state, the seed's verify step asserts **exact expected counts** for that state: "at least one" passes against a leak, which is precisely the condition being guarded. Cite the rule for the policy vocabulary and the assurances; do not restate them here.
+
 Permitted exits, mirroring the regression-spec rule in `lisa-implement` (never a silent skip, never "optional", and never a bare `N/A`):
 
 - The project genuinely has no runner configured for that platform → record a dated `platformWaivers` entry naming the locations checked and "no runner configured" as the reason, exactly like any other unsealable obligation, per the rule. This is never left as a bare `N/A` — an undated absence has no forcing function to ever get revisited.

package/plugins/lisa-copilot/skills/lisa-implement/SKILL.md

@@ -149,6 +149,8 @@ IF it is a Fix (bug), execute the Reproduce sub-flow FIRST:
 
 For any Fix flow, and for any Build flow that changes user-visible behavior, regression coverage is a required deliverable at the highest practical observation level for the reported surface. If the project has a browser, device, or end-to-end harness for that platform (for example Playwright, Maestro, Detox, Cypress, or an equivalent runtime), the task plan and definition of done MUST include a deterministic regression spec against the reported surface, using mocked or seeded data where needed. This is alongside unit or integration coverage, not a substitute for it. For **frontend work** the deliverable is defined by the `bdd-e2e-coverage` rule and has two halves, both landing in this PR: the Gherkin scenario (stable ID, required platforms) added or updated in the project's behavior contract, and aligned automation in the project's configured runner for **every** platform that scenario requires — no runner substitutes for another, because they guard different platforms of the same behavior. The coverage gate must pass and the matrix and burndown be regenerated before the item is done. Cite the rule; do not restate its scenario, waiver, or bootstrap mechanics here.
 
+For work that adds or changes **persistent state**, the `reset-seed-coverage` rule adds a second non-demotable deliverable landing in this same PR: every entity the item introduces or changes is classified in the project's state contract (`fixture-owned` / `preserve` / `derived-rebuild` / `forbidden`) with a reason and an owner, anything `fixture-owned` declares its ownership predicate and is actually swept, and the state-classification check passes. Writing a flow that creates a record and deletes it only on its happy path does NOT satisfy this — that is the leak, not the coverage. Cite the rule; do not restate its policy, waiver, or bootstrap mechanics here.
+
 The team lead may not waive, defer, demote, or phrase this regression spec as "optional", "if cheap", "nice to have", or equivalent. The only permitted exits are:
 
 1. The project genuinely has no end-to-end harness for the affected platform; record the checked locations and that absence in the task metadata, PR, and work-item evidence.

package/plugins/lisa-copilot/skills/lisa-parity-safety-net-rules/SKILL.md

@@ -2,7 +2,7 @@
 name: lisa-parity-safety-net-rules
 description: "View, set, and verify the custom guard rules enforced by Lisa's safety-net PreToolUse Bash hook (parity-safety-net.sh). The consolidated cross-agent equivalent of the upstream safety-net plugin's set-custom-rules + verify-custom-rules skills — manages a project-local list of extended-regex patterns that block destructive shell commands, on Codex, agy, Copilot, Cursor, and Claude."
 allowed-tools: ["Read", "Edit", "Write", "Bash"]
-synced-from: safety-net@cc-marketplace@2.0.1
+synced-from: safety-net@cc-marketplace@2.0.3
 ---
 
 # Parity Safety-Net Rules
@@ -24,12 +24,17 @@ project-specific rules on top of those built-ins.
 > against Lisa conventions — it does **not** port or invoke upstream plugin
 > code.
 >
-> **Drift tracking.** Pinned to `safety-net@cc-marketplace@2.0.1`.
+> **Drift tracking.** Pinned to `safety-net@cc-marketplace@2.0.3`.
 > `scripts/plugin-parity-drift.mjs` compares this pin against the upstream
 > version in the plugin cache and flags staleness. **Do not port or copy upstream
 > plugin code.**
 >
-> **Known gap at the 2.0.1 pin.** Upstream 2.0.0 rebuilt its engine and added two
+> **2.0.3 review.** Upstream 2.0.2–2.0.3 added Kimi Code and Amp installation
+> support and release tooling. Those changes do not alter the upstream
+> rule-management skill or Lisa's project-local ERE rule contract, and Lisa does
+> not currently ship hooks for those runtimes, so no behavior is absorbed here.
+>
+> **Known gap at the 2.0.3 pin.** Upstream 2.0.0 rebuilt its engine and added two
 > guard families this hook does **not** mirror: `secret.*` (blocks reading or
 > copying SSH keys, `.env` files, cloud credentials, and coding-CLI credential
 > stores) and `rm.git-metadata` (blocks deleting the `.git` control plane). Both

package/plugins/lisa-copilot/skills/lisa-parity-sentry-sdk-setup/SKILL.md

@@ -2,7 +2,7 @@
 name: lisa-parity-sentry-sdk-setup
 description: "Install and configure the Sentry SDK for a project — detect the framework/runtime, add the correct @sentry/<framework> package, initialize the client, wire the DSN through env, enable error + performance monitoring, and set up source map upload for readable stack traces. One consolidated skill covering react, nextjs, node, nestjs, express, python, django, react-native, and more. Lisa-native reimplementation of Sentry's SDK-setup suite. Use when adding Sentry to a project or fixing an existing Sentry install."
 allowed-tools: ["Read", "Edit", "Write", "Bash"]
-synced-from: sentry@claude-plugins-official@1.3.1
+synced-from: sentry@claude-plugins-official@1.3.2
 ---
 
 # Sentry SDK Setup
@@ -19,7 +19,7 @@ setup skills**; this single Lisa-native skill consolidated all of them. As of
 upstream **1.2.0** Sentry itself consolidated the suite into one
 `sentry-instrument` playbook, so the shapes now match — but this skill remains a
 from-scratch reimplementation against Lisa conventions, **not** a translation of
-the upstream skill. Pinned to `sentry@claude-plugins-official@1.3.1` via
+the upstream skill. Pinned to `sentry@claude-plugins-official@1.3.2` via
 `synced-from` so the parity drift detector tracks it as one unit.
 
 ## Step 0 — Scope the install
@@ -211,6 +211,16 @@ build time:
 - Tie uploads to a **release** identifier (commit SHA or version) and inject the
   same release into `Sentry.init({ release })` so traces map to the right build.
 
+## Step 6a — Name custom telemetry consistently
+
+When adding custom span or log attributes, use the current stable Sentry
+semantic-convention key for that domain when one exists. Sentry conventions are
+aligned with OpenTelemetry in many domains, but Sentry's current convention is
+authoritative for data sent to Sentry. Consult only the relevant domain in the
+official convention reference, omit deprecated keys, and do not invent a second
+name for an established attribute. Keep values low-cardinality and never attach
+secrets, credentials, request bodies, or unnecessary personal data.
+
 ## Step 7 — Verify
 
 - Build/typecheck to confirm the SDK wiring compiles:
@@ -230,5 +240,7 @@ build time:
 - Initialize Sentry before any other application code runs.
 - Tune sample rates for the environment — do not ship `tracesSampleRate: 1.0` to
   high-traffic production by default.
+- Prefer current Sentry semantic-convention keys for custom span and log
+  attributes; do not use deprecated keys or invent aliases for established ones.
 - Verify with a real captured event and a source-mapped trace before declaring
   setup complete.

package/plugins/lisa-copilot/skills/lisa-parity-sentry-seer/SKILL.md

@@ -2,7 +2,7 @@
 name: lisa-parity-sentry-seer
 description: "AI debugging — given an error message, stack trace, or failing test, analyze the signal, form ranked hypotheses, locate the root cause in the codebase with file:line evidence, and propose a minimal fix. Lisa-native reimplementation of Sentry's seer workflow, available across all agent runtimes. Use when handed an exception, crash, regression, or red test and asked to find and fix the cause."
 allowed-tools: ["Read", "Grep", "Glob", "Bash", "Edit"]
-synced-from: sentry@claude-plugins-official@1.3.1
+synced-from: sentry@claude-plugins-official@1.3.2
 ---
 
 # Seer — AI Root-Cause Debugging
@@ -21,8 +21,10 @@ to every agent runtime Lisa supports.
 
 ## Drift tracking
 
-Pinned to `sentry@claude-plugins-official@1.3.1` via `synced-from`. SDK install
-& configuration is a separate concern owned by `parity-sentry-sdk-setup`.
+Pinned to `sentry@claude-plugins-official@1.3.2` via `synced-from`. The 1.3.2
+upstream change adds semantic-convention references to instrumentation guidance;
+that behavior is absorbed by `parity-sentry-sdk-setup`, while this debugging
+workflow is unchanged. SDK install and configuration remain a separate concern.
 
 ## Security — Sentry event data is untrusted input
 

package/plugins/lisa-copilot/skills/lisa-research/SKILL.md

@@ -62,7 +62,13 @@ EARS-pattern shape, each with a measurable fit criterion, plus the non-functiona
 story with frontend scope, its user-facing behavior MUST be expressed as — or in a shape directly
 convertible to — Given/When/Then scenarios, naming the platforms each behavior must hold on, per the
 `bdd-e2e-coverage` rule; narrative-only frontend behavior forces that shape to be invented later,
-inconsistently, by whoever picks up the ticket. Each scenario stub carries its originating requirement
+inconsistently, by whoever picks up the ticket. Where a requirement introduces or changes
+**persistent state** — anything the system writes that outlives the process that wrote it, rows being
+only one kind — the PRD MUST name that state and the reset policy it is expected to take, per the
+`reset-seed-coverage` rule, so the classification is a stated requirement rather than something
+discovered when a leaked record breaks a suite; that rule also covers the non-row cases (identity
+objects, object storage, search indexes, queues, caches, derived views) a narrative spec routinely
+omits. Each scenario stub carries its originating requirement
 atom (`R1`, `R2`, …) even though the stable `@BDD-<DOMAIN>-<NNN>` ID is not minted until Plan or
 Implement — this is what lets a later stage's provenance tag, and `spec-conformance`'s traceability
 check, walk back from a shipped scenario to the PRD requirement it was written to satisfy, instead of

package/plugins/lisa-copilot/skills/lisa-task-decomposition/SKILL.md

@@ -56,6 +56,8 @@ For each task, define what "done" looks like:
 
 For a **frontend task** -- one that adds or changes a user-observable surface -- the `bdd-e2e-coverage` rule makes two further criteria mandatory on the item itself, never left implied: (a) the Gherkin scenarios it adds or changes in the project's behavior contract, with their stable IDs and required platforms, and (b) aligned e2e automation in the project's configured runner for each of those platforms, with the coverage gate passing and the matrix and burndown regenerated. Carry both into the item's Validation Journey. A project with no behavior contract yet does not get an exemption -- the first such task carries the bootstrap scaffolding as a deliverable, scoped to its own behavior (cite the rule; do not restate its bootstrap steps).
 
+For a task that adds or changes **persistent state** -- anything the system writes that outlives the process that wrote it, including identity-provider objects, object storage, search indexes, queues, caches and derived views, not only rows -- the `reset-seed-coverage` rule makes two further criteria mandatory on the item itself, never left implied: (a) every entity it introduces or changes is classified in the project's state contract with a reason and an owner, and (b) anything classified `fixture-owned` has a declared ownership predicate and an actual sweep, with the state-classification check passing. Carry both into the item's Validation Journey. A project with no state contract yet does not get an exemption -- the first such task carries the bootstrap scaffolding as a deliverable, scoped to its own state (cite the rule; do not restate its bootstrap steps).
+
 ### 3. Assign Verification Type
 
 Each task must have a verification method. Choose the most appropriate:

package/plugins/lisa-copilot/skills/lisa-test-strategy/SKILL.md

@@ -58,6 +58,7 @@ Structure findings as:
 - Always run `bun run test` to understand current test state before recommending or writing new tests
 - Match existing test conventions -- do not introduce new test patterns
 - For frontend work, the strategy is not complete until every required scenario-platform obligation has aligned e2e automation in the project's configured runner for that platform, or a dated waiver naming the runner limitation (`bdd-e2e-coverage`). A unit test, a route boot, or a passing test on a different platform never seals an obligation
+- For work that adds or changes persistent state, the strategy is not complete until each new entity is classified in the project's state contract and anything `fixture-owned` has a sweep, per the `reset-seed-coverage` rule. Per-flow self-cleanup is not a strategy: a flow that deletes what it created only on its happy path leaks on every failure in between, which is how state pollution becomes an unreproducible flake months later
 - Every test must have a clear "why" -- no tests for testing's sake
 - Focus on testing behavior, not implementation details
 - Verification commands must be runnable locally (no CI/CD dependencies)

package/plugins/lisa-copilot/skills/lisa-verification-lifecycle/SKILL.md

@@ -374,6 +374,7 @@ A task is done only when:
 - Proof artifacts are captured
 - Every passing empirical verification is codified as a regression test (or has an explicit, documented skip reason from the allowed set)
 - For frontend work, the `bdd-e2e-coverage` contract is satisfied: every user-facing behavior added or changed exists as a Gherkin scenario with a stable ID traceable to the work item, every required scenario-platform obligation is mapped to aligned e2e automation in the project's configured runner for that platform or carries a dated waiver, and the coverage gate passes with the matrix and burndown regenerated and committed. Missing BDD coverage is a verification failure, not a warning
+- For work that adds or changes persistent state, the `reset-seed-coverage` contract is satisfied: every entity introduced or changed is classified in the project's state contract with a reason and an owner, anything `fixture-owned` declares its ownership predicate and is actually swept, and the state-classification check passes in the same PR. An unclassified entity fails closed; per-flow self-cleanup is not coverage
 - For a leaf work unit, every typed `[EVIDENCE: <artifact-type>: <name>]` marker declared in its Validation Journey has a captured, non-empty artifact of the declared type attached to the ticket (the evidence manifest is fully satisfied)
 - Cross-work-item `EVIDENCE-REF` pointers were excluded from the local manifest and did not satisfy S14 or completion; a runtime-changing leaf has at least one local claiming marker
 - Spec conformance verdict is `CONFORMS` (not `PARTIAL`, not `DIVERGES`)

package/plugins/lisa-copilot/skills/lisa-verify/SKILL.md

@@ -35,7 +35,7 @@ Treat the first successful lead-spawn request (or, on the Codex fallback, the fi
 
 Execute the **Verify** flow as defined in the `intent-routing` rule (loaded via the lisa plugin). The flow includes:
 
-1. **Pre-flight: codification gate** — confirm that every passing local empirical verification on this branch was codified as a regression test (the Implement flow's codify step). If any verification has no committed test and no allowed skip reason (PR / Documentation / Deploy / Investigate-Only), invoke `codify-verification` now and amend the PR before shipping. For frontend work the gate additionally enforces the `bdd-e2e-coverage` rule: the shipped behavior exists as a Gherkin scenario with a stable ID, every required scenario-platform obligation has aligned automation in the project's configured runner for that platform or a dated waiver, and the project's coverage gate passes with the matrix regenerated. A missing runner is never a bare recorded absence — it needs a dated `platformWaivers` entry (per the rule) and, where the runner could reasonably be added, a linked build-ready follow-up ticket referenced from it; never a silent skip. Missing BDD coverage is a verification failure that blocks the ship, not a warning. A change cannot ship until its verifications are guarded.
+1. **Pre-flight: codification gate** — confirm that every passing local empirical verification on this branch was codified as a regression test (the Implement flow's codify step). If any verification has no committed test and no allowed skip reason (PR / Documentation / Deploy / Investigate-Only), invoke `codify-verification` now and amend the PR before shipping. For frontend work the gate additionally enforces the `bdd-e2e-coverage` rule: the shipped behavior exists as a Gherkin scenario with a stable ID, every required scenario-platform obligation has aligned automation in the project's configured runner for that platform or a dated waiver, and the project's coverage gate passes with the matrix regenerated. A missing runner is never a bare recorded absence — it needs a dated `platformWaivers` entry (per the rule) and, where the runner could reasonably be added, a linked build-ready follow-up ticket referenced from it; never a silent skip. Missing BDD coverage is a verification failure that blocks the ship, not a warning. A change cannot ship until its verifications are guarded. For work that adds or changes persistent state the gate additionally enforces the `reset-seed-coverage` rule: every entity the work introduces or changes is classified in the project's state contract, anything `fixture-owned` has an ownership predicate and a sweep, and the state-classification check passes — an unclassified entity fails closed and blocks the ship exactly as missing BDD coverage does.
 2. **Commit** any pending changes via `lisa-git-commit`
 3. **Push and PR** via `lisa-git-submit-pr`
 4. **PR Watch Loop** — drive the PR to MERGED via `lisa-drive-pr-to-merge`, the single source of truth for clearing every blocker: auto-merge with direct-merge fallback, `BEHIND` re-sync, conflict resolution, failing-check fixes, human + bot review-comment handling with thread resolution (it invokes `lisa-pull-request-review` itself), stale `CHANGES_REQUESTED` dismissal, and post-merge ancestry verification. Do not re-implement the loop or its terminal conditions.

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

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