@codyswann/lisa 2.100.0 → 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 +29 -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/skills/intake-explain/SKILL.md +29 -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.100.
|
|
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": {
|
|
@@ -104,6 +104,35 @@ Each verdict must carry a concrete next action:
|
|
|
104
104
|
- Prefer manual product clarification or the upstream product workflow for `PRODUCT_OWNED_STATE`.
|
|
105
105
|
- Prefer fixing config, lifecycle adoption, or repo scoping for `MISCONFIGURED`.
|
|
106
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
|
+
|
|
107
136
|
## Gate and ownership expectations
|
|
108
137
|
|
|
109
138
|
The explanation must stay aligned with existing Lisa rules:
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.100.
|
|
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.100.
|
|
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"
|
|
@@ -104,6 +104,35 @@ Each verdict must carry a concrete next action:
|
|
|
104
104
|
- Prefer manual product clarification or the upstream product workflow for `PRODUCT_OWNED_STATE`.
|
|
105
105
|
- Prefer fixing config, lifecycle adoption, or repo scoping for `MISCONFIGURED`.
|
|
106
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
|
+
|
|
107
136
|
## Gate and ownership expectations
|
|
108
137
|
|
|
109
138
|
The explanation must stay aligned with existing Lisa rules:
|