@codyswann/lisa 3.51.2 → 3.51.4

package/plugins/lisa-copilot/hooks/block-direct-issue-create.sh

@@ -123,6 +123,7 @@ fi
 # The build-ready role is read from config, never hard-coded: a project that
 # renamed its ready lane must still be able to satisfy the guard, and the
 # refusal has to name the token that project actually uses.
+default_ready_role="status:ready"
 case "$tracker" in
   github) ready_role="$(read_config_value '.github.labels.build.ready')" ;;
   jira) ready_role="$(read_config_value '.jira.workflow.ready')" ;;
@@ -130,7 +131,63 @@ case "$tracker" in
   *) ready_role="" ;;
 esac
 if [ -z "$ready_role" ]; then
-  ready_role="status:ready"
+  ready_role="$default_ready_role"
+fi
+
+# WHICH REPOSITORY'S VOCABULARY ANSWERS FOR THIS FILING
+#
+# The role above is the CALLING project's. For a same-repo filing that is the
+# right question. For a filing addressed at a DIFFERENT repository — which
+# Lisa ships a first-class, cron-driven path for in `lisa-persist-learning` —
+# it is the wrong repository's vocabulary, and the guard demanded a token the
+# target does not carry:
+#
+#   - a JIRA or Linear caller's ready role is a workflow STATE. Demanded as a
+#     `gh --label` on another repo it is unsatisfiable, because that label does
+#     not exist there and `gh` rejects an unknown one. Obeying the guard made
+#     the command fail, which is not the same thing as being refused.
+#   - a GitHub caller that renamed its ready lane demanded its own token of a
+#     repository that never had it.
+#   - a GitHub caller on the stock lane worked only because both repositories
+#     happened to choose the same string. That is a coincidence, not routing.
+#
+# The one escape that IS satisfiable cross-repo, `[lisa-human-gate]`, is a lie
+# about the item: it stamps a build-ready defect report as held for a human
+# product call, and the target's build queue scans the ready role and nothing
+# else. The report is filed and never picked up — precisely the incomplete
+# handoff this guard exists to prevent, committed one repository over.
+#
+# So the target's own role answers, resolved from CONFIG rather than the
+# network. A live `gh api repos/<o>/<r>/labels` lookup would be more general
+# and is the wrong trade for a PreToolUse hook: a network round-trip on every
+# intercepted command, and a new fail-open surface when it errors.
+own_org="$(read_config_value '.github.org')"
+own_name="$(read_config_value '.github.repo')"
+own_repo=""
+if [ -n "$own_org" ] && [ -n "$own_name" ]; then
+  own_repo="$own_org/$own_name"
+fi
+
+# `hardening.upstreamRepo` already names the upstream repository across Lisa's
+# filing skills; `hardening.upstreamReadyRole` is its sibling, so the guard
+# keeps its existing discipline — read the role from config, never hard-code it
+# — while reading it from the RIGHT repository's config.
+upstream_repo="$(read_config_value '.hardening.upstreamRepo')"
+if [ -z "$upstream_repo" ]; then
+  upstream_repo="CodySwannGT/lisa"
+fi
+upstream_ready_role="$(read_config_value '.hardening.upstreamReadyRole')"
+if [ -z "$upstream_ready_role" ]; then
+  upstream_ready_role="$default_ready_role"
+fi
+
+# A non-GitHub caller's ready role is a workflow STATE, so it is never the right
+# vocabulary for a GitHub target no matter what the target turns out to be. The
+# classifier needs to know that even when this project declares no repo of its
+# own to compare against.
+caller_is_github="0"
+if [ "$tracker" = "github" ]; then
+  caller_is_github="1"
 fi
 
 # Ambient-only override. Deliberately read here, from the hook process's own
