@plainconceptsplatform/workflows 0.20.1 → 0.20.3

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: [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

package/loops/workflows/authorize-bot-work.yml

@@ -1,105 +1,105 @@
-# Managed by @plainconceptsplatform/workflows. Source: loops/workflows/authorize-bot-work.yml. Update with `workflows update --force`; consumer edits may be overwritten.
-# Human adds implement/refine/direct/feature label → validates permission → bot adds bot-working
-# This ensures the bot is the actor for all agentic workflows.
-#
-# IMPORTANT: Only triggers for HUMAN actors. When the bot transitions refine→implement,
-# it adds bot-working itself, so authorize-bot-work must not fire again.
-name: "Authorize Bot Work"
-
-run-name: "Authorizing: ${{ github.event.issue.title }} (#${{ github.event.issue.number }})"
-
-on:
-  issues:
-    types: [labeled]
-
-permissions:
-  contents: read
-
-jobs:
-  authorize:
-    # Only trigger for work labels from HUMANS (not bots), and only if another bot run does not
-    # already own the issue.
-    #
-    # `review` is deliberately NOT excluded. It used to be, and that made the label a one-way
-    # door: the classifier refuses to route while `review` is set, so a person adding `refine`
-    # to a parked issue got no run, no comment and no error anywhere. Triage's own
-    # needs-maintainer verdict tells the maintainer to add `refine`, which could not work.
-    #
-    # A person adding a work label IS the human review the label was waiting for, so this
-    # workflow clears it below before handing the issue to the bot. The classifier's own guard
-    # stays as it is: it exists to stop the *bot* re-triggering itself, and by the time
-    # bot-working is added `review` is already gone.
-    if: >
-      (github.event.label.name == 'implement' ||
-       github.event.label.name == 'refine') &&
-      !contains(github.event.issue.labels.*.name, 'bot-working') &&
-      !endsWith(github.actor, '[bot]')
-    runs-on: ubuntu-latest
-    timeout-minutes: 5
-    concurrency:
-      group: authorize-${{ github.event.issue.number }}
-      cancel-in-progress: false
-    permissions:
-      contents: read
-      issues: write
-    steps:
-      - name: Check actor permission
-        id: check
-        env:
-          GH_TOKEN: ${{ github.token }}
-          ACTOR: ${{ github.actor }}
-        run: |
-          set -euo pipefail
-          
-          permission=$(gh api "repos/$GITHUB_REPOSITORY/collaborators/$ACTOR/permission" \
-            --jq '.permission' 2>/dev/null || echo "none")
-          
-          case "$permission" in
-            admin | maintain | write)
-              echo "authorized=true" >> "$GITHUB_OUTPUT"
-              echo "::notice::$ACTOR has $permission permission - authorized"
-              ;;
-            *)
-              echo "authorized=false" >> "$GITHUB_OUTPUT"
-              echo "::warning::$ACTOR has '$permission' permission - not authorized"
-              ;;
-          esac
-
-      - name: Checkout for App token action
-        if: steps.check.outputs.authorized == 'true'
-        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
-        with:
-          persist-credentials: false
-
-      - name: Generate App token
-        if: steps.check.outputs.authorized == 'true'
-        id: app-token
-        uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
-        with:
-          app-id: ${{ secrets.BOT_APP_ID }}
-          private-key: ${{ secrets.BOT_PRIVATE_KEY }}
-
-      - name: Bot takes the issue over
-        if: steps.check.outputs.authorized == 'true'
-        env:
-          GH_TOKEN: ${{ steps.app-token.outputs.token }}
-          ISSUE_NUMBER: ${{ github.event.issue.number }}
-          LABEL: ${{ github.event.label.name }}
-        run: |
-          set -euo pipefail
-
-          # Clear review FIRST. A person adding a work label is the human review the label was
-          # waiting for, and the classifier refuses to route an issue that still carries it, so
-          # removing it here is what makes the hand-off work at all. It also has to happen
-          # before bot-working, because that is the event the classifier reads: adding
-          # bot-working first would raise an event whose payload still shows review.
-          # --remove-label on an absent label is a no-op, so this is safe on a fresh issue.
-          # `stalled` goes with it: a person taking the issue on restarts the work, so the
-          # marker the janitor retries on must not survive into the new run.
-          gh issue edit "$ISSUE_NUMBER" --remove-label "review" --remove-label "stalled" 2>/dev/null ||
-            echo "::notice::no review or stalled label to clear on #$ISSUE_NUMBER"
-
-          echo "Adding bot-working label to issue #$ISSUE_NUMBER (triggered by $LABEL)"
-          gh issue edit "$ISSUE_NUMBER" --add-label "bot-working"
-
-          echo "::notice::bot-working label added - bot will now own the $LABEL workflow"
+# Managed by @plainconceptsplatform/workflows. Source: loops/workflows/authorize-bot-work.yml. Update with `workflows update --force`; consumer edits may be overwritten.
+# Human adds implement/refine/direct/feature label → validates permission → bot adds bot-working
+# This ensures the bot is the actor for all agentic workflows.
+#
+# IMPORTANT: Only triggers for HUMAN actors. When the bot transitions refine→implement,
+# it adds bot-working itself, so authorize-bot-work must not fire again.
+name: "Authorize Bot Work"
+
+run-name: "Authorizing: ${{ github.event.issue.title }} (#${{ github.event.issue.number }})"
+
+on:
+  issues:
+    types: [labeled]
+
+permissions:
+  contents: read
+
+jobs:
+  authorize:
+    # Only trigger for work labels from HUMANS (not bots), and only if another bot run does not
+    # already own the issue.
+    #
+    # `review` is deliberately NOT excluded. It used to be, and that made the label a one-way
+    # door: the classifier refuses to route while `review` is set, so a person adding `refine`
+    # to a parked issue got no run, no comment and no error anywhere. Triage's own
+    # needs-maintainer verdict tells the maintainer to add `refine`, which could not work.
+    #
+    # A person adding a work label IS the human review the label was waiting for, so this
+    # workflow clears it below before handing the issue to the bot. The classifier's own guard
+    # stays as it is: it exists to stop the *bot* re-triggering itself, and by the time
+    # bot-working is added `review` is already gone.
+    if: >
+      (github.event.label.name == 'implement' ||
+       github.event.label.name == 'refine') &&
+      !contains(github.event.issue.labels.*.name, 'bot-working') &&
+      !endsWith(github.actor, '[bot]')
+    runs-on: ubuntu-latest
+    timeout-minutes: 5
+    concurrency:
+      group: authorize-${{ github.event.issue.number }}
+      cancel-in-progress: false
+    permissions:
+      contents: read
+      issues: write
+    steps:
+      - name: Check actor permission
+        id: check
+        env:
+          GH_TOKEN: ${{ github.token }}
+          ACTOR: ${{ github.actor }}
+        run: |
+          set -euo pipefail
+          
+          permission=$(gh api "repos/$GITHUB_REPOSITORY/collaborators/$ACTOR/permission" \
+            --jq '.permission' 2>/dev/null || echo "none")
+          
+          case "$permission" in
+            admin | maintain | write)
+              echo "authorized=true" >> "$GITHUB_OUTPUT"
+              echo "::notice::$ACTOR has $permission permission - authorized"
+              ;;
+            *)
+              echo "authorized=false" >> "$GITHUB_OUTPUT"
+              echo "::warning::$ACTOR has '$permission' permission - not authorized"
+              ;;
+          esac
+
+      - name: Checkout for App token action
+        if: steps.check.outputs.authorized == 'true'
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          persist-credentials: false
+
+      - name: Generate App token
+        if: steps.check.outputs.authorized == 'true'
+        id: app-token
+        uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
+        with:
+          app-id: ${{ secrets.BOT_APP_ID }}
+          private-key: ${{ secrets.BOT_PRIVATE_KEY }}
+
+      - name: Bot takes the issue over
+        if: steps.check.outputs.authorized == 'true'
+        env:
+          GH_TOKEN: ${{ steps.app-token.outputs.token }}
+          ISSUE_NUMBER: ${{ github.event.issue.number }}
+          LABEL: ${{ github.event.label.name }}
+        run: |
+          set -euo pipefail
+
+          # Clear review FIRST. A person adding a work label is the human review the label was
+          # waiting for, and the classifier refuses to route an issue that still carries it, so
+          # removing it here is what makes the hand-off work at all. It also has to happen
+          # before bot-working, because that is the event the classifier reads: adding
+          # bot-working first would raise an event whose payload still shows review.
+          # --remove-label on an absent label is a no-op, so this is safe on a fresh issue.
+          # `stalled` goes with it: a person taking the issue on restarts the work, so the
+          # marker the janitor retries on must not survive into the new run.
+          gh issue edit "$ISSUE_NUMBER" --remove-label "review" --remove-label "stalled" 2>/dev/null ||
+            echo "::notice::no review or stalled label to clear on #$ISSUE_NUMBER"
+
+          echo "Adding bot-working label to issue #$ISSUE_NUMBER (triggered by $LABEL)"
+          gh issue edit "$ISSUE_NUMBER" --add-label "bot-working"
+
+          echo "::notice::bot-working label added - bot will now own the $LABEL workflow"