jb/harness-tools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Make development workflow risk-based and verification proportionate

Browse Source
This commit is contained in:
jb
2026-10-07 17:43:19 -04:00
parent 284fdd638d
commit 0cc0e82bbc
13 changed files with 265 additions and 173 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/develop/develop-workflow/references/review-and-remediation.md
+4 -28
View File
@@ -1,33 +1,9 @@
# Independent review and remediation
## Identity and capability
Use the shared [code-review skill](../../code-review/SKILL.md) as the single source of truth for reviewer selection, pinned evidence, both review axes, findings, and follow-up. One non-author reviewer is the default; additional reviewers require distinct risk or repository policy.
Exclude every identity that authored or mutated the reviewed diff. Record reviewer display name, profile, child ID, and session ID when available. When stable identity is unavailable, exclude the entire ambiguous profile/run. Keep reviewers read-only and separate for:
For workflow reviews, supply the retained record and originating request as the specification, along with repository standards, mutator identities, immutable base/product commits, tree/status evidence, exact binary diff command, and SHA-256. Record the delivered identity and verdict. Leave fixes to an implementer, never the reviewer.
- **Standards:** repository instructions and documented conventions.
- **Specification:** the approved workflow record and linked source plan/spec.
Review after focused checks and synchronization, before the final full-suite boundary. For a bounded fix, run affected checks and obtain targeted follow-up from the same independent reviewer covering the new fingerprint and interactions. Broaden review when prior conclusions no longer apply. Keep verification evidence and code-review approval separate: neither substitutes for the other.
Use Git-capable reviewer profiles with repository read access and no declared `write` or `edit` tools. Shell access can still mutate; capture status, tree, HEAD, and changed paths before and after review. Any mutation invalidates the verdict and marks that identity as a mutator.
## Review brief
Generate the brief in the parent. Include:
- pinned base and product HEAD;
- clean status and product tree hash;
- commit list;
- exact `git diff --binary --full-index --find-renames <base>...<product-head> --` command;
- SHA-256 of those exact bytes;
- approved record/specification sources;
- repository standards sources;
- all excluded mutator identities.
Launch standards and specification reviewers through separate direct subagent calls. Avoid wrapped parallel launch until its delivery defect is proven fixed. Require each reviewer to regenerate the pinned diff, confirm its digest before review, remain read-only, and bind every finding to file/hunk evidence and severity. Treat a missing result or digest mismatch as no verdict.
Approval binds to base, product HEAD, clean status, tree hash, and diff digest. Permit a later closure commit outside that fingerprint only after proving it changes the workflow record alone.
## Findings and remediation
Validate findings against repository evidence. Send accepted fixes to an original implementer or another non-reviewer, never the reviewer. Preserve exclusive path ownership and assignment evidence. Rerun affected checks and the full required suite, create focused commits, and generate a new fingerprint.
Launch fresh independent reviewers for the changed diff. Escalate after two unsuccessful remediation cycles or whenever a finding requires material scope, acceptance, ownership, verification, or architecture changes; return to plan approval before further production mutation.
After review, record-only evidence updates may be excluded only under the narrow [integration rule](git-and-integration.md#fast-forward-integration). Scope, specification, policy, and executable-instruction changes are not evidence-only updates.