@plainconceptsplatform/agent-harness 2.0.0 → 2.1.0

package/src/fragments/archive/none.md

@@ -1,73 +1,73 @@
-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
+   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.

package/src/fragments/guardrails/codegraph.md

@@ -1,7 +1,7 @@
-## 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
+
+- **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.

package/src/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 — 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.

package/src/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
+
+- 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.

package/src/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 ALL CLI commands with `rtk` (e.g. `rtk git diff`, `rtk pnpm test`). Read-only commands like `cat`, `ls`, `Get-Content` are exempt.

package/src/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 - 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.

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

@@ -1,29 +1,29 @@
-**Browser MCP tools are FORBIDDEN for all Azure DevOps operations.**
-
----
-
-### Step 1: Parse input
-
-`$ARGUMENTS` is the work item title/description. If it contains a title and body separated by a newline or `---`, split them. Otherwise use the full text as the title with an empty body.
-
-### Step 2: Create work item
-
-```bash
-az boards work-item create \
-  --title "{title}" \
-  --description "{body}" \
-  --type "User Story"
-```
-
-### Step 3: Report
-
-```text
-Work item created
-  ID: {id}
-  Title: {title}
-  URL: {work-item-url}
-```
-
-Tell the user: "Use `/plan-propose {work-item-url}` to turn this into a plan."
-
+**Browser MCP tools are FORBIDDEN for all Azure DevOps operations.**
+
+---
+
+### Step 1: Parse input
+
+`$ARGUMENTS` is the work item title/description. If it contains a title and body separated by a newline or `---`, split them. Otherwise use the full text as the title with an empty body.
+
+### Step 2: Create work item
+
+```bash
+az boards work-item create \
+  --title "{title}" \
+  --description "{body}" \
+  --type "User Story"
+```
+
+### Step 3: Report
+
+```text
+Work item created
+  ID: {id}
+  Title: {title}
+  URL: {work-item-url}
+```
+
+Tell the user: "Use `/plan-propose {work-item-url}` to turn this into a plan."
+
 ---

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

@@ -1,30 +1,30 @@
-**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.**
-Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
-
----
-
-### Step 1: Parse input
-
-`$ARGUMENTS` is the issue title/description. If it contains a title and body separated by a newline or `---`, split them. Otherwise use the full text as the title with an empty body.
-
-### Step 2: Create issue
-
-```bash
-gh issue create \
-  --repo {owner}/{repo} \
-  --title "{title}" \
-  --body "{body}"
-```
-
-### Step 3: Report
-
-```text
-Issue created
-  URL: {issue-url}
-  Number: #{number}
-  Title: {title}
-```
-
-Tell the user: "Use `/plan-propose {issue-url}` to turn this into a plan."
-
+**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.**
+Always pass `--repo {owner}/{repo}` explicitly, never rely on git context to resolve the repo.
+
+---
+
+### Step 1: Parse input
+
+`$ARGUMENTS` is the issue title/description. If it contains a title and body separated by a newline or `---`, split them. Otherwise use the full text as the title with an empty body.
+
+### Step 2: Create issue
+
+```bash
+gh issue create \
+  --repo {owner}/{repo} \
+  --title "{title}" \
+  --body "{body}"
+```
+
+### Step 3: Report
+
+```text
+Issue created
+  URL: {issue-url}
+  Number: #{number}
+  Title: {title}
+```
+
+Tell the user: "Use `/plan-propose {issue-url}` to turn this into a plan."
+
 ---

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

@@ -1,29 +1,29 @@
-**NEVER use browser tools to navigate to atlassian.net: use `acli` CLI only.**
-
----
-
-### Step 1: Parse input
-
-`$ARGUMENTS` is the issue title/description. If it contains a title and body separated by a newline or `---`, split them. Otherwise use the full text as the title with an empty body.
-
-### Step 2: Create issue
-
-```bash
-acli jira issue create \
-  --summary "{title}" \
-  --description "{body}" \
-  --type "Story"
-```
-
-### Step 3: Report
-
-```text
-Issue created
-  Key: {key}
-  Title: {title}
-  URL: {issue-url}
-```
-
-Tell the user: "Use `/plan-propose {issue-url}` to turn this into a plan."
-
+**NEVER use browser tools to navigate to atlassian.net: use `acli` CLI only.**
+
+---
+
+### Step 1: Parse input
+
+`$ARGUMENTS` is the issue title/description. If it contains a title and body separated by a newline or `---`, split them. Otherwise use the full text as the title with an empty body.
+
+### Step 2: Create issue
+
+```bash
+acli jira issue create \
+  --summary "{title}" \
+  --description "{body}" \
+  --type "Story"
+```
+
+### Step 3: Report
+
+```text
+Issue created
+  Key: {key}
+  Title: {title}
+  URL: {issue-url}
+```
+
+Tell the user: "Use `/plan-propose {issue-url}` to turn this into a plan."
+
 ---

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

@@ -1,41 +1,41 @@
-**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.
+**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.

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

@@ -1,53 +1,53 @@
-**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.
+**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.

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

@@ -1,38 +1,38 @@
-**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.
+**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.