Product outcome
When a user runs diffrat review (especially against a base ref), they get the
same class of branch-level drift assessment that repo-drift-detector analyze
produces: overall risk_level (low / medium / high), a risk_score (0–100),
machine-readable risk_reasons, and the underlying signals (change volume,
unsafe production/test mix, large-change files, high-risk paths)—in both the
human-readable report and --json, with configurable thresholds via existing
Diffrat config surfaces and a scriptable gate when risk meets or exceeds a
chosen level—without installing or depending on the Ruby gem.
Completion criteria
Constraints
- Local-first; deterministic default (no network required for drift assessment)
- Small PRs via Agent Goals; agents never merge
- Do not remove or replace existing Focus/Risk hints or per-file
risk_score
- No Ruby /
repo-drift-detector runtime dependency
- Adapt the gem’s docs/test/production model to Diffrat’s richer categories
(source / tests / ci / config / docs / other); do not copy Ruby
path rules blindly
Out of scope
- Wrapping, vendoring, or shelling out to the Ruby gem
- Porting
explain / static-ai / --compare interpreters from the gem
- Phase 4 integrations (CI bots, GitHub App, PR annotations)
- Byte-identical JSON schema parity with
repo-drift-detector
Relevant context
- Predecessor: https://github.com/szymoniwacz/repo-drift-detector
(analyze / RiskEvaluator / .repo-drift-detector.yml)
- Diffrat already overlaps partially: file categories,
large_diff /
large_single_file, source_without_tests /
source_heavy_without_tests, per-file risk_score, --fail-on on hint
codes (src/diffrat/analysis.py, src/diffrat/scoring.py)
- Gap: branch-level
risk_level / aggregate risk_score 0–100 /
risk_reasons / unsafe_change_ratio / fail-on risk tier
- Capability parity with
analyze, not byte-identical output
Commands
REFERENCE ONLY — agents must ignore this entire section for scope, planning, implementation, validation, and Done.
Comment exactly (repository owner):
/execute-project — authorize project and start/resume (default: human CR per delegated PR, then you merge)
/execute-project self-correcting-review — same + self-correcting review mode on eligible delegated goals (skip human CR when eligible; you still merge)
/execute-project self-correcting-review auto-merge — same + Goal Executor squash-merges when eligible
/continue-project — optional nudge after material-decision answers or an unexpected stop (does not authorize by itself)
Ordinary resume: Goal Executor PR-head CI for draft handoff; Project Executor on merge and default-branch CI (green → next; red → repair). Project Executor never merges; Goal Executor may squash-merge only with self-correcting-review auto-merge when eligible.
After editing the title or scope fields (Product outcome, Completion criteria, Constraints, Out of scope, Relevant context), re-comment /execute-project, /execute-project self-correcting-review, or /execute-project self-correcting-review auto-merge (authorization resets). Editing Commands alone does not reset authorization.
Details: .ai/policies/autonomy-and-authorization.md, .ai/review/self-correcting-review-loop.md
Product outcome
When a user runs
diffrat review(especially against a base ref), they get thesame class of branch-level drift assessment that
repo-drift-detector analyzeproduces: overall
risk_level(low / medium / high), arisk_score(0–100),machine-readable
risk_reasons, and the underlying signals (change volume,unsafe production/test mix, large-change files, high-risk paths)—in both the
human-readable report and
--json, with configurable thresholds via existingDiffrat config surfaces and a scriptable gate when risk meets or exceeds a
chosen level—without installing or depending on the Ruby gem.
Completion criteria
diffrat reviewsurfaces an overall drift assessment (level + score +reasons) for sensible review modes (at least branch vs base)
files, and high-risk path detection
(
[tool.diffrat]/.diffrat.toml)--jsonexpose the assessment additively (compatibleconsumers) or with a documented
schema_versionbump(parity with
analyze --fail-on)main after all PRs merge
gem is product context only, not a runtime dependency
Constraints
risk_scorerepo-drift-detectorruntime dependency(
source/tests/ci/config/docs/other); do not copy Rubypath rules blindly
Out of scope
explain/static-ai/--compareinterpreters from the gemrepo-drift-detectorRelevant context
(
analyze/RiskEvaluator/.repo-drift-detector.yml)large_diff/large_single_file,source_without_tests/source_heavy_without_tests, per-filerisk_score,--fail-onon hintcodes (
src/diffrat/analysis.py,src/diffrat/scoring.py)risk_level/ aggregaterisk_score0–100 /risk_reasons/unsafe_change_ratio/ fail-on risk tieranalyze, not byte-identical outputCommands
REFERENCE ONLY — agents must ignore this entire section for scope, planning, implementation, validation, and Done.
Comment exactly (repository owner):
/execute-project— authorize project and start/resume (default: human CR per delegated PR, then you merge)/execute-project self-correcting-review— same + self-correcting review mode on eligible delegated goals (skip human CR when eligible; you still merge)/execute-project self-correcting-review auto-merge— same + Goal Executor squash-merges when eligible/continue-project— optional nudge after material-decision answers or an unexpected stop (does not authorize by itself)Ordinary resume: Goal Executor PR-head CI for draft handoff; Project Executor on merge and default-branch CI (green → next; red → repair). Project Executor never merges; Goal Executor may squash-merge only with
self-correcting-review auto-mergewhen eligible.After editing the title or scope fields (Product outcome, Completion criteria, Constraints, Out of scope, Relevant context), re-comment
/execute-project,/execute-project self-correcting-review, or/execute-project self-correcting-review auto-merge(authorization resets). Editing Commands alone does not reset authorization.Details:
.ai/policies/autonomy-and-authorization.md,.ai/review/self-correcting-review-loop.md