Share the core between CLI and web, notify on stale installs, and make web a workspace

[jellologic]

Four related changes, all downstream of one question: do the CLI and the web UI actually share what they should? They did not, and looking properly turned up two shipped bugs.

1. The account rules had no owner

An account holding both an API key and a session directory produced four different behaviours:

web API     refused to save it
onboard     refused to create it
the launch  silently dropped the key and used the session, no warning
the doctor  "✓ credential: no ANTHROPIC_API_KEY; this provider allows that"
            — about a config that visibly contains an API key
CLI listing rendered only the session line; the key was invisible

core/account.ts now owns it: credentialSource (which models conflict as a real state rather than normalising it away), validateAccount, one shared CONFLICT_REASON sentence, and accountsUsedBy — the reverse index that existed in three copies. formatWindow joins core/format.ts, replacing two helpers written on the same day.

Consequences, not extras: the doctor gains a credential-conflict check, the CLI calls the problem out before describing the account, and the browser says the same sentence. Verified on one config across all three surfaces.

Why not a UI port, since that was the original question: driven ports (ConfigStorePort, ProcessPort, ProviderUsagePort) are interfaces the app defines and adapters implement — that side was already right. CLI and web are driving adapters; they call in, and the port on that side is the application's use-case API itself. A ports/ui.ts both implemented would be inverted, forcing terminal text, JSON and DOM into one rendering vocabulary. What was missing was the use-case layer, smeared across config-root.ts and web/api.ts.

2. Nobody knew they were running an old swisscode

bunx swisscode serves a stale cached version — measured against the live registry: with 0.4.0 published, npx resolved 0.4.0 while plain bunx kept running a cached 0.3.0, which cannot read a v3 config and reports provider undefined.

The launch path may not check for updates: test/architecture.test.ts forbids fetch and every socket module there, and proc.replace is execve, so there is no "after launch" either. A detached spawn would put a network call in the launch's causal chain for a notice.

So it is split. config/doctor/web refresh a cached "latest version" at most once a day as a side errand; a launch reads that one file and prints a single line. Documented consequence: someone who only ever launches never refreshes the cache and never sees the notice.

Adds swisscode config upgrade and --cc-version — deliberately not --version, which belongs to the agent and which scripts depend on.

3. The browser model picker was the worse one

Both UIs are React, so it was easy to assume they shared what matters:

	Ink	Web (before)
Filtering	core.filterModels	inline copy, no free-only filter
Sorting	core.rank (benchmark)	none — registry order
A free model	free	$0.00/M
1M context	1M	1000K

That file's own header says "a catalog with no prices shows no prices, rather than '$0.00', which would read as free" — and eleven lines down it rendered exactly that.

Root cause was a hand-written type: web/src/api.ts mirrored NormalizedModel narrowly, so the browser could not call rank, which sorts on benchmarks — a field the server was already sending and the type simply hid. Same for CatalogCapabilities, whose mirror had lost requiresAuth. Both are type-only imports now. Verified in a browser against the live OpenRouter catalog.

4. web/ is a workspace

It had a tsconfig and a vite config but no manifest, so vite, panda, preact and @types/react-dom sat in the root manifest advertising themselves as dependencies of a launcher that never loads them.

One lockfile, and it has to be package-lock.json. bun install does not read it and resolves fresh — 5 transitive packages disagreed in a measured diff — and bun publish has no OIDC/provenance, so npm is permanently in the release path. bun.lock is gitignored. Bun remains a first-class runtime: bun run test passes 770/770 against an npm-installed tree.

Two things this shook out, fixed rather than worked around: npm run --workspace web x breaks under bun (which rewrites npm run to bun run and spells it --filter), and build.js hard-coded a hoisting layout the two installers do not agree on.

Verification

770 tests, 122.8 kB packed (ceiling 150). Verified under both npm and bun: install, npm ci, build, full suite, packed artifact. The browser work was driven through a real browser against a live catalog. No change to the published artifact's shape.