@codyswann/lisa 4.26.2 → 4.26.4

package/plugins/lisa-copilot/rules/eager/leaf-only-lifecycle.md

@@ -49,6 +49,22 @@ When a leaf reaches the true terminal `done` (the production / final-env value),
 
 Intermediate env-keyed states (`status:on-dev`, `On Stg`, etc.) remain open. Idempotent — if already closed, report and continue.
 
+### Exactly one lifecycle role survives closure
+
+The terminal transition retires **every** other lifecycle role the item carries, not only the one it was last known to hold. Resolve the complete configured set — `ready`, `claimed`, `review` where bound, `blocked`, and every env-keyed `done` value — and remove each one that is present, except the terminal role being applied. Type, component, priority, and provenance labels are untouched.
+
+Retiring only the claimed role assumes the item travelled the happy path, and items skip stages: one reaches completion straight from `ready` having never been claimed, another is unblocked and closed still carrying `blocked`. Measured on a live tracker: 34 closed issues carried an active lifecycle role, six of them carrying `ready` and the terminal role at once.
+
+**This is not cosmetic.** A queue scan filters on the synthesized role, not the native closed state, so a closed item still reading `ready` is handed back out — one already-shipped fix was independently rebuilt end to end before a push-time gate caught it.
+
+Three constraints on how it is done:
+
+- **Remove only roles the item actually carries.** Naming an absent label is a 404, which fails a clean closure and makes a repeat run fail where the first one succeeded.
+- **Verify by re-reading.** Confirm the final closed state and the unique terminal role from a **fresh read of the item**, never from the write's own response. A write that reports success is not evidence of the state it intended to produce — asserting otherwise is the same defect as the drift being repaired, one layer up.
+- **Never re-complete an abandoned item.** Applying a terminal `done` role to an item someone already closed as not-planned rewrites their decision that the work would not be done, and afterwards the two are indistinguishable. Refuse and say so. This does not restrict the duplicate closeout below, which is a flow deliberately closing an open item as not-planned rather than overwriting a closure that already exists.
+
+Trackers with a native lifecycle field (JIRA, Linear) get exclusivity for free: the field that closes the item is the field a queue scan filters on, so the two cannot disagree. GitHub Issues has no lifecycle beyond open/closed, so Lisa synthesizes one in labels and inherits a reconciliation duty the others do not have. That asymmetry is tracked separately in `CodySwannGT/lisa#3479`; this section is the obligation, not the redesign.
+
 Duplicate closeout is a narrow terminal exception: build intake may close a claimed item without a PR only when `ticket-triage` returns `DUPLICATE_ALREADY_FIXED` with a canonical item reference and empirical base-branch proof. Close it through provider duplicate semantics, not as completed build work. `BLOCKED`, ambiguous, duplicate-of-open, and other human-owned dispositions are not auto-closed.
 
 Full vendor mechanics + the state machine in prose: [reference/leaf-only-lifecycle.md](../reference/leaf-only-lifecycle.md).

package/plugins/lisa-copilot/skills/lisa-github-build-intake/SKILL.md

@@ -431,14 +431,26 @@ Run this only when the returned triage verdict is exactly `DUPLICATE_ALREADY_FIX
 2. Post or preserve the triage-finding comment that explains why this issue is a duplicate and names the canonical issue.
 3. Ensure a native `duplicates <canonical>` link exists when GitHub exposes issue relationships; if this installation cannot create that relationship, leave an explicit issue cross-reference comment/body link and record the limitation in the summary.
 4. Resolve terminal `$DONE` exactly as in Phase 3d. For a single-env repo, `$DONE` is terminal; for env-keyed config, only the production/final value is terminal.
-5. Replace `$CLAIMED` with `$DONE`, then close the issue as duplicate/not-planned:
+5. Apply `$DONE` and retire every competing lifecycle role the issue currently carries — not just `$CLAIMED` — per the `leaf-only-lifecycle` rule's "Exactly one lifecycle role survives closure". Then close the issue as duplicate/not-planned:
 
 ```bash
