@codyswann/lisa 3.33.6 → 3.33.8

package/plugins/src/base/skills/lisa-git-submit-pr/SKILL.md

@@ -66,10 +66,17 @@ When updating an existing PR, preserve any existing linkage line unless the new
 After creating or updating the PR, always make the reverse link durable on the source work item when `work_item_ref` is available:
 
 1. Resolve the live PR URL with `gh pr view <pr-number> --json url --jq .url`.
-2. Invoke `lisa-tracker-sync` with the original work item ref, milestone `pr-ready`, `pr_url=<url>`, and `tracker_provider=<provider>` when known.
-3. The vendor sync skill must prefer the provider's native development-link primitive where one is available and verifiable.
-4. If native linkage is unavailable, unconfigured, or cannot be verified, the vendor sync skill must create or update a single managed `[lisa-pr-link]` comment on the work item containing the PR URL. The fallback comment is not optional; it is the ticket-side half of the two-way link.
-5. When the PR later merges, invoke `lisa-tracker-sync` again with milestone `pr-merged`, the same `pr_url`, and the merge SHA when available, so the managed backlink reflects the final state.
+2. Run the backlink command. It is the executable form of this requirement — it writes the managed `[lisa-pr-link]` comment on the work item, or updates the one already there, for every tracker Lisa supports:
+
+   ```bash
+   node scripts/lisa-work-item.mjs backlink --ref <work_item_ref> --pr-url <url>
+   ```
+
+   It is idempotent, so run it on every push rather than deciding whether it is needed. It refuses loudly for a tracker it cannot write, and never silently no-ops. Do not hand-post the comment, and do not describe the posting procedure anywhere: the same file that writes it is the file that checks it, which is what keeps producer and consumer from drifting.
+3. Invoke `lisa-tracker-sync` with the original work item ref, milestone `pr-ready`, `pr_url=<url>`, and `tracker_provider=<provider>` when known. That is the progress-note and status side; it is not what satisfies the traceability check.
+4. When the PR later merges, invoke `lisa-tracker-sync` again with milestone `pr-merged`, the same `pr_url`, and the merge SHA when available.
+
+**Why step 2 exists — do not "simplify" it away as redundant with the `Refs` line.** Under the non-closing rule above, GitHub never creates a native development link at all: that surface *is* the closing-reference mechanism, so no non-closing form can populate it. A PR carrying a perfectly correct `Refs` line still fails the required Work-Item Traceability check without the comment. The managed comment is the ticket-side half of the link, not a fallback for when native linkage happens to be absent.
 
 Do not report PR submission as fully synced while the PR body references the ticket but the ticket has neither a verified native PR link nor the managed backlink comment.
 

package/plugins/src/base/skills/lisa-github-sync/SKILL.md

@@ -57,8 +57,13 @@ Optional arguments include `pr_url=<url>` for the live pull request and `merge_s
 When `$ARGUMENTS` includes `pr_url=<url>` for `PR ready` or `PR merged`, ensure the GitHub Issue has a durable ticket -> PR link:
 
 1. Make sure the PR body contains `Refs #<n>` (or the fully qualified cross-repo form) — never a closing keyword, per the GitHub rule in `lisa-git-submit-pr`. Read the issue side with `gh api graphql` against `issue.timelineItems`, or `gh issue view <number> --json closedByPullRequestsReferences`. **Not** `gh issue view --json timelineItems`: `timelineItems` is not a supported field for that command, so the check silently returns nothing useful rather than failing loudly.
-2. Post or update a single managed issue comment starting with `[lisa-pr-link]`. Include the PR URL, milestone (`pr-ready` or `pr-merged`), and merge SHA when available. This is **unconditional**, not contingent on step 1 failing: under the non-closing rule GitHub never creates a native development link (that surface is the closing-reference mechanism), so this comment is the only ticket-side backlink there will be.
-3. Keep the fallback idempotent: search existing comments for `[lisa-pr-link]` and the PR URL; update/replace that managed comment where the provider allows updates, otherwise skip when the current body already matches. Do not append duplicate backlink comments on reruns.
+2. Establish the managed backlink comment by running the command that owns it — never by hand, and never by describing the procedure here:
+
+   ```bash
+   node scripts/lisa-work-item.mjs backlink --ref <work-item> --pr-url <url>
+   ```
+
+   It creates the `[lisa-pr-link]` comment or updates the one already present, instead of appending duplicates, so it is safe to run on every milestone. This is **unconditional**, not contingent on step 1 failing: under the non-closing rule GitHub never creates a native development link (that surface is the closing-reference mechanism), so this comment is the only ticket-side backlink there will be — run it whether or not native linkage exists or cannot be verified, because the required Work-Item Traceability check reads this comment and nothing else guarantees one. The comment carries the marker and the PR URL only; the milestone (`pr-ready` / `pr-merged`) and merge SHA belong in the milestone progress note, so that a rerun at a new milestone still converges on one backlink comment.
 
 Native GitHub linkage cannot be verified under the non-closing rule because it is never created in the first place, so the managed comment is not a contingency here — it is the mechanism. The issue must show the PR from at least one ticket-side surface, and this is the only one available.
 

