@codyswann/lisa 4.29.6 → 4.29.7
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/all/copy-overwrite/scripts/lisa-gates.mjs +20 -2
- package/all/copy-overwrite/scripts/lisa-work-item.mjs +366 -78
- package/dist/core/lisa-owned-hash-ledger.d.ts.map +1 -1
- package/dist/core/lisa-owned-hash-ledger.js +4 -0
- package/dist/core/lisa-owned-hash-ledger.js.map +1 -1
- package/dist/core/nightly-e2e-guard-behavior-certificate.js +2 -2
- package/dist/core/upstream-evidence-manifest.d.ts.map +1 -1
- package/dist/core/upstream-evidence-manifest.js +4 -3
- package/dist/core/upstream-evidence-manifest.js.map +1 -1
- package/package.json +4 -4
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa/rules/reference/tracked-work.md +19 -0
- package/plugins/lisa-agy/plugin.json +1 -1
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-agy/plugin.json +1 -1
- package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-copilot/rules/reference/tracked-work.md +19 -0
- package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cursor/rules/tracked-work-reference.mdc +19 -0
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-agy/plugin.json +1 -1
- package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo-cursor/.claude-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-harper-fabric-agy/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric-cursor/.claude-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-nestjs-agy/plugin.json +1 -1
- package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs-cursor/.claude-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-openclaw-agy/plugin.json +1 -1
- package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-agy/plugin.json +1 -1
- package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-phaser-cursor/.claude-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-rails-agy/plugin.json +1 -1
- package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails-cursor/.claude-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-typescript-agy/plugin.json +1 -1
- package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript-cursor/.claude-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/lisa-wiki-agy/plugin.json +1 -1
- package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/src/base/rules/reference/tracked-work.md +19 -0
package/package.json
CHANGED
|
@@ -164,7 +164,7 @@
|
|
|
164
164
|
"zod-validation-error": "^4.0.0"
|
|
165
165
|
},
|
|
166
166
|
"name": "@codyswann/lisa",
|
|
167
|
-
"version": "4.29.
|
|
167
|
+
"version": "4.29.7",
|
|
168
168
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
169
169
|
"main": "dist/index.js",
|
|
170
170
|
"exports": {
|
|
@@ -312,7 +312,7 @@
|
|
|
312
312
|
"test": "tests"
|
|
313
313
|
},
|
|
314
314
|
"types": "./dist/index.d.ts",
|
|
315
|
-
"lisaReleaseCommit": "
|
|
316
|
-
"gitHead": "
|
|
317
|
-
"lisaReleaseTag": "v4.29.
|
|
315
|
+
"lisaReleaseCommit": "10f016142fd9171827d0201d2365c75cce05dcfa",
|
|
316
|
+
"gitHead": "10f016142fd9171827d0201d2365c75cce05dcfa",
|
|
317
|
+
"lisaReleaseTag": "v4.29.7"
|
|
318
318
|
}
|
|
@@ -15,6 +15,25 @@ Use `lisa-track` as the single entry point:
|
|
|
15
15
|
|
|
16
16
|
The sequence is strict: **live validate/create -> claim -> link -> durable work**. A tracker answer of no, and any claim or binding failure, blocks the work. A tracker that cannot be reached — `gh` absent, or its credential refused — does not block a commit: the offline checks still run, the skip is loud on stderr, and the required `Work-Item Traceability` check re-runs the live checks with credentials before anything merges. Any other tracker failure still blocks. Tool presence or stale session text is not access.
|
|
17
17
|
|
|
18
|
+
## A pull request that carries several work items
|
|
19
|
+
|
|
20
|
+
One work item per pull request is the default and is what almost every branch
|
|
21
|
+
should do. It is not, however, a rule the commits can express on their own: an
|
|
22
|
+
integration or stacking branch that gathers several finished items before one
|
|
23
|
+
pull request has no edit to any commit that makes its range name a single item.
|
|
24
|
+
|
|
25
|
+
So the rule lives on the pull-request BODY, which is where an author can say
|
|
26
|
+
what a pull request is about and a reviewer can check it. The body must declare
|
|
27
|
+
EXACTLY the set of work items its commits carry — one `Work-Item:` line per
|
|
28
|
+
item. An item the commits carry and the body omits is refused; an item the body
|
|
29
|
+
declares and no commit carries is refused too, so padding the declaration is not
|
|
30
|
+
a way out. Every declared item is still proved live, open, repo-scoped, a leaf,
|
|
31
|
+
and (under `workItem.verify: "full"`) separately backlinked.
|
|
32
|
+
|
|
33
|
+
Batching is likewise a property of the push rather than of a branch: `git push`
|
|
34
|
+
carrying several ref updates validates each pushed ref on its own, exactly as if
|
|
35
|
+
each branch had been pushed alone.
|
|
36
|
+
|
|
18
37
|
## One canonical identity
|
|
19
38
|
|
|
20
39
|
The binding is authoritative for the worktree. Branches, commits, pull requests, usage accounting, evidence, and tracker-sync operations all carry the same canonical ref. Branch names are helpful discovery metadata but are not authoritative. After branch creation, `node scripts/lisa-work-item.mjs attach-branch` may attach the local branch to the binding.
|
|
@@ -15,6 +15,25 @@ Use `lisa-track` as the single entry point:
|
|
|
15
15
|
|
|
16
16
|
The sequence is strict: **live validate/create -> claim -> link -> durable work**. A tracker answer of no, and any claim or binding failure, blocks the work. A tracker that cannot be reached — `gh` absent, or its credential refused — does not block a commit: the offline checks still run, the skip is loud on stderr, and the required `Work-Item Traceability` check re-runs the live checks with credentials before anything merges. Any other tracker failure still blocks. Tool presence or stale session text is not access.
|
|
17
17
|
|
|
18
|
+
## A pull request that carries several work items
|
|
19
|
+
|
|
20
|
+
One work item per pull request is the default and is what almost every branch
|
|
21
|
+
should do. It is not, however, a rule the commits can express on their own: an
|
|
22
|
+
integration or stacking branch that gathers several finished items before one
|
|
23
|
+
pull request has no edit to any commit that makes its range name a single item.
|
|
24
|
+
|
|
25
|
+
So the rule lives on the pull-request BODY, which is where an author can say
|
|
26
|
+
what a pull request is about and a reviewer can check it. The body must declare
|
|
27
|
+
EXACTLY the set of work items its commits carry — one `Work-Item:` line per
|
|
28
|
+
item. An item the commits carry and the body omits is refused; an item the body
|
|
29
|
+
declares and no commit carries is refused too, so padding the declaration is not
|
|
30
|
+
a way out. Every declared item is still proved live, open, repo-scoped, a leaf,
|
|
31
|
+
and (under `workItem.verify: "full"`) separately backlinked.
|
|
32
|
+
|
|
33
|
+
Batching is likewise a property of the push rather than of a branch: `git push`
|
|
34
|
+
carrying several ref updates validates each pushed ref on its own, exactly as if
|
|
35
|
+
each branch had been pushed alone.
|
|
36
|
+
|
|
18
37
|
## One canonical identity
|
|
19
38
|
|
|
20
39
|
The binding is authoritative for the worktree. Branches, commits, pull requests, usage accounting, evidence, and tracker-sync operations all carry the same canonical ref. Branch names are helpful discovery metadata but are not authoritative. After branch creation, `node scripts/lisa-work-item.mjs attach-branch` may attach the local branch to the binding.
|
|
@@ -20,6 +20,25 @@ Use `lisa-track` as the single entry point:
|
|
|
20
20
|
|
|
21
21
|
The sequence is strict: **live validate/create -> claim -> link -> durable work**. A tracker answer of no, and any claim or binding failure, blocks the work. A tracker that cannot be reached — `gh` absent, or its credential refused — does not block a commit: the offline checks still run, the skip is loud on stderr, and the required `Work-Item Traceability` check re-runs the live checks with credentials before anything merges. Any other tracker failure still blocks. Tool presence or stale session text is not access.
|
|
22
22
|
|
|
23
|
+
## A pull request that carries several work items
|
|
24
|
+
|
|
25
|
+
One work item per pull request is the default and is what almost every branch
|
|
26
|
+
should do. It is not, however, a rule the commits can express on their own: an
|
|
27
|
+
integration or stacking branch that gathers several finished items before one
|
|
28
|
+
pull request has no edit to any commit that makes its range name a single item.
|
|
29
|
+
|
|
30
|
+
So the rule lives on the pull-request BODY, which is where an author can say
|
|
31
|
+
what a pull request is about and a reviewer can check it. The body must declare
|
|
32
|
+
EXACTLY the set of work items its commits carry — one `Work-Item:` line per
|
|
33
|
+
item. An item the commits carry and the body omits is refused; an item the body
|
|
34
|
+
declares and no commit carries is refused too, so padding the declaration is not
|
|
35
|
+
a way out. Every declared item is still proved live, open, repo-scoped, a leaf,
|
|
36
|
+
and (under `workItem.verify: "full"`) separately backlinked.
|
|
37
|
+
|
|
38
|
+
Batching is likewise a property of the push rather than of a branch: `git push`
|
|
39
|
+
carrying several ref updates validates each pushed ref on its own, exactly as if
|
|
40
|
+
each branch had been pushed alone.
|
|
41
|
+
|
|
23
42
|
## One canonical identity
|
|
24
43
|
|
|
25
44
|
The binding is authoritative for the worktree. Branches, commits, pull requests, usage accounting, evidence, and tracker-sync operations all carry the same canonical ref. Branch names are helpful discovery metadata but are not authoritative. After branch creation, `node scripts/lisa-work-item.mjs attach-branch` may attach the local branch to the binding.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "4.29.
|
|
3
|
+
"version": "4.29.7",
|
|
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": "4.29.
|
|
3
|
+
"version": "4.29.7",
|
|
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"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "4.29.
|
|
3
|
+
"version": "4.29.7",
|
|
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": "4.29.
|
|
3
|
+
"version": "4.29.7",
|
|
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": "4.29.
|
|
3
|
+
"version": "4.29.7",
|
|
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"
|
|
@@ -15,6 +15,25 @@ Use `lisa-track` as the single entry point:
|
|
|
15
15
|
|
|
16
16
|
The sequence is strict: **live validate/create -> claim -> link -> durable work**. A tracker answer of no, and any claim or binding failure, blocks the work. A tracker that cannot be reached — `gh` absent, or its credential refused — does not block a commit: the offline checks still run, the skip is loud on stderr, and the required `Work-Item Traceability` check re-runs the live checks with credentials before anything merges. Any other tracker failure still blocks. Tool presence or stale session text is not access.
|
|
17
17
|
|
|
18
|
+
## A pull request that carries several work items
|
|
19
|
+
|
|
20
|
+
One work item per pull request is the default and is what almost every branch
|
|
21
|
+
should do. It is not, however, a rule the commits can express on their own: an
|
|
22
|
+
integration or stacking branch that gathers several finished items before one
|
|
23
|
+
pull request has no edit to any commit that makes its range name a single item.
|
|
24
|
+
|
|
25
|
+
So the rule lives on the pull-request BODY, which is where an author can say
|
|
26
|
+
what a pull request is about and a reviewer can check it. The body must declare
|
|
27
|
+
EXACTLY the set of work items its commits carry — one `Work-Item:` line per
|
|
28
|
+
item. An item the commits carry and the body omits is refused; an item the body
|
|
29
|
+
declares and no commit carries is refused too, so padding the declaration is not
|
|
30
|
+
a way out. Every declared item is still proved live, open, repo-scoped, a leaf,
|
|
31
|
+
and (under `workItem.verify: "full"`) separately backlinked.
|
|
32
|
+
|
|
33
|
+
Batching is likewise a property of the push rather than of a branch: `git push`
|
|
34
|
+
carrying several ref updates validates each pushed ref on its own, exactly as if
|
|
35
|
+
each branch had been pushed alone.
|
|
36
|
+
|
|
18
37
|
## One canonical identity
|
|
19
38
|
|
|
20
39
|
The binding is authoritative for the worktree. Branches, commits, pull requests, usage accounting, evidence, and tracker-sync operations all carry the same canonical ref. Branch names are helpful discovery metadata but are not authoritative. After branch creation, `node scripts/lisa-work-item.mjs attach-branch` may attach the local branch to the binding.
|