-gh issue edit <number> --repo <org>/<repo> --remove-label "$CLAIMED" --add-label "$DONE"
-gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Closed as duplicate of <canonical>. Canonical fix: <PR-or-commit>. Evidence: <base-branch-proof>."
+gh issue view <number> --repo <org>/<repo> --json labels -q '[.labels[].name] | join(" ")'
+gh issue edit <number> --repo <org>/<repo> --add-label "$DONE" <one --remove-label "<role>" per competing role the issue CURRENTLY carries>
 gh issue close <number> --repo <org>/<repo> --reason "not planned"
 ```
 
+6. **Confirm with an independent readback, and only then announce** — the same obligation as Phase 3d step 5, for the same reason. Re-read the issue instead of trusting what the edit and close reported:
+
+```bash
+gh issue view <number> --repo <org>/<repo> --json state,stateReason,labels
+```
+
+It must read `state: CLOSED` with `stateReason: NOT_PLANNED`, carry `$DONE`, and carry **no** other lifecycle role. Anything else is an Error naming what is still present. Post the closeout comment only after that passes:
+
+```bash
+gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Closed as duplicate of <canonical>. Canonical fix: <PR-or-commit>. Evidence: <base-branch-proof>."
+```
+
 If the canonical fix is merged but not yet present on the production branch, append the production-promotion caveat to the close comment: the production error can recur until the canonical issue promotes, and recurrence is tracked by the canonical issue rather than by reopening this duplicate.
 
 This path is distinct from `BLOCKED`: ambiguity, open blockers, and duplicate-of-open findings remain held for human action and must not be auto-closed.
@@ -475,11 +487,15 @@ If the lifecycle run returned Success:
    - If `github.labels.build.done` is an object, only the production/final environment value is terminal (default: `status:done`). Intermediate env values such as `status:on-dev` and `status:on-stg` are not terminal and must stay open.
    - If the project uses a different final environment name, resolve it from the configured deployment topology; if ambiguous, record an Error and do not close.
 
+4. **Retire every competing lifecycle role**, per the `leaf-only-lifecycle` rule's "Exactly one lifecycle role survives closure" — cite it, do not restate it. Read the issue's current labels, intersect them with the configured role set (`$READY`, `$CLAIMED`, `$BLOCKED`, `$REVIEW` where bound, and every env-keyed done value), and remove each one that is present except `$DONE`. Removing only `$CLAIMED` leaves a stale `$READY` on any item that reached completion without passing through the claimed lane, and a closed item still reading ready is re-dispatched by this very scanner on its next cycle.
+
 ```bash
-gh issue edit <number> --repo <org>/<repo> --remove-label "$CLAIMED" --add-label "$DONE"
-gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Build complete. PR <URL> merged. Transitioned to $DONE."
+gh issue view <number> --repo <org>/<repo> --json labels -q '[.labels[].name] | join(" ")'
+gh issue edit <number> --repo <org>/<repo> --add-label "$DONE" <one --remove-label "<role>" per competing role the issue CURRENTLY carries>
 ```
 
+Name only roles the read actually returned: `--remove-label` on a label the issue does not carry is a 404, which turns a clean transition into an error and makes a repeat cycle fail where the first succeeded.
+
 If `$DONE` is terminal, immediately close the native GitHub issue:
 
 ```bash
@@ -488,6 +504,24 @@ gh issue close <number> --repo <org>/<repo> --reason completed
 
 This close is idempotent: if the issue is already closed, record that native closure was already satisfied and continue. If `$DONE` is an intermediate env state, leave the issue open by design.
 
+5. **Confirm with an independent readback, and only then announce.** Re-read the issue rather than trusting what the edit and close commands reported about themselves:
+
+```bash
+gh issue view <number> --repo <org>/<repo> --json state,stateReason,labels
+```
+
+The item must carry `$DONE` and **no** other lifecycle role, and — when `$DONE` is terminal — read `state: CLOSED`. Anything else is recorded as an Error naming the roles still present; do not report the transition as applied on the strength of a write that said it worked.
+
+Post the completion comment **only after** that readback passes:
+
+```bash
+gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Build complete. PR <URL> merged. Transitioned to $DONE."
+```
+
+The ordering is the point. Announcing before verifying leaves a public "Build complete" on an item whose lifecycle state was never confirmed, and a reader has no way to tell that claim apart from a verified one — the same indistinguishability the readback exists to prevent. On a failed readback, comment the Error instead.
+
+`node scripts/lisa-work-item.mjs complete --ref <org>/<repo>#<number>` performs this whole terminal sequence — merged-PR evidence check, full role reconciliation, close, independent readback — in one step, and is the preferred path whenever `$DONE` is the terminal value. Use the manual commands above for intermediate env transitions, which must not close the issue.
+
 For any non-Success outcome, do NOT transition. The issue sits in `$CLAIMED` (or wherever the lifecycle left it) — humans take it from there.
 
 #### 3d.1 Roll up the parent chain (forward rollup)
