@codyswann/lisa 3.51.2 → 3.51.4

package/plugins/lisa-agy/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-agy/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"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.51.2",
+  "version": "3.51.4",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.51.2",
+  "version": "3.51.4",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.51.2",
+  "version": "3.51.4",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.51.2",
+  "version": "3.51.4",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.51.2",
+  "version": "3.51.4",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-copilot/.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"