Dogfooding Yoi

This repository is developed with Yoi itself. Dogfooding is valuable because it exposes orchestration, memory, TUI, and workflow problems under real use.

Pre-restart gate

Never use the live dogfood Server or Runtime as the first startup test for a new binary. A dogfood restart is allowed only after this sequence succeeds:

Build the production entrypoints: cargo build -p worker-runtime --bin yoi-runtime -p yoi-workspace-server --bin yoi-server.
Run the focused and dependent tests for the changed contracts, followed by cargo fmt --all -- --check and git diff --check HEAD.
Run scripts/isolated-startup-smoke.sh from an external shell/process.
Inspect any failed run's retained /tmp/yoi-isolated-startup-smoke.* logs; do not restart dogfood until the cause is fixed and the smoke passes.
Have an external supervisor or operator restart Server and Runtime. A Worker hosted by the target Runtime must never terminate its own Runtime.
Verify post-restart readiness through the Workspace Runtime projection and a real restored Worker operation before treating the environment as healthy.

The smoke harness runs the normal yoi-server and yoi-runtime binaries using separate HOME, XDG_DATA_HOME, XDG_CONFIG_HOME, temporary Git repository, Server database, Runtime fs store, identity/trust material, and non-dogfood ports. It fails if either port is already occupied, if state escapes the temporary root, if a process exits unexpectedly, if Runtime readiness is not visible through Server, or if startup logs contain a panic, migration collision, or Worker execution restore failure. It also proves that a listening Server without its configured Runtime is not readiness and restarts the isolated Runtime once to exercise persistence reopen.

Override YOI_SMOKE_SERVER_BIN, YOI_SMOKE_RUNTIME_BIN, YOI_SMOKE_SERVER_PORT, or YOI_SMOKE_RUNTIME_PORT only when a separate build or port is intentionally under test. Set YOI_SMOKE_KEEP=1 to retain successful artifacts. Failed artifacts are retained automatically.

What to record

When a tool limitation, workflow obstacle, or model-facing policy problem blocks work, record it under docs/report/ or a work item artifact. Do not turn every minor annoyance into a maintained design doc.

A report is useful when it explains:

what the agent/user tried to do
what made the work unsafe, confusing, or slow
what design boundary was missing
what evidence was observed

Runtime command caveat

After rebuilding and restarting during dogfooding, current_exe() can point at a deleted binary path. Use typed runtime-command configuration and the development-only YOI_POD_RUNTIME_COMMAND executable override rather than reviving shell-command overrides.

Multi-Worker work

Use child Workers for scoped tasks and reviews, but keep orchestration decisions in visible project records. Do not merge, close, or clean up merely because a child notification arrived.

Secrets and logs

Do not put secrets, private prompts, or ignored secret-like file contents into diagnostics, work items, docs, session logs, or model context. During broad audits, existence/path checks are enough unless the user explicitly asks to inspect content.

3.2 KiB Raw Blame History