@plainconceptsplatform/agent-harness 2.7.0 → 2.9.0

package/README.md

@@ -400,7 +400,13 @@ Data the CLI reads lives in two places, split by kind:
 
 Every filename the harness writes into a project is declared once in `cli/utils/paths.js`. Change it there, and remember the OpenCode plugins under `harness/.opencode/plugins/` read those same names at runtime.
 
-`skills/` holds skills *about this CLI*, for agents that have to operate it. See [skills/README.md](./skills/README.md). They are not published to npm, and they are separate from the `pc-*` skills in `harness/` that get installed into your project.
+`skills/` holds both the installable `pc-*` skills and the `agent-harness-cli` skill for agents operating this CLI. See [skills/README.md](./skills/README.md). All of them ship to npm and are discoverable by `npx skills`, so you can install individual skills into any project without the full harness:
+
+```bash
+npx skills add PlainConceptsPlatform/agent-harness
+# or scope to a single skill:
+npx skills add PlainConceptsPlatform/agent-harness --skill pc-ops-ship
+```
 
 ```bash
 git clone https://github.com/PlainConceptsPlatform/agent-harness.git

package/cli/commands/migrate.js

@@ -9,7 +9,7 @@ import { CONFIG_FILE, MANIFEST_FILE, OPENCODE_DIR, USER_CONFIG_FILE } from '../u
 import { exit } from '../utils/process.js'
 
 const __dirname = path.dirname(fileURLToPath(import.meta.url))
-const CONTENT_SKILLS_DIR = path.resolve(__dirname, '../../harness/.agents/skills')
+const CONTENT_SKILLS_DIR = path.resolve(__dirname, '../../skills')
 
 // State files, old name to new. The run-state file is deleted rather than moved:
 // it is live wave state owned by the monitor plugin and is rebuilt on demand.

package/cli/steps/copy/skills.js

@@ -5,7 +5,7 @@ import { info, success } from '../../utils/exec.js'
 import { canUpdateManagedFile, readUpdateManifest, recordManagedFile, writeUpdateManifest } from '../../utils/update-manifest.js'
 
 const __dirname = path.dirname(fileURLToPath(import.meta.url))
-const CONTENT_SKILLS_DIR = path.resolve(__dirname, '../../../harness/.agents/skills')
+const CONTENT_SKILLS_DIR = path.resolve(__dirname, '../../../skills')
 const CONTENT_SKILLS_LOCK = path.resolve(__dirname, '../../../harness/skills-lock.json')
 
 // Userstory skills parse backlog work items: selected by backlogPlatform only.
@@ -28,7 +28,16 @@ export const SKILL_RENAME = {
   'pc-userstory-browser': 'pc-userstory',
 }
 
+// Skills that ship in the source tree but must never be copied into a target
+// project. agent-harness-cli documents the CLI itself for agents working on
+// THIS repo; it has no value in a consumer repo and would clutter .agents/skills.
+// Listed by directory name as read from CONTENT_SKILLS_DIR.
+export const NON_INSTALLABLE_SKILLS = new Set([
+  'agent-harness-cli',
+])
+
 function shouldInstallSkill(skill, backlogPlatform, _repoPlatform) {
+  if (NON_INSTALLABLE_SKILLS.has(skill)) return false
   if (skill in BACKLOG_PLATFORM_SKILLS) return BACKLOG_PLATFORM_SKILLS[skill] === backlogPlatform
   return true
 }
@@ -185,7 +194,8 @@ async function installObSkills(backlogPlatform = 'github', repoPlatform, { force
   // Build the set of skill names we ship (source dirs, after rename).
   // Only these may be removed during forceOverwrite — project-generated
   // skills (pc-merge-risk-assess, custom loops, etc.) must survive.
-  const contentSkills = await fse.readdir(CONTENT_SKILLS_DIR)
+  const contentSkills = (await fse.readdir(CONTENT_SKILLS_DIR))
+    .filter(name => !NON_INSTALLABLE_SKILLS.has(name))
   const shippedNames = new Set()
   for (const skill of contentSkills) {
     const stat = await fse.stat(path.join(CONTENT_SKILLS_DIR, skill)).catch(() => null)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@plainconceptsplatform/agent-harness",
-  "version": "2.7.0",
+  "version": "2.9.0",
   "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",
@@ -29,8 +29,10 @@
   "files": [
     "cli",
     "harness",
+    "skills",
     "!cli/**/*.test.js",
     "!harness/**/*.test.js",
+    "!skills/**/*.test.js",
     "!harness/**/node_modules"
   ],
   "publishConfig": {

package/skills/README.md

@@ -0,0 +1,18 @@
+# skills/
+
+Two kinds of skills live here, both discoverable by `npx skills`:
+
+| Kind | Directories | Purpose |
+| --- | --- | --- |
+| Installable `pc-*` + `browser-automation` | `pc-*`, `browser-automation` | What the CLI copies into a target project under `.agents/skills/` during onboarding. Plain Concepts' own skills. |
+| CLI-self | `agent-harness-cli` | Skills for agents working on THIS CLI repo (driving `npx @plainconceptsplatform/agent-harness`). Never copied into target projects. |
+
+Discoverability: any `SKILL.md` in a subdirectory here is auto-discovered by OpenCode, Claude Code, and `npx skills` (which scans `./skills/` as a recognized project-skill location).
+
+## Using one
+
+Point your agent at the directory, or copy a skill into wherever your tool discovers skills:
+
+```bash
+cp -r skills/agent-harness-cli ~/.claude/skills/
+```

package/skills/agent-harness-cli/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: agent-harness-cli
+description: Drive the agent-harness CLI - install the Plain Concepts Platform Harness into a repository, bring an existing one up to date, set up a teammate's machine, or rerun a single step. Load when asked to install, update, or repair the Platform Harness, when a repo needs AI/agent scaffolding set up, or when a command like `npx @plainconceptsplatform/agent-harness` fails and needs diagnosing.
+license: MIT
+---
+
+# agent-harness CLI
+
+`agent-harness` installs the **Plain Concepts Platform Harness** into a repository and keeps it up to date. The harness is Plain Concepts' own, and it is the set of files agents work from: slash commands, `pc-*` skills (the `pc-` is Plain Concepts), an agent team, OpenCode plugins, an OpenSpec workspace, and generated `ARCHITECTURE.md` and `DESIGN.md`.
+
+Everything runs against the **current working directory**. `cd` into the target repository first; there is no `--path` flag.
+
+## Pick the right verb
+
+Read the repo before running anything. `.opencode/harness.json` is the marker for "harness already installed".
+
+| Situation | Command |
+| --- | --- |
+| No `.opencode/harness.json` | `npx @plainconceptsplatform/agent-harness@latest` (the install wizard) |
+| Harness present, want the latest release's files | `npx @plainconceptsplatform/agent-harness@latest update` |
+| Harness present, new machine or new teammate | `npx @plainconceptsplatform/agent-harness join` |
+| One specific thing needs redoing | a single step command, see below |
+
+Requires Node.js 18+.
+
+## The install wizard is interactive
+
+The wizard asks about source scope, backlog and repository platform, three models, and optional token-optimization tools. **Do not run it in a non-interactive shell.** It will hang or abort. If you cannot present prompts to a human, say so and hand the command to the user rather than trying to drive it.
+
+Everything else (`update`, and the single-step commands other than `platform`, `models`, `optimization`) runs without prompts.
+
+## Single-step commands
+
+Run one step without the full wizard. Each reuses context from `.opencode/harness.json` when it needs to.
+
+```
+clean           Remove pre-existing AI files (AGENTS.md, .cursorrules, CLAUDE.md, ...)
+platform        Choose backlog + repository platform
+copy            Copy agents, skills, commands, docs into the repo
+openspec        Initialize the OpenSpec workspace
+models          Choose plan / build / fast models
+optimization    Configure RTK, quota, Simple English, codegraph, agentmemory, humanizer
+browser         Install agent-browser (npm package + its Chrome for Testing)
+metadata        Rewrite .opencode/harness.json
+```
+
+`metadata` last if you ran several, because it refreshes the config the others read.
+
+## What lands in the repo
+
+```
+.opencode/
+  harness.json            harness config: platform, models, agents.maxConcurrent
+  harness-managed.json    hash per managed file, so update spares your edits
+  harness.user.json       per-developer model override (gitignored)
+  harness-run.json        live subagent wave state (gitignored)
+  commands/               slash commands
+  plugins/                pc-subagent-monitor, pc-subagent-tiers, pc-system-reminders
+  agents/                 fullstack-engineer + user-created *-engineer files
+.agents/skills/           pc-* skills
+AGENTS.md ARCHITECTURE.md DESIGN.md
+```
+
+After a fresh install, the next move is `/repo-initialize` inside OpenCode. That is what generates real `ARCHITECTURE.md` and `DESIGN.md` and activates the agent team. Installing the harness alone does not do it.
+
+## `update` is edit-safe
+
+`update` compares each managed file against the hash recorded in `.opencode/harness-managed.json`. Files you changed by hand are left alone and reported as preserved. Generated skills (`pc-guardrails-project`, `pc-merge-risk-assess`) are never overwritten once populated. So `update` is safe to run repeatedly, and a second consecutive run should report no changes.
+
+## Diagnosing failures
+
+**"This project was set up by opencode-onboard v1".** The repo has v1 state files or `ob-*` skills. v2 renamed both and does not migrate. Re-onboard on a clean branch; do not try to rename the files by hand, because the marker comments inside the installed skills changed too.
+
+**"No config found. Run the wizard first."** `update` or a step needs `.opencode/harness.json` and it is absent. Run the wizard.
+
+**A platform step reports nothing and changes nothing.** Platform content is injected into `<!-- PC-PLATFORM-*-START/END -->` marker pairs. If a marker pair is missing from the target file, injection is skipped silently. Check the markers exist before concluding the step worked.
+
+**Skills missing after install.** Skill installation ends with `npx skills experimental_install --yes`, run once at the end of the optimization step. If it failed, rerun it directly in the repo.
+
+**Platform CLI warnings.** The harness expects `gh` (GitHub), `az` + azure-devops extension (Azure DevOps), `acli` (Jira), `glab` (GitLab), each authenticated. These are warnings, not fatal; the harness installs, but the matching `/ops-*` flows will not work until the CLI is present.
+
+## Rules
+
+- Never edit `.opencode/harness.json` by hand to change models. Use `/make-user-model <tier> <model>` inside OpenCode, or the `models` step.
+- Never commit `harness.user.json` or `harness-run.json`. Both belong in `.opencode/.gitignore`, which `join` verifies.
+- `clean` deletes files. Confirm with the user before running it on a repo that already has AI configuration worth keeping.

package/{harness/.agents/skills → skills}/pc-make-architecture/SKILL.md

@@ -13,6 +13,7 @@ Write `ARCHITECTURE.md` in the project root from what the codebase actually cont
 - Never regenerate over a file that carries a `<!-- Last updated:` footer. That footer is what makes the next run incremental, and a full rewrite silently drops whatever a human added by hand. Read the file first and pick the mode.
 - Never analyze outside `.opencode/source-roots.json` when it exists, plus this repo's own docs and config.
 - The footer is the file's last line, and it is the run's own ISO timestamp: `<!-- Last updated: <ISO date> -->`.
+- Follow the writing rules and self-check defined in the [structure template](structure-template.md). After generating, re-read each section: if a section only describes what exists without stating what breaks when its constraints are violated, rewrite it as constraint-embedded prose or cut it. The file is not written until the self-check passes.
 
 ## Modes
 

package/skills/pc-make-architecture/structure-template.md

@@ -0,0 +1,64 @@
+# ARCHITECTURE.md structure template
+
+Write (or update) `ARCHITECTURE.md` following this structure. Only include sections relevant to the project; omit sections with no evidence.
+
+- Architecture Overview: what the system is, what problem it solves, major architectural style
+- 1. Project Structure: annotated directory tree with purpose of each major directory
+- 2. High-Level System Diagram: Mermaid diagram of actors, services, data stores, external systems
+- 3. Core Components: each major component: name, responsibility, key files, technologies, inputs/outputs
+  - 3.1 Frontend / User Interface (if present)
+  - 3.2 Backend / Server / API (if present)
+  - 3.3 Shared Libraries / Common Code (if present)
+  - 3.4 CLI / Scripts / Automation (if present)
+- 4. Data Flow: request lifecycle, key user journeys, sequence diagram for main runtime flow
+- 5. Data Stores: all persistent storage: type, purpose, schemas, migration approach
+- 6. External Integrations / APIs: each integration: method, config location, auth, failure behavior
+- 7. Key Technologies: full stack summary with architectural relevance of each
+- 8. Deployment & Infrastructure: build artifacts, env config, containerization, CI/CD, hosting
+- 9. Security Architecture: auth, authz, secrets, input validation, trust boundaries
+- 10. Monitoring & Observability: logging, metrics, tracing, error reporting
+- 11. Performance & Scalability: caching, batching, concurrency, known bottlenecks
+- 12. Development Workflow: local setup, install/dev/test/build/lint commands
+- 13. Testing Strategy: test frameworks, locations, coverage gates, gaps
+- 14. Architectural Decisions & Rationale: key choices with evidence and tradeoffs
+- 15. Constraints, Risks, and Technical Debt: tight coupling, TODOs, operational risks
+- 16. Future Considerations: documented roadmap + reasonable recommendations (labeled as such)
+- 17. Project Identification: name, language, type, runtime, date of review, maintainer
+- 18. Glossary / Acronyms: project-specific terms an agent or new developer needs to know
+
+Append at the very end of the file:
+```
+<!-- Last updated: <current ISO timestamp> -->
+```
+
+Rules:
+- Be specific and concrete: include actual directories, files, modules, commands.
+- Mark anything undiscoverable as "Not evident from the repository".
+- Use Mermaid diagrams where helpful.
+- Write as if this document will be committed and maintained over time.
+
+## Writing rules
+
+These rules govern the voice and shape of every section. The ARCHITECTURE.md is the primary artifact an agent reads to understand the system's invariants — it must teach constraints, not just inventory structure. These are enforced by re-reading each section after generation (see the self-check in the skill).
+
+1. **Every section must answer "what breaks if this is violated," not just "what exists."** A section that only describes structure without stating the constraint it protects and the consequence of crossing it is reference material, not architecture. "The system has four modules" is structure; "Modules must not cross-reference each other in Domain or Application, and flow goes through port interfaces or domain events" is a constraint.
+
+2. **Architectural decisions must carry their rationale and what they superseded.** A decision table row that says "Adopt X" is a fact; "Adopt X because Y, supersedes decision Z which assumed W" is a constraint that teaches an agent why a change would be wrong. If a decision was reached after rejecting an alternative, name the alternative and why it was rejected.
+
+3. **State boundaries as prohibitions with consequences.** "Layering is enforced: Api → Application → Domain" is a constraint. "Api → Application → Domain" alone is a dependency list. "Only the Composition namespace in Api reaches Infrastructure" is a constraint; "Api depends on Infrastructure" is a fact. Prefer the constraint form: name the boundary, state who must not cross it, and what breaks when it is crossed.
+
+4. **Include what was tried and rejected, not just what was chosen.** The most valuable architecture decisions are the ones where an alternative was tested and found wanting. A section that says "dynamic sessions were rejected because they accept no volumes, cost more at scale, and are blocked by policy" teaches an agent more than "the engine runs as a container app."
+
+5. **Narrative over inventory.** Describe how the system behaves, what holds it together, and where the seams are. A reader who understands the constraints can infer the structure; a reader who only sees the structure cannot infer the constraints.
+
+## Self-check (before writing the file)
+
+Re-read every section you are about to write. Then:
+
+1. **Identify inventory-only sections.** If a section describes what exists without stating what breaks when its constraints are violated, rewrite it as constraint-embedded prose or cut it.
+
+2. **Check decision rows.** Every row in the decisions table must carry its rationale. If a decision has no "why," it is a fact, not a decision — cut it or find the rationale.
+
+3. **Scan for bare dependency lists.** "Api depends on Application depends on Domain" is a fact. Rewrite it as: name the boundary, state who must not cross it, and what breaks when it is crossed.
+
+4. **Verify rejected alternatives are present where they matter.** If a significant architectural choice was made, the rejected alternative and the reason for rejection should be in the document. An agent that does not know what was rejected will propose it again.

package/{harness/.agents/skills → skills}/pc-make-guardrails/SKILL.md

@@ -14,6 +14,7 @@ Turn this project's own documentation into `.agents/skills/pc-guardrails-project
 - Never invent a rule the project does not state somewhere. A guardrail that came from nowhere is one nobody agreed to, and it will be followed anyway.
 - Never write an empty category. Omit it.
 - Never touch a tier variant (`*-engineer.build.md`, `*-engineer.fast.md`, `*-engineer.plan.md`): they are regenerated from the base templates every startup.
