/resolve: batch mode for N decisions, without weakening per-decision rationale

jbr870 commented

2026-08-11 14:56:49 +00:00

Owner

Observed failure

/technical-plan emitted 13 mechanical disposition decisions in one run (axana). Clearing them
one-by-one through /resolve was impractical, so the model hand-ran the skill's internals instead —
which is exactly the helper-bypass the contract forbids, arrived at through UX pressure rather than
carelessness.

What it needs

A batch mode: one invocation resolving N decisions with per-item rationale, without weakening the
one-decision-one-record trail. Each decision must still get its own decision-resolution:v1 with its own
rationale — the batching is in the interface, never in the record.

The tension to resolve

Rationale is mandatory and must be real (rationale + rejected_alternative, per the Phase 1.3 work).
A batch UI that makes it easy to paste the same sentence 13 times satisfies the schema and defeats its
purpose. The design question is how to make per-item rationale cheap without making it uniform.

Pairs with the decisions-settled gate issue — the gate blocking on all open decisions regardless of
blocking: false is what makes 13 mechanical dispositions a blocker in the first place. Same friction
from both ends; worth designing together.

Source: dogfood retrospective 2026-08-07 (F5), deferred backlog.

## Observed failure `/technical-plan` emitted **13 mechanical disposition decisions** in one run (axana). Clearing them one-by-one through `/resolve` was impractical, so the model **hand-ran the skill's internals** instead — which is exactly the helper-bypass the contract forbids, arrived at through UX pressure rather than carelessness. ## What it needs A batch mode: **one invocation resolving N decisions with per-item rationale**, without weakening the one-decision-one-record trail. Each decision must still get its own `decision-resolution:v1` with its own rationale — the batching is in the *interface*, never in the record. ## The tension to resolve Rationale is mandatory and must be real (`rationale` + `rejected_alternative`, per the Phase 1.3 work). A batch UI that makes it easy to paste the same sentence 13 times satisfies the schema and defeats its purpose. The design question is how to make per-item rationale cheap **without** making it uniform. ## Related Pairs with the decisions-settled gate issue — the gate blocking on *all* open decisions regardless of `blocking: false` is what makes 13 mechanical dispositions a blocker in the first place. Same friction from both ends; worth designing together. *Source: dogfood retrospective 2026-08-07 (F5), deferred backlog.*

jbr870 commented

2026-08-11 14:57:37 +00:00

Author

Owner

Pairs with #19. The gate blocking on all open decisions regardless of blocking: false is what makes 13 mechanical dispositions a blocker in the first place; batch-resolving them is the other end of the same friction. Fixing either helps, fixing both is the real answer — worth designing together.

Pairs with #19. The gate blocking on *all* open decisions regardless of `blocking: false` is what makes 13 mechanical dispositions a blocker in the first place; batch-resolving them is the other end of the same friction. Fixing either helps, fixing both is the real answer — worth designing together.

jbr870 referenced this issue

2026-08-11 14:57:37 +00:00

Decisions-settled gate ignores the blocking flag — revisit the contract #19

jbr870 commented

2026-08-13 11:18:37 +00:00

Author

Owner

Cross-adapter recurrence strengthening this: the Axana run (local-fs adapter, run report axana-6ef04d20) hit the same wall — "/technical-plan raised 13 gate-blocking disposition decisions ... the model bypassed /resolve and hand-ran its internals to clear them in one pass", and verity-slot1-112 self-answered 12 dispositions the same way. With verity-slot5-164's 18 hand-rolled resolutions, that is 3 runs on 2 adapters where /resolve was bypassed at volume — the batch path is missing on every adapter, not a glab quirk.

Evidence added by /meta-retrospective 2026-08-13.

Cross-adapter recurrence strengthening this: the Axana run (local-fs adapter, run report axana-6ef04d20) hit the same wall — "/technical-plan raised 13 gate-blocking disposition decisions ... the model bypassed /resolve and hand-ran its internals to clear them in one pass", and verity-slot1-112 self-answered 12 dispositions the same way. With verity-slot5-164's 18 hand-rolled resolutions, that is 3 runs on 2 adapters where /resolve was bypassed at volume — the batch path is missing on every adapter, not a glab quirk. *Evidence added by /meta-retrospective 2026-08-13.*

jbr870 referenced this issue

2026-08-13 11:20:03 +00:00

Slow loop: periodic process review (drains devwork learnings, defer-rot, process-quality trend, conformance census) #10

jbr870 referenced this issue from a commit

2026-08-13 12:06:38 +00:00

meta-retrospective: review 2026-08-13 — 4 filed, 7 watchlisted, ~15 clusters verified resolved

jbr870 commented

2026-08-13 13:05:57 +00:00

Author

Owner

Slot3/#191 deep-dive sharpens the shape of the fix: the gap isn't only a batch mode — there is no decision-resolution-post.sh at all, so even the structured path hand-authors the schema. That run produced ~20 more decision-resolution:v1 comments built with jq -n + post-comment.sh against an inline copy of the schema (fourth run doing this, second adapter). Whatever batch design lands, the posting helper is the common denominator and could ship first.

Evidence added by /meta-retrospective 2026-08-13 (slot3 deep-dive).

Slot3/#191 deep-dive sharpens the shape of the fix: the gap isn't only a batch *mode* — there is no `decision-resolution-post.sh` at all, so even the structured path hand-authors the schema. That run produced ~20 more `decision-resolution:v1` comments built with `jq -n` + `post-comment.sh` against an inline copy of the schema (fourth run doing this, second adapter). Whatever batch design lands, the posting helper is the common denominator and could ship first. *Evidence added by /meta-retrospective 2026-08-13 (slot3 deep-dive).*

jbr870 commented

2026-08-13 13:08:47 +00:00

Author

Owner

One-line risk upgrade from the slot3 report (§ model mistakes, line 160): the hand-rolled resolution glue this issue would eliminate produced an actual wrong-record incident — a zsh 1-indexed off-by-one posted four resolutions with wrong sibling refs; caught and superseded in-run 8 seconds later, but only because the model checked its own batch. The posting helper is not just ergonomics; it is the guard against exactly this.

jbr870 referenced this issue

2026-08-14 13:01:48 +00:00

requirements/technical-plan: one question round per phase, not four inside eight minutes #42

Rows
Columns

/resolve: batch mode for N decisions, without weakening per-decision rationale #14

Observed failure

What it needs

The tension to resolve

Related