@codyswann/lisa 4.62.4 → 4.64.0

package/plugins/lisa-copilot/scripts/automation-status-expected-fleet.mjs

@@ -41,6 +41,10 @@ export const AUTOMATION_EXPECTED_CADENCES = {
     human: "once a day",
     rrule: "FREQ=DAILY;INTERVAL=1",
   },
+  "starter-sync": {
+    human: "once a day",
+    rrule: "FREQ=DAILY;INTERVAL=1",
+  },
   "learnings-audit": {
     human: "once a week",
     rrule: "FREQ=WEEKLY;INTERVAL=1",
@@ -336,6 +340,17 @@ export function resolveExpectedAutomationFleet(input = {}) {
     );
   }
 
+  if (config.starter?.sync?.auto === true) {
+    expected.push(
+      createExpectedEntry(
+        identity,
+        "starter-sync",
+        "/lisa:starter-sync",
+        "opt-in"
+      )
+    );
+  }
+
   return {
     ...identity,
     expected,

package/plugins/lisa-copilot/skills/lisa-learnings-audit/SKILL.md

@@ -260,11 +260,20 @@ computed **deterministically — never estimated by the model**:
 
 1. **Normalize** the invariant text: trim leading/trailing whitespace,
    collapse every internal whitespace run to a single space, lowercase.
-2. **Hash** in Bash: `printf '%s' "$normalized" | shasum -a 256 | cut -c1-12`.
+2. **Hash** through the shared implementation: write the invariant to a text file
+   and run `lisa effectiveness fingerprint --input <file>`. This performs the
+   normalization above and returns the first 12 SHA-256 hex characters.
 
 The same knowledge item therefore always produces the same key across runs,
 regardless of which session computes it.
 
+Read `lisa effectiveness report` for committed post-control recurrence counts by
+the same `<surface>+<invariant-hash>` key. Cite the count and occurrence sources as
+evidence when deciding whether a control helped. Missing history means unknown,
+not a successful control. Counts do not automatically justify a new ticket: apply
+the existing worth-doing judgment. The learning entry's content-version fingerprint
+is a different identifier and must not be substituted for this invariant hash.
+
 Before filing anything, search the tracker for the marker in
 **open AND closed** issues — and key the search on the deterministic
 `<surface>` prefix **first**, using the hash as disambiguation only, so even

package/plugins/lisa-copilot/skills/lisa-queue-status/SKILL.md

@@ -69,6 +69,16 @@ For each inspected queue, report:
 
 The report should stay terminal-first and immediately actionable: observable queue facts first, then the smallest useful next step.
 
+## Delivery effort
+
+Alongside queue counts, run the read-only `lisa effectiveness report`. Show observed
+human interventions per accepted outcome, its numerator/denominator, and evidence
+sources. State that this covers locally observed outcomes; absent reports or null
+attention mean **unknown**, not zero. If queue-wide coverage has not been verified,
+do not imply the ratio describes the whole queue. Show the separate run clocks and
+committed recurring-failure counts when present. Do not create reports, change
+tracker state, or use PR/token counts as outcome-value proxies from this skill.
+
 ## Pull request arming (#3903)
 
 Alongside the two work queues, report the **arming state of the repo's open pull requests**. A PR whose `autoMergeRequest` is `null` is fully green and permanently unmergeable: every check passes, `mergeStateStatus` is green, nothing complains, and it waits forever. Green-and-unarmed and green-and-waiting read identically on every other surface, so this is the one place that asks the question.

package/plugins/lisa-copilot/skills/lisa-setup-automations/SKILL.md

@@ -197,6 +197,26 @@ closed by the next run's dedupe or the human), not mutual exclusion; manual
 runs should first confirm the cron is not due or running. Tear-down removes
 it with the rest of the `lisa-auto-<project>-*` set.
 
+**Optional automation — starter sync.** Read `starter.sync.auto` from the
+project's current config. Only the boolean `true` opts in (default **false**).
+When true, reconcile exactly one `lisa-auto-<project>-starter-sync` registration
+running `/lisa:starter-sync` once a **day** (`FREQ=DAILY;INTERVAL=1`) in the
+verified durable project checkout. Use the current runtime's native scheduler
+and update an existing registration by its exact name rather than duplicating
+it. Its prompt must identify this as a scheduled invocation, require a fresh
+check of `starter.sync.auto` before mutation, and carry the literal command on
+its own line. The `lisa-starter-sync` skill calls the shipped CLI and preserves
+its configured landing strategy; an open PR is not an applied update.
+
+When false or absent, remove any exact `lisa-auto-<project>-starter-sync`
+registration using that same native scheduler, leaving all other schedules
+alone. Read the scheduler back after either operation and report the observed
+name, target, cadence, or verified absence. Saving the console toggle only saves
+config: run this reconciliation to change the registration. If scheduler access
+is unavailable, report registration/removal as **unverified**, not successful;
+do not write its backing files or install another scheduler. This representation
+gap applies to any runtime without a native recurring-task tool.
+
 **Optional automation — the health cron.** When `health.schedule` in
 `.lisa.config.json` is `daily` or `weekly` (default **off**, which registers
 nothing), additionally create `lisa-auto-<project>-health-drift` running

package/plugins/lisa-copilot/skills/lisa-starter-sync/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: lisa-starter-sync
+description: "Run one starter sync using Lisa's existing engine and landing command. Also used by the opt-in daily starter-sync automation."
+allowed-tools: ["Bash", "Read", "Skill"]
+---
+
+# Sync the project's starter
+
+Run one `lisa starter sync --json` in the verified project checkout using the
+installed Lisa CLI. The CLI owns diffing, ownership rules, isolated PR worktrees,
+direct-when-clean refusal, and reuse of an existing PR. Do not reproduce them.
+
+For a scheduled invocation, re-read `starter.sync.auto` from the project's
+current config before any mutation. If it is not exactly `true`, report
+`no-change — automatic starter sync is off` and stop. A stale registration must
+not keep applying changes after the operator turns the setting off.
+
+Use a real existing work item when supplied (`--work-item <ref>`) and the actual
+runtime's identity with `--co-author <identity>`. Never invent attribution,
+disable hooks, or open a ticket merely to make an empty sync pass. If project
+commit policy needs attribution that is unavailable, surface that requirement.
+
+Report the returned outcome accurately:
+
+- `current`: **nothing to do**; no changes landed.
+- `committed`: name the resulting commit.
+- `pull-request`: link the existing or newly opened PR; it is awaiting review,
+  not merged and not an advanced consumer baseline. Continue the existing
+  `lisa-drive-pr-to-merge` review workflow with `auto_merge=false` when available.
+- Nonzero exit or malformed output: report the actual failure and any retained
+  worktree location. Do not reset or delete those recovery files.
+
+Never write to the starter repository. Never enable auto-merge as part of this
+command. The same skill is distributed to all six agent runtimes; native slash
+commands use `/lisa:starter-sync`, and Codex uses `$lisa-starter-sync`.

package/plugins/lisa-copilot/skills/lisa-usage-accounting/SKILL.md

@@ -140,6 +140,15 @@ the managed comment path.
 
 ### Step 3 — Apply the requested operation
 
+For lifecycle rows, include the optional `effectiveness` observations defined in
+[portable effectiveness reference](references/effectiveness.md): four separate clocks, explicit unknowns, sourced human
+events, Lisa version, and worker configuration revision. Preserve extensions on old
+rows. After the canonical host write passes readback, mirror the row through
+`lisa effectiveness record --input <json-file>` for local status reports. On a
+confirmed recurrence after its control shipped, use `lisa effectiveness recurrence
+--input <json-file>` with the stable source event identity; commit that history
+through normal checks. Do not infer human minutes or invent missing runtime telemetry.
+
 All three operations use the shared utilities and rule contract; they differ only in which inputs
 they require and whether they recompute child totals:
 

package/plugins/lisa-copilot/skills/lisa-usage-accounting/references/effectiveness.md

@@ -0,0 +1,63 @@
+# Delivery observations (optional extension)
+
+Keep the primary 17-field usage token unchanged. New writers attach
+`LisaUsageEntry.effectiveness`; the shared serializer emits the adjacent
+`lisa:usage-effectiveness` token correlated by `entry_id`. Older readers may ignore
+the extension. New writers preserve it when rewriting historical rows.
+
+Each observation has `schema: 1` and all these fields, using `null` for unknown:
+
+- `lisaVersion`, `workerConfigRevision`: observed version/revision tags.
+- `workerWallMs`: actual execution duration for this run.
+- `feedbackMs`: measured blocking request-to-response samples in milliseconds.
+  Start when this worker issues the request; stop when its response is available.
+  Waiting on another agent is queue latency and is excluded. `[]` means a measured
+  run with no such requests; `null` means unavailable telemetry.
+- `workerSource`: runtime evidence identifier for wall time and feedback samples.
+- `attention`: observed `{id, source}` human interventions. Derive these from
+  non-bot ready-role flips, blocked-item answers, and review interventions. Dedupe
+  by stable tracker event identity. `[]` means the relevant history was inspected
+  and contained no interventions; `null` means it was not measured. Never infer
+  human minutes from gaps between comments.
+- `readyAt`, `acceptedAt`: canonical UTC timestamps from the configured ready-role
+  flip and terminal accepted outcome. The elapsed clock excludes pre-ready intake.
+  A merge or queued deployment alone is not acceptance. `lifecycleSources` holds
+  the tracker/release evidence for these timestamps.
+- `reworkSources`: observed reclaims, QA bounces, or reverts. The existing
+  `lisa-delivery-effectiveness` skill owns rework rates and other outcome measures;
+  these are observations, not a competing score.
+
+At the existing implement, verify, and intake accounting milestones, supply these
+observations even if every measurement is unknown. Collect runtime observations
+as work proceeds; do not reconstruct feedback samples from memory at the end.
+Runtime APIs differ across agents: unavailable measurements remain null on any
+agent rather than being estimated from tool/PR/token counts.
+
+After the canonical usage row is read back, mirror `{entryId, artifactRef,
+effectiveness}` with `lisa effectiveness record --input <json-file>`. Mirrors under
+`.lisa/effectiveness/` are ignored and disposable; reconstruct them from usage
+extensions when needed. Do not commit timing reports or store secrets in sources.
+The command refuses a non-ignored destination. Report write failures explicitly;
+they must not erase the canonical accounting row or claim measurement succeeded.
+
+Record an actual post-control failure using `lisa effectiveness recurrence --input
+<json-file>`. The object contains `invariant`, `surface`, `controlRef`,
+`controlShippedAt`, `occurrenceRef`, and `occurredAt`. Both timestamps use canonical
+UTC ISO strings with milliseconds. Verify that the control/learning really shipped
+before this occurrence; initial failures and unshipped proposals are not recurrences.
+Use a stable occurrence source, such as a test-run failure or tracker event, so
+replays and reports from different agents identify the same event.
+
+`.lisa/RECURRENCES.jsonl` is committed history: distinct occurrence identities are
+the durable count. Its existing built-in `merge=union` attribute retains concurrent
+branch appends, and the reader deduplicates replayed events. Never hand-increment
+a counter, compact away occurrences, or add counts to the bounded learnings ledger.
+Normal review, secret checks, and push requirements still apply to this file.
+The writer refuses missing merge setup and conflicting evidence for one identity.
+
+`lisa effectiveness report` is read-only. Its per-run feedback distribution, wall
+time, attention count, and ready-to-accepted duration remain separate. Attention
+ratios cover only the locally observed accepted outcomes, with the reported sources
+and denominator. Missing local records are unknown coverage, not zero factory effort.
+Rebuild local records for the requested reporting scope before making a scope-wide
+claim; never extrapolate a local subset to the whole queue.

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

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

package/plugins/lisa-cursor/commands/lisa/starter-sync.md

@@ -0,0 +1,6 @@
+---
+description: "Run one starter sync using the project's existing landing strategy."
+argument-hint: "[--work-item <ref>]"
+---
+
+Use the /lisa-starter-sync skill for one real sync in the current project. $ARGUMENTS

package/plugins/lisa-cursor/rules/usage-accounting-reference.mdc

@@ -257,6 +257,10 @@ The rollup contract is additive across the hierarchy: PRDs may roll up Epics/Sto
 - Re-running with the same logical entry set must produce byte-identical output. Rewriting a legacy
   primary-only marker or the 2.222.0 transitional marker migrates once to the canonical
   primary-plus-extension layout; subsequent rewrites are byte-identical.
-- Do not include timestamps in the section preamble or token lines.
+- Do not add timestamps to the section preamble or primary usage token. Sourced
+  lifecycle timestamps belong only in the optional effectiveness extension.
 
 Idempotency is enforced by `entry_id` for direct entries and by the fixed rollup token field order for totals.
+## Delivery observations
+
+Read `references/effectiveness.md` in the `lisa-usage-accounting` skill for the optional effectiveness extension, clock definitions, and recurrence storage contract shared by every supported agent. The primary 17-field usage token remains unchanged.

package/plugins/lisa-cursor/scripts/automation-status-expected-fleet.mjs

@@ -41,6 +41,10 @@ export const AUTOMATION_EXPECTED_CADENCES = {
     human: "once a day",
     rrule: "FREQ=DAILY;INTERVAL=1",
   },
+  "starter-sync": {
+    human: "once a day",
+    rrule: "FREQ=DAILY;INTERVAL=1",
+  },
   "learnings-audit": {
     human: "once a week",
     rrule: "FREQ=WEEKLY;INTERVAL=1",
@@ -336,6 +340,17 @@ export function resolveExpectedAutomationFleet(input = {}) {
     );
   }
 
+  if (config.starter?.sync?.auto === true) {
+    expected.push(
+      createExpectedEntry(
+        identity,
+        "starter-sync",
+        "/lisa:starter-sync",
+        "opt-in"
+      )
+    );
+  }
+
   return {
     ...identity,
     expected,

package/plugins/lisa-cursor/skills/lisa-learnings-audit/SKILL.md

@@ -260,11 +260,20 @@ computed **deterministically — never estimated by the model**:
 
 1. **Normalize** the invariant text: trim leading/trailing whitespace,
    collapse every internal whitespace run to a single space, lowercase.
-2. **Hash** in Bash: `printf '%s' "$normalized" | shasum -a 256 | cut -c1-12`.
+2. **Hash** through the shared implementation: write the invariant to a text file
+   and run `lisa effectiveness fingerprint --input <file>`. This performs the
+   normalization above and returns the first 12 SHA-256 hex characters.
 
 The same knowledge item therefore always produces the same key across runs,
 regardless of which session computes it.
 
+Read `lisa effectiveness report` for committed post-control recurrence counts by
+the same `<surface>+<invariant-hash>` key. Cite the count and occurrence sources as
+evidence when deciding whether a control helped. Missing history means unknown,
+not a successful control. Counts do not automatically justify a new ticket: apply
+the existing worth-doing judgment. The learning entry's content-version fingerprint
+is a different identifier and must not be substituted for this invariant hash.
+
 Before filing anything, search the tracker for the marker in
 **open AND closed** issues — and key the search on the deterministic
 `<surface>` prefix **first**, using the hash as disambiguation only, so even

package/plugins/lisa-cursor/skills/lisa-queue-status/SKILL.md

@@ -69,6 +69,16 @@ For each inspected queue, report:
 
 The report should stay terminal-first and immediately actionable: observable queue facts first, then the smallest useful next step.
 
+## Delivery effort
+
+Alongside queue counts, run the read-only `lisa effectiveness report`. Show observed
+human interventions per accepted outcome, its numerator/denominator, and evidence
+sources. State that this covers locally observed outcomes; absent reports or null
+attention mean **unknown**, not zero. If queue-wide coverage has not been verified,
+do not imply the ratio describes the whole queue. Show the separate run clocks and
+committed recurring-failure counts when present. Do not create reports, change
+tracker state, or use PR/token counts as outcome-value proxies from this skill.
+
 ## Pull request arming (#3903)
 
 Alongside the two work queues, report the **arming state of the repo's open pull requests**. A PR whose `autoMergeRequest` is `null` is fully green and permanently unmergeable: every check passes, `mergeStateStatus` is green, nothing complains, and it waits forever. Green-and-unarmed and green-and-waiting read identically on every other surface, so this is the one place that asks the question.

package/plugins/lisa-cursor/skills/lisa-setup-automations/SKILL.md

@@ -197,6 +197,26 @@ closed by the next run's dedupe or the human), not mutual exclusion; manual
 runs should first confirm the cron is not due or running. Tear-down removes
 it with the rest of the `lisa-auto-<project>-*` set.
 
+**Optional automation — starter sync.** Read `starter.sync.auto` from the
+project's current config. Only the boolean `true` opts in (default **false**).
+When true, reconcile exactly one `lisa-auto-<project>-starter-sync` registration
+running `/lisa:starter-sync` once a **day** (`FREQ=DAILY;INTERVAL=1`) in the
+verified durable project checkout. Use the current runtime's native scheduler
+and update an existing registration by its exact name rather than duplicating
+it. Its prompt must identify this as a scheduled invocation, require a fresh
+check of `starter.sync.auto` before mutation, and carry the literal command on
+its own line. The `lisa-starter-sync` skill calls the shipped CLI and preserves
+its configured landing strategy; an open PR is not an applied update.
+
+When false or absent, remove any exact `lisa-auto-<project>-starter-sync`
+registration using that same native scheduler, leaving all other schedules
+alone. Read the scheduler back after either operation and report the observed
+name, target, cadence, or verified absence. Saving the console toggle only saves
+config: run this reconciliation to change the registration. If scheduler access
+is unavailable, report registration/removal as **unverified**, not successful;
+do not write its backing files or install another scheduler. This representation
+gap applies to any runtime without a native recurring-task tool.
+
 **Optional automation — the health cron.** When `health.schedule` in
 `.lisa.config.json` is `daily` or `weekly` (default **off**, which registers
 nothing), additionally create `lisa-auto-<project>-health-drift` running

package/plugins/lisa-cursor/skills/lisa-starter-sync/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: lisa-starter-sync
+description: "Run one starter sync using Lisa's existing engine and landing command. Also used by the opt-in daily starter-sync automation."
+allowed-tools: ["Bash", "Read", "Skill"]
+---
+
+# Sync the project's starter
+
+Run one `lisa starter sync --json` in the verified project checkout using the
+installed Lisa CLI. The CLI owns diffing, ownership rules, isolated PR worktrees,
+direct-when-clean refusal, and reuse of an existing PR. Do not reproduce them.
+
+For a scheduled invocation, re-read `starter.sync.auto` from the project's
+current config before any mutation. If it is not exactly `true`, report
+`no-change — automatic starter sync is off` and stop. A stale registration must
+not keep applying changes after the operator turns the setting off.
+
+Use a real existing work item when supplied (`--work-item <ref>`) and the actual
+runtime's identity with `--co-author <identity>`. Never invent attribution,
+disable hooks, or open a ticket merely to make an empty sync pass. If project
+commit policy needs attribution that is unavailable, surface that requirement.
+
+Report the returned outcome accurately:
+
+- `current`: **nothing to do**; no changes landed.
+- `committed`: name the resulting commit.
+- `pull-request`: link the existing or newly opened PR; it is awaiting review,
+  not merged and not an advanced consumer baseline. Continue the existing
+  `lisa-drive-pr-to-merge` review workflow with `auto_merge=false` when available.
+- Nonzero exit or malformed output: report the actual failure and any retained
+  worktree location. Do not reset or delete those recovery files.
+
+Never write to the starter repository. Never enable auto-merge as part of this
+command. The same skill is distributed to all six agent runtimes; native slash
+commands use `/lisa:starter-sync`, and Codex uses `$lisa-starter-sync`.

package/plugins/lisa-cursor/skills/lisa-usage-accounting/SKILL.md

@@ -140,6 +140,15 @@ the managed comment path.
 
 ### Step 3 — Apply the requested operation
 
+For lifecycle rows, include the optional `effectiveness` observations defined in
+[portable effectiveness reference](references/effectiveness.md): four separate clocks, explicit unknowns, sourced human
+events, Lisa version, and worker configuration revision. Preserve extensions on old
+rows. After the canonical host write passes readback, mirror the row through
+`lisa effectiveness record --input <json-file>` for local status reports. On a
+confirmed recurrence after its control shipped, use `lisa effectiveness recurrence
+--input <json-file>` with the stable source event identity; commit that history
+through normal checks. Do not infer human minutes or invent missing runtime telemetry.
+
 All three operations use the shared utilities and rule contract; they differ only in which inputs
 they require and whether they recompute child totals:
 

package/plugins/lisa-cursor/skills/lisa-usage-accounting/references/effectiveness.md

@@ -0,0 +1,63 @@
+# Delivery observations (optional extension)
+
+Keep the primary 17-field usage token unchanged. New writers attach
+`LisaUsageEntry.effectiveness`; the shared serializer emits the adjacent
+`lisa:usage-effectiveness` token correlated by `entry_id`. Older readers may ignore
+the extension. New writers preserve it when rewriting historical rows.
+
+Each observation has `schema: 1` and all these fields, using `null` for unknown:
+
+- `lisaVersion`, `workerConfigRevision`: observed version/revision tags.
+- `workerWallMs`: actual execution duration for this run.
+- `feedbackMs`: measured blocking request-to-response samples in milliseconds.
+  Start when this worker issues the request; stop when its response is available.
+  Waiting on another agent is queue latency and is excluded. `[]` means a measured
+  run with no such requests; `null` means unavailable telemetry.
+- `workerSource`: runtime evidence identifier for wall time and feedback samples.
+- `attention`: observed `{id, source}` human interventions. Derive these from
+  non-bot ready-role flips, blocked-item answers, and review interventions. Dedupe
+  by stable tracker event identity. `[]` means the relevant history was inspected
+  and contained no interventions; `null` means it was not measured. Never infer
+  human minutes from gaps between comments.
+- `readyAt`, `acceptedAt`: canonical UTC timestamps from the configured ready-role
+  flip and terminal accepted outcome. The elapsed clock excludes pre-ready intake.
+  A merge or queued deployment alone is not acceptance. `lifecycleSources` holds
+  the tracker/release evidence for these timestamps.
+- `reworkSources`: observed reclaims, QA bounces, or reverts. The existing
+  `lisa-delivery-effectiveness` skill owns rework rates and other outcome measures;
+  these are observations, not a competing score.
+
+At the existing implement, verify, and intake accounting milestones, supply these
+observations even if every measurement is unknown. Collect runtime observations
+as work proceeds; do not reconstruct feedback samples from memory at the end.
+Runtime APIs differ across agents: unavailable measurements remain null on any
+agent rather than being estimated from tool/PR/token counts.
+
+After the canonical usage row is read back, mirror `{entryId, artifactRef,
+effectiveness}` with `lisa effectiveness record --input <json-file>`. Mirrors under
+`.lisa/effectiveness/` are ignored and disposable; reconstruct them from usage
+extensions when needed. Do not commit timing reports or store secrets in sources.
+The command refuses a non-ignored destination. Report write failures explicitly;
+they must not erase the canonical accounting row or claim measurement succeeded.
+
+Record an actual post-control failure using `lisa effectiveness recurrence --input
+<json-file>`. The object contains `invariant`, `surface`, `controlRef`,
+`controlShippedAt`, `occurrenceRef`, and `occurredAt`. Both timestamps use canonical
+UTC ISO strings with milliseconds. Verify that the control/learning really shipped
+before this occurrence; initial failures and unshipped proposals are not recurrences.
+Use a stable occurrence source, such as a test-run failure or tracker event, so
+replays and reports from different agents identify the same event.
+
+`.lisa/RECURRENCES.jsonl` is committed history: distinct occurrence identities are
+the durable count. Its existing built-in `merge=union` attribute retains concurrent
+branch appends, and the reader deduplicates replayed events. Never hand-increment
+a counter, compact away occurrences, or add counts to the bounded learnings ledger.
+Normal review, secret checks, and push requirements still apply to this file.
+The writer refuses missing merge setup and conflicting evidence for one identity.
+
+`lisa effectiveness report` is read-only. Its per-run feedback distribution, wall
+time, attention count, and ready-to-accepted duration remain separate. Attention
+ratios cover only the locally observed accepted outcomes, with the reported sources
+and denominator. Missing local records are unknown coverage, not zero factory effort.
+Rebuild local records for the requested reporting scope before making a scope-wide
+claim; never extrapolate a local subset to the whole queue.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.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": "4.62.4",
+  "version": "4.64.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.62.4",
+  "version": "4.64.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.62.4",
+  "version": "4.64.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "4.62.4",
+  "version": "4.64.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"