• Verified live in LM Studio on google/gemma-4-26b-a4b-qat and gpt-oss-20b: reasoning collapses into the native "Thought for Ns" block, bash_terminal / update_plan_step execute as real tool calls with correct names and expandable arguments/results, and no raw tags reach the chat bubble.
• tests/index.test.ts previously asserted the inverted invariant (that withToolsProvider was never registered), so it would have stayed green on the broken wiring indefinitely. It now guards both directions.

• Consequence: MIN_SUBSTANTIAL_HISTORY_CHARS was recalibrated 500 → 150. Against the 19-char constant, > 500 was never true, so the new-conversation detection had never fired in production in any code path.

• A mid-conversation compaction/roll still preserves the plan — the reset only fires on a dramatic shrink with no vibeLM managed-context block present, which is what distinguishes a new chat from a roll.

Plan steps can now override the session's reasoningEffort setting individually. create_plan accepts either a plain string or { description, thinking } per step (thinking is "off"|"low"|"medium"|"high"), and update_plan_step can set/change it later. When resolving the thinking directive for a bridge tick, the current step's override (the first in_progress step, or failing that the first pending one) wins over the session-wide config. This lets one plan mark mechanical steps "off" and a tricky step "high" instead of applying one uniform reasoning level to every step — the per-model-family directive mapping (reasoningDirectiveFor) already handled Qwen's binary /think//no_think switch, gpt-oss's native Harmony tiers, and a generic natural-language fallback for everything else, so this only needed a new source for which effort to apply, not new per-family logic.

vibe_bridge ticks now give a generous maxTokens floor (6000) to architectures whose reasoning can't actually be turned off, instead of leaving it uncapped or subject to whatever ambient per-model limit LM Studio applies. Live-tested against real loaded models across gpt-oss-20b, qwen3-4b, google/gemma-4-e4b, microsoft/phi-4-mini-reasoning, and nvidia/nemotron-3-nano-omni: qwen3's native /no_think switch works correctly (reasoning_tokens: 1), but gemma-4 and Nemotron-H kept producing full reasoning_content regardless of vibeLM's directive or NVIDIA's own documented "detailed thinking off"/<thought off> conventions, and LM Studio's own native reasoning REST setting (/api/v1/chat) outright rejected "off" for phi-4-mini-reasoning with "Supported settings: 'on'" — i.e. LM Studio itself confirms there is no off-switch for that model. Under a tight token budget this reasoning can consume the entire allowance before the model reaches its answer — reproduced live on phi-4-mini-reasoning, which returned empty content with finish_reason: "length" after burning 396 of 400 tokens on reasoning alone. resolveBridgeTickMaxTokens(arch) now detects this class of architecture (gemma.?4|phi.?[34]|nemotron) and gives it explicit headroom so a verbose reasoning phase can't silently starve the tick of room for its actual answer/tool call.

A mid-conversation lms dev hot reload (or plugin process restart) could silently drop an in-progress plan instead of resuming it. bootstrapSessionState() had two paths for "the raw conversation history can't be matched against what was persisted": one for "history exists but its fingerprint doesn't match" (already correctly carried the last-known plan/managedContextBlocks forward) and one for "no history could be read at all" (hard-reset to a blank session, no carryover). The second path fires whenever the very first bootstrap call after a reload comes from a controller with no pullHistory() — which is exactly what happens when vibe_bridge's background tick runs before any real preprocessMessage() call re-establishes history. Caught live: editing toolsProvider.ts while a real vibe_bridge-driven session was mid-plan triggered esbuild's watch rebuild, and the next tick came up with a brand-new sessionId and an empty plan — even though the plan was still sitting in runtime-state.json on disk the whole time. The no-history path now carries over the persisted plan and managedContextBlocks the same way the fingerprint-mismatch path already did.

