amosblomqvist
f9e3a4c43d
Model slots wave (2026-09-20), chunk B:
- settings: new `models` section {strong, cheap, vision} slots (each
field independent, same shape as a role override); ROLE_SLOT maps all
nine roles to tiers (strong=prober+teacher, cheap=researcher/
demoBuilder/extractor/auditor/labeler, vision=visualMaker+pdfReader);
resolution chain per role: override → slot → factory pin.
- config: ModelSpec gains provider (all pins openrouter, the BYOK
default); MODEL_PINS in stores.ts now spans all nine roles (the strong
slot's factory rep IS the prober pin).
- engine: piModels() registers EVERY builtin provider catalog;
piEngineForSpec(resolved spec) is the new engine factory (pi-ai
resolves per-provider keys from env itself); piEngineFor stays as the
config-pin fallback. chat-handler resolves the conversation chain
(chat override → strong slot → pin) and injects engineFor into the job
runner, closing the old gap where per-role overrides never reached
job engines.
- /api/models: models federate ONLY keyed providers (providers surface
with keyPresent, env-wins, fresh per call); slots (resolved tier pins)
join rolePins; catalogDefaultsFor inherits the strong slot; the models
settings section gets the same catalog gate as chat.
- pricing: PRICES/CONTEXT_LIMITS uniformly keyed provider:id
(regenerated from ALL pi-ai catalogs, 1354 keys); usage stamps
(TurnUsage, JobUsage, extraction stages) switch to provider:id —
owner decision: no legacy compat, old stamps render unpriced.
54 lines
2.1 KiB
TypeScript
54 lines
2.1 KiB
TypeScript
/**
|
|
* THE COMPOSITION ROOT for storage — the single place concrete store
|
|
* adapters are wired. Everything else (core, services, agents) codes against
|
|
* the port types in core/ports.ts and receives instances through this
|
|
* module. Swapping the fs adapter for SQLite later changes exactly this
|
|
* file (and the adapter implementations in src/store/).
|
|
*/
|
|
|
|
import { MODELS } from "../../config.ts";
|
|
import { chatStore } from "../store/chats.ts";
|
|
import { graphStore } from "../store/graph.ts";
|
|
import { jobStore } from "../store/jobs.ts";
|
|
import { settingsStore } from "../store/settings.ts";
|
|
import { resolveSettings, type EffectiveSettings, type ModelRoleSpecs } from "../core/settings-resolution.ts";
|
|
/** The wired adapters. Satisfies core/graph.ts's GraphDeps structurally. */
|
|
export const stores = {
|
|
chatStore,
|
|
graphStore,
|
|
jobStore,
|
|
settingsStore,
|
|
};
|
|
|
|
export type Stores = typeof stores;
|
|
|
|
/** config.ts's MODELS as the compiled factory layer the resolution reads —
|
|
* ALL NINE roles since the model-slots wave (2026-09-20): the strong
|
|
* slot's factory fallback IS the prober pin. core stays pure (it takes
|
|
* this as a parameter, never imports config at runtime). Per-role
|
|
* OVERRIDES stay background-only (the conversation pair is
|
|
* chat-settings-controlled) — that split lives in core's
|
|
* BACKGROUND_MODEL_ROLES, unchanged. */
|
|
const MODEL_PINS: ModelRoleSpecs = {
|
|
prober: MODELS.prober,
|
|
teacher: MODELS.teacher,
|
|
researcher: MODELS.researcher,
|
|
demoBuilder: MODELS.demoBuilder,
|
|
visualMaker: MODELS.visualMaker,
|
|
pdfReader: MODELS.pdfReader,
|
|
extractor: MODELS.extractor,
|
|
auditor: MODELS.auditor,
|
|
labeler: MODELS.labeler,
|
|
};
|
|
export { MODEL_PINS };
|
|
|
|
/**
|
|
* The resolved view of the settings record (core/settings-resolution.ts):
|
|
* every knob concrete, record overrides over config.ts factory pins. Read
|
|
* fresh on every call — the record is a small file and turns are rare, so
|
|
* no caching layer (stale toggles after a settings PUT would be worse).
|
|
*/
|
|
export function effectiveSettings(): EffectiveSettings {
|
|
return resolveSettings(settingsStore.readSettings(), MODEL_PINS);
|
|
}
|