@codyswann/lisa 4.53.7 → 4.54.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/dist/core/nightly-e2e-guard-behavior-certificate.js +2 -2
- package/dist/core/reusable-workflow-pin.d.ts +28 -0
- package/dist/core/reusable-workflow-pin.d.ts.map +1 -1
- package/dist/core/reusable-workflow-pin.js +49 -0
- package/dist/core/reusable-workflow-pin.js.map +1 -1
- package/dist/core/upstream-evidence-manifest.d.ts.map +1 -1
- package/dist/core/upstream-evidence-manifest.js +6 -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/.codex-plugin/skills/lisa-drive-pr-to-merge/SKILL.md +39 -1
- package/plugins/lisa/.codex-plugin/skills/lisa-linear-write-issue/SKILL.md +8 -0
- package/plugins/lisa/.codex-plugin/skills/lisa-repair-intake/SKILL.md +22 -0
- package/plugins/lisa/skills/lisa-drive-pr-to-merge/SKILL.md +39 -1
- package/plugins/lisa/skills/lisa-linear-write-issue/SKILL.md +8 -0
- package/plugins/lisa/skills/lisa-repair-intake/SKILL.md +22 -0
- package/plugins/lisa-agy/plugin.json +1 -1
- package/plugins/lisa-agy/skills/lisa-drive-pr-to-merge/SKILL.md +39 -1
- package/plugins/lisa-agy/skills/lisa-linear-write-issue/SKILL.md +8 -0
- package/plugins/lisa-agy/skills/lisa-repair-intake/SKILL.md +22 -0
- 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/skills/lisa-drive-pr-to-merge/SKILL.md +39 -1
- package/plugins/lisa-copilot/skills/lisa-linear-write-issue/SKILL.md +8 -0
- package/plugins/lisa-copilot/skills/lisa-repair-intake/SKILL.md +22 -0
- package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cursor/skills/lisa-drive-pr-to-merge/SKILL.md +39 -1
- package/plugins/lisa-cursor/skills/lisa-linear-write-issue/SKILL.md +8 -0
- package/plugins/lisa-cursor/skills/lisa-repair-intake/SKILL.md +22 -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/skills/lisa-drive-pr-to-merge/SKILL.md +39 -1
- package/plugins/src/base/skills/lisa-linear-write-issue/SKILL.md +8 -0
- package/plugins/src/base/skills/lisa-repair-intake/SKILL.md +22 -0
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "4.
|
|
3
|
+
"version": "4.54.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": "4.
|
|
3
|
+
"version": "4.54.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"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "4.
|
|
3
|
+
"version": "4.54.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": "4.
|
|
3
|
+
"version": "4.54.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": "4.
|
|
3
|
+
"version": "4.54.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"
|
|
@@ -931,11 +931,49 @@ proxy for the other, so read them separately:
|
|
|
931
931
|
wedged looking abandoned.
|
|
932
932
|
|
|
933
933
|
Never dismiss on `reviewDecision` alone. Dismiss the stale (often bot) review
|
|
934
|
-
where repo policy permits
|
|
934
|
+
where repo policy permits:
|
|
935
935
|
```bash
|
|
936
936
|
gh api -X PUT repos/<owner>/<repo>/pulls/<pr>/reviews/<review_id>/dismissals \
|
|
937
937
|
-f message="Addressed; threads resolved." -f event=DISMISS
|
|
938
938
|
```
|
|
939
|
+
|
|
940
|
+
**When you cannot dismiss, re-requesting is NOT the automatic fallback.** This
|
|
941
|
+
file already forbids re-requesting to refresh a review, in as many words, and
|
|
942
|
+
that prohibition applies here too — the fallback used to contradict it, and an
|
|
943
|
+
agent reaching it was told to do the thing the same file calls one-way
|
|
944
|
+
destruction (CodySwannGT/lisa#3587).
|
|
945
|
+
|
|
946
|
+
Read the reviews before deciding, because the read is cheap and settles it:
|
|
947
|
+
|
|
948
|
+
```bash
|
|
949
|
+
gh api "repos/<owner>/<repo>/pulls/<pr>/reviews" \
|
|
950
|
+
--jq '[.[] | {author: .user.login, state: .state, hasBody: (((.body // "") | length) > 0)}]'
|
|
951
|
+
```
|
|
952
|
+
|
|
953
|
+
- **A human reviewer** — re-request freely. Re-requesting a person's review is
|
|
954
|
+
unremarkable and loses nothing.
|
|
955
|
+
- **A bot reviewer whose review is NOT the only substantive one** — re-request.
|
|
956
|
+
Something else still evidences that this head was read.
|
|
957
|
+
- **A bot reviewer whose review IS the only substantive one on the PR** — do
|
|
958
|
+
NOT re-request. **Escalate for a dismissal decision instead.** Under a
|
|
959
|
+
throttle or a spending cap the bot answers a new request with a status
|
|
960
|
+
carrying no review body, that hollow answer becomes its latest review, and
|
|
961
|
+
every effective-review computation — including the "latest non-dismissed
|
|
962
|
+
review per reviewer" rule immediately below — then reads the hollow one. The
|
|
963
|
+
substantive review is still retrievable from the reviews API; what is lost is
|
|
964
|
+
its standing as the reviewer's current review, which is the thing the merge
|
|
965
|
+
standard reads.
|
|
966
|
+
|
|
967
|
+
Deleting the fallback outright would over-correct: it is the only remedy a lane
|
|
968
|
+
without dismissal permission has, and that permission is not universal. This
|
|
969
|
+
narrows it to the case that costs nothing.
|
|
970
|
+
|
|
971
|
+
**Unverified, and stated as such rather than asserted:** that a bot's re-review
|
|
972
|
+
REPLACES its predecessor in the effective set is inferred from the observed
|
|
973
|
+
consequence, not measured against the vendor. It has not been tested here, and
|
|
974
|
+
testing it means re-requesting on a live pull request. The guidance is worth
|
|
975
|
+
following either way — the escalation costs one human decision, and the failure
|
|
976
|
+
it avoids is one-way.
|
|
939
977
|
Some org rulesets allow 0 approvals yet a bot `CHANGES_REQUESTED` still blocks
|
|
940
978
|
auto-merge — dismissing the stale review after resolving all threads is what
|
|
941
979
|
unblocks it.
|
|
@@ -229,6 +229,14 @@ For each candidate, classify the relationship:
|
|
|
229
229
|
|
|
230
230
|
Linear native relations are set on the Issue via `save_issue`'s `relations` field (or via a paired `save_issue_relation` call if available in the MCP). For Project-level (Epic) relationships, capture them in the description under `## Related Projects` since Linear doesn't model relations between Projects natively.
|
|
231
231
|
|
|
232
|
+
**Adding a relation to an already-linked pair may be a REPLACE, not an add.** Reported measured twice against the raw `issueRelationCreate` mutation: creating a `blocks` edge between two issues already carrying a `related` edge converted that edge in place — the source issue's outgoing relation count did not grow (CodySwannGT/lisa#3605). Relationship discovery is mandatory on the UPDATE path as well as creation, so this skill's own contract routinely points it at pairs that already have edges.
|
|
233
|
+
|
|
234
|
+
So on an update, read the pair's existing relations before writing one. Where an edge already exists and differs in type, surface it and let a human decide rather than writing over it — **an inherited relation is not a verified one**, and rewriting it silently removes the only moment anyone would check what it meant.
|
|
235
|
+
|
|
236
|
+
**The true undo is delete plus re-create with the original type.** A single delete removes the link entirely and does not restore what was there before, so any runbook recording "undo = delete relation X" has written down a plan that loses the prior relationship.
|
|
237
|
+
|
|
238
|
+
**Marked UNVERIFIED.** The observations were against the raw mutation; whether the MCP's `relations` field diffs before writing has not been tested, and testing it means writing a relation to a live workspace. Note that this does not make Lisa safe by default: `lisa-linear-access` resolves `LINEAR_API_KEY` + raw GraphQL as **tier 1, ahead of the MCP**, so the normal autonomous path is the one the observations were made against.
|
|
239
|
+
|
|
232
240
|
### 4c. Remote Links
|
|
233
241
|
|
|
234
242
|
Identify and attach (Linear stores attachments / links on the Issue or in description body):
|
|
@@ -352,6 +352,28 @@ a PR that cannot merge or a deploy that failed — it just churns.
|
|
|
352
352
|
ticket, and record it. The existing "Build `blocked` → unblock if cleared" path resumes this item on
|
|
353
353
|
a later cycle once the fix ticket is terminal — a self-healing loop. Skip the resume steps below.
|
|
354
354
|
|
|
355
|
+
**On Linear, READ the pair's existing relations before writing that link.** Reported measured
|
|
356
|
+
twice: `issueRelationCreate` on a pair that already carries a `related` edge appears to CONVERT
|
|
357
|
+
that edge rather than add a second one — the outgoing count did not grow — and the undo is not
|
|
358
|
+
what it looks like, because deleting the new relation removes the link entirely instead of
|
|
359
|
+
restoring the original. Full reversal is delete **plus re-create with the original type**
|
|
360
|
+
(CodySwannGT/lisa#3605).
|
|
361
|
+
|
|
362
|
+
So: fetch the pair's relations first. If any edge already exists between the two items, do
|
|
363
|
+
**not** write — record the item under the run's escalations naming the existing edge and its
|
|
364
|
+
type, and leave both alone. A fix ticket freshly filed by this same pass has no prior edge by
|
|
365
|
+
construction, which is the ordinary case and stays a single write.
|
|
366
|
+
|
|
367
|
+
This matters here more than anywhere else Lisa writes a relation: this pass runs unattended on a
|
|
368
|
+
schedule, and `max_candidates` defaults to 100, so a converting write is not one lost edge but
|
|
369
|
+
up to a hundred — none of them logged, because nothing read the prior state.
|
|
370
|
+
|
|
371
|
+
**Marked UNVERIFIED, deliberately.** The conversion was observed against the raw GraphQL
|
|
372
|
+
mutation, and confirming it on Lisa's own path means writing a relation to a live Linear
|
|
373
|
+
workspace. That has not been done and must not be done to close this. The read costs one call
|
|
374
|
+
and is correct whether or not the semantics are what they appear to be — which is the whole
|
|
375
|
+
reason it is safe to adopt without settling the question.
|
|
376
|
+
|
|
355
377
|
If the PR is healthy in-flight and no blocker is found, the work simply died mid-flight — run the **same per-item sequence
|
|
356
378
|
the vendor build-intake runs**, skipping the claim transition (the item is already `claimed`):
|
|
357
379
|
|