@codyswann/lisa 3.18.2 → 3.19.0

package/dist/health/drift-tickets.d.ts

@@ -0,0 +1,88 @@
+/**
+ * Decide which health drift becomes a ticket, and which is already tracked.
+ *
+ * The scheduled health consumer's whole difficulty is idempotency: a nightly
+ * cron that refiles the same drift every night is worse than no cron at all,
+ * because it trains people to ignore the tickets it files. Everything here
+ * exists to make "the same drift" a decidable question.
+ *
+ * ## Dedupe is per CHECK, not per drift set
+ *
+ * The marker fingerprints the check id. Fingerprinting the whole finding set
+ * would mean one added finding produces a brand-new ticket while the old one
+ * still stands, so a slowly-degrading project accumulates near-duplicates —
+ * the same "worse than no cron" outcome by a slightly different route. Per
+ * check also makes partial repair behave: fix one drifting check, its ticket
+ * closes, the others stay open on their own merits.
+ *
+ * ## A closed ticket does not suppress live drift
+ *
+ * Enforced by construction rather than by a conditional: this planner is given
+ * only the OPEN tickets, so a closed one cannot suppress anything. It is not
+ * that closed tickets are checked and then ignored — they are not in evidence.
+ *
+ * The alternative, treating closure as permanent suppression, means closing a
+ * ticket without fixing anything makes that drift invisible forever, which is
+ * the silent decay this consumer exists to prevent. Suppression should be a
+ * configured declaration visible in a diff, not a side effect of somebody
+ * tidying a backlog. Turning the check off in config is the sanctioned way.
+ * @module health/drift-tickets
+ */
+import type { HealthFinding } from "./contract.js";
+/** Marker prefix written into a filed ticket so the next run can find it. */
+export declare const DRIFT_MARKER_PREFIX = "lisa-health-drift";
+/**
+ * The dedupe marker for one check.
+ *
+ * An HTML comment so it is invisible in rendered ticket bodies but present in
+ * the raw text every tracker returns. Trackers differ in what they preserve of
+ * a body; they do not differ in preserving its characters.
+ * @param check - The health check id
+ * @returns The marker to embed in a filed ticket
+ */
+export declare function driftMarker(check: string): string;
+/** A ticket already open in the tracker, reduced to what dedupe needs. */
+export interface OpenTicket {
+    readonly id: string;
+    readonly body: string;
+}
+/** One ticket the consumer should file. */
+export interface DriftTicket {
+    readonly check: string;
+    readonly title: string;
+    readonly body: string;
+    readonly marker: string;
+}
+/** Drift already covered by an open ticket, reported rather than dropped. */
+export interface TrackedDrift {
+    readonly check: string;
+    readonly ticketId: string;
+}
+/** What a scheduled run should do about the drift it found. */
+export interface DriftTicketPlan {
+    readonly file: readonly DriftTicket[];
+    readonly alreadyTracked: readonly TrackedDrift[];
+}
+/**
+ * Inputs to a planning pass.
+ *
+ * `openTickets` is deliberately named for its own precondition. A caller that
+ * passes closed tickets defeats the ruling above, and a parameter called
+ * `tickets` would not have told them so.
+ */
+export interface DriftTicketInput {
+    readonly findings: readonly HealthFinding[];
+    readonly openTickets: readonly OpenTicket[];
+}
+/**
+ * Decide what to file for the drift a run found.
+ *
+ * Total and pure: every unique drifting check lands in exactly one of `file` or
+ * `alreadyTracked` after duplicate findings for that check collapse, so a caller
+ * reporting "nothing to do" is asserting it looked at all checks rather than
+ * that its filter happened to be empty.
+ * @param input - Findings from the run and the tracker's OPEN tickets
+ * @returns Tickets to file, and drift already covered
+ */
+export declare function planDriftTickets(input: DriftTicketInput): DriftTicketPlan;
+//# sourceMappingURL=drift-tickets.d.ts.map

