brain

Build the first usable rule set from the org's connected code.

Document uploads and email intake already create drafts as they arrive, while continuous connector jobs keep approved rules fresh afterward. This endpoint owns the missing dashboard-native step: scan enabled GitHub repositories for existing AI instruction files and open review PRs for anything that has not already been imported.

This org's onboarding progress — "how close is this org to a working setup" — aggregated off onboarding_events (gnt/onboarding_metrics.py). Planned future ROI metering will read off the same table, so counts stay a flat event_type -> count map here rather than baking in today's five known types.

onboarding_completed is the one real "is this org actually done" answer now — orgs.onboarding_completed, the same flag the browser wizard's own done screen sets (routers/onboarding.py's POST /complete) and lib/onboarding-wizard.ts's isWizardCompleteForWeb reads server-side. gnt login/gnt status read this field instead of computing their own connected_cli/connected_github/rules_proposed proxy for "done" -- there's one onboarding system (the browser wizard) now, not two independent ones to keep in sync. The other fields below (connected_cli, rules_proposed, ...) are still real and still useful for gnt status's own general reporting -- just not what "done" means anymore.

connected_cli isn't an onboarding_event (gnt login has no event-log call site, unlike the Slack/GitHub connect routes and rule proposal) — it's read straight off mcp_api_keys instead. A CLI key, once minted, always stays a row here even if later revoked, so this answers "has this org ever completed gnt login", not "is a CLI key live right now".

reached_five_rules_milestone is this product's "org reaches N approved rules in first session" success metric, N=5 — derived straight off the same counts, not a second query, since rules_approved already is that lifetime-cumulative count (see onboarding_metrics.RULES_APPROVED_MILESTONE for why that's an accurate proxy for "first session" here).

consume_wow defaults False -- this endpoint has consumers besides the /welcome page that actually renders the wow panel (the web account sidebar's useOnboardingStatus hook, gnt status/login/ connect-status), and without this gate whichever of those happens to call first would silently burn wow_panel_shown before the panel ever rendered. Only welcome/page.tsx's server-side fetch passes ?consume_wow=true; every other caller gets the wow fields back as None without touching the flag.