Skip to content

Local Dogfooding

The first user is the project owner on a local machine. Dogfooding must be safe, observable, and reversible.

Default posture

  • one disposable sandbox per run;
  • workspace-only write access;
  • restricted or disabled network by task;
  • no host home, SSH, cloud credentials, browser profile, or Docker socket mounts;
  • no production database or deployment access;
  • feature branches and local commits only;
  • snapshots before destructive or high-risk steps;
  • immutable outputs copied outside the sandbox;
  • human approval for protected branches, port exposure, credentials, and deployment.

Run evidence

Every dogfood run should retain the specification, policy version, sandbox/session IDs, decision events, command results, test output, published artifacts, checkpoints, and final acceptance result.

The smallest useful dogfood loop is: define the objective, inspect the policy decision, run in a disposable workspace, verify the result, review the retained evidence, and clean up only after the evidence is preserved. This gives the project owner a repeatable acceptance path before a workflow is shared with other users or connected to external systems.

Escalation

When a task is ambiguous or requires authority outside the active policy, pause and record the exact request. Do not broaden the sandbox globally to unblock one task.