package/dist/health/drift-tickets.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"drift-tickets.d.ts","sourceRoot":"","sources":["../../src/health/drift-tickets.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AAEH,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,eAAe,CAAC;AAKnD,6EAA6E;AAC7E,eAAO,MAAM,mBAAmB,sBAAsB,CAAC;AAEvD;;;;;;;;GAQG;AACH,wBAAgB,WAAW,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,CAEjD;AAED,0EAA0E;AAC1E,MAAM,WAAW,UAAU;IACzB,QAAQ,CAAC,EAAE,EAAE,MAAM,CAAC;IACpB,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;CACvB;AAED,2CAA2C;AAC3C,MAAM,WAAW,WAAW;IAC1B,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;IACvB,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;IACvB,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,MAAM,EAAE,MAAM,CAAC;CACzB;AAED,6EAA6E;AAC7E,MAAM,WAAW,YAAY;IAC3B,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;IACvB,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC;CAC3B;AAED,+DAA+D;AAC/D,MAAM,WAAW,eAAe;IAC9B,QAAQ,CAAC,IAAI,EAAE,SAAS,WAAW,EAAE,CAAC;IACtC,QAAQ,CAAC,cAAc,EAAE,SAAS,YAAY,EAAE,CAAC;CAClD;AAED;;;;;;GAMG;AACH,MAAM,WAAW,gBAAgB;IAC/B,QAAQ,CAAC,QAAQ,EAAE,SAAS,aAAa,EAAE,CAAC;IAC5C,QAAQ,CAAC,WAAW,EAAE,SAAS,UAAU,EAAE,CAAC;CAC7C;AA0BD;;;;;;;;;GASG;AACH,wBAAgB,gBAAgB,CAAC,KAAK,EAAE,gBAAgB,GAAG,eAAe,CA0CzE"}

package/dist/health/drift-tickets.js

