@plainconceptsplatform/agent-harness 3.0.2 → 3.1.0

package/skills/pc-repo-verify/SKILL.md

@@ -1,123 +1,150 @@
----
-name: pc-repo-verify
-description: Write a reproduction plan for the completed change as a journey of agent-browser waypoints stored with the change. Does not run checks, launch a browser, or take screenshots. Invoked by /repo-verify and the plan-goal pipeline.
-license: MIT
----
-
-# Repo Verify
-
-Write the verification plan for the current branch's change. The checks gate lives in `pc-plan-apply` step 10 (lint, typecheck, test, build). This skill produces the reproduction plan instead: a journey through the new functionality with observation waypoints, written so a later agent-browser executor skill can follow it verbatim.
-
-This skill never launches a browser, never takes a screenshot, never starts a server. It only reads the change and writes a plan file. It is the agent-executed counterpart to `pc-ops-evidence`, whose `capturePlan` stays the CI-side screenshot workflow.
-
-Work only on the current branch: do not switch branches, push, create pull requests, or contact external platforms. Write the plan into the change directory; it is carried into the archive by `pc-plan-archive`.
-
-## Step 1: Read the change
-
-1. Resolve the change id from the caller (autonomous mode) or from the current branch's unarchived change under `openspec/changes/<change-id>/`. Read `proposal.md`, `tasks.md`, and `design.md` when present.
-2. Read `.opencode/source-roots.json` when it exists; use its non-empty `roots` array to scope frontend source, otherwise use the repository root.
-3. Inspect `git diff` against the branch base and the working tree for context on what changed.
-
-## Step 2: Determine UI impact
-
-Decide whether the change is reachable from something a user sees or does in the browser.
-
-1. **Direct** — changed files include user-visible UI: `*.tsx`/`jsx`/`vue`/`svelte`, `*.css`/`scss`/`less`, pages, layouts, components, navigation, routes. The affected surfaces are the routes/components the diff touches.
-2. **Indirect (backend-only diff, frontend-affected)** — the diff touches only API/backend code, but the changed contract is consumed by the frontend. Trace it: for every changed endpoint, route, handler, query, or exported function, search the frontend source roots for references to that name or path. If any reference exists, the frontend **is** affected. Map the surfaces (the routes/components that import or call the changed contract) and build the journey through them, treating the API change as an indirect UI change.
-3. **None** — no path reaches the frontend. Write the stub plan (Step 3, `status: not-applicable`) and stop. Do not fabricate a journey.
-
-Mixed or unknown counts as affected: be safe.
-
-## Step 3: Write the plan
-
-Write `verification-plan.md` into the change directory:
-
-```
-openspec/changes/<change-id>/verification-plan.md
-```
-
-The plan is written in agent-browser idiom so a future executor skill can follow it verbatim. Format:
-
-```markdown
-# verification-plan.md — <change-id>
-
-environment:
-  start: pnpm run dev
-  url: http://localhost:3000
-  login: mock-sso
-  data: |
-    <seed/data preconditions, or "none">
-
-journey:
-  - id: 1
-    arrive:
-      - agent-browser open http://localhost:3000/
-      - agent-browser wait --load networkidle
-    waypoint: wp-1-home
-    capture: home
-    expect: homepage renders; nav is visible
-
-  - id: 2
-    arrive:
-      - agent-browser find text "Items" click
-    waypoint: wp-2-items-list
-    capture: items-list
-    expect: the items list shows the seeded rows
-
-  - id: 3
-    arrive:
-      - agent-browser find first ".item-row" click
-      - agent-browser wait --load networkidle
-    waypoint: wp-3-detail-before
-    capture: detail-before
-    expect: the item detail panel is open and shows the record
-
-  - id: 4
-    arrive:
-      - agent-browser find role button click --name "Status"
-    waypoint: wp-4-detail-active
-    capture: detail-active
-    expect: the status badge now reads "Active"
-```
-
-Replace the example routes, captions, locators, and expectations with the actual change. Locators must be agent-browser-native and stable: prefer `find role`, `find text`, `find label`, `find testid`; use CSS selectors only when no semantic locator exists. Use `wait --load networkidle` (or `wait <selector>` / `wait --text "<known>"`) so the executor reaches the state before observing.
-
-### Waypoint rules
-
-1. The first waypoint is always the baseline at `/`: `wp-1-home`, `capture: home`.
-2. Place waypoints as a pre/post pair around the changed behavior — the state immediately before and immediately after the core change is exercised.
-3. Every waypoint has a `waypoint:` id (`wp-<n>-<slug>`), a `capture:` id (kebab-case, unique), and an `expect:` line stating what must be observable there.
-4. Dynamic data uses `sampleId: first` or `sampleId: any` in the `data:` block; locators that target a record resolve through it.
-5. The number of waypoints is the minimum that reproduces and proves the behavior — not every screenshottable moment, just the meaningful observation points.
-
-### When the change is not UI-reachable
-
-Write the stub and stop:
-
-```markdown
-# verification-plan.md — <change-id>
-
-status: not-applicable
-reason: |
-  Change is backend-only and no frontend code references the changed contract
-  (<names>). No user-visible journey exists; the executor skill should skip.
-```
-
-Adapt the reason to the actual change. Do not invent a journey when Step 2 concluded `None`.
-
-### Rules for writing
-
-- This skill MUST NOT launch a browser, start the app, take screenshots, or run build/test/lint. Those belong elsewhere.
-- Never commit, stage, or push verifications. The caller owns git.
-- The plan file is the only artifact written. Do not modify the change's specs, tasks, or proposal.
-- Keep locators stable and observable: prefer semantic locators over brittle CSS paths.
-
-## Step 4: Result
-
-Report one of:
-
-- `PLAN_WRITTEN <change-id>` — a journey with waypoints was written to `verification-plan.md`.
-- `STUB_WRITTEN <change-id>` — `status: not-applicable` stub written with a reason.
-- `NOT WRITTEN` — hard blocker (unreadable change, missing change directory). Report the blocker and the exact next step.
-
-A correct plan file written to the change directory is the success condition. Write a stub for non-UI changes; never skip writing the file.
+---
+name: pc-repo-verify
+description: Write the verification plan for the completed change, a journey through the new functionality as a fenced YAML block that the evidence workflow replays in headless Chromium after the pull request merges. Does not run checks, launch a browser, or take screenshots. Invoked by /repo-verify and the plan-goal pipeline.
+license: MIT
+---
+
+# Repo Verify
+
+Write the verification plan for the current branch's change. The checks gate lives in `pc-plan-apply` step 10 (lint, typecheck, test, build). This skill produces the reproduction plan instead: a journey through the new functionality with one screenshot per waypoint.
+
+The plan is executed by a machine, not read by one. When the pull request merges, the evidence workflow (`evidence.yml` from `@plainconceptsplatform/workflows`) checks out the pull request head, starts the app, replays every step below in headless Chromium with no model in the loop, and archives one screenshot per waypoint on the pull request. A step it cannot follow is a screenshot of the wrong screen. Write every step so it can be followed literally from a freshly started app.
+
+This skill never launches a browser, never takes a screenshot, never starts a server. It only reads the change and writes a plan file.
+
+Work only on the current branch: do not switch branches, push, create pull requests, or contact external platforms. Write the plan into the change directory; it is carried into the archive by `pc-plan-archive`.
+
+## Project environment
+
+How this project's app starts, where it answers, how a person signs in locally, and what data a fresh start already has. Read it before writing a journey; it is the project's, and an update keeps it.
+
+<!-- PC-PROJECT-ENVIRONMENT-START -->
+- Start: `pnpm run dev` at the repository root brings up the whole stack with mock authentication.
+- URL: `http://localhost:3000`.
+- Sign-in: none recorded yet. Find the local sign-in (a mock account picker, a dev login button) in the source and write its steps into the first waypoint.
+- Seeded data: none recorded yet. Create what the journey needs through the UI.
+<!-- PC-PROJECT-ENVIRONMENT-END -->
+
+## Step 1: Read the change
+
+1. Resolve the change id from the caller (autonomous mode) or from the current branch's unarchived change under `openspec/changes/<change-id>/`. Read `proposal.md`, `tasks.md`, and `design.md` when present.
+2. Read `.opencode/source-roots.json` when it exists; use its non-empty `roots` array to scope frontend source, otherwise use the repository root.
+3. Inspect `git diff` against the branch base and the working tree for context on what changed.
+
+## Step 2: Determine UI impact
+
+Decide whether the change is reachable from something a user sees or does in the browser.
+
+1. **Direct**: changed files include user-visible UI: `*.tsx`/`jsx`/`vue`/`svelte`, `*.css`/`scss`/`less`, pages, layouts, components, navigation, routes. The affected surfaces are the routes/components the diff touches.
+2. **Indirect (backend-only diff, frontend-affected)**: the diff touches only API/backend code, but the changed contract is consumed by the frontend. Trace it: for every changed endpoint, route, handler, query, or exported function, search the frontend source roots for references to that name or path. If any reference exists, the frontend **is** affected. Map the surfaces (the routes/components that import or call the changed contract) and build the journey through them.
+3. **None**: no path reaches the frontend. Write the stub plan (Step 3, `status: not-applicable`) and stop. Do not fabricate a journey.
+
+Mixed or unknown counts as affected: be safe.
+
+## Step 3: Write the plan
+
+Write `verification-plan.md` into the change directory:
+
+```
+openspec/changes/<change-id>/verification-plan.md
+```
+
+Prose around the block is for people and is ignored by the replay. The replay reads the first fenced `yaml` block that holds a `journey`:
+
+````markdown
+# Verification plan: <change-id>
+
+One or two sentences on what the journey proves.
+
+```yaml
+url: http://localhost:3000
+journey:
+  - capture: home
+    expect: signed in, the item list is the home page
+    steps:
+      - open: /
+      - click: { role: button, name: Alice Admin }
+      - wait: { role: heading, name: Items }
+
+  - capture: detail-before
+    expect: the detail panel shows the item without a status badge
+    steps:
+      - click: { text: Seeded item }
+      - wait: { load: networkidle }
+
+  - capture: detail-active
+    expect: the status badge reads Active
+    steps:
+      - click: { role: button, name: Activate }
+      - wait: { text: Active }
+```
+````
+
+### Keys
+
+- `url`: where the app answers once started, from the project environment above. Relative `open:` paths resolve against it.
+- `start` (optional): the command that starts the app, only when it is not the project's default.
+- `viewport` (optional): `1280x800` unless the change is about another size.
+- `journey`: the waypoints, in order, in one browser tab. Each has a `capture` (kebab-case, unique), an `expect` (what is visible in the screenshot), and the `steps` that get there from the previous waypoint.
+
+### Steps
+
+Each step is a map with exactly one action:
+
+| Step | Does |
+|---|---|
+| `open: /path` | navigate (relative to `url`, or a full URL) |
+| `click: <locator>` | click; add `button: right` inside the locator for a context menu |
+| `dblclick: <locator>`, `hover: <locator>`, `check: <locator>`, `uncheck: <locator>` | as named |
+| `fill: { <locator>, value: text }` | replace the field's text |
+| `select: { <locator>, value: option }` | choose an option |
+| `press: Enter` or `press: { <locator>, key: Enter }` | press a key |
+| `wait: <locator>` | until the element is visible |
+| `wait: { text: Saved }` | until the text is visible |
+| `wait: { load: networkidle }` | until the page settles; never a failure on its own |
+| `wait: { url: /items/ }` | until the address contains it |
+| `wait: { ms: 500 }` | a fixed pause, only for an animation with nothing to wait on |
+
+A locator is one of `{ role: button, name: Save }`, `{ text: Save }`, `{ label: Name }`, `{ placeholder: Search }`, `{ testid: save }`, `{ alt: Logo }`, `{ title: Close }`, or `{ css: ".row" }`, optionally with `nth: 1` or `last: true`. The first match is used.
+
+### Rules
+
+1. The first waypoint starts with `open` and signs in, using the sign-in from the project environment. The replay starts from a freshly started app with nothing in the browser.
+2. Everything the journey needs that a fresh start does not have, create through the UI in the steps (a record to open, a setting to change). Never assume data from a developer's machine.
+3. Place waypoints as a pre/post pair around the changed behavior: the state immediately before and immediately after the core change is exercised.
+4. Use the minimum number of waypoints that reproduces and proves the behavior, normally three to six.
+5. Locators name what a person sees: prefer `role` with `name`, then `label`, `text`, `testid`. Copy visible text from the source's default-language strings exactly, not from memory. Use `css` only when nothing semantic exists.
+6. Wait for the state before each capture: end every waypoint's steps with a `wait` on something the screenshot is meant to show.
+7. Only the steps above replay. Network inspection, console reads, and API calls do not; prove those in tests, not here.
+
+### When the change is not UI-reachable
+
+Write the stub and stop:
+
+````markdown
+# Verification plan: <change-id>
+
+```yaml
+status: not-applicable
+reason: Backend-only change; no frontend code references the changed contract (<names>).
+```
+````
+
+Adapt the reason to the actual change. Do not invent a journey when Step 2 concluded `None`.
+
+### Rules for writing
+
+- This skill MUST NOT launch a browser, start the app, take screenshots, or run build/test/lint. Those belong elsewhere.
+- Never commit, stage, or push. The caller owns git.
+- The plan file is the only artifact written. Do not modify the change's specs, tasks, or proposal.
+- When the project environment above says `none recorded yet` and you found the real sign-in or start command in the source, say so in the result so a person can record it there.
+
+## Step 4: Result
+
+Report one of:
+
+- `PLAN_WRITTEN <change-id>`: a journey with waypoints was written to `verification-plan.md`.
+- `STUB_WRITTEN <change-id>`: `status: not-applicable` stub written with a reason.
+- `NOT WRITTEN`: hard blocker (unreadable change, missing change directory). Report the blocker and the exact next step.
+
+A correct plan file written to the change directory is the success condition. Write a stub for non-UI changes; never skip writing the file.

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

