@plainconceptsplatform/agent-harness 2.0.0 → 2.1.0

package/src/content/.agents/skills/pc-make-merge-risk-assess/SKILL.md

@@ -1,70 +1,70 @@
----
-name: pc-make-merge-risk-assess
-description: Generate or update the pc-merge-risk-assess skill from project guardrails and architecture. Produces a PR-level risk assessment that loop recipes can gate automerge on. Invoked by the /make-merge-risk-assess command and the repo-initialize flow.
-license: MIT
----
-
-# Make Merge Risk Assess
-
-Analyze `ARCHITECTURE.md`, the project guardrails skill, and other project files to generate or update an `pc-merge-risk-assess` skill: a checklist of risk indicators that an AI agent evaluates before auto-merging a pull request. When any indicator matches, the agent blocks automerge and leaves the PR for human review with an explanation.
-
-## Steps
-
-1. **Check current state**
-
-   Read `.agents/skills/pc-merge-risk-assess/SKILL.md`. Determine which mode to use:
-   - Does not exist: Generate mode. Create from scratch.
-   - Exists and has a `<!-- Last updated:` footer: Update mode. Incrementally update.
-   - Exists but no timestamp: proceed in Generate mode (full regeneration).
-
-2a. **Generate mode: read source documents**
-
-   Read ALL of the following that exist:
-   - `.agents/skills/pc-guardrails-project/SKILL.md` (primary source — project-specific constraints)
-   - `.agents/skills/pc-guardrails-generic/SKILL.md` (generic safety rules)
-   - `ARCHITECTURE.md` (architecture boundaries, critical paths)
-   - `AGENTS.md` (non-negotiable constraints, verification rules)
-   - `.opencode/harness.json` (platform, concurrency)
-   - CI/CD workflows: `.github/workflows/*`, `azure-pipelines.yml`: whatever exists
-   - Loop recipes: `.loops/recipes/*-loop.yaml` (understand the automerge flow)
-
-   Use file tools to discover risk-critical code paths: `grep` for calculation engines, audit appenders, auth middleware, schema migrations, permission checks, and other sensitive areas.
-
-2b. **Update mode: incremental analysis**
-
-   Extract the `<!-- Last updated: <ISO date> -->` timestamp from the existing skill file. Then:
-   - Read `.agents/skills/pc-guardrails-project/SKILL.md` and check its `<!-- Last updated:` timestamp. If the guardrails haven't changed and ARCHITECTURE.md hasn't changed since the risk skill was last generated, report "Merge risk assessment up to date" and stop.
-   - Run `git log --oneline --since="<date>" -- <relevant config and architecture files>` to find what changed.
-   - If nothing changed: report "Merge risk assessment up to date" and stop.
-   - Update only the affected risk categories. Preserve manually-added risk indicators in unchanged categories.
-   - If changes are pervasive, fall back to Generate mode.
-
-3. **Extract risk indicators**
-
-   From the documents and code analysis, extract concrete, testable risk indicators. Follow the [category reference](category-reference.md) for the full list of categories, indicator quality standards, and the skill file template.
-
-   Each risk indicator must identify a code path or change pattern that, when touched, makes a PR too dangerous to auto-merge. The indicator must be something an AI agent can detect by reading the PR diff.
-
-4. **Write the skill**
-
-   Write (or update) `.agents/skills/pc-merge-risk-assess/SKILL.md` using the template from the [category reference](category-reference.md). Only include sections that have real indicators. Omit empty sections.
-
-5. **Update agents**
-
-   For every `*-engineer.md` in `.opencode/agents/`, add `@pc-merge-risk-assess` to the Agent Workflow ability group (skip if already present). This ensures every engineer can evaluate risk before merge. Use this pattern:
-   ```markdown
-   ## Abilities
-   - Guardrails: @pc-guardrails-generic, @pc-guardrails-project[, ...existing entries unchanged]
-   ...
-   - Development, Agent Workflow: @pc-merge-risk-assess[, ...existing entries unchanged]
-   ```
-
-   If no "Development, Agent Workflow" line exists, create it. Exclude tier variant files (`*-engineer.build.md`, `*-engineer.fast.md`, `*-engineer.plan.md`): they are generated copies; only update the base templates.
-
-6. **Report**
-
-   Tell the user:
-   - Whether the skill was generated or updated (and which categories changed)
-   - Number of risk indicators extracted per category
-   - Number of agent files updated
-   - Tip: "Rerun `/make-merge-risk-assess` any time the architecture or project guardrails change significantly."
+---
+name: pc-make-merge-risk-assess
+description: Generate or update the pc-merge-risk-assess skill from project guardrails and architecture. Produces a PR-level risk assessment that loop recipes can gate automerge on. Invoked by the /make-merge-risk-assess command and the repo-initialize flow.
+license: MIT
+---
+
+# Make Merge Risk Assess
+
+Analyze `ARCHITECTURE.md`, the project guardrails skill, and other project files to generate or update an `pc-merge-risk-assess` skill: a checklist of risk indicators that an AI agent evaluates before auto-merging a pull request. When any indicator matches, the agent blocks automerge and leaves the PR for human review with an explanation.
+
+## Steps
+
+1. **Check current state**
+
+   Read `.agents/skills/pc-merge-risk-assess/SKILL.md`. Determine which mode to use:
+   - Does not exist: Generate mode. Create from scratch.
+   - Exists and has a `<!-- Last updated:` footer: Update mode. Incrementally update.
+   - Exists but no timestamp: proceed in Generate mode (full regeneration).
+
+2a. **Generate mode: read source documents**
+
+   Read ALL of the following that exist:
+   - `.agents/skills/pc-guardrails-project/SKILL.md` (primary source — project-specific constraints)
+   - `.agents/skills/pc-guardrails-generic/SKILL.md` (generic safety rules)
+   - `ARCHITECTURE.md` (architecture boundaries, critical paths)
+   - `AGENTS.md` (non-negotiable constraints, verification rules)
+   - `.opencode/harness.json` (platform, concurrency)
+   - CI/CD workflows: `.github/workflows/*`, `azure-pipelines.yml`: whatever exists
+   - Loop recipes: `.loops/recipes/*-loop.yaml` (understand the automerge flow)
+
+   Use file tools to discover risk-critical code paths: `grep` for calculation engines, audit appenders, auth middleware, schema migrations, permission checks, and other sensitive areas.
+
+2b. **Update mode: incremental analysis**
+
+   Extract the `<!-- Last updated: <ISO date> -->` timestamp from the existing skill file. Then:
+   - Read `.agents/skills/pc-guardrails-project/SKILL.md` and check its `<!-- Last updated:` timestamp. If the guardrails haven't changed and ARCHITECTURE.md hasn't changed since the risk skill was last generated, report "Merge risk assessment up to date" and stop.
+   - Run `git log --oneline --since="<date>" -- <relevant config and architecture files>` to find what changed.
+   - If nothing changed: report "Merge risk assessment up to date" and stop.
+   - Update only the affected risk categories. Preserve manually-added risk indicators in unchanged categories.
+   - If changes are pervasive, fall back to Generate mode.
+
+3. **Extract risk indicators**
+
+   From the documents and code analysis, extract concrete, testable risk indicators. Follow the [category reference](category-reference.md) for the full list of categories, indicator quality standards, and the skill file template.
+
+   Each risk indicator must identify a code path or change pattern that, when touched, makes a PR too dangerous to auto-merge. The indicator must be something an AI agent can detect by reading the PR diff.
+
+4. **Write the skill**
+
+   Write (or update) `.agents/skills/pc-merge-risk-assess/SKILL.md` using the template from the [category reference](category-reference.md). Only include sections that have real indicators. Omit empty sections.
+
+5. **Update agents**
+
+   For every `*-engineer.md` in `.opencode/agents/`, add `@pc-merge-risk-assess` to the Agent Workflow ability group (skip if already present). This ensures every engineer can evaluate risk before merge. Use this pattern:
+   ```markdown
+   ## Abilities
+   - Guardrails: @pc-guardrails-generic, @pc-guardrails-project[, ...existing entries unchanged]
+   ...
+   - Development, Agent Workflow: @pc-merge-risk-assess[, ...existing entries unchanged]
+   ```
+
+   If no "Development, Agent Workflow" line exists, create it. Exclude tier variant files (`*-engineer.build.md`, `*-engineer.fast.md`, `*-engineer.plan.md`): they are generated copies; only update the base templates.
+
+6. **Report**
+
+   Tell the user:
+   - Whether the skill was generated or updated (and which categories changed)
+   - Number of risk indicators extracted per category
+   - Number of agent files updated
+   - Tip: "Rerun `/make-merge-risk-assess` any time the architecture or project guardrails change significantly."

package/src/content/.agents/skills/pc-make-merge-risk-assess/category-reference.md

@@ -1,98 +1,98 @@
-# Merge risk assessment category reference
-
-From the project guardrails, architecture, and code analysis, extract concrete, testable risk indicators in these categories. Only include a category if you found real evidence for it.
-
-- **Calculation integrity**: changes to pricing, quoting, or calculation engines; modifications to formula inputs, salary tables, assumptions, or margin waterfalls. Any file under a calculation or quoting namespace is a risk indicator.
-- **Audit & compliance**: modifications to audit appenders, audit log storage, hash-chaining, or tamper-evident mechanisms. Any change that could affect regulatory traceability.
-- **Authentication & authorization**: changes to auth middleware, permission checks, role definitions, token issuance, or session management. Changes to `.RequirePermission()` calls or permission seed data.
-- **Data schema & migration**: EF Core entity changes, new migrations, column type changes, constraint additions/removals, or seed data modifications. Schema changes are always risky because they affect production data.
-- **Reference data versioning**: changes to effective-dated configuration, salary bands, assumptions, or any "magic number" that affects calculations. Changes to versioning or snapshot logic.
-- **Cross-boundary violations**: imports that break the layering direction (e.g. Domain referencing Application, Application referencing ASP.NET), cross-context data access bypassing ports.
-- **Security surface**: new endpoints without authorization, input validation removal, secrets exposure, dependency version downgrades, or changes to security scanning configuration.
-- **Financial correctness**: any change that could produce incorrect monetary values, incorrect tax calculations, incorrect currency handling, or rounding changes. Money is `decimal` — changes to precision or conversion logic are risk indicators.
-- **State machine transitions**: modifications to entity lifecycle transitions (e.g. quote status flow, approval gates, sign-off logic). Breaking a state machine can leave data in unrecoverable states.
-- **Integration contracts**: changes to external API contracts, webhook payloads, or CRM integration ports. Breaking integrations can cascade to downstream systems.
-
-Each indicator must be:
-- **Concrete**: "Changes to `QuoteCalculator.Calculate`" not "Changes to important calculations"
-- **Evidence-based**: derive from the project guardrails, architecture, and actual code paths
-- **Detectable**: an AI agent can find it by reading the PR diff (file paths, class names, method names, import changes)
-- **Exclusive**: do not duplicate indicators across categories — each belongs in its primary category
-
-## Skill template
-
-Write (or update) `.agents/skills/pc-merge-risk-assess/SKILL.md`:
-
-```markdown
----
-name: pc-merge-risk-assess
-description: Evaluate a pull request for merge risk. Load when a loop recipe or agent needs to decide whether a PR is safe to auto-merge or requires human review. Produces a structured risk assessment with a binary outcome and reasoning.
-license: MIT
----
-
-# Merge Risk Assessment
-
-> Auto-generated by `/make-merge-risk-assess`. Regenerate when architecture or guardrails change.
-
-## Purpose
-
-Determine whether a pull request is safe to auto-merge or requires human review. This skill is loaded by AI agents in loop recipes (e.g. `dev-assess-risk`) before merging. The agent inspects the PR diff and evaluates each risk indicator below.
-
-## Output contract
-
-On completion, produce a single JSON object on stdout:
-
-```json
-{"riskLevel":"safe"|"risky","reason":"<one-sentence explanation if risky, or 'No risk indicators detected' if safe>"}
-```
-
-- `riskLevel: "risky"` → exit non-zero. The loop recipe routes to the "leave for human review" path.
-- `riskLevel: "safe"` → exit zero. The loop recipe routes to the automerge path.
-
-## Risk indicators
-
-### Calculation Integrity
-- <indicator: file path, class, or method pattern>
-- <indicator>
-
-### Audit & Compliance
-- <indicator>
-
-### Authentication & Authorization
-- <indicator>
-
-### Data Schema & Migration
-- <indicator>
-
-### Reference Data Versioning
-- <indicator>
-
-### Cross-Boundary Violations
-- <indicator>
-
-### Security Surface
-- <indicator>
-
-### Financial Correctness
-- <indicator>
-
-### State Machine Transitions
-- <indicator>
-
-### Integration Contracts
-- <indicator>
-
-## Evaluation rules
-
-1. **Load `@pc-guardrails-project` first.** Every non-negotiable constraint in the project guardrails is a potential risk indicator. If a change violates or weakens any guardrail, the outcome is `risky`.
-2. **Inspect the full PR diff** using `gh pr diff <url>`. Do not guess based on the PR title or description alone.
-3. **Check each risk indicator** against the diff. A single matching indicator is sufficient to flag as `risky`.
-4. **When risky, explain why.** The `reason` field must name the specific indicator that matched and the files involved. Do not give vague explanations.
-5. **Do not second-guess the developer.** If the changes look intentional and no indicator matches, classify as `safe`. The purpose is to catch dangerous changes, not to block all non-trivial work.
-6. **Pure additions are lower risk.** New files, new endpoints with authorization, new tests, new UI components that don't touch existing critical paths are generally safe unless they introduce schema changes or cross-boundary imports.
-7. **Refactors within a single layer are generally safe.** Renaming, extracting methods, or reorganizing within the same bounded context and same architectural layer rarely triggers a risk indicator unless the refactor changes behavior.
-
-<!-- Last updated: <current ISO timestamp> -->
-```
-
-Only include sections that have real indicators. Omit empty sections and their headers.
+# Merge risk assessment category reference
+
+From the project guardrails, architecture, and code analysis, extract concrete, testable risk indicators in these categories. Only include a category if you found real evidence for it.
+
+- **Calculation integrity**: changes to pricing, quoting, or calculation engines; modifications to formula inputs, salary tables, assumptions, or margin waterfalls. Any file under a calculation or quoting namespace is a risk indicator.
+- **Audit & compliance**: modifications to audit appenders, audit log storage, hash-chaining, or tamper-evident mechanisms. Any change that could affect regulatory traceability.
+- **Authentication & authorization**: changes to auth middleware, permission checks, role definitions, token issuance, or session management. Changes to `.RequirePermission()` calls or permission seed data.
+- **Data schema & migration**: EF Core entity changes, new migrations, column type changes, constraint additions/removals, or seed data modifications. Schema changes are always risky because they affect production data.
+- **Reference data versioning**: changes to effective-dated configuration, salary bands, assumptions, or any "magic number" that affects calculations. Changes to versioning or snapshot logic.
+- **Cross-boundary violations**: imports that break the layering direction (e.g. Domain referencing Application, Application referencing ASP.NET), cross-context data access bypassing ports.
+- **Security surface**: new endpoints without authorization, input validation removal, secrets exposure, dependency version downgrades, or changes to security scanning configuration.
+- **Financial correctness**: any change that could produce incorrect monetary values, incorrect tax calculations, incorrect currency handling, or rounding changes. Money is `decimal` — changes to precision or conversion logic are risk indicators.
+- **State machine transitions**: modifications to entity lifecycle transitions (e.g. quote status flow, approval gates, sign-off logic). Breaking a state machine can leave data in unrecoverable states.
+- **Integration contracts**: changes to external API contracts, webhook payloads, or CRM integration ports. Breaking integrations can cascade to downstream systems.
+
+Each indicator must be:
+- **Concrete**: "Changes to `QuoteCalculator.Calculate`" not "Changes to important calculations"
+- **Evidence-based**: derive from the project guardrails, architecture, and actual code paths
+- **Detectable**: an AI agent can find it by reading the PR diff (file paths, class names, method names, import changes)
+- **Exclusive**: do not duplicate indicators across categories — each belongs in its primary category
+
+## Skill template
+
+Write (or update) `.agents/skills/pc-merge-risk-assess/SKILL.md`:
+
+```markdown
+---
+name: pc-merge-risk-assess
+description: Evaluate a pull request for merge risk. Load when a loop recipe or agent needs to decide whether a PR is safe to auto-merge or requires human review. Produces a structured risk assessment with a binary outcome and reasoning.
+license: MIT
+---
+
+# Merge Risk Assessment
+
+> Auto-generated by `/make-merge-risk-assess`. Regenerate when architecture or guardrails change.
+
+## Purpose
+
+Determine whether a pull request is safe to auto-merge or requires human review. This skill is loaded by AI agents in loop recipes (e.g. `dev-assess-risk`) before merging. The agent inspects the PR diff and evaluates each risk indicator below.
+
+## Output contract
+
+On completion, produce a single JSON object on stdout:
+
+```json
+{"riskLevel":"safe"|"risky","reason":"<one-sentence explanation if risky, or 'No risk indicators detected' if safe>"}
+```
+
+- `riskLevel: "risky"` → exit non-zero. The loop recipe routes to the "leave for human review" path.
+- `riskLevel: "safe"` → exit zero. The loop recipe routes to the automerge path.
+
+## Risk indicators
+
+### Calculation Integrity
+- <indicator: file path, class, or method pattern>
+- <indicator>
+
+### Audit & Compliance
+- <indicator>
+
+### Authentication & Authorization
+- <indicator>
+
+### Data Schema & Migration
+- <indicator>
+
+### Reference Data Versioning
+- <indicator>
+
+### Cross-Boundary Violations
+- <indicator>
+
+### Security Surface
+- <indicator>
+
+### Financial Correctness
+- <indicator>
+
+### State Machine Transitions
+- <indicator>
+
+### Integration Contracts
+- <indicator>
+
+## Evaluation rules
+
+1. **Load `@pc-guardrails-project` first.** Every non-negotiable constraint in the project guardrails is a potential risk indicator. If a change violates or weakens any guardrail, the outcome is `risky`.
+2. **Inspect the full PR diff** using `gh pr diff <url>`. Do not guess based on the PR title or description alone.
+3. **Check each risk indicator** against the diff. A single matching indicator is sufficient to flag as `risky`.
+4. **When risky, explain why.** The `reason` field must name the specific indicator that matched and the files involved. Do not give vague explanations.
+5. **Do not second-guess the developer.** If the changes look intentional and no indicator matches, classify as `safe`. The purpose is to catch dangerous changes, not to block all non-trivial work.
+6. **Pure additions are lower risk.** New files, new endpoints with authorization, new tests, new UI components that don't touch existing critical paths are generally safe unless they introduce schema changes or cross-boundary imports.
+7. **Refactors within a single layer are generally safe.** Renaming, extracting methods, or reorganizing within the same bounded context and same architectural layer rarely triggers a risk indicator unless the refactor changes behavior.
+
+<!-- Last updated: <current ISO timestamp> -->
+```
+
+Only include sections that have real indicators. Omit empty sections and their headers.

package/src/content/.agents/skills/pc-make-user-model/SKILL.md

@@ -1,66 +1,66 @@
----
-name: pc-make-user-model
-description: Set the model for a tier (plan, build, or fast). Team-wide or user-local override. Invoked by the /make-user-model command.
-license: MIT
----
-Set the concrete model for one tier. Writes to `models` in either the team config (shared, git-tracked) or a user-local override (gitignored).
-
-Usage:
-
-```
-/make-user-model <tier> <model>
-/make-user-model user <tier> <model>
-```
-
-- `user`: optional prefix. If present, writes to `.opencode/harness.user.json` (gitignored, overrides team config for this machine only). If absent, writes to `.opencode/harness.json` (shared with the team).
-- `<tier>`: one of `plan`, `build`, `fast`.
-- `<model>`: a fully-qualified model id (e.g. `opencode/big-pickle`) OR the keyword `current` to use the model active in this session.
-
-Arguments: `$ARGUMENTS`
-
-Steps
-
-1. Parse `$ARGUMENTS`** by whitespace.
-   - If first token is `user`: `isUser = true`, `<tier>` = second token, `<model>` = third token.
-   - Otherwise: `isUser = false`, `<tier>` = first token, `<model>` = second token.
-   - If `$ARGUMENTS` is empty: read both `.opencode/harness.json` and `.opencode/harness.user.json` and show the current `models` from each (team first, user override second), then show the usage above. Change nothing.
-   - If `<tier>` is not exactly one of `plan` / `build` / `fast`, or `<model>` is missing: print the usage and stop. Change nothing.
-
-2. **Resolve `<model>`:**
-   - If it is the literal `current`: use the model id visible in the opencode status line for this session. Use only the model id shown there, not a guessed value.
-   - Otherwise use the value verbatim. It must look like `provider/model-id`. If it contains no `/`, warn that it looks malformed and call the `question` tool to confirm before writing:
-
-     ```json
-     {
-       "questions": [
-         {
-           "header": "Malformed model id",
-           "question": "\"<model>\" doesn't look like a valid model id (expected provider/model-id). Write it anyway?",
-           "options": [
-             { "label": "yes", "description": "Write the value as-is to the config file." },
-             { "label": "no", "description": "Cancel. Do not write anything." }
-           ]
-         }
-       ]
-     }
-     ```
-
-     Only proceed to write if the user answers `yes`.
-
-3. Determine target file.
-   - `isUser = false` -> `.opencode/harness.json` (team). If it does not exist, stop and tell the user onboarding has not generated it yet.
-   - `isUser = true` -> `.opencode/harness.user.json` (user override). If it does not exist, create it with `{ "models": {} }`.
-
-4. Update the config. Read the target file, set `models.<tier>` to the resolved model id (create `models` if absent). Do not touch any other field. Preserve the existing 2-space JSON formatting, then write the file back.
-
-5. Confirm:
-
-   ```
-   <team|user> config updated
-     <tier> model -> <resolved-id>
-     file: <path written>
-   ```
-
-   Restart opencode for the change to take effect. The `pc-subagent-tiers` plugin reads the model configs at startup and injects tier-suffixed agent variants (`<engineer>.<tier>`) into the live config. After restart, `/plan-apply` will spawn agents on the new model.
-
-This command edits `harness.json` (team) or `harness.user.json` (user) only. It never modifies agent files, `opencode.json`, or `tasks.md`. Tier variants are generated in-memory by the `pc-subagent-tiers` plugin at startup: no file re-stamping needed.
+---
+name: pc-make-user-model
+description: Set the model for a tier (plan, build, or fast). Team-wide or user-local override. Invoked by the /make-user-model command.
+license: MIT
+---
+Set the concrete model for one tier. Writes to `models` in either the team config (shared, git-tracked) or a user-local override (gitignored).
+
+Usage:
+
+```
+/make-user-model <tier> <model>
+/make-user-model user <tier> <model>
+```
+
+- `user`: optional prefix. If present, writes to `.opencode/harness.user.json` (gitignored, overrides team config for this machine only). If absent, writes to `.opencode/harness.json` (shared with the team).
+- `<tier>`: one of `plan`, `build`, `fast`.
+- `<model>`: a fully-qualified model id (e.g. `opencode/big-pickle`) OR the keyword `current` to use the model active in this session.
+
+Arguments: `$ARGUMENTS`
+
+Steps
+
+1. Parse `$ARGUMENTS`** by whitespace.
+   - If first token is `user`: `isUser = true`, `<tier>` = second token, `<model>` = third token.
+   - Otherwise: `isUser = false`, `<tier>` = first token, `<model>` = second token.
+   - If `$ARGUMENTS` is empty: read both `.opencode/harness.json` and `.opencode/harness.user.json` and show the current `models` from each (team first, user override second), then show the usage above. Change nothing.
+   - If `<tier>` is not exactly one of `plan` / `build` / `fast`, or `<model>` is missing: print the usage and stop. Change nothing.
+
+2. **Resolve `<model>`:**
+   - If it is the literal `current`: use the model id visible in the opencode status line for this session. Use only the model id shown there, not a guessed value.
+   - Otherwise use the value verbatim. It must look like `provider/model-id`. If it contains no `/`, warn that it looks malformed and call the `question` tool to confirm before writing:
+
+     ```json
+     {
+       "questions": [
+         {
+           "header": "Malformed model id",
+           "question": "\"<model>\" doesn't look like a valid model id (expected provider/model-id). Write it anyway?",
+           "options": [
+             { "label": "yes", "description": "Write the value as-is to the config file." },
+             { "label": "no", "description": "Cancel. Do not write anything." }
+           ]
+         }
+       ]
+     }
+     ```
+
+     Only proceed to write if the user answers `yes`.
+
+3. Determine target file.
+   - `isUser = false` -> `.opencode/harness.json` (team). If it does not exist, stop and tell the user onboarding has not generated it yet.
+   - `isUser = true` -> `.opencode/harness.user.json` (user override). If it does not exist, create it with `{ "models": {} }`.
+
+4. Update the config. Read the target file, set `models.<tier>` to the resolved model id (create `models` if absent). Do not touch any other field. Preserve the existing 2-space JSON formatting, then write the file back.
+
+5. Confirm:
+
+   ```
+   <team|user> config updated
+     <tier> model -> <resolved-id>
+     file: <path written>
+   ```
+
+   Restart opencode for the change to take effect. The `pc-subagent-tiers` plugin reads the model configs at startup and injects tier-suffixed agent variants (`<engineer>.<tier>`) into the live config. After restart, `/plan-apply` will spawn agents on the new model.
+
+This command edits `harness.json` (team) or `harness.user.json` (user) only. It never modifies agent files, `opencode.json`, or `tasks.md`. Tier variants are generated in-memory by the `pc-subagent-tiers` plugin at startup: no file re-stamping needed.