+- Before writing the file, run the self-check defined in the [category reference](category-reference.md): count rules, cut positive phrasing and reference facts, strip anything already enforced by tooling or by `pc-guardrails-generic`, and re-count. The file is not written until the self-check passes.
 
 ## Sources
 

package/{harness/.agents/skills → skills}/pc-make-guardrails/category-reference.md

@@ -24,8 +24,22 @@ Each rule must be:
 
 **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.
 
+## Contrastive example
+
+**Bad** (reference fact — cut):
+> - The SQL Server database name is `myapp`, lowercase.
+
+The agent reads the connection string in config. It costs tokens on every load and the agent cannot "break" it.
+
+**Good** (negative constraint with consequence — keep):
+> - Never add a cached column for a value that is derived from another entity; a later edit to the source leaves the cache stale, and nothing in the build catches it.
+
+The agent could break this without noticing, nothing mechanically enforces it, and the consequence is stated.
+
 ## Skill template
 
+Each section holds constraints an agent could break without noticing, not reference facts. "Naming Conventions" does not mean "list how files are named" — it means "name the conventions whose violation is silent and costly." "Build & Deployment" does not mean "list the build commands" — it means "name the build rules a developer could violate without CI catching it." If a section has only reference facts, omit it entirely.
+
 Write (or update) `.agents/skills/pc-guardrails-project/SKILL.md`:
 
 ```markdown
@@ -71,3 +85,28 @@ license: MIT
 ```
 
 Only include sections that have real rules. Omit empty sections.
