onboarding

Step 3 of the onboarding wizard. Any org member can submit this (not require_admin-gated) -- it's preference data about why this org signed up, not a privileged action.

Step 2's non-identity fields. Called right after organization.create on the client -- same non-admin-gated reasoning as submit_survey above: at this point in the flow the caller is the org's sole member, its own owner.

Step 5's repo picker -- every repo the org's GitHub App install granted access to (routers/github.py's app/callback persists one row per repo, all enabled by default), so the wizard can show what's connected and let the org narrow it down before continuing to the scan step. installation_id IS NOT NULL scopes this to the App flow -- onboarding never uses the legacy PAT flow, but an org that connected via gnt connect github --pat before ever starting onboarding shouldn't see that single PAT row show up here as if it came through this picker.

Step 5's continue button -- flips enabled on for exactly the repo_urls given and off for every other App-connected row this org has, so unchecking a repo in the picker actually turns gnt off for it rather than only affecting some default selection. 404s if any requested repo_url isn't one of this org's own connections -- same tenant-isolation posture as rules.py's _get_org_rule, not a silent no-op on a typo'd or another org's URL.

Step 6 -- walks every enabled repo's tree for AI rules files and returns what it found, content included, so the step 7 reveal screen can render a preview without a second round trip. Doesn't write anything yet (no rules created, repo_scan_completed not set) -- that's POST /rules/import below, once the org has reviewed and possibly narrowed the per-file toggles the reveal screen defaults to "all on".

Step 7's continue button -- converts whichever scanned files are still checked into draft rules (rules.py's create_draft_rule, the same path a human hand-authoring a rule goes through) and marks the scan step done. apply_privacy_gate stays False (create_draft_rule's own default): this is the org's own repo and its own authored file, the same "a deliberate action by whoever's exposing this content" posture create_rule already takes, not ambient third-party ingestion.

Same idempotency guard as workers/tasks_onboarding_scan.py's own _scan_new_connection: that job auto-scans and imports on an org's first GitHub connection, racing this manual click-through on the primary web onboarding path. Whichever of the two gets here first flips repo_scan_completed, so the other is a no-op instead of drafting (and, on the job's side, proposing) the same files twice.

The settings-page counterpart to PATCH below -- lets the Configure settings page (post-onboarding, ongoing) load whatever's actually saved instead of always rendering the same hardcoded defaults PATCH's own ConfigureRequest falls back to on a first-ever save. Same defaults here when check_action_settings is still NULL (never configured at all), so a brand-new org and one that already went through the onboarding step read identically until someone actually changes something.

Step 8. Admin-gated (unlike survey/organization-profile above) -- unlike those two purely descriptive fields, this is meant to eventually gate what an autonomous agent is allowed to do, so it gets the same posture as every other real settings change in this router from the start rather than needing a follow-up migration once the real option list lands.

Step 10's stat tiles. mcp_endpoint_url is gnt's one real published endpoint (config.py's Settings.mcp_url) -- not a per-org gnt.ai/<handle> URL the way the plan's own draft copy speculated: every org hits the same endpoint and authenticates with its own MCP API key (routers/settings.py's POST /settings/mcp-keys), so showing a fabricated per-org URL here would be actively wrong, not just simplified.

Finish onboarding only after Stripe confirms paid or trialing access.