Settings¶

Registry-driven Work Buddy settings, authority boundaries, App/System placement, and persistence.

Details¶

Settings is the authority and information architecture for configurable Work Buddy behavior.

Application-owned settings are organized under Apps, separated by provenance such as Built-in and Community. Journal and Co-work each appear once under Apps -> Built-in; Co-work owns its atomic Review shortcut map on that page. View- and System-related groups are sections inside the owning App page rather than duplicate global View entries.

Cross-dashboard model behavior belongs under System → Dashboard AI at /app/settings/system/dashboard-ai, not Apps. The former /app/settings/apps/dashboard route redirects while preserving navigation state, query and fragment. Existing opt-in identity/value is unchanged.

Document-encoding placement belongs under System → Embeddings at /app/settings/system/embeddings. The page combines one restart-gated setting with read-only evidence from the running embedding service; it does not treat a saved preference as proof of current execution.

The canonical Journal route is /app/settings/apps/journal. Contextual settings launchers navigate directly to the owning page. Compatibility routes may redirect there while preserving navigation state; they do not create a second setting identity.

Registry model¶

The registry separates:

a definition, which owns identity, type, validation, default, authority, and provenance;
a page, which owns navigation identity;
a section, which groups controls on a page; and
a placement, which places one definition into one section.

A definition may have several placements without duplicating its stored value.

Authority¶

Authority is declared per setting. Device-local settings cover presentation and accessibility behavior such as typography. Server/profile settings cover shared domain meaning, such as the Journal day boundary. Native and community contributions can use the same registry shape while receiving different trust and permission grants.

Embedding execution¶

wb.embedding.document-execution controls the large document-side encoder used by document and passage similarity as well as indexing:

Local only always permits local leaf-ir execution.
Prefer LM Studio uses the configured remote model when available and permits an intentional local fallback.
Require LM Studio fails document-vector production closed when the remote route cannot run and never loads the document model locally. Index refreshes still commit lexical documents and durable ledger progress, but remain incomplete while dense work is pending; similarity/search consumers use their supported non-dense fallback.

Interactive query encoders remain local in every mode. Saving a change creates a restart-required state: the selector shows the configured choice, the Settings record retains the currently effective choice, and the runtime panel shows the policy actually reported by the running service. A service restart promotes the pending choice.

The same page reports endpoint reachability separately from the configured model's current advertisement state, local document-model residency, last route/fallback, and provider cooldown or error details. An absent advertisement is inconclusive because LM Studio may load the model on demand; an actual route result is stronger evidence. The approximately 526 MB local-memory figure describes model weights, not guaranteed private-commit savings; buffers and allocator high-water state can persist until the process restarts.

The runtime panel also surfaces deterministic route-configuration failures (for example, a missing LM Studio model alias) before the first document batch. If Settings authority could not be read at service startup, it explains the enforced fail-closed remote route: query models stay available, while the document model remains non-eager and cannot fall back locally until the authority problem is fixed and the service restarts.

Dashboard AI defaults¶

wb.dashboard.assistance permits explicit form-agent starts; it does not itself send content or launch a model. wb.dashboard.chat-execution-default stores one atomic provider/model pair for new or unbound dashboard chats. Each conversation pins its own selection, so changing this default neither changes nor restarts existing chats. The old assistance-tier preference is retained dormant, not reinterpreted as an account-backed choice.

The default bootstraps once from the configured account-backed default and uses normal Settings revision/reset semantics. Selection and reset validate the exact pair with the execution provider registry. The shared model picker is also used here through a Settings-backed adapter. Local inference profiles are not registered interactive agent providers; contextual help explains the limitation, and no cloud fallback is selected on their behalf.

Broker behavior¶

The same-origin Settings API exposes registry, values, preview, mutation, and reset operations. Mutations use typed validation, revision checks, authority enforcement, and the dashboard read-only gate. Successful changes publish settings.changed to the live UI projection.

Registry-backed select controls use the same authoritative values path as the Journal time control. The reusable keybinding-map control also uses that path: one setting owns a declared command set and one atomic command-to-chord object, so capture, collision validation, persistence, reset, runtime resolution, and rendered shortcut hints share the same source of truth across Apps. Immediate values take effect in the mutation response; only settings explicitly declared next-boundary enter the Journal transition path. A stored default is frozen for its declared value_version, so changing a definition's default or representation requires a deliberate Settings-store migration rather than silently reinterpreting an existing profile. Co-work's legacy inverted/Vim Review-navigation value is therefore explicitly migrated to the complete shortcut map instead of being treated as the new representation.

Page search is immediate lexical filtering and keeps controls mounted so draft values are not destroyed. Global semantic Settings search is a separate integration boundary and is not supplied by browser calls to the embedding service.

/app/settings/status is a projection of the component dependency/control graph. It reports whether Work Buddy can operate and how requirements can be repaired; it is not a bag of ordinary editable settings.

See services/dashboard/react, architecture/control-graph, and journal/day-lifecycle.