@plainconceptsplatform/agent-harness 2.0.0 → 2.0.1

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.

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

@@ -1,63 +1,63 @@
-**Browser MCP tools are FORBIDDEN for all Azure DevOps operations.**
-
----
-
-### Step 1: Find PRs
-
-If PR link provided, extract ID from URL. Otherwise:
-
-```bash
-az repos pr list --repository {repo} --status active --top 1
-```
-
-### Step 2: Read comment threads
-
-```bash
-az devops invoke \
-  --area git --resource pullRequestThreads \
-  --route-parameters project={project} repositoryId={repo} pullRequestId={id} \
-  --http-method GET --api-version 7.1
-```
-
-### Step 3: Categorize feedback
-
-| Category      | Description                         | Action                              |
-| ------------- | ----------------------------------- | ----------------------------------- |
-| `code-change` | Reviewer requests code modification | Return to lead to spawn specialists |
-| `spec-update` | Affects proposal, design, or tasks  | Update openspec artifacts           |
-| `question`    | Reviewer asks a question            | Reply with answer                   |
-| `resolved`    | Thread already resolved             | Skip                                |
-
-### Step 4: Update openspec (if spec-update)
-
-```bash
-git branch --show-current
-# feature/193208-roles-crud → change: us-193208-roles-crud
-```
-
-Update: `openspec/changes/{change}/proposal.md`, `design.md`, or `tasks.md` as appropriate.
-
-### Step 5: Reply to each thread
-
-```bash
-az devops invoke \
-  --area git --resource pullRequestThreadComments \
-  --route-parameters project={project} repositoryId={repo} pullRequestId={id} threadId={tid} \
-  --http-method POST --api-version 7.1 --in-file reply.json
-```
-
-`reply.json`:
-
-```json
-{
-  "comments": [
-    {
-      "parentCommentId": 1,
-      "content": "Acknowledged, applying this change now.",
-      "commentType": 1
-    }
-  ]
-}
-```
-
+**Browser MCP tools are FORBIDDEN for all Azure DevOps operations.**
+
+---
+
+### Step 1: Find PRs
+
+If PR link provided, extract ID from URL. Otherwise:
+
+```bash
+az repos pr list --repository {repo} --status active --top 1
+```
+
+### Step 2: Read comment threads
+
+```bash
+az devops invoke \
+  --area git --resource pullRequestThreads \
+  --route-parameters project={project} repositoryId={repo} pullRequestId={id} \
+  --http-method GET --api-version 7.1
+```
+
+### Step 3: Categorize feedback
+
+| Category      | Description                         | Action                              |
+| ------------- | ----------------------------------- | ----------------------------------- |
+| `code-change` | Reviewer requests code modification | Return to lead to spawn specialists |
+| `spec-update` | Affects proposal, design, or tasks  | Update openspec artifacts           |
+| `question`    | Reviewer asks a question            | Reply with answer                   |
+| `resolved`    | Thread already resolved             | Skip                                |
+
+### Step 4: Update openspec (if spec-update)
+
+```bash
+git branch --show-current
+# feature/193208-roles-crud → change: us-193208-roles-crud
+```
+
+Update: `openspec/changes/{change}/proposal.md`, `design.md`, or `tasks.md` as appropriate.
+
+### Step 5: Reply to each thread
+
+```bash
+az devops invoke \
+  --area git --resource pullRequestThreadComments \
+  --route-parameters project={project} repositoryId={repo} pullRequestId={id} threadId={tid} \
+  --http-method POST --api-version 7.1 --in-file reply.json
+```
+
+`reply.json`:
+
+```json
+{
+  "comments": [
+    {
+      "parentCommentId": 1,
+      "content": "Acknowledged, applying this change now.",
+      "commentType": 1
+    }
+  ]
+}
+```
+
 ---

package/src/fragments/ops-review/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 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: Find PRs
-
-If PR link provided, extract number from URL. Otherwise:
-
-```bash
-gh pr list --repo {owner}/{repo} --state open --limit 1
-```
-
-### Step 2: Read comment threads
-
-```bash
-gh pr view {pr-number} --repo {owner}/{repo} --comments
-# Or structured output:
-gh api repos/{owner}/{repo}/pulls/{pr-number}/comments
-gh api repos/{owner}/{repo}/pulls/{pr-number}/reviews
-```
-
-### Step 3: Categorize feedback
-
-| Category      | Description                         | Action                              |
-| ------------- | ----------------------------------- | ----------------------------------- |
-| `code-change` | Reviewer requests code modification | Return to lead to spawn specialists |
-| `spec-update` | Affects proposal, design, or tasks  | Update openspec artifacts           |
-| `question`    | Reviewer asks a question            | Reply with answer                   |
-| `resolved`    | Thread already resolved             | Skip                                |
-
-### Step 4: Update openspec (if spec-update)
-
-```bash
-git branch --show-current
-# feature/add-user-auth → change: add-user-auth
-```
-
-Update: `openspec/changes/{change}/proposal.md`, `design.md`, or `tasks.md` as appropriate.
-
-### Step 5: Reply to each comment thread
-
-```bash
-# Reply to a review comment
-gh api repos/{owner}/{repo}/pulls/{pr-number}/comments/{comment-id}/replies \
-  --method POST \
-  --field body="Acknowledged, applying this change now."
-
-# Or post a general PR comment
-gh pr comment {pr-number} --body "Updated design.md to reflect feedback."
-```
-
+**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: Find PRs
+
+If PR link provided, extract number from URL. Otherwise:
+
+```bash
+gh pr list --repo {owner}/{repo} --state open --limit 1
+```
+
+### Step 2: Read comment threads
+
+```bash
+gh pr view {pr-number} --repo {owner}/{repo} --comments
+# Or structured output:
+gh api repos/{owner}/{repo}/pulls/{pr-number}/comments
+gh api repos/{owner}/{repo}/pulls/{pr-number}/reviews
+```
+
+### Step 3: Categorize feedback
+
+| Category      | Description                         | Action                              |
+| ------------- | ----------------------------------- | ----------------------------------- |
+| `code-change` | Reviewer requests code modification | Return to lead to spawn specialists |
+| `spec-update` | Affects proposal, design, or tasks  | Update openspec artifacts           |
+| `question`    | Reviewer asks a question            | Reply with answer                   |
+| `resolved`    | Thread already resolved             | Skip                                |
+
+### Step 4: Update openspec (if spec-update)
+
+```bash
+git branch --show-current
+# feature/add-user-auth → change: add-user-auth
+```
+
+Update: `openspec/changes/{change}/proposal.md`, `design.md`, or `tasks.md` as appropriate.
+
+### Step 5: Reply to each comment thread
+
+```bash
+# Reply to a review comment
+gh api repos/{owner}/{repo}/pulls/{pr-number}/comments/{comment-id}/replies \
+  --method POST \
+  --field body="Acknowledged, applying this change now."
+
+# Or post a general PR comment
+gh pr comment {pr-number} --body "Updated design.md to reflect feedback."
+```
+
 ---