@plainconceptsplatform/workflows 0.19.2 → 0.20.1

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/templates/opencode/opencode.ci.json

@@ -1,49 +1,55 @@
-{
-  "$schema": "https://opencode.ai/config.json",
-  "model": "forge/glm-5-3",
-  "plugin": [],
-  "default_agent": "ci-workflow-agent",
-  "agent": {
-    "ci-workflow-agent": {
-      "description": "Executes GitHub Agentic Workflow tasks in CI.",
-      "mode": "primary",
-      "prompt": "You execute the GitHub Agentic Workflow task in the user prompt. Read AGENTS.md before any non-trivial change. Load only skills the workflow task explicitly names via skill(); when a workflow says load @skill-name, call skill(\"skill-name\"), the @ prefix is just a hint to use the skill tool. Execute only the requested task and required commands. Do not probe or inspect unrelated commands. The GitHub CLI is intentionally unauthenticated: never use `gh` for GitHub reads or writes. Read supplied workflow files first, then use the GitHub MCP tools only when fresh GitHub data is required. Use direct `safeoutputs` commands for GitHub writes. Each safe-output type has a small per-run allowance, and a call that fails still spends it: never send an empty, partial or test payload to discover what a tool accepts, because that probe can be recorded as a success, take the allowance with it, and leave the real call refused as over the limit, ending a run that did all the work and published none of it. Call each safe-output tool once, with the complete final payload, only when you are ready to commit to the outcome. For syntax-only validation of a conventional GitHub Actions YAML file, use Ruby's standard YAML library; do not probe, install, or fall back through PyYAML, js-yaml, actionlint, or Docker. A task is complete only after every required Safe Outputs command succeeds. After the final required Safe Outputs command, stop immediately without further tools, prose, or model turns. Use `mcpscripts` only when the runtime explicitly lists it as available.\n\nOUTPUT DISCIPLINE: Do not narrate. Do not explain what you are about to do before doing it. Do not write prose between tool calls. Call tools silently. The only prose you produce is the final result or a brief error explanation when something fails. Never output sentences like 'Let me check...', 'Now I will...', 'I have enough context...', or 'Next I need to...'. If you are about to call a tool, just call it. If you must think, use the todowrite tool, not prose.\n\nMEMORY: agentmemory is the shared long-term store. Start non-trivial tasks by calling its recall/search tool with the key concepts of the task (component names, error text) and reuse what it returns instead of rediscovering it. Before finishing, store 1-3 concise memories of durable non-obvious learnings: architecture constraints, root causes and their fixes, decisions and their why. Skip trivia the repo already documents. Never store secrets or tokens."
-    }
-  },
-  "permission": {
-    "read": "allow",
-    "external_directory": {
-      "/tmp/**": "allow",
-      "/home/runner/work/_temp/gh-aw/**": "allow"
-    }
-  },
-  "lsp": {
-    "csharp": {
-      "disabled": true
-    },
-    "fsharp": {
-      "disabled": true
-    },
-    "razor": {
-      "disabled": true
-    }
-  },
-  "provider": {
-    "forge": {
-      "api": "{env:OPENAI_BASE_URL}",
-      "options": {
-        "apiKey": "{env:OPENAI_API_KEY}"
-      },
-      "models": {
-        "glm-5-3": {
-          "name": "GLM 5.3",
-          "attachment": true
-        },
-        "glm-5-2": {
-          "name": "GLM 5.2",
-          "attachment": true
-        }
-      }
-    }
-  }
-}
+{
+  "$schema": "https://opencode.ai/config.json",
+  "model": "forge/glm-5-3",
+  "plugin": [],
+  "default_agent": "ci-workflow-agent",
+  "agent": {
+    "ci-workflow-agent": {
+      "description": "Executes GitHub Agentic Workflow tasks in CI.",
+      "mode": "primary",
+      "prompt": "You execute the GitHub Agentic Workflow task in the user prompt. Read AGENTS.md before any non-trivial change. Load only skills the workflow task explicitly names via skill(); when a workflow says load @skill-name, call skill(\"skill-name\"), the @ prefix is just a hint to use the skill tool. Execute only the requested task and required commands. Do not probe or inspect unrelated commands. The GitHub CLI is intentionally unauthenticated: never use `gh` for GitHub reads or writes. Read supplied workflow files first, then use the GitHub MCP tools only when fresh GitHub data is required. Use direct `safeoutputs` commands for GitHub writes. Each safe-output type has a small per-run allowance, and a call that fails still spends it: never send an empty, partial or test payload to discover what a tool accepts, because that probe can be recorded as a success, take the allowance with it, and leave the real call refused as over the limit, ending a run that did all the work and published none of it. Call each safe-output tool once, with the complete final payload, only when you are ready to commit to the outcome. For syntax-only validation of a conventional GitHub Actions YAML file, use Ruby's standard YAML library; do not probe, install, or fall back through PyYAML, js-yaml, actionlint, or Docker. A task is complete only after every required Safe Outputs command succeeds. After the final required Safe Outputs command, stop immediately without further tools, prose, or model turns. Use `mcpscripts` only when the runtime explicitly lists it as available.\n\nOUTPUT DISCIPLINE: Do not narrate. Do not explain what you are about to do before doing it. Do not write prose between tool calls. Call tools silently. The only prose you produce is the final result or a brief error explanation when something fails. Never output sentences like 'Let me check...', 'Now I will...', 'I have enough context...', or 'Next I need to...'. If you are about to call a tool, just call it. If you must think, use the todowrite tool, not prose.\n\nMEMORY: agentmemory is the shared long-term store. Start non-trivial tasks by calling its recall/search tool with the key concepts of the task (component names, error text) and reuse what it returns instead of rediscovering it. Before finishing, store 1-3 concise memories of durable non-obvious learnings: architecture constraints, root causes and their fixes, decisions and their why. Skip trivia the repo already documents. Never store secrets or tokens."
+    },
+    "finding-verifier": {
+      "description": "Use to verify a single claim about a code change: whether a suspected defect is real. Reads the code fresh and tries to disprove the claim, with no sight of the reasoning that produced it. Returns whether it is verified, and the evidence.",
+      "mode": "subagent",
+      "temperature": 0,
+      "prompt": "You are handed ONE claim about a code change and asked whether it is real. You did not write it and you have not seen the reasoning behind it. Your job is to try to DISPROVE it.\n\nRead the code the claim names, and the code around it. Run the test or the command that would settle it if one exists. Follow the path from entry point to the line in question and check whether the condition the claim depends on can actually hold.\n\nAnswer with a JSON object and nothing else:\n{\"verified\": true|false, \"verification\": \"the command you ran and what it printed, or the code path quoted end to end\", \"severity\": \"critical|high|medium|low\", \"reason\": \"one sentence\"}\n\n`verified: true` means you demonstrated the problem, not that you failed to rule it out. If you could not reproduce it, if the guard the claim says is missing is actually present upstream, or if the claim is about style, taste or a hypothetical caller that does not exist in this repository, answer `verified: false` and say why. Disagreeing with the claim is a useful result and costs you nothing. Do not soften a real defect and do not manufacture one. Never edit a file, never push, never call a safe output."
+    }
+  },
+  "permission": {
+    "read": "allow",
+    "external_directory": {
+      "/tmp/**": "allow",
+      "/home/runner/work/_temp/gh-aw/**": "allow"
+    }
+  },
+  "lsp": {
+    "csharp": {
+      "disabled": true
+    },
+    "fsharp": {
+      "disabled": true
+    },
+    "razor": {
+      "disabled": true
+    }
+  },
+  "provider": {
+    "forge": {
+      "api": "{env:OPENAI_BASE_URL}",
+      "options": {
+        "apiKey": "{env:OPENAI_API_KEY}"
+      },
+      "models": {
+        "glm-5-3": {
+          "name": "GLM 5.3",
+          "attachment": true
+        },
+        "glm-5-2": {
+          "name": "GLM 5.2",
+          "attachment": true
+        }
+      }
+    }
+  }
+}

