@plainconceptsplatform/workflows 1.13.1 → 1.14.0

package/loops/templates/issues/bug_report.yml

@@ -1,109 +1,109 @@
-name: Bug report
-description: Report a defect
-labels: ["bug"]
-body:
-  - type: markdown
-    attributes:
-      value: |
-        Thanks for reporting. Do **not** include real secrets or production data use placeholders.
-
-        For security vulnerabilities, contact the team directly instead of filing a public issue.
-  - type: dropdown
-    id: severity
-    attributes:
-      label: Severity
-      options:
-        - Production-down / data loss
-        - Major broken core flow
-        - Minor broken edge case
-        - Cosmetic / polish
-    validations:
-      required: true
-  - type: dropdown
-    id: frequency
-    attributes:
-      label: Frequency
-      description: How often does this happen?
-      options:
-        - Always
-        - Intermittent
-        - Only once
-    validations:
-      required: true
-  - type: textarea
-    id: what-happened
-    attributes:
-      label: What happened?
-      description: A clear description of the bug and its impact.
-    validations:
-      required: true
-  - type: textarea
-    id: repro
-    attributes:
-      label: Steps to reproduce
-      description: How can a maintainer reproduce it?
-      placeholder: |
-        1. Go to ...
-        2. Do ...
-        3. See error
-    validations:
-      required: true
-  - type: textarea
-    id: expected
-    attributes:
-      label: Expected behavior
-    validations:
-      required: true
-  - type: dropdown
-    id: area
-    attributes:
-      label: Where does it occur?
-      options:
-        - Backend
-        - Frontend
-        - Both
-        - CLI / tooling
-        - Configuration / deployment
-        - Documentation
-        - Other
-    validations:
-      required: true
-  - type: textarea
-    id: acceptance
-    attributes:
-      label: Acceptance criteria
-      description: How will we know it's fixed? A checklist a reviewer can verify (include the test that should turn green).
-      placeholder: |
-        - [ ] ...
-        - [ ] A test that fails before the fix and passes after
-    validations:
-      required: false
-  - type: textarea
-    id: open-questions
-    attributes:
-      label: Open questions
-      description: Decisions a maintainer must make before this can be planned. Leave blank if none.
-    validations:
-      required: false
-  - type: textarea
-    id: environment
-    attributes:
-      label: Environment
-      description: Local vs deployed, branch/commit, OS, runtime versions if relevant.
-    validations:
-      required: false
-  - type: textarea
-    id: logs
-    attributes:
-      label: Logs / screenshots
-      description: Paste relevant logs or screenshots. Redact secrets and PII.
-      render: shell
-    validations:
-      required: false
-  - type: textarea
-    id: related
-    attributes:
-      label: Related links
-      description: Links to related issues, PRs, discussions, or docs. Leave blank if none.
-    validations:
-      required: false
+name: Bug report
+description: Report a defect
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for reporting. Do **not** include real secrets or production data use placeholders.
+
+        For security vulnerabilities, contact the team directly instead of filing a public issue.
+  - type: dropdown
+    id: severity
+    attributes:
+      label: Severity
+      options:
+        - Production-down / data loss
+        - Major broken core flow
+        - Minor broken edge case
+        - Cosmetic / polish
+    validations:
+      required: true
+  - type: dropdown
+    id: frequency
+    attributes:
+      label: Frequency
+      description: How often does this happen?
+      options:
+        - Always
+        - Intermittent
+        - Only once
+    validations:
+      required: true
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened?
+      description: A clear description of the bug and its impact.
+    validations:
+      required: true
+  - type: textarea
+    id: repro
+    attributes:
+      label: Steps to reproduce
+      description: How can a maintainer reproduce it?
+      placeholder: |
+        1. Go to ...
+        2. Do ...
+        3. See error
+    validations:
+      required: true
+  - type: textarea
+    id: expected
+    attributes:
+      label: Expected behavior
+    validations:
+      required: true
+  - type: dropdown
+    id: area
+    attributes:
+      label: Where does it occur?
+      options:
+        - Backend
+        - Frontend
+        - Both
+        - CLI / tooling
+        - Configuration / deployment
+        - Documentation
+        - Other
+    validations:
+      required: true
+  - type: textarea
+    id: acceptance
+    attributes:
+      label: Acceptance criteria
+      description: How will we know it's fixed? A checklist a reviewer can verify (include the test that should turn green).
+      placeholder: |
+        - [ ] ...
+        - [ ] A test that fails before the fix and passes after
+    validations:
+      required: false
+  - type: textarea
+    id: open-questions
+    attributes:
+      label: Open questions
+      description: Decisions a maintainer must make before this can be planned. Leave blank if none.
+    validations:
+      required: false
+  - type: textarea
+    id: environment
+    attributes:
+      label: Environment
+      description: Local vs deployed, branch/commit, OS, runtime versions if relevant.
+    validations:
+      required: false
+  - type: textarea
+    id: logs
+    attributes:
+      label: Logs / screenshots
+      description: Paste relevant logs or screenshots. Redact secrets and PII.
+      render: shell
+    validations:
+      required: false
+  - type: textarea
+    id: related
+    attributes:
+      label: Related links
+      description: Links to related issues, PRs, discussions, or docs. Leave blank if none.
+    validations:
+      required: false

