@plainconceptsplatform/agent-harness 2.4.1 → 2.5.1

package/cli/fragments/archive/none.md

@@ -1,73 +1,75 @@
-2. **Find the oldest unarchived change**
-
-   List unarchived changes (top-level only, excludes `archive/`):
-
-   ```bash
-   find "$REPO_ROOT/openspec/changes" -mindepth 1 -maxdepth 1 -type d -not -name 'archive' | sort
-   ```
-
-   If empty, report a blocker and stop. Otherwise select the **oldest** change (by directory creation/sort order) as the candidate.
-
-   This mode has no platform PR integration, so completion is judged from local state only. Do not look up remote PRs or work items.
-
-3. **Confirm the candidate**
-
-   Show the candidate (ID, title) and any other unarchived changes, then ask:
-
-   ```text
-   Oldest unarchived change found:
-     ID: {change-id}
-     Title: {title from proposal.md}
-
-   Proceed with archiving? [yes/no]
-   ```
-
-   Stop if the user does not confirm.
-
-4. **Archive the change**
-
-   ```bash
-   git checkout -b archive/{change-id}
-   ```
-
-   Load `@openspec-archive-change` skill and follow it to archive the change.
-
-5. **Update docs**
-
-   Compare the archived change's specs against `ARCHITECTURE.md` and `DESIGN.md`. If updates are needed, show them and get user approval before applying.
-
-6. **Commit the archive**
-
-   ```bash
-   git add -A
-   git commit -m "archive: {title} ({change-id})"
-   ```
-
-   No PR is created in this mode. Leave the `archive/{change-id}` branch for the user to merge or push manually if they choose.
-
-   If work was stashed in step 1, restore it after the commit unless the user opts out.
-
-7. **Report**
-
-   Display:
-
-   ```text
-   Archive complete
-
-     Change ID: {change-id}
-     Title: {title}
-     Archive branch: archive/{change-id}
-
-     Documentation updates:
-     - ARCHITECTURE.md: {count} changes applied
-     - DESIGN.md: {count} changes applied
-   ```
-
-## Rules
-
-- All OpenSpec paths resolve from `git rev-parse --show-toplevel`. Never use `/openspec/...`.
-- Only process top-level directories in `$REPO_ROOT/openspec/changes/`; exclude `archive/`.
-- Use change ID and slug only as search hints; do not assume the source branch name.
-- The oldest unarchived change is the only candidate: never ask the user which change to archive.
-- This mode has no GitHub or Azure DevOps integration. Never call `gh` or `az`, and never use browser tools or direct web requests for PR/work-item lookups.
-- Never invent or guess PR, branch, or merge metadata.
+2. **Find the oldest unarchived change**
+
+   List unarchived changes (top-level only, excludes `archive/`):
+
+   ```bash
+   find "$REPO_ROOT/openspec/changes" -mindepth 1 -maxdepth 1 -type d -not -name 'archive' | sort
+   ```
+
+   If empty, report a blocker and stop. Otherwise select the **oldest** change (by directory creation/sort order) as the candidate.
+
+   This mode has no platform PR integration, so completion is judged from local state only. Do not look up remote PRs or work items.
+
+3. **Confirm the candidate**
+
+   Show the candidate (ID, title) and any other unarchived changes, then ask:
+
+   ```text
+   Oldest unarchived change found:
+     ID: {change-id}
+     Title: {title from proposal.md}
+
+   Proceed with archiving? [yes/no]
+   ```
+
+   Stop if the user does not confirm.
+
+4. **Archive the change**
+
+   ```bash
+   git checkout -b archive/{change-id}
+   ```
+
+   Load `@openspec-archive-change` skill and follow it to archive the change.
+
+5. **Update docs**
+
+   Compare the archived change's specs against `ARCHITECTURE.md` and `DESIGN.md`. If updates are needed, show them and get user approval before applying.
+
+6. **Commit the archive**
+
+   ```bash
+   # Stage specific paths only: a shared tree may hold another agent's or a
+   # person's edits, and -A commits them under this message.
+   git add openspec/changes/   # plus ARCHITECTURE.md / DESIGN.md if step 5 updated them
+   git commit -m "archive: {title} ({change-id})"
+   ```
+
+   No PR is created in this mode. Leave the `archive/{change-id}` branch for the user to merge or push manually if they choose.
+
+   If work was stashed in step 1, restore it after the commit unless the user opts out.
+
+7. **Report**
+
+   Display:
+
+   ```text
+   Archive complete
+
+     Change ID: {change-id}
+     Title: {title}
+     Archive branch: archive/{change-id}
+
+     Documentation updates:
+     - ARCHITECTURE.md: {count} changes applied
+     - DESIGN.md: {count} changes applied
+   ```
+
+## Rules
+
+- All OpenSpec paths resolve from `git rev-parse --show-toplevel`. Never use `/openspec/...`.
+- Only process top-level directories in `$REPO_ROOT/openspec/changes/`; exclude `archive/`.
+- Use change ID and slug only as search hints; do not assume the source branch name.
+- The oldest unarchived change is the only candidate: never ask the user which change to archive.
+- This mode has no GitHub or Azure DevOps integration. Never call `gh` or `az`, and never use browser tools or direct web requests for PR/work-item lookups.
+- Never invent or guess PR, branch, or merge metadata.