@@ -139,6 +196,11 @@ ambient_override="${LISA_ALLOW_DIRECT_ISSUE_CREATE:-}"
 
 refuse() {
   local signature="$1"
+  local roles="$2"
+  local target="$3"
+  if [ -n "$target" ]; then
+    refuse_cross_repo "$signature" "$roles" "$target"
+  fi
   cat >&2 <<EOF
 BLOCKED: refusing \`$signature\` — this filing declares no readiness.
 
@@ -184,6 +246,61 @@ EOF
   exit 2
 }
 
+# The cross-repo refusal is a separate message, not a variable swapped into the
+# one above, because its REMEDIATION is different. The local filing flow writes
+# to this project's own tracker and structurally cannot reach another
+# repository, so naming it here would send the agent to a path that cannot do
+# the thing it was just refused for. Name the route that reaches the target,
+# and name the target's role rather than this project's.
+refuse_cross_repo() {
+  local signature="$1"
+  local roles="$2"
+  local target="$3"
+  cat >&2 <<EOF
+BLOCKED: refusing \`$signature\` — this filing declares no readiness.
+
+WHY: a work item filed without the build-ready role is an incomplete handoff.
+Build-intake scans the ready lane and nothing else, so nothing will ever pick
+it up: the write succeeds and the work still dies.
+
+THIS FILING IS ADDRESSED AT ANOTHER REPOSITORY: \`$target\`.
+That repository runs its own build queue off its own ready role, so this
+project's role does not answer for it — and this project's filing flow writes
+to this project's tracker, so it cannot reach the target at all.
+
+FILE IT THE SANCTIONED WAY:
+
+1. An upstream defect or hardening report — the highest-signal report there is,
+   because it is reproduced and attributed rather than guessed at. Use the
+   upstream filing path, which composes a redacted, public-safe body through an
+   allowlist projection instead of free-form prose:
+
+     bunx @codyswann/lisa file-upstream --input <filing-event>.json
+
+   \`lisa-persist-learning\` step 6 runs exactly this, headless, on a cron, and
+   files the result with explicit \`build_ready: true\` so the target's queue
+   picks it up.
+
+2. If you must run the CLI directly, the command has to carry the TARGET
+   repository's build-ready role — \`$roles\` — as the value of a \`--label\`
+   flag. Configure it as \`hardening.upstreamReadyRole\` when the target renamed
+   its lane.
+
+DO NOT reach for \`[lisa-human-gate]\` to get past this one. It still satisfies
+the guard — it is a real declaration — but on an upstream defect report it is a
+false one: it stamps the item as held for a human product call, and the
+target's build queue scans the ready role and nothing else. The report is filed
+and never picked up, which is the incomplete handoff this guard exists to
+prevent, committed one repository over. Use it only when a human product call
+is genuinely pending on the target.
+
+OPERATOR ESCAPE: a human can export \`LISA_ALLOW_DIRECT_ISSUE_CREATE=1\` in the
+environment before starting the session. It is deliberately not reachable by
+setting it inline on this command — an inline assignment is refused.
+EOF
+  exit 2
+}
+
 # The classifier is read into a variable with a top-level here-document rather
 # than piped straight in from inside `$( … )`. bash 3.2 — which is what macOS
 # still ships as /bin/bash, and therefore what this fleet's hooks run under —
@@ -202,6 +319,11 @@ import sys
 command = os.environ.get("LISA_GUARD_COMMAND", "")
 ready_role = os.environ.get("LISA_GUARD_READY_ROLE", "")
 ambient_override = os.environ.get("LISA_GUARD_AMBIENT_OVERRIDE", "")
+default_ready_role = os.environ.get("LISA_GUARD_DEFAULT_READY_ROLE", "")
+own_repo = os.environ.get("LISA_GUARD_OWN_REPO", "").strip().lower()
+upstream_repo = os.environ.get("LISA_GUARD_UPSTREAM_REPO", "").strip().lower()
+upstream_ready_role = os.environ.get("LISA_GUARD_UPSTREAM_READY_ROLE", "")
+caller_is_github = os.environ.get("LISA_GUARD_CALLER_IS_GITHUB", "") == "1"
 
 OVERRIDE_NAME = "LISA_ALLOW_DIRECT_ISSUE_CREATE"
 HUMAN_GATE_MARKER = "[lisa-human-gate]"
@@ -269,6 +391,14 @@ PAYLOAD_VALUE_FLAGS = {"-f", "-F", "--raw-field", "--field"}
 
 GITHUB_ISSUES_PATH = re.compile(r"repos/[^/\s]+/[^/\s]+/issues/?$")
 GITHUB_ISSUES_URL = re.compile(r"api\.github\.com/repos/[^/\s]+/[^/\s]+/issues")
+# The repository a creation is ADDRESSED at, which decides whose ready role
+# answers for it. `gh` accepts the flag before or after the subcommand and in
+# either spelling, and the REST paths carry the same pair positionally.
+REPO_FLAGS = {"--repo", "-R"}
+GITHUB_ISSUES_PATH_REPO = re.compile(r"repos/([^/\s]+)/([^/\s]+)/issues/?$")
+GITHUB_ISSUES_URL_REPO = re.compile(
+    r"api\.github\.com/repos/([^/\s]+)/([^/\s]+)/issues"
+)
 JIRA_ISSUE_URL = re.compile(r"atlassian\.net/rest/api/[^/\s]+/issue")
 GRAPHQL_CREATE = re.compile(r"createIssue|issueCreate")
 
@@ -655,20 +785,118 @@ def body_file_paths(args):
     return paths
 
 
-def declares_readiness(raw_args):
+def normalise_repo(value):
+    """A `--repo` value reduced to a comparable `owner/name`.
+
+    `gh` accepts `OWNER/REPO`, `HOST/OWNER/REPO`, and a full browser URL, and
+    GitHub itself is case-insensitive about both halves — so comparing the raw
+    token would call the same repository two different places depending on how
+    it was typed.
+
+    Args:
+        value: The raw token.
+
+    Returns:
+        A lowercased `owner/name`, or None when the token names no repository.
+    """
+    text = value.strip().strip("'\"")
+    if text.endswith(".git"):
+        text = text[: -len(".git")]
+    parts = [part for part in text.split("/") if part and not part.endswith(":")]
+    if len(parts) < 2:
+        return None
+    return ("%s/%s" % (parts[-2], parts[-1])).lower()
+
+
+def target_repository(args):
+    """The repository this creation is addressed at, when it names one.
+
+    Read only from positions that actually reach the created item: a flag
+    before the end-of-options marker, or the endpoint the write is posted to.
+    A `-f repo=o/r` payload field is data being SENT, not the address being
+    posted to, and `endpoint_tokens` already excludes it.
+
+    Args:
+        args: A creating command's arguments.
+
+    Returns:
+        A lowercased `owner/name`, or None when the calling project is the
+        target — which is the overwhelmingly common case and today's behaviour.
+    """
+    scoped = before_end_of_options(args)
+    for index, token in enumerate(scoped):
+        if token in REPO_FLAGS and index + 1 < len(scoped):
+            return normalise_repo(scoped[index + 1])
+        if "=" in token:
+            head, value = token.split("=", 1)
+            if head in REPO_FLAGS:
+                return normalise_repo(value)
+    for token in endpoint_tokens(scoped, GITHUB_ISSUES_PATH):
+        match = GITHUB_ISSUES_PATH_REPO.search(token)
+        if match:
+            return normalise_repo("%s/%s" % (match.group(1), match.group(2)))
+    for token in scoped:
+        match = GITHUB_ISSUES_URL_REPO.search(token)
+        if match:
+            return normalise_repo("%s/%s" % (match.group(1), match.group(2)))
+    return None
+
+
+def roles_for(target):
+    """Which ready-role tokens satisfy a creation addressed at `target`.
+
+    The guard demands a declaration either way; this decides only WHOSE
+    vocabulary the declaration is written in.
+
+    The indeterminate case is the last branch: a GitHub-tracked project that
+    declares no `github.org`/`github.repo` cannot be compared against a target,
+    so both roles are accepted rather than inventing a refusal. That is
+    permissive about which token, never about whether one is required.
+
+    Args:
+        target: The addressed repository, or None.
+
+    Returns:
+        A (roles, cross_repo_target) pair. The target is None when the calling
+        project is the one being written to.
+    """
+    if target is None or (own_repo and target == own_repo):
+        return [ready_role], None
+    if upstream_repo and target == upstream_repo:
+        role = upstream_ready_role
+    else:
+        # Another repository Lisa has no configuration for. Its lane is
+        # whatever GitHub's stock one is; the caller's token is categorically
+        # not it.
+        role = default_ready_role
+    if own_repo or not caller_is_github:
+        return [role], target
+    # Indeterminate, and the target is deliberately NOT reported. The refusal
+    # would otherwise say "this filing is addressed at another repository" and
+    # "this project's role does not answer for it" — the first unproven and the
+    # second flatly false, since this branch accepts the project's role. A
+    # message naming a token that does not work is the remediation pointing
+    # away from the fix, which is the defect being repaired here.
+    return [ready_role, role], None
+
+
+def declares_readiness(raw_args, roles):
     """Whether the create carries one of the two required declarations.
 
     Args:
         raw_args: The creating command's arguments.
+        roles: The build-ready role tokens that satisfy this filing.
 
     Returns:
-        True when the build-ready role or a human-gate marker is present.
+        True when a build-ready role or a human-gate marker is present.
     """
     args = before_end_of_options(raw_args)
-    if ready_role:
+    for role in roles:
+        if not role:
+            continue
         for raw in flag_values(args, LABEL_FLAGS):
             candidates = [part.strip().strip("'\"") for part in raw.split(",")]
-            if ready_role in candidates:
+            if role in candidates:
                 return True
     # The human-gate marker is matched anywhere, and that asymmetry is
     # deliberate: it is a marker with no other meaning, so its presence in the
@@ -746,7 +974,8 @@ def scan(text, depth):
         depth: Current nesting depth.
 
     Returns:
-        A refusal signature, or None when nothing creation-shaped was found.
+        A (signature, roles, cross_repo_target) triple, or None when nothing
+        creation-shaped was found.
     """
     try:
         stripped = strip_heredocs(text)
@@ -757,7 +986,11 @@ def scan(text, depth):
         # raises on the unbalanced quote. Two appended characters, no binary
         # required. "I could not parse it" must never mean "it is fine".
         if UNPARSEABLE_CREATION.search(text):
-            return "an unparseable command that reads as a tracker creation"
+            return (
+                "an unparseable command that reads as a tracker creation",
+                [ready_role],
+                None,
+            )
         return None
 
     for argv in segment(tokens):
@@ -774,9 +1007,10 @@ def scan(text, depth):
             # disqualifies the override rather than supplying it.
             if ambient_override and not inline_override:
                 continue
-            if declares_readiness(args):
+            roles, target = roles_for(target_repository(args))
+            if declares_readiness(args, roles):
                 continue
-            return signature
+            return signature, roles, target
 
         for operand in nested_operands(argv):
             if depth >= MAX_NESTING_DEPTH:
@@ -784,7 +1018,11 @@ def scan(text, depth):
                 # made a creation inside a 4th `bash -c` layer pass, which is
                 # the depth cap being used as the bypass.
                 if UNPARSEABLE_CREATION.search(operand):
-                    return "a tracker creation nested past the inspection depth"
+                    return (
+                        "a tracker creation nested past the inspection depth",
+                        [ready_role],
+                        None,
+                    )
                 continue
             nested = scan(operand, depth + 1)
             if nested is not None:
@@ -802,7 +1040,14 @@ inline_override = (OVERRIDE_NAME + "=") in command
 
 found = scan(command, 0)
 if found is not None:
-    print("REFUSE %s" % found)
+    signature, roles, target = found
+    # Key=value lines rather than one delimited string: a signature contains
+    # spaces and slashes, and a role may contain a colon, so anything the shell
+    # would have to split on appears inside a value already.
+    print("REFUSE")
+    print("signature=%s" % signature)
+    print("roles=%s" % ", ".join(role for role in roles if role))
+    print("target=%s" % (target or ""))
     sys.exit(0)
 
 print("ALLOW")
@@ -815,6 +1060,11 @@ verdict="$(
     LISA_GUARD_COMMAND="$command_str" \
       LISA_GUARD_READY_ROLE="$ready_role" \
       LISA_GUARD_AMBIENT_OVERRIDE="$ambient_override" \
+      LISA_GUARD_DEFAULT_READY_ROLE="$default_ready_role" \
+      LISA_GUARD_OWN_REPO="$own_repo" \
+      LISA_GUARD_UPSTREAM_REPO="$upstream_repo" \
+      LISA_GUARD_UPSTREAM_READY_ROLE="$upstream_ready_role" \
+      LISA_GUARD_CALLER_IS_GITHUB="$caller_is_github" \
       python3 -
 )"
 python_status=$?
@@ -827,8 +1077,17 @@ if [ "$python_status" -ne 0 ]; then
   exit 0
 fi
 
+verdict_field() {
+  printf '%s\n' "$verdict" | sed -n "s/^$1=//p" | head -1
+}
+
 case "$verdict" in
-  REFUSE*) refuse "${verdict#REFUSE }" ;;
+  REFUSE*)
+    refuse \
+      "$(verdict_field signature)" \
+      "$(verdict_field roles)" \
+      "$(verdict_field target)"
+    ;;
 esac
 
 exit 0

package/plugins/lisa-copilot/rules/eager/ready-role-filing.md

@@ -23,4 +23,6 @@ Filed, not ready, and no `human_gate` is the **incomplete handoff** case — wri
 
 The PreToolUse guard `block-direct-issue-create.sh` refuses a direct tracker-creation command (`gh issue create`, `gh api` POST to an issues endpoint, `linear`/`jira`/`acli` creates, equivalent `curl` posts) that carries **no readiness declaration** — no configured build-ready role and no `[lisa-human-gate]` marker. It shipped because this rule as prose did not bind: 13 of 13 issues filed during the session that merged it bypassed it, several by the agent that wrote it, while the one obligation backed by a git hook was honored 50 of 50 times. It stands down where no tracker is configured, and for an operator who set `LISA_ALLOW_DIRECT_ISSUE_CREATE` **in the ambient environment** — never from an inline assignment on the refused command.
 
+**The role is the TARGET repository's, not the caller's.** A creation addressed at another repository — `--repo` / `-R`, or a `repos/<org>/<repo>/issues` endpoint — is judged against that repository's build-ready role: `hardening.upstreamReadyRole` (default `status:ready`) when the target is `hardening.upstreamRepo`, and the stock `status:ready` otherwise. A creation naming no repository, or naming the project's own `github.org`/`github.repo`, is judged against the project's own role exactly as before. A declaration is required either way; only its vocabulary changes.
+
 Full contract (the per-vendor before/after table, marker format, and recovery sweep): [reference/ready-role-filing.md](../reference/ready-role-filing.md).

package/plugins/lisa-copilot/rules/reference/credential-substrate-precedence.md

@@ -179,8 +179,14 @@ the chokepoint cannot answer for is a setup gap to fix, not a store to add.
 4. Keep MCP adapters and name the operations for which MCP is the only substrate.
 5. Make the terminal failure name the exact credential and remediation command.
 
-Single-substrate access skills are conformant when their one substrate is
-provider-credential-authenticated (`lisa-sonarcloud-access`: the official SonarQube MCP
-authenticates headlessly from `SONARQUBE_CLI_TOKEN`, so it *is* the tier 1 substrate and
-needs no separate REST tier). Reserve a multi-tier ladder for vendors whose MCP is
-browser-OAuth or keychain-bound and therefore dead headless.
+An access skill whose MCP is provider-credential-authenticated has no interactive
+tier to demote — that MCP *is* the tier 1 substrate (`lisa-sonarcloud-access`: the
+official SonarQube MCP authenticates headlessly from `SONARQUBE_CLI_TOKEN`).
+Reserve a browser-OAuth demotion for vendors whose MCP is keychain-bound and
+therefore dead headless.
+
+That is a claim about tier ORDER and never about exclusivity. "Tier 1 needs no
+demotion" does not license "there is no other substrate": where the vendor exposes
+a token-authenticated Web API, it remains a sanctioned read-only fallback for a
+surface on which the MCP is not wired, and a missing MCP there is a demotion rather
+than a terminal tool-access failure.

package/plugins/lisa-copilot/rules/reference/integration-access-layer.md

@@ -33,14 +33,17 @@ unavailable" means.
 Do not blind-retry a failed or absent substrate, and never silently no-op when no
 tier is available.
 
-Some MCPs authenticate headlessly from an env token and need no separate REST
-tier — such an MCP **is** the configured-provider substrate on both developer
-machines and cloud routines, so a single-substrate access skill is conformant. The
-official SonarQube MCP is one such case (`SONARQUBE_CLI_TOKEN`
-[+ `SONARQUBE_CLI_ORG`/`SONARQUBE_CLI_SERVER`]): `lisa-sonarcloud-access` resolves it as a
-single substrate with no hand-rolled REST fallback. Reserve the multi-tier ladder
-for vendors whose MCP is browser-OAuth or keychain-bound and therefore dead
-headless.
+Some MCPs authenticate headlessly from an env token — such an MCP **is** the
+configured-provider substrate on both developer machines and cloud routines, so it
+sits at tier 1 with nothing above it to demote. The official SonarQube MCP is one
+such case (`SONARQUBE_CLI_TOKEN` [+ `SONARQUBE_CLI_ORG`/`SONARQUBE_CLI_SERVER`]):
+`lisa-sonarcloud-access` prefers it and falls back to the token-authenticated Sonar
+Web API for reads on a surface where it is not wired. Reserve the browser-OAuth
+demotion for vendors whose MCP is keychain-bound and therefore dead headless.
+
+Being top of the ladder is not the same as being the whole ladder. An access layer
+may say "prefer this substrate"; it may not say "this is the only one" while the
+vendor exposes a token-authenticated API the same credential already opens.
 
 ## Access Skills
 
@@ -66,7 +69,7 @@ Source audit date: 2026-06-23. Scope: `plugins/src/**/skills/**` and
 | Notion | setup-only references | `notion-access` | Done. |
 | Linear | Multiple base queue/read/write/verify skills | Raw Linear MCP | Access layer added; consumers still need migration to `linear-access`. |
 | Jam | None in `plugins/src` at audit time | No access layer | Access layer added for host rules that include Jam triage. |
-| SonarCloud | Routed through `sonarcloud-access` | Official SonarQube MCP (single substrate) | Migrated to the official token-authed SonarQube MCP; bespoke REST dispatch removed. |
+| SonarCloud | Routed through `sonarcloud-access` | Official SonarQube MCP preferred; token-authed Web API as the read-only fallback | Migrated to the official token-authed SonarQube MCP; the bespoke REST *dispatch* was removed, which is not the same as forbidding a Web API read. |
 | Sentry | No Sentry MCP references in `plugins/src`; CLI/REST mentions only | CLI/REST scattered in observability docs | Access layer added for future MCP-backed consumers. |
 | PostHog | No PostHog MCP references in `plugins/src`; observability docs mention PostHog detection | No access layer | Access layer added for future MCP-backed consumers. |
 | Google Play | No MCP surface; EAS submit docs only | `play-store-access` for Expo post-submit release visibility | Done for Expo stack. |

package/plugins/lisa-copilot/rules/reference/ready-role-filing.md

@@ -67,6 +67,33 @@ Two ways out, both deliberate:
 - **No tracker configured** — `.lisa.config.json` absent or carrying no `tracker`. There is no `lisa-tracker-write` to route through, so the guard stands down. This is the bootstrapping case, and it is *detected* rather than asserted: nobody has to remember an env var to bring up a new repo.
 - **`LISA_ALLOW_DIRECT_ISSUE_CREATE`** in the ambient environment — the human operator's override, mirroring `LISA_ALLOW_INSTRUCTION_FILE_WRITE`. It is honored **only** from the environment the hook inherits and is refused outright when it appears as an inline assignment on the intercepted command. A tool-call shell is fresh each time and its exports never reach the hook, so the ambient variable can only have been set by a human before the session began. An escape the governed agent reaches by typing one more token in front of the command it was just refused is not an escape hatch; it is this rule's original failure with extra steps.
 
+### Which repository's vocabulary answers
+
+The guard demands a build-ready role. Whose role that is depends on **where the item lands**, not on whose config file is nearest.
+
+Resolving it from the calling project unconditionally made the highest-value report Lisa receives unfileable. Filing upstream is not a hypothetical: `lisa-persist-learning` step 6 files a redacted hardening ticket at `hardening.upstreamRepo` on a cron, and Lisa's own design already states that repository runs *its own* build queue off *its own* ready role. The guard was the one component assuming there is only one. What actually happened, per calling tracker:
+
+| Caller's tracker | What was demanded of another repository | Outcome |
+|---|---|---|
+| `jira` / `linear` | a workflow **state**, as the value of a `gh --label` | **unsatisfiable** — that label does not exist there and `gh` rejects an unknown one, so obeying the guard made the command fail |
+| `github`, renamed lane | the caller's own label | refused; the target never carried that token |
+| `github`, stock lane | `status:ready` | worked — because both repositories happened to pick the same string. A coincidence, not a routing decision, which is why the defect was intermittent across the fleet rather than universal |
+
+Unsatisfiable is not the same as refused. The only escape that *did* work cross-repo was `[lisa-human-gate]`, and using it there is a lie about the item: it stamps a build-ready defect report as held for a human product call, and the target's build queue scans the ready role and nothing else. The report is filed and never picked up — the exact incomplete handoff this guard exists to prevent, committed one repository over. (The workaround actually in use was worse still: ask a second agent, in a repo with the right label, to type the command. A control routinely satisfied by delegating around it is misrouting, not enforcing.)
+
+So the target is extracted from the command — `--repo` / `-R` / `--repo=o/r` in any position before a bare `--`, and the `repos/<org>/<repo>/issues` endpoint on the `gh api` and `curl` paths — and the role resolved for **it**:
+
+- **No target named, or the project's own `github.org`/`github.repo`** — the project's own role, unchanged.
+- **The configured `hardening.upstreamRepo`** — `hardening.upstreamReadyRole`, defaulting to `status:ready`.
+- **Any other repository** — the stock `status:ready`. Lisa has no configuration describing it, and the caller's token is categorically not its lane.
+- **A GitHub-tracked project that declares no `github.org`/`github.repo`** cannot be compared against a target at all, so both roles are accepted. Permissive about *which* token, never about *whether* one is required.
+
+The source is config, not the network. A live `gh api repos/<org>/<repo>/labels` lookup would be more general and is the wrong trade for a `PreToolUse` hook: a round-trip on every intercepted command, and a new fail-open surface when it errors.
+
+The refusal changes with it. `/lisa:track` routes through `lisa-tracker-write` to the **caller's own** tracker and therefore cannot file upstream at all, so recommending it for a cross-repo filing sends the agent to a path that structurally cannot do what it was refused for. The cross-repo message names `bunx @codyswann/lisa file-upstream` — the path Lisa actually ships, which composes a public-safe body through an allowlist projection — and names the target's ready role.
+
+What did **not** change: an undeclared cross-repo create is still refused. Only which token satisfies the declaration moved.
+
 ### Where the guard's authority ends
 
 Two limits, stated rather than implied, because a control that documents its own boundary is worth more than one that suggests completeness it does not have.

package/plugins/lisa-copilot/skills/lisa-sonarcloud-access/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-sonarcloud-access
-description: "Vendor-neutral access layer for SonarQube Cloud/Server. Sonar triage skills MUST delegate through this skill rather than calling the SonarQube MCP tools directly. Single substrate: the official SonarQube MCP server (mcp__sonarqube__*), authenticated headlessly from SONARQUBE_CLI_TOKEN (+ SONARQUBE_CLI_ORG for Cloud, SONARQUBE_CLI_SERVER for Server)."
+description: "Vendor-neutral access layer for SonarQube Cloud/Server. Sonar triage skills MUST delegate through this skill rather than calling the SonarQube MCP tools directly. Preferred substrate: the official SonarQube MCP server (mcp__sonarqube__*), authenticated headlessly from SONARQUBE_CLI_TOKEN (+ SONARQUBE_CLI_ORG for Cloud, SONARQUBE_CLI_SERVER for Server); the Sonar Web API, authenticated with the same token, is the sanctioned fallback when the MCP is not wired on this surface."
 allowed-tools: ["Bash", "Read", "Skill"]
 ---
 
@@ -12,16 +12,26 @@ this skill owns the tool selection.
 
 ## Substrate
 
-There is exactly one substrate: the **official SonarQube MCP server**, provided by
+The **preferred** substrate is the **official SonarQube MCP server**, provided by
 the `sonarqube` plugin and launched by the `sonar` CLI (`sonar run mcp`). It
 authenticates headlessly from environment variables — no browser, no OS keychain —
 so it is the same substrate on a developer machine and in a headless cloud routine.
-
-That makes this skill conformant with `credential-substrate-precedence` as a
-single-substrate access layer: this MCP **is** the configured-provider substrate
-(it is token-authenticated, not browser-OAuth), so there is no interactive tier to
-demote and no second REST tier to add. Identity-match against the configured org
-remains mandatory, as on every substrate.
+Prefer it because it owns the tool selection this skill exists to centralise.
+
+It is not the only sanctioned substrate. The **Sonar Web API**, authenticated with
+the same token, is a sanctioned fallback for read-only operations when the MCP is
+not wired on this surface. An earlier revision of this file said otherwise — that
+the MCP was "the only sanctioned substrate" and a missing MCP was "not a reason to
+curl the Web API" — and that was wrong on its face: `.github/workflows/quality.yml`
+already reads `api/ce/task` with a token to turn an opaque failed scan into an
+operator-readable one. A rule the shipping repository contradicts is documentation,
+not a constraint.
+
+The distinction that does hold: a token-authenticated MCP **is** the
+configured-provider substrate under `credential-substrate-precedence` (it is not
+browser-OAuth), so there is no interactive tier to demote here. That is a statement
+about tier ORDER, not about exclusivity. Identity-match against the configured org
+remains mandatory on either substrate.
 
 - `SONARQUBE_CLI_TOKEN` — required (Sonar user/analysis token).
 - `SONARQUBE_CLI_ORG` — required for SonarQube Cloud.
@@ -89,16 +99,21 @@ being on PATH is not access. Probe by searching projects (the `projects` toolset
 always enabled):
 
 - If a `mcp__sonarqube__*` project-search tool returns, access is proven.
-- If no `mcp__sonarqube__*` tool is present, or the call fails authentication, fail
-  loudly and do not improvise a substitute:
+- If no `mcp__sonarqube__*` tool is present on this surface, that is a **demotion,
+  not a blocker**. Fall back to the Sonar Web API with the same resolved token for
+  the read-only operation at hand.
+- Only when neither substrate can prove access — no MCP tool *and* no usable token
+  — is this a terminal tool-access-gate failure. Say so, and do not improvise a
+  third route:
 
 ```text
 Error: no SonarQube access. Run /lisa:setup:sonar (or `sonar integrate <agent>`), and set SONARQUBE_CLI_TOKEN (+ SONARQUBE_CLI_ORG for Cloud / SONARQUBE_CLI_SERVER for Server).
 ```
 
-There is no hand-rolled REST fallback: the official MCP is headless-capable via the
-token env vars, so it is the only sanctioned substrate. A missing MCP is a
-tool-access-gate failure to surface, not a reason to curl the Web API.
+The distinction matters because the two cases have different remedies. An absent
+MCP on a surface that holds a valid credential is a wiring gap the agent can work
+around; treating it as terminal manufactures a tool-access failure on a surface
+that has access.
 
 ## Operation → toolset map
 
@@ -127,14 +142,17 @@ tool accepts them.
 Every operation in the map above is **read-only** — quality, coverage, and
 security data. So the `credential-substrate-precedence` guarded fallback for
 mutating operations (write, read back, assert the tenant from the response, roll
-back on mismatch) is not engaged here; with one substrate there is nothing to
-fall back to in any case. A future operation that mutates Sonar state — marking
+back on mismatch) is not engaged here, because nothing in the map writes. The
+Web API fallback is sanctioned for READS only; it does not open a mutation path.
+A future operation that mutates Sonar state — marking
 a hotspot safe, changing an issue's status — is a write and MUST reconcile by
 read-back before any retry.
 
 ## Invariants
 
-- The official SonarQube MCP is the only substrate; there is no REST fallback.
+- The official SonarQube MCP is the preferred substrate, not the only one. The
+  Sonar Web API with the same token is a sanctioned read-only fallback, and a
+  missing MCP is a demotion rather than a terminal failure.
 - `SONARQUBE_CLI_*` values are resolved through `lisa-secrets-access` and
   exported in-process, with the bare environment variables as the documented
   fallback. Never write them to a dotfile or a `.env` on a local surface.

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

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