@codyswann/lisa 2.78.0 → 2.79.0

package/package.json

@@ -82,7 +82,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.78.0",
+  "version": "2.79.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": "2.78.0",
+  "version": "2.79.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": "2.78.0",
+  "version": "2.79.0",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/rules/config-resolution.md

@@ -459,6 +459,38 @@ preflight for those configured vendors only.
      unreadable after all supported probes, is a doctor `FAIL`.
    - A reachable vendor with only auxiliary-substrate degradation is a doctor `WARN`.
 
+### Doctor automation readiness
+
+Doctor's automation-readiness group is also read-only. It answers "could this repo safely support
+Lisa's recurring automations from the current runtime?" without creating, editing, deleting, or
+reconciling any automation state.
+
+1. **Resolve the automation queues from merged config**
+   - Resolve the PRD automation queue from merged `source`.
+   - Resolve the build automation queue from merged `tracker`.
+   - Resolve repair-intake from the same queue-detection contract `lisa:intake` /
+     `lisa:repair-intake` already use; doctor should not invent a second queue schema.
+   - If an automation's queue cannot be resolved because `source`, `tracker`, or the selected
+     vendor's required keys are still missing after merge, that automation is a doctor `FAIL`.
+     Unattended runs would be ambiguous before the scheduler is even involved.
+2. **Check native scheduler availability by runtime, read-only**
+   - Codex automation support means the runtime exposes the native automations surface
+     (`automation_update`) that `setup-automations` depends on.
+   - Claude automation support means `/schedule` is available.
+   - Other runtimes should be reported explicitly as having no known native Lisa scheduler unless a
+     supported surface is observable.
+   - Doctor must not create a throwaway automation just to prove the scheduler exists.
+3. **Match exploratory automation support to the repo's shipped stack**
+   - `exploratory-bugs` exists only for stacks that ship `exploratory-qa` (`expo`, `rails`,
+     `harper-fabric`). If the repo lacks that command surface, doctor reports the automation as
+     `SKIP`, not `FAIL`.
+   - `exploratory-prds` follows the normal queue-resolution rules; if its prerequisites are
+     unresolved, preserve the exact blocking config fact.
+4. **Severity**
+   - Queue resolution failure is a doctor `FAIL`.
+   - Missing native scheduler support in an otherwise manually-usable repo is a doctor `WARN`.
+   - Intentional absence of an optional exploratory automation surface is a doctor `SKIP`.
+
 ## Skill mapping
 
 The shim → vendor mapping is fixed:

package/plugins/lisa/skills/doctor/SKILL.md

@@ -193,6 +193,47 @@ FAIL github.projects.v2: github.projects.v2.owner.slug must match github.org in
 Remediation: use a Project owned by CodySwannGT or remove github.projects.v2.
 ```
 
+### Minimum automation-readiness checks
+
+Doctor's automation-readiness group stays read-only: it audits whether this repo and runtime could
+support `/lisa:setup-automations` and the resulting recurring jobs, but it does **not** create,
+edit, delete, or reconcile automations on the default doctor path.
+
+1. **Resolve the queue inputs exactly as setup-automations would**
+   - Resolve the PRD queue from merged `source`.
+   - Resolve the build queue from merged `tracker`.
+   - Resolve the repair queue from the same queue-detection rules as `lisa:repair-intake`
+     (identical source-dispatch contract to `lisa:intake`).
+   - If any automation would require guessing because `source`, `tracker`, or their vendor keys are
+     still unresolved after the config-readiness audit, report that automation as `FAIL` rather
+     than pretending scheduling can proceed safely.
+2. **Audit the current runtime's native scheduler surface without mutating it**
+   - Codex: doctor should report whether the runtime exposes the native automations surface
+     (`automation_update`) needed by `/lisa:setup-automations`.
+   - Claude: doctor should report whether the runtime exposes `/schedule`.
+   - Other runtimes: doctor should explicitly say that no native Lisa scheduler is known for the
+     current runtime.
+   - This is observability only. Never create a placeholder automation just to prove the scheduler
+     works.
+3. **Check exploratory-automation support by shipped stack surface**
+   - `exploratory-bugs` is supported only when the project ships an `exploratory-qa` command
+     surface (the `expo`, `rails`, or `harper-fabric` stacks today). Reuse the same stack/support
+     rule documented by `setup-automations`; do not invent exploratory jobs for stacks that do not
+     ship that command.
+   - When the repo does not ship `exploratory-qa`, report `exploratory-bugs` as `SKIP` with the
+     reason.
+   - `exploratory-prds` remains applicable when the repo can run `/lisa:project-ideation`; if its
+     queue/config prerequisites are unresolved, report the exact blocking config fact.
+4. **Severity ladder**
+   - `PASS` when an automation's queue inputs are resolvable and the runtime exposes the required
+     native scheduler surface for that automation.
+   - `WARN` when Lisa remains usable manually, but the current runtime has no native scheduler
+     surface for unattended runs, so automation setup would be unavailable from here.
+   - `SKIP` when an optional automation is intentionally unsupported for this repo surface (for
+     example, `exploratory-bugs` on a stack with no `exploratory-qa` command).
+   - `FAIL` when the repo's config cannot resolve the queue that an automation needs, because that
+     would make unattended runs ambiguous or broken before scheduling even starts.
+
 ## Output contract
 
 The final report must:

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.78.0",
+  "version": "2.79.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": "2.78.0",
+  "version": "2.79.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.78.0",
+  "version": "2.79.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.78.0",
+  "version": "2.79.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.78.0",
+  "version": "2.79.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.78.0",
+  "version": "2.79.0",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.78.0",
+  "version": "2.79.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.78.0",
+  "version": "2.79.0",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/rules/config-resolution.md

@@ -459,6 +459,38 @@ preflight for those configured vendors only.
      unreadable after all supported probes, is a doctor `FAIL`.
    - A reachable vendor with only auxiliary-substrate degradation is a doctor `WARN`.
 
+### Doctor automation readiness
+
+Doctor's automation-readiness group is also read-only. It answers "could this repo safely support
+Lisa's recurring automations from the current runtime?" without creating, editing, deleting, or
+reconciling any automation state.
+
+1. **Resolve the automation queues from merged config**
+   - Resolve the PRD automation queue from merged `source`.
+   - Resolve the build automation queue from merged `tracker`.
+   - Resolve repair-intake from the same queue-detection contract `lisa:intake` /
+     `lisa:repair-intake` already use; doctor should not invent a second queue schema.
+   - If an automation's queue cannot be resolved because `source`, `tracker`, or the selected
+     vendor's required keys are still missing after merge, that automation is a doctor `FAIL`.
+     Unattended runs would be ambiguous before the scheduler is even involved.
+2. **Check native scheduler availability by runtime, read-only**
+   - Codex automation support means the runtime exposes the native automations surface
+     (`automation_update`) that `setup-automations` depends on.
+   - Claude automation support means `/schedule` is available.
+   - Other runtimes should be reported explicitly as having no known native Lisa scheduler unless a
+     supported surface is observable.
+   - Doctor must not create a throwaway automation just to prove the scheduler exists.
+3. **Match exploratory automation support to the repo's shipped stack**
+   - `exploratory-bugs` exists only for stacks that ship `exploratory-qa` (`expo`, `rails`,
+     `harper-fabric`). If the repo lacks that command surface, doctor reports the automation as
+     `SKIP`, not `FAIL`.
+   - `exploratory-prds` follows the normal queue-resolution rules; if its prerequisites are
+     unresolved, preserve the exact blocking config fact.
+4. **Severity**
+   - Queue resolution failure is a doctor `FAIL`.
+   - Missing native scheduler support in an otherwise manually-usable repo is a doctor `WARN`.
+   - Intentional absence of an optional exploratory automation surface is a doctor `SKIP`.
+
 ## Skill mapping
 
 The shim → vendor mapping is fixed:

package/plugins/src/base/skills/doctor/SKILL.md

@@ -193,6 +193,47 @@ FAIL github.projects.v2: github.projects.v2.owner.slug must match github.org in
 Remediation: use a Project owned by CodySwannGT or remove github.projects.v2.
 ```
 