package/plugins/src/base/skills/lisa-implement/SKILL.md

@@ -341,7 +341,7 @@ Before shutting down the team, execute the Verify flow:
 5. Commit ALL outstanding changes in logical batches on the branch (minus sensitive data/information) — not just changes made by the agent team. This includes pre-existing uncommitted changes that were on the branch before the plan started. Do NOT filter commits to only "task-related" files. If it shows up in git status, it gets committed (unless it contains secrets).
 6. Push the changes - if any pre-push hook blocks you, create a task for the agent team to fix the error/problem whether it was pre-existing or not
 7. Open a pull request with auto-merge on via `lisa-git-submit-pr`, targeting the **base branch resolved from the ticket's environment** (`target_branch=<base>`, per the branch step above), and including the mandatory work-item ref so the PR can be linked natively to the source issue.
-7a. Confirm two-way linkage before treating PR submission as complete: the PR body/title/branch must reference the work item, and the work item must have either a verified native PR link or a single managed `[lisa-pr-link]` fallback comment from `lisa-tracker-sync`.
+7a. Confirm two-way linkage before treating PR submission as complete: the PR body/title/branch must reference the work item, and the work item must have either a verified native PR link or the single managed `[lisa-pr-link]` comment. Establish that comment with `node scripts/lisa-work-item.mjs backlink --ref <work_item_ref> --pr-url <url>` rather than posting it by hand — it is idempotent, and it is the same file that enforces the check, so producer and consumer cannot drift.
 8. PR Watch Loop: Drive the PR to merge via the `drive-pr-to-merge` skill — the single source of truth for clearing every blocker (auto-merge with direct-merge fallback, `BEHIND` re-sync, conflict resolution, failing-check fixes, human + bot review-comment handling with thread resolution, stale `CHANGES_REQUESTED` dismissal, and post-merge ancestry verification). `git-submit-pr` already invokes it; if you reach this step with a PR already open, invoke `drive-pr-to-merge` directly with the PR number. For a large review backlog you may fan the code-fix work out to the agent team, but `drive-pr-to-merge` owns the loop and the terminal conditions — do not re-implement them.
 9. Merge the PR, then refresh the ticket-side backlink with `lisa-tracker-sync <work_item_ref> pr-merged pr_url=<url> merge_sha=<sha> tracker_provider=<provider>`.
 10. Monitor the deploy action that triggers automatically from the successful merge

package/plugins/src/base/skills/lisa-jira-sync/SKILL.md

@@ -55,8 +55,13 @@ Before adding a comment, check for an existing milestone comment to avoid duplic
 When `$ARGUMENTS` includes `pr_url=<url>` for `PR ready` or `PR merged`, ensure the JIRA ticket has a durable ticket -> PR link:
 
 1. Prefer the JIRA development-link surface when the site's GitHub/JIRA integration or remote-link API is available through `lisa-atlassian-access`; verify by re-reading the ticket's remote links / development metadata.
-2. If native linkage is unavailable, unconfigured, cross-system, or cannot be verified, create or update a single managed JIRA comment containing the PR URL. The comment must start with `[lisa-pr-link]` and include the milestone (`pr-ready` or `pr-merged`) and merge SHA when available.
-3. Keep the fallback idempotent: read existing comments, find the `[lisa-pr-link]` comment for the same PR URL, and update/skip it instead of appending duplicates. If the current access layer cannot update comments in place, skip when an identical managed comment already exists and otherwise add exactly one replacement comment with the stable marker.
+2. Establish the managed backlink comment by running the command that owns it — never by hand, and never by describing the procedure here:
+
+   ```bash
+   node scripts/lisa-work-item.mjs backlink --ref <work-item> --pr-url <url>
+   ```
+
+   It creates the `[lisa-pr-link]` comment or updates the one already present, instead of appending duplicates, so it is safe to run on every milestone. This is **unconditional** — run it whether or not native linkage exists or cannot be verified, because the required Work-Item Traceability check reads this comment and nothing else guarantees one. The comment carries the marker and the PR URL only; the milestone (`pr-ready` / `pr-merged`) and merge SHA belong in the milestone progress note, so that a rerun at a new milestone still converges on one backlink comment.
 
 The PR body/branch issue key is the PR -> ticket side. This step is the required ticket -> PR side.
 