@@ -1,44 +0,0 @@
-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 +0,0 @@
-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,42 +0,0 @@
-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/presets/quota.json

@@ -1,20 +0,0 @@
-{
-  "plugin": "@slkiser/opencode-quota@5.0.1",
-  "prompt": {
-    "message": "Install opencode-quota with recommended defaults?",
-    "default": true,
-    "timeoutMs": 20000
-  },
-  "defaults": {
-    "enabledProviders": "auto",
-    "formatStyle": "singleWindow",
-    "percentDisplayMode": "used",
-    "showSessionTokens": true,
-    "enableToast": false,
-    "resetNotifications": { "enabled": false },
-    "tuiCommandDisplay": "inline",
-    "tuiCompactStatus": { "enabled": false },
-    "tuiPromptBar": { "enabled": false },
-    "tuiSidebarPanel": { "enabled": true }
-  }
-}

package/cli/steps/optimization/quota.js

@@ -1,135 +0,0 @@
-import { confirm } from '@inquirer/prompts'
-import fse from 'fs-extra'
-import path from 'node:path'
-import { fileURLToPath } from 'url'
-import { applyEdits, modify, parse as parseJsonc } from 'jsonc-parser'
-import { error, header, info, loading, success, warn } from '../../utils/exec.js'
-
-const __dirname = path.dirname(fileURLToPath(import.meta.url))
-const QUOTA_PRESET_PATH = path.resolve(__dirname, '../../presets/quota.json')
-const quotaPreset = await fse.readJson(QUOTA_PRESET_PATH)
-const PLUGIN = quotaPreset.plugin
-
-export function splitPackageSpec(spec) {
-  const separator = spec.startsWith('@') ? spec.indexOf('@', 1) : spec.lastIndexOf('@')
-  if (separator === -1) return { name: spec, version: 'latest' }
-  return { name: spec.slice(0, separator), version: spec.slice(separator + 1) }
-}
-
-export async function installQuota(options = {}) {
-  if (!options.skipHeader) header('Installing opencode-quota')
-
-  let shouldInstall = true
-  if (!options.skipPrompt && process.stdin.isTTY) {
-    // Same abort-on-timeout pattern as tokenOptimizationStep: never race a
-    // live inquirer prompt, it leaks raw-mode stdin and unhandled rejections.
-    const controller = new AbortController()
-    const timer = setTimeout(() => controller.abort(), quotaPreset.prompt.timeoutMs)
-    try {
-      shouldInstall = await confirm(
-        {
-          message: quotaPreset.prompt.message,
-          default: quotaPreset.prompt.default,
-        },
-        { signal: controller.signal },
-      )
-    } catch (err) {
-      if (err.name !== 'AbortPromptError') throw err
-      shouldInstall = true
-    } finally {
-      clearTimeout(timer)
-    }
-  }
-
-  if (!shouldInstall) {
-    warn('Skipped opencode-quota installation')
-    return { optedIn: false, installed: false }
-  }
-
-  loading('configuring opencode-quota...')
-
-  try {
-    const opencodeDir = path.join(process.cwd(), '.opencode')
-    const opencodePath = path.join(process.cwd(), 'opencode.jsonc')
-    const pkgPath = path.join(opencodeDir, 'package.json')
-
-    // opencode-quota 5.x reads its settings from `opencode-quota/quota-toast.jsonc`
-    // next to the OpenCode config (project root), not from `.opencode/`. The old
-    // `.opencode/opencode-quota/quota-toast.json` is the v4 location and is migrated
-    // below so the settings actually take effect.
-    const quotaDir = path.join(process.cwd(), 'opencode-quota')
-    const quotaPath = path.join(quotaDir, 'quota-toast.jsonc')
-    const legacyQuotaPath = path.join(opencodeDir, 'opencode-quota', 'quota-toast.json')
-
-    let opencodeText = JSON.stringify({ $schema: 'https://opencode.ai/config.json' }, null, 2)
-    let opencode
-    if (await fse.pathExists(opencodePath)) {
-      const errors = []
-      opencodeText = await fse.readFile(opencodePath, 'utf-8')
-      opencode = parseJsonc(opencodeText, errors)
-      if (errors.length > 0 || !opencode || typeof opencode !== 'object' || Array.isArray(opencode)) {
-        throw new Error('opencode.jsonc could not be parsed')
-      }
-    } else {
-      opencode = { $schema: 'https://opencode.ai/config.json' }
-    }
-
-    const pkg = await fse.pathExists(pkgPath)
-      ? await fse.readJson(pkgPath)
-      : {}
-
-    // V2 configures server plugins under `plugins`. A V1 `plugin` array found
-    // here is carried over so the quota entry is not lost when the config
-    // patcher has not run first.
-    const plugins = Array.isArray(opencode.plugins)
-      ? [...opencode.plugins]
-      : Array.isArray(opencode.plugin)
-        ? [...opencode.plugin]
-        : []
-    if (!plugins.includes(PLUGIN)) {
-      plugins.push(PLUGIN)
-      opencodeText = applyEdits(opencodeText, modify(opencodeText, ['plugins'], plugins, {
-        formattingOptions: { insertSpaces: true, tabSize: 2 },
-      }))
-    }
-
-    if (!pkg.dependencies) pkg.dependencies = {}
-    const { name: pkgName, version: pkgVersion } = splitPackageSpec(PLUGIN)
-    if (pkg.dependencies[pkgName] !== pkgVersion) pkg.dependencies[pkgName] = pkgVersion
-
-    await fse.ensureDir(opencodeDir)
-    await fse.writeFile(opencodePath, opencodeText, 'utf-8')
-    await fse.writeJson(pkgPath, pkg, { spaces: 2 })
-
-    // Carry over any existing settings (new location first, then the legacy
-    // v4 file) and layer the recommended defaults on top. The edge defaults
-    // disable toasts and reset notifications and keep slash reports inline.
-    let quotaConfig = {}
-    if (await fse.pathExists(quotaPath)) {
-      quotaConfig = await fse.readJson(quotaPath)
-    } else if (await fse.pathExists(legacyQuotaPath)) {
-      quotaConfig = await fse.readJson(legacyQuotaPath)
-    }
-
-    Object.assign(quotaConfig, quotaPreset.defaults)
-
-    await fse.ensureDir(quotaDir)
-    await fse.writeJson(quotaPath, quotaConfig, { spaces: 2 })
-
-    if (await fse.pathExists(legacyQuotaPath)) {
-      await fse.remove(legacyQuotaPath)
-      const legacyDir = path.dirname(legacyQuotaPath)
-      if ((await fse.readdir(legacyDir)).length === 0) {
-        await fse.remove(legacyDir)
-      }
-      info('Moved opencode-quota settings to opencode-quota/quota-toast.jsonc')
-    }
-
-    success('opencode-quota configured (popups and notifications disabled)')
-    info('Restart OpenCode and run /quota to verify')
-    return { optedIn: true, installed: true }
-  } catch (err) {
-    error(`Failed to configure opencode-quota: ${err.message}`)
-    return { optedIn: true, installed: false }
-  }
-}

package/harness/.opencode/commands/ops-evidence.md

@@ -1,9 +0,0 @@
----
-description: Capture a screenshot (or text summary) of a completed change and post it as a comment on the originating issue or work item.
----
-
-Load the `pc-ops-evidence` skill and execute it.
-
-Input:
-
-$ARGUMENTS