Patch Changes

• Updated dependencies [351d172]:
  • @context-chef/[email protected]

Patch Changes

• 351d172 Thanks @MyPrototypeWhat! - Add AbortSignal support to compile() and event handlers (T2.4).

  CompileOptions.signal?: AbortSignal propagates cooperative cancellation in two ways:

  1. Forwarded to event handlers as the second argument. chef.on(event, async (payload, signal) => { await db.write(payload, { signal }); }) lets observers honor cancellation in slow async work (DB writes, metric exports, fetch calls).
  2. Checked at compile() phase boundaries — after compile:start, after Janitor compress, after onBeforeCompile, after memory sweep, after transformContext. Aborting throws via signal.throwIfAborted() (DOMException with name: 'AbortError').

  EventHandler<T> signature widened to (payload: T, signal?: AbortSignal) => void | Promise<void>. Backward compatible — handlers that don't declare the second parameter continue to work unchanged.

  Memory events fired from external memory().set() / memory().delete() calls (outside compile()) receive signal: undefined.

  Caveats (documented in CompileOptions.signal JSDoc):

  • compile:start is emitted before any abort check — observers may receive a compile:start for a compile that ultimately throws without firing compile:done.
  • Memory turn counter advances at step 4; aborting after step 4 leaves Memory.turnCount advanced even though no payload was produced.
  • Cancellation is coarse-grained — long-running phases run to completion; abort honored at the next phase boundary.

  Known limitation: compile() is not concurrency-safe on the same chef instance — concurrent calls clobber _currentSignal, double-advance the memory turn counter, and interleave skill/history reads. Serialize per chef instance, or create separate instances for parallel work. Snapshot+serialize support is planned (see TODO.md T2.4.1).

Patch Changes

• Updated dependencies [351d172]:
  • @context-chef/[email protected]

Patch Changes

• 0b09ce5 Thanks @MyPrototypeWhat! - Error message UX patch — clearer text, consistent empty-registry rendering, and one real config-field-name fix.

  Real bug fix

  • ContextChef.getMemory(): previously claimed requires a memoryStore in ChefConfig, but the actual config field is memory: { store: ... } — not memoryStore. Users hitting this error and grep'ing the docs found nothing. Now points at the correct field name plus a hint about the three built-in store implementations (InMemoryStore, VFSMemoryStore, custom MemoryStore).

  Clearer error text

  • tanstack-ai's compactConfig rejection: previously Unrecognized toolCalls compact mode: "X" left users to grep the source for valid values. Now lists all four ('none', 'all', 'before-last-message', 'before-last-N-messages') with the N-substitution example.
  • loadSkill parse errors: missing name / description errors now embed a minimal SKILL.md frontmatter snippet so the fix is obvious from the error alone. The "indented values are not supported" error now points to inline-array / quoted-string workarounds. The missing-description snippet reuses the user's parsed name (sanitized: long names or --- literals fall back to my-skill to avoid generating a malformed example).

  Consistent empty-registry rendering

  Five throw sites across the library now render an empty options list as (none) rather than producing Available: (trailing empty space) or Registered: []. — matches the pattern already used by ContextChef.activateSkill:

  • Pruner.extractToolkit — empty toolkit registry
  • Pruner.resolveNamespace (unknown namespace) — empty namespace registry
  • Pruner.resolveNamespace (unknown action) — namespace with no tools
  • AdapterRegistry.get — empty adapter registry

  Consumer-visible side effect for loadSkill errors only

  The missing-name and missing-description loadSkill errors now contain literal \n newlines (the example snippet). Code that does error.message.split('\n')[0] to summarize, or relies on these messages being single-line for log formatting, will see the extra lines. Multi-line messages flow through loadSkillsDir's result.errors[].message field; if you JSON-serialize that for transport or UI, the newlines become \\n and the snippet renders less readably than in a terminal log. The other rewritten messages (getMemory, compactConfig, Pruner / AdapterRegistry empty fallbacks, "indented values") all remain single-line.

• Updated dependencies [0b09ce5]:

  • @context-chef/[email protected]

Patch Changes

• 135337d Thanks @MyPrototypeWhat! - Tighten tokenizer option signature from (messages: unknown[]) => number to (messages: Message[]) => number.

  The middleware always invokes the user-supplied tokenizer with Message[] (the core IR type) — the previous unknown[] was a leak in the public type, forcing callers to cast or narrow inside their tokenizer. The new signature matches the actual runtime contract and matches @context-chef/core's Janitor config.

  Type-only change; no runtime behavior change. Existing tokenizers typed as (messages: unknown[]) => number will continue to compile, but callers can now drop the cast and read Message fields directly.

