reporter-protocol

name	reporter-protocol
description	Loaded by the reporter agent to supply operating protocol and invariants for code review report generation in the parity-test-f pipeline. Not user-invocable.
disable-model-invocation	true
user-invocable	false

Reporter — Operational Protocol

The reporter agent reads the structured findings JSON produced by the analyzer and the reviewer verdict supplied via dispatch context (parsed by the orchestrator from the reviewer's terminal output), renders a comprehensive markdown code review report with sections for issues found and the review verdict, and writes the final output to `{ROOT}/output/parity-test-f-review-report.md`. It is the final step of the parity-test-f Sequential pipeline (Pattern 1) on Tier 1d (Codex CLI). The quality bar is: the output markdown must be human-readable and contain both required sections without truncation or placeholder text.

Protocol

1. DISCOVER

1. Read inputs from the orchestrator dispatch context:
   • findings_path: path to findings.json written by the analyzer.
   • reviewer_verdict: verdict string from the reviewer (approved / approved_with_concerns / rejected), parsed by the orchestrator from the reviewer's terminal-output REVIEWER VERDICT block.
   • reviewer_completeness_score: completeness score from the reviewer.
   • reviewer_missing_categories: comma-separated missing categories from the reviewer (or "none").
   • reviewer_notes: reviewer notes text (or "none").
   • output_path: path where the final markdown report must be written (always {ROOT}/output/parity-test-f-review-report.md).
   • state_path: path to pipeline-state.json for status updates.
   • run_id: current run identifier.
   • root: resolved scope root.
2. Verify findings_path exists and is valid JSON. If the file does not exist: emit BLOCKED with message: "Analyzer findings not found at {findings_path}. The analyzer step may have failed."
3. Parse the findings JSON. If JSON is malformed: emit BLOCKED with message: "Analyzer findings at {findings_path} are not valid JSON."
4. Confirm reviewer_verdict is supplied and is one of approved / approved_with_concerns / rejected. If absent or unrecognized: emit BLOCKED with message: "Reviewer verdict not supplied in dispatch context. The reviewer step may have failed."

2. PROCESS

Render the markdown code review report using the following template (populated from parsed findings and verdict):

# Code Review Report — parity-test-f

> Generated by the parity-test-f pipeline (Tier 1d — Codex CLI)
> Source diff: `{findings.diff_path}`
> Total issues found: {findings.issue_count}
> Review verdict: {reviewer_verdict}

## Issues Found

{If findings.issues is non-empty, group by category and render:}

### Null Checks

{For each issue where category = "null_check":}
- **[{issue.severity}]** `{issue.location}` — {issue.description}

{If no null_check issues:}
- No null check issues detected.

### Error Handling

{For each issue where category = "error_handling":}
- **[{issue.severity}]** `{issue.location}` — {issue.description}

{If no error_handling issues:}
- No error handling issues detected.

### Naming

{For each issue where category = "naming":}
- **[{issue.severity}]** `{issue.location}` — {issue.description}

{If no naming issues:}
- No naming issues detected.

## Review Verdict

| Field | Value |
|---|---|
| Verdict | {reviewer_verdict} |
| Completeness Score | {reviewer_completeness_score} |
| Missing Categories | {reviewer_missing_categories} |

{If reviewer_notes is non-empty and not "none":}
**Reviewer Notes:** {reviewer_notes}

{If reviewer_notes is empty or "none":}
**Reviewer Notes:** No additional notes.

Ensure:

• ## Issues Found section is present and contains all three category subsections.
• ## Review Verdict section is present with the verdict table.
• No section is left entirely blank or contains placeholder text.
• The header block accurately reflects findings.diff_path, findings.issue_count, and reviewer_verdict.

3. DELIVER

1. Create the {root}/output/ directory if it does not exist.
2. Write the rendered markdown to output_path using the Write tool.
3. Update pipeline-state.json:
   • Set phases[2].status = "completed".
   • Set phases[2].outputs = [output_path].
   • Set top-level status = "completed".
   • Set completed_at = current ISO-8601 timestamp.
4. Emit terminal status:
   • DONE — report written successfully; both required sections present; verdict is "approved".
   • DONE_WITH_CONCERNS — report written but reviewer verdict is "approved_with_concerns" or "rejected" (surface the verdict and reviewer_notes to the orchestrator).
   • BLOCKED — findings file missing/malformed or reviewer_verdict not supplied; output not written.

- ALWAYS write the output to exactly `{ROOT}/output/parity-test-f-review-report.md` — never a different path. - ALWAYS include `## Issues Found` and `## Review Verdict` sections in the output. - NEVER write partial output — if rendering fails mid-way, do not write the file; emit BLOCKED. - NEVER hardcode platform paths — use only the `root` value supplied in the dispatch context. - ALWAYS update `pipeline-state.json` phases[2] and top-level status after writing. - Emit exactly one terminal status: DONE / DONE_WITH_CONCERNS / BLOCKED.