@mstar-harness/opencode 3.2.4 → 3.2.6

package/CHANGELOG.md

@@ -6,6 +6,26 @@ The monorepo root [CHANGELOG.md](../../CHANGELOG.md) summarizes cross-surface re
 
 ## [Unreleased]
 
+## [3.2.6] - 2026-08-24
+
+### Bundled harness skills (`harness-skills/` at publish)
+
+- **PR deep-review report template hardening**: the `Considered & rejected` placeholder no longer embeds the bullet dash inside angle brackets (a posted review rendered literal `<finding>` wrappers verbatim); rejected entries now use `- **<short title>**: rejected — <reason>` with an explicit "never render brackets" rule stated at the template top; empty Plan-to-fix sections collapse to a bare `none` instead of prose.
+
+- Version alignment with harness **3.2.6** (no OpenCode package API change).
+
+See root [CHANGELOG.md](../../CHANGELOG.md) **3.2.6**.
+
+## [3.2.5] - 2026-08-24
+
+### Bundled harness skills (`harness-skills/` at publish)
+
+- **PR deep-review lists every finding by default**: the `[full]` flag is removed from `/pr-deep-review` — complete findings (all merge classes, nits included) are now always listed in the chat output and GitHub Review; nothing is truncated. README command signature updated.
+
+- Version alignment with harness **3.2.5** (no OpenCode package API change).
+
+See root [CHANGELOG.md](../../CHANGELOG.md) **3.2.5**.
+
 ## [3.2.4] - 2026-08-24
 
 ### Bundled harness skills (`harness-skills/` at publish)

package/harness-commands/pr-deep-review.md

@@ -2,7 +2,7 @@
 name: pr-deep-review
 description: Use when asked to deeply review a pull request, branch, or diff before merge — deciding whether a change is safe to ship with evidence-backed findings, rather than a shallow "looks good" pass. Produces a `ship it` / `needs fixes` / `blocked` verdict. Also for a batch of sibling PRs. Do not use for self-checking a change you just authored.
 agent: project-manager
-input: "[pr|branch|scope] [full]"
+input: "[pr|branch|scope]"
 ---
 
 # Deep PR Review

package/harness-skills/mstar-audit/references/pr-review.md

@@ -87,7 +87,7 @@ Then open cited code yourself and dispose by-design / mis-attributed / duplicate
 ## Verdict synthesis
 
 - Order findings by impact-if-shipped; no padding, no invented requirements, no style grading.
-- List **every** `must-fix` and `should-fix` finding — the default top 1–3 cut (unless `full`) applies to nits only, and truncated nits are summarized in the display line (§ Output shape / Display contract).
+- List **every** accepted finding — `must-fix`, `should-fix`, and nits alike; nothing is truncated.
 - The verdict is **derived from the tally, not chosen**: classify every accepted finding (§ Merge class) → apply leftover `unmet` AC increments if any (§ Linked-issue hygiene) → apply **Verdict-from-tally** (§ Tally and derived score) → emit that one token. The reviewer does not pick a verdict by vibe.
 - Exactly one verdict:
   - `ship it` — evidence-backed, safe to ship.
@@ -230,7 +230,7 @@ Posting the GitHub Review is a **mandatory deliverable** of the `pr` variant —
 
 ### Report template (GitHub Review `body`)
 
-The posted review body is a three-section report. Section order fixed; omit a subsection only when its content is genuinely empty (write `none`, never delete the heading).
+The posted review body is a three-section report. Section order fixed; omit a subsection only when its content is genuinely empty (write `none`, never delete the heading). The block below shows only **fill-in slots**: a `<...>` that wraps descriptive text (`<verdict>`, `<n>`, `<finding title>`, …) is a slot — replace the whole bracket pair with real content and never render those brackets. The literal HTML tags in the template (`<details>`, `<summary>`, `<br>`) are **structural** — keep them verbatim so the collapsible block survives. The Slot rules below the template are guidance — never copy them into the posted body.
 
 **Section emoji map** — verdict: `ship it` ✅ · `needs fixes` ⚠️ · `blocked` ⛔. Finding classes: 🔴 must-fix · 🟠 should-fix · 🔵 nit · ❓ unverified.
 
