@codyswann/lisa 3.18.2 → 3.19.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (81) hide show
  1. package/dist/core/upstream-evidence-manifest.d.ts.map +1 -1
  2. package/dist/core/upstream-evidence-manifest.js +18 -1
  3. package/dist/core/upstream-evidence-manifest.js.map +1 -1
  4. package/dist/health/drift-tickets.d.ts +88 -0
  5. package/dist/health/drift-tickets.d.ts.map +1 -0
  6. package/dist/health/drift-tickets.js +112 -0
  7. package/dist/health/drift-tickets.js.map +1 -0
  8. package/dist/health/index.d.ts +1 -0
  9. package/dist/health/index.d.ts.map +1 -1
  10. package/dist/health/index.js +1 -0
  11. package/dist/health/index.js.map +1 -1
  12. package/package.json +1 -1
  13. package/plugins/lisa/.claude-plugin/plugin.json +1 -1
  14. package/plugins/lisa/.codex-plugin/plugin.json +1 -1
  15. package/plugins/lisa/.codex-plugin/skills/lisa-health-drift-cron/SKILL.md +80 -0
  16. package/plugins/lisa/.codex-plugin/skills/lisa-health-drift-cron/agents/openai.yaml +4 -0
  17. package/plugins/lisa/.codex-plugin/skills/lisa-setup-automations/SKILL.md +10 -0
  18. package/plugins/lisa/commands/health-drift-cron.md +9 -0
  19. package/plugins/lisa/skills/lisa-health-drift-cron/SKILL.md +80 -0
  20. package/plugins/lisa/skills/lisa-health-drift-cron/agents/openai.yaml +4 -0
  21. package/plugins/lisa/skills/lisa-setup-automations/SKILL.md +10 -0
  22. package/plugins/lisa-agy/commands/lisa/health-drift-cron.md +9 -0
  23. package/plugins/lisa-agy/plugin.json +1 -1
  24. package/plugins/lisa-agy/skills/lisa-health-drift-cron/SKILL.md +80 -0
  25. package/plugins/lisa-agy/skills/lisa-setup-automations/SKILL.md +10 -0
  26. package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
  27. package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
  28. package/plugins/lisa-cdk-agy/plugin.json +1 -1
  29. package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json +1 -1
  30. package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json +1 -1
  31. package/plugins/lisa-copilot/.claude-plugin/plugin.json +1 -1
  32. package/plugins/lisa-copilot/commands/lisa/health-drift-cron.md +9 -0
  33. package/plugins/lisa-copilot/skills/lisa-health-drift-cron/SKILL.md +80 -0
  34. package/plugins/lisa-copilot/skills/lisa-setup-automations/SKILL.md +10 -0
  35. package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
  36. package/plugins/lisa-cursor/commands/lisa/health-drift-cron.md +9 -0
  37. package/plugins/lisa-cursor/skills/lisa-health-drift-cron/SKILL.md +80 -0
  38. package/plugins/lisa-cursor/skills/lisa-setup-automations/SKILL.md +10 -0
  39. package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
  40. package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
  41. package/plugins/lisa-expo-agy/plugin.json +1 -1
  42. package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json +1 -1
  43. package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json +1 -1
  44. package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
  45. package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
  46. package/plugins/lisa-harper-fabric-agy/plugin.json +1 -1
  47. package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json +1 -1
  48. package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json +1 -1
  49. package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
  50. package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
  51. package/plugins/lisa-nestjs-agy/plugin.json +1 -1
  52. package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json +1 -1
  53. package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json +1 -1
  54. package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
  55. package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
  56. package/plugins/lisa-openclaw-agy/plugin.json +1 -1
  57. package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json +1 -1
  58. package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json +1 -1
  59. package/plugins/lisa-phaser/.claude-plugin/plugin.json +1 -1
  60. package/plugins/lisa-phaser/.codex-plugin/plugin.json +1 -1
  61. package/plugins/lisa-phaser-agy/plugin.json +1 -1
  62. package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json +1 -1
  63. package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json +1 -1
  64. package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
  65. package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
  66. package/plugins/lisa-rails-agy/plugin.json +1 -1
  67. package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json +1 -1
  68. package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json +1 -1
  69. package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
  70. package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
  71. package/plugins/lisa-typescript-agy/plugin.json +1 -1
  72. package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json +1 -1
  73. package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json +1 -1
  74. package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
  75. package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
  76. package/plugins/lisa-wiki-agy/plugin.json +1 -1
  77. package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json +1 -1
  78. package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json +1 -1
  79. package/plugins/src/base/commands/health-drift-cron.md +9 -0
  80. package/plugins/src/base/skills/lisa-health-drift-cron/SKILL.md +80 -0
  81. package/plugins/src/base/skills/lisa-setup-automations/SKILL.md +10 -0
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-cdk",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "AWS CDK-specific plugin",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-cdk",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "AWS CDK-specific plugin",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-cdk",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "AWS CDK-specific plugin",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -0,0 +1,9 @@
1
+ ---
2
+ description: "Run the scheduled health consumer: check health headless, and file one deduped ticket per drifting check."
3
+ argument-hint: "[project-path]"
4
+ ---
5
+
6
+ Use the /lisa-health-drift-cron skill to run Lisa Health for the optional project path and turn any
7
+ drift into tracked work. File exactly one ticket per drifting check through `lisa-tracker-write`,
8
+ deduped by the per-check marker across OPEN tickets only, and file nothing for a project in band.
9
+ This flow files; it never closes, edits, or repairs. $ARGUMENTS
@@ -0,0 +1,80 @@
1
+ ---
2
+ name: lisa-health-drift-cron
3
+ description: "Scheduled health consumer. Runs Lisa Health headless, and for each check that has drifted files exactly one tracker ticket through lisa-tracker-write, deduped by a per-check marker across OPEN tickets only. Files nothing for a project in band. Use for the lisa-auto-<project>-health-drift automation registered when health.schedule is set."
4
+ allowed-tools: ["Skill", "Bash", "Read"]
5
+ ---
6
+
7
+ # Lisa Health Drift Cron: $ARGUMENTS
8
+
9
+ Consumer #3 of the health layer: the cron. A health check you have to remember to run is a health check that goes stale, so this one runs on a schedule and turns drift into **tracked work** rather than silent decay.
10
+
11
+ It **files**. It never closes, edits, or repairs. Disposal belongs to humans and the Implement factory.
12
+
13
+ ## Why idempotency is the whole job
14
+
15
+ A nightly cron that refiles the same drift every night is worse than no cron at all, because it teaches everyone to ignore the tickets it files. Every rule below exists to make *"the same drift"* a decidable question, and the decision is not made in this prose — it is made by `planDriftTickets` in `src/health/drift-tickets.ts`, which is unit-tested against each of these cases.
16
+
17
+ **Do not reimplement the dedupe here.** Call the planner and act on its answer. A second implementation in prose is a second implementation to drift.
18
+
19
+ ## Phase 1 — Run the health check headless
20
+
21
+ Invoke **`/lisa-health`** and use the JSON it emits. Do not call the CLI directly and do not invent flags for it: `lisa health` takes `[path]`, `--prepare-agentic`, and `--agentic-evaluation`, and nothing else. There is no `--json` — the persisted result IS the command's stdout, and an unknown option makes commander exit non-zero, so a guessed flag turns the first phase of a scheduled run into a failure nobody is watching.
22
+
23
+ Routing through the skill also means the bounded harness-review step and its cleanup stay in one place rather than being re-described here and drifting.
24
+
25
+ Do not reconstruct, merge, or summarize findings; the result is passed to Phase 3 verbatim.
26
+
27
+ If the run itself fails, that is a **recovery-required** outcome. Report it and stop. Do not file a drift ticket about a health check that did not complete — a run that could not measure has not found drift, and saying otherwise is the same defect the health layer exists to catch.
28
+
29
+ ## Phase 2 — Read the OPEN tickets only
30
+
31
+ Fetch the tracker's **open** items carrying the drift marker prefix `lisa-health-drift`.
32
+
33
+ **Open only, and this is load-bearing.** A closed ticket must not suppress live drift: if it did, closing a ticket without fixing anything would make that drift invisible forever, which is exactly the silent decay this consumer exists to prevent. Suppression should be a configured declaration visible in a diff — turn the check off in config — not a side effect of somebody tidying a backlog.
34
+
35
+ The planner enforces this by construction: it accepts an `openTickets` list and has no notion of a closed one. Passing closed tickets defeats the design, and the parameter is named to say so.
36
+
37
+ ## Phase 3 — Plan
38
+
39
+ Feed the findings and the open tickets to `planDriftTickets`. It returns:
40
+
41
+ - `file` — one entry per drifting check with no open ticket, carrying `title`, `body`, and `marker`
42
+ - `alreadyTracked` — drift that an open ticket already covers, with the ticket id
43
+
44
+ Every unique drifting check lands in exactly one of the two after duplicate findings for the same check are collapsed, so a run reporting "nothing to do" is asserting it looked at all of them.
45
+
46
+ The collapse is not tidiness. The marker cannot tell two findings for one check apart, so filing both would self-duplicate on the very FIRST run — before any second run exists to blame. `file.length + alreadyTracked.length` therefore counts distinct drifting checks, which is fewer than the drifting findings whenever a run reports one check twice.
47
+
48
+ Dedupe is per **check**, not per drift set. Fingerprinting the whole finding set would mean one added finding produces a fresh ticket while the old one still stands, so a slowly-degrading project accumulates near-duplicates — the same "worse than no cron" outcome by another route.
49
+
50
+ ## Phase 4 — File
51
+
52
+ For each entry in `file`, invoke **`/lisa-tracker-write`** with its title and body. **Never call a vendor writer (`lisa-github-write-issue` / `lisa-jira-write-ticket` / `lisa-linear-write-issue`) directly** — routing through the shim is what makes the tracker switchable per project.
53
+
54
+ The body already contains the marker. Do not strip it, and do not add a second one: the next run finds the ticket by that exact string.
55
+
56
+ ## Run outcome
57
+
58
+ Per the automation runbook contract, end with exactly one outcome and a one-line operator-readable summary:
59
+
60
+ - **no-change** — the project is in band, or every drifting check is already tracked. Say which: `no-change — in band, nothing filed.` versus `no-change — 2 drifting checks, both already tracked (#41, #42).`
61
+ - **change-proved** — tickets were filed. `change-proved — filed 1 drift ticket: coverage-floor (#57).`
62
+ - **recovery-required** — the health run failed, or a write failed. Name what a human must do.
63
+
64
+ The distinction between the two `no-change` shapes matters. "Nothing filed" and "nothing wrong" are different facts, and collapsing them hides a project whose drift is real and simply already on somebody's list.
65
+
66
+ ## Registration
67
+
68
+ Registered as `lisa-auto-<project>-health-drift` when `health.schedule` is set to `daily` or `weekly` in `.lisa.config.json`. `off` (the default) registers nothing. Torn down with the rest of the `lisa-auto-<project>-*` set.
69
+
70
+ Register at most **one** per project.
71
+
72
+ ### What the dedupe does and does not guarantee
73
+
74
+ It guarantees **convergence, not mutual exclusion**, and the difference is worth stating plainly rather than leaving to be discovered.
75
+
76
+ Two runs that overlap — a manual invocation alongside the scheduled one, or a run still going when the next fires — can both read an empty open-ticket set and both file for the same check. A single registration makes that rare; it does not make it impossible, and no amount of care in this document would.
77
+
78
+ What the design does guarantee is that it stops there. The next run sees both open tickets carrying the marker, matches, and files nothing further, so duplicates do not compound. The transient duplicate persists until a human closes one, and closing it is safe: if the drift is still live, the remaining ticket still tracks it.
79
+
80
+ This is the same stance `lisa-learnings-audit` takes for the same reason, and the same advice applies — **a manual run should first confirm the cron is not due or running.** A project-scoped lease would buy true exclusion at the cost of a lock to acquire, hold, and expire correctly on a path that only runs daily; the failure it prevents is cosmetic and self-limiting, and the failure a stuck lease causes is a health check that silently stops running.
@@ -197,6 +197,16 @@ closed by the next run's dedupe or the human), not mutual exclusion; manual
197
197
  runs should first confirm the cron is not due or running. Tear-down removes
