v0.0.62 — Cobuild + governance + promote-to-live

Released: 2026-05-09. Thirty commits — the headline is Cobuild, a new product surface for AI-driven, multi-step authoring across recipes, dashboards, and agents. Plus a governance pipeline (F10) and a promotion lifecycle (F11) that gate publishing on automated checks.

Cobuild — new product surface

Cobuild is a chat-driven workspace for building Honeyframe assets end-to-end: discover datasets, profile data quality, propose a recipe, generate a dashboard, run governance, promote to live. Sessions persist conversation history; threads run parallel workstreams within a session.

See the new Cobuild page for the full concept guide.

F5 — data model

Three tables seed the surface:

• cobuild_sessions — top-level workspace (session_id, project_id, org_id, title, kind)
• cobuild_threads — parallel workstreams within a session (thread_id, session_id, workstream_kind, status, primary_asset_id)
• cobuild_messages — turn-by-turn record (message_id, thread_id, role, content, plan_state, tool_calls)

CRUD endpoints under /api/cobuild/sessions and /api/cobuild/threads.

F7 — multi-step planner

A new planner agent runs the standard agent loop with a curated toolset that includes catalog_discovery, profile_dataset, create_recipe, create_dashboard, patch_recipe_step, run_governance_review, promote_to_live. The planner can pause to ask for approval (status='awaiting_approval') before destructive tool calls; the UI surfaces a PlanCard with a friendly summary of what the LLM intends to do. Approve / reject buttons resume the loop with the user's decision.

Sidebar adds an entry at /cobuild. The page lists sessions; clicking one opens a chat surface with the session's threads.

F8 — parallel workstreams

A single Cobuild session can run multiple workstreams in parallel — the planner can spawn_workstreams mid-loop to fan out (e.g. "build the bookings dataset" + "build the revenue dashboard" + "set up the governance review" all at once). Each spawned thread runs an independent agent loop; the parent thread's LiveTrace surfaces the fan-out so users see what's running.

Tx unpoison on tool SQL errors

The Cobuild planner runs in a longer-lived Postgres transaction than the typical request. A failed tool SQL call previously poisoned the connection, 500-ing the next /run or /resume. Tool dispatch now explicitly ROLLBACKs and re-acquires a clean connection on failure.

F10 — governance pipeline

A new governance_runs table records advisory + blocking checks against an asset before it can be activated. Slices A–D land in this release:

Slice	Check	Severity	Asset types
A	asset_resolved — the asset exists in (project, org) scope	blocking	recipe, dashboard, agent
B	has_executable_body / has_cards / has_tools — asset isn't a stub	advisory	recipe / dashboard / agent
C	no_unmasked_pii — walks referenced datasets, classifies columns through masking.classify_columns (per-dataset overrides → org masking_defaults → PII_DEFAULTS auto-mask), flags strategy='none' on non-None sensitivity	advisory	recipe, dashboard, agent
D	has_tools on agents	advisory	agent

Endpoints:

• POST /api/governance/run — fires run_governance_review on one asset, persists the row, returns the serialized GovernanceRun
• GET /api/governance/runs — lists in (project, org) scope, optional asset_type + asset_id filters, cap 200

Cobuild's planner can call run_governance_review as a tool — the verdict surfaces in the PlanCard before any promote_to_live step is allowed.

See the new Governance page.

F11 — promote_to_live

A new is_test boolean on published_assets. Newly created assets default to is_test=true (visible only to the creator + admins). Calling the promote_to_live planner tool — gated by a passing F10 governance run — flips is_test=false and the asset becomes visible to everyone with dashboard.read / equivalent.

This finally gives Honeyframe a draft → live lifecycle. Recipes and dashboards built in Cobuild stay in test mode until governance passes and the user promotes.

Dashboard display_options registry

Card config knobs are now registered in a per-card-type display_options registry. v0.0.62 adds:

• Map color scales — geo_scatter / choropleth take a color_scale option (viridis, plasma, rdylgn, ...).
• number_format — KPIs and bigsigle-number cards format value strings with a small DSL ("0.0%", "$#,##0", ...).
• Sort — table and pivot cards accept a sort_by + sort_direction.
• Stack — bar/area charts accept a stack mode (group, stack, percent-stack).

The chat agent emits these via update_card_config mutations. A commit-on-yes rule in the prompt: the LLM proposes the change as a PlanCard, the user clicks Yes, the mutation fires. Display-option toggles never auto-apply silently.

Percent-stacked tooltip and pivot heatmap color scales polished in the same release.

F1 — catalog_discovery tool

LLM-callable dataset finder: GET /api/projects/{id}/catalog?q=…&tags=…&limit=… returns {name, friendly_name, schema, layer, row_count, tags} for matching datasets. The Cobuild planner uses this as the first step when a user asks "build me a revenue dashboard" — no need to spell out the dataset name. Bind-parser fix: CAST(:tag_filter AS text[]) (the :bind::cast form tripped asyncpg).

F2 — profile_dataset tool

LLM-callable data-quality summary: returns row count, column types, null counts, top-K distinct values, min/max/median for numerics. The planner uses this between catalog_discovery and create_recipe to ground recipe SQL in actual data shapes.

F4 — patch_recipe_step tool

First mutation tool on the chat surface (vs. read-only Tier C tools): the planner can patch a single step in an existing recipe. Gated by recipe.edit and surfaced as a PlanCard before applying.

Telemetry corrections

• Usage page now sums dashboard_chat_calls (was missing the chat-driven calls entirely — the page under-counted the active LLM workload).
• Sync Health reads from v_all_runs so it catches modern recipe_runner rows (was reading only the legacy table).