Dream

Dream reviews recent local activity and produces a small set of suggestions for the operator to inspect. It is a deliberate review workflow, not an unattended public automation service.

Run and inspect

bun run scheduler:dream:status
bun run scheduler:dream:run
bun run scheduler:dream:status

The Home review queue shows the recommendation, rationale, timing, and visible apply or skip actions. Accepted or dismissed state is confirmed by fresh local data rather than hidden optimistic UI state.

Dream is enabled in scheduler metadata, but each execution still needs an explicit local activation through the dashboard, command process, or installed timer. A skipped run can therefore be correct when activation is absent.

Lifecycle and Replay

The Home surface supports dismiss, apply, and restore for existing suggestion IDs. The server derives the private state owner and accepts only the closed action; the browser cannot submit a replacement state or path. Home refetches after a successful action.

Replay presents a bounded recent history with safe dates, engine labels, titles, summaries, priorities, and lifecycle state. Invalid history degrades to product-facing recovery copy. The public demo can use only its reviewed snapshot and has no persistent lifecycle controls.

Provider and material readiness

Dream checks browser-safe host material first. When that material is stale or missing, it refreshes the scoped host and agent job without running Trend Finder collectors. It then evaluates provider readiness, locks, cooldowns, and output validation.

The codex Dream engine maps to the implemented subscription-backed account runtime. Account login, model entitlement, and consumer success are separate checks; see OpenAI subscription runtime.

Scheduling

bun run install-dream
bun run scheduler:dream:status

The installer manages the supported macOS or Windows timer path and prints Linux guidance. A timer registration is not proof that the latest run succeeded. Use the status command for actual run state.

Boundaries

• Dream runs locally through the scheduler-owned path.
• Output is validated and projected before it reaches the browser.
• Lifecycle actions persist locally and refresh from server-confirmed state.
• Engine-selection claims require matching code and tests; this guide does not imply an unverified live provider.
• The public demo shows reviewed fixtures and cannot execute Dream.