@codyswann/lisa 2.77.2 → 2.79.0

package/package.json

@@ -82,7 +82,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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

@@ -140,6 +140,100 @@ every vendor Lisa supports.
    - `FAIL` when no supported substrate can prove read access for the configured tracker/source, or
      when the configured vendor target is unreadable from the current runtime.
 
+### Minimum GitHub Project coordination checks
+
+When `github.projects.v2` is configured, doctor must run one additional read-only coordination
+check instead of treating the config block as implicitly ready.
+
+1. **Delegate through the shared chokepoint**
+   - Call `lisa:github-project-v2` in read-only resolution mode:
+
+     ```text
+     operation: resolve-project
+     ```
+
+   - Do not inline ad-hoc Project GraphQL in doctor. Setup, doctor, writers, and linked-PR flows
+     must all read the same owner/access contract from the shared utility.
+2. **Preserve exact namespace + access failures**
+   - Enforce the v1 namespace rule exactly as documented by the shared utility. If
+     `github.projects.v2.owner.slug` does not match `github.org`, report:
+
+     ```yaml
+     code: project_namespace_mismatch
+     message: "github.projects.v2.owner.slug must match github.org in v1"
+     remediation: "Use a Project owned by <github.org> or remove github.projects.v2."
+     ```
+
+   - For owner-access or GraphQL failures, preserve the exact GitHub / GraphQL failure text in the
+     observed output. Examples include missing Project, `Resource not accessible by integration`,
+     unsupported owner kind, or a wrong owner/number pair.
+3. **Report exact remediation paths**
+   - Doctor must make the next operator action explicit. At minimum, say whether they need to:
+     1. choose a Project owned by the tracked repo namespace,
+     2. grant the token Project read/write access,
+     3. correct the configured Project number/owner, or
+     4. remove `github.projects.v2` when coordination is not required.
+4. **Map shared utility outcomes into doctor severity**
+   - `required: false` => doctor `WARN`. Repository-local GitHub issue/PR flows remain usable while
+     Project coordination is degraded.
+   - `required: true` => doctor `FAIL`. The same Project validation failure blocks Lisa readiness
+     because coordination was configured as required.
+
+Good output examples:
+
+```text
+WARN github.projects.v2: Resource not accessible by integration
+Observed: exact GitHub / GraphQL failure text preserved from resolve-project.
+Remediation: grant the token Project read/write access or remove github.projects.v2.required.
+Repository-local GitHub issue/PR flows remain usable; Project coordination is disabled.
+```
+
+```text
+FAIL github.projects.v2: github.projects.v2.owner.slug must match github.org in v1
+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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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.77.2",
+  "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

@@ -140,6 +140,100 @@ every vendor Lisa supports.
    - `FAIL` when no supported substrate can prove read access for the configured tracker/source, or
      when the configured vendor target is unreadable from the current runtime.
 
+### Minimum GitHub Project coordination checks
+
+When `github.projects.v2` is configured, doctor must run one additional read-only coordination
+check instead of treating the config block as implicitly ready.
+
+1. **Delegate through the shared chokepoint**
+   - Call `lisa:github-project-v2` in read-only resolution mode:
+
+     ```text
+     operation: resolve-project
+     ```
+
+   - Do not inline ad-hoc Project GraphQL in doctor. Setup, doctor, writers, and linked-PR flows
+     must all read the same owner/access contract from the shared utility.
+2. **Preserve exact namespace + access failures**
+   - Enforce the v1 namespace rule exactly as documented by the shared utility. If
+     `github.projects.v2.owner.slug` does not match `github.org`, report:
+
+     ```yaml
+     code: project_namespace_mismatch
+     message: "github.projects.v2.owner.slug must match github.org in v1"
+     remediation: "Use a Project owned by <github.org> or remove github.projects.v2."
+     ```
+
+   - For owner-access or GraphQL failures, preserve the exact GitHub / GraphQL failure text in the
+     observed output. Examples include missing Project, `Resource not accessible by integration`,
+     unsupported owner kind, or a wrong owner/number pair.
+3. **Report exact remediation paths**
+   - Doctor must make the next operator action explicit. At minimum, say whether they need to:
+     1. choose a Project owned by the tracked repo namespace,
+     2. grant the token Project read/write access,
+     3. correct the configured Project number/owner, or
+     4. remove `github.projects.v2` when coordination is not required.
+4. **Map shared utility outcomes into doctor severity**
+   - `required: false` => doctor `WARN`. Repository-local GitHub issue/PR flows remain usable while
+     Project coordination is degraded.
+   - `required: true` => doctor `FAIL`. The same Project validation failure blocks Lisa readiness
+     because coordination was configured as required.
+
+Good output examples:
+
+```text
+WARN github.projects.v2: Resource not accessible by integration
+Observed: exact GitHub / GraphQL failure text preserved from resolve-project.
+Remediation: grant the token Project read/write access or remove github.projects.v2.required.
+Repository-local GitHub issue/PR flows remain usable; Project coordination is disabled.
+```
+
+```text
+FAIL github.projects.v2: github.projects.v2.owner.slug must match github.org in v1
+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: