@codyswann/lisa 2.99.1 → 2.100.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/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/skills/intake-explain/SKILL.md +10 -1
- 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/skills/intake-explain/SKILL.md +10 -1
package/package.json
CHANGED
|
@@ -82,7 +82,7 @@
|
|
|
82
82
|
"lodash": ">=4.18.1"
|
|
83
83
|
},
|
|
84
84
|
"name": "@codyswann/lisa",
|
|
85
|
-
"version": "2.
|
|
85
|
+
"version": "2.100.0",
|
|
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": {
|
|
@@ -50,9 +50,18 @@ Keep the diagnosis terminal-first and human-readable: observable item facts firs
|
|
|
50
50
|
|
|
51
51
|
Resolve item family, queue source/tracker, and lifecycle role names from `.lisa.config.json` plus the same defaults the active intake and repair flows already consume.
|
|
52
52
|
|
|
53
|
+
Route one-item diagnosis through the same contract surfaces the write-side flows already trust:
|
|
54
|
+
|
|
55
|
+
- determine whether the item belongs to the configured PRD **source** lane or build **tracker** lane using the same `source` / `tracker` settings that `/lisa:intake` and `/lisa:repair-intake` already resolve
|
|
56
|
+
- read vendor lifecycle role names from the same config keys and fallback defaults documented in the `config-resolution` rule rather than inventing hardcoded status names
|
|
57
|
+
- keep repo/project scoping aligned with the same current-repo detection and queue-target rules the active intake scanners use
|
|
58
|
+
|
|
59
|
+
When the runtime can identify the item but cannot confidently resolve its source lane, tracker lane, lifecycle namespace, or current repo/project scope from that contract, report `MISCONFIGURED` instead of guessing.
|
|
60
|
+
|
|
53
61
|
Reuse the existing execution-side semantics instead of recreating them by hand:
|
|
54
62
|
|
|
55
63
|
- queue/source detection and lifecycle naming from intake + repair-intake
|
|
64
|
+
- one-item routing helpers for resolving the item's queue family against the correct source/tracker contract
|
|
56
65
|
- product-owned versus Lisa-owned lifecycle roles
|
|
57
66
|
- leaf-only and repo-scope build eligibility
|
|
58
67
|
- active dependency holds
|
|
@@ -103,7 +112,7 @@ The explanation must stay aligned with existing Lisa rules:
|
|
|
103
112
|
- If a build item has active blockers, list the blocker refs and explain that intake would hold or skip it until they clear.
|
|
104
113
|
- If a PRD is in a product-owned role such as `draft`, `shipped`, or `verified`, explain why intake or repair will not mutate it.
|
|
105
114
|
- If a claimed, in-review, or blocked item is not yet repairable, explain the relevant staleness or backoff condition at a human-readable level.
|
|
106
|
-
- If the repo or lifecycle namespace is unresolved, report `MISCONFIGURED` instead of pretending the item is idle or actionable.
|
|
115
|
+
- If the source lane, tracker lane, repo/project scope, or lifecycle namespace is unresolved, report `MISCONFIGURED` instead of pretending the item is idle or actionable.
|
|
107
116
|
|
|
108
117
|
## Rule explanation expectations
|
|
109
118
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.100.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": "2.
|
|
3
|
+
"version": "2.100.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"
|
|
@@ -50,9 +50,18 @@ Keep the diagnosis terminal-first and human-readable: observable item facts firs
|
|
|
50
50
|
|
|
51
51
|
Resolve item family, queue source/tracker, and lifecycle role names from `.lisa.config.json` plus the same defaults the active intake and repair flows already consume.
|
|
52
52
|
|
|
53
|
+
Route one-item diagnosis through the same contract surfaces the write-side flows already trust:
|
|
54
|
+
|
|
55
|
+
- determine whether the item belongs to the configured PRD **source** lane or build **tracker** lane using the same `source` / `tracker` settings that `/lisa:intake` and `/lisa:repair-intake` already resolve
|
|
56
|
+
- read vendor lifecycle role names from the same config keys and fallback defaults documented in the `config-resolution` rule rather than inventing hardcoded status names
|
|
57
|
+
- keep repo/project scoping aligned with the same current-repo detection and queue-target rules the active intake scanners use
|
|
58
|
+
|
|
59
|
+
When the runtime can identify the item but cannot confidently resolve its source lane, tracker lane, lifecycle namespace, or current repo/project scope from that contract, report `MISCONFIGURED` instead of guessing.
|
|
60
|
+
|
|
53
61
|
Reuse the existing execution-side semantics instead of recreating them by hand:
|
|
54
62
|
|
|
55
63
|
- queue/source detection and lifecycle naming from intake + repair-intake
|
|
64
|
+
- one-item routing helpers for resolving the item's queue family against the correct source/tracker contract
|
|
56
65
|
- product-owned versus Lisa-owned lifecycle roles
|
|
57
66
|
- leaf-only and repo-scope build eligibility
|
|
58
67
|
- active dependency holds
|
|
@@ -103,7 +112,7 @@ The explanation must stay aligned with existing Lisa rules:
|
|
|
103
112
|
- If a build item has active blockers, list the blocker refs and explain that intake would hold or skip it until they clear.
|
|
104
113
|
- If a PRD is in a product-owned role such as `draft`, `shipped`, or `verified`, explain why intake or repair will not mutate it.
|
|
105
114
|
- If a claimed, in-review, or blocked item is not yet repairable, explain the relevant staleness or backoff condition at a human-readable level.
|
|
106
|
-
- If the repo or lifecycle namespace is unresolved, report `MISCONFIGURED` instead of pretending the item is idle or actionable.
|
|
115
|
+
- If the source lane, tracker lane, repo/project scope, or lifecycle namespace is unresolved, report `MISCONFIGURED` instead of pretending the item is idle or actionable.
|
|
107
116
|
|
|
108
117
|
## Rule explanation expectations
|
|
109
118
|
|