198
198
  it with the rest of the `lisa-auto-<project>-*` set.
199
199
 
200
+ **Optional automation — the health cron.** When `health.schedule` in
201
+ `.lisa.config.json` is `daily` or `weekly` (default **off**, which registers
202
+ nothing), additionally create `lisa-auto-<project>-health-drift` running
203
+ `/lisa:health-drift-cron` at that cadence. It runs Lisa Health headless and,
204
+ for each check that has drifted, files exactly one ticket through
205
+ `lisa-tracker-write`. A project in band files nothing. Register at most ONE per
206
+ project: the per-check marker dedupe converges under a single scheduled runner,
207
+ and two concurrent runs can both observe an empty open-ticket set and both
208
+ file. Tear-down removes it with the rest of the `lisa-auto-<project>-*` set.
209
+
200
210
  **Exploratory PRD pressure gate.** `auto-start-prds=true` means "create PRDs in the ready PRD
201
211
  lifecycle when the PRD queue has capacity," not "always create a new ready PRD." The
202
212
  `exploratory-prds` automation uses the same PRD source queue and pressure roles reported by
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -0,0 +1,9 @@
1
+ ---
2
+ description: "Run the scheduled health consumer: check health headless, and file one deduped ticket per drifting check."
3
+ argument-hint: "[project-path]"
4
+ ---
5
+
6
+ Use the /lisa-health-drift-cron skill to run Lisa Health for the optional project path and turn any
7
+ drift into tracked work. File exactly one ticket per drifting check through `lisa-tracker-write`,
8
+ deduped by the per-check marker across OPEN tickets only, and file nothing for a project in band.
9
+ This flow files; it never closes, edits, or repairs. $ARGUMENTS
@@ -0,0 +1,80 @@
1
+ ---
2
+ name: lisa-health-drift-cron
3
+ description: "Scheduled health consumer. Runs Lisa Health headless, and for each check that has drifted files exactly one tracker ticket through lisa-tracker-write, deduped by a per-check marker across OPEN tickets only. Files nothing for a project in band. Use for the lisa-auto-<project>-health-drift automation registered when health.schedule is set."
4
+ allowed-tools: ["Skill", "Bash", "Read"]
5
+ ---
6
+
7
+ # Lisa Health Drift Cron: $ARGUMENTS
8
+
9
+ Consumer #3 of the health layer: the cron. A health check you have to remember to run is a health check that goes stale, so this one runs on a schedule and turns drift into **tracked work** rather than silent decay.
10
+
11
+ It **files**. It never closes, edits, or repairs. Disposal belongs to humans and the Implement factory.
12
+
13
+ ## Why idempotency is the whole job
14
+
15
+ A nightly cron that refiles the same drift every night is worse than no cron at all, because it teaches everyone to ignore the tickets it files. Every rule below exists to make *"the same drift"* a decidable question, and the decision is not made in this prose — it is made by `planDriftTickets` in `src/health/drift-tickets.ts`, which is unit-tested against each of these cases.
16
+
17
+ **Do not reimplement the dedupe here.** Call the planner and act on its answer. A second implementation in prose is a second implementation to drift.
18
+
19
+ ## Phase 1 — Run the health check headless
20
+
21
+ Invoke **`/lisa-health`** and use the JSON it emits. Do not call the CLI directly and do not invent flags for it: `lisa health` takes `[path]`, `--prepare-agentic`, and `--agentic-evaluation`, and nothing else. There is no `--json` — the persisted result IS the command's stdout, and an unknown option makes commander exit non-zero, so a guessed flag turns the first phase of a scheduled run into a failure nobody is watching.
22
+
23
+ Routing through the skill also means the bounded harness-review step and its cleanup stay in one place rather than being re-described here and drifting.
24
+
25
+ Do not reconstruct, merge, or summarize findings; the result is passed to Phase 3 verbatim.
26
+
27
+ If the run itself fails, that is a **recovery-required** outcome. Report it and stop. Do not file a drift ticket about a health check that did not complete — a run that could not measure has not found drift, and saying otherwise is the same defect the health layer exists to catch.
28
+
29
+ ## Phase 2 — Read the OPEN tickets only
30
+
31
+ Fetch the tracker's **open** items carrying the drift marker prefix `lisa-health-drift`.
32
+
33
+ **Open only, and this is load-bearing.** A closed ticket must not suppress live drift: if it did, closing a ticket without fixing anything would make that drift invisible forever, which is exactly the silent decay this consumer exists to prevent. Suppression should be a configured declaration visible in a diff — turn the check off in config — not a side effect of somebody tidying a backlog.
34
+
35
+ The planner enforces this by construction: it accepts an `openTickets` list and has no notion of a closed one. Passing closed tickets defeats the design, and the parameter is named to say so.
36
+
37
+ ## Phase 3 — Plan
38
+
39
+ Feed the findings and the open tickets to `planDriftTickets`. It returns:
40
+
41
+ - `file` — one entry per drifting check with no open ticket, carrying `title`, `body`, and `marker`
42
+ - `alreadyTracked` — drift that an open ticket already covers, with the ticket id
43
+
44
+ Every unique drifting check lands in exactly one of the two after duplicate findings for the same check are collapsed, so a run reporting "nothing to do" is asserting it looked at all of them.
45
+
46
+ The collapse is not tidiness. The marker cannot tell two findings for one check apart, so filing both would self-duplicate on the very FIRST run — before any second run exists to blame. `file.length + alreadyTracked.length` therefore counts distinct drifting checks, which is fewer than the drifting findings whenever a run reports one check twice.
47
+
48
+ Dedupe is per **check**, not per drift set. Fingerprinting the whole finding set would mean one added finding produces a fresh ticket while the old one still stands, so a slowly-degrading project accumulates near-duplicates — the same "worse than no cron" outcome by another route.
49
+
50
+ ## Phase 4 — File
51
+
52
+ For each entry in `file`, invoke **`/lisa-tracker-write`** with its title and body. **Never call a vendor writer (`lisa-github-write-issue` / `lisa-jira-write-ticket` / `lisa-linear-write-issue`) directly** — routing through the shim is what makes the tracker switchable per project.
53
+
54
+ The body already contains the marker. Do not strip it, and do not add a second one: the next run finds the ticket by that exact string.
55
+
56
+ ## Run outcome
57
+
58
+ Per the automation runbook contract, end with exactly one outcome and a one-line operator-readable summary:
59
+
60
+ - **no-change** — the project is in band, or every drifting check is already tracked. Say which: `no-change — in band, nothing filed.` versus `no-change — 2 drifting checks, both already tracked (#41, #42).`
61
+ - **change-proved** — tickets were filed. `change-proved — filed 1 drift ticket: coverage-floor (#57).`
62
+ - **recovery-required** — the health run failed, or a write failed. Name what a human must do.
63
+
64
+ The distinction between the two `no-change` shapes matters. "Nothing filed" and "nothing wrong" are different facts, and collapsing them hides a project whose drift is real and simply already on somebody's list.
65
+
66
+ ## Registration
67
+
68
+ Registered as `lisa-auto-<project>-health-drift` when `health.schedule` is set to `daily` or `weekly` in `.lisa.config.json`. `off` (the default) registers nothing. Torn down with the rest of the `lisa-auto-<project>-*` set.
69
+
70
+ Register at most **one** per project.
71
+
72
+ ### What the dedupe does and does not guarantee
73
+
74
+ It guarantees **convergence, not mutual exclusion**, and the difference is worth stating plainly rather than leaving to be discovered.
75
+
76
+ Two runs that overlap — a manual invocation alongside the scheduled one, or a run still going when the next fires — can both read an empty open-ticket set and both file for the same check. A single registration makes that rare; it does not make it impossible, and no amount of care in this document would.
77
+
78
+ What the design does guarantee is that it stops there. The next run sees both open tickets carrying the marker, matches, and files nothing further, so duplicates do not compound. The transient duplicate persists until a human closes one, and closing it is safe: if the drift is still live, the remaining ticket still tracks it.
79
+
80
+ This is the same stance `lisa-learnings-audit` takes for the same reason, and the same advice applies — **a manual run should first confirm the cron is not due or running.** A project-scoped lease would buy true exclusion at the cost of a lock to acquire, hold, and expire correctly on a path that only runs daily; the failure it prevents is cosmetic and self-limiting, and the failure a stuck lease causes is a health check that silently stops running.
@@ -197,6 +197,16 @@ closed by the next run's dedupe or the human), not mutual exclusion; manual
197
197
  runs should first confirm the cron is not due or running. Tear-down removes
