Omar Sobh
e3011ed025
Before: reviewer rejected a publish → audit log flipped, topic stayed in reviewing, no way to feed the critique back into the run pipeline. Reviewers with revision notes had to eat them or hand-message the coordinator. Now: reject accepts an optional `notes` field. When present: - Persisted on the research_publish_approvals row (migration 0039). - Topic flips `reviewing → standby` so the next `start_topic` is legal. - `start_topic` reads the most recent rejected-approval notes for the topic and prepends "PRIOR REVIEW NOTES (address these in this revision):\n<notes>\n---" to the coordinator task. Loop closes through the same run pipeline — no new spawn code path, which means the reviewer's guidance flows through the same topology_worker, run_events, outcome-writer chain and lands as a fresh research_outcomes row (versioned, prior drafts preserved). No notes on reject = legacy behavior (topic stays in reviewing, publish requests still allowed). Migration 0039 adds nullable `notes TEXT` to research_publish_approvals. `decide()` gains a `notes: Option<&str>` parameter (only one caller, updated inline). New `latest_rejection_notes(pool, topic_id)` helper for start_topic. Frontend: - rejectPublish(id, notes?) now sends a JSON body when notes are provided. - ResearchCanvas reject button opens an inline form with a textarea + Cancel/"Send back for revision" pair. Empty notes → plain reject. - Button label switches: "Send back for revision" when notes present, "Reject without notes" when empty. Follow-up: - Notes shown in the review UI on the resulting draft so the next reviewer sees what changed. - Multiple rejection rounds — currently only the LATEST rejection's notes surface. Accumulating history is a schema-only tweak.
15 lines
770 B
SQL
15 lines
770 B
SQL
-- Adds a nullable `notes` column to research_publish_approvals so a
|
|
-- reviewer rejecting a publish can include revision guidance the next
|
|
-- coordinator run picks up (R2 — reject-with-revision loop).
|
|
--
|
|
-- The notes are stashed on the approval row, then `start_topic` reads the
|
|
-- most recent rejected approval for the topic and prepends its notes to
|
|
-- the coordinator task string as "Prior review notes:". This closes the
|
|
-- loop without duplicating the run-spawn code — the reviewer's critique
|
|
-- steers the next iteration through the same start_topic path.
|
|
--
|
|
-- NULL means "reject with no revision guidance" — legacy behavior stays
|
|
-- correct (topic stays in reviewing, nothing else fires).
|
|
ALTER TABLE research_publish_approvals
|
|
ADD COLUMN notes TEXT;
|