@@ -0,0 +1,112 @@
+/**
+ * Decide which health drift becomes a ticket, and which is already tracked.
+ *
+ * The scheduled health consumer's whole difficulty is idempotency: a nightly
+ * cron that refiles the same drift every night is worse than no cron at all,
+ * because it trains people to ignore the tickets it files. Everything here
+ * exists to make "the same drift" a decidable question.
+ *
+ * ## Dedupe is per CHECK, not per drift set
+ *
+ * The marker fingerprints the check id. Fingerprinting the whole finding set
+ * would mean one added finding produces a brand-new ticket while the old one
+ * still stands, so a slowly-degrading project accumulates near-duplicates —
+ * the same "worse than no cron" outcome by a slightly different route. Per
+ * check also makes partial repair behave: fix one drifting check, its ticket
+ * closes, the others stay open on their own merits.
+ *
+ * ## A closed ticket does not suppress live drift
+ *
+ * Enforced by construction rather than by a conditional: this planner is given
+ * only the OPEN tickets, so a closed one cannot suppress anything. It is not
+ * that closed tickets are checked and then ignored — they are not in evidence.
+ *
+ * The alternative, treating closure as permanent suppression, means closing a
+ * ticket without fixing anything makes that drift invisible forever, which is
+ * the silent decay this consumer exists to prevent. Suppression should be a
+ * configured declaration visible in a diff, not a side effect of somebody
+ * tidying a backlog. Turning the check off in config is the sanctioned way.
+ * @module health/drift-tickets
+ */
+/** Statuses that count as drift worth tracking. `pass` is not drift. */
+const DRIFT_STATUSES = new Set(["warn", "fail"]);
+/** Marker prefix written into a filed ticket so the next run can find it. */
+export const DRIFT_MARKER_PREFIX = "lisa-health-drift";
+/**
+ * The dedupe marker for one check.
+ *
+ * An HTML comment so it is invisible in rendered ticket bodies but present in
+ * the raw text every tracker returns. Trackers differ in what they preserve of
+ * a body; they do not differ in preserving its characters.
+ * @param check - The health check id
+ * @returns The marker to embed in a filed ticket
+ */
+export function driftMarker(check) {
+    return `<!-- ${DRIFT_MARKER_PREFIX}: ${check} -->`;
+}
+/**
+ * Compose the ticket body for one drifting check.
+ * @param finding - The drifting finding
+ * @returns Operator-readable body carrying the dedupe marker
+ */
+function bodyFor(finding) {
+    return [
+        `The scheduled health check found drift in \`${finding.check}\`.`,
+        "",
+        `**Status:** ${finding.status}`,
+        `**Layer:** ${finding.layer}`,
+        `**Reason:** ${finding.reason}`,
+        "",
+        "Filed automatically by the scheduled health consumer. It files; it never",
+        "closes or edits. Repairing the drift is separate work.",
+        "",
+        "If this drift is accepted rather than fixed, turn the check off in config",
+        "rather than closing this ticket — a closed ticket does not suppress live",
+        "drift, so it would simply be filed again on the next run.",
+        "",
+        driftMarker(finding.check),
+    ].join("\n");
+}
+/**
+ * Decide what to file for the drift a run found.
+ *
+ * Total and pure: every unique drifting check lands in exactly one of `file` or
+ * `alreadyTracked` after duplicate findings for that check collapse, so a caller
+ * reporting "nothing to do" is asserting it looked at all checks rather than
+ * that its filter happened to be empty.
+ * @param input - Findings from the run and the tracker's OPEN tickets
+ * @returns Tickets to file, and drift already covered
+ */
+export function planDriftTickets(input) {
+    const drifting = input.findings.filter(finding => DRIFT_STATUSES.has(finding.status));
+    // One entry per check even when a run reports the same check twice: the
+    // marker cannot distinguish them, so filing two would self-duplicate on the
+    // very first run — the defect this module exists to prevent, arriving before
+    // any second run happens. First occurrence wins, so the reported reason is
+    // the one a reader would see first in the run output.
+    const unique = drifting.filter((finding, index) => drifting.findIndex(other => other.check === finding.check) === index);
+    const decided = unique.map(finding => {
+        const marker = driftMarker(finding.check);
+        return {
+            finding,
+            marker,
+            existing: input.openTickets.find(ticket => ticket.body.includes(marker)),
+        };
+    });
+    return {
+        file: decided.flatMap(entry => entry.existing
+            ? []
+            : [
+                {
+                    check: entry.finding.check,
+                    title: `health drift: ${entry.finding.check}`,
+                    body: bodyFor(entry.finding),
+                    marker: entry.marker,
+                },
+            ]),
+        alreadyTracked: decided.flatMap(entry => entry.existing
+            ? [{ check: entry.finding.check, ticketId: entry.existing.id }]
+            : []),
+    };
+}
+//# sourceMappingURL=drift-tickets.js.map

