Nest as the door, not the engine room

Two runtimes that both believe they own the clock will eventually lie to managers. Late July’s stake was to finish the story the Go migration started: Nest should answer HTTP and enqueue work; dedicated workers and schedulers should be the only processes that consume that work.

What shipped was Nest runtime removal in earnest — processors, cron producers, and consumer-only domain services deleted after staging cutover confidence, with API-only role assertions and docs/compose defaults updated to match. Nest still owns the public /v1 surface and continues to enqueue; Go owns dugout-worker and dugout-scheduler. Orphan schedule residue and processor-only methods that had lingered as comfort blankets were cleared rather than left “just in case.” In simple terms, the API process stopped moonlighting as a background farm.

The challenges were residual temptation and local developer muscle memory. It is easy to keep a Nest cron “for convenience” or a dual path “until we are sure”; each leftover is a second heartbeat waiting for a config mistake. The strength of a hard API-only role is a crisp mental model for agents and humans alike; the drawback is that local demos now require the Go binaries beside Nest, which is the correct cost rather than a temporary inconvenience.

Paths not taken included keeping Nest processors as a permanent fallback, splitting “light” crons back into the API process, or delaying deletion until every accepted divergence was closed. Permanent fallback invites double consumption; light crons become heavy the day they matter; waiting for perfection would have left the ownership story half-told after the cutover already proved the point.

What it unlocked was a thinner Nest for youth and player-dev work to land against — enqueue, read, admin preview — without another round of deleting tick orchestrators after the fact.