@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.
- package/dist/core/upstream-evidence-manifest.d.ts.map +1 -1
- package/dist/core/upstream-evidence-manifest.js +18 -1
- package/dist/core/upstream-evidence-manifest.js.map +1 -1
- package/dist/health/drift-tickets.d.ts +88 -0
- package/dist/health/drift-tickets.d.ts.map +1 -0
- package/dist/health/drift-tickets.js +112 -0
- package/dist/health/drift-tickets.js.map +1 -0
- package/dist/health/index.d.ts +1 -0
- package/dist/health/index.d.ts.map +1 -1
- package/dist/health/index.js +1 -0
- package/dist/health/index.js.map +1 -1
- package/package.json +1 -1
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/skills/lisa-health-drift-cron/SKILL.md +80 -0
- package/plugins/lisa/.codex-plugin/skills/lisa-health-drift-cron/agents/openai.yaml +4 -0
- package/plugins/lisa/.codex-plugin/skills/lisa-setup-automations/SKILL.md +10 -0
- package/plugins/lisa/commands/health-drift-cron.md +9 -0
- package/plugins/lisa/skills/lisa-health-drift-cron/SKILL.md +80 -0
- package/plugins/lisa/skills/lisa-health-drift-cron/agents/openai.yaml +4 -0
- package/plugins/lisa/skills/lisa-setup-automations/SKILL.md +10 -0
- package/plugins/lisa-agy/commands/lisa/health-drift-cron.md +9 -0
- package/plugins/lisa-agy/plugin.json +1 -1
- package/plugins/lisa-agy/skills/lisa-health-drift-cron/SKILL.md +80 -0
- package/plugins/lisa-agy/skills/lisa-setup-automations/SKILL.md +10 -0
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-agy/plugin.json +1 -1
- package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/commands/lisa/health-drift-cron.md +9 -0
- package/plugins/lisa-copilot/skills/lisa-health-drift-cron/SKILL.md +80 -0
- package/plugins/lisa-copilot/skills/lisa-setup-automations/SKILL.md +10 -0
- package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cursor/commands/lisa/health-drift-cron.md +9 -0
- package/plugins/lisa-cursor/skills/lisa-health-drift-cron/SKILL.md +80 -0
- package/plugins/lisa-cursor/skills/lisa-setup-automations/SKILL.md +10 -0
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-agy/plugin.json +1 -1
- package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-agy/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-agy/plugin.json +1 -1
- package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-agy/plugin.json +1 -1
- package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-agy/plugin.json +1 -1
- package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-agy/plugin.json +1 -1
- package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-agy/plugin.json +1 -1
- package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-agy/plugin.json +1 -1
- package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/src/base/commands/health-drift-cron.md +9 -0
- package/plugins/src/base/skills/lisa-health-drift-cron/SKILL.md +80 -0
- package/plugins/src/base/skills/lisa-setup-automations/SKILL.md +10 -0
|
@@ -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
|
|
@@ -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-openclaw",
|
|
3
|
-
"version": "3.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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"
|