package/dist/health/drift-tickets.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"drift-tickets.js","sourceRoot":"","sources":["../../src/health/drift-tickets.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AAIH,wEAAwE;AACxE,MAAM,cAAc,GAAG,IAAI,GAAG,CAAC,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC,CAAC;AAEjD,6EAA6E;AAC7E,MAAM,CAAC,MAAM,mBAAmB,GAAG,mBAAmB,CAAC;AAEvD;;;;;;;;GAQG;AACH,MAAM,UAAU,WAAW,CAAC,KAAa;IACvC,OAAO,QAAQ,mBAAmB,KAAK,KAAK,MAAM,CAAC;AACrD,CAAC;AAwCD;;;;GAIG;AACH,SAAS,OAAO,CAAC,OAAsB;IACrC,OAAO;QACL,+CAA+C,OAAO,CAAC,KAAK,KAAK;QACjE,EAAE;QACF,eAAe,OAAO,CAAC,MAAM,EAAE;QAC/B,cAAc,OAAO,CAAC,KAAK,EAAE;QAC7B,eAAe,OAAO,CAAC,MAAM,EAAE;QAC/B,EAAE;QACF,0EAA0E;QAC1E,wDAAwD;QACxD,EAAE;QACF,2EAA2E;QAC3E,0EAA0E;QAC1E,2DAA2D;QAC3D,EAAE;QACF,WAAW,CAAC,OAAO,CAAC,KAAK,CAAC;KAC3B,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AACf,CAAC;AAED;;;;;;;;;GASG;AACH,MAAM,UAAU,gBAAgB,CAAC,KAAuB;IACtD,MAAM,QAAQ,GAAG,KAAK,CAAC,QAAQ,CAAC,MAAM,CAAC,OAAO,CAAC,EAAE,CAC/C,cAAc,CAAC,GAAG,CAAC,OAAO,CAAC,MAAM,CAAC,CACnC,CAAC;IACF,wEAAwE;IACxE,4EAA4E;IAC5E,6EAA6E;IAC7E,2EAA2E;IAC3E,sDAAsD;IACtD,MAAM,MAAM,GAAG,QAAQ,CAAC,MAAM,CAC5B,CAAC,OAAO,EAAE,KAAK,EAAE,EAAE,CACjB,QAAQ,CAAC,SAAS,CAAC,KAAK,CAAC,EAAE,CAAC,KAAK,CAAC,KAAK,KAAK,OAAO,CAAC,KAAK,CAAC,KAAK,KAAK,CACvE,CAAC;IAEF,MAAM,OAAO,GAAG,MAAM,CAAC,GAAG,CAAC,OAAO,CAAC,EAAE;QACnC,MAAM,MAAM,GAAG,WAAW,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC;QAC1C,OAAO;YACL,OAAO;YACP,MAAM;YACN,QAAQ,EAAE,KAAK,CAAC,WAAW,CAAC,IAAI,CAAC,MAAM,CAAC,EAAE,CAAC,MAAM,CAAC,IAAI,CAAC,QAAQ,CAAC,MAAM,CAAC,CAAC;SACzE,CAAC;IACJ,CAAC,CAAC,CAAC;IAEH,OAAO;QACL,IAAI,EAAE,OAAO,CAAC,OAAO,CAAC,KAAK,CAAC,EAAE,CAC5B,KAAK,CAAC,QAAQ;YACZ,CAAC,CAAC,EAAE;YACJ,CAAC,CAAC;gBACE;oBACE,KAAK,EAAE,KAAK,CAAC,OAAO,CAAC,KAAK;oBAC1B,KAAK,EAAE,iBAAiB,KAAK,CAAC,OAAO,CAAC,KAAK,EAAE;oBAC7C,IAAI,EAAE,OAAO,CAAC,KAAK,CAAC,OAAO,CAAC;oBAC5B,MAAM,EAAE,KAAK,CAAC,MAAM;iBACrB;aACF,CACN;QACD,cAAc,EAAE,OAAO,CAAC,OAAO,CAAC,KAAK,CAAC,EAAE,CACtC,KAAK,CAAC,QAAQ;YACZ,CAAC,CAAC,CAAC,EAAE,KAAK,EAAE,KAAK,CAAC,OAAO,CAAC,KAAK,EAAE,QAAQ,EAAE,KAAK,CAAC,QAAQ,CAAC,EAAE,EAAE,CAAC;YAC/D,CAAC,CAAC,EAAE,CACP;KACF,CAAC;AACJ,CAAC"}

package/dist/health/index.d.ts

@@ -5,4 +5,5 @@ export * from "./storage.js";
 export * from "./evaluation-protocol.js";
 export * from "./prepare.js";
 export * from "./consumer.js";
+export * from "./drift-tickets.js";
 //# sourceMappingURL=index.d.ts.map