+### Minimum automation-readiness checks
+
+Doctor's automation-readiness group stays read-only: it audits whether this repo and runtime could
+support `/lisa:setup-automations` and the resulting recurring jobs, but it does **not** create,
+edit, delete, or reconcile automations on the default doctor path.
+
+1. **Resolve the queue inputs exactly as setup-automations would**
+   - Resolve the PRD queue from merged `source`.
+   - Resolve the build queue from merged `tracker`.
+   - Resolve the repair queue from the same queue-detection rules as `lisa:repair-intake`
+     (identical source-dispatch contract to `lisa:intake`).
+   - If any automation would require guessing because `source`, `tracker`, or their vendor keys are
+     still unresolved after the config-readiness audit, report that automation as `FAIL` rather
+     than pretending scheduling can proceed safely.
+2. **Audit the current runtime's native scheduler surface without mutating it**
+   - Codex: doctor should report whether the runtime exposes the native automations surface
+     (`automation_update`) needed by `/lisa:setup-automations`.
+   - Claude: doctor should report whether the runtime exposes `/schedule`.
+   - Other runtimes: doctor should explicitly say that no native Lisa scheduler is known for the
+     current runtime.
+   - This is observability only. Never create a placeholder automation just to prove the scheduler
+     works.
+3. **Check exploratory-automation support by shipped stack surface**
+   - `exploratory-bugs` is supported only when the project ships an `exploratory-qa` command
+     surface (the `expo`, `rails`, or `harper-fabric` stacks today). Reuse the same stack/support
+     rule documented by `setup-automations`; do not invent exploratory jobs for stacks that do not
+     ship that command.
+   - When the repo does not ship `exploratory-qa`, report `exploratory-bugs` as `SKIP` with the
+     reason.
+   - `exploratory-prds` remains applicable when the repo can run `/lisa:project-ideation`; if its
+     queue/config prerequisites are unresolved, report the exact blocking config fact.
+4. **Severity ladder**
+   - `PASS` when an automation's queue inputs are resolvable and the runtime exposes the required
+     native scheduler surface for that automation.
+   - `WARN` when Lisa remains usable manually, but the current runtime has no native scheduler
+     surface for unattended runs, so automation setup would be unavailable from here.
+   - `SKIP` when an optional automation is intentionally unsupported for this repo surface (for
+     example, `exploratory-bugs` on a stack with no `exploratory-qa` command).
+   - `FAIL` when the repo's config cannot resolve the queue that an automation needs, because that
+     would make unattended runs ambiguous or broken before scheduling even starts.
+
 ## Output contract
 
 The final report must: