Work-order history and model reliability
Work orders are moving behind a cleaner gateway and Postgres storage pilot, while safer model routing and history reloads reduce ghost turns and replay failures.
Work-order history is getting a more durable foundation, without changing the public default path yet.
Postgres pilot behind a storage flag
A Postgres-backed work-order gateway now supports headers, history, lists, and edges behind a storage mode flag. Public environments still default to the legacy Firestore, Redis, and BigQuery path. The pilot gives us a real migration lane without forcing a storage cutover before each customer environment is ready.
The UI is already compatible with the pilot path: work-order detail views handle safe dates, expanded history rows, invalidated refetch hints, and tool-result expansion.
One gateway for work-order history
Durable reads and writes now route through gateway chokepoints instead of scattered direct history calls. That makes history assembly, token usage, related artifacts, and cache invalidation easier to reason about during long conversations and autonomous runs.
Fresh reflection work orders also skip the old synthetic step-entry bootstrap message when there are no completed steps, keeping new chats and guided-plan openings cleaner.
Safer model and tool-call replay
Model routing has been updated to Gemini 2.5-only fallback chains after Gemini 2.0 retirement. Tool turns are normalized for Gemini replay, stable tool-call IDs are threaded into history, and GCS-first history reloads no longer replace full model turns with placeholder Firestore rows on Redis miss.
Reliability: gateway bypass checks now protect the migration path, system events carry tenant IDs for analytics and poller traces, and local OpenAI-compatible LLM routing is available for development and testing.