package/dist/health/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/health/index.ts"],"names":[],"mappings":"AAAA,cAAc,eAAe,CAAC;AAC9B,cAAc,cAAc,CAAC;AAC7B,cAAc,oBAAoB,CAAC;AACnC,cAAc,cAAc,CAAC;AAC7B,cAAc,0BAA0B,CAAC;AACzC,cAAc,cAAc,CAAC;AAC7B,cAAc,eAAe,CAAC"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/health/index.ts"],"names":[],"mappings":"AAAA,cAAc,eAAe,CAAC;AAC9B,cAAc,cAAc,CAAC;AAC7B,cAAc,oBAAoB,CAAC;AACnC,cAAc,cAAc,CAAC;AAC7B,cAAc,0BAA0B,CAAC;AACzC,cAAc,cAAc,CAAC;AAC7B,cAAc,eAAe,CAAC;AAC9B,cAAc,oBAAoB,CAAC"}

package/dist/health/index.js

@@ -5,4 +5,5 @@ export * from "./storage.js";
 export * from "./evaluation-protocol.js";
 export * from "./prepare.js";
 export * from "./consumer.js";
+export * from "./drift-tickets.js";
 //# sourceMappingURL=index.js.map

package/dist/health/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/health/index.ts"],"names":[],"mappings":"AAAA,cAAc,eAAe,CAAC;AAC9B,cAAc,cAAc,CAAC;AAC7B,cAAc,oBAAoB,CAAC;AACnC,cAAc,cAAc,CAAC;AAC7B,cAAc,0BAA0B,CAAC;AACzC,cAAc,cAAc,CAAC;AAC7B,cAAc,eAAe,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/health/index.ts"],"names":[],"mappings":"AAAA,cAAc,eAAe,CAAC;AAC9B,cAAc,cAAc,CAAC;AAC7B,cAAc,oBAAoB,CAAC;AACnC,cAAc,cAAc,CAAC;AAC7B,cAAc,0BAA0B,CAAC;AACzC,cAAc,cAAc,CAAC;AAC7B,cAAc,eAAe,CAAC;AAC9B,cAAc,oBAAoB,CAAC"}

package/package.json

@@ -129,7 +129,7 @@
     }
   },
   "name": "@codyswann/lisa",
-  "version": "3.18.2",
+  "version": "3.19.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

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

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