package/loops/templates/issues/feature_request.yml

@@ -1,75 +1,75 @@
-name: Feature request
-description: Propose a small improvement or new capability
-labels: ["enhancement"]
-body:
-  - type: markdown
-    attributes:
-      value: |
-        This template is for small, well-scoped improvements a focused
-        enhancement, a missing convenience, a quality-of-life fix.
-
-        For large features, architecture changes, or cross-cutting work,
-        open a planning issue or an ADR instead.
-
-        Do **not** include real secrets or production data use placeholders.
-  - type: dropdown
-    id: scope
-    attributes:
-      label: Scope
-      description: How big is this change? If it doesn't fit Small or Medium, use a planning issue instead.
-      options:
-        - Small a single file or component, no refactoring
-        - Medium touches a few files or a feature area, may need minor refactoring
-    validations:
-      required: true
-  - type: textarea
-    id: current-behavior
-    attributes:
-      label: Current behavior
-      description: How does it work today? Describe the existing behavior or limitation.
-    validations:
-      required: true
-  - type: textarea
-    id: problem
-    attributes:
-      label: Problem / motivation
-      description: What user or business need does this address? Why is the current behavior a problem?
-    validations:
-      required: true
-  - type: textarea
-    id: proposal
-    attributes:
-      label: Proposed solution
-      description: What would you like to happen?
-    validations:
-      required: true
-  - type: textarea
-    id: alternatives
-    attributes:
-      label: Alternatives considered
-    validations:
-      required: false
-  - type: textarea
-    id: acceptance
-    attributes:
-      label: Acceptance criteria
-      description: A checklist a reviewer can verify when this is done (include the tests).
-      placeholder: |
-        - [ ] ...
-        - [ ] Tests
-    validations:
-      required: false
-  - type: textarea
-    id: open-questions
-    attributes:
-      label: Open questions
-      description: Decisions a maintainer must make before this can be planned. Leave blank if none.
-    validations:
-      required: false
-  - type: textarea
-    id: related
-    attributes:
-      label: Related links
-      description: Links to related issues, PRs, discussions, or docs. Leave blank if none.
-    validations:
-      required: false
+name: Feature request
+description: Propose a small improvement or new capability
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        This template is for small, well-scoped improvements a focused
+        enhancement, a missing convenience, a quality-of-life fix.
+
+        For large features, architecture changes, or cross-cutting work,
+        open a planning issue or an ADR instead.
+
+        Do **not** include real secrets or production data use placeholders.
+  - type: dropdown
+    id: scope
+    attributes:
+      label: Scope
+      description: How big is this change? If it doesn't fit Small or Medium, use a planning issue instead.
+      options:
+        - Small a single file or component, no refactoring
+        - Medium touches a few files or a feature area, may need minor refactoring
+    validations:
+      required: true
+  - type: textarea
+    id: current-behavior
+    attributes:
+      label: Current behavior
+      description: How does it work today? Describe the existing behavior or limitation.
+    validations:
+      required: true
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem / motivation
+      description: What user or business need does this address? Why is the current behavior a problem?
+    validations:
+      required: true
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed solution
+      description: What would you like to happen?
+    validations:
+      required: true
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives considered
+    validations:
+      required: false
+  - type: textarea
+    id: acceptance
+    attributes:
+      label: Acceptance criteria
+      description: A checklist a reviewer can verify when this is done (include the tests).
+      placeholder: |
+        - [ ] ...
+        - [ ] Tests
+    validations:
+      required: false
+  - type: textarea
+    id: open-questions
+    attributes:
+      label: Open questions
+      description: Decisions a maintainer must make before this can be planned. Leave blank if none.
+    validations:
+      required: false
+  - type: textarea
+    id: related
+    attributes:
+      label: Related links
+      description: Links to related issues, PRs, discussions, or docs. Leave blank if none.
+    validations:
+      required: false

