Forelead handbook

Appearance

Switchover ​

This is how agent work for forelead-ai/platform moves from Switchboard to Forelead, and how to move it back. It moves one repository's intake. It does not move other Switchboard boards.

In plain words ​

  1. Prove the route. Record the exact commit the installed image was built from, and check the preflight, runner capacity, mirror, gates, publish and the status view really work. A running Compose service alone is not proof.
  2. Run a pilot. Route five platform issues in a row through Forelead, from Ready to an approved, gate-green PR. Any restart, manual fix, nudge or human state change breaks the streak. Never give the same issue to both systems.
  3. Cut over intake. Stop giving new platform issues to Switchboard, let its active tasks finish, then route the next Ready issue to Forelead and watch it.
  4. Keep a way back. Roll back intake to Switchboard if Forelead cannot claim or complete work, a gate cannot run, evidence is missing, or the sandbox is unsafe. Rolling back intake does not roll back database migrations or discard records.
  5. Keep an independent path for changes to the runner, sandbox, lifecycle state machine and GitHub adapter, for at least four weeks of stable operation.
  6. Last step: disable the Forelead board entry in Switchboard's configuration. This is a routing change, not a deletion.

Technical notes ​

  • /v1/tasks reports currentStreak and switchoverReady per linked repository. They are a starting check only: audit all five records and the GitHub readbacks yourself.
  • The criteria are from decision 0017 S2 and S3 and 0016 O10 in the design repository.

Sources ​