Omar Sobh
0c17de52dd
Coordinator can now log WHY it worked on an INT-XX out of order
("REORDER: INT-05 before INT-04 because prereq X is unmet") and the
completion hook captures each rationale as an append-only event on
the loop. Sets up a reviewable timeline of when the plan was
adjusted, independent of the underlying `consumed_int_ids` advance.
Migration 0043:
- loops.reorder_events JSONB NOT NULL DEFAULT '[]'::jsonb — append-
only array of {run_id, iteration, text, ts}. Kept on the loop row
(rather than a dedicated table) so the mini-timeline is one read
away from the loop card.
Backend:
- topology_worker::parse_reorder_rationale — line matcher symmetric
with parse_completed_int_ids. Tolerates list dashes / prefixes /
markdown emphasis; case-insensitive marker match, preserves case of
the rationale text.
- cm_db::repo::loops::append_reorder_event — one INSERT-like append
per rationale, uses jsonb_build_object with postgres now() so ts is
wall-clock canonical (no client-clock skew).
- topology_runs::iteration_for_run — new helper so events carry the
iteration index.
- routes::loops::compose_iteration_task — coordinator prompt now
explicitly asks for `REORDER: <one-sentence>` at the top of the
first substantive turn when working out of order, AND spells out
that both markers must appear literally with colons (no bold, no
code fence) so the line parser doesn't miss them.
Non-loop and standalone-loop runs are unaffected — the hook only
fires when the run belongs to a source-bound loop.
Follow-up: expose reorder_events on the loops list endpoint + render
a small collapsed timeline on the LoopsList card.
18 lines
922 B
SQL
18 lines
922 B
SQL
-- Append-only event log of coordinator-issued reorders on a
|
|
-- research-bound loop. Whenever a run's coordinator emits
|
|
-- REORDER: INT-05 before INT-04 because prereq X is unmet
|
|
-- (or any `REORDER: <text>` line in the run's final output), the
|
|
-- topology_worker completion hook parses it and appends a
|
|
-- {iteration, run_id, text, ts}
|
|
-- object to this array. The loop card can then surface a mini-timeline
|
|
-- of when the plan was adjusted and why — useful when the reviewer
|
|
-- wants to understand why P0 items landed out of order.
|
|
--
|
|
-- JSONB rather than a separate table so the loop row carries its own
|
|
-- history — reads are already fast (loops list <10ms) and a
|
|
-- per-iteration event log lives naturally alongside consumed_int_ids +
|
|
-- current_int_index. If the log grows huge we can promote to a
|
|
-- dedicated table later.
|
|
ALTER TABLE loops
|
|
ADD COLUMN reorder_events JSONB NOT NULL DEFAULT '[]'::jsonb;
|