package/cli/fragments/guardrails/codegraph.md

@@ -1,7 +1,5 @@
-## CodeGraph
-
-- **Use `codegraph_explore` INSTEAD OF grep, glob, or read.** It is always available. Do not assume it might be missing.
-  - One call returns the relevant symbols' verbatim, line-numbered source plus the call paths between them, use it as a full replacement for Read, Grep, and file-reading sub-tasks when working with indexed code.
-  - If you instinctively reach for grep or read to find or understand code, STOP: call `codegraph_explore` instead with the symbol name, file path, or a natural-language question. It covers the same ground in one call instead of a dozen.
-- **Fall back to grep/glob/read ONLY when `codegraph_explore` returns no results** or the query is for something codegraph does not index (config files, plain-text docs, `.env` patterns, raw string searches). When you do fall back, you MUST state that codegraph returned nothing.
-- Do NOT run `codegraph` in bash: it is an MCP server, not a CLI tool.
+## CodeGraph
+
+- `codegraph_explore` replaces grep, glob and read for anything indexed: one call returns the relevant symbols' verbatim, line-numbered source plus the call paths between them, where finding the same thing by hand takes a dozen. Give it a symbol name, a file path, or a plain question.
+- Fall back to grep, glob and read when it returns nothing, or for what it does not index: config files, plain-text docs, `.env` patterns, raw string searches. Say that it returned nothing when you do.
+- It is an MCP server, not a CLI. Never run `codegraph` in bash.

package/cli/fragments/guardrails/humanizer.md

@@ -1,4 +1,4 @@
-## Humanizer (optimization skill — MANDATORY LOAD)
-
-- **You MUST call `skill("humanizer")` via the skill tool before writing any prose** (commit messages, PR descriptions, docs, proposals) to remove AI writing patterns and sound more natural.
-- Do NOT apply humanizer to code, config files, or terminal output: only to prose.
+## Humanizer (optimization skill)
+
+- Load `skill("humanizer")` before writing prose (commit messages, PR descriptions, docs, proposals); unhumanized prose reads as machine-written. Editing, shell and spawning stay blocked until it is loaded (pc-system-reminders).
+- Never apply it to code, config files, or terminal output: prose only.

package/cli/fragments/guardrails/memory.md

@@ -1,4 +1,4 @@
-## Agentmemory
-
-- Use agentmemory MCP tools (`memory_smart_search`, `memory_save`, `memory_sessions`, `memory_governance_delete`) for cross-session context: `memory_smart_search` for prior decisions before implementing unfamiliar areas, `memory_save` for architecture decisions and cross-agent context.
-- Do NOT run `agentmemory` in bash: it is an MCP server. Start the server with `agentmemory` in a separate terminal, then use MCP tools.
+## Agentmemory
+
+- Cross-session context lives in the agentmemory MCP tools: `memory_smart_search` for prior decisions before working somewhere unfamiliar, `memory_save` for architecture decisions and anything the next agent will need, plus `memory_sessions` and `memory_governance_delete`.
+- It is an MCP server, not a CLI. Never run `agentmemory` in bash; start it with `agentmemory` in a separate terminal and use the tools.

