--- 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 / 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, /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 cannot reach the Gitea REST API (cross-repo scenario, [org-internal #2115]); the fallbacks below keep reviews working without it. The Orchestrator probes REST reachability **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**: `GET /api/v1/repos/{owner}/{repo}/wiki/page/{mangled-name}` — use when REST is reachable. Resolve `{mangled-name}` from `GET .../wiki/pages` (`sub_url` — mangled name with `%2F` encoding and possible `.-` suffix); never construct it by hand. Page-name resolution context is in `_shared/gitea-read-patterns.md` Pattern 1. - **Fallback** (when REST is unreachable): read the **local wiki clone** at `/{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="/{repo}-wiki/") # then read the returned path ``` ### Checklists (`core/checklists/*.md`) `/` **is git-tracked** (skills, checklists, rules — only runtime artifacts under `/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/.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/.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 `/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: - `` — 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). - `` — mandatory orchestrator rules - `` — final report format - `` — Phase C revision prompt template - `` — 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 `/` 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 `/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). --- ## Target: process (audit) The audit target is the **SDLC factory itself** — the set of skills, checklists, templates, and schemas under `/` — 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 `/` 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 / 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 `/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 `/` 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 ``` /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) --- ## 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 `GET /api/v1/repos/{owner}/{repo}/wiki/page/{mangled-name}`, `sub_url` resolved from `GET .../wiki/pages` first). 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 `/{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 ``` /{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