Skip to content

0037 — Studio settings IA (typed panels + YAML advanced view)

Status: IN PROGRESS — from Matt's 2026-07-23 studio driving notes (0029 §9); implementation started 2026-07-23 with the spec's recommendations adopted for D1 (Socials = enablement/settings only), D2 (Advanced-YAML edits the project file only), D3 (last-write-wins with a reload warning). Date: 2026-07-23 Relates: 0034 (project settings — the tabbed overlay this extends), 0035 (config writes — all panels persist via Store.Apply), 0014 (per-project config; inheritance), 0019 (publish/connections), 0012 (remote git).

1. Problem

The 0034 settings overlay has Themes · Avatars · Advanced, where Advanced is a raw key/value editor over the whole config. Much of what lives there deserves a real UI, and a raw table is the wrong escape hatch for a YAML-shaped, comment-carrying config file.

2. Goals (Matt's notes, items 3 + Themes-tab note)

  1. Extract typed panels from the raw settings into their own tabs:
  2. Version control — the 0012 commit-on-save/push-on-save/remote settings.
  3. Socials — platform enablement + per-platform posting settings (0019's config surface; token health stays on the Publish tab's ConnectionsPanel).
  4. Auth — OAuth client ids/redirects and the studio exposure settings (0018); secrets stay keychain/env-resolved, never editable plaintext.
  5. Themes belong in the Themes tab — any theme keys still reachable through Advanced disappear from it (single owner: the 0036 editor).
  6. Advanced becomes a YAML view — an editable YAML representation of the project config (.keryx.yaml), replacing the key/value table. Round-trips through the go/config Store so comments/anchors/key-order survive (0035); validated + diffed (a Plan preview) before apply; secret-bearing keys masked/rejected exactly as the current putConfig allowlist does.

Update 2026-07-24 — Storage tab added (spec 0039). The object-store settings landed as a seventh typed panel (Providers · Storage · Version control · Socials · Auth, plus Themes/Avatars/Advanced): storage.provider, storage.prefix, and storage.s3.{bucket,region,endpoint} — all non-secret (credentials resolve via the AWS default chain, never the file), added to the putConfig allowlist. The panel opts into a Verify button (a new ConfigPanel verify prop) that calls POST /api/v1/storage/verify → the backend's Store.Verify (bucket reachable + versioning enabled), showing the outcome inline; Verify is disabled while the form is dirty ("save first").

3. Design sketch

  • Tab strip becomes: Themes · Avatars · Providers · Storage · Version control · Socials · Auth · Advanced.
  • Each typed panel is a thin form over a declared key subset (same allowlist mechanism as putConfig today); unknown/unclaimed keys remain visible only in Advanced-YAML.
  • Advanced-YAML: GET renders the project file verbatim (comments included); save routes the edit (not a whole-file overwrite) through Store.Apply — either by computing the key-level diff or by a guarded whole-document replace that preserves the unedited remainder. Inherited-from-global keys render read-only (provenance via Origin).

4. Open questions (for review)

  • D1: does the Socials panel include per-platform copy templates, or only enablement/settings? (Rec: enablement/settings v1.)
  • D2: Advanced-YAML scope — project file only (rec), or a second read-only pane for the effective merged view (Explain-backed)?
  • D3: YAML editing conflict story vs CLI writes — last-write-wins with a reload warning (rec) or ETag-guarded?

5. Non-goals

  • Editing the global config from the studio; managing keychain secrets; token capture flows (stay on the CLI / Publish connections).