@plainconceptsplatform/workflows 0.27.4 → 0.27.6

package/loops/actions/decide-agent-retry/action.yml

@@ -35,7 +35,7 @@ runs:
     #
     # Written once here because the rule was in the implement worker alone, and refine, triage and
     # apply-review parked instead -- an Odyssey refine died in three minutes on
-    # `Model 'glm-5-3' not found`, a gateway fault that clears in seconds, and waited on the
+    # `Model 'glm-5-2' not found`, a gateway fault that clears in seconds, and waited on the
     # janitor's six-hourly sweep. Five copies of sixty lines is how one rule becomes five.
     - name: Decide whether this failure is worth repeating
       id: decide

package/loops/actions/verify-route-matrix/verify-route-matrix.sh

@@ -1990,7 +1990,7 @@ echo "── Retrying a run that died early ────────────
 
 # A run that died before producing anything is worth repeating; one that worked and then failed
 # produced an answer that was wrong, and repeating it buys the same wrong answer later. Only the
-# implement worker knew that. An Odyssey refine died in three minutes on `Model 'glm-5-3' not
+# implement worker knew that. An Odyssey refine died in three minutes on `Model 'glm-5-2' not
 # found` -- a gateway fault that clears in seconds -- parked, and waited on the janitor's
 # six-hourly sweep.
 RETRY_OK=1

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

@@ -1,6 +1,6 @@
 {
   "$schema": "https://opencode.ai/config.json",
-  "model": "forge/glm-5-3",
+  "model": "forge/glm-5-2",
   "plugin": [],
   "default_agent": "ci-workflow-agent",
   "agent": {
@@ -41,15 +41,15 @@
         "apiKey": "{env:OPENAI_API_KEY}"
       },
       "models": {
-        "glm-5-3": {
+        "glm-5-2": {
           "name": "GLM 5.3",
           "attachment": true
         },
-        "glm-5-2": {
+        "quasar-438b": {
           "name": "GLM 5.2",
           "attachment": true
         }
       }
     }
   }
-}
+}

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

@@ -26,7 +26,7 @@ repository root as `opencode.ci.json`.
   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`.
+- Default model: `forge/glm-5-2`.
 
 ### Agents
 

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

@@ -14,7 +14,7 @@ env:
   REVIEW_MARKER: "<!-- agent-apply-review -->"
   # A run that died before it produced anything is worth repeating; one that worked and then
   # failed produced an answer that was wrong, and repeating it buys the same wrong answer later.
-  # Duration is what separates them. Odyssey #190 died in three minutes on `Model 'glm-5-3' not
+  # Duration is what separates them. Odyssey #190 died in three minutes on `Model 'glm-5-2' not
   # found`, a gateway fault that clears in seconds, and waited on the janitor's six-hourly sweep
   # because only the implement worker could do this.
   APPLY_REVIEW_ATTEMPT_MARKER: "<!-- agent-apply-review-attempt -->"
@@ -399,7 +399,7 @@ engine:
   env:
     OPENAI_BASE_URL: https://forge.plainconcepts.com/v1
 
-model: openai/glm-5-3
+model: openai/glm-5-2
 
 max-turns: 300
 max-turn-cache-misses: 3000

package/loops/workflows/agent-audit.md

@@ -67,7 +67,7 @@ engine:
   env:
     OPENAI_BASE_URL: https://forge.plainconcepts.com/v1
 
-model: openai/glm-5-3
+model: openai/glm-5-2
 
 max-turns: 300
 max-turn-cache-misses: 3000

package/loops/workflows/agent-implement.md

@@ -615,7 +615,7 @@ engine:
   env:
     OPENAI_BASE_URL: https://forge.plainconcepts.com/v1
 
-model: openai/glm-5-3
+model: openai/glm-5-2
 
 max-turns: 300
 max-turn-cache-misses: 3000

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

@@ -685,7 +685,7 @@ engine:
   env:
     OPENAI_BASE_URL: https://forge.plainconcepts.com/v1
 