package/loops/templates/opencode/opencode.ci.json.md

@@ -1,49 +1,59 @@
-# Ownership: opencode.ci.json
-
-Managed by @plainconceptsplatform/workflows. Source:
-`loops/templates/opencode/opencode.ci.json`. Update with
-`workflows update --force --template opencode.ci.json`; consumer edits may be
-overwritten.
-
-JSON (RFC 8259) does not permit comments, so the ownership header is documented
-here instead of inline in `opencode.ci.json`.
-
-## Template contents
-
-This template provides a standalone OpenCode CI configuration for consumer
-repositories running agentic workflows in GitHub Actions. It is copied to the
-repository root as `opencode.ci.json`.
-
-### Provider
-
-- The `forge` provider is OpenAI-compatible and reads its endpoint from
-  `OPENAI_BASE_URL` and its key from `OPENAI_API_KEY` at runtime. Those are the
-  two variables every worker's agent job sets (`engine.env` in the worker and
-  the `OPENAI_API_KEY` secret), so the file works with no consumer wiring. An
-  earlier template read `FORGE_API_URL`/`FORGE_API_KEY`, which nothing set.
-- Each consumer configures its own router endpoint, credential, model IDs, and
-  capabilities. The workflow package does not assume a particular gateway
-  host, authentication system, or model vendor.
-- Model entries are fallback metadata. Consumers should set `attachment: true`
-  only for models whose router supports image input.
-- Default model: `forge/glm-5-3`.
-
-### Agent
-
-- **ci-workflow-agent** in `primary` mode with the output discipline directive:
-  no narration, no prose between tool calls, stop immediately after the final
-  Safe Outputs command.
-
-### LSP
-
-- `csharp`, `fsharp`, and `razor` LSP servers are disabled. Consumers not
-  working with .NET can remove the `lsp` block entirely.
-
-### Consumer edits
-
-After copying, edit the file directly for repository-specific needs:
-
-- Change the model or add providers.
-- Adjust agent prompt rules or permissions.
-- Remove the `lsp` block if LSP is not needed or add other language servers.
-- Add MCP servers or plugins as required.
+# Ownership: opencode.ci.json
+
+Managed by @plainconceptsplatform/workflows. Source:
+`loops/templates/opencode/opencode.ci.json`. Update with
+`workflows update --force --template opencode.ci.json`; consumer edits may be
+overwritten.
+
+JSON (RFC 8259) does not permit comments, so the ownership header is documented
+here instead of inline in `opencode.ci.json`.
+
+## Template contents
+
+This template provides a standalone OpenCode CI configuration for consumer
+repositories running agentic workflows in GitHub Actions. It is copied to the
+repository root as `opencode.ci.json`.
+
+### Provider
+
+- The `forge` provider is OpenAI-compatible and reads its endpoint from
+  `OPENAI_BASE_URL` and its key from `OPENAI_API_KEY` at runtime. Those are the
+  two variables every worker's agent job sets (`engine.env` in the worker and
+  the `OPENAI_API_KEY` secret), so the file works with no consumer wiring. An
+  earlier template read `FORGE_API_URL`/`FORGE_API_KEY`, which nothing set.
+- Each consumer configures its own router endpoint, credential, model IDs, and
+  capabilities. The workflow package does not assume a particular gateway
+  host, authentication system, or model vendor.
+- Model entries are fallback metadata. Consumers should set `attachment: true`
+  only for models whose router supports image input.
+- Default model: `forge/glm-5-3`.
+
+### Agents
+
+- **ci-workflow-agent** in `primary` mode with the output discipline directive:
+  no narration, no prose between tool calls, stop immediately after the final
+  Safe Outputs command.
+- **finding-verifier** in `subagent` mode, at temperature 0. It takes one claim
+  about a code change and tries to disprove it against the code, with no sight
+  of the reasoning that produced it. Only a finding it returns `verified: true`
+  for can block a merge. It exists so that the agent that found a problem is not
+  also the only one who judges it, which is the check self-review cannot provide.
+  It reads and runs; it never writes, pushes, or calls a safe output.
+
+  The merge-gate prompt asks for independent verification without naming this
+  agent or the tool that reaches it: opencode routes on the agent's
+  `description`, so the mechanism stays opencode's to change.
+
+### LSP
+
+- `csharp`, `fsharp`, and `razor` LSP servers are disabled. Consumers not
+  working with .NET can remove the `lsp` block entirely.
+
+### Consumer edits
+
+After copying, edit the file directly for repository-specific needs:
+
+- Change the model or add providers.
+- Adjust agent prompt rules or permissions.
+- Remove the `lsp` block if LSP is not needed or add other language servers.
+- Add MCP servers or plugins as required.

