octopus-workflow/core/skills/review-artifact/SKILL.md

---
name: review-artifact
description: >-
  Use ONLY after analyze-dag has produced the DAG artifact — review the task DAG (review-dag single gate) — OR when auditing the <instance-root>/ process infrastructure itself (audit-process).   Spawns N parallel Explorer reviewers (1 dimension each) against the matching checklist, synthesizes findings with a Worker Synthesizer, and iterates with a Worker reviser until convergence. The legacy roadmap / design-space / iteration-plan targets were archived 2026-08-21 ([org-internal #3072] phase 3, <instance-root>/archive/). Do NOT use for code review — use the review-code skill for that.
triggers:
  - audit-process
  - review-dag
  - dag review
  - DAG 评审
  - process audit
  - parallel review
  - reviewer
  - checklist review
  - mandatory gate
# `stage` is set to the primary gate `audit-process`; the second live target
# (review-dag) carries its own stage id in the Target Selection table below.
stage: audit-process
role: Reviewer
---

> Core 中立版（Increment 6a 改写，原 deferHard verbatimDir）。机制、结构与 frontmatter 保持；实例术语（工具名、路径、工单号）按 `core/adapters/TERMINOLOGY.md` 绑定到具体实例。

# Skill: review-artifact

## Tool Availability & Path Resolution

This skill's reviewers (parallel Explorer subagents) read two kinds of files.
Some runs lack the `gitea_wiki__*` MCP tools (cross-repo scenario, [org-internal #2115]); the
fallbacks below keep reviews working without them.

The Orchestrator probes availability **before dispatching reviewers** (Phase A
step 1, `_shared/review-pipeline-phases.md`) and fails fast if neither path is
usable, so every reviewer has a working read path by the time it runs.

### Wiki artifacts (DAG artifact / review reports)

- **Primary**: `wiki 读写 API（见 TERMINOLOGY）(owner, repo, page_name)` — use when the
  tool is available. `page_name` construction is in
  `_shared/gitea-read-patterns.md` Pattern 1.
- **Fallback** (when `gitea_wiki__*` is unavailable): read the **local wiki
  clone** at `<wiki-clone-root>/{repo}-wiki/` — a git checkout of the wiki repo,
  kept current. Wiki filenames are URL-encoded (`/` → `%2F`, with a possible
  `.-` before `.md`), so resolve the file with `glob` rather than constructing
  one fixed path:

  ```
  glob(pattern="*{slug}*{page-title}*.md", path="<wiki-clone-root>/{repo}-wiki/")
  # then read the returned path
  ```

### Checklists (`core/checklists/*.md`)

`<instance-root>/` **is git-tracked** (skills, checklists, rules — only runtime
artifacts under `<instance-root>/locks/`, `entropy-baseline.json`, etc. are
gitignored). Therefore the relative paths referenced throughout this skill
(`core/checklists/dag-single-gate.md`, etc.) **resolve correctly inside
any git worktree** — no absolute path is needed.

- **Primary**: read `core/checklists/<name>.md` relative to the project /
  worktree root (the reviewer subagent's CWD).
- **Fallback** (non-standard CWD only): read from the main project directory,
  e.g. `/data/{repo}/core/checklists/<name>.md`.

## Target Selection

This skill reviews different artifact types. Identify the target from the pipeline stage that triggered the review:

| Target | Stage ID | Checklist | Dimensions | Revision Role | Output namespace |
|---|---|---|---|---|---|
| **process** | `audit-process` | `core/checklists/audit-process.md` | 10 | Remediator | `audit/{date}/` |
| **review-dag** | `review-dag` | `core/checklists/dag-single-gate.md` | 3 | Analyst | `{epic-slug}/reviews/review-dag/` |

> **Retired targets (historical)**: the `roadmap`, `design-space`, and `plan`
> targets were archived on 2026-08-21 per [org-internal #3072] phase 3 (ruling:
> `docs/workflow-refactor/phase3-retirement-ruling.md`) — the legacy
> production skills they gated no longer exist (see `<instance-root>/archive/`).
> Their stage ids (`review-roadmap`, `review-design-space`,
> `review-iteration-plan`) were retired from the stage registry in the same
> ruling. Historical review pages under `{slug}/reviews/roadmap|design-space|plan/`
> remain readable; no new reviews run against those targets.

The stage IDs remain as-is — they are used by the stage registry and auto-approve system. The skill name is `review-artifact`, but the stage IDs do not change.

> **Progressive disclosure ([org-internal #3734])**: this skill has two disjoint live
> targets — dispatch an auditor/reviewer with
> `skills: ["review-artifact:target-process"]` or
> `["review-artifact:target-review-dag"]` (preamble + that target only)
> instead of the full body. Tool availability, target selection, and shared
> pipeline mechanics are unmarked preamble and always inject. Full-body
> remains the default when no selector is passed.

## Shared Pipeline Mechanics

This skill follows the standardized parallel-review pipeline. The full mechanics are in:

- `<!-- inject: ../_shared/review-pipeline-phases.md -->` — Phase A through Phase E
  - **Phase A step 0**: move the source issue to the `review` column on the
    Pipeline Stages board per `_shared/gitea-write-patterns.md` Pattern 7.5
    (see `_shared/review-pipeline-phases.md` for the canonical orchestrator
    actions — step 0 is now part of the shared flow).
- `<!-- inject: ../_shared/review-orchestrator-rules.md -->` — mandatory orchestrator rules
- `<!-- inject: ../_shared/review-final-report-template.md -->` — final report format
- `<!-- inject: ../_shared/review-revision-prompt.md -->` — Phase C revision prompt template
- `<!-- inject: ../_shared/compaction-round-boundary.md -->` — round-boundary compaction procedure (Phase D)

**Context compaction**: this skill compacts at every review round ≥ 2. The
round-boundary procedure (`compaction-round-boundary.md`) is injected directly
above — that is the normative source; do not restate it here. At the stage
level, the main session also compacts after this skill converges, per
`core/rules/compact.md` §"Stage-boundary compaction".

Each target binds the canonical phase placeholders and defines target-specific overrides in its section below.

### JSON Schemas

| Schema File | Used For |
|---|---|
| `core/schemas/reviewer-output.schema.json` | Per-dimension reviewer findings |
| `core/schemas/synthesis.schema.json` | Orchestrator round synthesis |
| `core/schemas/review-status.schema.json` | Review lifecycle tracking |

### Reviewer Prompt

The Orchestrator MUST use the standardized reviewer prompt template at `core/skills/_shared/review-reviewer-prompt.md` when dispatching each reviewer. The template is the same for all reviewers; the Orchestrator fills in skill-level constants and per-dimension values. Each target defines its own constants in its section below.

### Agent Roles

| Role | Agent Type | Count | Responsibility |
|---|---|---|---|
| Orchestrator | Worker | 1 | Spawns reviewers, reads synthesis, drives revision loop |
| Reviewer | Explorer | N (per target) | Reviews ONE dimension, outputs structured JSON |
| Revision Role | Worker | 1 | Processes findings, revises artifact (role varies by target) |

All reviewers run in parallel. The orchestrator and revision role run sequentially.

### Preconditions

Before launching any review, confirm:
- [ ] The target artifact exists (source varies by target: wiki pages for
  review-dag; the local `<instance-root>/` corpus for audit-process — no upstream
  producer, self-authored).
- [ ] The matching checklist is accessible (see target selection table above).
- [ ] `core/schemas/` contains the shared review schemas (`reviewer-output`, `synthesis`, `review-status`).
- [ ] `slug` is known (for process audits, `slug` is the literal `audit`).

Each target adds specific preconditions listed in its section below. If any precondition is unmet, abort and inform the user.

> ## Retired targets (historical, [org-internal #3072] phase 3)

The three legacy production-review targets — **roadmap** (stage
`review-roadmap`, checklist `roadmap.md`, revision role Analyst),
**design-space** (stage `review-design-space`, checklists
`requirements-analysis.md` + `design.md`, revision role Architect), and
**plan** (stage `review-iteration-plan`, checklist `iteration-plan.md`,
revision role Planner) — were archived on 2026-08-21 together with the
production skills they gated (ruling:
`docs/workflow-refactor/phase3-retirement-ruling.md`; skills and exclusive
checklists/templates recoverable under `<instance-root>/archive/`). Their stage ids
are retired from the stage registry; no new reviews run against them, and
historical review pages under `{slug}/reviews/{roadmap|design-space|plan}/`
stay readable as produced. Live targets: **process** (below) and
**review-dag** (single gate).
---

<!-- section:target-process -->
## Target: process (audit)

The audit target is the **SDLC factory itself** — the set of skills, checklists, templates, and schemas under `<instance-root>/` — judged for internal consistency, cross-reference integrity, and conformance to audit standards (ISO 19011:2018, IEEE 1028-2008) and `AGENTS.md` conventions.

**Scope boundary**: This skill audits the *definition* of the pipeline. It does NOT audit whether a project *followed* the pipeline — that is the `retrospective` skill's responsibility.

### Audit Subject

| Area | Path | What is audited |
|---|---|---|
| Skills | `core/skills/**/SKILL.md` | Frontmatter, references, pipeline wiring |
| Checklists | `core/checklists/*.md` | Coverage, orphans, dimension count match |
| Templates | `core/templates/*.md` | Orphans, referenced existence |
| Schemas | `core/schemas/*.json` | Validity, field alignment with skill text |
| Conventions | `AGENTS.md` | Engineering-convention conformance |

### Preconditions

- [ ] `core/skills/` exists and contains at least one `SKILL.md`.
- [ ] `core/checklists/audit-process.md` is accessible.
- [ ] `core/schemas/` contains the shared review schemas (`reviewer-output`, `synthesis`, `review-status`).

No `.artifacts/{slug}/` inputs are required — the audit reads `<instance-root>/` itself. Audit outputs are published as Gitea wiki pages under `audit/{date}/`.

### Audit Dimensions

| # | Dimension | Label | Checklist Ref | Files to Read |
|---|---|---|---|---|
| 1 | INV | Inventory Completeness | INV 1.1–1.7 | `core/skills/` tree, `checklists/`, `templates/`, `schemas/` listings |
| 2 | XREF | Cross-Reference Integrity | XREF 2.1–2.7 | ALL `SKILL.md`; resolve every referenced path |
| 3 | FM | Frontmatter Conformance | FM 3.1–3.7 | Frontmatter block of every `SKILL.md` |
| 4 | NAM | Naming Convention | NAM 4.1–4.6 | ALL `SKILL.md`, checklist filenames, schema enums |
| 5 | FLOW | Pipeline Cohesion | FLOW 5.1–5.6 | Preconditions + output sections of every `SKILL.md` |
| 6 | SCH | Schema Contract | SCH 6.1–6.5 | `core/schemas/*.json` + skills that reference them |
| 7 | DUP | Duplication & Drift | DUP 7.1–7.4 | ALL `SKILL.md` + ALL `checklists/*.md` |
| 8 | STD | Audit Standards (ISO/IEEE) | STD 8.1–8.7 | `review-*` skills, `review-artifact` (target: `audit-process`) itself |
| 9 | AGT | AGENTS.md Conformance | AGT 9.1–9.5 | ALL `SKILL.md` + `AGENTS.md` |
| 10 | TRC | Traceability | TRC 10.1–10.5 | `review-*` skills, schemas, status artifacts |

### Phase A Threshold

The process target has 10 dimensions, so Phase A is satisfied when **≥8 of 10
dimension findings are produced after retries** (≥75% coverage). If fewer
than 8 dimension JSONs are available after
retries, abort the round with FAIL — an audit round must not proceed with an
underspecified fraction of dimensions covered. Crashed/timed-out dimensions are
marked `UNRESOLVED` and retried in the next round.

### Auditor Constants

In auditor output, the `dimension` field carries the audit dimension code (INV, XREF, FM, ...) and `slug` in the commit status is the literal `audit`.

The Orchestrator MUST use the standardized auditor prompt template from `core/skills/_shared/review-reviewer-prompt.md` with these constants:

- Model tier: default session reviewer model (`Reviewer` Explorer role, `_shared/roles/reviewer.yaml`) — the process target sets no `reviewer-tier` override; record any assignment change here so sibling review skills stay comparable (TRC 10.5)
- `{REVIEWER_ROLE}`: process auditor
- `{BASELINE_SECTION}`:
  ```
  ## Audit Subject
  You are auditing the <instance-root>/ process infrastructure ITSELF — the SDLC factory of skills, checklists, templates, and schemas. You are NOT auditing any application code, and NOT auditing whether a project followed the process.
  ```
- `{READ_FIRST_STEPS}`:
  1. Read every file listed above. Do NOT skip any file.
  2. For XREF/SCH dimensions: for every path or field referenced in a skill, actually resolve it (Read/Glob) and confirm it exists and matches. A referenced-but-missing path or a field-name mismatch is a finding.
  3. For all other dimensions, read every assigned file and flag any cross-file inconsistency (terminology, numbering, drift) you find.
- `{ARTIFACT_NOUN}`: process infrastructure
- `{FINDING_DETAILS}`: file path and line number, a summary, detailed explanation, and quoted evidence from the file
- `{FINDING_ID_EXAMPLE}`: INV-F001
- `{CONTRADICTION_RULE}`:
  6. (not applicable — the audit is a self-contained inspection, not a baseline comparison)
- `{SEVERITY_DEFINITIONS}`:
   - BLOCKER: broken cross-reference (skill references a non-existent checklist/template/schema/path), missing required frontmatter `description` (skill never triggers), a pipeline stage with no producer for its declared precondition, schema field mismatch that would make written artifacts invalid
   - MAJOR: orphan checklist/template/schema, dimension count mismatch between a review skill and its checklist, naming inconsistency for a dimension code or role, missing convergence/approval gate, AGENTS.md command divergence (e.g. `bun test` instead of `bun run test:parallel`)
   - MINOR: terminology drift, duplicated rule that should live in one place, inconsistent standard-number formatting, missing cross-reference comment
   - INFO: observation or improvement suggestion beyond the checklist
- `{LOOKS_FINE_PHRASE}`: the pipeline looks fine

### Phase Bindings

| Placeholder | Value |
|---|---|
| `{DIMENSION_COUNT}` | 10 |
| `{REVISION_ROLE}` | Remediator |
| `{REVIEW_TYPE}` | audit-process |
| `{STAGE}` | audit-process |
| `{REVIEWER_OR_AUDITOR}` / `{REVIEWER_OR_AUDITOR_NAME}` | auditor / Audit |
| `{REVIEWER_OR_AUDIT_LOOP}` | Re-audit |
| Output mode | Tier 1 local files under `<runs-root>/audit/reviews/audit-process/round{N}/findings-{DIMENSION_CODE}.json` (validated by `core/schemas/reviewer-output.schema.json`); synthesis wiki page + commit status stay Tier 2 |
| Commit status context | `pipeline/audit-process` |
| Wiki namespace | `audit/{date}/` |
| Status tracking | Commit status `pipeline/audit-process` (via REST, `_shared/gitea-write-patterns.md` Pattern 8) — `slug: "audit"` |
| Date resolution | `{date}` resolved as `YYYY-MM-DD` |
| Task file names | `task-synthesizer`, `task-remediator` |

### Phase E — Close-actor (process target)

After the final report is written and the `## 工件索引` REVIEW row is
updated per the shared Phase E step 2, IF this route closes the source issue
(audit-only close, the common Kind/Enhancement process-improvement path that
does NOT run verify), execute archive-at-close per
`core/rules/artifact-index-guards.md` guard #3: edit the index comment
in place — add the canonical archive banner (defined in
`_shared/gitea-write-patterns.md` Pattern 10) above the table, and set
every row's 重读 column to `ARCHIVE`. Mechanism details (single-comment
invariant, no URL deletion, reversibility) per Pattern 10.

### Remediator Constraints

The Remediator revises `<instance-root>/` files. Constraints:
- Do NOT change the meaning of a skill's workflow to satisfy a finding; fix the inconsistency, not the intent.
- Preserve frontmatter `name`/`description` semantics; only correct conformance issues.
- When fixing a broken cross-reference, fix the reference OR create the missing file — whichever preserves the pipeline's intent; explain the choice.

### Output Artifacts

```
<runs-root>/audit/reviews/audit-process/
├── index.json                           # Tier 1 manifest (one row per findings/synthesis/task file; validated by runs-index.schema.json)
├── status.json                          # Review lifecycle tracking (shared Phase A step 0.5; validated by review-status.schema.json)
└── round{N}/
    ├── task-remediator.md               # Remediator input prompt (Tier 1 copy; index row type `remediation-prompt`)
    ├── task-synthesizer.md              # Synthesizer input prompt (Tier 1; index row type `synthesis-prompt`)
    ├── findings-{DIMENSION_CODE}.json   # Auditor dimension findings (Tier 1 local, validated by reviewer-output.schema.json; index row type `review-findings`)
    └── synthesis-return.md              # Synthesizer return summary (index row type `other`)

audit/{date}/                                                # Wiki page hierarchy (Tier 2)
├── round{N}/
│   ├── task-remediator                                      # Remediator input (wiki page)
│   ├── revision-summary                                     # Remediator revision summary
│   └── synthesis                                            # Orchestrator synthesis (```json block, wiki page — audits have no source issue comment)
├── round{N+1}/...
└── final/
    └── report                                               # Final human-readable report
```

> **Wiki namespace override**: the audit target writes `task-{ROLE}`,
> `revision-summary`, `synthesis`, and `final/report` under `audit/{date}/`
> (date-slug), NOT the shared `{slug}/reviews/{stage}/` formula. See the Phase
> Bindings `Wiki namespace` row above and `_shared/review-pipeline-phases.md`
> Phase C step 1 / Phase E step 1 for the audit carve-out.

### References

- `core/checklists/audit-process.md` — The authoritative checklist for all 10 audit dimensions
- `core/schemas/` — Shared JSON schemas (reviewer-output, synthesis, review-status) reused by this audit
- `retrospective` skill — Complementary: audits a project's *adherence* to the process; this skill audits the process *definition* itself
- ISO 19011:2018 — Guidelines for auditing management systems (independence, evidence-based, documented)
- IEEE 1028-2008 — Software Reviews and Audits (completeness, repeatability, severity classification)

---

<!-- section:target-review-dag -->
## Target: review-dag

The DAG review is a **single gate** (spec-02 §1 D-02) that replaces `review-design-space` +
`review-iteration-plan` for a DAG artifact. It reviews one artifact — the DAG
at wiki page `{epic-slug}/dag` (NOT per-size-tier pages) — against
`core/checklists/dag-single-gate.md` with three fixed dimensions. It saves
orchestration overhead, not the revision loop — the three dimensions each
review an independent risk surface.

### Preconditions

- [ ] The DAG artifact exists at wiki page `{epic-slug}/dag` (read via `wiki 读写 API（见 TERMINOLOGY）`).
- [ ] The DAG's `dag_metrics.review_depth` is set (D1–D4) — review depth, reviewer count, `dim_split`, and the Phase D round cap are all derived from this field, NOT from `Size/*` labels.
- [ ] `core/checklists/dag-single-gate.md` is accessible.
- [ ] `{epic-slug}` is known.

### Review Dimensions

Fixed dimension ids — do NOT rename:

| # | Dimension | Label | Checklist Ref | Files to Read |
|---|---|---|---|---|
| 1 | TOPO | Topology | `core/checklists/dag-single-gate.md` §TOPO | `{epic-slug}/dag` |
| 2 | REQMAP | Requirement Mapping | `core/checklists/dag-single-gate.md` §REQMAP | `{epic-slug}/dag` (+ `{epic-slug}/dag-nodes/{node-id}` subpages when AC detail is sunk) |
| 3 | RELEASE | Rolling Release | `core/checklists/dag-single-gate.md` §RELEASE | `{epic-slug}/dag` |

> **REQMAP reviews task nodes only** — milestone nodes carry no `req_refs` /
> `acceptance_criteria` (only a DoD) and are not part of the REQMAP surface.

### Review Depth (from `dag_metrics.review_depth`)

Review depth is derived from the DAG's `dag_metrics.review_depth` (D1–D4), NOT
from `Size/*` labels.

| Depth | Reviewers | dim_split |
|---|---|---|
| D1 | 1 | `all` |
| D2 | 3 | `TOPO:1 REQMAP:1 RELEASE:1` |
| D3 | 5 | `TOPO:2 REQMAP:2 RELEASE:1` |
| D4 | 5 ([org-internal #3061] cap) | `TOPO:2 REQMAP:2 RELEASE:1` |

> **D4 cap ([org-internal #3061])**: D4 keeps its own rounds budget (4) but its fanout is
> capped at D3 level (5 reviewers) — under the 3-dimension + checklist-bound
> review the marginal coverage of 9 reviewers was redundancy, and round
> iteration is the backstop.

### Reviewer slots & findings files (dim_split > 1)

`dim_split` may assign MORE THAN ONE reviewer to a dimension (D3/D4
`TOPO:2`). Each reviewer within a dimension occupies a 1-based **slot**
and writes its OWN findings file — parallel reviewers must never share one
file (concurrent write race):

- 1 reviewer on the dimension → `findings-{DIM}.json` (unchanged shape).
- n > 1 reviewers → `findings-{DIM}-r{k}.json`, k = 1..n — e.g. a D3/D4 round
  (dim_split `TOPO:2 REQMAP:2 RELEASE:1`) produces `findings-TOPO-r1.json` /
  `-r2.json`, `findings-REQMAP-r1.json` / `-r2.json`, and a single
  `findings-RELEASE.json` (RELEASE has one reviewer at every depth ≥ D2).
- Multi-slot findings JSONs MUST set `reviewer_slot` (their k) and
  `reviewer_count` (n) — optional fields in
  `core/schemas/reviewer-output.schema.json`. Finding ids inside slot
  files MUST be slot-prefixed (`{DIM}R{k}-F{NNN}`, e.g. `TOPOR1-F001`) so ids
  stay unique across a dimension's slot files. This preserves per-reviewer
  attribution (retrospective overlap analysis, [org-internal #2996] step ①a) and makes the
  write race impossible by construction.
- Synthesis input for a dimension = ALL `findings-{DIM}*.json` in the round
  directory — the synthesizer already globs every `findings-*.json`; the slot
  files of one dimension aggregate as that dimension's findings.
- Phase A's "dimension produced" check: a dimension counts as produced only
  when EVERY assigned slot's file exists.

### Reviewer Constants

- Model tier: `reviewer-tier` (per `analyze-dag` §Exec-Resource Configuration — reviewer-tier's only allowed consumer; corresponds to the `Reviewer` Explorer role, `_shared/roles/reviewer.yaml`)
- `{REVIEWER_ROLE}`: DAG reviewer
- `{BASELINE_SECTION}`:
  ```
  ## Baseline
  The artifact under review is the DAG at wiki page `{epic-slug}/dag` (read via `gitea_wiki__get_page`). Read it first for orientation. Its `dag_metrics.review_depth` (D1–D4) sets this review's depth and round cap.
  ```
- `{READ_FIRST_STEPS}`:
  1. Read the DAG artifact at `{epic-slug}/dag` first for orientation.
  2. Read `core/checklists/dag-single-gate.md`.
  3. For REQMAP when AC detail is sunk: follow the `{node-id} → {epic-slug}/dag-nodes/{node-id}` pointers to read the subpage ACs.
- `{ARTIFACT_NOUN}`: DAG artifact
- `{FINDING_DETAILS}`: location in the document, a summary, detailed explanation, quoted evidence from the document
- `{FINDING_ID_EXAMPLE}`: TOPO-F001
- `{CONTRADICTION_RULE}`:
  6. When a DAG element contradicts its own declared topology, requirement mapping, or rolling-release plan, this is at minimum a MAJOR finding. When a required DAG section is entirely absent, this is a BLOCKER.
- `{SEVERITY_DEFINITIONS}`:
   - BLOCKER: cycle in the DAG edge graph (TOPO 环检测), milestone missing at a `cross_session_in ≥ 2` convergence point (TOPO 里程碑位置), ≥3 task nodes below the granularity floor (`estimated_sessions < 0.25`, TOPO 粒度下限), a requirement with zero node coverage (REQMAP 需求覆盖)
   - MAJOR: missing or reversed dependency edge (TOPO 依赖正确性), giant node (`estimated_sessions ≥ 2`) needing split (TOPO 大小均匀性), `estimated_hours`/`estimated_sessions` field inconsistency (`|estimated_hours − 8 × estimated_sessions| > 2`), a single task node below the granularity floor, AC missing error/boundary-path coverage (REQMAP AC 路径覆盖), contract↔node AC inconsistency (REQMAP 契约↔节点一致性), task node with empty/invalid `req_refs` (REQMAP 节点溯源)
   - MINOR: `1 < estimated_sessions < 2` (over-upper-limit, suggest split), formatting issue, missing cross-reference, terminology drift, revision record not initialized
   - INFO: observation or recommendation beyond the checklist, including the TOPO page-size signal (see below) — does not affect any gate verdict
- `{LOOKS_FINE_PHRASE}`: the DAG looks fine

### Phase Bindings

| Placeholder | Value |
|---|---|
| `{DIMENSION_COUNT}` | 3 |
| `{REVISION_ROLE}` | Analyst |
| `{REVIEW_TYPE}` | review-dag |
| `{STAGE}` | review-dag |
| `{REVIEWER_OR_AUDITOR}` / `{REVIEWER_OR_AUDITOR_NAME}` | reviewer / Review |
| `{REVIEWER_OR_AUDIT_LOOP}` | Re-review |
| Output mode | Tier 1 local files under `<runs-root>/{epic-slug}/reviews/review-dag/round{N}/findings-{DIMENSION_CODE}.json` — one file per reviewer slot when dim_split > 1 (`findings-{DIM}-r{k}.json`, see §"Reviewer slots & findings files") — validated by `core/schemas/reviewer-output.schema.json`; synthesis comment + commit status stay Tier 2 |
| Commit status context | `pipeline/review-dag` |
| Wiki namespace | `{epic-slug}/reviews/review-dag/` |
| Task file names | `task-synthesizer`, `task-analyst` |

### Output (single gate)

The review produces a **single-gate synthesis**: the synthesis comment (reusing
`core/schemas/synthesis.schema.json`) uses `dimensions` key =
`TOPO` / `REQMAP` / `RELEASE`, and the commit status context is
`pipeline/review-dag`. Revision role = **Analyst** (the DAG author).

### Phase A Threshold

Unlike the process target (≥8 of 10 dimensions), review-dag has only 3 dimensions, so
Phase A is satisfied when **ALL THREE dimension findings are produced (3/3 = 100%)**.

- "3/3=100%" applies to a **full round** only (all 3 dimensions assigned and produced).
- In a **partial re-review round** (rounds ≥3 re-review only FAIL/WARN/UNRESOLVED dimensions), Phase A is satisfied when the assigned dimensions' findings are all produced.
- In a **full round where one dimension is UNRESOLVED** (e.g. a reviewer crashed, only 2/3 produced), that round proceeds with the produced dimensions and the UNRESOLVED dimension defers to the next partial re-review round — do NOT abort and do NOT apply the 8-file threshold.

### Phase D MAX_ROUNDS (per depth)

review-dag's Phase D convergence loop round cap is read from
`dag_metrics.review_depth`, NOT the shared `review-artifact` skill default of 3:

| Depth | MAX_ROUNDS |
|---|---|
| D1 | ≤2 |
| D2 | ≤3 |
| D3 | ≤3 |
| D4 | ≤4 |

**D4 override**: the shared `review-artifact` skill MAX_ROUNDS is 3 (see
`_shared/review-pipeline-phases.md` Phase D "`{MAX_ROUNDS}` binding"), but
review-dag overrides it per depth. D4 reaches round 4 (≤4), which exceeds the
shared default — the D4 round cap MUST take precedence for review-dag.

### Round-3 Escalation Guardrail interaction

The Round-3 Escalation Guardrail (see `_shared/review-pipeline-phases.md`
Phase D) applies to review-dag. Its interaction with the per-depth round cap:

- **D1–D3** (cap ≤3): the guardrail and the per-depth cap coincide — no conflict.
- **D4** (cap ≤4): when the Round-3 guardrail triggers, it MUST offer the option "(b) 继续进入第 4 轮" (continue into round 4) rather than a hard stop. The guardrail means "escalate to human / give the user a choice", not "force-stop at round 3" — so D4's round 4 is reachable via that option. Independently of the guardrail, entering round 4 at all is gated by the shared **Round-4 user-choice escalation point** (`_shared/review-pipeline-phases.md` Phase D) — the choice is offered unconditionally at the round-3→4 transition, whether or not the guardrail's >50% condition fired.

### TOPO Page-Size Signal

The TOPO reviewer reads the `> 页尺寸自检: 超限` flag at the top of
`{epic-slug}/dag`. If present, the TOPO reviewer records it as an **INFO
finding** in the synthesis — summary = page-size over-limit, with the
acceptance-criteria detail sunk to the `{subpages}` of the DAG. This INFO
finding does NOT change any gate verdict and does NOT trigger re-derivation of
the DAG.

### Output Artifacts

```
<runs-root>/{epic-slug}/reviews/review-dag/
└── round{N}/
    ├── findings-{DIMENSION_CODE}.json        # single-reviewer dimension (Tier 1 local, validated by reviewer-output.schema.json)
    └── findings-{DIMENSION_CODE}-r{k}.json   # one per reviewer slot when dim_split > 1 (D3/D4) — reviewer_slot/reviewer_count set

Wiki: {epic-slug}/reviews/review-dag/
├── round{N}/
│   ├── task-analyst          # Phase C dispatch prompt (wiki page)
│   └── revision-summary      # Analyst revision summary (wiki page)
└── final/
    └── report                # Final human-readable report (wiki page)

Ticket: #{issue_number}
└── synthesis comment         # Orchestrator synthesis (```json block, Tier 2) — dimensions key = TOPO / REQMAP / RELEASE

Commit status: context "pipeline/review-dag"
```

### References

- `core/checklists/dag-single-gate.md` — The authoritative checklist for the 3 review dimensions (TOPO / REQMAP / RELEASE)
- `core/schemas/` — Shared JSON schemas for reviewer output, synthesis, and status
- IEEE 1028-2008 — Software Reviews and Audits
- ISO/IEC/IEEE 24765:2017 — Systems and software engineering vocabulary

---

## References

- `core/checklists/audit-process.md` — Process audit dimensions
- `core/checklists/dag-single-gate.md` — DAG single-gate review dimensions (TOPO / REQMAP / RELEASE)
- `core/schemas/reviewer-output.schema.json` — Per-dimension reviewer findings
- `core/schemas/synthesis.schema.json` — Orchestrator round synthesis
- `core/schemas/review-status.schema.json` — Review lifecycle tracking
- `core/templates/dag.md` — DAG artifact structure contract (review-dag target)
- IEEE 1028-2008 — Software Reviews and Audits
- ISO 19011:2018 — Guidelines for auditing management systems
- ISO/IEC/IEEE 24765:2017 — Systems and software engineering vocabulary