+
+## Self-check (before writing the file)
+
+Re-read the output you are about to write. Then:
+
+1. **Count the rules** (every bullet under every section). If there are more than 40, cut from the bottom — rank by what a violation costs and remove the cheapest until you are at or under 40. A rule file past 40 dilutes the ones that matter.
+
+2. **Scan for positive phrasing and reference facts.** Cut or rewrite any rule that:
+   - States what something is named, rather than what must not be named that way and why.
+   - Lists a port number, a database name, a package version, a SDK version, or a connection string. The agent discovers these by reading config.
+   - Describes how something works (e.g. "auth uses a smart scheme that forwards to JWT or Cookies"), rather than what must not be done with it.
+   - Restates a project's tech stack as a list ("Frontend: React 19, Next.js 15, TypeScript…"). That is reference material, not a constraint.
+
+3. **Strip anything already enforced by tooling.** Remove a rule if any of these already fails the build on its violation:
+   - Biome / ESLint / Prettier / Steiger / lint:fsd
+   - NetArchTest / architecture test projects
+   - Semgrep / Trivy / TruffleHog / SBOM checks
+   - Coverage gates (`scripts/check-coverage.mjs`)
+   - `.editorconfig`, `Directory.Build.props`, NuGet audit gates
+   - 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.
+
+5. **Re-count after cutting.** If you are still over 40, you are writing reference material, not constraints. Cut harder.