@@ -541,7 +575,7 @@ Total PRs opened: <n>
 - **Claim-first ordering**: `$CLAIMED` set BEFORE the lifecycle dispatch for leaves; containers are also moved to `$CLAIMED` to leave the ready pickup queue, but are not dispatched.
 - **No writes outside the lifecycle**: this skill only relabels `$READY → $CLAIMED` and `$CLAIMED → $DONE`. For containers, `$READY → $CLAIMED` is a lifecycle repair, not a direct build claim. Every other label change is owned by the per-issue lifecycle (github-agent workflow).
 - **Duplicate terminal exception**: `DUPLICATE_ALREADY_FIXED` is the only triage outcome that may close a claimed item without a PR from this cycle. It must include a canonical issue reference and empirical base-branch evidence, and it closes as duplicate/not-planned rather than as completed build work.
-- **Terminal native closure**: after `$CLAIMED → $DONE`, close the GitHub issue only when `$DONE` is the true terminal done value per `leaf-only-lifecycle`; intermediate env labels stay open.
+- **Terminal native closure**: after applying `$DONE` and retiring every competing lifecycle role (`leaf-only-lifecycle`, "Exactly one lifecycle role survives closure"), close the GitHub issue only when `$DONE` is the true terminal done value per `leaf-only-lifecycle`; intermediate env labels stay open. Confirm the result with an independent readback, never with the write's own response.
 - **One item per cycle**: per-issue exceptions are caught and recorded, then the cycle exits. The scheduler owns retrying or moving on to the next ready item.
 - **Single cycle per repo**: do not run two `lisa-github-build-intake` cycles in parallel against the same repo — concurrent claims could race. The scheduling layer is responsible for serialization.
 - **Single-label invariant**: after every transition, verify exactly one `status:*` label is present on the issue. If two are present (rare race), surface as an Error and skip — do NOT auto-resolve.

package/plugins/lisa-copilot/skills/lisa-jira-journey/SKILL.md

@@ -37,8 +37,30 @@ python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
 
 The parser resolves Jira configuration from the checkout first: it searches
 `$CLAUDE_PROJECT_DIR/.lisa/jira-cli/.config.yml`, then the current directory and
-its parents, and only then falls back to `~/.config/.jira/.config.yml`. Do not
-copy project settings into the home-level file just to make this step work.
+its parents, and uses `~/.config/.jira/.config.yml` when no checkout config
+exists. Do not copy project settings into the home-level file just to make this
+step work.
+
+A checkout config is not automatically trusted. The first checkout candidate
+that exists is decisive — that is `$CLAUDE_PROJECT_DIR` when it is set, which
+outranks a config nearer the current directory, and only otherwise the nearest
+one walking up from the current directory. Its server must match the operator's
+trust root — `JIRA_SERVER` when set, otherwise the home config — and a mismatch
+fails naming that file rather than quietly using the home config instead, so the
+error points at the file that is actually wrong.
+
+`server` must be a bare HTTPS origin: `https://host`, optionally with a port and
+a single trailing slash. An explicit `:443` is accepted and canonicalized away,
+so `https://host:443` and `https://host` are the same origin and either may be
+configured. Userinfo (`https://user:token@…`), a query, a fragment, and any
+other path are refused rather than trimmed away. So are a hostname this parser
+cannot describe unambiguously — surrounding whitespace, control characters,
+percent-encoded or non-ASCII hostnames, a trailing dot, and port 0.
+The reason is that this value is both the trust key and the base every request
+is built from; normalizing a richer URL down to its origin would approve one
+value and then send the API token to a different one. Self-hosted context paths
+and internationalized hostnames are out of scope and would need their own
+base-path contract.
 
 The script outputs JSON with: `ticket`, `prerequisites`, `steps`, `viewports`, `assertions`.
 

package/plugins/lisa-copilot/skills/lisa-jira-journey/scripts/parse-plan.py

