@plainconceptsplatform/workflows 1.3.0 → 1.3.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/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: ubuntu-latest
-    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: ubuntu-latest
+    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

package/loops/workflows/agent-apply-review.md

@@ -541,6 +541,11 @@ timeout-minutes: 90
     ${{ env.VERIFY_COMMANDS }}
     ```
 
+   When `.opencode/scripts/check-diff.mjs` exists, also run
+   `node .opencode/scripts/check-diff.mjs`.
+   It must exit 0: delete the comments and tests it lists. The merge gate runs it too and does not
+   merge while it fails.
+
 7. Select one review outcome.
 
    - **implemented**: You made the requested change, verification passed, and you will propose

package/loops/workflows/agent-implement.md

@@ -707,6 +707,12 @@ timeout-minutes: 180
 
      Never open a pull request that does not pass them.
 
+     When `.opencode/scripts/check-diff.mjs` exists, also run
+     `node .opencode/scripts/check-diff.mjs`
+     on both paths. It must exit 0. It holds the comments and tests you add to the size of the
+     change and makes you clean the files you touched; fix every line it lists. The merge gate
+     runs it again and does not merge while it fails.
+
 5. Do not touch `changelog.json`. The workflow records the change itself once the work is on
    the default branch. Every implement used to edit that one file, so two runs whose branches
    were cut before the other merged conflicted on it and failed to open a pull request with the

package/loops/workflows/agent-merge-gate.md

@@ -131,7 +131,9 @@ on:
   # this entry activation read needs.protected_changes.outputs.requires_review before
   # protected_changes had started; the value was '' and the clause was always true
   # (Pliny-Bot run 34042143350: activation finished 18 s before protected_changes began).
-  needs: [protected_changes]
+  # code_rules is here for the same reason: the prompt prints its result and report, and the
+  # prompt is rendered in activation.
+  needs: [protected_changes, code_rules]
 
 # Rung 4. Router has classified the event; identify-gate-subject validates PR ownership,
 # resolves the closing issue, and confirms the CI verdict.
@@ -240,6 +242,51 @@ jobs:
           medium-lines: ${{ env.BLAST_MEDIUM_LINES }}
           ignore-paths: ${{ env.BLAST_IGNORE_PATHS }}
 
+  # Rung 4c. The comments and tests the change adds, measured by the harness's check-diff on the
+  # pull request head before any model reads it. Prose in the implement prompt did not hold bot
+  # pull requests to the guardrails: they added 27-63% comment lines in October 2026. `fail`
+  # stops an auto-merge in the validator; the agent is told to repair it like a CI failure.
+  # A repository without the script reports `absent` and is not held to it.
+  code_rules:
+    needs: subject
+    if: needs.subject.outputs.found == 'true'
+    runs-on: agents-arc
+    timeout-minutes: 10
+    permissions:
+      contents: read
+    outputs:
+      result: ${{ steps.check.outputs.result }}
+      report: ${{ steps.check.outputs.report }}
+    steps:
+      - name: Checkout the pull request
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          ref: refs/pull/${{ needs.subject.outputs.pr }}/head
+          fetch-depth: 0
+          persist-credentials: false
+      - name: Check the comments and tests it adds
+        id: check
+        env:
+          BASE: origin/${{ github.event.repository.default_branch || 'main' }}
+        run: |
+          set -uo pipefail
+          if [ ! -f .opencode/scripts/check-diff.mjs ]; then
+            echo "result=absent" >> "$GITHUB_OUTPUT"
+            echo "check-diff is not installed (agent-harness 3.2.0 or later ships it), so comments and tests were not checked." >> "$GITHUB_STEP_SUMMARY"
+            exit 0
+          fi
+          report=$(node .opencode/scripts/check-diff.mjs --base "$BASE" 2>&1)
+          code=$?
+          case "$code" in 0) result=pass ;; 1) result=fail ;; *) result=error ;; esac
+          delimiter="EOF_$(openssl rand -hex 8)"
+          {
+            echo "result=$result"
+            echo "report<<$delimiter"
+            printf '%s\n' "${report:0:8000}"
+            echo "$delimiter"
+          } >> "$GITHUB_OUTPUT"
+          printf '```\n%s\n```\n' "$report" >> "$GITHUB_STEP_SUMMARY"
+
   review_required:
     needs: [subject, protected_changes]
     # gh-aw makes the agent depend on custom jobs. Keep this job successful when
@@ -362,7 +409,7 @@ jobs:
             Problems found in PR #${{ needs.subject.outputs.pr }}. ${{ steps.conflicts.outputs.has_conflicts == 'true' && 'Merge conflicts detected.' || 'CI failed.' }}
             Bot is working on fixing it.
   validate_output:
-    needs: [activation, subject, protected_changes, agent, safe_outputs]
+    needs: [activation, subject, protected_changes, code_rules, agent, safe_outputs]
     if: >
       always() &&
       needs.agent.result == 'success' &&
@@ -396,6 +443,7 @@ jobs:
           protected-hit: ${{ needs.protected_changes.outputs.requires_review }}
           owner-hit: ${{ needs.protected_changes.outputs.owner_hit }}
           confidence-threshold: ${{ env.CONFIDENCE_THRESHOLD }}
+          code-rules: ${{ needs.code_rules.outputs.result }}
   conclude:
     needs: [activation, subject, protected_changes, agent, safe_outputs, validate_output]
     # `protected_changes.result == 'success'` is stated rather than relied on. GitHub skips a job
@@ -854,6 +902,18 @@ timeout-minutes: 120
    ${{ needs.protected_changes.outputs.signals }}
    ```
 
+   **Comments and tests (`check-diff`): `${{ needs.code_rules.outputs.result }}`**
+
+   ```
+   ${{ needs.code_rules.outputs.report }}
+   ```
+
+   When that is `fail`, repairing it is part of this run whatever CI concluded: delete the
+   comments and tests it lists, leave every file it names with no slop, run
+   `node .opencode/scripts/check-diff.mjs`
+   until it exits 0, then verify, push and report `remediated` as in step 6. An `assessed`
+   verdict while it fails blocks the pull request.
+
    - **success** → step 4, then step 5 (review the change).
    - **failure** → step 4, then step 6 (CI remediation).
    - **action_required, cancelled, timed_out, or anything else** → CI did not produce a usable