@codyswann/lisa 2.282.0 → 2.284.0

package/plugins/lisa-cursor/rules/dependency-decision-records-reference.mdc

@@ -0,0 +1,145 @@
+---
+description: "Dependency Decisions"
+alwaysApply: false
+---
+
+# Dependency Decisions
+
+Lisa already governs dependency *mechanics* — pinning, audit gates, override
+resolution, duplicate detection. What those mechanics cannot tell anyone is
+**why** a dependency is in the project at all, what capability it owns, how much
+blast radius it has, or what would fail if a bad update shipped. Dependency
+decision records close that gap: they turn dependency posture into decisions an
+operator can read, instead of package-manager trivia only an engineer can
+interpret.
+
+## Where the record lives
+
+The governed record is the markdown file `.lisa/DEPENDENCY_DECISIONS.md` in the
+host project.
+
+It is distributed through Lisa's `all/create-only` template surface, so:
+
+- Every project that runs `lisa apply` receives the scaffold, regardless of
+  stack — the record is stack-independent because dependency posture is.
+- The strategy is **create-only**: Lisa seeds the file once and never overwrites
+  it. Host projects own their content outright, and Lisa upstream never carries
+  a copy of any host project's private dependency inventory.
+- It lives in the cold `.lisa/` directory rather than an auto-loaded rules tree,
+  so a long record is never injected raw into every session. Agents read the
+  entry they need, when they need it.
+
+Markdown is deliberate. The record's primary audience is the product gate, where
+a non-technical operator has to make a keep/replace/escalate judgment. A machine
+format would serve tooling and fail that reader.
+
+## What an entry must name
+
+Each material-dependency entry names nine things, in this order. Every label
+leads with the operator's question and keeps the technical term in parentheses,
+because the record's primary reader is looking for an answer, not a term:
+
+- **Why we keep it** — plain-language reason, written for a non-technical
+  reader, leading with the outcome it protects. This is deliberately the FIRST
+  bullet: an entry that opens with a version range opens with exactly the
+  package-manager trivia this record exists to replace.
+- **What it is (dependency)** — package or service, plus the version range in
+  use.
+- **What it does for us (owned capability)** — the single capability the
+  dependency is responsible for. A dependency with no nameable capability is
+  either not material, or is doing too much and should be split in the record.
+- **Why we believe it's safe (trust basis)** — the evidence that it will still
+  be maintained and safe next quarter: maintainer, release cadence,
+  security-response history, breadth of adoption, whether the version is pinned.
+- **What breaks if this is compromised (exposure)** — what it can reach and what
+  breaks when it misbehaves: build-time versus runtime, and whether it touches
+  user data, secrets, the network, or CI credentials.
+- **What it would take to replace (replacement cost)** — the honest effort to
+  remove or swap it, what would need rewriting, and whether a viable alternative
+  exists today.
+- **What would catch a bad update (detection evidence)** — the named check that
+  would **fail** if an update broke the owned capability: a test, suite,
+  workflow, or monitor. "Nothing would catch it" is a legitimate and high-value
+  answer.
+- **Who owns this and how often we recheck (owner / review cadence)** — who is
+  accountable, and how often the entry gets re-read.
+- **Last reviewed** — ISO `YYYY-MM-DD` date of the most recent actual review.
+
+## When to escalate
+
+The record exists to produce decisions, so three states are escalations rather
+than to-dos. Raise them to an owner instead of leaving them recorded:
+
+- Detection evidence says "nothing would catch it" — the capability is trusted
+  blind.
+- `Last reviewed` predates the dependency's last major upgrade — the record
+  describes software no longer running.
+- The trust basis names no maintainer, owner, or release history.
+
+An entry full of `_Not yet decided_` is not an escalation; it is unstarted work.
+These three are escalations precisely because someone already looked and the
+answer was bad.
+
+## What counts as material
+
+Material means: if this dependency vanished, broke, or shipped a hostile update,
+a user would notice, or replacing it would cost real time. Test frameworks,
+linters, HTTP clients, ORMs, auth libraries, UI toolkits, and build tooling are
+usually material. Transitive packages and single-function utilities usually are
+not — record the direct dependency that owns the capability, not everything
+underneath it.
+
+Do not attempt to record the whole lockfile. An exhaustive record decays into
+noise and stops being read, which is worse than a short record that is true.
+
+## Maintenance
+
+Update the relevant entry in the same change that adds a material dependency,
+upgrades one across a major version, or removes one. Refresh `Last reviewed`
+whenever someone actually re-reads an entry, even when nothing else changes — a
+stale date is the signal that the record has drifted from reality.
+
+When detection evidence fails for a dependency, treat the entry as the first
+place to look and the first place to correct: either the evidence was wrong
+about what it protects, or the exposure was understated.
+
+## Entry format
+
+Entries are uniform and appendable by design, because a later seeding pass adds
+them mechanically rather than by rewriting the document:
+
+- An entry is a level-3 heading (`### <name>`) followed by the nine field
+  bullets in the fixed order above.
+- Entries live under `## Records`, the final section of the file, and new
+  entries are appended to its end. A `###` heading inside `## Records` is always
+  an entry, never guidance — that scoping is what makes the section safe to
+  parse and append to.
+- `_Not yet decided_` is the reserved marker for a field nobody has answered
+  yet. Never leave a field blank and never guess: a blank field is
+  indistinguishable from an overlooked one, and a guess is a wrong answer that
+  nobody re-checks.
+
+Note that `_Not yet decided_` and "nothing would catch it" are different
+statements. The first means nobody has looked. The second is a finding — a real
+capability with no detection evidence behind it.
+
+## Scaffold, not inventory
+
+The seeded file is a scaffold: field structure, guidance, and one clearly marked
+worked example so an operator can see the intended shape. The example is meant
+to be replaced or deleted once real entries exist. Lisa does not pre-populate a
+host project's dependency inventory — only the project knows which of its
+dependencies are material.
+
+## Agent parity
+
+The record is a governed markdown artifact, not a runtime behavior, so every
+supported coding agent — Claude Code, Codex, Cursor, OpenCode, Antigravity, and
+Copilot — reaches it identically through the shared rules mirror and the same
+`.lisa/DEPENDENCY_DECISIONS.md` path in the host project. There is no per-agent
+enforcement surface to diverge.
+
+The documented gap, uniform across all six runtimes: no agent runtime enforces
+that entries stay accurate or current. Nothing blocks a commit whose dependency
+change skips the record, and nothing fails when `Last reviewed` goes stale.
+Freshness is carried by this rule and by review, not by a hook or a lint gate.