Patch Changes

• 0b09ce5 Thanks @MyPrototypeWhat! - Error message UX patch — clearer text, consistent empty-registry rendering, and one real config-field-name fix.

  Real bug fix

  • ContextChef.getMemory(): previously claimed requires a memoryStore in ChefConfig, but the actual config field is memory: { store: ... } — not memoryStore. Users hitting this error and grep'ing the docs found nothing. Now points at the correct field name plus a hint about the three built-in store implementations (InMemoryStore, VFSMemoryStore, custom MemoryStore).

  Clearer error text

  • tanstack-ai's compactConfig rejection: previously Unrecognized toolCalls compact mode: "X" left users to grep the source for valid values. Now lists all four ('none', 'all', 'before-last-message', 'before-last-N-messages') with the N-substitution example.
  • loadSkill parse errors: missing name / description errors now embed a minimal SKILL.md frontmatter snippet so the fix is obvious from the error alone. The "indented values are not supported" error now points to inline-array / quoted-string workarounds. The missing-description snippet reuses the user's parsed name (sanitized: long names or --- literals fall back to my-skill to avoid generating a malformed example).

  Consistent empty-registry rendering

  Five throw sites across the library now render an empty options list as (none) rather than producing Available: (trailing empty space) or Registered: []. — matches the pattern already used by ContextChef.activateSkill:

  • Pruner.extractToolkit — empty toolkit registry
  • Pruner.resolveNamespace (unknown namespace) — empty namespace registry
  • Pruner.resolveNamespace (unknown action) — namespace with no tools
  • AdapterRegistry.get — empty adapter registry

  Consumer-visible side effect for loadSkill errors only

  The missing-name and missing-description loadSkill errors now contain literal \n newlines (the example snippet). Code that does error.message.split('\n')[0] to summarize, or relies on these messages being single-line for log formatting, will see the extra lines. Multi-line messages flow through loadSkillsDir's result.errors[].message field; if you JSON-serialize that for transport or UI, the newlines become \\n and the snippet renders less readably than in a terminal log. The other rewritten messages (getMemory, compactConfig, Pruner / AdapterRegistry empty fallbacks, "indented values") all remain single-line.

Patch Changes

• Updated dependencies [0b09ce5]:
  • @context-chef/[email protected]

Patch Changes

• 135337d Thanks @MyPrototypeWhat! - Tighten tokenizer option signature from (messages: unknown[]) => number to (messages: Message[]) => number.

  The middleware always invokes the user-supplied tokenizer with Message[] (the core IR type) — the previous unknown[] was a leak in the public type, forcing callers to cast or narrow inside their tokenizer. The new signature matches the actual runtime contract and matches @context-chef/core's Janitor config.

  Type-only change; no runtime behavior change. Existing tokenizers typed as (messages: unknown[]) => number will continue to compile, but callers can now drop the cast and read Message fields directly.

Patch Changes

• Updated dependencies [31d1812]:
  • @context-chef/[email protected]

Minor Changes

• b9cec8b Thanks @MyPrototypeWhat! - feat: add usagePreference to control which token source drives compression triggers

  When both a tokenizer and a reportTokenUsage() value are available, you can now choose
  how the Janitor decides whether to compress:

  • 'max' (default, backward-compatible) — Math.max(tokenizer, fed). Most conservative;
    any over-budget signal triggers compression.
  • 'feedFirst' — prefer the API-reported usage when present, fall back to the tokenizer.
    Use when reported usage is authoritative and the tokenizer over-estimates (e.g. one
    config shared across providers, some of which report usage and some of which rely on
    the tokenizer fallback).
  • 'tokenizerFirst' — ignore the fed value entirely; trust the tokenizer.

  The split-index calculation is unchanged — it always uses precise per-turn tokenization
  in the tokenizer path. usagePreference only affects the trigger decision.

  Both middleware packages expose this as compress.usagePreference. When 'tokenizerFirst'
  is set without a tokenizer, the middleware sanitizes it to 'max' at construction time
  with a console warning.

  Type-level note. JanitorConfig is now a discriminated union on tokenizer presence.
  TypeScript rejects 'tokenizerFirst' at compile time when no tokenizer is configured.
  Callers that previously passed tokenizer: SomeFn | undefined in a single literal will
  need to split construction into two branches (tokenizer ? new Janitor({...}) : new Janitor({...}));
  runtime behavior is unchanged.

Patch Changes

• Updated dependencies [b9cec8b]:
  • @context-chef/[email protected]