@codyswann/lisa 2.104.0 → 2.104.3
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/rules/repo-scope-split.md +1 -1
- package/plugins/lisa/skills/github-build-intake/SKILL.md +1 -0
- package/plugins/lisa/skills/intake-explain/SKILL.md +28 -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/rules/repo-scope-split.md +1 -1
- package/plugins/src/base/skills/github-build-intake/SKILL.md +1 -0
- package/plugins/src/base/skills/intake-explain/SKILL.md +28 -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.104.
|
|
85
|
+
"version": "2.104.3",
|
|
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": {
|
|
@@ -47,7 +47,7 @@ Resolve the current repo per the `config-resolution` "Repo scoping" section (con
|
|
|
47
47
|
|
|
48
48
|
**Cost.** Only **unlabeled** candidates need content determination; once stamped, wrong-repo candidates are skipped by label alone. Prefer candidates already labeled `repo:<current>` first (cheap claim), falling through to unlabeled candidates (determine + stamp) only when no pre-labeled current-repo leaf is ready.
|
|
49
49
|
|
|
50
|
-
A container (Epic/Story/Spike) is handled by the leaf-only gate, not here — containers may span repos and are never claimed/built directly.
|
|
50
|
+
A container (Epic/Story/Spike) is handled by the leaf-only gate, not here — containers may span repos, may keep multiple `repo:<name>` labels for visibility, and are never claimed/built directly. Only a leaf work unit is split or skipped by repo scope.
|
|
51
51
|
|
|
52
52
|
## Vendor mechanics
|
|
53
53
|
|
|
@@ -170,6 +170,7 @@ GitHub Issues live in one repo by definition, so the scanned repo's issues are u
|
|
|
170
170
|
3. **Per candidate, apply the repo-scope decision (`repo-scope-split`):**
|
|
171
171
|
- Carries `repo:<other>` → **skip** (leave it `ready` for that repo's own intake); next candidate.
|
|
172
172
|
- **Unlabeled** → determine the target repo(s) from the issue + code surfaces, then **stamp** `repo:<name>` via `gh issue edit <n> --add-label "repo:<name>"` (create the label lazily) so later cycles filter cheaply; re-apply with the now-known repo. (An issue whose work is entirely in the scanned repo is simply labeled `repo:<current>`.)
|
|
173
|
+
- **Container visibility is allowed.** A multi-repo Epic / Story / Spike may legitimately carry multiple `repo:<name>` labels for operator visibility. Do not split or claim it here; leave the repo markers intact and fall through to the leaf-only gate, which repairs the stale build-ready label instead of dispatching the container.
|
|
173
174
|
- **Multi-repo leaf → split, never claim.** Run the `repo-scope-split` work-time procedure into single-repo siblings, each created **build-ready** (`build_ready: true`) and stamped with its own `repo:<name>`; the current repo's sibling becomes a normal candidate.
|
|
174
175
|
- **Single-repo leaf for the current repo** → fall through to 3a (leaf-only gate) and 3b (claim).
|
|
175
176
|
4. Continue until a claimable current-repo leaf is found (claim it; one per cycle) or the ready set is exhausted — exit cleanly with `"No ready issues for repo <current>. Nothing to do."`.
|
|
@@ -215,6 +215,34 @@ The `Next action:` line should stay small and specific. Prefer one actionable fo
|
|
|
215
215
|
- "manual product clarification" when Lisa is not the current owner
|
|
216
216
|
- "fix `.lisa.config.json` or lifecycle labels" when the problem is misconfiguration
|
|
217
217
|
|
|
218
|
+
## Smoke fixtures and read-only assertions
|
|
219
|
+
|
|
220
|
+
Intake-explain must keep representative smoke fixtures for both PRD and build lifecycles. These fixtures are contract examples for implementers and tests: they prove that lifecycle classification, dependency holds, staleness windows, and repair backoff map to the same verdict language operators see in real diagnosis output.
|
|
221
|
+
|
|
222
|
+
Minimum PRD smoke fixtures:
|
|
223
|
+
|
|
224
|
+
| Fixture | Decisive signals | Expected verdict |
|
|
225
|
+
|---|---|---|
|
|
226
|
+
| `prd-draft-product-owned` | PRD role `draft`; source lane resolved; no Lisa claim marker | `PRODUCT_OWNED_STATE` |
|
|
227
|
+
| `prd-ready-actionable` | PRD role `ready`; source lane resolved; validation-ready content present | `ELIGIBLE_FOR_INTAKE` |
|
|
228
|
+
| `prd-in-review-fresh` | PRD role `in_review`; newest Lisa or tracker activity is inside `stale_after` | `WAITING_ON_STALENESS` |
|
|
229
|
+
| `prd-blocked-backoff` | PRD role `blocked`; latest `[lisa-repair-intake]` fingerprint is unchanged and inside the backoff window | `WAITING_ON_STALENESS` |
|
|
230
|
+
| `prd-blocked-new-signal` | PRD role `blocked`; clarifying answer or blocker fingerprint changed after the last repair marker | `ELIGIBLE_FOR_REPAIR` |
|
|
231
|
+
|
|
232
|
+
Minimum build smoke fixtures:
|
|
233
|
+
|
|
234
|
+
| Fixture | Decisive signals | Expected verdict |
|
|
235
|
+
|---|---|---|
|
|
236
|
+
| `build-ready-leaf` | `status:ready`; `repo:<current>`; leaf type; no open children; no active blockers | `ELIGIBLE_FOR_INTAKE` |
|
|
237
|
+
| `build-active-dependency` | otherwise actionable ready leaf; `Blocked by:` points at an open blocker without a cleared status | `HELD_BY_BLOCKERS` |
|
|
238
|
+
| `build-cleared-dependency` | otherwise actionable ready leaf; blockers are closed or carry cleared build status | `ELIGIBLE_FOR_INTAKE` |
|
|
239
|
+
| `build-open-children` | build lifecycle role present; native sub-issues or body parentage include open child work | `NON_LEAF_CONTAINER` |
|
|
240
|
+
| `build-claimed-fresh` | `status:in-progress`; newest claim, PR, check, or issue activity is inside `stale_after` | `WAITING_ON_STALENESS` |
|
|
241
|
+
| `build-blocked-backoff` | `status:blocked`; blocker fingerprint unchanged and repair-backoff marker still suppresses retries | `WAITING_ON_STALENESS` |
|
|
242
|
+
| `build-blocked-cleared` | `status:blocked`; parsed blockers are now cleared or the blocker fingerprint changed | `ELIGIBLE_FOR_REPAIR` |
|
|
243
|
+
|
|
244
|
+
Every smoke fixture must assert read-only behavior. A diagnosis may call vendor read APIs, inspect config, and render a verdict, but it must not call write APIs such as `gh issue edit`, `gh issue comment`, label creation, issue creation, transition endpoints, PR mutation, or tracker comment/update calls. If execution intake would stamp repo labels, split a multi-repo leaf, repair a stale container label, add a dependency-hold comment, or retry stuck work, the smoke fixture should assert that intake-explain only reports that action as the next step.
|
|
245
|
+
|
|
218
246
|
## Output shape
|
|
219
247
|
|
|
220
248
|
Use a stable grouped shape so one diagnosis is easy to scan:
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.104.
|
|
3
|
+
"version": "2.104.3",
|
|
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.104.
|
|
3
|
+
"version": "2.104.3",
|
|
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"
|
|
@@ -47,7 +47,7 @@ Resolve the current repo per the `config-resolution` "Repo scoping" section (con
|
|
|
47
47
|
|
|
48
48
|
**Cost.** Only **unlabeled** candidates need content determination; once stamped, wrong-repo candidates are skipped by label alone. Prefer candidates already labeled `repo:<current>` first (cheap claim), falling through to unlabeled candidates (determine + stamp) only when no pre-labeled current-repo leaf is ready.
|
|
49
49
|
|
|
50
|
-
A container (Epic/Story/Spike) is handled by the leaf-only gate, not here — containers may span repos and are never claimed/built directly.
|
|
50
|
+
A container (Epic/Story/Spike) is handled by the leaf-only gate, not here — containers may span repos, may keep multiple `repo:<name>` labels for visibility, and are never claimed/built directly. Only a leaf work unit is split or skipped by repo scope.
|
|
51
51
|
|
|
52
52
|
## Vendor mechanics
|
|
53
53
|
|
|
@@ -170,6 +170,7 @@ GitHub Issues live in one repo by definition, so the scanned repo's issues are u
|
|
|
170
170
|
3. **Per candidate, apply the repo-scope decision (`repo-scope-split`):**
|
|
171
171
|
- Carries `repo:<other>` → **skip** (leave it `ready` for that repo's own intake); next candidate.
|
|
172
172
|
- **Unlabeled** → determine the target repo(s) from the issue + code surfaces, then **stamp** `repo:<name>` via `gh issue edit <n> --add-label "repo:<name>"` (create the label lazily) so later cycles filter cheaply; re-apply with the now-known repo. (An issue whose work is entirely in the scanned repo is simply labeled `repo:<current>`.)
|
|
173
|
+
- **Container visibility is allowed.** A multi-repo Epic / Story / Spike may legitimately carry multiple `repo:<name>` labels for operator visibility. Do not split or claim it here; leave the repo markers intact and fall through to the leaf-only gate, which repairs the stale build-ready label instead of dispatching the container.
|
|
173
174
|
- **Multi-repo leaf → split, never claim.** Run the `repo-scope-split` work-time procedure into single-repo siblings, each created **build-ready** (`build_ready: true`) and stamped with its own `repo:<name>`; the current repo's sibling becomes a normal candidate.
|
|
174
175
|
- **Single-repo leaf for the current repo** → fall through to 3a (leaf-only gate) and 3b (claim).
|
|
175
176
|
4. Continue until a claimable current-repo leaf is found (claim it; one per cycle) or the ready set is exhausted — exit cleanly with `"No ready issues for repo <current>. Nothing to do."`.
|
|
@@ -215,6 +215,34 @@ The `Next action:` line should stay small and specific. Prefer one actionable fo
|
|
|
215
215
|
- "manual product clarification" when Lisa is not the current owner
|
|
216
216
|
- "fix `.lisa.config.json` or lifecycle labels" when the problem is misconfiguration
|
|
217
217
|
|
|
218
|
+
## Smoke fixtures and read-only assertions
|
|
219
|
+
|
|
220
|
+
Intake-explain must keep representative smoke fixtures for both PRD and build lifecycles. These fixtures are contract examples for implementers and tests: they prove that lifecycle classification, dependency holds, staleness windows, and repair backoff map to the same verdict language operators see in real diagnosis output.
|
|
221
|
+
|
|
222
|
+
Minimum PRD smoke fixtures:
|
|
223
|
+
|
|
224
|
+
| Fixture | Decisive signals | Expected verdict |
|
|
225
|
+
|---|---|---|
|
|
226
|
+
| `prd-draft-product-owned` | PRD role `draft`; source lane resolved; no Lisa claim marker | `PRODUCT_OWNED_STATE` |
|
|
227
|
+
| `prd-ready-actionable` | PRD role `ready`; source lane resolved; validation-ready content present | `ELIGIBLE_FOR_INTAKE` |
|
|
228
|
+
| `prd-in-review-fresh` | PRD role `in_review`; newest Lisa or tracker activity is inside `stale_after` | `WAITING_ON_STALENESS` |
|
|
229
|
+
| `prd-blocked-backoff` | PRD role `blocked`; latest `[lisa-repair-intake]` fingerprint is unchanged and inside the backoff window | `WAITING_ON_STALENESS` |
|
|
230
|
+
| `prd-blocked-new-signal` | PRD role `blocked`; clarifying answer or blocker fingerprint changed after the last repair marker | `ELIGIBLE_FOR_REPAIR` |
|
|
231
|
+
|
|
232
|
+
Minimum build smoke fixtures:
|
|
233
|
+
|
|
234
|
+
| Fixture | Decisive signals | Expected verdict |
|
|
235
|
+
|---|---|---|
|
|
236
|
+
| `build-ready-leaf` | `status:ready`; `repo:<current>`; leaf type; no open children; no active blockers | `ELIGIBLE_FOR_INTAKE` |
|
|
237
|
+
| `build-active-dependency` | otherwise actionable ready leaf; `Blocked by:` points at an open blocker without a cleared status | `HELD_BY_BLOCKERS` |
|
|
238
|
+
| `build-cleared-dependency` | otherwise actionable ready leaf; blockers are closed or carry cleared build status | `ELIGIBLE_FOR_INTAKE` |
|
|
239
|
+
| `build-open-children` | build lifecycle role present; native sub-issues or body parentage include open child work | `NON_LEAF_CONTAINER` |
|
|
240
|
+
| `build-claimed-fresh` | `status:in-progress`; newest claim, PR, check, or issue activity is inside `stale_after` | `WAITING_ON_STALENESS` |
|
|
241
|
+
| `build-blocked-backoff` | `status:blocked`; blocker fingerprint unchanged and repair-backoff marker still suppresses retries | `WAITING_ON_STALENESS` |
|
|
242
|
+
| `build-blocked-cleared` | `status:blocked`; parsed blockers are now cleared or the blocker fingerprint changed | `ELIGIBLE_FOR_REPAIR` |
|
|
243
|
+
|
|
244
|
+
Every smoke fixture must assert read-only behavior. A diagnosis may call vendor read APIs, inspect config, and render a verdict, but it must not call write APIs such as `gh issue edit`, `gh issue comment`, label creation, issue creation, transition endpoints, PR mutation, or tracker comment/update calls. If execution intake would stamp repo labels, split a multi-repo leaf, repair a stale container label, add a dependency-hold comment, or retry stuck work, the smoke fixture should assert that intake-explain only reports that action as the next step.
|
|
245
|
+
|
|
218
246
|
## Output shape
|
|
219
247
|
|
|
220
248
|
Use a stable grouped shape so one diagnosis is easy to scan:
|