@codyswann/lisa 3.33.5 → 3.33.7

package/expo/copy-overwrite/scripts/bdd/baseline.mjs

@@ -38,6 +38,9 @@ import { parseFeatureSource, scenarioIdsIn } from "./parse.mjs";
 
 const defect = (code, message) => ({ code, message });
 
+/** Defect / evidence code, named once. */
+const SCENARIO_DELETED = "scenario-deleted";
+
 /** The maintainer-applied PR label that authorizes giving coverage back. */
 export const BASELINE_LABEL = "bdd-floor-baseline";
 
@@ -247,10 +250,14 @@ export function obligationKeys(scenarios, contract) {
 
 /**
  * Every `SCENARIO:platform` a waiver removes from the denominator.
+ *
+ * Exported because `bdd-matrix.mjs` calls it too. It was calling it WITHOUT an
+ * import — a live ReferenceError on every matrix render, invisible because this
+ * whole tree sat outside the ESLint config until #2658 put it back in.
  * @param {object|null} contract - A coverage map.
  * @returns {Set<string>} Waived keys.
  */
-function waivedKeys(contract) {
+export function waivedKeys(contract) {
   return new Set(
     (contract?.platformWaivers ?? []).flatMap(waiver =>
       (waiver.platforms ?? []).map(platform => `${waiver.scenario}:${platform}`)
@@ -420,19 +427,19 @@ function deletionDefects(id, record, labels) {
   if (!record) {
     return [
       defect(
-        "scenario-deleted",
+        SCENARIO_DELETED,
         `${id} was deleted from the contract. Retiring a behavior is @superseded, not deletion — deleting it shrinks the denominator instead of the gap. A genuine removal needs a retirements record and the "${BASELINE_LABEL}" label.`
       ),
     ];
   }
   const missing = RETIREMENT_FIELDS.filter(field => !record[field]);
   const defects = missing.map(field =>
-    defect("scenario-deleted", `${id}: retirements record has no ${field}`)
+    defect(SCENARIO_DELETED, `${id}: retirements record has no ${field}`)
   );
   if (!labels.includes(BASELINE_LABEL)) {
     defects.push(
       defect(
-        "scenario-deleted",
+        SCENARIO_DELETED,
         `${id}: a retirement needs the maintainer-applied "${BASELINE_LABEL}" label`
       )
     );

package/expo/copy-overwrite/scripts/bdd/discover.mjs

@@ -69,6 +69,12 @@ export function isUnderPrefix(relative, prefix) {
  */
 const defect = (code, message, subject) => ({ code, message, subject });
 
+/** Defect / evidence code, named once. */
+const CALL_TITLE = "call-title";
+
+/** Defect / evidence code, named once. */
+const EXCLUSION_STALE = "exclusion-stale";
+
 /**
  * The evidence grammars a project may choose from, as SOURCE CONSTANTS.
  *
@@ -78,7 +84,7 @@ const defect = (code, message, subject) => ({ code, message, subject });
  * (`test("...")`, `it.skip('...')`); `line-field` reads a leading document
  * field (`name: ...`), which is how flow-style runners title a file.
  */
-export const EVIDENCE_KINDS = Object.freeze(["call-title", "line-field"]);
+export const EVIDENCE_KINDS = Object.freeze([CALL_TITLE, "line-field"]);
 
 /** A JavaScript identifier, the only shape a declared function name may take. */
 const IDENTIFIER = /^[A-Za-z_$][A-Za-z0-9_$]*$/;
@@ -176,7 +182,7 @@ function evidenceProblems(evidence) {
       `evidence.kind ${JSON.stringify(evidence.kind)} is not one of ${EVIDENCE_KINDS.join(", ")}`,
     ];
   }
-  if (evidence.kind === "call-title") {
+  if (evidence.kind === CALL_TITLE) {
     return isListOf(
       evidence.functions,
       entry => typeof entry === "string" && IDENTIFIER.test(entry)
@@ -316,7 +322,7 @@ function discoverRunner({ root, runner, config, contract }) {
  * @returns {{evidence: string|null, dynamic: boolean}[]} Discovered entries.
  */
 function extract(source, evidence) {
-  return evidence.kind === "call-title"
+  return evidence.kind === CALL_TITLE
     ? callTitles(source, evidence.functions)
     : lineField(source, evidence.field);
 }
@@ -485,7 +491,7 @@ function exclusionStale({ root, exclusion, discovery, at, subject }) {
   if (!resolved.path) {
     return [
       defect(
-        "exclusion-stale",
+        EXCLUSION_STALE,
         `${at}: ${exclusion.file} — ${resolved.error}; retire the exclusion or restore the file`,
         subject
       ),
@@ -494,7 +500,7 @@ function exclusionStale({ root, exclusion, discovery, at, subject }) {
   if (!discovery.roots.some(entry => isUnderPrefix(exclusion.file, entry))) {
     return [
       defect(
-        "exclusion-stale",
+        EXCLUSION_STALE,
         `${at}: ${exclusion.file} is covered by no configured discovery root (${discovery.roots.map(entry => entry || ".").join(", ") || "none declared"}), so the exclusion suppresses nothing`,
         subject
       ),
@@ -504,7 +510,7 @@ function exclusionStale({ root, exclusion, discovery, at, subject }) {
     ? []
     : [
         defect(
-          "exclusion-stale",
+          EXCLUSION_STALE,
           `${at}: no discovered test in ${exclusion.file} matches ${JSON.stringify(exclusion.evidence)}`,
           subject
         ),

package/expo/copy-overwrite/scripts/bdd/waivers.mjs

@@ -24,6 +24,9 @@ const REQUIRED_FIELDS = [
   "expiresAt",
 ];
 
+/** Defect / evidence code, named once. */
+const WAIVER_METADATA = "waiver-metadata";
+
 /** ISO calendar date, the only accepted date shape. */
 export const ISO_DATE = /^\d{4}-\d{2}-\d{2}$/;
 
@@ -48,7 +51,7 @@ export function validateWaivers({ scenarios, contract, today }) {
     ? []
     : [
         defect(
-          "waiver-metadata",
+          WAIVER_METADATA,
           `the evaluation date ${JSON.stringify(today ?? null)} is not an ISO date (YYYY-MM-DD), so no waiver expiry could be evaluated. Set BDD_TODAY to a calendar date or leave it unset.`
         ),
       ];
@@ -118,13 +121,13 @@ function blockingError(waiver, scenario, at) {
  */
 function metadataDefects(waiver, at, today) {
   const defects = REQUIRED_FIELDS.filter(field => !waiver[field]).map(field =>
-    defect("waiver-metadata", `${at}: has no ${field}`)
+    defect(WAIVER_METADATA, `${at}: has no ${field}`)
   );
   for (const field of ["recordedAt", "expiresAt"]) {
     if (waiver[field] && !ISO_DATE.test(waiver[field])) {
       defects.push(
         defect(
-          "waiver-metadata",
+          WAIVER_METADATA,
           `${at}: ${field} must be an ISO date (YYYY-MM-DD)`
         )
       );
@@ -136,7 +139,7 @@ function metadataDefects(waiver, at, today) {
   ) {
     defects.push(
       defect(
-        "waiver-metadata",
+        WAIVER_METADATA,
         `${at}: ticket ${waiver.ticket} is not a valid tracker reference`
       )
     );

package/expo/copy-overwrite/scripts/bdd-matrix.mjs

@@ -23,6 +23,7 @@ import * as fs from "node:fs";
 import * as path from "node:path";
 import { fileURLToPath } from "node:url";
 
+import { waivedKeys } from "./bdd/baseline.mjs";
 import { byCodeUnit, declaredPlatforms, trackerUrl } from "./bdd/contract.mjs";
 import { loadScenarios } from "./bdd/parse.mjs";
 import { indexResults } from "./bdd/report.mjs";

package/expo/copy-overwrite/scripts/check-bdd-coverage.mjs

@@ -90,6 +90,18 @@ const PACKAGE_ROOT = path.resolve(
 const MAP_REL = "bdd/coverage-map.json";
 const defect = (code, message) => ({ code, message });
 
+/** Defect / mode code, named once. */
+const NOT_ADOPTED = "not-adopted";
+
+/** Defect / mode code, named once. */
+const BOOTSTRAP_METADATA = "bootstrap-metadata";
+
+/** Defect / mode code, named once. */
+const EXECUTION_RESULTS = "execution-results";
+
+/** Defect / mode code, named once. */
+const EMPTY_CONTRACT = "empty-contract";
+
 /**
  * Resolve the adoption state from the environment.
  * @param {Record<string, string|undefined>} env - Process environment.
@@ -97,10 +109,10 @@ const defect = (code, message) => ({ code, message });
  */
 export function resolveMode(env) {
   const raw = (env.BDD_MODE ?? "").trim();
-  if (raw === "") return { mode: "not-adopted", error: null };
+  if (raw === "") return { mode: NOT_ADOPTED, error: null };
   if (!ADOPTION_STATES.includes(raw)) {
     return {
-      mode: "not-adopted",
+      mode: NOT_ADOPTED,
       error: `BDD_MODE="${raw}" is not one of ${ADOPTION_STATES.join(", ")}`,
     };
   }
@@ -188,7 +200,7 @@ function bootstrapDefects(adoption, today) {
     // would make the time-box unreachable and bootstrap permanent.
     defects.push(
       defect(
-        "bootstrap-metadata",
+        BOOTSTRAP_METADATA,
         `the evaluation date ${JSON.stringify(today ?? null)} is not an ISO date (YYYY-MM-DD), so the bootstrap expiry could not be evaluated`
       )
     );
@@ -196,7 +208,7 @@ function bootstrapDefects(adoption, today) {
   if (!adoption.owner) {
     defects.push(
       defect(
-        "bootstrap-metadata",
+        BOOTSTRAP_METADATA,
         "bootstrap requires adoption.owner (a named person, not a team)"
       )
     );
@@ -204,14 +216,14 @@ function bootstrapDefects(adoption, today) {
   if (!adoption.expiresAt) {
     defects.push(
       defect(
-        "bootstrap-metadata",
+        BOOTSTRAP_METADATA,
         "bootstrap requires adoption.expiresAt (an ISO date); a bootstrap with no time-box never ends"
       )
     );
   } else if (!ISO_DATE.test(adoption.expiresAt)) {
     defects.push(
       defect(
-        "bootstrap-metadata",
+        BOOTSTRAP_METADATA,
         "adoption.expiresAt must be an ISO date (YYYY-MM-DD)"
       )
     );
@@ -239,7 +251,7 @@ export function loadExecutionResults(root, files) {
     const resolved = path.resolve(root, file);
     if (!fs.existsSync(resolved)) {
       defects.push(
-        defect("execution-results", `execution results not found: ${file}`)
+        defect(EXECUTION_RESULTS, `execution results not found: ${file}`)
       );
       continue;
     }
@@ -248,17 +260,14 @@ export function loadExecutionResults(root, files) {
       for (const run of Array.isArray(parsed) ? parsed : [parsed]) {
         if (!run.runner) {
           defects.push(
-            defect(
-              "execution-results",
-              `${file}: each run must name its runner`
-            )
+            defect(EXECUTION_RESULTS, `${file}: each run must name its runner`)
           );
           continue;
         }
         runs.push(run);
       }
     } catch (error) {
-      defects.push(defect("execution-results", `${file}: ${error.message}`));
+      defects.push(defect(EXECUTION_RESULTS, `${file}: ${error.message}`));
     }
   }
   return { runs, defects };
@@ -372,7 +381,7 @@ function enforcedDefects({ contract, scenarios, report, discovery }) {
   if (scenarios.length === 0) {
     defects.push(
       defect(
-        "empty-contract",
+        EMPTY_CONTRACT,
         "enforced mode: bdd/features declares zero scenarios"
       )
     );
@@ -380,7 +389,7 @@ function enforcedDefects({ contract, scenarios, report, discovery }) {
   if ((contract.mappings ?? []).length === 0) {
     defects.push(
       defect(
-        "empty-contract",
+        EMPTY_CONTRACT,
         "enforced mode: bdd/coverage-map.json declares zero test mappings"
       )
     );
@@ -388,7 +397,7 @@ function enforcedDefects({ contract, scenarios, report, discovery }) {
   if (Object.keys(contract.runnerPlatforms ?? {}).length === 0) {
     defects.push(
       defect(
-        "empty-contract",
+        EMPTY_CONTRACT,
         "enforced mode: bdd/coverage-map.json declares no runnerPlatforms"
       )
     );
@@ -494,7 +503,7 @@ export function run(root, options) {
  */
 function configFatals(loaded, mode) {
   if (loaded.error) return defect("config-malformed", loaded.error);
-  if (loaded.present || mode === "not-adopted") return null;
+  if (loaded.present || mode === NOT_ADOPTED) return null;
   return defect(
     "config-absent",
     `${mode} mode requires ${MAP_REL}, which does not exist. In ${mode} mode absence is a failure, never a skip.`
@@ -562,7 +571,7 @@ function result({ mode, defects, report, contract }) {
 function statusFor({ mode, defects, fatal, report }) {
   if (defects.some(item => INVALID_CODES.includes(item.code))) return "invalid";
   if (fatal) return "failed";
-  if (mode === "not-adopted" && !report) return "not-adopted";
+  if (mode === NOT_ADOPTED && !report) return NOT_ADOPTED;
   return "completed";
 }
 

package/expo/copy-overwrite/scripts/check-e2e-coverage.mjs

@@ -596,21 +596,24 @@ function main() {
   ]) {
     if (collected.skipped.length > 0) {
       console.log(
-        `[e2e-coverage] ${runner}: ${collected.skipped.length} file(s) excluded from the run and NOT counted as coverage:\n` +
-          collected.skipped.map(file => `  - ${file}`).join("\n")
+        `[e2e-coverage] ${runner}: ${collected.skipped.length} file(s) excluded from the run and NOT counted as coverage:\n${collected.skipped
+          .map(file => `  - ${file}`)
+          .join("\n")}`
       );
     }
   }
   if (exempt.length > 0) {
     console.log(
-      `[e2e-coverage] ${exempt.length} route(s) deliberately exempt (removed from the denominator):\n` +
-        exempt.map(route => `  - ${route}`).join("\n")
+      `[e2e-coverage] ${exempt.length} route(s) deliberately exempt (removed from the denominator):\n${exempt
+        .map(route => `  - ${route}`)
+        .join("\n")}`
     );
   }
   if (unknown.length > 0) {
     console.error(
-      `[e2e-coverage] FAIL: ${unknown.length} exemption(s) name a route that does not exist. A waiver that outlived its screen permanently excuses whatever replaces it:\n` +
-        unknown.map(route => `  - ${route}`).join("\n")
+      `[e2e-coverage] FAIL: ${unknown.length} exemption(s) name a route that does not exist. A waiver that outlived its screen permanently excuses whatever replaces it:\n${unknown
+        .map(route => `  - ${route}`)
+        .join("\n")}`
     );
     process.exit(1);
     return;
@@ -641,8 +644,9 @@ function main() {
     } else {
       console.error(`[e2e-coverage] ${runner}: FAIL — ${summary}`);
       console.error(
-        `[e2e-coverage] ${runner}: screens with no e2e test yet:\n` +
-          verdict.missing.map(route => `  - ${route}`).join("\n")
+        `[e2e-coverage] ${runner}: screens with no e2e test yet:\n${verdict.missing
+          .map(route => `  - ${route}`)
+          .join("\n")}`
       );
     }
   }

package/package.json

@@ -131,7 +131,7 @@
     "ws": ">=8.21.0"
   },
   "name": "@codyswann/lisa",
-  "version": "3.33.5",
+  "version": "3.33.7",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

package/plugins/lisa/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "3.33.5",
+  "version": "3.33.7",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "3.33.5",
+  "version": "3.33.7",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/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/lisa/.codex-plugin/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/lisa/.codex-plugin/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/lisa/.codex-plugin/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/lisa/.codex-plugin/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/lisa/.codex-plugin/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/plugins/lisa/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/lisa/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/lisa/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/lisa/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/lisa/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/lisa/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/plugins/lisa-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "3.33.5",
+  "version": "3.33.7",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"