Planning Namespace Settings Project and Database Design

Summary

Please create a new project in a new worktree to start working on a new project called "Namespace Settings" to add more namespace config options. Follow project guidelines like others in @docs/projects/

One question is
i'm not sure if the right approach is to create a namespaceSettings table with columns for more configuration options, or just add more columns into namespaces. Settings will be things like

Privacy Settings (Default Privacy)
LLM Settings (OPENAI_API_KEY, used for Trace Summaries etc)

Please recommend an option after studying this repo

Done — I set this up in a fresh worktree and drafted the project plan.

New worktree: /Users/tarunsachdeva/code/traces-worktrees/feat-namespace-settings
Branch: feat/namespace-settings
New project doc: docs/projects/namespace-settings.md

I recommend using a dedicated namespaceSettings table (not adding config columns directly to namespaces), and handling sensitive values like OPENAI_API_KEY in a separate namespaceSecrets table (or secret-manager reference).

Why this is the safer fit for this repo:

api/convex/namespaces.ts:14 serves namespace profile data from namespaces on public paths.
api/convex/internal/namespaces.ts:9 returns full namespace docs and is used broadly in auth/session flows.
Trace default visibility is currently hardcoded in api/convex/services/traces.ts:125 and api/convex/services/traces.ts:166.
Trace summary LLM key is currently global env only in api/convex/utils/ai.ts:60.

So: keep namespaces as identity/profile, move configurable behavior to settings, and isolate secrets from general namespace reads.

If you want, I can now start Part 2 in this worktree and scaffold the schema + internal functions.

Okay, lets start

drop visibility as a setting this will just be a bheaviour inherited from the org

i just want to do openai_api_key / anthropic_api_key etc at namespace level

still wanna do namespaceSettings as a table but how do i set it up mimially

Great call. I started with the minimal setup for namespace-level provider keys only (no visibility setting).

Updated project plan to this narrower scope in docs/projects/namespace-settings.md.
Added namespaceSettings table in api/convex/schema.ts with:
- namespaceId
- llmApiKeys (Record<string, string>)
- updatedBy, updatedAt
Added internal settings primitives in api/convex/internal/namespace_settings.ts:
- getProviderApiKey
- setProviderApiKey
- listConfiguredProviders
Wired trace summary to use namespace OpenAI key first, then env fallback:
- api/convex/internal/scheduled/traceSummary.ts
- api/convex/utils/ai.ts (now accepts optional key override)
Updated cleanup/reset paths for the new table:
- api/convex/internal/test_helpers.ts
- api/convex/reset.ts

Minimal model recommendation (what we now have):

Keep namespaces as identity/profile only.
Keep one namespaceSettings row per namespace.
Store provider keys in llmApiKeys map keyed by provider name (openai, anthropic, etc.).
Use internal read/write functions first, then add admin HTTP/UI next.

Note:

This is intentionally minimal and currently stores keys directly in DB (not encrypted yet). Good for quick iteration, but before broader rollout we should add encryption-at-rest.

I couldn’t run tests here because bun is unavailable in this environment.
If you want, next I can implement admin-only HTTP endpoints (GET/PATCH /v1/namespaces/:slug/settings) with masked responses so the settings page can manage keys safely.

why do we need - updatedBy, updatedAt it doesnt make sense for settings at this level

also convex gives us stuff for free