@mstar-harness/dsh 3.2.1 → 3.2.3

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

@@ -1,6 +1,6 @@
 ---
 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 review` / `blocked` verdict. Also for a batch of sibling PRs. Do not use for self-checking a change you just authored.
+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]"
 ---
@@ -9,6 +9,8 @@ input: "[pr|branch|scope] [full]"
 
 Run a read-only, evidence-first deep review of a pull request, branch, or diff and decide whether it is safe to ship. When a PR number exists, posting the GitHub Review is **mandatory** — the review is not complete until comments land on the PR. Output: verdict + findings presented to the user, plus the posted review URL. Never auto-approve, never REQUEST_CHANGES, never merge.
 
+The verdict is **computed from the finding tally** (`must-fix` / `should-fix` / `nit` + `unverified`); `score_pct` is display-only feedback and never overrides it. Procedure and formula → **`references/pr-review.md`** § Verdict synthesis / Tally and derived score.
+
 **Read-only advisory.** The review does not enter the harness plan state machine (`Todo → InProgress → InReview → Done`). Reviewers never edit the worktree, never merge, and never approve-as-merge.
 
 ## Boot

package/harness-skills/mstar-audit/SKILL.md

@@ -25,7 +25,7 @@ A read-only advisory skill that discovers what is worth doing in a codebase and
 Two entry families, one skill:
 
 - **Full codebase audit** — user asks: "audit my codebase", "what should I improve", "find bugs/security/perf issues", "what tech debt do we have", "what should I build next"; PM routes a request with `Task category: audit`; before a major refactoring initiative; as input to iteration planning. Process detail → **`references/codebase-audit.md`**.
-- **Deep PR review** — user asks to deeply review a pull request / branch / diff before merge (verdict `ship it` / `needs review` / `blocked`). Process detail → **`references/pr-review.md`**.
+- **Deep PR review** — user asks to deeply review a pull request / branch / diff before merge (verdict `ship it` / `needs fixes` / `blocked`). Process detail → **`references/pr-review.md`**.
 
 ## Variant dispatch
 
@@ -91,7 +91,7 @@ Do not write 30 plans nobody asked for. If running non-interactively (no user av
 The output contract is common; per-variant output shapes live in the variant reference.
 
 - **Full codebase audit**: audit index `README.md` template (findings table, direction, execution order & status, considered-and-rejected, red-team dispositions) and the `mstar audit scaffold` Engine-check callout → **`references/codebase-audit.md`** § Output format. Plan writing → **`## Plan output (all variants)`** below.
-- **PR review**: `findings` / `verdict` / `evidence` / `unverified` / `next` / `notes` / `comments` labels → **`references/pr-review.md`** § Output shape.
+- **PR review**: `findings` / `verdict` / `score_pct` / `tally` / `evidence` / `unverified` / `next` / `notes` / `comments` → **`references/pr-review.md`** § Output shape.
 - Every finding follows **`references/finding-format.md`** — read it before the first finding.
 
 ## Plan output (all variants)

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

@@ -1,6 +1,6 @@
 # Deep PR Review Process
 
-Read-only, evidence-first review of a pull request / branch / diff, producing exactly one verdict: `ship it` / `needs review` / `blocked`. Runs under `mstar-audit` § `pr` variant, reusing the Recon → Audit → Vet discipline (recon = PR scope + repo guidance; vet = three-way attack). The reviewer never edits the worktree, never merges, and never approves-as-merge.
+Read-only, evidence-first review of a pull request / branch / diff, producing exactly one verdict: `ship it` / `needs fixes` / `blocked`. Runs under `mstar-audit` § `pr` variant, reusing the Recon → Audit → Vet discipline (recon = PR scope + repo guidance; vet = three-way attack). The reviewer never edits the worktree, never merges, and never approves-as-merge.
 
 ## Worktree isolation
 
@@ -86,20 +86,92 @@ Then open cited code yourself and dispose by-design / mis-attributed / duplicate
 
 ## Verdict synthesis
 
-- Order findings by impact-if-shipped.
-- Cut to the top 1–3 unless `full` was requested.
-- No padding, no invented requirements, no style grading.
-- Choose exactly one verdict:
+- 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).
+- 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.
-  - `needs review` — issues found; address before merge.
+  - `needs fixes` — issues found; address before merge.
   - `blocked` — a must-fix issue stands in the way of shipping.
 