package/harness/.agents/skills/pc-make-architecture/structure-template.md

@@ -1,38 +0,0 @@
-# ARCHITECTURE.md structure template
-
-Write (or update) `ARCHITECTURE.md` following this structure. Only include sections relevant to the project; omit sections with no evidence.
-
-- Architecture Overview: what the system is, what problem it solves, major architectural style
-- 1. Project Structure: annotated directory tree with purpose of each major directory
-- 2. High-Level System Diagram: Mermaid diagram of actors, services, data stores, external systems
-- 3. Core Components: each major component: name, responsibility, key files, technologies, inputs/outputs
-  - 3.1 Frontend / User Interface (if present)
-  - 3.2 Backend / Server / API (if present)
-  - 3.3 Shared Libraries / Common Code (if present)
-  - 3.4 CLI / Scripts / Automation (if present)
-- 4. Data Flow: request lifecycle, key user journeys, sequence diagram for main runtime flow
-- 5. Data Stores: all persistent storage: type, purpose, schemas, migration approach
-- 6. External Integrations / APIs: each integration: method, config location, auth, failure behavior
-- 7. Key Technologies: full stack summary with architectural relevance of each
-- 8. Deployment & Infrastructure: build artifacts, env config, containerization, CI/CD, hosting
-- 9. Security Architecture: auth, authz, secrets, input validation, trust boundaries
-- 10. Monitoring & Observability: logging, metrics, tracing, error reporting
-- 11. Performance & Scalability: caching, batching, concurrency, known bottlenecks
-- 12. Development Workflow: local setup, install/dev/test/build/lint commands
-- 13. Testing Strategy: test frameworks, locations, coverage gates, gaps
-- 14. Architectural Decisions & Rationale: key choices with evidence and tradeoffs
-- 15. Constraints, Risks, and Technical Debt: tight coupling, TODOs, operational risks
-- 16. Future Considerations: documented roadmap + reasonable recommendations (labeled as such)
-- 17. Project Identification: name, language, type, runtime, date of review, maintainer
-- 18. Glossary / Acronyms: project-specific terms an agent or new developer needs to know
-
-Append at the very end of the file:
-```
-<!-- Last updated: <current ISO timestamp> -->
-```
-
-Rules:
-- Be specific and concrete: include actual directories, files, modules, commands.
-- Mark anything undiscoverable as "Not evident from the repository".
-- Use Mermaid diagrams where helpful.
-- Write as if this document will be committed and maintained over time.

