@codyswann/lisa 2.345.1 → 2.348.0

package/plugins/src/base/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/src/base/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/src/base/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/src/expo/skills/ops-db-ops/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ops-db-ops
-description: Database migrations, reverts, schema generation, and GraphQL codegen for Expo + serverless backend projects. Operates on the backend (TypeORM) and frontend (GraphQL code generation).
+description: Database migrations, reverts, schema generation, GraphQL codegen, and the reset/seed/verify state operations for Expo + serverless backend projects. Operates on the backend (TypeORM) and frontend (GraphQL code generation).
 allowed-tools:
   - Bash
   - Read
@@ -8,9 +8,10 @@ allowed-tools:
 
 # Ops: Database Operations
 
-Manage database migrations, schema generation, and GraphQL code generation.
+Manage database migrations, schema generation, GraphQL code generation, and the project's
+reset/seed/verify state operations.
 
-**Argument**: `$ARGUMENTS` — operation (`migrate`, `revert`, `generate`, `schema`, `codegen`) and optional environment (default: `dev`)
+**Argument**: `$ARGUMENTS` — operation (`migrate`, `revert`, `generate`, `schema`, `codegen`, `seed`, `reset`, `reset:verify`, `state:inventory`, `state:classify`) and optional environment (default: `dev`)
 
 ## Path Convention
 
@@ -21,6 +22,21 @@ Manage database migrations, schema generation, and GraphQL code generation.
 
 **CRITICAL**: Never run migrations or reverts against production without explicit human confirmation.
 
+**Destructive state operations are stricter than that.** `reset` (and any `seed` that clears before
+it writes) is governed by the `reset-seed-coverage` rule and never runs on the strength of a
+confirmation alone:
+
+- Run `--dry-run` first, always, and read what it says it will change. A dry run that reports an
+  entity whose ownership it cannot establish is a STOP, not a warning.
+- The environment is whatever the adapter resolves server-side. A `--stage`, `TEST_ENV`, URL, host,
+  or public build-time variable is a *request* the adapter checks, never the answer. If the requested
+  stage and the resolved environment disagree, that is a refusal to investigate — not something to
+  re-run with a different flag.
+- **Production has no override, in any repo, ever.** There is no flag, variable, or confirmation
+  phrase that makes a production reset correct. If one appears to exist, stop and report it.
+- Never invent a reset. If the project ships no reset adapter, say so and stop; do not improvise
+  deletions with ad-hoc queries or the migration tooling.
+
 ## Discovery
 
 Read the backend `package.json` to discover available migration and schema scripts:
@@ -31,10 +47,22 @@ Read the backend `package.json` to discover available migration and schema scrip
 - `generate:sql-schema*` — regenerate SQL schema for MCP
 - AWS credential/profile scripts such as `aws:signin:*` and any environment-backed remote profile
 
+Read the backend and frontend `package.json` to discover the state operations. Discover them; do not
+assume these exact names — a project may expose them under its own, and this skill runs whatever the
+project declares:
+- `db:seed` / `seed:*` — write the fixture baseline
+- `db:reset` / `reset:*` — converge state back to that baseline
+- `db:reset:verify` / `reset:verify:*` — prove the post-state, by exact counts
+- `state:inventory` — enumerate what the running environment actually holds
+- `check:state-classification` — compare that inventory against the state contract
+
 Read the frontend `package.json` to discover codegen scripts:
 - `fetch:graphql:schema:*` — fetch GraphQL schema
 - `generate:types:*` — generate TypeScript types
 
+If a state script the operation needs does not exist, report the absence and the scripts that DO
+exist. Do not substitute a different script, and do not fall back to running SQL by hand.
+
 ## AWS Prerequisite
 
 All database operations (except `codegen`) require AWS credentials. Verify the target profile first:
@@ -113,11 +141,74 @@ STAGE={env} bun run generate:sql-schema
 
 **Note**: The backend must be running (locally or deployed) for schema fetching to work.
 