+## Merge class (PR findings only)
+
+Classify each **accepted** finding (after three-way vet) as exactly one class. Do not invent a fourth class. Do not derive class from `Confidence`.
+
+| Class | Use when | Verdict effect |
+| --- | --- | --- |
+| `must-fix` | Shipping this issue is unsafe: correctness bug, security hole, data loss, auth/authz bypass, or a broken public contract. Same meaning as today's `blocked` gloss ("a must-fix issue stands in the way of shipping"). | Any count ≥ 1 → `blocked` |
+| `should-fix` | A real issue that should be addressed before merge but is not itself a ship-stopper. Same meaning as today's middle gloss ("issues found; address before merge"). | Else if count ≥ 1 → `needs fixes` |
+| `nit` | Optional cleanup, naming, comment, or small suggestion that does **not** change merge-readiness. Lint-covered cosmetics stay ignored (existing lens rule) — they are not findings. | Does not change verdict |
+
+Tie-break: unsafe to ship → `must-fix`; should be addressed before merge but ship-safe → `should-fix`; otherwise `nit`. A LOW-confidence smell that fails evidence rules is **not** a finding (existing disqualify rules) — put it on `- unverified:` if it must be mentioned.
+
+Field placement: on each finding, `- **Merge class**: must-fix | should-fix | nit`, immediately after `Confidence` (before `Fix sketch`). The shared finding template (`references/finding-format.md`) is unchanged — this field is PR-review-only.
+
+## Tally and derived score
+
+Verbatim, applied after the three-way vet to **accepted** findings, then leftover unmet ACs:
+
+```
+must_fix   = count of accepted findings with Merge class: must-fix
+should_fix = count of accepted findings with Merge class: should-fix
+nit        = count of accepted findings with Merge class: nit
+unverified = count of residual items under `- unverified:` (0 when `none`)
+
+# leftover unmet ACs (§ Linked-issue hygiene) — tally increment, not a fourth class, not a second finding:
+for each leftover AC marked unmet (not met, not cut):
+    if that leftover is itself unsafe-to-ship / a broken public contract:
+        must_fix += 1
+    else:
+        should_fix += 1
+
+if must_fix >= 1:
+    verdict = blocked
+else if should_fix >= 1:
+    verdict = needs fixes
+else:
+    verdict = ship it
+```
+
+`score_pct` — integer arithmetic only. Floor at 0. No decimals. No second formula:
+
+```
+score_pct = max(0, 100 - 40*must_fix - 15*should_fix - 3*nit - 10*unverified)
+```
+
+### Override invariant
+
+```
+Score never overrides verdict.
+blocked + any score_pct       → not shippable
+needs fixes + any score_pct   → still address findings before merge
+ship it + score_pct < 100    → allowed (nits and/or unverified deducted)
+High score_pct never means APPROVE. Low score_pct never means REQUEST_CHANGES.
+```
+
+### Worked examples (check table)
+
+| must / should / nit / unverified | score_pct | verdict | Display line |
+| --- | --- | --- | --- |
+| 0 / 0 / 0 / 0 + 1 leftover unmet AC | 85 | `needs fixes` | `needs fixes · 85%` |
+| 0 / 0 / 0 / 0 + 1 leftover unmet AC (unsafe-to-ship) | 60 | `blocked` | `blocked · 60%` |
+| 0 / 0 / 2 / 0 | 94 | `ship it` | `ship it · 94%` |
+| 0 / 0 / 0 / 2 | 80 | `ship it` | `ship it · 80%` |
+| 0 / 1 / 0 / 0 | 85 | `needs fixes` | `needs fixes · 85%` |
+| 0 / 1 / 1 / 0 | 82 | `needs fixes` | `needs fixes · 82%` |
+| 1 / 0 / 0 / 0 | 60 | `blocked` | `blocked · 60%` |
+| 1 / 2 / 1 / 1 | 17 | `blocked` | `blocked · 17%` |
+| 3 / 0 / 0 / 0 | 0 (floor) | `blocked` | `blocked · 0%` |
+
+`blocked · 60%` is still not shippable. `needs fixes · 85%` still means address findings.
+
 ## Linked-issue hygiene
 
 If the PR closes/fixes a tracked issue, score **every** acceptance criterion against the diff:
 
 - Mark each: met / unmet / cut.
