ferueda Change Review Workflow
Assess review value at a coherent completion point, not after every edit or commit. A review request alone does not authorize fixes, commits, or publication.
Select the review scope
Inspect the complete intended change against its base, accepted outcome, and available verification, not just the last patch. Honor explicitly requested roles and mandatory caller/repository gates. Otherwise choose:
- Skip: routine, readily understood changes with no material behavior, contract, ownership, structural, or verification risk. Test names, comments, formatting, and ordinary tests using established fixtures usually fit.
- Implementation: material correctness, acceptance, failure-handling, compatibility, security, or behavioral-proof questions; structure is familiar.
- Quality: substantial structural or abstraction changes with no material behavior/contract uncertainty needing a separate implementation review.
- Both: distinct behavioral and structural risks, such as redesigning a shared primitive's contract, lifecycle, or owner across consumers.
Judge consequences and uncertainty, not file extensions, line counts, or the mere presence of tests or primitives. Weakening a critical assertion can need implementation review; changing a primitive's comment does not. Inspect uncertain scope before deciding; inability to inspect is not evidence that review is safe to skip. Select only roles with a concrete purpose, without a separate model call or assessment artifact. Give a short reason in the existing completion summary.
A skip means no independent review ran, not a passing review. Do not invoke Harness for a skip. Required local checks still apply. Explicit review requests receive the requested review even for small changes; otherwise one relevant role is sufficient when it covers the material risks.
Run selected roles
Resolve the task/plan, base, and head. Harness reviews
merge-base(base, head)..head; staged, unstaged, and untracked changes are not
included. Use an authorized temporary review ref/commit object for local work,
or report the exact uncovered scope. Never commit unrelated work for the runner.
Discover the available harness, .harness/bin/harness, or source executable;
consult help for flags. Pass --steps implementation, --steps quality, or
--steps implementation,quality deliberately. The bare command still defaults
to both for compatibility; that is not a requirement to run both on every task.
Include --plan when relevant. Load the handoff reference
only for session-only context, selected scope, or follow-up decisions.
Reviews can take up to 20 minutes, depending on task size. Prefer completion notifications; when polling is needed, check every 1–2 minutes for small tasks and every 3–5 minutes for larger tasks, rather than every 30 seconds. Adjust to observed progress; elapsed time alone is not a reason to stop the review.
If the runner is unavailable, report the limitation. Use an available direct reviewer only when the task permits it; never claim Harness ran. A delegated operation returns to its caller and cannot waive that caller's review or publication requirements.
Findings and remediation
Read structured reviewer outputs and metadata. Merge duplicate issues while preserving provenance. Report findings only when evidence establishes a concrete consequence for the accepted task. Omit nitpicks, equivalent styles, speculative hardening, and unrelated cleanup rather than collecting them as advisories. A blocker must explain why the issue prevents safe acceptance; severity alone is not a blocker rule. Useful non-blocking observations do not require fixes or another review cycle. No findings is a valid result.
Give material findings an evidence-backed Implement, Adapt, or Decline disposition. When fixes are authorized, make the smallest accepted correction and run relevant checks and required gates. Otherwise return findings without editing. Pause only corrections needing new authority or a material human decision. New evidence of a material defect remains valid even when a previous reviewer missed it; do not reopen settled preferences without new evidence.
Follow-up and completion
Reassess changes since the last review. Rerun only roles whose conclusions could be materially invalidated, whose blockers need independent confirmation, or whose execution failed. A logic fix may need implementation; a structural fix may need quality or both. Mechanical edits or straightforward test additions can be inspected and checked locally without another model run. Do not rerun solely because HEAD changed. Do not drop an unresolved required role to obtain a pass.
Use at most three total runs: initial plus two follow-ups. Preserve the budget and dispositions across continuations; report unresolved blockers or unavailable required coverage when exhausted.
Complete when the selected required roles pass, material findings are resolved
or dispositioned with evidence, and later edits do not invalidate that evidence.
A quality-only result need not acquire an implementation pass. A selected-role
run remains partial relative to the full catalogue; omitted unnecessary roles
are not failed coverage. A failed or blocked required role is incomplete, not a
skip or approval. Skipping is a selection decision, never a fabricated verdict.
Report roles, the reviewed revision, checks, dispositions, and material limits. If later edits were verified directly, distinguish them from the independently reviewed revision. Do not claim a reviewer approved unseen changes. Publication remains separate and requires task authority.