-model: openai/glm-5-3
+model: openai/glm-5-2
 
 max-turns: 300
 max-turn-cache-misses: 3000

package/loops/workflows/agent-refine.md

@@ -26,7 +26,7 @@ env:
   REFINE_MARKER: "<!-- agent-refine -->"
   # A run that died before it produced anything is worth repeating; one that worked and then
   # failed produced an answer that was wrong, and repeating it buys the same wrong answer later.
-  # Duration is what separates them. Odyssey #190 died in three minutes on `Model 'glm-5-3' not
+  # Duration is what separates them. Odyssey #190 died in three minutes on `Model 'glm-5-2' not
   # found`, a gateway fault that clears in seconds, and waited on the janitor's six-hourly sweep
   # because only the implement worker could do this.
   REFINE_ATTEMPT_MARKER: "<!-- agent-refine-attempt -->"
@@ -483,9 +483,9 @@ engine:
     OPENAI_BASE_URL: https://forge.plainconcepts.com/v1
   args:
     - "--model"
-    - "plainconcepts/glm-5-3"
+    - "plainconcepts/glm-5-2"
 
-model: openai/glm-5-3
+model: openai/glm-5-2
 # 150 rather than 500. With a four-hour clock this is the loop guard, and the worst
 # observed run used 44 turns, so this leaves better than three times the worst case.
 max-turns: 150
@@ -548,93 +548,33 @@ timeout-minutes: 90
      temporal draft from the earlier pass: reuse what still holds, and resolve its pending
      marks with the author's answers.
 