package/plugins/lisa/.codex-plugin/skills/lisa-health-drift-cron/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: lisa-health-drift-cron
+description: "Scheduled health consumer"
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Lisa Health Drift Cron: $ARGUMENTS
+
+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.
+
+It **files**. It never closes, edits, or repairs. Disposal belongs to humans and the Implement factory.
+
+## Why idempotency is the whole job
+
+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.
+
+**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.
+
+## Phase 1 — Run the health check headless
+
+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.
+
+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.
+
+Do not reconstruct, merge, or summarize findings; the result is passed to Phase 3 verbatim.
+
+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.
+
+## Phase 2 — Read the OPEN tickets only
+
+Fetch the tracker's **open** items carrying the drift marker prefix `lisa-health-drift`.
+
+**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.
+
+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.
+
+## Phase 3 — Plan
+
+Feed the findings and the open tickets to `planDriftTickets`. It returns:
+
+- `file` — one entry per drifting check with no open ticket, carrying `title`, `body`, and `marker`
+- `alreadyTracked` — drift that an open ticket already covers, with the ticket id
+
+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.
+
+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.
+
+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.
+
+## Phase 4 — File
+
+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.
+
+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.
+
+## Run outcome
+
+Per the automation runbook contract, end with exactly one outcome and a one-line operator-readable summary:
+
+- **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).`
+- **change-proved** — tickets were filed. `change-proved — filed 1 drift ticket: coverage-floor (#57).`
+- **recovery-required** — the health run failed, or a write failed. Name what a human must do.
+
+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.
+
+## Registration
+
+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.
+
+Register at most **one** per project.
+
+### What the dedupe does and does not guarantee
+
+It guarantees **convergence, not mutual exclusion**, and the difference is worth stating plainly rather than leaving to be discovered.
+
+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.
+
+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.
+
+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.

package/plugins/lisa/.codex-plugin/skills/lisa-health-drift-cron/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Health Drift Cron"
+short_description: "Scheduled health consumer"
+default_prompt:
+  - "Use $lisa-health-drift-cron: Scheduled health consumer."

package/plugins/lisa/.codex-plugin/skills/lisa-setup-automations/SKILL.md

@@ -197,6 +197,16 @@ 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 — 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
+`/lisa:health-drift-cron` at that cadence. It runs Lisa Health headless and,
+for each check that has drifted, files exactly one ticket through
+`lisa-tracker-write`. A project in band files nothing. Register at most ONE per
+project: the per-check marker dedupe converges under a single scheduled runner,
+and two concurrent runs can both observe an empty open-ticket set and both
+file. Tear-down removes it with the rest of the `lisa-auto-<project>-*` set.
+
 **Exploratory PRD pressure gate.** `auto-start-prds=true` means "create PRDs in the ready PRD
 lifecycle when the PRD queue has capacity," not "always create a new ready PRD." The
 `exploratory-prds` automation uses the same PRD source queue and pressure roles reported by

package/plugins/lisa/commands/health-drift-cron.md

@@ -0,0 +1,9 @@
+---
+description: "Run the scheduled health consumer: check health headless, and file one deduped ticket per drifting check."
+argument-hint: "[project-path]"
+---
+
+Use the /lisa-health-drift-cron skill to run Lisa Health for the optional project path and turn any
+drift into tracked work. File exactly one ticket per drifting check through `lisa-tracker-write`,
+deduped by the per-check marker across OPEN tickets only, and file nothing for a project in band.
+This flow files; it never closes, edits, or repairs. $ARGUMENTS

package/plugins/lisa/skills/lisa-health-drift-cron/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: lisa-health-drift-cron
+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."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Lisa Health Drift Cron: $ARGUMENTS
+
+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.
+
+It **files**. It never closes, edits, or repairs. Disposal belongs to humans and the Implement factory.
+
+## Why idempotency is the whole job
+
+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.
+
+**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.
+
+## Phase 1 — Run the health check headless
+
+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.
+
+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.
+
+Do not reconstruct, merge, or summarize findings; the result is passed to Phase 3 verbatim.
+
+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.
+
+## Phase 2 — Read the OPEN tickets only
+
+Fetch the tracker's **open** items carrying the drift marker prefix `lisa-health-drift`.
+
+**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.
+
+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.
+
+## Phase 3 — Plan
+
+Feed the findings and the open tickets to `planDriftTickets`. It returns:
+
+- `file` — one entry per drifting check with no open ticket, carrying `title`, `body`, and `marker`
+- `alreadyTracked` — drift that an open ticket already covers, with the ticket id
+
+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.
+
+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.
+
+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.
+
+## Phase 4 — File
+
+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.
+
+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.
+
+## Run outcome
+
+Per the automation runbook contract, end with exactly one outcome and a one-line operator-readable summary:
+
+- **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).`
+- **change-proved** — tickets were filed. `change-proved — filed 1 drift ticket: coverage-floor (#57).`
+- **recovery-required** — the health run failed, or a write failed. Name what a human must do.
+
+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.
+
+## Registration
+
+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.
+
+Register at most **one** per project.
+
+### What the dedupe does and does not guarantee
+
+It guarantees **convergence, not mutual exclusion**, and the difference is worth stating plainly rather than leaving to be discovered.
+
+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.
+
+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.
+
+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.

package/plugins/lisa/skills/lisa-health-drift-cron/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Health Drift Cron"
+short_description: "Scheduled health consumer"
+default_prompt:
+  - "Use $lisa-health-drift-cron: Scheduled health consumer."

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

@@ -197,6 +197,16 @@ 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 — 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
+`/lisa:health-drift-cron` at that cadence. It runs Lisa Health headless and,
+for each check that has drifted, files exactly one ticket through
+`lisa-tracker-write`. A project in band files nothing. Register at most ONE per
+project: the per-check marker dedupe converges under a single scheduled runner,
+and two concurrent runs can both observe an empty open-ticket set and both
+file. Tear-down removes it with the rest of the `lisa-auto-<project>-*` set.
+
 **Exploratory PRD pressure gate.** `auto-start-prds=true` means "create PRDs in the ready PRD
 lifecycle when the PRD queue has capacity," not "always create a new ready PRD." The
 `exploratory-prds` automation uses the same PRD source queue and pressure roles reported by

package/plugins/lisa-agy/commands/lisa/health-drift-cron.md

@@ -0,0 +1,9 @@
+---
+description: "Run the scheduled health consumer: check health headless, and file one deduped ticket per drifting check."
+argument-hint: "[project-path]"
+---
+
+Use the /lisa-health-drift-cron skill to run Lisa Health for the optional project path and turn any
+drift into tracked work. File exactly one ticket per drifting check through `lisa-tracker-write`,
+deduped by the per-check marker across OPEN tickets only, and file nothing for a project in band.
+This flow files; it never closes, edits, or repairs. $ARGUMENTS

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-health-drift-cron/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: lisa-health-drift-cron
+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."
+allowed-tools: ["Skill", "Bash", "Read"]
+---
+
+# Lisa Health Drift Cron: $ARGUMENTS
+
+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.
+
+It **files**. It never closes, edits, or repairs. Disposal belongs to humans and the Implement factory.
+
+## Why idempotency is the whole job
+
+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.
+
+**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.
+
+## Phase 1 — Run the health check headless
+
+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.
+
+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.
+
+Do not reconstruct, merge, or summarize findings; the result is passed to Phase 3 verbatim.
+
+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.
+
+## Phase 2 — Read the OPEN tickets only
+
+Fetch the tracker's **open** items carrying the drift marker prefix `lisa-health-drift`.
+
+**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.
+
+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.
+
+## Phase 3 — Plan
+
+Feed the findings and the open tickets to `planDriftTickets`. It returns:
+
+- `file` — one entry per drifting check with no open ticket, carrying `title`, `body`, and `marker`
+- `alreadyTracked` — drift that an open ticket already covers, with the ticket id
+
+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.
+
+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.
+
+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.
+
+## Phase 4 — File
+
+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.
+
+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.
+
+## Run outcome
+
+Per the automation runbook contract, end with exactly one outcome and a one-line operator-readable summary:
+
+- **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).`
+- **change-proved** — tickets were filed. `change-proved — filed 1 drift ticket: coverage-floor (#57).`
+- **recovery-required** — the health run failed, or a write failed. Name what a human must do.
+
+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.
+
+## Registration
+
+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.
+
+Register at most **one** per project.
+
+### What the dedupe does and does not guarantee
+
+It guarantees **convergence, not mutual exclusion**, and the difference is worth stating plainly rather than leaving to be discovered.
+
+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.
+
+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.
+
+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.

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

@@ -197,6 +197,16 @@ 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 — 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
+`/lisa:health-drift-cron` at that cadence. It runs Lisa Health headless and,
+for each check that has drifted, files exactly one ticket through
+`lisa-tracker-write`. A project in band files nothing. Register at most ONE per
+project: the per-check marker dedupe converges under a single scheduled runner,
+and two concurrent runs can both observe an empty open-ticket set and both
+file. Tear-down removes it with the rest of the `lisa-auto-<project>-*` set.
+
 **Exploratory PRD pressure gate.** `auto-start-prds=true` means "create PRDs in the ready PRD
 lifecycle when the PRD queue has capacity," not "always create a new ready PRD." The
 `exploratory-prds` automation uses the same PRD source queue and pressure roles reported by

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.18.2",
+  "version": "3.19.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.18.2",
+  "version": "3.19.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"