Oneshot Websites

Give each experiment to a fresh lead subagent, pass it the actual prompt, and let it decide how to accomplish the task.

“One-shot” describes the delegation boundary: one initial task prompt and one owning lead subagent per experiment. It does not mean one model call, a short turn, a fixed stack, or a restricted workflow. The lead may work for as long as the task needs, use any suitable tools or dependencies, revise its own work, create its own subagents, and let those descendants recursively create further descendants. The build process is open; the final handoff is a static folder with one root index.html entrypoint and as many supporting asset files and directories as the experience needs.

When the user selects verification, the lead also owns a lean internal quality gauntlet: establish an inspectable bar, build, and give one fresh critic the real rendered result rather than a builder summary. A READY verdict ends the gauntlet; a NOT_READY verdict returns one coherent batch of material blockers for a single build pass and a targeted recheck. These are internal revisions by the same lead inside the same one-shot run, not coordinator follow-ups or new experiments.

Choose Verification Before Dispatch

Before reserving or dispatching a new build, ask: “Run the built artifact and workspace through the existing battery of tests (the gauntlet), or generate only without verification?” Skip the question only when the active user request explicitly chooses. Do not interpret silence as consent; wait for a choice before dispatch. Catalogue-only requests do not need this question.

• Yes — gauntlet: keep the existing verification pipeline below, including local static checks, critics, and applicable directional browser measurement. Verified completion is OK.
• No — none: perform a genuine generation-only one-shot. Do not verify the artifact or workspace: no browser/render/screenshots, smoke tests, lints/typechecks/tests, critics, directional probe or adapter, fallback-path checks, benchmarks, static artifact scans, or validation/repair loops. Build/export steps essential to produce deliverables are allowed; their success does not prove behavior. Do not disguise checks as integration, recovery, safety, or completion work. Reading source as needed to continue generation is allowed, not inspecting the output to judge it. Complete generation, safely clean scratch, then mark both records UNVERIFIED, never green verified OK. Keep artifact.staticDeploymentVerified: false, verification: [], and qualityGauntlet: null.

Pass --verification gauntlet|none explicitly to preparation. Run schema 3.5 and immutable coordinator receipt 2.5 record verificationMode; dispatch that same value and propagate it to all descendants. Worker reports retain schema 2.1 with the matching mode. Never change the selection during continuation or recovery, and never let a worker-only edit opt out. Historical helpers without the flag retain their legacy gauntlet default and 3.4/2.4 schemas; missing mode on a historical receipt is not an opt-out. Ordinary provenance, scoped authority, single writer, sealed prompt identity reads, and safe exact-path cleanup remain mandatory in both modes. Package developer regression tests and repository validation remain enabled.

Keep Remote Publication Off by Default