package/loops/workflows/agent-implement.md

@@ -6,12 +6,12 @@ env:
   # so it names its model here. `model:` below only satisfies the compiler. A repository may
   # change it to any model its opencode.ci.json declares.
   AGENT_LEAD_MODEL: "forge/glm-5-2"
-  # Every harness tier (plan, build, fast) on one model the CI's Forge account is granted.
-  # harness.json names quasar-438b and carina-60b, which that account is not granted: Pliny-Bot
-  # #823's build tasks failed on quasar. Empty runs the tiers harness.json names.
-  AGENT_TIER_MODEL: "plainconcepts/glm-5-2"
-  # The fast tier alone, while the CI's Forge account is not granted carina-60b.
-  AGENT_FAST_MODEL: "plainconcepts/glm-5-2"
+  # Let harness.json drive the tiers: plan=glm-5-3, build/fast=glm-5-2. A repository
+  # whose CI account is not granted a tier model can still pin every tier to one
+  # model by setting AGENT_TIER_MODEL.
+  AGENT_TIER_MODEL: ""
+  # Empty: harness.json already names glm-5-2 for fast.
+  AGENT_FAST_MODEL: ""
   VERIFY_COMMANDS: ""
   REPO_RULES: "Implement only the selected issue. Follow repository documentation and existing conventions. Do not weaken tests, lower coverage thresholds, or bypass checks."
   # Split out of REPO_RULES because one field asked to carry architecture, testing, coverage and
@@ -770,13 +770,14 @@ timeout-minutes: 180
 
    1. `pc-plan-goal`, then Phase 0 as it describes.
 
-   **Propose and archive run in the `planner` agent, not in this session.** Spawn it with the
-   task tool (`subagent_type: planner`) and a prompt that names the skill to load
+   **Propose and archive run in the `planner-sub` agent, not in this session.** Spawn it with the
+   task tool (`subagent_type: planner-sub`) and a prompt that names the skill to load
    (`pc-plan-propose` or `pc-plan-archive`), the issue context path above, the branch, and that it
-   runs in autonomous mode with no one to ask. `planner` runs on the repository's plan model, which
-   is stronger than this session's, and these two steps decide the whole change. Wait for it in the
-   same turn, then continue with the next phase yourself. Only when no `planner` agent exists
-   (agent-harness older than 3.4.0) load the skill here instead.
+   runs in autonomous mode with no one to ask. `planner-sub` runs on the repository's plan model,
+   which these two steps decide the whole change on. Wait for it in the same turn, then continue
+   with the next phase yourself. If `planner-sub` is not in the task tool's enum, call
+   `report_incomplete` naming it; do not load `pc-plan-propose` here. Only when the harness is
+   older than 3.4.0 and has neither `planner` nor `planner-sub` may you load the skill here.
 
    2. `pc-plan-propose`, even when the issue is refined. It is what turns the issue into
       `openspec/changes/<id>/tasks.md` with every task annotated