package/loops/templates/release/github-release.yml

@@ -1,30 +1,30 @@
-# Managed by @plainconceptsplatform/workflows. Source: loops/templates/release/github-release.yml. Update with `workflows update --force`; consumer edits may be overwritten.
-name: Publish GitHub release
-
-on:
-  push:
-    tags:
-      - "v*"
-
-permissions:
-  contents: write
-
-jobs:
-  publish:
-    name: Publish release
-    runs-on: [self-hosted, linux, agents]
-    timeout-minutes: 10
-    steps:
-      - name: Create or update GitHub release
-        env:
-          GH_TOKEN: ${{ github.token }}
-          TAG: ${{ github.ref_name }}
-        shell: bash
-        run: |
-          set -euo pipefail
-
-          if gh release view "$TAG" >/dev/null 2>&1; then
-            gh release edit "$TAG" --title "$TAG" --generate-notes
-          else
-            gh release create "$TAG" --title "$TAG" --generate-notes
-          fi
+# Managed by @plainconceptsplatform/workflows. Source: loops/templates/release/github-release.yml. Update with `workflows update --force`; consumer edits may be overwritten.
+name: Publish GitHub release
+
+on:
+  push:
+    tags:
+      - "v*"
+
+permissions:
+  contents: write
+
+jobs:
+  publish:
+    name: Publish release
+    runs-on: [self-hosted, linux, agents]
+    timeout-minutes: 10
+    steps:
+      - name: Create or update GitHub release
+        env:
+          GH_TOKEN: ${{ github.token }}
+          TAG: ${{ github.ref_name }}
+        shell: bash
+        run: |
+          set -euo pipefail
+
+          if gh release view "$TAG" >/dev/null 2>&1; then
+            gh release edit "$TAG" --title "$TAG" --generate-notes
+          else
+            gh release create "$TAG" --title "$TAG" --generate-notes
+          fi