package/cli/fragments/guardrails/rtk.md

@@ -1,3 +1,3 @@
-## RTK
-
-- Prefix ALL CLI commands with `rtk` (e.g. `rtk git diff`, `rtk pnpm test`). Read-only commands like `cat`, `ls`, `Get-Content` are exempt.
+## RTK
+
+- Prefix CLI commands with `rtk` (`rtk git diff`, `rtk pnpm test`); it strips the output down to what matters. Read-only commands like `cat`, `ls` and `Get-Content` are exempt.

package/cli/fragments/guardrails/simple-english.md

@@ -1,4 +1,4 @@
-## Simple English (optimization skill - MANDATORY LOAD)
-
-- **You MUST call `skill("simple-english")` via the skill tool before responding.** This is not optional. Apply Simplified Technical English to all prose responses.
-- Keep code blocks, identifiers, CLI commands, file paths, quoted errors, and product names exact.
+## Simple English (optimization skill)
+
+- Apply Simplified Technical English to all prose: `skill("simple-english")`. Editing, shell and spawning stay blocked until it is loaded (pc-system-reminders).
+- Keep code blocks, identifiers, CLI commands, file paths, quoted errors, and product names exact.

package/cli/fragments/ops-backlog/az.md

@@ -1,4 +1,4 @@
-**Browser MCP tools are FORBIDDEN for all Azure DevOps operations.**
+Azure DevOps data comes from the `az` CLI; a page fetch of dev.azure.com is denied (pc-system-reminders). If `az` is unavailable, report it as a blocker.
 
 ---
 

package/cli/fragments/ops-backlog/gh.md

@@ -1,4 +1,4 @@
-**ALL GitHub data MUST come from `gh` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitHub operations, even if gh CLI fails. If `gh` is unavailable, report as a blocker.**
+GitHub data comes from the `gh` CLI; a page fetch of github.com is denied (pc-system-reminders). If `gh` is unavailable, report it as a blocker.
 Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
 
 ---

package/cli/fragments/ops-backlog/jira.md

@@ -1,4 +1,4 @@
-**NEVER use browser tools to navigate to atlassian.net: use `acli` CLI only.**
+Jira data comes from the `acli` CLI; a page fetch of atlassian.net is denied (pc-system-reminders). If `acli` is unavailable, report it as a blocker.
 
 ---
 

package/cli/fragments/ops-evidence/az.md