package/loops/workflows/shared/opencode-ci.md

@@ -208,11 +208,10 @@ pre-agent-steps:
     # Two of the three run here. pc-system-reminders gates shell and edits on skills a CI
     # worker's prompt does not load, and has never run in CI; it stays off until it does.
     #
-    # The tier models come from AGENT_TIER_MODEL when a worker sets it. The AWF proxy refuses
-    # a model it has no AI credits price for; harness.json names carina-60b and quasar-438b,
-    # which had none until the `models.providers` prices at the top of this file (Atlas #2016).
-    # CI still pins every tier to one model, through the gitignored per-user override the
-    # plugin reads first, until a run on the newly priced models has passed.
+    # The tier models come from AGENT_TIER_MODEL when a worker sets it. The implement worker
+    # leaves it empty so harness.json drives: plan=glm-5-3, build/fast=glm-5-2. A repository
+    # whose CI account is not granted a tier model can still pin every tier to one model
+    # through the gitignored per-user override the plugin reads first.
     run: |
       set -euo pipefail
       if [ ! -f .opencode/package.json ]; then
@@ -246,6 +245,19 @@ pre-agent-steps:
       echo "Harness plugins: $(ls .opencode/plugins | tr '\n' ' ')"
       echo "Tier models: $(jq -c '.models' .opencode/harness.user.json 2>/dev/null || jq -c '.models' .opencode/harness.json)"
 
+  - name: Sync harness agents and print model routing
+    # The plugin writes these at startup, but OpenCode builds the task enum from what
+    # exists when it starts. Generating them here makes planner-sub and the tier
+    # variants visible from the first turn; the doctor is the audit line.
+    run: |
+      set -euo pipefail
+      if [ -f .opencode/scripts/sync-agents.mjs ] && [ -f .opencode/plugins/pc-subagent-tiers-core.js ]; then
+        node .opencode/scripts/sync-agents.mjs --strict
+      fi
+      if [ -f .opencode/scripts/harness-doctor.mjs ]; then
+        node .opencode/scripts/harness-doctor.mjs --strict
+      fi
+
   - name: Merge the CI-only OpenCode provider into opencode.jsonc
     env:
       GH_TOKEN: ${{ github.token }}

package/loops/workflows/shared/platform-defaults.md

