Reviewer DESIGN.md roadmap: is "Reviewer-performed merges" still wanted, given design 009 shipped Tier 1 merge authority differently? nf-dr3r ← Beads

closed priority 2 task unassigned needs:direction

Twinned from https://github.com/cfsh/ninefold/issues/1081 by tools/beads/import_github.py's reconcile pass.

Context: #1077/PR #1078 renamed "Tier 0"/"Tier 1"/"Tier 2" vocabulary in tools/reviewer/DESIGN.md's ## 6. Authority roadmap to plain names, but (per #1077's own "Open questions" §2 default) left the roadmap's *content* untouched — deliberately, since deciding whether it's still wanted was flagged as out of scope for a wording cleanup.

The unbuilt roadmap item in question: **"Reviewer-performed merges (not built)"** — the reviewer bot merging low-risk PRs itself (bypass actor + Contents R/W). Design 009 has since shipped a *different* "Tier 1" merge mechanism (the perimeter + jcantsp-bot, no reviewer-initiated merge involved) that covers similar ground: docs/test-only/tooling/pure-logic PRs merging without human approval.

Options: - A. Keep the roadmap item as-is. It's still a distinct, valid future mechanism (reviewer-initiated merge via bypass actor) even though the perimeter now covers some of the same PR classes a different way. - B. Drop or rewrite the roadmap item. If the perimeter's shipped mechanism now covers what this was meant to solve, the roadmap entry is stale and should say so or be removed.

Recommended default: A (keep as-is). The two mechanisms differ in *how* authority is granted (reviewer-initiated vs. perimeter-classified), not just in outcome, and nothing in design 009 argues the reviewer-merge path is superseded — only that a different path shipped first.

Default ships if unanswered — nothing is blocked on this.

Dependencies

None.

Comments

No comments.

Add a comment