@@ -1,41 +1,44 @@
-**Browser MCP tools are FORBIDDEN for all Azure DevOps operations. Use `az boards` CLI only. If `az` is unavailable, skip publishing (report it) — do not fail the pipeline unless the caller declared publishing a ship gate.**
-
-Publish one status comment for every manifest. A `blocked` or `failed` manifest must include its status and reason, never a success claim.
-
-### Step 1 — Image hosting caveat
-
-Azure DevOps discussion comments do not render an image from a repo blob URL the way GitHub does, and `az boards` cannot upload an attachment inline. Use text evidence and derive a commit-pinned repository URL from `git remote get-url origin` when possible. Otherwise include the committed asset path, branch, and SHA.
-
-```
-Screenshot committed at: {asset-path} (branch {branch}, commit {sha})
-```
-
-### Step 2 — Build the comment with a stable marker (idempotent)
-
-```
-<!-- pc-visual-evidence:{change-id} -->
-
-Status: `{status}`
-
-{reason?}
-
-Manifest and assets: {commit-pinned links when available, otherwise committed paths and SHA}
-
-{prMarkdown}
-
-{image-line?}
-```
-
-### Step 3 — Upsert the discussion comment on the work item (and the PR when provided)
-
-`az boards work-item update --discussion` appends a comment; to stay idempotent, first read existing discussion comments and skip if one already carries the marker for this change id, otherwise post:
-
-```bash
-# best-effort existing-comment check via the work-item comments API
-az boards work-item show --id {work-item-id} --query 'fields."System.History"' -o tsv 2>/dev/null | grep -q "pc-visual-evidence:{change-id}" \
-  || az boards work-item update --id {work-item-id} --discussion "$BODY"
-```
-
-When a PR number is provided, also add the same body as a PR thread comment (`az repos pr` thread APIs) if available.
-
-- If a comment call fails: report it. Fail the run ONLY when publishing was declared a ship gate; otherwise continue.
+Azure DevOps data comes from the `az` CLI; a page fetch of dev.azure.com is denied (pc-system-reminders). If `az` is unavailable, skip publishing and report it; do not fail the pipeline unless the caller declared publishing a ship gate.
+
+Publish one status comment for every manifest. A `blocked` or `failed` manifest must include its status and reason, never a success claim.
+
+### Step 1 — Image hosting caveat
+
+Azure DevOps discussion comments do not render an image from a repo blob URL the way GitHub does, and `az boards` cannot upload an attachment inline. Use text evidence and derive a commit-pinned repository URL from `git remote get-url origin` when possible. Otherwise include the committed asset path, branch, and SHA.
+
+```
+Screenshot committed at: {asset-path} (branch {branch}, commit {sha})
+```
+
+### Step 2 — Build the comment with a stable marker (idempotent)
+
+```
+<!-- pc-visual-evidence:{change-id} -->
+<!-- pc-visual-evidence-status:{status} -->
+
+Status: `{status}`
+
+{reason?}
+
+Manifest and assets: {commit-pinned links when available, otherwise committed paths and SHA}
+
+{prMarkdown}
+
+{image-line?}
+```
+
+### Step 3 — Upsert the discussion comment on the work item (and the PR when provided)
+
+`az boards work-item update --discussion` appends a comment and cannot edit one in place, so match on the status probe rather than the change id alone. Matching the change id alone leaves a stale `blocked` comment standing after a later run succeeds:
+
+```bash
+# Skip only when this exact status is already published for this change.
+az boards work-item show --id {work-item-id} --query 'fields."System.History"' -o tsv 2>/dev/null | grep -q "pc-visual-evidence-status:{status}" \
+  || az boards work-item update --id {work-item-id} --discussion "$BODY"
+```
+
+When an earlier comment carries this change id with a different status, this one supersedes it: open the body with `Supersedes the earlier evidence comment for this change.` so a reader can tell which is current.
+
+When a PR number is provided, also add the same body as a PR thread comment (`az repos pr` thread APIs) if available.
+
+- If a comment call fails: report it. Fail the run ONLY when publishing was declared a ship gate; otherwise continue.

package/cli/fragments/ops-evidence/gh.md