Every real conversation turn silently started a brand-new session, resetting turnCounter to 0 and making auto-compaction, session-scoped fact-dedup, and the context-spine resume mechanism unreachable in production. toolsProvider() forced a session-state re-bootstrap on every call using its own ToolsProviderController, which — unlike the PromptPreprocessorController — has no pullHistory() method (confirmed against the SDK's own type definitions). The forced bootstrap's history read always silently failed, so it always concluded "history unreadable, must be a fresh/rolled session" and manufactured a new random sessionId, discarding whatever preprocessMessage() had correctly established moments earlier in the same turn. Caught live driving a real multi-turn LM Studio conversation: runtime-state.json's sessionId changed on every single turn and turnCounter never advanced past 0, even though the working-window/spine/compaction machinery all assume sessionId identifies one whole conversation, not one exchange. toolsProvider() no longer forces the bootstrap; it reuses the state preprocessMessage() already established for the turn.

Live re-testing after the fix above still showed sessionId changing across some turns even without a process reload. Suspected contributing factors, not yet isolated: vibe_bridge's background tick shares the same module-level session state via its own separate model.act() call (built from a minimal handover summary, not the real conversation history), and/or having two plugin instances (a lms dev instance and a stale production install) simultaneously enabled in LM Studio, each with independent in-memory state. Needs a clean, uncounfounded live session (fresh chat, vibe_bridge disabled from the start, single plugin instance) to isolate further.

Importance-tiered context budgeting (Layer 3). Replaces the blunt fixed limits with tiers keyed on importance:

• Tool-result retention is no longer a flat 500-char cap for every tool. Information-bearing reads/searches keep up to 1500 chars, failures keep 300 (they're already distilled into a fact), everything else keeps 500 — so a 3 KB file read now survives on the turn log instead of losing 83% of itself the same way a one-line failed probe did.
• The pinned head (context spine) is assembled tier-by-tier under a char budget (20% of the context window, so it scales with the model) instead of a fixed fact count: goal + plan are pinned first, then established facts fill whatever budget remains.
• The session goal is auto-populated into the persisted plan field from the first substantive request, so the pinned head has a goal to anchor to even when the model never calls create_plan. parsePersistedPlan now accepts a goal-only plan (previously it silently dropped any plan with zero steps, which would have discarded the auto-goal on the next read).
• The working-window FIFO is now head+tail retention — it pins the first turn (the session anchor) plus the most recent turns and cuts the middle, instead of rolling the oldest (the goal) off first.

Cut-the-middle context retention via a pinned "context spine". Previously, when the LM Studio host rolled raw history it dropped the oldest turns first — the goal and everything the agent had established — and vibeLM only re-asserted its last directive, so early context was effectively lost (a rolling/tail strategy). vibeLM now rebuilds a pinned head from durable state — the plan (goal + step statuses) plus the top distilled facts — and re-injects it on resume after a detected roll. The head survives, the recent tail is whatever the host still holds, and the middle is deliberately not reproduced (only its distilled facts carry forward). Facts fall back to the most recent across sessions when a roll has regenerated the session id, so the "what we've learned" block isn't empty exactly when it's needed most.

• Workspace: set_workspace, get_config
• Files: list_files, read_file, write_file, append_file, rename_file, search_files, delete_file
• Shell: bash_terminal
• Memory: save_memory, search_memory, list_memories, update_memory, delete_memory, clear_memories
• Context: compact_context
• Web: web_fetch, web_search
• Math & Time: calculate, get_current_datetime
• Utilities: generate_uuid, generate_password, encode_base64, decode_base64
• Infrastructure: ssh_exec, check_service
• Sub-agent: consult_expert (coder, debugger, architect, reviewer, writer, analyst, researcher, data_scientist, knowledge_keeper)
• Response control: respond_to_user (later renamed to amend)

• Verified live in LM Studio on google/gemma-4-26b-a4b-qat and gpt-oss-20b: reasoning collapses into the native "Thought for Ns" block, bash_terminal / update_plan_step execute as real tool calls with correct names and expandable arguments/results, and no raw tags reach the chat bubble.
• tests/index.test.ts previously asserted the inverted invariant (that withToolsProvider was never registered), so it would have stayed green on the broken wiring indefinitely. It now guards both directions.

• Consequence: MIN_SUBSTANTIAL_HISTORY_CHARS was recalibrated 500 → 150. Against the 19-char constant, > 500 was never true, so the new-conversation detection had never fired in production in any code path.

• A mid-conversation compaction/roll still preserves the plan — the reset only fires on a dramatic shrink with no vibeLM managed-context block present, which is what distinguishes a new chat from a roll.

Plan steps can now override the session's reasoningEffort setting individually. create_plan accepts either a plain string or { description, thinking } per step (thinking is "off"|"low"|"medium"|"high"), and update_plan_step can set/change it later. When resolving the thinking directive for a bridge tick, the current step's override (the first in_progress step, or failing that the first pending one) wins over the session-wide config. This lets one plan mark mechanical steps "off" and a tricky step "high" instead of applying one uniform reasoning level to every step — the per-model-family directive mapping (reasoningDirectiveFor) already handled Qwen's binary /think//no_think switch, gpt-oss's native Harmony tiers, and a generic natural-language fallback for everything else, so this only needed a new source for which effort to apply, not new per-family logic.

vibe_bridge ticks now give a generous maxTokens floor (6000) to architectures whose reasoning can't actually be turned off, instead of leaving it uncapped or subject to whatever ambient per-model limit LM Studio applies. Live-tested against real loaded models across gpt-oss-20b, qwen3-4b, google/gemma-4-e4b, microsoft/phi-4-mini-reasoning, and nvidia/nemotron-3-nano-omni: qwen3's native /no_think switch works correctly (reasoning_tokens: 1), but gemma-4 and Nemotron-H kept producing full reasoning_content regardless of vibeLM's directive or NVIDIA's own documented "detailed thinking off"/<thought off> conventions, and LM Studio's own native reasoning REST setting (/api/v1/chat) outright rejected "off" for phi-4-mini-reasoning with "Supported settings: 'on'" — i.e. LM Studio itself confirms there is no off-switch for that model. Under a tight token budget this reasoning can consume the entire allowance before the model reaches its answer — reproduced live on phi-4-mini-reasoning, which returned empty content with finish_reason: "length" after burning 396 of 400 tokens on reasoning alone. resolveBridgeTickMaxTokens(arch) now detects this class of architecture (gemma.?4|phi.?[34]|nemotron) and gives it explicit headroom so a verbose reasoning phase can't silently starve the tick of room for its actual answer/tool call.

A mid-conversation lms dev hot reload (or plugin process restart) could silently drop an in-progress plan instead of resuming it. bootstrapSessionState() had two paths for "the raw conversation history can't be matched against what was persisted": one for "history exists but its fingerprint doesn't match" (already correctly carried the last-known plan/managedContextBlocks forward) and one for "no history could be read at all" (hard-reset to a blank session, no carryover). The second path fires whenever the very first bootstrap call after a reload comes from a controller with no pullHistory() — which is exactly what happens when vibe_bridge's background tick runs before any real preprocessMessage() call re-establishes history. Caught live: editing toolsProvider.ts while a real vibe_bridge-driven session was mid-plan triggered esbuild's watch rebuild, and the next tick came up with a brand-new sessionId and an empty plan — even though the plan was still sitting in runtime-state.json on disk the whole time. The no-history path now carries over the persisted plan and managedContextBlocks the same way the fingerprint-mismatch path already did.

Every real conversation turn silently started a brand-new session, resetting turnCounter to 0 and making auto-compaction, session-scoped fact-dedup, and the context-spine resume mechanism unreachable in production. toolsProvider() forced a session-state re-bootstrap on every call using its own ToolsProviderController, which — unlike the PromptPreprocessorController — has no pullHistory() method (confirmed against the SDK's own type definitions). The forced bootstrap's history read always silently failed, so it always concluded "history unreadable, must be a fresh/rolled session" and manufactured a new random sessionId, discarding whatever preprocessMessage() had correctly established moments earlier in the same turn. Caught live driving a real multi-turn LM Studio conversation: runtime-state.json's sessionId changed on every single turn and turnCounter never advanced past 0, even though the working-window/spine/compaction machinery all assume sessionId identifies one whole conversation, not one exchange. toolsProvider() no longer forces the bootstrap; it reuses the state preprocessMessage() already established for the turn.

Live re-testing after the fix above still showed sessionId changing across some turns even without a process reload. Suspected contributing factors, not yet isolated: vibe_bridge's background tick shares the same module-level session state via its own separate model.act() call (built from a minimal handover summary, not the real conversation history), and/or having two plugin instances (a lms dev instance and a stale production install) simultaneously enabled in LM Studio, each with independent in-memory state. Needs a clean, uncounfounded live session (fresh chat, vibe_bridge disabled from the start, single plugin instance) to isolate further.

Importance-tiered context budgeting (Layer 3). Replaces the blunt fixed limits with tiers keyed on importance:

• Tool-result retention is no longer a flat 500-char cap for every tool. Information-bearing reads/searches keep up to 1500 chars, failures keep 300 (they're already distilled into a fact), everything else keeps 500 — so a 3 KB file read now survives on the turn log instead of losing 83% of itself the same way a one-line failed probe did.
• The pinned head (context spine) is assembled tier-by-tier under a char budget (20% of the context window, so it scales with the model) instead of a fixed fact count: goal + plan are pinned first, then established facts fill whatever budget remains.
• The session goal is auto-populated into the persisted plan field from the first substantive request, so the pinned head has a goal to anchor to even when the model never calls create_plan. parsePersistedPlan now accepts a goal-only plan (previously it silently dropped any plan with zero steps, which would have discarded the auto-goal on the next read).
• The working-window FIFO is now head+tail retention — it pins the first turn (the session anchor) plus the most recent turns and cuts the middle, instead of rolling the oldest (the goal) off first.

Cut-the-middle context retention via a pinned "context spine". Previously, when the LM Studio host rolled raw history it dropped the oldest turns first — the goal and everything the agent had established — and vibeLM only re-asserted its last directive, so early context was effectively lost (a rolling/tail strategy). vibeLM now rebuilds a pinned head from durable state — the plan (goal + step statuses) plus the top distilled facts — and re-injects it on resume after a detected roll. The head survives, the recent tail is whatever the host still holds, and the middle is deliberately not reproduced (only its distilled facts carry forward). Facts fall back to the most recent across sessions when a roll has regenerated the session id, so the "what we've learned" block isn't empty exactly when it's needed most.

• Workspace: set_workspace, get_config
• Files: list_files, read_file, write_file, append_file, rename_file, search_files, delete_file
• Shell: bash_terminal
• Memory: save_memory, search_memory, list_memories, update_memory, delete_memory, clear_memories
• Context: compact_context
• Web: web_fetch, web_search
• Math & Time: calculate, get_current_datetime
• Utilities: generate_uuid, generate_password, encode_base64, decode_base64
• Infrastructure: ssh_exec, check_service
• Sub-agent: consult_expert (coder, debugger, architect, reviewer, writer, analyst, researcher, data_scientist, knowledge_keeper)
• Response control: respond_to_user (later renamed to amend)