-- Leftover criteria get a follow-up or a narrowed scope **before** merge, with reasoning on the review comment.
+
+Leftover `unmet` criteria count against the verdict: they are **tally increments**, not extra findings (do not also emit a Merge-class finding for the same leftover — that would double-count). Each leftover AC marked `unmet` (not `met`, not `cut`) increments `should_fix` by 1, or `must_fix` by 1 when that leftover is itself a broken public contract / unsafe-to-ship. The increment lives in the tally procedure (§ Tally and derived score); apply Verdict-from-tally **after** it, so leftover `unmet` ACs cannot yield `ship it`. Score uses the existing formula only (`should_fix` deducts 15, `must_fix` deducts 40 — no second formula, no new tally key). Leftovers are already mentioned in the review `body` (§ Comment posting) — no fourth merge class.
 - Do not invent a follow-up when all criteria landed.
 
 ## CI attribution
@@ -145,7 +217,7 @@ Posting the GitHub Review is a **mandatory deliverable** of the `pr` variant —
 2. Build one review payload:
    - `event`: `COMMENT` — **never** `APPROVE`, **never** `REQUEST_CHANGES`, never a merge.
    - `commit_id`: the PR head SHA.
-   - `body`: verdict + ranked findings (short) + linked-issue leftover reasoning + optional folded plan index (below).
+   - `body`: follow **§ Report template (below)** — three sections (Verdict → Review → Plan to fix). `event` stays `COMMENT` — **never** `APPROVE`, **never** `REQUEST_CHANGES`, never a merge.
    - `comments[]`: one entry per finding whose `path` + `line` is in the three-dot diff, `side: RIGHT`. Finding body = title + evidence + impact + fix sketch — not the whole plan.
 3. Post it:
    ```
@@ -156,25 +228,77 @@ Posting the GitHub Review is a **mandatory deliverable** of the `pr` variant —
 5. Record `html_url` / review id for `comments:`. Only now clean up the worktree (or after the n/a-no-PR skip).
 6. **Batch:** each reviewer posts on **their own PRs** only. No second PM summary comment unless the Assignment says so.
 
-### Folding plans into the summary
+### 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).
+
+**Section emoji map** — verdict: `ship it` ✅ · `needs fixes` ⚠️ · `blocked` ⛔. Finding classes: 🔴 must-fix · 🟠 should-fix · 🔵 nit · ❓ unverified.
+
+````markdown
+## <verdict-emoji> Verdict: `<verdict>` · Confidence <score_pct>%
+
+| Findings | Count |
+| --- | --- |
+| 🔴 must-fix | <n> |
+| 🟠 should-fix | <n> |
+| 🔵 nit | <n> |
+| ❓ unverified | <n> |
+
+## 📋 Review
 
-Fold follow-up plans into the review body **only if** this review wrote them. A short index — title, priority, effort, 1–3 sentence sketch, plan path — inside:
+**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.>
 
+### 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.>
+
+### Linked-issue AC
+
+<When § Linked-issue hygiene applied: per-criterion met / unmet / cut with one-line reasoning. Otherwise `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.>
+
+### 🗑️ 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.>
+
+## 🛠️ Plan to fix
+
+<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.>
 ```
-<details><summary>Follow-up plans</summary>
 
-- <plan title> — P1 / S — <1–3 sentence sketch> (`{PLAN_DIR}/audit-<date>/NNN-<slug>.md`)
 </details>
+````
+
+- 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.
+
+### Folding plans into the summary
+
+Fold follow-up plans into the review body **only if** this review wrote them. Put a short index — title, priority, effort, 1–3 sentence sketch, plan path — as the first content inside the § Report template **Plan to fix** `<details>` block, before the ```md fix-plan block:
+
+```
+- <plan title> — P1 / S — <1–3 sentence sketch> (`{PLAN_DIR}/audit-<date>/NNN-<slug>.md`)
 ```
 
 Never dump full plan files.
 
 ## Output shape
 
-Verbatim labels, in order:
-
-- `- findings:` — list of evidence-backed findings (`none` when none).
-- `- verdict:` — one of `ship it` / `needs review` / `blocked`.
+- `- findings:` — list of evidence-backed findings (`none` when none). Each accepted finding includes **Merge class** (§ Merge class).
+- `- verdict:` — exactly one of `ship it` / `needs fixes` / `blocked` (§ Verdict synthesis).
+- `- score_pct:` — integer 0–100 from the locked formula (§ Tally and derived score).
+- `- tally:`
+  - `- must-fix: <n>`
+  - `- should-fix: <n>`
+  - `- nit: <n>`
+  - `- unverified: <n>`
 - `- evidence:` — concise what-checks-proved summary.
 - `- unverified:` — residual unverified claims, or `none`.
 - `- next:` — one of `implementation` / `verify` / `docs`.
