@plainconceptsplatform/agent-harness 2.9.0 → 3.0.2

package/harness/opencode.jsonc

@@ -1,47 +1,36 @@
 {
   "$schema": "https://opencode.ai/config.json",
-  "instructions": [
-    "AGENTS.md"
-  ],
-  "plugin": [
-    "@mohak34/opencode-notifier@0.2.8"
-  ],
   "mcp": {
-    "agent-browser": {
-      "type": "local",
-      "command": ["agent-browser", "mcp", "--tools", "core"],
-      "enabled": true
+    "servers": {
+      "agent-browser": {
+        "type": "local",
+        "command": ["agent-browser", "mcp", "--tools", "core"],
+        "disabled": false
+      }
+    },
+    "timeout": {
+      "catalog": 300000,
+      "execution": 300000
     }
   },
-  "experimental": {
-    "mcp_timeout": 300000
-  },
   "compaction": {
     "auto": true,
-    "prune": true,
-    "reserved": 10000
+    "buffer": 10000
   },
-  "permission": {
-    "question": "allow",
-    "todowrite": "allow",
-    "skill": "allow"
-  },
-  "skills": {
-    "paths": [".agents/skills"]
-  },
-  // build and plan are the only primaries, and plan is the default: a session
-  // starts read-only and you switch to build once you know what to change.
-  // The pc-subagent-tiers plugin
-  // regenerates .opencode/agents/{build,plan}.md from fullstack-engineer.md on
-  // every startup and overrides these two entries with the resolved tier model,
-  // so what is here is only the floor if the plugin cannot run. Every engineer
-  // is mode: subagent and reached through task(), never picked by a human.
+  "permissions": [
+    { "action": "question", "resource": "*", "effect": "allow" },
+    { "action": "skill", "resource": "*", "effect": "allow" }
+  ],
+  "skills": [".agents/skills"],
   "default_agent": "plan",
-  "agent": {
+  "agents": {
     "build": { "mode": "primary" },
     "plan": {
       "mode": "primary",
-      "permission": { "edit": "deny", "task": "deny" }
+      "permissions": [
+        { "action": "edit", "resource": "*", "effect": "deny" },
+        { "action": "subagent", "resource": "*", "effect": "deny" }
+      ]
     }
   }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@plainconceptsplatform/agent-harness",
-  "version": "2.9.0",
+  "version": "3.0.2",
   "description": "Installs the Plain Concepts Platform Harness into any codebase, and keeps it up to date. Wires OpenCode, OpenSpec, codegraph, and agentmemory into a multi-agent workflow that runs on native parallel subagents.",
   "keywords": [
     "opencode",

package/skills/pc-guardrails-generic/SKILL.md

@@ -6,23 +6,28 @@ license: MIT
 
 ## Transitive loads (optimization skills)
 
-The marker sections below name the optimization skills this project selected. Load each one before doing any work.
+The marker sections below name the optimization skills this project selected. Load each before doing any work.
 
 ## Secrets
 
-- Treat `.env` files as write-only: write to them when configuring, and read credentials at runtime from the environment or the secret store.
-- Never put a credential, API key or token in a log line, an output, or a commit in anything but encrypted or template form. Anything printed is in a CI log that outlives the run.
+- Treat `.env` files as write-only: write to them when configuring, read credentials at runtime from the environment or secret store.
+- Never put a credential, API key, or token in a log line, output, or commit in anything but encrypted or template form.
 
 ## Code
 
-- Comments are for WHY, not WHAT. Use them only where the code does something non-obvious or the reason cannot be inferred from context. Past a 10% comment ratio in a file, refactor for clarity instead.
-- Never add a file that collects unrelated things — `constants.js`, `types.ts`, `config.js`, `utils.ts`. One responsibility per file, split by domain or feature (`user-constants.ts`, `order-types.ts`, `auth-config.ts`). A file importing from many unrelated modules is already the symptom.
+- The default is zero comments. Add one only where the code is genuinely non-obvious. Past 10% comment-to-code ratio, refactor for clarity. Never add comments that restate the code, label variables, TODOs without a linked issue, commented-out code, separator banners, or auto-generated docstrings/JSDoc/XML docs unless explicitly asked.
+- Never add a file that collects unrelated things — `constants.js`, `types.ts`, `utils.ts`. One responsibility per file, split by domain. A file importing from many unrelated modules is already the symptom.
 
 ## Temporary files
 
-- Never write outside `$REPO_ROOT`, and never to an operating-system temporary directory: the next step and the next agent cannot see it, and nobody cleans it up. Scratch goes under `$REPO_ROOT/.opencode/.tmp/`, in a task-specific child directory when needed (enforced by pc-system-reminders).
-- Never report a path under `.tmp/` as a deliverable. Copy or move the artifact to its required repository path first.
-- Never leave scratch files behind at the end of a task, unless they are the evidence for a failure you are reporting.
+- Never write outside `$REPO_ROOT` or an OS temp directory: the next agent cannot see it and nobody cleans it up. Scratch goes under `$REPO_ROOT/.opencode/.tmp/` (enforced by pc-system-reminders).
+- Never report a `.tmp/` path as a deliverable. Copy or move the artifact to its repository path first. Never leave scratch files behind unless they are evidence for a failure you are reporting.
+
+## Tests
+
+- Never write more tests than the change requires. A bug fix gets one regression test. A new function gets tests for its public contract, not every internal branch. Never aim for a coverage number.
+- Never test framework or library internals. Test your code's contract, not that EF Core saves a tracked entity.
+- Never generate integration, e2e, or snapshot tests unless explicitly asked. Mock nothing you do not own — use a fake that records state. Never add a test that duplicates a type-check or linter rule.
 
 <!-- PC-GUARDRAILS-RTK-START -->
 <!-- PC-GUARDRAILS-RTK-END -->
@@ -41,7 +46,7 @@ The marker sections below name the optimization skills this project selected. Lo
 
 ## Engineer workflow (when spawned)
 
-The lead put your task IDs and their text in your prompt. Two things about that are not up to you:
+The lead puts your task IDs and their text in your prompt. Two things about that are not up to you:
 
 - Load every skill under your `## Abilities` before you start, guardrails first, one `skill` call per `@skill-name`. Editing, shell and spawning are blocked until you have (pc-system-reminders).
-- Edit only files in your assigned scope, then return a summary: task IDs done, files changed, tests and lint result, decisions made. Then you exit. Never poll for more work, and never claim a task the lead did not give you: the lead spawns with the work in hand, so a worker that waits is a worker that hangs the wave.
+- Edit only files in your assigned scope, then return: task IDs done, files changed, tests and lint result, decisions made. Then exit. Never poll for more work or claim a task the lead did not give you.

package/skills/pc-make-engineer/SKILL.md

@@ -1,59 +1,59 @@
----
-name: pc-make-engineer
-description: Create a custom engineer agent via persona-driven interactive design. Invoked by the /make-engineer command.
-license: MIT
----
-
-Create one file, `.opencode/agents/{persona}-engineer.md`, from the [template](template.md). The research behind it is for choosing the right skills, not for filling the file: expertise notes, architecture, conventions, file maps and workflow steps belong in skills.
-
-## Rules
-
-- Never write the agent file before the user has confirmed the skill set and it is installed. An engineer whose abilities do not exist cannot work.
-- Never write `model:` or `color:`. `pc-subagent-tiers` injects both at startup, so a hand-picked colour is overwritten.
-- Never create `*.build.md`, `*.fast.md`, `*.plan.md`, `build.md` or `plan.md`. The plugin regenerates all of them every startup and anything written there is lost.
-- `mode: subagent`. Engineers are reached through `task()`, and a primary would clutter the two-entry list a human picks from.
-- The only `##` heading is `## Abilities`, and the identity paragraph is two or three sentences carrying no project knowledge.
-- Every `@skill` under `## Abilities` exists in `.agents/skills/` and in `skills-lock.json`. A name that is not installed is skipped rather than blocking the worker, so a typo costs the agent that ability in silence.
-- Project-local installs only: `npx skills add -y ...`, never `-g`.
-- At most five form questions, and only where more than one option was detected. A signal with one option is used without asking.
-
-## Contracts
-
-Personas: `frontend`, `layout`, `backend`, `data`, `devops`, `security`, `mobile`, `api`, `qa`. A persona passed as an argument (`/make-engineer frontend`) or typed by the user is taken as given.
-
-Signals to detect: language, framework, data layer, testing, styling, architecture, i18n, CI/CD, cloud and IaC, monitoring, linting, dependency injection.
-
-Discovery needs `find-skills`, and has no fallback without it:
-
-```bash
-npx skills add -y vercel-labs/skills@find-skills
-```
-
-When `.opencode/agents/{persona}-engineer.md` already exists, ask before touching it:
-
-```json
-{
-  "questions": [
-    {
-      "header": "Overwrite engineer",
-      "question": "An engineer named \"{persona}-engineer\" already exists. Overwrite or cancel?",
-      "options": [
-        { "label": "Overwrite", "description": "Rewrite the file from the template." },
-        { "label": "Cancel", "description": "Stop. Do not modify the existing file." }
-      ]
-    }
-  ]
-}
-```
-
-`fullstack-engineer.md` is the body `pc-subagent-tiers` copies into `build.md` and `plan.md`, so every skill listed there reaches both primaries. Merge into it additively: add only skills it does not already list, put them in the category lines that already exist where they fit, and leave its frontmatter, identity paragraph and existing ability lines alone.
-
-## Flow
-
-1. **Persona.** Ask with the `question` tool unless it arrived as an argument. The answer decides what to detect, what to ask, and which skills to look for.
-2. **Signals.** Read `.opencode/source-roots.json` (if it is missing or empty, ask which directories to scan), then `ARCHITECTURE.md`, `DESIGN.md`, and the manifests (`package.json`, `tsconfig.json`, `*.csproj`, `pyproject.toml`, `go.mod`, `Cargo.toml`). Detect what the persona needs and report the inventory.
-3. **Form.** Present the detected options with the `question` tool, pre-selected and marked `(Recommended)`. For `frontend`, `backend`, `layout` and `api`, one question is architecture and patterns, whose options come from the [signal mapping](signal-mapping.md) tables.
-4. **Skills.** A signal already covered by a skill in `.agents/skills/` or `skills-lock.json` needs no search. Map each remaining signal to a query through the [signal mapping](signal-mapping.md), present the candidates as one multi-select `question` grouped by category (name, one line, `owner/repo`, install count), install what the user confirms, and verify each one landed in both `.agents/skills/` and the lockfile.
-5. **Write** the file from the [template](template.md).
-6. **Merge** the new skills into `fullstack-engineer.md`.
-7. **Report** the file created, the skills installed, the signals with no quality skill, whatever failed, and that opencode has to restart before `pc-subagent-tiers` picks the engineer up.
+---
+name: pc-make-engineer
+description: Create a custom engineer agent via persona-driven interactive design. Invoked by the /make-engineer command.
+license: MIT
+---
+
+Create one file, `.opencode/agents/{persona}-engineer.md`, from the [template](template.md). The research behind it is for choosing the right skills, not for filling the file: expertise notes, architecture, conventions, file maps and workflow steps belong in skills.
+
+## Rules
+
+- Never write the agent file before the user has confirmed the skill set and it is installed. An engineer whose abilities do not exist cannot work.
+- Never write `model:` or `color:`. `pc-subagent-tiers` injects both at startup, so a hand-picked colour is overwritten.
+- Never create `*.build.md`, `*.fast.md`, `*.plan.md`, `build.md` or `plan.md`. The plugin regenerates all of them every startup and anything written there is lost.
+- `mode: subagent`. Engineers are reached through the subagent tool, and a primary would clutter the two-entry list a human picks from.
+- The only `##` heading is `## Abilities`, and the identity paragraph is two or three sentences carrying no project knowledge.
+- Every `@skill` under `## Abilities` exists in `.agents/skills/` and in `skills-lock.json`. A name that is not installed is skipped rather than blocking the worker, so a typo costs the agent that ability in silence.
+- Project-local installs only: `npx skills add -y ...`, never `-g`.
+- At most five form questions, and only where more than one option was detected. A signal with one option is used without asking.
+
+## Contracts
+
+Personas: `frontend`, `layout`, `backend`, `data`, `devops`, `security`, `mobile`, `api`, `qa`. A persona passed as an argument (`/make-engineer frontend`) or typed by the user is taken as given.
+
+Signals to detect: language, framework, data layer, testing, styling, architecture, i18n, CI/CD, cloud and IaC, monitoring, linting, dependency injection.
+
+Discovery needs `find-skills`, and has no fallback without it:
+
+```bash
+npx skills add -y vercel-labs/skills@find-skills
+```
+
+When `.opencode/agents/{persona}-engineer.md` already exists, ask before touching it:
+
+```json
+{
+  "questions": [
+    {
+      "header": "Overwrite engineer",
+      "question": "An engineer named \"{persona}-engineer\" already exists. Overwrite or cancel?",
+      "options": [
+        { "label": "Overwrite", "description": "Rewrite the file from the template." },
+        { "label": "Cancel", "description": "Stop. Do not modify the existing file." }
+      ]
+    }
+  ]
+}
+```
+
+`fullstack-engineer.md` is the body `pc-subagent-tiers` copies into `build.md` and `plan.md`, so every skill listed there reaches both primaries. Merge into it additively: add only skills it does not already list, put them in the category lines that already exist where they fit, and leave its frontmatter, identity paragraph and existing ability lines alone.
+
+## Flow
+
+1. **Persona.** Ask with the `question` tool unless it arrived as an argument. The answer decides what to detect, what to ask, and which skills to look for.
+2. **Signals.** Read `.opencode/source-roots.json` (if it is missing or empty, ask which directories to scan), then `ARCHITECTURE.md`, `DESIGN.md`, and the manifests (`package.json`, `tsconfig.json`, `*.csproj`, `pyproject.toml`, `go.mod`, `Cargo.toml`). Detect what the persona needs and report the inventory.
+3. **Form.** Present the detected options with the `question` tool, pre-selected and marked `(Recommended)`. For `frontend`, `backend`, `layout` and `api`, one question is architecture and patterns, whose options come from the [signal mapping](signal-mapping.md) tables.
+4. **Skills.** A signal already covered by a skill in `.agents/skills/` or `skills-lock.json` needs no search. Map each remaining signal to a query through the [signal mapping](signal-mapping.md), present the candidates as one multi-select `question` grouped by category (name, one line, `owner/repo`, install count), install what the user confirms, and verify each one landed in both `.agents/skills/` and the lockfile.
+5. **Write** the file from the [template](template.md).
+6. **Merge** the new skills into `fullstack-engineer.md`.
+7. **Report** the file created, the skills installed, the signals with no quality skill, whatever failed, and that opencode has to restart before `pc-subagent-tiers` picks the engineer up.

package/skills/pc-make-engineer/template.md

@@ -1,42 +1,36 @@
-# Agent file template
-
-The whole file, with nothing else in it:
-
-```markdown
----
-description: <one sentence naming the persona + top 3-5 detected technologies>
-mode: subagent
-permission:
-  edit: allow
-  bash: allow
-  read: allow
-  glob: allow
-  grep: allow
----
-
-<One paragraph: "You are a {persona} engineer specializing in {top technologies}. You own all work in {scope/files}." Keep it to 2-3 sentences max.>
-
-## Abilities
-- Guardrails: @pc-guardrails-generic, @pc-guardrails-project
-- Development: <@installed-skill-1>, <@installed-skill-2>, ...
-- Testing: <@installed-skill-for-testing>, ...
-- Infrastructure: <@installed-skill-for-devops>, ...
-```
-
-Replace every `<...>` placeholder with real values, and drop any category line with no skills in it (Guardrails always stays). Development is language, framework, UI and DI skills; Testing is test, lint and typecheck skills; Infrastructure is DevOps, CI/CD and cloud skills.
-
-## Description quality bar
-
-`description:` is the matching key for `/plan-apply`: the lead compares a task's domain text against it to pick a specialist, so a vague one gets the wrong engineer spawned.
-
-Bad: `"A frontend engineer for React"`
-
-Good: `"Frontend engineer for Ink 7 + React 19 TUI, FSD architecture, Inversify DI, design tokens, and i18n"`
-
-Name the persona, list the three to five technologies actually detected, one sentence, no padding.
-
-## Identity paragraph
-
-Two or three sentences: who the engineer is, and what files or layers it owns. A knowledge dump here is knowledge the lead cannot reuse and the engineer did not ask for.
-
-Good: `"You are a frontend engineer specializing in terminal UI development with Ink 7 + React 19. You own all work in the FSD layers: src/app/, src/widgets/, src/features/, src/entities/, and src/shared/."`
+# Agent file template
+
+The whole file, with nothing else in it:
+
+```markdown
+---
+description: <one sentence naming the persona + top 3-5 detected technologies>
+mode: subagent
+---
+
+<One paragraph: "You are a {persona} engineer specializing in {top technologies}. You own all work in {scope/files}." Keep it to 2-3 sentences max.>
+
+## Abilities
+- Guardrails: @pc-guardrails-generic, @pc-guardrails-project
+- Development: <@installed-skill-1>, <@installed-skill-2>, ...
+- Testing: <@installed-skill-for-testing>, ...
+- Infrastructure: <@installed-skill-for-devops>, ...
+```
+
+Replace every `<...>` placeholder with real values, and drop any category line with no skills in it (Guardrails always stays). Development is language, framework, UI and DI skills; Testing is test, lint and typecheck skills; Infrastructure is DevOps, CI/CD and cloud skills.
+
+## Description quality bar
+
+`description:` is the matching key for `/plan-apply`: the lead compares a task's domain text against it to pick a specialist, so a vague one gets the wrong engineer spawned.
+
+Bad: `"A frontend engineer for React"`
+
+Good: `"Frontend engineer for Ink 7 + React 19 TUI, FSD architecture, Inversify DI, design tokens, and i18n"`
+
+Name the persona, list the three to five technologies actually detected, one sentence, no padding.
+
+## Identity paragraph
+
+Two or three sentences: who the engineer is, and what files or layers it owns. A knowledge dump here is knowledge the lead cannot reuse and the engineer did not ask for.
+
+Good: `"You are a frontend engineer specializing in terminal UI development with Ink 7 + React 19. You own all work in the FSD layers: src/app/, src/widgets/, src/features/, src/entities/, and src/shared/."`

package/skills/pc-make-guardrails/category-reference.md

@@ -20,7 +20,7 @@ Each rule must be:
 - **Concrete**: "Use `pnpm` not `npm`" not "Use the right package manager".
 - **Evidence-based**: derived from the files and code graph you analyzed. Never invent a rule the project does not state or demonstrate somewhere.
 - **Not enforced elsewhere.** Skip anything the formatter, linter, type checker, test suite, CI gate or a harness plugin already fails the build on. A rule restating `biome.json` is read on every load and changes nothing: the build was going to catch it. Write the rules that nothing but a careful reader would catch.
-- **Not already in `pc-guardrails-generic`.** That skill loads alongside this one, every request. Secrets, comment discipline, scratch-file location and one-responsibility-per-file are its rules, not this file's.
+- **Not already in `pc-guardrails-generic`.** That skill loads alongside this one, every request. Secrets, zero-comment default, scratch-file location, one-responsibility-per-file, minimal-test discipline, and the engineer workflow are its rules, not this file's.
 
 **At most 40 rules, across all categories.** Rank by what a violation costs and cut from the bottom; a category with nothing consequential in it gets no rules at all. This cap is the point of the exercise, not tidiness: compliance falls away as a rule file grows, so the 41st rule does not just cost its own tokens, it dilutes the 40 that matter. If more than 40 survive every bar above, the excess is a sign the project's constraints belong in a linter rule or a CI check instead.
 
@@ -107,6 +107,6 @@ Re-read the output you are about to write. Then:
    - CI workflow steps (`app-ci.yml`, `ci.yml`)
    - GitHub branch protection / required checks. If the build catches it, the rule costs tokens and adds nothing. The only exception is a rule whose enforcement is partial or non-obvious (e.g. architecture tests enforce layering but a developer could still import a namespace through reflection or a transitive dependency — that nuance is worth a rule).
 
-4. **Strip anything already in `pc-guardrails-generic`.** That skill loads on every request alongside this one. Its rules are: secrets discipline, comment discipline (WHY not WHAT, 10% ceiling), scratch-file location, one-responsibility-per-file, and the engineer workflow. Do not restate any of them here.
+4. **Strip anything already in `pc-guardrails-generic`.** That skill loads on every request alongside this one. Its rules are: secrets discipline, zero-comment default (WHY not WHAT, 10% ceiling, no auto-generated docstrings), scratch-file location, one-responsibility-per-file, minimal-test discipline (one regression test per bug, no framework/library tests, no integration/e2e/snapshot unless asked, no mock-assertion of third-party calls), and the engineer workflow. Do not restate any of them here.
 
 5. **Re-count after cutting.** If you are still over 40, you are writing reference material, not constraints. Cut harder.

package/skills/pc-plan-goal/branching.md

@@ -1,30 +1,39 @@
-# Branching procedure
-
-Resolve and record the branch names:
-
-```bash
-START_BRANCH="$(git branch --show-current)"
-DEFAULT_BRANCH="$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')"
-[ -z "$DEFAULT_BRANCH" ] && DEFAULT_BRANCH="main"
-```
-
-Stash uncommitted work when needed and record that the goal stash exists:
-
-```bash
-git stash push -u -m "goal-wip"
-```
-
-Create the feature branch from the synchronized default branch:
-
-```bash
-git switch "$DEFAULT_BRANCH"
-
-if git remote get-url origin >/dev/null 2>&1; then
-  git pull origin "$DEFAULT_BRANCH"
-fi
-
-git switch -c "feature/{slug}"
-BRANCH="$(git branch --show-current)"
-```
-
-Everything through archive happens on `$BRANCH`.
+# Branching procedure
+
+Resolve and record the branch names. If the invoking workflow already placed you on a feature branch (`feature/*`, `fix/*`, etc.), it owns the branch: do not stash, switch, pull, or rename. The sandbox hosting the workflow has no git credentials, so those commands would either corrupt the tree or hang, and the workflow has already cut the branch from the default branch. Treat its result as given.
+
+```bash
+BRANCH="$(git branch --show-current)"
+case "$BRANCH" in
+  feature/*|fix/*|chore/*|docs/*|refactor/*)
+    START_BRANCH="$BRANCH"
+    DEFAULT_BRANCH="$BRANCH"
+    GOAL_STASH="none"
+    ;;
+  *)
+    START_BRANCH="$BRANCH"
+    DEFAULT_BRANCH="$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')"
+    [ -z "$DEFAULT_BRANCH" ] && DEFAULT_BRANCH="main"
+
+    # Stash uncommitted work when needed and record that the goal stash exists.
+    git stash push -u -m "goal-wip"
+    GOAL_STASH="goal-wip"
+
+    # Create the feature branch from the synchronized default branch.
+    git switch "$DEFAULT_BRANCH"
+
+    if git remote get-url origin >/dev/null 2>&1; then
+      git pull origin "$DEFAULT_BRANCH"
+    fi
+
+    git switch -c "feature/{slug}"
+    BRANCH="$(git branch --show-current)"
+    ;;
+esac
+```
+
+Record the branch name and that `feature/{slug}` was applied unconditionally, so downstream phases can restore if they move off it.
+
+Everything through archive happens on `$BRANCH`.
+
+When a later phase renames `$BRANCH` to match the canonical change slug (Phase 3 of `pc-plan-goal`), skip the rename if the workflow already fixed the name. Renaming would call `git branch -m`, which a credentialless sandbox refuses, and the workflow's `create_pull_request` is told to use the branch as named. Detect this by checking that `$BRANCH` already starts with `feature/`; if it does, keep it.

package/harness/.opencode/tui/pc-subagents.tsx

@@ -1,98 +0,0 @@
-/** @jsxImportSource @opentui/solid */
-import type { TuiPlugin, TuiPluginModule } from "@opencode-ai/plugin/tui"
-import { createSignal, For, Show } from "solid-js"
-import { readFile } from "node:fs/promises"
-import { join } from "node:path"
-
-const id = "ob.subagents"
-
-type Row = { id: string; agent: string; model: string; task: string; status: string }
-
-// Renders a live "Subagents" panel in the session sidebar.
-//
-// Server plugins (opencode.json) cannot draw UI, only TUI plugins (tui.json)
-// can, via the `sidebar_content` slot. This panel is fed by the
-// `.opencode/harness-run.json` state file that the `pc-subagent-monitor` server
-// plugin maintains, so the two cooperate: server plugin = data producer,
-// this TUI plugin = renderer.
-const tui: TuiPlugin = async (api) => {
-  const statePath = join(process.cwd(), ".opencode", "harness-run.json")
-  const [rows, setRows] = createSignal<Row[]>([])
-  // Only show live subagents, finished/failed ones are kept in harness-run.json
-  // for recovery but are not navigable targets the user cares about here.
-  // Entries marked stale (left "running" by a crashed process) are not live.
-  const active = () => rows().filter((r) => r.status === "running")
-
-  const refresh = async () => {
-    try {
-      const data = JSON.parse(await readFile(statePath, "utf-8"))
-      const agents = data?.agents ?? {}
-      setRows(
-        Object.entries(agents)
-          .filter(([, a]: [string, any]) => !a?.stale)
-          .map(([sid, a]: [string, any]) => ({
-            id: sid,
-            agent: a?.agent ?? "?",
-            model: a?.model ?? "",
-            task: Array.isArray(a?.tasks) && a.tasks.length ? a.tasks.join(",") : (a?.title ?? ""),
-            status: a?.status ?? "running",
-          })),
-      )
-    } catch (err: any) {
-      // Missing file = genuinely idle. Anything else (transient read/parse
-      // hiccup) keeps the last good rows instead of flashing "idle" mid-run.
-      if (err?.code === "ENOENT") setRows([])
-    }
-  }
-
-  await refresh()
-  // session.updated fires constantly; debounce so we don't re-read the file
-  // on every keystroke-sized event.
-  let timer: ReturnType<typeof setTimeout> | null = null
-  const scheduleRefresh = () => {
-    if (timer) return
-    timer = setTimeout(() => {
-      timer = null
-      void refresh()
-    }, 200)
-  }
-  for (const evt of ["session.created", "session.idle", "session.updated"]) {
-    try {
-      api.event.on(evt as any, scheduleRefresh)
-    } catch {
-      /* event type unavailable on this host, ignore */
-    }
-  }
-
-  api.slots.register({
-    order: 50,
-    slots: {
-      sidebar_content() {
-        return (
-          <box flexDirection="column">
-            <text>Subagents</text>
-            <Show when={active().length === 0}>
-              <text>  idle</text>
-            </Show>
-            <For each={active()}>
-              {(r) => (
-                <box onMouseUp={() => api.route.navigate("session", { sessionID: r.id })}>
-                  <text>
-                    {"▶ "}
-                    {r.agent}
-                    {r.model ? ` · ${r.model}` : ""}
-                    {r.task ? `, ${r.task}` : ""}
-                  </text>
-                </box>
-              )}
-            </For>
-          </box>
-        )
-      },
-    },
-  })
-}
-
-const pluginModule: TuiPluginModule & { id: string } = { id, tui }
-
-export default pluginModule

package/harness/.opencode/tui.json

@@ -1,6 +0,0 @@
-{
-  "$schema": "https://opencode.ai/tui.json",
-  "plugin": [
-    "./tui/pc-subagents.tsx"
-  ]
-}