package/plugins/src/base/skills/lisa-linear-sync/SKILL.md

@@ -72,8 +72,13 @@ Call `lisa-linear-access operation: save-comment({issueId: <id>, body: <comment>
 When `$ARGUMENTS` includes `pr_url=<url>` for `pr-ready` or `pr-merged`, ensure the Linear Issue has a durable ticket -> PR link:
 
 1. Prefer Linear's native GitHub attachment / pull request link when the integration has attached the PR through the branch name, PR title, or PR body issue identifier. Verify by re-reading the Issue and its attachments / relations where the Linear access layer exposes them.
-2. If native linkage is unavailable, unconfigured, cross-system, or cannot be verified, create or update a single managed Linear comment containing the PR URL. The comment must start with `[lisa-pr-link]` and include the milestone (`pr-ready` or `pr-merged`) and merge SHA when available.
-3. Keep the fallback idempotent: read existing comments where the access layer exposes them, find the `[lisa-pr-link]` comment for the same PR URL, and update/skip it instead of appending duplicates. If comment update is unavailable, skip when an identical managed comment already exists and otherwise add exactly one replacement comment with the stable marker.
+2. Establish the managed backlink comment by running the command that owns it — never by hand, and never by describing the procedure here:
+
+   ```bash
+   node scripts/lisa-work-item.mjs backlink --ref <work-item> --pr-url <url>
+   ```
+
+   It creates the `[lisa-pr-link]` comment or updates the one already present, instead of appending duplicates, so it is safe to run on every milestone. This is **unconditional** — run it whether or not native linkage exists or cannot be verified, because the required Work-Item Traceability check reads this comment and nothing else guarantees one. The comment carries the marker and the PR URL only; the milestone (`pr-ready` / `pr-merged`) and merge SHA belong in the milestone progress note, so that a rerun at a new milestone still converges on one backlink comment.
 
 The PR branch/title/body identifier is the PR -> Linear side. This phase is the required Linear -> PR side.
 

package/plugins/src/base/skills/lisa-tracker-sync/SKILL.md

@@ -52,8 +52,13 @@ When `$ARGUMENTS` includes `pr_url=<url>` with milestone `pr-ready` or `pr-merge
 
 1. Prefer the provider's native development-link primitive when Lisa can write and verify it for that provider.
 2. Verify the native link using the provider read surface when available.
-3. If the native link is unavailable, unconfigured, cross-system, or cannot be verified, create or update one managed backlink comment on the work item containing the PR URL and current milestone.
-4. Keep the comment idempotent by using a stable marker such as `[lisa-pr-link]`; reruns update or skip the existing managed comment rather than appending duplicates.
+3. Whether or not the native link exists or cannot be verified, establish the managed backlink comment with the one command that owns it:
+
+   ```bash
+   node scripts/lisa-work-item.mjs backlink --ref <work-item> --pr-url <url>
+   ```
+
+4. That command is idempotent by construction — it updates the existing `[lisa-pr-link]` comment rather than appending duplicates — and it refuses loudly for a tracker it cannot write. Do not restate its procedure in a vendor skill; the file that writes the comment is the file that checks it, and that is what stops the two from drifting.
 
 This is the reverse half of `lisa-git-submit-pr`'s PR body linkage. A PR that mentions a ticket is not considered fully synced until the ticket also has either a verified native PR link or the managed fallback comment.
 

package/typescript/copy-contents/.husky/pre-push

@@ -11,7 +11,74 @@ if ! command -v node >/dev/null 2>&1; then
   echo "❌ Push blocked: Node.js is required to validate tracker work items."
   exit 1
 fi