@@ -1,53 +1,54 @@
-**ALL GitHub data MUST come from `gh` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitHub. If `gh` is unavailable, skip publishing (report it) — do not fail the pipeline over it unless the caller declared publishing a ship gate.**
-Always pass `--repo {owner}/{repo}` (or `repos/{owner}/{repo}` for `gh api`) explicitly.
-
-Publish one status comment for every manifest. A `blocked` or `failed` manifest must include its status and reason, never a success claim.
-
-### Step 1 — Build commit-pinned repository links
-
-An embedded image must be a raw URL pinned to the commit that actually contains it, and that commit must be pushed. For each asset in `evidence.json`:
-
-```bash
-SHA="$(git log -n 1 --format=%H -- '{asset-path}')"          # the commit that added this asset
-[ -z "$SHA" ] && echo "asset not committed: {asset-path}" && exit-skip
-gh api "repos/{owner}/{repo}/contents/{asset-path}?ref=$SHA" --silent   # 404 → not pushed yet → skip embedding
-```
-
-Build a blob link for every committed manifest and asset: `https://github.com/{owner}/{repo}/blob/{SHA}/{asset-path}`. Use the raw URL only for a verified embeddable image: `https://raw.githubusercontent.com/{owner}/{repo}/{SHA}/{asset-path}`. If verification fails, include the asset path and SHA as text; never post a dead link.
-
-### Step 2 — Build the comment body with a stable marker (idempotent)
-
-Prefix the body with a hidden marker so re-runs update the same comment instead of piling on:
-
-```
-<!-- pc-visual-evidence:{change-id} -->
-
-Status: `{status}`
-
-{reason?}
-
-Manifest: {commit-pinned evidence.json link}
-
-Assets: {commit-pinned asset links}
-
-{prMarkdown}
-```
-
-### Step 3 — Upsert the comment on BOTH the issue and the PR
-
-For each target number (the originating issue, and the PR number when provided), find an existing marked comment and PATCH it, else POST a new one:
-
-```bash
-# find existing
-ID="$(gh api "repos/{owner}/{repo}/issues/{number}/comments" --paginate --jq \
-  '.[] | select(.body | contains("<!-- pc-visual-evidence:{change-id} -->")) | .id' | head -1)"
-
-if [ -n "$ID" ]; then
-  gh api --method PATCH "repos/{owner}/{repo}/issues/comments/$ID" -f body="$BODY" --silent
-else
-  gh api --method POST  "repos/{owner}/{repo}/issues/{number}/comments" -f body="$BODY" --silent
-fi
-```
-
-- Text-only (no verified image, or `default` mode / nothing pushed): drop the image lines, keep the summary (tasks N/N, verification result, commits).
-- If a comment call fails: report it. Fail the run ONLY when the caller declared publishing a ship gate; otherwise continue.
+GitHub data comes from the `gh` CLI; a page fetch of github.com is denied (pc-system-reminders). If `gh` is unavailable, skip publishing and report it; do not fail the pipeline unless the caller declared publishing a ship gate.
+Always pass `--repo {owner}/{repo}` (or `repos/{owner}/{repo}` for `gh api`) explicitly.
+
+Publish one status comment for every manifest. A `blocked` or `failed` manifest must include its status and reason, never a success claim.
+
+### Step 1 — Build commit-pinned repository links
+
+An embedded image must be a raw URL pinned to the commit that actually contains it, and that commit must be pushed. For each asset in `evidence.json`:
+
+```bash
+SHA="$(git log -n 1 --format=%H -- '{asset-path}')"          # the commit that added this asset
+[ -z "$SHA" ] && echo "asset not committed: {asset-path}" && exit-skip
+gh api "repos/{owner}/{repo}/contents/{asset-path}?ref=$SHA" --silent   # 404 → not pushed yet → skip embedding
+```
+
+Build a blob link for every committed manifest and asset: `https://github.com/{owner}/{repo}/blob/{SHA}/{asset-path}`. Use the raw URL only for a verified embeddable image: `https://raw.githubusercontent.com/{owner}/{repo}/{SHA}/{asset-path}`. If verification fails, include the asset path and SHA as text; never post a dead link.
+
+### Step 2 — Build the comment body with a stable marker (idempotent)
+
+Prefix the body with a hidden marker so re-runs update the same comment instead of piling on:
+
+```
+<!-- pc-visual-evidence:{change-id} -->
+<!-- pc-visual-evidence-status:{status} -->
+
+Status: `{status}`
+
+{reason?}
+
+Manifest: {commit-pinned evidence.json link}
+
+Assets: {commit-pinned asset links}
+
+{prMarkdown}
+```
+
+### Step 3 — Upsert the comment on BOTH the issue and the PR
+
+For each target number (the originating issue, and the PR number when provided), find an existing marked comment and PATCH it, else POST a new one:
+
+```bash
+# find existing
+ID="$(gh api "repos/{owner}/{repo}/issues/{number}/comments" --paginate --jq \
+  '.[] | select(.body | contains("<!-- pc-visual-evidence:{change-id} -->")) | .id' | head -1)"
+
+if [ -n "$ID" ]; then
+  gh api --method PATCH "repos/{owner}/{repo}/issues/comments/$ID" -f body="$BODY" --silent
+else
+  gh api --method POST  "repos/{owner}/{repo}/issues/{number}/comments" -f body="$BODY" --silent
+fi
+```
+
+- Text-only (no verified image, or `default` mode / nothing pushed): drop the image lines, keep the summary (tasks N/N, verification result, commits).
+- If a comment call fails: report it. Fail the run ONLY when the caller declared publishing a ship gate; otherwise continue.

package/cli/fragments/ops-evidence/jira.md