@@ -1,53 +1,53 @@
----
-# Managed by @plainconceptsplatform/workflows. Source: loops/workflows/shared/platform-defaults.md. Update with `workflows update --force`; consumer edits may be overwritten.
-description: Shared network and safe-output defaults for catalog agent workflows, plus the verification rules every worker that builds or pushes has to follow. The body below is runtime-imported into each worker's prompt ahead of its own steps.
-
-network:
-  allowed:
-    - defaults
-    - forge.plainconcepts.com
-    # opencode fetches its model registry from models.opencode.ai at startup; without
-    # this host on the allowlist the fetch blocks bootstrap and the run stalls after
-    # "init" until the runner kills it. The apex "opencode.ai" is not enough.
-    - models.opencode.ai
-    - node
-    - github
-    - dotnet
-    - fonts
-    - login.microsoftonline.com
-    # centralised AgentMemory (App Service); the MCP shim needs it through the egress proxy
-    - agentmemory-pro-01.azurewebsites.net
-
-safe-outputs:
-  threat-detection: false
----
-
-## These runs are not interactive
-
-- Nothing resumes you. A turn that ends with text and no tool call ends the whole run, and the work
-  is discarded, whatever the text promised. "I'll read the context files first." as a last message
-  is a finished run: the Pliny-Bot merge gate did exactly that on #801, ended in twenty-three
-  seconds with exit code 0 and no outcome, and was retried twice before the pull request was handed
-  to a person for nothing.
-- So every message you write carries a tool call until the last one, which is the safe-output call
-  the task names. Say what you are about to do and do it in the same message. Never announce a step
-  and stop, never wait for a command, a reviewer or a "next turn".
-- A command the bash tool reports as moved to the background is still running: poll its output file
-  with tool calls (`sleep 40; tail -n 15 <file>`) until it shows an exit status, then go on.
-
-## Verification, for every worker that builds or pushes
-
-- Scope every check to the files you changed. This is the runner, not a preference: a
-  whole-repository lint, build or test run exhausts its memory and gets killed mid-run, which
-  fails the job with no useful output. Pass the changed paths to the linter (`pnpm exec biome
-  check <files>`), build only the projects containing them, and run only the test project that
-  covers them. Escalate to the full suite only after the scoped run passes and only when the
-  change crosses a project boundary.
-- Run nothing at all for a change that touches only documentation. A cold Release build on a
-  shared runner is minutes the run does not get back.
-- Never make a check pass by weakening it: not a deleted test, not a lowered threshold, not a
-  skipped step. Fix the cause and run it again.
-- Once the checks pass, run the project's lint fix command over the files you changed
-  (`pnpm lint:fix`, `pnpm exec biome check --write <changed-files>`, or its equivalent), or
-  correct what lint reports where no fix command exists. A branch that arrives with lint errors
-  gets sent back for them.
+---
+# Managed by @plainconceptsplatform/workflows. Source: loops/workflows/shared/platform-defaults.md. Update with `workflows update --force`; consumer edits may be overwritten.
+description: Shared network and safe-output defaults for catalog agent workflows, plus the verification rules every worker that builds or pushes has to follow. The body below is runtime-imported into each worker's prompt ahead of its own steps.
+
+network:
+  allowed:
+    - defaults
+    - forge.plainconcepts.com
+    # opencode fetches its model registry from models.opencode.ai at startup; without
+    # this host on the allowlist the fetch blocks bootstrap and the run stalls after
+    # "init" until the runner kills it. The apex "opencode.ai" is not enough.
+    - models.opencode.ai
+    - node
+    - github
+    - dotnet
+    - fonts
+    - login.microsoftonline.com
+    # centralised AgentMemory (App Service); the MCP shim needs it through the egress proxy
+    - agentmemory-pro-01.azurewebsites.net
+
+safe-outputs:
+  threat-detection: false
+---
+
+## These runs are not interactive
+
+- Nothing resumes you. A turn that ends with text and no tool call ends the whole run, and the work
+  is discarded, whatever the text promised. "I'll read the context files first." as a last message
+  is a finished run: the Pliny-Bot merge gate did exactly that on #801, ended in twenty-three
+  seconds with exit code 0 and no outcome, and was retried twice before the pull request was handed
+  to a person for nothing.
+- So every message you write carries a tool call until the last one, which is the safe-output call
+  the task names. Say what you are about to do and do it in the same message. Never announce a step
+  and stop, never wait for a command, a reviewer or a "next turn".
+- A command the bash tool reports as moved to the background is still running: poll its output file
+  with tool calls (`sleep 40; tail -n 15 <file>`) until it shows an exit status, then go on.
+
+## Verification, for every worker that builds or pushes
+
+- Scope every check to the files you changed. This is the runner, not a preference: a
+  whole-repository lint, build or test run exhausts its memory and gets killed mid-run, which
+  fails the job with no useful output. Pass the changed paths to the linter (`pnpm exec biome
+  check <files>`), build only the projects containing them, and run only the test project that
+  covers them. Escalate to the full suite only after the scoped run passes and only when the
+  change crosses a project boundary.
+- Run nothing at all for a change that touches only documentation. A cold Release build on a
+  shared runner is minutes the run does not get back.
+- Never make a check pass by weakening it: not a deleted test, not a lowered threshold, not a
+  skipped step. Fix the cause and run it again.
+- Once the checks pass, run the project's lint fix command over the files you changed
+  (`pnpm lint:fix`, `pnpm exec biome check --write <changed-files>`, or its equivalent), or
+  correct what lint reports where no fix command exists. A branch that arrives with lint errors
+  gets sent back for them.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@plainconceptsplatform/workflows",
-  "version": "1.13.1",
+  "version": "1.14.0",
   "description": "Install and update Platform GitHub agentic workflows.",
   "keywords": [
     "github-actions",