package/plugins/lisa-cursor/rules/dependency-decision-records.mdc

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

package/plugins/lisa-cursor/rules/dependency-trust-classes-reference.mdc

@@ -0,0 +1,248 @@
+---
+description: "Dependency Trust Classes"
+alwaysApply: false
+---
+
+# Dependency Trust Classes
+
+Without named classes, every third-party package sits in one implicit bucket:
+"we installed it, so presumably it's fine." That bucket makes a payment SDK and
+a code formatter look identical at review time, and it forces every dependency
+conversation to re-argue trust from first principles.
+
+Trust classes fix that. Each class states, in plain language, **why we can trust
+that kind of dependency**, and names **the one event that would trigger human
+review**. A dependency's class is the answer to the
+"Why we believe it's safe (trust basis)" field in
+`.lisa/DEPENDENCY_DECISIONS.md` — the record says what
+this dependency is and what would catch a bad update; the class says what bar it
+had to clear to be here at all.
+
+Exactly one class per dependency. If two seem to fit, take the lower-trust one —
+the requirements are strictly stronger, and being over-careful about a formatter
+costs a review cycle while being under-careful about an auth client costs users.
+
+## The five review inputs
+
+Every class fixes the same five inputs. What changes between classes is how
+demanding each one is:
+
+- **Capability owner** — who is accountable when this breaks. A role for
+  high-trust classes; a named person for low-trust ones, because "the platform
+  team" cannot be paged at 2am.
+- **Update cadence** — how often the entry is re-read and the version re-judged.
+- **Detection evidence** — the named check that fails if an update breaks the
+  owned capability. Stronger classes demand evidence *we* own, not upstream's
+  test suite.
+- **Replacement-cost threshold** — the point past which the cost itself is the
+  finding. High replacement cost is acceptable in a high-trust class and is an
+  escalation in a low-trust one.
+- **Product/human ratification** — whether a human has to say yes before the
+  dependency is added, upgraded, or kept. This is the gate, and it is deliberate
+  that the lower-trust and higher-exposure classes carry it.
+
+## The six classes
+
+### 1. Mature ecosystem primitive
+
+**Why we can trust it:** so many other projects depend on it that a bad release
+is usually found, reported, and fixed by someone else before it reaches us. It
+has an identifiable maintaining organization, a published release cadence, and a
+documented process for handling security reports. Trust here comes from the size
+of the crowd standing in front of us, not from us having read the code.
+
+Examples in kind: a language's canonical test runner, a foundation-maintained
+linter, a mainstream UI framework.
+
+- **Capability owner:** a role or team is sufficient.
+- **Update cadence:** re-read at each major upgrade, and at least every 12
+  months.
+- **Detection evidence:** an existing CI check must fail if the owned capability
+  breaks. Naming an upstream test suite is acceptable here and only here.
+- **Replacement-cost threshold:** high replacement cost is accepted. That is the
+  bargain — we take deep coupling in exchange for the crowd's scrutiny.
+- **Ratification:** not required to add or to take a minor/patch upgrade.
+
+**Human review is triggered when:** maintainership changes hands or the project
+is archived, or a security advisory goes unfixed past the project's own
+published response window. Either event removes the crowd, which was the whole
+basis for the trust — reclassify rather than re-trust.
+
+### 2. Fast-moving standard implementation
+
+**Why we can trust it:** it is the standard implementation of a protocol, spec,
+or platform we have deliberately decided not to own — a cloud SDK, an API
+client, a framework tracking a moving platform. We trust the *standard*; we do
+not trust the release we happen to be on, because the project moves faster than
+our review cycle does. Trust here is conditional on us keeping up.
+
+- **Capability owner:** a named team that owns staying current.
+- **Update cadence:** re-read at every minor upgrade, and no less than
+  quarterly. A dependency in this class going quiet for a year is itself a
+  finding.
+- **Detection evidence:** an automated test **we** own that exercises the owned
+  capability. Upstream's suite does not count — it tests their contract, not our
+  use of it.
+- **Replacement-cost threshold:** replacement cost must stay moderate. Keep the
+  coupling behind our own boundary so a forced migration is a rewrite of the
+  boundary, not of the application.
+- **Ratification:** required for any major upgrade that changes user-visible
+  behavior.
+
+**Human review is triggered when:** two consecutive major versions ship that we
+did not adopt inside the cadence window. At that point we are pinned to
+unsupported software and the decision — catch up, replace, or accept the
+exposure — belongs to a human.
+
+### 3. Build/development tool
+
+**Why we can trust it:** it never runs in production and never touches customer
+data. If it ships a bad update, developers notice within one build, and the
+worst case is lost engineering time rather than a user-visible failure. The
+blast radius is what earns the trust, not the maintainer.
+
+- **Capability owner:** a role or team is sufficient.
+- **Update cadence:** re-read at each major upgrade, and at least every 12
+  months.
+- **Detection evidence:** the build, lint, or test job the tool powers. It fails
+  loudly and immediately, which is the point.
+- **Replacement-cost threshold:** high cost is accepted — swapping a build tool
+  is disruptive but never urgent.
+- **Ratification:** not required.
+
+**Human review is triggered when:** the tool gains reach it did not have —
+running in production, reading secrets, or reading CI credentials. The moment
+that happens the blast-radius argument is void: reclassify it as a
+runtime-critical service client and apply that class's requirements immediately.
+
+### 4. Runtime-critical service client
+
+**Why we can trust it:** honestly, we mostly don't. This class covers anything
+that reaches users, their data, or money in production — payment SDKs, auth
+libraries, database drivers, service clients on the request path. Even a mature,
+well-run project lands in this class if a bad update reaches production, because
+maturity does not shrink blast radius. Trust here is bought with our own
+evidence and a human's signature, not the vendor's reputation.
+
+- **Capability owner:** a named accountable person, not a team.
+- **Update cadence:** re-judged at every version change. Versions are pinned
+  exactly, so upgrades are always deliberate.
+- **Detection evidence:** an integration or end-to-end test that exercises the
+  real capability, **plus** a production monitor that would notice failure in
+  the wild. "Nothing would catch it" is not an acceptable answer in this class —
+  it is a blocker.
+- **Replacement-cost threshold:** replacement cost must be written down, never
+  `_Not yet decided_`. If nobody can estimate it, we do not know how trapped we
+  are, and that unknown is the finding.
+- **Ratification:** **product/human ratification is required** before adding the
+  dependency and before any major upgrade.
+
+**Human review is triggered when:** any version changes, any security advisory
+is published, or the vendor has a service incident. Every one of those is a
+human decision in this class — that is what makes it the strictest.
+
+### 5. Thin wrapper suitable for in-house ownership
+
+**Why we can trust it:** it is small enough that we could read all of it in an
+afternoon and own it outright. Safety is not really the question; whether it is
+earning its keep is. A dependency we could write in a day still costs us a
+supply-chain entry, a transitive tree, and an upgrade obligation forever.
+
+- **Capability owner:** the team that would inherit the code if we in-housed it.
+  If no team will claim it, do not add it.
+- **Update cadence:** re-read at every upgrade — there should be few.
+- **Detection evidence:** our own unit tests covering the wrapped behavior. They
+  are cheap here precisely because the surface is small, and they are what makes
+  in-housing a one-day job later instead of a rewrite.
+- **Replacement-cost threshold:** roughly one day. Under it, the default is to
+  in-house the code rather than take the dependency.
+- **Ratification:** **required to keep it** when replacement cost is under the
+  threshold. Note the inversion: the human signs off on the *exception* — taking
+  a dependency we could trivially own — not on the removal.
+
+**Human review is triggered when:** the package goes unmaintained, or its
+transitive dependency tree grows larger than the code it wraps. Either way we
+are now carrying more supply chain than capability, and in-housing should be
+reconsidered on purpose.
+
+### 6. Temporary/experimental dependency
+
+**Why we can trust it:** we don't, and we say so. This class exists so a spike,
+a prototype, or a stopgap can move fast without silently becoming permanent. It
+is admitted on a clock: a written expiry date and a named exit — replace,
+in-house, promote to another class, or remove.
+
+- **Capability owner:** the person who introduced it, by name. Ownership does
+  not transfer to a team while the dependency is in this class.
+- **Update cadence:** reviewed at the stated expiry date, which is at most one
+  quarter out. No expiry date means it does not belong in this class.
+- **Detection evidence:** "nothing would catch it" is tolerated **only** while
+  exposure stays out of production. The moment it reaches production, the
+  runtime-critical requirements apply.
+- **Replacement-cost threshold:** must be low by construction. Anything
+  expensive to remove is not temporary — it is a permanent dependency wearing a
+  temporary label, and it should be classified honestly on day one.
+- **Ratification:** **required to extend past the expiry date** or to promote it
+  into any other class. An expiry that slides without a human saying yes is how
+  a prototype becomes production.
+
+**Human review is triggered when:** the expiry date passes, or the dependency
+starts running in production or touching user data — whichever happens first.
+
+## Ratification, summarized
+
+Ratification is not a formality; it is the point where a human owns the residual
+risk. Required for:
+
+- **Runtime-critical service client** — to add, and for every major upgrade.
+- **Temporary/experimental dependency** — to extend past expiry or to promote.
+- **Thin wrapper suitable for in-house ownership** — to keep it rather than
+  in-house it.
+- **Fast-moving standard implementation** — for a major upgrade that changes
+  user-visible behavior.
+
+Not required for mature ecosystem primitives or build/development tools on
+routine adds and upgrades. Those two classes are where the crowd and the blast
+radius do the work a human would otherwise have to do.
+
+## Naming a class at planning time
+
+A work item that proposes adding a new material dependency must, before it is
+buildable, name the dependency's trust class and state that it will update the
+`.lisa/DEPENDENCY_DECISIONS.md` entry in the same change. This is enforced at
+decomposition time by the `lisa-task-decomposition` skill, which rejects a work
+unit proposing a material dependency with no named class.
+
+The class is what makes the rest of the ticket reviewable: it tells the reviewer
+which evidence to demand and whether a human has to ratify before the work
+starts, rather than discovering both at the end.
+
+Naming a class is not a formality either. If nobody can pick one, that is the
+finding — an unclassifiable dependency is usually one nobody has thought about,
+and it should be resolved before the work item is accepted rather than after the
+package is installed.
+
+## Reclassification
+
+Trust classes describe the dependency as it is used today, not as it was
+introduced. When exposure changes — a build tool starts running in production, a
+prototype ships to users, a thin wrapper grows a large transitive tree — move it
+to the correct class and apply the new requirements immediately. Update the
+`Last reviewed` date on the record entry when you do.
+
+Reclassifying downward (to a lower-trust class) is never a demotion of the
+dependency. It is an admission that its blast radius grew, which is a fact about
+us, not about the maintainers.
+
+## Agent parity
+
+Trust classes are a governed markdown rule and a decomposition-time expectation,
+not a runtime behavior, so Claude Code, Codex, Cursor, OpenCode, Antigravity,
+and Copilot all reach them identically through the shared rules mirror and the
+same `lisa-task-decomposition` skill.
+
+The documented gap, uniform across all six runtimes: no agent runtime enforces
+that a dependency carries a correct class. Nothing fails a build when a package
+is installed with no class named, and nothing detects that a build tool quietly
+started running in production. Classification is carried by this rule, the
+decomposition skill, and review — not by a hook or a lint gate.