+### seed (write the fixture baseline)
+
+Run the project's discovered seed script for the target environment. A seed is additive or
+convergent, never a blind wipe; if the project's seed clears first, treat it as a reset and follow
+the reset sequence below.
+
+```bash
+cd "${BACKEND_DIR:-../backend-v2}"
+{package-manager} run {discovered-seed-script} --stage {env}
+```
+
+### reset (converge state back to the baseline)
+
+Never a single command. The sequence is fixed:
+
+1. **Dry run.** `{discovered-reset-script} --dry-run --stage {env}`. Read the enumeration. Stop on
+   any entity of unknown ownership, on any `forbidden`-classified entity appearing at all, and on
+   any disagreement between the requested stage and the resolved environment.
+2. **Classify first if the contract is stale.** If `check:state-classification` reports an
+   unclassified entity, the reset does not run — an unclassified entity is neither safe to keep nor
+   safe to delete. Fix the state contract, then start over at step 1.
+3. **Apply**, passing an idempotency key when running in CI:
+   `{discovered-reset-script} --stage {env} --idempotency-key {run-id}`.
+4. **Verify** with `reset:verify`. A reset that mutated but did not verify is a failure, not a
+   partial success.
+5. **Converge check.** Applying a second time must report no further change. If the second run keeps
+   deleting, the ownership predicate is wrong — report it rather than re-running.
+
+### reset:verify (prove the post-state)
+
+```bash
+{package-manager} run {discovered-verify-script} --stage {env}
+```
+
+Verification asserts **exact** expected counts per fixture entity. "At least one" passes against a
+leak, which is the condition being guarded.
+
+### state:inventory (enumerate what the environment actually holds)
+
+Produces the runtime inventory the classification check compares against. A complete inventory
+covers more than rows: identity-provider objects, object storage prefixes, search indexes, queues
+and dead-letter backlogs, caches with a persistence tier, derived and materialized views, and
+runtime-created jobs. Record anything that could not be enumerated, with the reason.
+
+### state:classify (compare the inventory to the contract)
+
+```bash
+node scripts/check-state-classification.mjs
+```
+
+Exit 0 = every entity the environment holds is classified and every policy obligation is met.
+Nonzero = an unclassified entity, an unswept `fixture-owned` entity, a stale classification, an
+incomplete inventory, or a missing assurance. Report the findings verbatim — each names the entity
+and what is missing.
+
 ## Output Format
 
+Every state operation returns the standard command envelope on stdout — one JSON object with
+`schemaVersion`, `capability`, `mode`, `operation`, `environment`, `contractVersion`, `dryRun`,
+`status`, `correlationId`, and `summary{deleted,created,preserved}`. Report from that envelope, not
+from prose scraped off stderr. A destructive operation that produced no envelope has not been
+verified, whatever its exit code said.
+
 Report operation result:
 
 | Operation | Environment | Target | Status | Details |
 |-----------|-------------|--------|--------|---------|
 | migrate | dev | local DB | SUCCESS | 2 migrations applied |
 | codegen | dev | frontend | SUCCESS | Types regenerated |
+| reset | dev | reset adapter | completed | deleted 12 / preserved 31, converged on second apply, correlation `abc123` |
+| state:classify | dev | state contract | failed | `public.notes` unclassified — fail closed |

package/scripts/check-state-classification.mjs

@@ -0,0 +1,27 @@
+#!/usr/bin/env node
+/**
+ * Lisa's own adopter entry point for the shipped state-classification check.
+ *
+ * Lisa holds no persistent state of its own, so there is nothing here to
+ * classify. What this file buys is that the *shipped* mechanism — the
+ * copy-overwrite script plus the `🧬 State Classification` job in the reusable
+ * quality workflow — runs on Lisa's own pull requests instead of only on
+ * adopters. Without it, a regression in the gate would ship silently and be
+ * discovered downstream.
+ *
+ * It points the check at `state/demo-project/`, a small worked example standing
+ * in for an adopter repo: a handful of entities across all four policies,
+ * including state that is not rows. A change that makes the check stop failing
+ * on an unclassified or unswept entity turns Lisa's own CI red.
+ *
+ * This is the same path `lisa apply` writes into an adopter (`scripts/`), so
+ * adopters get the file itself, not this wrapper.
+ * @module scripts/check-state-classification
+ */
+import { main } from "../all/copy-overwrite/scripts/check-state-classification.mjs";
+
+process.exitCode = main([
+  ...process.argv.slice(2),
+  "--root",
+  "state/demo-project",
+]);