198
198
  it with the rest of the `lisa-auto-<project>-*` set.
199
199
 
200
+ **Optional automation — the health cron.** When `health.schedule` in
201
+ `.lisa.config.json` is `daily` or `weekly` (default **off**, which registers
202
+ nothing), additionally create `lisa-auto-<project>-health-drift` running
203
+ `/lisa:health-drift-cron` at that cadence. It runs Lisa Health headless and,
204
+ for each check that has drifted, files exactly one ticket through
205
+ `lisa-tracker-write`. A project in band files nothing. Register at most ONE per
206
+ project: the per-check marker dedupe converges under a single scheduled runner,
207
+ and two concurrent runs can both observe an empty open-ticket set and both
208
+ file. Tear-down removes it with the rest of the `lisa-auto-<project>-*` set.
209
+
200
210
  **Exploratory PRD pressure gate.** `auto-start-prds=true` means "create PRDs in the ready PRD
201
211
  lifecycle when the PRD queue has capacity," not "always create a new ready PRD." The
202
212
  `exploratory-prds` automation uses the same PRD source queue and pressure roles reported by
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-expo",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-expo",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-expo",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-expo",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-expo",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-harper-fabric",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Harper/Fabric-specific rules for TypeScript component apps",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-harper-fabric",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-harper-fabric",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Harper/Fabric-specific rules for TypeScript component apps",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-harper-fabric",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Harper/Fabric-specific rules for TypeScript component apps",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-harper-fabric",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Harper/Fabric-specific rules for TypeScript component apps",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-nestjs",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-nestjs",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "NestJS-specific skills and migration write-protection hooks.",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-nestjs",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-nestjs",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-nestjs",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-openclaw",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "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",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-openclaw",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-openclaw",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "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",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-openclaw",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "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",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-openclaw",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "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",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-phaser",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Phaser 4 game-development rules for TypeScript projects",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-phaser",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Phaser 4 game-development rules for TypeScript projects",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-phaser",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Phaser 4 game-development rules for TypeScript projects",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-phaser",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Phaser 4 game-development rules for TypeScript projects",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-phaser",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Phaser 4 game-development rules for TypeScript projects",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-rails",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-rails",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-rails",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-rails",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-rails",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-typescript",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-typescript",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-typescript",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-typescript",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-typescript",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-wiki",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-wiki",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-wiki",
3
- "version": "3.18.2",
3
+ "version": "3.19.0",
4
4
  "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
5
5
  "author": {
6
6
  "name": "Cody Swann"