-3. Explore before you write. Call skill("pc-plan-explore"); it owns the stance for this step.
-
-   Split the issue into work units first. If the issue body is a bullet list of distinct tasks
-   (for example "- check the button component", "- then check the login", "- then suggest a
-   register page"), treat each bullet as its own work unit. Otherwise treat the whole issue as a
-   single work unit.
-
-   Create a todo entry for each work unit before you start exploring. Process them one at a
-   time, strictly sequentially: explore unit 1, self-answer its questions, mark the todo
-   complete, then move to unit 2. Do not explore multiple work units in the same pass. Do not
-   start unit N+1 until unit N is marked complete.
-
-   For the current work unit, answer your own questions from the codebase and the docs, and
-   set one aside for the author only when it is a business or product decision the code cannot
-   settle. A unit's todo is complete when its findings would support acceptance criteria: if you
-   read a file but cannot say what changes for this unit, it is not.
-
-   At most ${{ env.MAX_SELF_QUESTIONS }} self-asked questions per work unit, and stop sooner
-   once more exploring stops changing your understanding. Never write a self-asked question or
-   its answer to the issue: this is internal working, and the issue is read by people.
-
-4. **Classify the change complexity.** Based on your exploration, determine whether this is a
-   trivial change. A change is **trivial** only if every one of these holds:
-   ${{ env.TRIVIAL_CRITERIA }}
-
-   If all hold → **trivial path** (step 4a). If any fails → **standard path** (step 5).
-
-   **4a. Trivial path.** Skip `/plan-story`. Do not write Gherkin acceptance criteria or
-   Mermaid diagrams. Instead, prepare the replacement issue body as valid Markdown:
-
-   1. `${{ env.TRIVIAL_MARKER }}`
-   2. A short plain-English summary of what needs to change and why (2-3 sentences max)
-   3. A simple checklist of concrete steps:
-      ```
-      ## Tasks
-      - [ ] Change X in file Y
-      - [ ] Verify Z
-      ```
-
-   No "As a / I want / so that" form. No Given/When/Then. No Mermaid. Just the marker,
-   the summary, and the checklist.
-
-   Load `@humanizer` and prepare the replacement issue body, then go directly to step 8
-   (estimate). Skip steps 5-7.
-
-5. Before writing the story, verify coverage: list every work unit and confirm each one has
-   exploration findings concrete enough for acceptance criteria. If any unit is missing, go back
-   and explore it now. Then call skill("pc-plan-story") and run `/plan-story` for the issue,
-   passing everything you learned while exploring as the exploration findings. Ground the story
-   in the actual codebase by reading the relevant files. Never read outside this repository root.
-   `pc-plan-story` owns the story's shape. This workflow's own requirement is coverage: several
-   work units become one story that covers all of them, with at least one acceptance scenario
-   per unit.
-
-     Apply repository documentation and established conventions before finalizing the story.
-     Adhere to ${{ env.REPO_RULES }}.
-
-6. **Wrap the story in the repository's issue form.** The body people read must follow the
-   repository's own issue template when one exists; the story is the content, the template
-   is the shape.
-
-   Find the form first:
-
-   - List the YAML and Markdown forms under `.github/ISSUE_TEMPLATE/`, plus a legacy
-     `.github/issue_template.md` or a root `template.yml`. `config.yml` there only declares
-     contact links, which are not forms: ignore it.
-   - When a form filters by labels and the issue carries one of those labels, that form
-     wins. Otherwise use the repository's default form.
-   - When the repository has no form at all, keep the free-form story shape from step 5:
-     there is nothing to wrap around.
-
-   Then fill it:
-
-   - Draw every field's content from your exploration findings. Required fields always get
-     real content; optional fields only when you genuinely have something for them.
-   - The story narrative lands in the field that asks for it — proposal, description, or
-     what-happened, depending on the form.
-   - The Given/When/Then scenarios go into the form's acceptance-criteria field when it has
-     one; otherwise they stay a section of their own. The Mermaid diagram goes where it
-     reads best inside the filled form.
-   - The machine-readable lines the later steps add — split markers in step 9, estimate
-     lines in step 10 — always sit at the very top of the body, above the form's first
-     heading, so the workflow can read them whatever the form's shape.
-
-7. Load `@humanizer` and prepare the complete replacement issue body as valid Markdown.
-
-8. **Estimate the story in points.** Use the Fibonacci scale, where one point is roughly one
+3. **Explore and write the story.** Split the issue into work units first. If the issue body is
+   a bullet list of distinct tasks, treat each bullet as its own work unit. Otherwise treat the
+   whole issue as a single work unit.
+
+   Call `skill("pc-plan-explore")` and pass it the work-unit list. It owns the exploration
+   stance: sequential per-unit investigation, self-answered questions from the codebase, and
+   findings held as internal working. Never write a self-asked question or its answer to the
+   issue. At most ${{ env.MAX_SELF_QUESTIONS }} self-asked questions per work unit, and stop
+   sooner once more exploring stops changing your understanding.
+
+   Then classify the change complexity. A change is **trivial** only if every one of these
+   holds: ${{ env.TRIVIAL_CRITERIA }}
+
+   **Trivial path.** Skip the story skill. Prepare the replacement issue body as valid Markdown:
+   `${{ env.TRIVIAL_MARKER }}`, a short plain-English summary (2-3 sentences max), and a simple
+   checklist of concrete steps. No "As a / I want / so that" form, no Given/When/Then, no Mermaid.
+   Load `@humanizer` and prepare the body, then go directly to step 4 (estimate).
+
+   **Standard path.** Call `skill("pc-plan-story")` and pass it the work units and the exploration
+   findings. `pc-plan-story` owns the story's shape: drafting, coverage gate, repo-docs application,
+   issue-form discovery and wrapping, humanizer pass, and the structured implementation plan. Do not
+   repeat any of those steps yourself. Adhere to ${{ env.REPO_RULES }}.
+
+   The story body the skill returns has its machine-readable lines at the very top, above the
+   form's first heading, so the workflow can read them whatever the form's shape.
+
+4. **Estimate the story in points.** Use the Fibonacci scale, where one point is roughly one
    human day of work for a developer who knows this codebase. Estimate the whole story: code,
    tests, and the edge cases the acceptance criteria imply.
 
@@ -647,7 +587,7 @@ timeout-minutes: 90
    Elapsed clock time is not evidence. A large change can land in minutes and a small one can
    wait days for a human, so never reason from how long anything took.
 
-9. **Split when the estimate is ${{ env.SPLIT_THRESHOLD }} or more.** An oversized story is the
+5. **Split when the estimate is ${{ env.SPLIT_THRESHOLD }} or more.** An oversized story is the
    single best predictor of a pull request that never lands.
 
    First test whether it *can* split. A story splits when it contains slices that are each
@@ -672,7 +612,7 @@ timeout-minutes: 90
    single story and say so in one sentence in the body, under the estimate. An honest 8 is more
    useful than three fake threes that each break the build.
 
-10. **Record the estimate in every body you write**, parent and children alike, immediately below
+6. **Record the estimate in every body you write**, parent and children alike, immediately below
    the title line, as exactly these two lines:
 
    ```
@@ -683,7 +623,7 @@ timeout-minutes: 90
    The visible line is for people and the marker is read by the workflow, which turns it into the
    `sp-N` label. A body without the marker gets no estimate label at all.
 
-11. Decide exactly one outcome:
+7. Decide exactly one outcome:
 
     Labels are workflow-owned state. Do not call `add_labels` or `remove_labels`.
 
@@ -691,9 +631,9 @@ timeout-minutes: 90
     could not answer. Leave the partial work visible: first call `update_issue` with a
     temporal draft, then call `add_comment` once with the questions.
 
-    The temporal draft is the replacement body your path would have written — the filled
-    issue form from step 6 on the standard path, the marker, summary and checklist from
-    step 4a on the trivial path — holding everything you already established, with every
+    The temporal draft is the replacement body your path would have written — the story
+    body from the standard path, the marker, summary and checklist from the trivial path —
+    holding everything you already established, with every
     part the questions leave open marked `_pending — see questions below_`. Its very
     first line is `${{ env.DRAFT_MARKER }}`; the next run replaces the draft wholesale
     with the final body.

package/loops/workflows/agent-release.md

@@ -41,7 +41,7 @@ engine:
   env:
     OPENAI_BASE_URL: https://forge.plainconcepts.com/v1
 
-model: openai/glm-5-3
+model: openai/glm-5-2
 
 max-turns: 100
 max-turn-cache-misses: 3000

package/loops/workflows/agent-triage.md

@@ -19,7 +19,7 @@ env:
   TRIAGE_MARKER: "<!-- agent-triage -->"
   # A run that died before it produced anything is worth repeating; one that worked and then
   # failed produced an answer that was wrong, and repeating it buys the same wrong answer later.
-  # Duration is what separates them. Odyssey #190 died in three minutes on `Model 'glm-5-3' not
+  # Duration is what separates them. Odyssey #190 died in three minutes on `Model 'glm-5-2' not
   # found`, a gateway fault that clears in seconds, and waited on the janitor's six-hourly sweep
   # because only the implement worker could do this.
   TRIAGE_ATTEMPT_MARKER: "<!-- agent-triage-attempt -->"
@@ -409,9 +409,9 @@ engine:
     OPENAI_BASE_URL: https://forge.plainconcepts.com/v1
   args:
     - "--model"
-    - "plainconcepts/glm-5-3"
+    - "plainconcepts/glm-5-2"
 
-model: openai/glm-5-3
+model: openai/glm-5-2
 max-turns: 120
 max-turn-cache-misses: 3000
 max-ai-credits: 5000

package/loops/workflows/agent-visual-verify.md

@@ -206,7 +206,7 @@ engine:
   env:
     OPENAI_BASE_URL: https://forge.plainconcepts.com/v1
 
-model: openai/glm-5-3
+model: openai/glm-5-2
 max-turns: 120
 max-turn-cache-misses: 3000
 max-ai-credits: 5000

package/package.json

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