-node "$WORK_ITEM_SCRIPT" validate-push "${1:-origin}" || exit 1
+# ---------------------------------------------------------------------------
+# Work-item traceability, at the push moment.
+#
+# This call used to be unconditional, and it was the last check in either hook
+# that ran outside the gate facade: `gates.traceability` could say `off` and it
+# still ran, could say `required` and nothing changed. That is the defect #2680
+# measured in CI, one moment earlier. The declaration decides now, and this is
+# the FALLBACK:
+#
+#   declared at push, at any level  -> the registry owns the property. The gate
+#                                      runner below runs what the project
+#                                      declared, and this step stands down.
+#   not declared, or the registry
+#   cannot be read at all           -> this runs, exactly as it always has. A
+#                                      project that has declared nothing loses
+#                                      no protection whatsoever.
+#
+# `off` needs no third branch, for the same reason it needed none in CI: an off
+# declaration is still a declaration, the runner records it as covered, and the
+# built-in step stands down having correctly done nothing. What is refused is
+# the shape where this step runs and its exit code is discarded — a check that
+# reports green having proved nothing is the defect the facade exists to remove.
+#
+# WHY THE DECISION IS RESOLVED HERE rather than read from the coverage file the
+# other built-in steps consult. This step must run BEFORE the GIT_* set is
+# unset below, and before anything else reads the hook's stdin, because Git
+# feeds the refs being pushed in on stdin and that is what the validator parses.
+# No coverage file exists this early, so the declaration is resolved directly.
+# That makes deferring only half a decision; the other half is further down,
+# where this runs after all if the registry never actually proved it.
+# ---------------------------------------------------------------------------
+GATE_REGISTRY=""
+for LISA_GATE_REGISTRY_CANDIDATE in \
+  "node_modules/@codyswann/lisa/all/copy-overwrite/scripts/lisa-gates.mjs" \
+  "scripts/lisa-gates.mjs" \
+  "all/copy-overwrite/scripts/lisa-gates.mjs"
+do
+  if [ -f "$LISA_GATE_REGISTRY_CANDIDATE" ]; then
+    GATE_REGISTRY="$LISA_GATE_REGISTRY_CANDIDATE"
+    break
+  fi
+done
+unset LISA_GATE_REGISTRY_CANDIDATE
+
+# Nothing here discards stderr. A resolver that failed and a project that
+# declared nothing produce the same empty answer, and both send this hook to the
+# built-in step — which is the safe direction — but only one of them is a
+# problem somebody needs to see.
+TRACEABILITY_DECLARED=""
+if [ -n "$GATE_REGISTRY" ]; then
+  TRACEABILITY_DECLARED=$(node "$GATE_REGISTRY" list --moment=push --json --include-off | node -e '
+let raw = "";
+process.stdin.on("data", chunk => { raw += chunk }).on("end", () => {
+  try {
+    const declared = JSON.parse(raw || "[]").some(gate => gate.id === "traceability");
+    process.stdout.write(declared ? "declared" : "");
+  } catch (error) {
+    process.stderr.write(`\u26a0\ufe0f  Could not read the gate registry: ${error.message}\n`);
+  }
+});
+')
+fi
+
+if [ "$TRACEABILITY_DECLARED" = "declared" ]; then
+  echo "ℹ️  gates.traceability is declared at push; the gate registry decides what runs."
+else
+  node "$WORK_ITEM_SCRIPT" validate-push "${1:-origin}" || exit 1
+fi
 
 # Git supplies repository-local GIT_* variables to hooks. Keep them for push
 # validation above, then remove exactly Git's documented local set so nested
@@ -117,6 +184,26 @@ lisa_gate_covers() {
 # BEGIN: built-in checks — the pre-registry path, kept step for step so a
 # project without a `gates` block behaves exactly as it did before.
 
+# Work-item traceability, when the registry took the property and then proved
+# nothing with it — no runner on disk, a runner that could not run, a coverage
+# file that could not be written. Each of those means nothing was proved, and a
+# declared gate must never be a quieter way of turning a check off than
+# declaring it `off`.
+#
+# A late run is not identical to the early one: the repository-local GIT_*
+# variables are gone by here, and a declared gate that read stdin has already
+# consumed the pushed refs. `validate-push` survives both — with empty stdin it
+# falls back to `git rev-list HEAD --not --remotes=<remote>` — which is what
+# makes a degraded run worth having, and why the early position stays the
+# normal one.
+if lisa_gate_covers traceability; then
+  echo "ℹ️  Covered by the traceability gate; the built-in work-item validation stands down."
+elif [ "$TRACEABILITY_DECLARED" = "declared" ]; then
+  echo "⚠️  gates.traceability is declared at push, but the gate registry proved nothing here."
+  echo "   Running the built-in work-item validation so the property is not lost."
+  node "$WORK_ITEM_SCRIPT" validate-push "${1:-origin}" || exit 1
+fi
+
 # Run the whole-project type check once before code leaves the machine. It is
 # intentionally not a pre-commit gate because TypeScript cannot check only the
 # staged files and rebuilding the full program makes small commits too slow.