package/harness/.agents/skills/pc-make-evidence-scaffold/SKILL.md

@@ -1,18 +0,0 @@
----
-name: pc-make-evidence-scaffold
-description: DEPRECATED. Visual evidence is now built into pc-ops-evidence using playwright-cli + pnpm run dev. No per-project scaffold is needed. This skill is kept for backward compatibility but should not be used.
-license: MIT
----
-
-# DEPRECATED
-
-This skill is no longer needed. Visual evidence uses a two-phase architecture:
-
-1. **Agent phase:** `pc-ops-evidence` writes a `capturePlan` in `evidence.json` (the agent sandbox cannot run Docker or headless Chromium)
-2. **CI phase:** A separate "Visual evidence" CI workflow reads the capturePlan and captures screenshots on a runner with full Docker and Chrome access
-
-No per-project scaffold, fixture apps, or scenario registries are required. The `pc-ops-evidence` skill handles everything generically.
-
-If you previously ran `/make-evidence-scaffold` and have a `src/visual-evidence/` directory or `visual-evidence` scripts in `package.json`, you can delete them — the new system does not use them.
-
-To capture evidence for a change, run `/ops-evidence`.

package/harness/.agents/skills/pc-make-evidence-scaffold/evidence-contract.md

@@ -1,29 +0,0 @@
-# Evidence contract
-
-Evidence captured by `/ops-evidence` lives at `openspec/changes/archive/<dated>-<id>/evidence/`. A standalone pre-archive capture may use `openspec/changes/<id>/evidence/`, but archive moves it into the archived change before publication. That folder contains only:
-- ordered capture images (`01-{label}.png/webp`, ...) and/or `flow.gif`
-- `evidence.json`: the manifest, schema below.
-
-## version 1 schema
-
-```jsonc
-{
-  "version": 1,
-  "changeId": "...",
-  "required": true,
-  "status": "passed",            // passed | skipped | failed | blocked
-  "assets": [ { "type": "screenshot", "path": "openspec/changes/archive/<dated>-<id>/evidence/01-final.png", "caption": "...", "bytes": 0, "format": "png" } ],
-  "reason": "...",                 // skipped | blocked
-  "failedStep": "...",             // failed
-  "prMarkdown": "## Evidence ..."
-}
-```
-
-## Statuses
-
-- `passed`: evidence required and produced.
-- `skipped`: evidence not required (see decision rule). Exit success.
-- `blocked`: required but could not run (no harness, app won't start, budget exceeded). Not a skip. Surface it.
-- `failed`: a project harness ran and its assertions failed. Surface it.
-
-`blocked` (required but unrunnable) is never treated as a skip.

package/harness/.opencode/commands/make-evidence-scaffold.md

@@ -1,5 +0,0 @@
----
-description: DEPRECATED. Per-project evidence scaffolds are gone; run /ops-evidence instead.
----
-
-Load the `pc-make-evidence-scaffold` skill.