@@ -184,3 +308,20 @@ Verbatim labels, in order:
   - `review_url: <url>` when `posted: yes`; `n/a` when `n/a-no-pr` or `failed`
   - `inline: <N> posted / <M> attempted (<K> summary-only fallback)`
   - `plans_folded: yes` | `no`
+
+### Display contract (chat output)
+
+First two lines of the **chat** display — verbatim:
+
+```
+{verdict} · {score_pct}%
+must-fix=<n> should-fix=<n> nit=<n> unverified=<n>
+```
+
+Then ranked findings / leftover AC summary. Do not put `score_pct%` on the `- verdict:` token line.
+
+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/harness-skills/mstar-harness-core/SKILL.md

@@ -123,7 +123,7 @@ Read **`mstar-host`** after this skill; detect host per its table, then Read the
 
 ## 护栏（不变量）
 
-- 未经用户同意不改 `opencode.json`、凭据、`secrets.env`。
+- 未经用户同意不改宿主配置文件与用户凭据。
 - 行为变更须有验证证据。
 - 业务仓默认功能分支（Assignment `Branch policy` 例外）→ **`mstar-branch-worktree`**。
 - **Dev 三角**：`@fullstack-dev` 后端主导；UI → `@frontend-dev`；第二轨 → `@fullstack-dev-2`（`mstar-roles` PM 节）。

package/harness-skills/mstar-roles/references/_shared/leaf-executor-core.md

@@ -59,7 +59,7 @@ All leaf executors share these anti-recursion red lines (role-specific sibling l
 When the assignment is a review/audit dispatch — `Task category: audit`, `Audit mode: on`, or a `pr-deep-review` batch seat — the executor operates as a **read-only audit seat**, not an implementer:
 
 - **Permission contract**: no tracked-file writes, no `edit`/`write`/`ast_edit` on the reviewed worktree, no merge, no approve-as-merge. The write permissions the role normally has are **suspended for the assignment**; do not "fix things while reviewing". **Required exception (`pr-deep-review` with a PR number):** the GitHub Review POST (`gh api` Reviews POST, `event: COMMENT`) **must** be posted — it is the deliverable, not a source-code mutation; Git stays read-only with no commits. Procedure → **`skills/mstar-audit/references/pr-review.md`** § Comment posting.
-- **Process**: load `mstar-audit` (`pr` variant or audit process) + its references + `mstar-coding-behavior` evidence discipline; run the concern-lens review and the three-way attack; produce `findings` + `verdict` (`ship it` / `needs review` / `blocked` for PR review) + `unverified` in the `pr-deep-review` output shape.
+- **Process**: load `mstar-audit` (`pr` variant or audit process) + its references + `mstar-coding-behavior` evidence discipline; run the concern-lens review and the three-way attack; produce `findings` + `verdict` (`ship it` / `needs fixes` / `blocked` for PR review) + `unverified` in the `pr-deep-review` output shape.
 - **Mode lock**: one assignment = one mode. Review-assigned work is completed as review only; implementation mode applies to implementation assignments only.
 - **Completion Report**: `Git:` states `read-only, no commits`. **Artifacts** must include `comments.posted` and match the `pr` variant output shape — do **not** collapse failure into `n/a-no-pr`:
   - `posted: yes` → Status `Done`; Artifacts include `comments.review_url`

package/harness-skills/mstar-roles/references/code-reviewer.md

@@ -80,7 +80,7 @@ Follow `mstar-audit` output format — audit index `README.md` (findings table,
 
 ### Output (Mode C)
 
-Follow the `pr` variant output shape in **`references/pr-review.md`** § Output shape — `findings` / `verdict` / `evidence` / `unverified` / `next` / `notes` / `comments` — including the posted review URL.
+Follow the `pr` variant output shape in **`references/pr-review.md`** § Output shape — `findings` / `verdict` / `score_pct` / `tally` / `evidence` / `unverified` / `next` / `notes` / `comments` — including the posted review URL.
 
 ## Non-Recursive Dispatch Rule (Hard)
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mstar-harness/dsh",
-  "version": "3.2.1",
+  "version": "3.2.3",
   "description": "Morning Star harness dsh (DeepSeek Harness) cordis function plugin — in-process engine gates (status/dispatch/lease) with hard refusal channels.",
   "keywords": [
     "dsh",