Files
clawmates/migrations/0041_integrations_outcome.sql
T
Omar Sobh 3ed1d03d2b
ci / gates (push) Successful in 6s
ci / frontend (push) Successful in 39s
ci / rust (push) Successful in 22m15s
ci / e2e (push) Has been skipped
ci / publish (push) Successful in 2m40s
research: integrations outcome + rich wizard cards + coordinator template
Adds a fifth outcome kind ('integrations') tuned for the "audit repo,
survey papers, propose a menu of concrete integrations" use case.
Every INT-XX item is self-contained (what, how, where, prereqs, effort,
risk, testing, rollback, acceptance) so a downstream loop can execute
one per iteration.

Backend:
- Migration 0041 drops + re-adds the outcome_kind CHECK constraint
  with 'integrations' allowed. Existing rows unaffected.
- VALID_OUTCOMES gains 'integrations'.
- New deliverable_template(kind) returns the canonical section shape
  for each outcome — spec, prod_plan, roadmap, paper, integrations all
  get first-class treatment (prior: all shared a bare label).
- build_coordinator_task injects an ARTIFACT SHAPE block from the
  template into the coordinator prompt, so the final synthesis
  actually matches the promise the wizard made.

Frontend:
- OutcomeKind gains 'integrations'.
- ResearchWizard OUTCOMES list carries a `sections` array per kind.
- Selected card renders an "ARTIFACT WILL CONTAIN" preview so users
  pick by seeing what they'll get, not by reading a one-line hint.
- Integrations card gets the fullest preview (executive summary +
  INT-XX card shape) since it's the most structured deliverable.

Follow-ups queued (next commit): loop wizard "Import from research
artifact" bridge + one-INT-per-iteration mode.
2026-07-09 18:42:46 -07:00

17 lines
888 B
SQL

-- Extends research_topics.outcome_kind to include 'integrations' — a new
-- deliverable shape for "audit this repo, survey the literature, produce
-- a prioritized menu of concrete integrations we can implement" runs.
-- The artifact is a list of INT-XX items, each self-contained (what,
-- how, where in the architecture, prereqs, effort, risk, acceptance
-- criteria) so a downstream loop can consume them one-per-iteration.
--
-- The existing check constraint is dropped and re-added with the new
-- value; existing rows aren't affected. Postgres requires the drop
-- because you can't ALTER a constraint's expression in place.
ALTER TABLE research_topics
DROP CONSTRAINT research_topics_outcome_kind_check;
ALTER TABLE research_topics
ADD CONSTRAINT research_topics_outcome_kind_check
CHECK (outcome_kind IN ('spec', 'prod_plan', 'roadmap', 'paper', 'integrations'));