@@ -1,38 +1,42 @@
-**NEVER use browser tools to navigate to atlassian.net: use `acli` CLI only. If `acli` is unavailable, skip publishing (report it) — do not fail the pipeline unless the caller declared publishing a ship gate.**
-
-Publish one status comment for every manifest. A `blocked` or `failed` manifest must include its status and reason, never a success claim.
-
-### Step 1 — Image hosting caveat
-
-Jira comments cannot embed an image from a repo blob URL, and `acli` does not upload attachments inline. Use text evidence and derive a commit-pinned repository URL from `git remote get-url origin` when possible. Otherwise include the committed asset path, branch, and SHA:
-
-```
-Screenshot committed at: {asset-path} (branch {branch}, commit {sha})
-```
-
-### Step 2 — Build the comment with a stable marker (idempotent)
-
-```
-<!-- pc-visual-evidence:{change-id} -->
-
-Status: `{status}`
-
-{reason?}
-
-Manifest and assets: {commit-pinned links when available, otherwise committed paths and SHA}
-
-{prMarkdown}
-
-{image-line?}
-```
-
-### Step 3 — Upsert the comment on the issue
-
-Keep it idempotent: list existing comments and skip if one already carries the marker for this change id, otherwise add:
-
-```bash
-acli jira issue comment list --key {issue-key} 2>/dev/null | grep -q "pc-visual-evidence:{change-id}" \
-  || acli jira issue comment --key {issue-key} --body "$BODY"
-```
-
-- If the comment command fails: report it. Fail the run ONLY when publishing was declared a ship gate; otherwise continue.
+Jira data comes from the `acli` CLI; a page fetch of atlassian.net is denied (pc-system-reminders). If `acli` is unavailable, skip publishing and report it; do not fail the pipeline unless the caller declared publishing a ship gate.
+
+Publish one status comment for every manifest. A `blocked` or `failed` manifest must include its status and reason, never a success claim.
+
+### Step 1 — Image hosting caveat
+
+Jira comments cannot embed an image from a repo blob URL, and `acli` does not upload attachments inline. Use text evidence and derive a commit-pinned repository URL from `git remote get-url origin` when possible. Otherwise include the committed asset path, branch, and SHA:
+
+```
+Screenshot committed at: {asset-path} (branch {branch}, commit {sha})
+```
+
+### Step 2 — Build the comment with a stable marker (idempotent)
+
+```
+<!-- pc-visual-evidence:{change-id} -->
+<!-- pc-visual-evidence-status:{status} -->
+
+Status: `{status}`
+
+{reason?}
+
+Manifest and assets: {commit-pinned links when available, otherwise committed paths and SHA}
+
+{prMarkdown}
+
+{image-line?}
+```
+
+### Step 3 — Upsert the comment on the issue
+
+`acli` cannot edit a comment in place, so match on the status probe rather than the change id alone. Matching the change id alone leaves a stale `blocked` comment standing after a later run succeeds:
+
+```bash
+# Skip only when this exact status is already published for this change.
+acli jira issue comment list --key {issue-key} 2>/dev/null | grep -q "pc-visual-evidence-status:{status}" \
+  || acli jira issue comment --key {issue-key} --body "$BODY"
+```
+
+When an earlier comment carries this change id with a different status, this one supersedes it: open the body with `Supersedes the earlier evidence comment for this change.` so a reader can tell which is current.
+
+- If the comment command fails: report it. Fail the run ONLY when publishing was declared a ship gate; otherwise continue.

package/cli/fragments/ops-review/az.md

@@ -1,4 +1,4 @@
-**Browser MCP tools are FORBIDDEN for all Azure DevOps operations.**
+Azure DevOps data comes from the `az` CLI; a page fetch of dev.azure.com is denied (pc-system-reminders). If `az` is unavailable, report it as a blocker.
 
 ---
 

package/cli/fragments/ops-review/gh.md

@@ -1,4 +1,4 @@
-**ALL GitHub data MUST come from `gh` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitHub operations, even if gh CLI fails. If `gh` is unavailable, report as a blocker.**
+GitHub data comes from the `gh` CLI; a page fetch of github.com is denied (pc-system-reminders). If `gh` is unavailable, report it as a blocker.
 Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
 
 ---

package/cli/fragments/ops-review/gl.md

@@ -1,4 +1,4 @@
-**ALL GitLab data MUST come from `glab` CLI. NEVER use webfetch, HTTP requests, or browser MCP tools for GitLab operations, even if glab CLI fails. If `glab` is unavailable, report as a blocker.**
+GitLab data comes from the `glab` CLI; a page fetch of gitlab.com is denied (pc-system-reminders). If `glab` is unavailable, report it as a blocker.
 Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
 
 ---