@@ -25,6 +25,7 @@ Output (JSON):
     }
 """
 
+import ipaddress
 import json
 import os
 import re
@@ -41,6 +42,24 @@ from urllib.parse import urlsplit
 # a capture obligation.
 LOCAL_EVIDENCE_PATTERN = re.compile(r'\[(SCREENSHOT|EVIDENCE):\s*([^\]]+)\]')
 
+# One ASCII DNS name: dot-separated labels of letters, digits and inner hyphens.
+# IPv4 literals are a subset of this form. Anything else -- percent-encoding, a
+# trailing dot, an empty label, a leading or trailing hyphen -- is refused,
+# because a hostname this pattern cannot describe is one whose meaning depends
+# on who resolves it.
+DNS_NAME_PATTERN = re.compile(
+    r'^[a-z0-9]([a-z0-9-]*[a-z0-9])?(\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)*$'
+)
+
+# The only two path spellings that mean "no path".
+ROOT_PATHS = ("", "/")
+
+DEFAULT_HTTPS_PORT = 443
+
+
+class JiraConfigError(Exception):
+    """A configured Jira server could not be established as trusted."""
+
 
 def jira_config_candidates():
     """Return project-first jira-cli config candidates without duplicates."""
@@ -80,63 +99,158 @@ def read_jira_config(config_path):
     return server, login
 
 
+def canonical_authority(netloc, hostname):
+    """Return the canonical authority for one host, or "" when it is not one."""
+    if netloc.startswith("["):
+        try:
+            return f"[{ipaddress.IPv6Address(hostname).compressed}]"
+        except ValueError:
+            return ""
+    return hostname if DNS_NAME_PATTERN.match(hostname) else ""
+
+
+def is_bare_origin(server, parsed):
+    """Report whether the raw value names an origin and nothing besides.
+
+    The query and fragment are checked against the raw string rather than the
+    parse, because ``https://host?`` and ``https://host`` parse to the same
+    empty query. A delimiter carrying nothing is still a component the operator
+    wrote and the trust key would discard.
+    """
+    if "?" in server or "#" in server:
+        return False
+    if parsed.scheme != "https" or "@" in parsed.netloc:
+        return False
+    return parsed.path in ROOT_PATHS
+
+
 def server_origin(server):
-    """Return the normalized HTTPS origin used as the credential trust key."""
+    """Return the canonical HTTPS origin, or "" when the value is not one.
+
+    This value is both the credential trust key and the base every request is
+    built from, so the two have to be the same string. A normalizer that reduced
+    an arbitrary URL to its origin would approve one value and send another:
+    userinfo, a query, a fragment, or a path would ride along into the request
+    while the trust check saw only the host, which is how an API token reaches a
+    URL that validation never approved. So the accepted grammar is a bare
+    origin -- ``https://host`` or ``https://host/`` with an optional non-default
+    port -- and every richer form is refused rather than trimmed down to fit.
+
+    Self-hosted context paths and internationalized hostnames are deliberately
+    out of scope: either needs its own base-path contract, and inventing one
+    here would re-open the gap between what is checked and what is sent.
+    """
+    if not server or any(char <= " " or char >= "\x7f" for char in server):
+        return ""
     try:
         parsed = urlsplit(server)
         port = parsed.port
     except ValueError:
         return ""
-    if parsed.scheme.lower() != "https" or not parsed.hostname:
+    if not parsed.hostname or port == 0:
+        return ""
+    if not is_bare_origin(server, parsed):
         return ""
-    if port == 0:
+    authority = canonical_authority(parsed.netloc, parsed.hostname)
+    if not authority:
         return ""
-    hostname = parsed.hostname.lower()
-    authority = f"[{hostname}]" if ":" in hostname else hostname
-    if port is not None and port != 443:
+    if port is not None and port != DEFAULT_HTTPS_PORT:
         authority = f"{authority}:{port}"
     return f"https://{authority}"
 
 
-def resolve_jira_config_path():
-    """Resolve a project config only when its host matches a user trust root."""
+def resolve_trusted_origin():
+    """Return the operator-owned origin a checkout config must match, or "".
+
+    An explicit JIRA_SERVER wins over the home config. A JIRA_SERVER that is not
+    a canonical origin raises rather than resolving to "": degrading a malformed
+    trust root into "no trust root" would silently widen what a checkout config
+    is allowed to claim, which is the opposite of what setting it asked for.
+    """
+    configured = os.environ.get("JIRA_SERVER", "")
+    if configured.strip():
+        origin = server_origin(configured)
+        if not origin:
+            raise JiraConfigError(
+                "JIRA_SERVER must be a valid HTTPS URL naming one origin, with "
+                "no userinfo, path, query or fragment"
+            )
+        return origin
+
+    home_config = (Path.home() / ".config" / ".jira" / ".config.yml").resolve()
+    if not home_config.exists():
+        return ""
+    return server_origin(read_jira_config(home_config)[0])
+
+
+def resolve_jira_config_path(trusted_origin=None):
+    """Select the jira-cli config that governs this checkout.
+
+    The nearest checkout-owned config is decisive. When one exists it must match
+    the operator's trust root, and a mismatch fails naming that file. Falling
+    through to the home config instead would report a missing or unusable home
+    config for a project config that was found and refused -- an error about the
+    wrong file, pointing whoever has to fix it away from the one that is wrong.
+
+    Args:
+        trusted_origin: The operator's trust root, resolved when not supplied.
+    """
     candidates = jira_config_candidates()
     home_config = candidates[-1]
-    trusted_server = os.environ.get("JIRA_SERVER", "").strip()
-    if not trusted_server and home_config.exists():
-        trusted_server, _ = read_jira_config(home_config)
-    trusted_origin = server_origin(trusted_server)
+    if trusted_origin is None:
+        trusted_origin = resolve_trusted_origin()
 
     for candidate in candidates[:-1]:
         if not candidate.exists():
             continue
-        candidate_server, _ = read_jira_config(candidate)
-        if trusted_origin and server_origin(candidate_server) == trusted_origin:
-            return candidate
+        if not trusted_origin:
+            raise JiraConfigError(
+                f"jira-cli config {candidate} cannot be trusted: neither "
+                "JIRA_SERVER nor a home config establishes a trust root"
+            )
+        if server_origin(read_jira_config(candidate)[0]) != trusted_origin:
+            raise JiraConfigError(
+                f"jira-cli config {candidate} server does not match the "
+                "trusted JIRA server origin"
+            )
+        return candidate
     return home_config
 
 
 def get_jira_config():
-    """Read JIRA server and login from the project-first jira-cli config."""
-    config_path = resolve_jira_config_path()
+    """Read JIRA server and login from the project-first jira-cli config.
+
+    Every exit below happens before the token is read, so a configured URL that
+    fails validation cannot reach a request. The returned server is the
+    canonical origin, never the configured string, which is what keeps the value
+    that was checked and the value that is sent identical.
+    """
+    try:
+        trusted_origin = resolve_trusted_origin()
+        config_path = resolve_jira_config_path(trusted_origin)
+    except JiraConfigError as error:
+        print(f"ERROR: {error}", file=sys.stderr)
+        sys.exit(1)
+
     if not config_path.exists():
         print(f"ERROR: jira-cli config not found at {config_path}", file=sys.stderr)
         sys.exit(1)
 
     server, login = read_jira_config(config_path)
-
-    trusted_server = os.environ.get("JIRA_SERVER", "").strip()
-    trusted_origin = server_origin(trusted_server)
-    if trusted_server and not trusted_origin:
-        print("ERROR: JIRA_SERVER must be a valid HTTPS URL", file=sys.stderr)
+    origin = server_origin(server)
+    if not origin:
+        print(
+            f"ERROR: JIRA server in {config_path} must be an HTTPS URL naming "
+            "one origin, with no userinfo, path, query or fragment",
+            file=sys.stderr,
+        )
         sys.exit(1)
-    if trusted_origin:
-        if server_origin(server) != trusted_origin:
-            print("ERROR: jira-cli config server does not match trusted JIRA_SERVER", file=sys.stderr)
-            sys.exit(1)
-        server = trusted_server.rstrip("/")
-    if not server_origin(server):
-        print("ERROR: JIRA server must be an HTTPS URL from a trusted config", file=sys.stderr)
+    if trusted_origin and origin != trusted_origin:
+        print(
+            f"ERROR: jira-cli config {config_path} server does not match the "
+            "trusted JIRA server origin",
+            file=sys.stderr,
+        )
         sys.exit(1)
 
     token = os.environ.get("JIRA_API_TOKEN", "")
@@ -144,7 +258,7 @@ def get_jira_config():
         print("ERROR: JIRA_API_TOKEN env var not set", file=sys.stderr)
         sys.exit(1)
 
-    return server, login, token
+    return origin, login, token
 
 
 def fetch_ticket(server, login, token, ticket_id):

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

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

package/plugins/lisa-cursor/rules/leaf-only-lifecycle.mdc

@@ -54,6 +54,22 @@ When a leaf reaches the true terminal `done` (the production / final-env value),
 
 Intermediate env-keyed states (`status:on-dev`, `On Stg`, etc.) remain open. Idempotent — if already closed, report and continue.
 
+### Exactly one lifecycle role survives closure
+
+The terminal transition retires **every** other lifecycle role the item carries, not only the one it was last known to hold. Resolve the complete configured set — `ready`, `claimed`, `review` where bound, `blocked`, and every env-keyed `done` value — and remove each one that is present, except the terminal role being applied. Type, component, priority, and provenance labels are untouched.
+
+Retiring only the claimed role assumes the item travelled the happy path, and items skip stages: one reaches completion straight from `ready` having never been claimed, another is unblocked and closed still carrying `blocked`. Measured on a live tracker: 34 closed issues carried an active lifecycle role, six of them carrying `ready` and the terminal role at once.
+
+**This is not cosmetic.** A queue scan filters on the synthesized role, not the native closed state, so a closed item still reading `ready` is handed back out — one already-shipped fix was independently rebuilt end to end before a push-time gate caught it.
+
+Three constraints on how it is done:
+
+- **Remove only roles the item actually carries.** Naming an absent label is a 404, which fails a clean closure and makes a repeat run fail where the first one succeeded.
+- **Verify by re-reading.** Confirm the final closed state and the unique terminal role from a **fresh read of the item**, never from the write's own response. A write that reports success is not evidence of the state it intended to produce — asserting otherwise is the same defect as the drift being repaired, one layer up.
+- **Never re-complete an abandoned item.** Applying a terminal `done` role to an item someone already closed as not-planned rewrites their decision that the work would not be done, and afterwards the two are indistinguishable. Refuse and say so. This does not restrict the duplicate closeout below, which is a flow deliberately closing an open item as not-planned rather than overwriting a closure that already exists.
+
+Trackers with a native lifecycle field (JIRA, Linear) get exclusivity for free: the field that closes the item is the field a queue scan filters on, so the two cannot disagree. GitHub Issues has no lifecycle beyond open/closed, so Lisa synthesizes one in labels and inherits a reconciliation duty the others do not have. That asymmetry is tracked separately in `CodySwannGT/lisa#3479`; this section is the obligation, not the redesign.
+
 Duplicate closeout is a narrow terminal exception: build intake may close a claimed item without a PR only when `ticket-triage` returns `DUPLICATE_ALREADY_FIXED` with a canonical item reference and empirical base-branch proof. Close it through provider duplicate semantics, not as completed build work. `BLOCKED`, ambiguous, duplicate-of-open, and other human-owned dispositions are not auto-closed.
 
 Full vendor mechanics + the state machine in prose: [reference/leaf-only-lifecycle.md](leaf-only-lifecycle-reference.mdc).

package/plugins/lisa-cursor/skills/lisa-github-build-intake/SKILL.md

@@ -431,14 +431,26 @@ Run this only when the returned triage verdict is exactly `DUPLICATE_ALREADY_FIX
 2. Post or preserve the triage-finding comment that explains why this issue is a duplicate and names the canonical issue.
 3. Ensure a native `duplicates <canonical>` link exists when GitHub exposes issue relationships; if this installation cannot create that relationship, leave an explicit issue cross-reference comment/body link and record the limitation in the summary.
 4. Resolve terminal `$DONE` exactly as in Phase 3d. For a single-env repo, `$DONE` is terminal; for env-keyed config, only the production/final value is terminal.
-5. Replace `$CLAIMED` with `$DONE`, then close the issue as duplicate/not-planned:
+5. Apply `$DONE` and retire every competing lifecycle role the issue currently carries — not just `$CLAIMED` — per the `leaf-only-lifecycle` rule's "Exactly one lifecycle role survives closure". Then close the issue as duplicate/not-planned:
 
 ```bash
-gh issue edit <number> --repo <org>/<repo> --remove-label "$CLAIMED" --add-label "$DONE"
-gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Closed as duplicate of <canonical>. Canonical fix: <PR-or-commit>. Evidence: <base-branch-proof>."
+gh issue view <number> --repo <org>/<repo> --json labels -q '[.labels[].name] | join(" ")'
+gh issue edit <number> --repo <org>/<repo> --add-label "$DONE" <one --remove-label "<role>" per competing role the issue CURRENTLY carries>
 gh issue close <number> --repo <org>/<repo> --reason "not planned"
 ```
 
+6. **Confirm with an independent readback, and only then announce** — the same obligation as Phase 3d step 5, for the same reason. Re-read the issue instead of trusting what the edit and close reported:
+
+```bash
+gh issue view <number> --repo <org>/<repo> --json state,stateReason,labels
+```
+
+It must read `state: CLOSED` with `stateReason: NOT_PLANNED`, carry `$DONE`, and carry **no** other lifecycle role. Anything else is an Error naming what is still present. Post the closeout comment only after that passes:
+
+```bash
+gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Closed as duplicate of <canonical>. Canonical fix: <PR-or-commit>. Evidence: <base-branch-proof>."
+```
+
 If the canonical fix is merged but not yet present on the production branch, append the production-promotion caveat to the close comment: the production error can recur until the canonical issue promotes, and recurrence is tracked by the canonical issue rather than by reopening this duplicate.
 
 This path is distinct from `BLOCKED`: ambiguity, open blockers, and duplicate-of-open findings remain held for human action and must not be auto-closed.
@@ -475,11 +487,15 @@ If the lifecycle run returned Success:
    - If `github.labels.build.done` is an object, only the production/final environment value is terminal (default: `status:done`). Intermediate env values such as `status:on-dev` and `status:on-stg` are not terminal and must stay open.
    - If the project uses a different final environment name, resolve it from the configured deployment topology; if ambiguous, record an Error and do not close.
 
+4. **Retire every competing lifecycle role**, per the `leaf-only-lifecycle` rule's "Exactly one lifecycle role survives closure" — cite it, do not restate it. Read the issue's current labels, intersect them with the configured role set (`$READY`, `$CLAIMED`, `$BLOCKED`, `$REVIEW` where bound, and every env-keyed done value), and remove each one that is present except `$DONE`. Removing only `$CLAIMED` leaves a stale `$READY` on any item that reached completion without passing through the claimed lane, and a closed item still reading ready is re-dispatched by this very scanner on its next cycle.
+
 ```bash
-gh issue edit <number> --repo <org>/<repo> --remove-label "$CLAIMED" --add-label "$DONE"
-gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Build complete. PR <URL> merged. Transitioned to $DONE."
+gh issue view <number> --repo <org>/<repo> --json labels -q '[.labels[].name] | join(" ")'
+gh issue edit <number> --repo <org>/<repo> --add-label "$DONE" <one --remove-label "<role>" per competing role the issue CURRENTLY carries>
 ```
 
+Name only roles the read actually returned: `--remove-label` on a label the issue does not carry is a 404, which turns a clean transition into an error and makes a repeat cycle fail where the first succeeded.
+
 If `$DONE` is terminal, immediately close the native GitHub issue:
 
 ```bash
@@ -488,6 +504,24 @@ gh issue close <number> --repo <org>/<repo> --reason completed
 
 This close is idempotent: if the issue is already closed, record that native closure was already satisfied and continue. If `$DONE` is an intermediate env state, leave the issue open by design.
 
+5. **Confirm with an independent readback, and only then announce.** Re-read the issue rather than trusting what the edit and close commands reported about themselves:
+
+```bash
+gh issue view <number> --repo <org>/<repo> --json state,stateReason,labels
+```
+
+The item must carry `$DONE` and **no** other lifecycle role, and — when `$DONE` is terminal — read `state: CLOSED`. Anything else is recorded as an Error naming the roles still present; do not report the transition as applied on the strength of a write that said it worked.
+
+Post the completion comment **only after** that readback passes:
+
+```bash
+gh issue comment <number> --repo <org>/<repo> --body "[claude-build-intake] Build complete. PR <URL> merged. Transitioned to $DONE."
+```
+
+The ordering is the point. Announcing before verifying leaves a public "Build complete" on an item whose lifecycle state was never confirmed, and a reader has no way to tell that claim apart from a verified one — the same indistinguishability the readback exists to prevent. On a failed readback, comment the Error instead.
+
+`node scripts/lisa-work-item.mjs complete --ref <org>/<repo>#<number>` performs this whole terminal sequence — merged-PR evidence check, full role reconciliation, close, independent readback — in one step, and is the preferred path whenever `$DONE` is the terminal value. Use the manual commands above for intermediate env transitions, which must not close the issue.
+
 For any non-Success outcome, do NOT transition. The issue sits in `$CLAIMED` (or wherever the lifecycle left it) — humans take it from there.
 
 #### 3d.1 Roll up the parent chain (forward rollup)
@@ -541,7 +575,7 @@ Total PRs opened: <n>
 - **Claim-first ordering**: `$CLAIMED` set BEFORE the lifecycle dispatch for leaves; containers are also moved to `$CLAIMED` to leave the ready pickup queue, but are not dispatched.
 - **No writes outside the lifecycle**: this skill only relabels `$READY → $CLAIMED` and `$CLAIMED → $DONE`. For containers, `$READY → $CLAIMED` is a lifecycle repair, not a direct build claim. Every other label change is owned by the per-issue lifecycle (github-agent workflow).
 - **Duplicate terminal exception**: `DUPLICATE_ALREADY_FIXED` is the only triage outcome that may close a claimed item without a PR from this cycle. It must include a canonical issue reference and empirical base-branch evidence, and it closes as duplicate/not-planned rather than as completed build work.
-- **Terminal native closure**: after `$CLAIMED → $DONE`, close the GitHub issue only when `$DONE` is the true terminal done value per `leaf-only-lifecycle`; intermediate env labels stay open.
+- **Terminal native closure**: after applying `$DONE` and retiring every competing lifecycle role (`leaf-only-lifecycle`, "Exactly one lifecycle role survives closure"), close the GitHub issue only when `$DONE` is the true terminal done value per `leaf-only-lifecycle`; intermediate env labels stay open. Confirm the result with an independent readback, never with the write's own response.
 - **One item per cycle**: per-issue exceptions are caught and recorded, then the cycle exits. The scheduler owns retrying or moving on to the next ready item.
 - **Single cycle per repo**: do not run two `lisa-github-build-intake` cycles in parallel against the same repo — concurrent claims could race. The scheduling layer is responsible for serialization.
 - **Single-label invariant**: after every transition, verify exactly one `status:*` label is present on the issue. If two are present (rare race), surface as an Error and skip — do NOT auto-resolve.

package/plugins/lisa-cursor/skills/lisa-jira-journey/SKILL.md

@@ -37,8 +37,30 @@ python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
 
 The parser resolves Jira configuration from the checkout first: it searches
 `$CLAUDE_PROJECT_DIR/.lisa/jira-cli/.config.yml`, then the current directory and
-its parents, and only then falls back to `~/.config/.jira/.config.yml`. Do not
-copy project settings into the home-level file just to make this step work.
+its parents, and uses `~/.config/.jira/.config.yml` when no checkout config
+exists. Do not copy project settings into the home-level file just to make this
+step work.
+
+A checkout config is not automatically trusted. The first checkout candidate
+that exists is decisive — that is `$CLAUDE_PROJECT_DIR` when it is set, which
+outranks a config nearer the current directory, and only otherwise the nearest
+one walking up from the current directory. Its server must match the operator's
+trust root — `JIRA_SERVER` when set, otherwise the home config — and a mismatch
+fails naming that file rather than quietly using the home config instead, so the
+error points at the file that is actually wrong.
+
+`server` must be a bare HTTPS origin: `https://host`, optionally with a port and
+a single trailing slash. An explicit `:443` is accepted and canonicalized away,
+so `https://host:443` and `https://host` are the same origin and either may be
+configured. Userinfo (`https://user:token@…`), a query, a fragment, and any
+other path are refused rather than trimmed away. So are a hostname this parser
+cannot describe unambiguously — surrounding whitespace, control characters,
+percent-encoded or non-ASCII hostnames, a trailing dot, and port 0.
+The reason is that this value is both the trust key and the base every request
+is built from; normalizing a richer URL down to its origin would approve one
+value and then send the API token to a different one. Self-hosted context paths
+and internationalized hostnames are out of scope and would need their own
+base-path contract.
 
 The script outputs JSON with: `ticket`, `prerequisites`, `steps`, `viewports`, `assertions`.