v0.40.0
·
811 commits
to master
since this release
v0.40.0
Per-repository configuration profiles, clearer failure diagnostics across doctor and embedding surfaces, and a batch of community-reported fixes.
Configuration profiles (#354)
Define named model-selection profiles in your user config and select one per repository — work repositories can use work-provided models while personal repositories use your own subscriptions, simultaneously:
// <repo>/.cortexkit/magic-context.jsonc
{ "profile": "work" } // repositories select by name only- Profiles carry only the model-selection surface (historian/dreamer models, fallbacks, reasoning qualifiers); everything identity-bearing (embedding, storage, compaction, memory) is rejected at parse.
- Repository configs can never define profile contents — only select from your own set. Unknown names warn loudly and fall back to your base config.
- The active profile shows in
/ctx-status. Existing configs are untouched: no profiles block means byte-identical behavior to previous releases. - The feature passed an adversarial multi-model audit before release; both findings (an inherited-name lookup edge and an over-broad profile schema) are fixed in this release.
Fixes
- Embedding failures name their cause (#361):
/ctx-embedsummaries now distinguish served-model substitution rejections, HTTP errors, and malformed response envelopes — deterministic failures tell you what to change instead of advising a retry. - Telemetry honesty (#349):
m0_tool_set_hash_prevrecords NULL for first observations instead of an empty string that read as a phantom tool-set change. - Migration guard evidence (#281): the database migration blocking message now lists each blocking process with its command line and start time, so you can verify what the guard saw.
doctor --issue: GitHub issue creation failures name their cause (authentication, body size, transport) and always leave the diagnostics bundle at a local path; child sessions are now selectable for diagnosis with parent linkage.- Test isolation: plugin test runs use per-worker temporary databases and can no longer contend with production data under any invocation (#312).
Notes
- No database schema migration in this release.
- A production WAL/checkpoint investigation (#362) concluded no changes are needed; the report ships in-repo with escalation conditions documented.