@@ -246,36 +246,52 @@ The posted review body is a three-section report. Section order fixed; omit a su
 
 ## 📋 Review
 
-**What this PR does**: <2–3 sentences summarizing the diff's intent and surface — from the PR description plus your own read of the changed files, not copied marketing text.>
+**What this PR does**: <2–3 sentence summary of the diff's intent and surface>
 
 ### Findings
 
-<Ranked findings (§ List cut). Each finding keeps its normal format — title, evidence (`file:line`), impact, **Merge class**, **Confidence**, fix sketch — with its class emoji prefixing the title.>
+#### <class-emoji> <finding title>
+
+- **Evidence**: `file:line` — what the code does
+- **Impact**: why it matters
+- **Merge class**: must-fix | should-fix | nit
+- **Confidence**: HIGH | MEDIUM | LOW
+- **Fix sketch**: one-line suggestion
 
 ### Linked-issue AC
 
-<When § Linked-issue hygiene applied: per-criterion met / unmet / cut with one-line reasoning. Otherwise `none`.>
+<per-criterion: met / unmet / cut — one-line reasoning, or `none`>
 
 ### ✅ Verified
 
-<Concise what-checks-proved summary — the smallest runtime checks actually run and what they showed. Residual unverified leads go here as `- ❓ <lead>` lines, not into the findings table.>
+- <check or command> → <what it showed>
+- ❓ <unverified lead, if any>
 
 ### 🗑️ Considered & rejected
 
-<- <finding>: rejected because <one line>. Otherwise `none` — rejections come from the three-way attack / vet pass (§ Attack and vet), so the next reviewer does not re-chase them.>
+- **<short finding title>**: rejected — <one-line reason>
 
 ## 🛠️ Plan to fix
 
-<details><summary>展开修复计划 / Expand fix plan</summary>
+<details><summary>Expand fix plan</summary>
 <br>
 
 ```md
-<Fix plan in markdown when the audit produced one: ordered steps per finding, files touched, verification gates. Omit the block entirely only when no fix is proposed.>
+<fix plan in markdown>
 ```
 
 </details>
 ````
 
+**Slot rules (guidance — not part of the posted body):**
+
+- **What this PR does**: from the PR description plus your own read of the changed files, not copied marketing text.
+- **Findings**: ranked by impact-if-shipped (§ Verdict synthesis); every accepted finding listed, nothing truncated; repeat the `#### <class-emoji> <title>` block per finding.
+- **Linked-issue AC**: fill only when § Linked-issue hygiene applied; otherwise a bare `none`.
+- **Verified**: the smallest runtime checks actually run and what they showed; unverified leads as `❓` lines here, never in the findings table.
+- **Considered & rejected**: one bullet per rejected candidate from the three-way attack / vet pass (§ Attack and vet), so the next reviewer does not re-chase it; bare `none` when nothing was rejected.
+- **Plan to fix**: fix plan in markdown (ordered steps per finding, files touched, verification gates); follow-up plan index folds in above the ```md block (§ Folding plans); when there is no fix plan, replace the whole `<details>` block with a single line `none`.
+
 - The Verdict section replaces the old two-line tally header on GitHub: same facts (verdict token + `score_pct` as Confidence + four-class tally), structured. The chat display contract (§ Display contract) is unchanged.
 - When the fix plan itself contains fenced code blocks, open the outer fence with four backticks so the inner fences survive.
 
@@ -353,6 +369,3 @@ Then ranked findings / leftover AC summary. Do not put `score_pct%` on the `- ve
 
 The GitHub Review `body` no longer uses the two-line header — it follows § Report template, whose Verdict section carries the same facts structured (verdict token + Confidence + four-class emoji tally table).
 
-### List cut
-
-The default "top 1–3 unless `full`" applies to **nits only**: every `must-fix` and `should-fix` finding is listed. If nits are omitted from the narrative list, add one line `nits: <n> omitted from list (counted in tally)` — `tally.nit` stays complete.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mstar-harness/opencode",
-  "version": "3.2.4",
+  "version": "3.2.6",
   "description": "Morning Star harness OpenCode plugin — skills bootstrap + engine-backed runtime hooks (status lint, dispatch validation, Enforcement: hard gates).",
   "license": "MIT",
   "repository": {