@codyswann/lisa 2.99.1 → 2.100.1
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 +39 -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 +39 -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.1",
|
|
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
|
|
@@ -95,6 +104,35 @@ Each verdict must carry a concrete next action:
|
|
|
95
104
|
- Prefer manual product clarification or the upstream product workflow for `PRODUCT_OWNED_STATE`.
|
|
96
105
|
- Prefer fixing config, lifecycle adoption, or repo scoping for `MISCONFIGURED`.
|
|
97
106
|
|
|
107
|
+
## Ownership and repair readiness
|
|
108
|
+
|
|
109
|
+
Classify ownership before recommending any command. Intake-explain should make clear whether the item is waiting for a human/product promotion, already belongs to Lisa automation, or is terminal enough that normal intake should leave it alone.
|
|
110
|
+
|
|
111
|
+
Product-owned roles are roles that Lisa must not mutate from this read-only diagnosis and that normal intake/repair should not "fix" just because the item exists:
|
|
112
|
+
|
|
113
|
+
- PRD `draft`: still being authored; next action is manual product clarification or promotion to `ready`.
|
|
114
|
+
- PRD `shipped`: generated work is complete and the next automated owner is `/lisa:verify-prd`, not PRD intake or repair.
|
|
115
|
+
- PRD `verified`: empirically checked terminal state; no intake or repair action is required unless a human reopens scope.
|
|
116
|
+
- Build items with no build lifecycle role or without the configured current-repo scope: outside the build pickup lane until a human adopts the lifecycle label or fixes repo scoping.
|
|
117
|
+
|
|
118
|
+
Lisa-owned roles are roles where the framework has accepted responsibility for moving the item forward or surfacing a precise blocker:
|
|
119
|
+
|
|
120
|
+
- PRD `ready`: actionable for `/lisa:intake`.
|
|
121
|
+
- PRD `in_review`: already claimed by PRD intake; repairable only when the item is stale beyond `stale_after` and not suppressed by repair backoff.
|
|
122
|
+
- PRD `blocked`: Lisa asked for clarification or failed validation; repairable only when new answers, dependency changes, or other current signals make another validate-to-route pass materially different.
|
|
123
|
+
- PRD `ticketed`: generated work exists; normal PRD intake owns rollup toward `shipped`, while repair-intake may reconcile rollup drift when all generated top-level work is terminal.
|
|
124
|
+
- Build `ready`: actionable for `/lisa:intake` if repo-scope, leaf-only, and dependency gates pass.
|
|
125
|
+
- Build `claimed`: already claimed by build intake; repairable only when stale beyond `stale_after` and not protected by recent PR/check/comment activity.
|
|
126
|
+
- Build `blocked`: Lisa surfaced an implementation blocker; repairable only when every parsed blocker is cleared or the blocker fingerprint changed enough to justify a new attempt.
|
|
127
|
+
- Build `done`: terminal build role; repair-intake may only reconcile provider-native close-out drift, not re-run implementation.
|
|
128
|
+
|
|
129
|
+
Report repair readiness in this order:
|
|
130
|
+
|
|
131
|
+
1. If the role is product-owned, return `PRODUCT_OWNED_STATE` and name the product or verification workflow that owns the next move.
|
|
132
|
+
2. If the item is Lisa-owned but in an in-progress role, compare the newest activity signal with the configured staleness threshold. Fresh activity returns `WAITING_ON_STALENESS`; stale activity can return `ELIGIBLE_FOR_REPAIR`.
|
|
133
|
+
3. If the item is Lisa-owned but blocked, evaluate current blockers, clarifying answers, and the `[lisa-repair-intake]` fingerprint/backoff window. Active blockers or unchanged fingerprints stay held; cleared blockers or new answers can return `ELIGIBLE_FOR_REPAIR`.
|
|
134
|
+
4. If the item is ready for first pickup, run the same repo-scope, leaf-only, and dependency checks used by intake before returning `ELIGIBLE_FOR_INTAKE`.
|
|
135
|
+
|
|
98
136
|
## Gate and ownership expectations
|
|
99
137
|
|
|
100
138
|
The explanation must stay aligned with existing Lisa rules:
|
|
@@ -103,7 +141,7 @@ The explanation must stay aligned with existing Lisa rules:
|
|
|
103
141
|
- If a build item has active blockers, list the blocker refs and explain that intake would hold or skip it until they clear.
|
|
104
142
|
- 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
143
|
- 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.
|
|
144
|
+
- 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
145
|
|
|
108
146
|
## Rule explanation expectations
|
|
109
147
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.100.1",
|
|
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.1",
|
|
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
|
|
@@ -95,6 +104,35 @@ Each verdict must carry a concrete next action:
|
|
|
95
104
|
- Prefer manual product clarification or the upstream product workflow for `PRODUCT_OWNED_STATE`.
|
|
96
105
|
- Prefer fixing config, lifecycle adoption, or repo scoping for `MISCONFIGURED`.
|
|
97
106
|
|
|
107
|
+
## Ownership and repair readiness
|
|
108
|
+
|
|
109
|
+
Classify ownership before recommending any command. Intake-explain should make clear whether the item is waiting for a human/product promotion, already belongs to Lisa automation, or is terminal enough that normal intake should leave it alone.
|
|
110
|
+
|
|
111
|
+
Product-owned roles are roles that Lisa must not mutate from this read-only diagnosis and that normal intake/repair should not "fix" just because the item exists:
|
|
112
|
+
|
|
113
|
+
- PRD `draft`: still being authored; next action is manual product clarification or promotion to `ready`.
|
|
114
|
+
- PRD `shipped`: generated work is complete and the next automated owner is `/lisa:verify-prd`, not PRD intake or repair.
|
|
115
|
+
- PRD `verified`: empirically checked terminal state; no intake or repair action is required unless a human reopens scope.
|
|
116
|
+
- Build items with no build lifecycle role or without the configured current-repo scope: outside the build pickup lane until a human adopts the lifecycle label or fixes repo scoping.
|
|
117
|
+
|
|
118
|
+
Lisa-owned roles are roles where the framework has accepted responsibility for moving the item forward or surfacing a precise blocker:
|
|
119
|
+
|
|
120
|
+
- PRD `ready`: actionable for `/lisa:intake`.
|
|
121
|
+
- PRD `in_review`: already claimed by PRD intake; repairable only when the item is stale beyond `stale_after` and not suppressed by repair backoff.
|
|
122
|
+
- PRD `blocked`: Lisa asked for clarification or failed validation; repairable only when new answers, dependency changes, or other current signals make another validate-to-route pass materially different.
|
|
123
|
+
- PRD `ticketed`: generated work exists; normal PRD intake owns rollup toward `shipped`, while repair-intake may reconcile rollup drift when all generated top-level work is terminal.
|
|
124
|
+
- Build `ready`: actionable for `/lisa:intake` if repo-scope, leaf-only, and dependency gates pass.
|
|
125
|
+
- Build `claimed`: already claimed by build intake; repairable only when stale beyond `stale_after` and not protected by recent PR/check/comment activity.
|
|
126
|
+
- Build `blocked`: Lisa surfaced an implementation blocker; repairable only when every parsed blocker is cleared or the blocker fingerprint changed enough to justify a new attempt.
|
|
127
|
+
- Build `done`: terminal build role; repair-intake may only reconcile provider-native close-out drift, not re-run implementation.
|
|
128
|
+
|
|
129
|
+
Report repair readiness in this order:
|
|
130
|
+
|
|
131
|
+
1. If the role is product-owned, return `PRODUCT_OWNED_STATE` and name the product or verification workflow that owns the next move.
|
|
132
|
+
2. If the item is Lisa-owned but in an in-progress role, compare the newest activity signal with the configured staleness threshold. Fresh activity returns `WAITING_ON_STALENESS`; stale activity can return `ELIGIBLE_FOR_REPAIR`.
|
|
133
|
+
3. If the item is Lisa-owned but blocked, evaluate current blockers, clarifying answers, and the `[lisa-repair-intake]` fingerprint/backoff window. Active blockers or unchanged fingerprints stay held; cleared blockers or new answers can return `ELIGIBLE_FOR_REPAIR`.
|
|
134
|
+
4. If the item is ready for first pickup, run the same repo-scope, leaf-only, and dependency checks used by intake before returning `ELIGIBLE_FOR_INTAKE`.
|
|
135
|
+
|
|
98
136
|
## Gate and ownership expectations
|
|
99
137
|
|
|
100
138
|
The explanation must stay aligned with existing Lisa rules:
|
|
@@ -103,7 +141,7 @@ The explanation must stay aligned with existing Lisa rules:
|
|
|
103
141
|
- If a build item has active blockers, list the blocker refs and explain that intake would hold or skip it until they clear.
|
|
104
142
|
- 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
143
|
- 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.
|
|
144
|
+
- 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
145
|
|
|
108
146
|
## Rule explanation expectations
|
|
109
147
|
|