package/plugins/lisa-cursor/rules/dependency-trust-classes.mdc

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

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

@@ -74,6 +74,31 @@ Each task must have a verification method. Choose the most appropriate:
 - Prefer independent tasks that can run in parallel where possible
 - Flag external dependencies (other teams, services, permissions, data) that may block progress
 
+### 4.5. Classify Any New Material Dependency
+
+Step 4 maps dependencies *between tasks*. This step covers third-party
+dependencies a task proposes to **add**.
+
+A dependency is **material** if its failure, disappearance, or bad update would
+break something a user can see, or would cost real time to replace. If a work
+unit proposes adding one, the work unit must, before it is buildable:
+
+1. **Name its trust class** — exactly one of: mature ecosystem primitive,
+   fast-moving standard implementation, build/development tool, runtime-critical
+   service client, thin wrapper suitable for in-house ownership, or
+   temporary/experimental dependency. See the `dependency-trust-classes` rule
+   for what each class means and why it is trusted.
+2. **State the class's required evidence** — the detection evidence that class
+   demands, and whether product/human ratification is required before the work
+   starts. Runtime-critical service clients and expiry extensions on temporary
+   dependencies always require ratification; a work unit that needs it and does
+   not say so is not ready.
+3. **Include updating `.lisa/DEPENDENCY_DECISIONS.md`** in its acceptance
+   criteria, so the record entry lands in the same change as the dependency.
+
+If nobody can pick a class, that is the finding — resolve it before accepting
+the work unit, not after the package is installed.
+
 ### 5. Determine Execution Order
 
 - Place foundational tasks first (types, schemas, interfaces, shared utilities)
@@ -121,6 +146,7 @@ Map each task to the skills needed to complete it. This enables delegation to sp
 - Every task must have at least one acceptance criterion that can be empirically verified
 - Do not create tasks that cannot be verified -- if you cannot define how to prove it is done, the task is not well-scoped
 - Every Task / Bug / Sub-task / Improvement is scoped to exactly one repo -- if the work spans repos, split into per-repo work units under a shared parent Story (see step 1.5)
+- Any task proposing a new material dependency names its trust class, states that class's required evidence and whether human ratification is needed, and updates `.lisa/DEPENDENCY_DECISIONS.md` in the same change (see step 4.5) -- a proposed material dependency with no named class is not ready to build
 - Keep tasks ordered so that no task references work that has not been completed by a prior task
 - Flag any task that requires access, permissions, or external input not yet available
 - Prefer more small tasks over fewer large tasks -- smaller tasks are easier to verify and less risky to fail

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.282.0",
+  "version": "2.284.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"