Decide: hub#140 — one question survives (W1–W3): carve-out strength, design defaults, and the issue's disposition #156
Unanswered
Replies: 1 comment
|
Decided, and built the same day. Recording the answer here as well as on the artifact, which is now the permanent record. @jwildfire, in chat, 2026-08-15: "#156 looks good. recommnendations approved." — all three recommendations adopted as written (D0005.1–.3, formerly W1–W3).
Full record, including what each answer resolves: the artifact · decisions log This comment was drafted by Claude Code using Opus 5 (👯🤖 hub140x sibling) and reviewed by @jwildfire |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Decision artifact: https://jwildfire.github.io/obot.roadmap/reports/decisions/2026-08-14-hub140-one-question/ — full diagnosis, evidence, and options there; this thread is the place to record the calls.
The question: hub#140 has carried eight decisions (D1–D8) unanswered for thirteen days and is the bottleneck for the merge carve-out gate and a truthful
obot-merge --check. Every claim was re-verified against the live repos tonight; seven of the eight retire — they are engineering calls the design already answers. What survives is one policy call, one blanket sign-off, and the disposition of the issue itself.Three calls (answer one by one):
W1 — what does the carve-out require? (was D4;
policy.json'scarveOut._noteandinvariants.nevercontradict each other, and oa#83 merged standard-lane on 08-14 while claiming attested — the second live violation) → Recommend a: attested-always — any PR touching a carve-out path needs--jeremy-approved, attended or not; option b (bar only unattended merges) is barely implementable becauseobot-mergecannot observe attendance.W2 — blanket-accept the design's defaults for D1, D2, D3-core, D5, D6, D7, D8? One checkbox, not seven; D3's hub-workflows fragment severs to its own issue (it needs a PreToolUse guard, not a merge gate). → Recommend a: yes — none of the seven changes what any repo permits, and each remains overridable in review of the implementation PR, which is attested so you see it anyway.
W3 — what happens to #140 itself? → Recommend a: close it with the obot.agent v0.4.0 release. Its Business Requirement (one write-policy decision per repo) shipped 2026-07-29 and headlines the v0.4.0 notes; the enforcement work is fully tracked in oa#65 + oa#75 + discussion #141 with the design doc as spec — nothing needs re-filing. Option b keeps #140 open until the enforcement PR merges (design §10 status quo), preserving the stale-Requirement framing that already stalled once.
What unblocks: W1 + W2 open the single obot.agent PR from design §10 (policy.json v3, Gates A+B, truthful
--check, committed sweep), closing oa#65, oa#75, and #141. While unanswered: the carve-out gate does not exist mechanically, the attested lane can post audit comments for merges that never happen, and--checksays "policy permits merging" for PRs GitHub will refuse.This discussion was drafted by Claude Code using Fable 5 (👯🤖 sibling, session 2026-08-14) and awaits @jwildfire's review.
All reactions