@codyswann/lisa 2.223.3 → 2.225.0

package/plugins/lisa/rules/reference/factory-model.md

@@ -77,12 +77,16 @@ Greenfield projects are agent-ready by construction. A brownfield project must e
 two ordered steps before the automation fleet runs unattended:
 
 1. **Knowledge convergence** (`/lisa:agent-ready`): build the initial knowledge wiki from every
-   reachable source — repository, git history, tracker, connected systems — under the operating
+   inventoried source — repository, git history, tracker, connected systems — under the operating
    premise *"starting tomorrow, you maintain this project without human input; today is your only
-   chance to ask questions."* Everything derivable is derived and written into the wiki; what only
-   a human can answer becomes a product-readable entry in `wiki/gaps.md`. Humans answer inline, a
-   **fresh session** re-runs the skill, verified answers are absorbed into wiki pages, and the loop
-   repeats until a run reports zero open gaps.
+   chance to ask questions."* Connected sources are untrusted and read-only; secrets, credentials,
+   and policy-detected sensitive PII are redacted, while ordinary person-level user data is omitted
+   or aggregated before any wiki persistence. Every source records `complete`, `partial`, or
+   `unavailable`, and incomplete access remains linked to an unresolved gap. Everything derivable is
+   derived and written into the wiki; what only a human can answer becomes a product-readable entry
+   in `wiki/gaps.md`. Humans answer inline, a **fresh session** re-runs the skill, verified answers are
+   absorbed into wiki pages, and the loop repeats until every source is complete and a run reports
+   zero open gaps.
 2. **Standards adoption**: apply Lisa's full lint rules, guardrails, and thresholds — the project
    goes red by design — then refactor to conformance **without changing business logic or
    functionality**, via the improve/fix flows, with behavior preservation proven by tests and

package/plugins/lisa/scripts/automation-status-expected-fleet.mjs

