@codyswann/lisa 2.91.1 → 2.91.2
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/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/commands/automation-status.md +7 -0
- package/plugins/lisa/skills/automation-status/SKILL.md +36 -0
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-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-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.codex-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-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.codex-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-wiki/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
- package/plugins/src/base/commands/automation-status.md +7 -0
- package/plugins/src/base/skills/automation-status/SKILL.md +36 -0
package/package.json
CHANGED
|
@@ -82,7 +82,7 @@
|
|
|
82
82
|
"lodash": ">=4.18.1"
|
|
83
83
|
},
|
|
84
84
|
"name": "@codyswann/lisa",
|
|
85
|
-
"version": "2.91.
|
|
85
|
+
"version": "2.91.2",
|
|
86
86
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
87
87
|
"main": "dist/index.js",
|
|
88
88
|
"exports": {
|
|
@@ -3,3 +3,10 @@ description: "Inspect the current project's Lisa automation fleet and report whe
|
|
|
3
3
|
---
|
|
4
4
|
|
|
5
5
|
Use the /lisa:automation-status skill to inspect the current project's expected Lisa automations, compare them with the runtime's scheduler metadata, and report fleet health, drift, staleness, unsupported jobs, and remediation hints. $ARGUMENTS
|
|
6
|
+
|
|
7
|
+
Common operator usage:
|
|
8
|
+
|
|
9
|
+
- `/lisa:automation-status`
|
|
10
|
+
- `/lisa:automation-status --verbose`
|
|
11
|
+
|
|
12
|
+
This surface is read-only in v1. Use it to understand whether Lisa's unattended jobs are healthy before deciding whether to rerun `/lisa:setup-automations`, inspect scheduler errors, or use `/lisa:intake` / `/lisa:repair-intake` to address queue fallout.
|
|
@@ -49,6 +49,42 @@ For each expected automation, report:
|
|
|
49
49
|
|
|
50
50
|
Emit an overall grouped fleet verdict such as `HEALTHY`, `ATTENTION_NEEDED`, or `PARTIAL_SUPPORT`, plus the runtime surface inspected.
|
|
51
51
|
|
|
52
|
+
## Operator usage
|
|
53
|
+
|
|
54
|
+
Typical entrypoint:
|
|
55
|
+
|
|
56
|
+
```text
|
|
57
|
+
/lisa:automation-status
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
Use this command when an operator needs to answer one of these questions for the current repo:
|
|
61
|
+
|
|
62
|
+
- "Did Lisa set up every automation this project expects?"
|
|
63
|
+
- "Is the scheduler still pointing at the right cadence and queue arguments?"
|
|
64
|
+
- "Is the queue idle because there is no work, or because the automation is stale or failing?"
|
|
65
|
+
|
|
66
|
+
The report should be terminal-first and immediately actionable: observable scheduler facts first, then the smallest useful remediation step.
|
|
67
|
+
|
|
68
|
+
## Runtime differences
|
|
69
|
+
|
|
70
|
+
- **Codex**: prefer native automation metadata and use backing-store files only to fill gaps such as timestamps or failure recency. When Codex exposes health/memory signals, include them as observed facts rather than assumptions.
|
|
71
|
+
- **Claude**: use the `/schedule` listing as the primary runtime surface. Compare the live schedule name, cadence, and command shape against the Lisa contract, but degrade gracefully when `/schedule` does not expose equivalent recency or failure fields.
|
|
72
|
+
- **Other runtimes**: report automation-status as unsupported for that runtime instead of guessing from unrelated files or naming patterns.
|
|
73
|
+
|
|
74
|
+
## Verdicts and remediation
|
|
75
|
+
|
|
76
|
+
- `HEALTHY`: every expected automation exists and the inspected runtime metadata shows no actionable drift, staleness, or failure.
|
|
77
|
+
- `PARTIAL_SUPPORT`: the fleet is otherwise healthy, but at least one exploratory job is intentionally unsupported for this stack or runtime.
|
|
78
|
+
- `ATTENTION_NEEDED`: at least one automation is missing, drifted, stale, or failing.
|
|
79
|
+
|
|
80
|
+
Status-specific remediation guidance:
|
|
81
|
+
|
|
82
|
+
- `MISSING`: tell the operator which job is absent and recommend rerunning `/lisa:setup-automations` or recreating the missing job with the expected cadence and command.
|
|
83
|
+
- `DRIFTED`: show the expected versus observed cadence/command mismatch and recommend aligning the scheduler entry with Lisa's current setup contract, usually by rerunning `/lisa:setup-automations`.
|
|
84
|
+
- `STALE`: explain that the job exists but has not run recently enough for its cadence. Recommend inspecting the runtime's recent-run history or failure logs before changing queue state.
|
|
85
|
+
- `FAILING`: surface the failure signal directly and recommend checking the latest runtime error plus the affected queue command (`/lisa:intake`, `/lisa:repair-intake`, or exploratory job) after the scheduler issue is resolved.
|
|
86
|
+
- `UNSUPPORTED`: explain why the job is intentionally absent and say that no remediation is required unless the project stack or runtime support changed.
|
|
87
|
+
|
|
52
88
|
Render the report in grouped sections using the shared `scripts/automation-status-report.mjs` contract:
|
|
53
89
|
|
|
54
90
|
```text
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.91.
|
|
3
|
+
"version": "2.91.2",
|
|
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": "2.91.
|
|
3
|
+
"version": "2.91.2",
|
|
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"
|
|
@@ -3,3 +3,10 @@ description: "Inspect the current project's Lisa automation fleet and report whe
|
|
|
3
3
|
---
|
|
4
4
|
|
|
5
5
|
Use the /lisa:automation-status skill to inspect the current project's expected Lisa automations, compare them with the runtime's scheduler metadata, and report fleet health, drift, staleness, unsupported jobs, and remediation hints. $ARGUMENTS
|
|
6
|
+
|
|
7
|
+
Common operator usage:
|
|
8
|
+
|
|
9
|
+
- `/lisa:automation-status`
|
|
10
|
+
- `/lisa:automation-status --verbose`
|
|
11
|
+
|
|
12
|
+
This surface is read-only in v1. Use it to understand whether Lisa's unattended jobs are healthy before deciding whether to rerun `/lisa:setup-automations`, inspect scheduler errors, or use `/lisa:intake` / `/lisa:repair-intake` to address queue fallout.
|
|
@@ -49,6 +49,42 @@ For each expected automation, report:
|
|
|
49
49
|
|
|
50
50
|
Emit an overall grouped fleet verdict such as `HEALTHY`, `ATTENTION_NEEDED`, or `PARTIAL_SUPPORT`, plus the runtime surface inspected.
|
|
51
51
|
|
|
52
|
+
## Operator usage
|
|
53
|
+
|
|
54
|
+
Typical entrypoint:
|
|
55
|
+
|
|
56
|
+
```text
|
|
57
|
+
/lisa:automation-status
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
Use this command when an operator needs to answer one of these questions for the current repo:
|
|
61
|
+
|
|
62
|
+
- "Did Lisa set up every automation this project expects?"
|
|
63
|
+
- "Is the scheduler still pointing at the right cadence and queue arguments?"
|
|
64
|
+
- "Is the queue idle because there is no work, or because the automation is stale or failing?"
|
|
65
|
+
|
|
66
|
+
The report should be terminal-first and immediately actionable: observable scheduler facts first, then the smallest useful remediation step.
|
|
67
|
+
|
|
68
|
+
## Runtime differences
|
|
69
|
+
|
|
70
|
+
- **Codex**: prefer native automation metadata and use backing-store files only to fill gaps such as timestamps or failure recency. When Codex exposes health/memory signals, include them as observed facts rather than assumptions.
|
|
71
|
+
- **Claude**: use the `/schedule` listing as the primary runtime surface. Compare the live schedule name, cadence, and command shape against the Lisa contract, but degrade gracefully when `/schedule` does not expose equivalent recency or failure fields.
|
|
72
|
+
- **Other runtimes**: report automation-status as unsupported for that runtime instead of guessing from unrelated files or naming patterns.
|
|
73
|
+
|
|
74
|
+
## Verdicts and remediation
|
|
75
|
+
|
|
76
|
+
- `HEALTHY`: every expected automation exists and the inspected runtime metadata shows no actionable drift, staleness, or failure.
|
|
77
|
+
- `PARTIAL_SUPPORT`: the fleet is otherwise healthy, but at least one exploratory job is intentionally unsupported for this stack or runtime.
|
|
78
|
+
- `ATTENTION_NEEDED`: at least one automation is missing, drifted, stale, or failing.
|
|
79
|
+
|
|
80
|
+
Status-specific remediation guidance:
|
|
81
|
+
|
|
82
|
+
- `MISSING`: tell the operator which job is absent and recommend rerunning `/lisa:setup-automations` or recreating the missing job with the expected cadence and command.
|
|
83
|
+
- `DRIFTED`: show the expected versus observed cadence/command mismatch and recommend aligning the scheduler entry with Lisa's current setup contract, usually by rerunning `/lisa:setup-automations`.
|
|
84
|
+
- `STALE`: explain that the job exists but has not run recently enough for its cadence. Recommend inspecting the runtime's recent-run history or failure logs before changing queue state.
|
|
85
|
+
- `FAILING`: surface the failure signal directly and recommend checking the latest runtime error plus the affected queue command (`/lisa:intake`, `/lisa:repair-intake`, or exploratory job) after the scheduler issue is resolved.
|
|
86
|
+
- `UNSUPPORTED`: explain why the job is intentionally absent and say that no remediation is required unless the project stack or runtime support changed.
|
|
87
|
+
|
|
52
88
|
Render the report in grouped sections using the shared `scripts/automation-status-report.mjs` contract:
|
|
53
89
|
|
|
54
90
|
```text
|