@@ -10,6 +10,7 @@
 
 import {
   resolveBuildQueueArgument,
+  resolveGithubQueueRepoRef,
   resolveGithubRepoRef,
   resolvePrdQueueArgument,
   resolvePrdSource,
@@ -119,9 +120,32 @@ export function resolveExpectedAutomationFleet(input = {}) {
 
   const tracker = config.tracker;
   const source = resolvePrdSource(config);
-  const prdQueue = resolvePrdQueueArgument(config, source);
-  const buildQueue = resolveBuildQueueArgument(config, tracker);
-  const repairQueue = resolveRepairQueueArgument(config, source, tracker);
+  const explicitGithubIdentity = `${identity.owner}/${identity.repo}`;
+  const githubQueue =
+    tracker === "github"
+      ? resolveGithubQueueRepoRef(config, {
+          gitRemoteUrl: input.gitRemoteUrl,
+        })
+      : null;
+  const explicitGithubQueue = githubQueue
+    ? `${githubQueue.owner}/${githubQueue.repo}`
+    : undefined;
+  const prdQueue =
+    source === "github"
+      ? `${explicitGithubIdentity} intake_mode=prd`
+      : resolvePrdQueueArgument(config, source);
+  const buildQueue = resolveBuildQueueArgument(config, tracker, {
+    explicitQueue: tracker === "github" ? explicitGithubQueue : undefined,
+    gitRemoteUrl: input.gitRemoteUrl,
+  });
+  const repairQueue = resolveRepairQueueArgument(
+    config,
+    source,
+    tracker,
+    explicitGithubIdentity,
+    explicitGithubQueue,
+    buildQueue
+  );
 
   const expected = [
     createExpectedEntry(
@@ -237,10 +261,17 @@ function createUnsupportedEntry(identity, id, reason) {
  * @param {string | undefined} tracker
  * @returns {string}
  */
-function resolveRepairQueueArgument(config, source, tracker) {
+function resolveRepairQueueArgument(
+  config,
+  source,
+  tracker,
+  explicitGithubIdentity,
+  explicitGithubQueue,
+  resolvedBuildQueue
+) {
   if (tracker === "github" && source === "github") {
     requireGithubRepo(config);
-    return "github intake_mode=both";
+    return `${explicitGithubIdentity} intake_mode=both build_queue=${explicitGithubQueue}`;
   }
 
   if (tracker === "linear" && source === "linear") {
@@ -260,13 +291,12 @@ function resolveRepairQueueArgument(config, source, tracker) {
 
   if (tracker === "github" && source === undefined) {
     requireGithubRepo(config);
-    return "github intake_mode=both";
+    return `${explicitGithubIdentity} intake_mode=both build_queue=${explicitGithubQueue}`;
   }
 
-  const buildQueue = resolveBuildQueueArgument(config, tracker);
-  return buildQueue.includes("intake_mode=")
-    ? buildQueue
-    : `${buildQueue} intake_mode=build`;
+  return resolvedBuildQueue.includes("intake_mode=")
+    ? resolvedBuildQueue
+    : `${resolvedBuildQueue} intake_mode=build`;
 }
 
 /**

package/plugins/lisa/scripts/queue-contract-resolution.mjs

@@ -173,12 +173,17 @@ export function resolvePrdQueueArgument(
  */
 export function resolveBuildQueueArgument(
   config = {},
-  tracker = resolveBuildTracker(config)
+  tracker = resolveBuildTracker(config),
+  options = {}
 ) {
   switch (tracker) {
-    case "github":
-      requireGithubRepo(config);
+    case "github": {
+      const queue = resolveGithubQueueRepoRef(config, options);
+      if (options.explicitQueue || config.github?.queueRepo) {
+        return `${queue.owner}/${queue.repo} intake_mode=build`;
+      }
       return "github intake_mode=build";
+    }
     case "linear":
       requireLinearWorkspace(config);
       return "linear";
@@ -340,6 +345,14 @@ export function resolveQueueContract(input = {}) {
   const source = resolvePrdSource(config);
   const tracker = resolveBuildTracker(config);
 
+  const githubIdentity = resolveGithubRepoRef(config, input.gitRemoteUrl);
+  const githubQueue =
+    tracker === "github"
+      ? resolveGithubQueueRepoRef(config, {
+          gitRemoteUrl: input.gitRemoteUrl,
+        })
+      : null;
+
   return {
     currentRepo: resolveCurrentRepo(input),
     source,
@@ -349,7 +362,15 @@ export function resolveQueueContract(input = {}) {
       ...resolvePrdLifecycleRoles(config, source),
     },
     buildQueue: {
-      argument: resolveBuildQueueArgument(config, tracker),
+      argument: resolveBuildQueueArgument(config, tracker, {
+        gitRemoteUrl: input.gitRemoteUrl,
+      }),
+      ...(tracker === "github"
+        ? {
+            identityRepo: `${githubIdentity.owner}/${githubIdentity.repo}`,
+            queueRepo: `${githubQueue.owner}/${githubQueue.repo}`,
+          }
+        : {}),
       ...resolveBuildLifecycleRoles(config, tracker),
     },
   };
@@ -408,6 +429,54 @@ export function resolveGithubRepoRef(config = {}, gitRemoteUrl) {
   return null;
 }
 
+/**
+ * Resolve the GitHub queue without changing the repository identity used
+ * for automation names and `repo:<name>` claim scoping. An explicit invocation
+ * target wins, followed by `github.queueRepo`, then the identity repo.
+ *
+ * `github.queueRepo` may be a short repo name (normalized to the identity
+ * owner) or an `owner/repo` reference. Cross-owner queues therefore remain
+ * explicit while the common same-organization umbrella layout stays concise.
+ *
+ * @param {Record<string, any>} config
+ * @param {{ readonly explicitQueue?: string, readonly gitRemoteUrl?: string }} [options]
+ * @returns {{ readonly owner: string, readonly repo: string }}
+ */
+export function resolveGithubQueueRepoRef(config = {}, options = {}) {
+  const identity = resolveGithubRepoRef(config, options.gitRemoteUrl);
+  if (!identity) {
+    throw new Error(
+      "Unable to resolve the GitHub repository identity: github.org/github.repo or a GitHub origin remote is required."
+    );
+  }
+
+  const configured = options.explicitQueue ?? config.github?.queueRepo;
+  if (configured === undefined || configured === null || configured === "") {
+    return identity;
+  }
+  if (typeof configured !== "string") {
+    throw new Error(
+      "Unable to resolve the GitHub queue: github.queueRepo must be a repo name or owner/repo."
+    );
+  }
+
+  const value = configured
+    .trim()
+    .replace(/^https:\/\/github\.com\//i, "")
+    .replace(/\.git$/i, "");
+  const parts = value.split("/").filter(Boolean);
+  if (parts.length === 1) {
+    return { owner: identity.owner, repo: parts[0] };
+  }
+  if (parts.length === 2) {
+    return { owner: parts[0], repo: parts[1] };
+  }
+
+  throw new Error(
+    "Unable to resolve the GitHub queue: github.queueRepo must be a repo name or owner/repo."
+  );
+}
+
 /**
  * @param {string | undefined} gitRemoteUrl
  * @returns {string | null}

package/plugins/lisa/scripts/queue-status-build-readers.mjs

@@ -58,23 +58,75 @@ const HIGHLIGHT_COPY = {
  *   readonly queueResolved?: boolean
  *   readonly queueArgument?: string
  *   readonly resolutionError?: string | null
+ *   readonly currentRepo?: string | null
  * }} input
  */
 export function readGithubBuildQueueSnapshot(input = {}) {
   const roles = input.roles ?? resolveBuildLifecycleRoles({}, "github").roles;
-  const normalizedItems = (input.issues ?? [])
+  const issues = input.issues ?? [];
+  const normalizedItems = issues
+    .filter(
+      issue =>
+        classifyGithubIssueRepoScope(issue, input.currentRepo) === "current"
+    )
+    .map(issue => normalizeGithubBuildIssue(issue, roles))
+    .filter(Boolean);
+  const unscopedCandidates = issues
+    .filter(
+      issue =>
+        classifyGithubIssueRepoScope(issue, input.currentRepo) === "unscoped"
+    )
     .map(issue => normalizeGithubBuildIssue(issue, roles))
     .filter(Boolean);
 
-  return createBuildQueueSnapshot({
-    tracker: "github",
-    items: normalizedItems,
-    roles,
-    namespaceAdopted: input.namespaceAdopted,
-    queueResolved: input.queueResolved,
-    queueArgument: input.queueArgument,
-    resolutionError: input.resolutionError,
-  });
+  return {
+    ...createBuildQueueSnapshot({
+      tracker: "github",
+      items: normalizedItems,
+      roles,
+      namespaceAdopted: input.namespaceAdopted,
+      queueResolved: input.queueResolved,
+      queueArgument: input.queueArgument,
+      resolutionError: input.resolutionError,
+    }),
+    unscopedCount: unscopedCandidates.length,
+    unscopedCandidates,
+  };
+}
+
+/**
+ * Classify current-repo, unlabeled, and sibling-only candidates. Unlabeled work
+ * remains separately visible because build intake must determine and stamp its
+ * repo, but it must not inflate current-repo lifecycle counts. Containers
+ * carrying multiple repo labels are current when one label matches.
+ *
+ * @param {Record<string, any>} issue
+ * @param {string | null | undefined} currentRepo
+ * @returns {"current" | "unscoped" | "sibling"}
+ */
+function classifyGithubIssueRepoScope(issue, currentRepo) {
+  if (typeof currentRepo !== "string" || currentRepo.trim().length === 0) {
+    return "current";
+  }
+
+  const repoLabels = (Array.isArray(issue?.labels) ? issue.labels : [])
+    .map(label =>
+      typeof label === "string"
+        ? label
+        : typeof label?.name === "string"
+          ? label.name
+          : ""
+    )
+    .map(label => label.trim().toLowerCase())
+    .filter(label => label.startsWith("repo:") && label.length > 5);
+
+  if (repoLabels.length === 0) {
+    return "unscoped";
+  }
+
+  return repoLabels.includes(`repo:${currentRepo.trim().toLowerCase()}`)
+    ? "current"
+    : "sibling";
 }
 
 /**

package/plugins/lisa/skills/lisa-agent-ready/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-agent-ready
-description: "Make a brownfield project agent-ready: build the initial knowledge wiki from everything the agent can reach (repository, git history, connected trackers, docs, observability), then write wiki/gaps.md — the questions only a human can answer before agents can operate the project autonomously. Iterative convergence: humans answer the gaps inline, a fresh session re-runs the skill, verified answers are absorbed into wiki pages, and the loop repeats until a run reports zero open gaps and declares the project agent-ready. This is the knowledge half of brownfield onboarding; standards adoption (applying Lisa's lint rules, guardrails, and thresholds, then refactoring to conform without changing behavior) follows it."
+description: "Make a brownfield project agent-ready: build the initial knowledge wiki from read-only, redacted ingestion of every inventoried source (repository, git history, connected trackers, docs, observability), then write wiki/gaps.md — the questions only a human can answer before agents can operate the project autonomously. Iterative convergence: humans answer the gaps inline, a fresh session re-runs the skill, verified answers are absorbed into wiki pages, and the loop repeats until every source is complete, zero open gaps remain, and the project is declared agent-ready. This is the knowledge half of brownfield onboarding; standards adoption (applying Lisa's lint rules, guardrails, and thresholds, then refactoring to conform without changing behavior) follows it."
 allowed-tools: ["Skill", "Bash", "Read", "Write", "Edit", "Glob", "Grep", "WebFetch"]
 ---
 
@@ -38,19 +38,88 @@ that a later reader could have answered from the repository is a defect of this
 1. Ensure the knowledge wiki exists. If the project has no `wiki/`, install it first (delegate to
    the wiki install/setup surface — `/lisa:wiki:install` / `lisa-wiki-setup`); do not hand-roll a
    wiki layout.
-2. Inventory every reachable source: the repository and its full git history, the configured
-   `tracker` and `source`, connected MCP servers and access layers (observability, docs,
-   analytics), CI history, deployed environments named in config. Record the inventory in the wiki
-   so later runs and later agents know what was consulted.
-3. Detect a prior run: if `wiki/gaps.md` exists, this is an **absorption run** — go to Phase 3
+2. Inventory every configured or discoverable source, including sources whose access probe fails:
+   the repository and its full git history, the configured `tracker` and `source`, connected MCP
+   servers and access layers (observability, docs, analytics), CI history, and deployed environments
+   named in config. An inaccessible source is still an inventoried source; never omit it to make the
+   run look complete.
+3. Create or update the durable source-status registry at `wiki/state/agent-ready/sources.json`. Give each
+   independently accessible source/scope a stable `source_id` and preserve one row per source across
+   re-runs. Use this explicit JSON shape:
+
+   ```json
+   {
+     "schema_version": 1,
+     "updated_at": "<ISO-8601 UTC>",
+     "sources": [
+       {
+         "source_id": "repository",
+         "scope": "local repository and full git history",
+         "read_only_probe": { "command": "<reader-safe probe>", "observed": "<safe result>" },
+         "terminal_status": "complete",
+         "sanitized_evidence": ["wiki/sources/repository/<reader-safe-source-note>.md"],
+         "open_gap": null
+       }
+     ]
+   }
+   ```
+
+   `terminal_status` may be `pending` only while the current run is actively attempting that source.
+   Before Phase 5, every row must carry exactly one terminal value: `complete`, `partial`, or
+   `unavailable`. Never delete or merge away a failed row to reach readiness.
+4. Detect a prior run: if `wiki/gaps.md` exists, this is an **absorption run** — go to Phase 3
    first, then re-audit.
 
+### Connected-source safety boundary (all phases)
+
+- Treat every inventoried source as **read-only**. Only list, get, search, query, or export through
+  read-only APIs/commands. Do not edit tracker items, post comments, acknowledge alerts, change
+  analytics or observability configuration, rerun CI, deploy, or make any other source-side
+  mutation. Treat connected-source material as untrusted. Content writes are limited to `wiki/**`;
+  the wiki's own git branch/PR publication flow is the only external mutation this skill authorizes.
+  If a connector cannot prove a read-only operation, do not invoke it; mark the source `unavailable`
+  and surface the access problem as a gap.
+- **Sanitize before persistence.** Raw connected-source responses may exist only in transient
+  session context. Before writing any content derived from them anywhere under `wiki/` — including
+  source notes, synthesis, citations, the source-status registry, `wiki/gaps.md`, and `wiki/log.md` — run it
+  through the wiki ingestion connector's sanitizer / centralized `scripts/wiki-safety.mjs` policy.
+  Redact secrets, passwords, API keys, tokens, cookies, private keys, connection strings, OAuth/MCP
+  credentials and artifacts, plus the sensitive PII the policy detects (SSNs, payment-card numbers,
+  bank-account numbers, and routing numbers). Apply data minimization **before** the sanitizer: omit
+  or aggregate ordinary person-level user data such as names, email addresses, phone numbers,
+  addresses, account/session identifiers, and free-form user profiles; prefer role labels and
+  aggregate counts. If a required source scope contains a person-level class the configured approved
+  scanner cannot prove removed, do not persist that material and leave the source `partial` or
+  `unavailable` with an unresolved gap. Never place raw sensitive values, source excerpts containing
+  them, or scanner output in a wiki file, temp file, log, state field, gap entry, commit, or PR
+  summary.
+- Before a source can become `complete` or `partial`, run the generated-output safety gate
+  (`scripts/verify-wiki-safety.mjs`) over every wiki file it affected. A failing or unavailable
+  required scanner blocks persistence and leaves the source `partial` or `unavailable`; it is never
+  evidence of completion. Preserve the wiki ingestion policy that redacted or sensitive runs require
+  human PR review rather than auto-merge.
+
 ### Phase 1 — Ingest
 
 Delegate to the wiki's ingestion surface (`lisa-wiki-ingest` and its connectors) across the
 repository, the git history, and each connected source from the Phase 0 inventory. Bounded and
 resumable — prefer several focused ingests over one unbounded crawl.
 
+After attempting each source, update its registry row with its terminal result and only sanitized,
+non-sensitive evidence:
+
+- `complete` — the entire inventoried scope was fetched read-only, sanitized before persistence,
+  written as source notes/synthesis, and passed the wiki safety and ingestion verification gates.
+- `partial` — some usable scope was ingested and verified, but a named portion was not covered (for
+  example pagination stopped, a sub-project denied access, or the run hit a bounded limit).
+- `unavailable` — no usable content could be ingested because the read-only tool, connection,
+  permission, or source was unavailable.
+
+Evidence must name the attempted scope, the safe count/range or cursor reached, and reader-safe wiki
+source-note paths. It must not contain raw credentials, PII, sensitive source snippets, or scanner
+output. `partial` and `unavailable` are valid honest terminal outcomes for a run, but they are not
+knowledge-readiness success.
+
 ### Phase 2 — Deep-read for autonomy
 
 Beyond raw ingestion, author the pages an unattended operator needs, deriving everything derivable:
@@ -71,6 +140,9 @@ For each gap in `wiki/gaps.md` a human has answered inline:
    resolved section of the file.
 
 Never treat your own inference as a human answer, and never resolve an open gap by guessing.
+For a source-coverage gap, do not absorb the answer merely because a human described the missing
+material: re-run the source read-only and move its registry row to `complete`, or keep a narrower
+unresolved source gap linked from that row.
 
 ### Phase 4 — Gaps audit
 
@@ -86,6 +158,7 @@ person answering may not code:
 - **Why it blocks autonomy**: <what an unattended agent cannot safely do without this>
 - **What was searched**: <the sources consulted before declaring this a gap>
 - **How to answer**: <where the answer likely lives / what format is useful>
+- **Source**: <source_id from wiki/state/agent-ready/sources.json, or `derived-knowledge`>
 - **Answer**: _(human fills in)_
 - **Status**: open
 ```
@@ -93,13 +166,25 @@ person answering may not code:
 Order entries by autonomy impact (what would cause the worst unattended decision first). Keep the
 file short — a gaps file with fifty entries means Phase 2 stopped too early.
 
+Reconcile source coverage before counting gaps. Every `partial` or `unavailable` registry row must
+link, through its `open_gap` field, to a stable, unresolved gap entry whose `Source` field names that
+row's `source_id` and explains the missing scope or access in plain language. A missing row, a
+`pending`/invalid status, a broken gap link, or a partial/unavailable row without an unresolved gap
+is itself an open blocking gap. Never mark that source gap absorbed while its registry status remains
+`partial` or `unavailable`.
+
 ### Phase 5 — Converge and report
 
 - **Open gaps remain** → report the count and the top items, and instruct: a human answers inline
   in `wiki/gaps.md`, then re-runs `/lisa:agent-ready` in a **new session** (a fresh session avoids
   anchoring on this run's assumptions). Commit the wiki changes through the normal wiki PR flow.
-- **Zero open gaps** → declare the project **agent-ready for knowledge**: record the verdict and
-  date in the gaps file header and the wiki log, and point at the next step — standards adoption.
+- **Zero open gaps** → first enforce the source-completeness gate. Declare the project
+  **agent-ready for knowledge** only when the registry contains a terminal row for every inventoried
+  source, every row is `complete`, every row has verified sanitized evidence, and the open-gap count
+  is zero. If any row is missing, `pending`, `partial`, or `unavailable`, the zero-gap declaration is
+  blocked: regenerate/link the required unresolved source gap and report the project as not ready.
+  When the gate passes, record the verdict and date in the gaps file header and the wiki log, and
+  point at the next step — standards adoption.
 
 ## After convergence: standards adoption
 
@@ -119,5 +204,10 @@ verification. Only then should the automation fleet run unattended on a brownfie
   inline answers.
 - The wiki is the durable store; `wiki/gaps.md` is a queue. Every absorbed answer must land in a
   real wiki page with the gaps entry pointing at it.
+- `wiki/state/agent-ready/sources.json` is the durable coverage record. Source access is always
+  read-only, all source-derived wiki content is sanitized before persistence, and no status may
+  claim more scope than its sanitized evidence proves.
+- Zero open product questions is not enough: knowledge readiness additionally requires every
+  inventoried source to be terminal and `complete`.
 - Follow the wiki's own conventions for commits, `wiki/index.md`, and `wiki/log.md` — this skill
   adds no parallel bookkeeping.

package/plugins/lisa/skills/lisa-agent-ready/agents/openai.yaml

@@ -1,4 +1,4 @@
 display_name: "Agent Ready"
-short_description: "Make a brownfield project agent-ready: build the initial knowledge wiki from everything the agent can reach (repository, git history…"
+short_description: "Make a brownfield project agent-ready: build the initial knowledge wiki from read-only, redacted ingestion of every inventoried source…"
 default_prompt:
-  - "Use $lisa-agent-ready: Make a brownfield project agent-ready: build the initial knowledge wiki from everything the agent can reach (repository, git history…."
+  - "Use $lisa-agent-ready: Make a brownfield project agent-ready: build the initial knowledge wiki from read-only, redacted ingestion of every inventoried source…."

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

@@ -10,7 +10,13 @@ allowed-tools: ["Skill", "Bash"]
 
 1. A GitHub `org/repo` token (e.g., `acme/frontend-v2`).
 2. A full GitHub repo URL (e.g., `https://github.com/acme/frontend-v2`).
-3. The literal token `github` — falls back to `.lisa.config.json` (`github.org` / `github.repo`).
+3. The literal token `github` (or an omitted repo) — resolves merged config
+   `github.queueRepo`, falling back to the identity `github.org/github.repo`.
+
+An explicit `org/repo` token or GitHub URL always wins. `github.queueRepo` may be canonical
+`owner/repo` or a short repo name normalized to `github.org`. It changes only the scanned queue;
+the Phase 3a.0 `repo:<current>` gate still resolves the code repository from `repo` /
+`github.repo` / the git remote.
 
 Run one build-intake cycle. The first eligible issue in the configured `ready` build label is claimed, built via the `github-agent` workflow run in-session (Phase 3c, culminating in `lisa-implement`), relabeled to the configured `done` label (env-aware — see Workflow resolution), then the cycle exits. Remaining ready issues stay queued for later scheduler invocations.
 
@@ -133,7 +139,10 @@ A "transition" means: remove the old role label and add the new one, in two `gh
 1. Parse `$ARGUMENTS`:
    - `org/repo` token → use as-is.
    - GitHub URL → extract `org` and `repo`.
-   - Literal `github` → resolve from `.lisa.config.json` (`github.org`, `github.repo`); error if not set.
+   - Literal `github` or omitted repo → resolve local then global `github.queueRepo`, falling back
+     to `github.org/github.repo`; normalize a short `queueRepo` to `github.org`; error if the
+     resulting identity/queue cannot be resolved.
+   - Never replace current-repo identity with the queue repo. An umbrella queue is only a scan target.
 2. Confirm `gh auth status` succeeds.
 3. Confirm the repo is reachable: `gh repo view <org>/<repo> --json name --jq '.name'`.
 
@@ -405,7 +414,8 @@ Total PRs opened: <n>
 | Variable | Default | Purpose |
 |----------|---------|---------|
 | `.lisa.config.json` `github.org` | (from `$ARGUMENTS`) | GitHub org for the default queue |
-| `.lisa.config.json` `github.repo` | (from `$ARGUMENTS`) | GitHub repo for the default queue |
+| `.lisa.config.json` `github.repo` | (from `$ARGUMENTS`) | Current code-repo identity and `repo:<current>` scope |
+| `.lisa.config.json` `github.queueRepo` | `github.org/github.repo` | Default GitHub scan repo when no explicit repo/URL is passed |
 | `.lisa.config.json` `github.labels.build.ready` | `status:ready` | The label that signals "human says this is buildable" |
 | `.lisa.config.json` `github.labels.build.claimed` | `status:in-progress` | The label set on pickup |
 | `.lisa.config.json` `github.labels.build.done` | env-keyed map or string | The label set after a successful build; env-aware |

package/plugins/lisa/skills/lisa-intake/SKILL.md

@@ -6,7 +6,10 @@ allowed-tools: ["Skill", "Bash", "mcp__claude_ai_Notion__notion-fetch", "mcp__cl
 
 # Intake: $ARGUMENTS
 
-Run one intake cycle against the queue identified by `$ARGUMENTS`. Scans for `Status = Ready`, claims the first eligible item, dispatches it to the appropriate single-item lifecycle skill, then exits. Remaining Ready items are left for later scheduler invocations.
+Run one intake cycle against the queue identified by `$ARGUMENTS`, or by merged GitHub config when
+the repo argument is omitted and a GitHub source/tracker default is resolvable. Scan for
+`Status = Ready`, claim the first eligible item, dispatch it to the appropriate single-item
+lifecycle skill, then exit. Remaining Ready items are left for later scheduler invocations.
 
 For build-queue runs, Intake also accepts an optional `assignee=<vendor-user-id-or-login>` filter.
 Resolution order is:
@@ -22,7 +25,9 @@ as part of this filter.
 
 ## Confirmation policy
 
-Do NOT ask the caller whether to proceed. Once invoked with a queue, run the cycle to completion. The caller (a human at the CLI or a scheduled cron) has already authorized the run by invoking the skill; re-prompting defeats the purpose of a background batch.
+Do NOT ask the caller whether to proceed. Once invoked, resolve the explicit or config-backed queue
+and run the cycle to completion. The caller (a human at the CLI or a scheduled cron) has already
+authorized the run by invoking the skill; re-prompting defeats the purpose of a background batch.
 
 Specifically forbidden:
 
@@ -33,7 +38,8 @@ Specifically forbidden:
 
 The only legitimate reasons to stop early:
 
-- Missing required input (no queue argument, missing project configuration). Surface the missing value and exit.
+- Missing required input (no queue argument **and** no resolvable GitHub default, or missing project
+  configuration). Surface the missing value and exit.
 - The queue itself is misconfigured (Status property missing expected values, JIRA workflow can't reach required transitions). Surface and exit.
 - Empty `Ready` set. Exit cleanly with the idle-case message.
 
@@ -70,7 +76,7 @@ Detect the queue type from `$ARGUMENTS` and route:
 | A full JQL filter (e.g. `project = SE AND component = "frontend"`) | Work queue (JIRA, narrowed) | Invoke `lisa-jira-build-intake` with the JQL |
 | A GitHub **repository** URL or `org/repo` token (e.g. `https://github.com/acme/product-prds` or `acme/product-prds`) when used for **PRDs** | PRD queue (GitHub) | Invoke `lisa-github-prd-intake` (which queries `gh issue list --label prd-ready`, claims the first eligible PRD by relabeling to `prd-in-review`, runs the dry-run validate → branch → write pipeline, then exits). PRD discovery is independent of the destination tracker — the resulting tickets land wherever `.lisa.config.json` `tracker` says. |
 | A GitHub **repository** URL or `org/repo` token when `tracker = github` is configured (build-queue mode) | Work queue (GitHub) | Invoke `lisa-tracker-build-intake` which dispatches to `lisa-github-build-intake` (which queries `gh issue list --label status:ready`, optionally narrows by the resolved assignee filter, claims the first eligible issue via `status:in-progress`, runs `lisa-implement`, relabels to `status:on-dev` on success, then exits). |
-| The literal token `github` | Defaults to `.lisa.config.json` `github.org` / `github.repo`. Routes by **the `intake_mode` flag** in `$ARGUMENTS` (`prd` or `build`); if the flag is absent, prefer the PRD queue when both label namespaces are present, otherwise pick whichever exists. | Invoke the matching skill (`lisa-github-prd-intake` or `lisa-tracker-build-intake`). |
+| The literal token `github` or omitted GitHub repo when merged config resolves a GitHub source/tracker and identity | Routes by **the `intake_mode` flag** in `$ARGUMENTS` (`prd` or `build`). Build mode defaults to merged `github.queueRepo`, then identity `github.org/github.repo`; PRD mode keeps its existing identity source. If the flag is absent, prefer the PRD queue when both label namespaces are present, otherwise pick whichever exists. | Invoke the matching skill (`lisa-github-prd-intake` or `lisa-tracker-build-intake`). |
 
 Disambiguation rules:
 
@@ -80,7 +86,13 @@ Disambiguation rules:
 - A `linear.app` URL → Linear queue. If the path is `/<workspace>` only or `/<workspace>/team/<KEY>/...`, route here. If the path includes `/project/<slug>-<id>` it's a single-PRD URL — direct the caller to `lisa-plan` instead, this skill is batch-only.
 - The literal token `linear` (case-insensitive) → Linear queue, default workspace from `linear.workspace` in `.lisa.config.json`.
 - A `github.com` URL or an `<org>/<repo>` token → GitHub queue. The PRD-vs-build dispatch is determined by which label namespace the repo currently uses: PRD-side (`prd-ready`) → `lisa-github-prd-intake`; build-side (`status:ready` and `tracker = github` in `.lisa.config.json`) → `lisa-tracker-build-intake`. If both namespaces are present, prefer the PRD queue unless `$ARGUMENTS` includes `intake_mode=build`. If the URL points at a single issue (`https://github.com/<org>/<repo>/issues/<n>`), this skill is batch-only — direct the caller to `lisa-plan` (for a single PRD issue) or `lisa-implement` (for a single build issue).
-- The literal token `github` (case-insensitive) → GitHub queue, default repo from `.lisa.config.json` `github.org` / `github.repo`.
+- A GitHub URL or `owner/repo` token is an explicit queue and always wins. The literal token
+  `github` (case-insensitive), or an omitted repo when merged config resolves a GitHub source/tracker
+  and identity, resolves local then global `github.queueRepo`, then identity
+  `github.org/github.repo` **for build dispatch**. Normalize a short queueRepo to `github.org`. PRD
+  dispatch remains on the configured GitHub PRD source. Without an explicit queue or resolvable
+  GitHub default, stop with the missing-input error. Do not use the build queue repo as current-repo
+  identity for `repo:<name>` scoping.
 - A bare alphanumeric token that matches the JIRA project key regex (uppercase letters / digits / hyphen, ≤10 chars — typically the value of `jira.project` in `.lisa.config.json`) is treated as a JIRA project key by default. A token that does not match the regex is treated as a Confluence space key. If it does not resolve as a Confluence space key either, attempt to resolve as a Linear team key via `lisa-linear-access operation: list-teams({query})` before giving up. The only time to stop and ask is when the token resolves to more than one of {JIRA project, Confluence space, Linear team, GitHub `org/repo`} simultaneously — in that overlap the user must disambiguate which queue to scan.
 - An `<org>/<repo>` token (slash-separated, both halves are GitHub-name-shaped) → GitHub queue.
 - A string starting with `project = ` or containing JQL operators (`AND`, `OR`, `=`, `!=`, `~`, etc.) → JQL filter.

package/plugins/lisa/skills/lisa-queue-status/SKILL.md

@@ -58,11 +58,14 @@ Render the report in **grouped sections** so operators can scan it top-down with
 For each inspected queue, report:
 
 1. The queue source or tracker Lisa resolved.
-2. Lifecycle counts using the repo's configured role names.
-3. Whether the queue appears `IDLE`, `HEALTHY`, `ATTENTION_NEEDED`, or `MISCONFIGURED`.
-4. Whether the lifecycle namespace appears adopted versus absent.
-5. The oldest or most actionable blocked, in-review, claimed, shipped, or similar stuck items Lisa can surface without mutating work.
-6. A concise remediation hint when attention is needed.
+2. For GitHub, both `Identity repo: <owner/repo>` and `Queue repo: <owner/repo>`, even when equal.
+3. Lifecycle counts using the repo's configured role names. GitHub umbrella-queue build counts
+   must be scoped to `repo:<currentRepo>` from the repo-scoping ladder; the queue repo is never
+   current-repo identity.
+4. Whether the queue appears `IDLE`, `HEALTHY`, `ATTENTION_NEEDED`, or `MISCONFIGURED`.
+5. Whether the lifecycle namespace appears adopted versus absent.
+6. The oldest or most actionable blocked, in-review, claimed, shipped, or similar stuck items Lisa can surface without mutating work.
+7. A concise remediation hint when attention is needed.
 
 The report should stay terminal-first and immediately actionable: observable queue facts first, then the smallest useful next step.
 
@@ -92,6 +95,11 @@ Queue sections should stay visually grouped. Do not interleave PRD and build fac
 ## Runtime and vendor expectations
 
 - Reuse the same config-resolution defaults and queue-routing rules that `intake` and `repair-intake` use.
+- For GitHub, resolve an explicit repo/URL first, then merged `github.queueRepo`, then
+  `github.org/github.repo`; accept a short queueRepo by normalizing it to `github.org`.
+- Pass the contract's `currentRepo` into `readGithubBuildQueueSnapshot`; lifecycle counts include
+  only `repo:<current>` work. Report its `unscopedCount` / `unscopedCandidates` separately because
+  intake still needs to determine and stamp unlabeled work; exclude sibling-only issues.
 - Work from the current repo's `.lisa.config.json` instead of hardcoding one vendor's lifecycle names.
 - Support the vendor families already served by Lisa intake: GitHub, Linear, JIRA, Notion, and Confluence.
 - If a queue cannot be resolved or its lifecycle namespace has not been adopted, report that explicitly as `MISCONFIGURED` rather than pretending the queue is empty.