delivery-preflight-gate

Delivery Preflight Gate

Run the smallest useful baseline check before committing the agent to a long implementation loop or before letting a risky branch leave the local workspace.

Use When

• the task is expected to take multiple implementation steps or phases;
• the repo already has build, test, typecheck, lint, or app-run expectations;
• a broken baseline would waste retries or mislead later verification;
• the user is about to ask for an autonomous or low-supervision run;
• a branch should pass a disposable push gate before opening or updating a PR.

For security-sensitive work, run authorized-security-router first when authorization, target boundary, or allowed action level is not already explicit.

If repeated preflight failures reveal a reusable lesson, use agent-learning-layer-triage to decide whether the fix belongs in a memory/context note, durable repo doc, checklist, SKILL.md, script/tool, eval, or golden fixture.

Core Rules

• Deduplicate checks. Do not run the same command under different names.
• Prefer the narrowest commands that still represent the real baseline.
• Verify before planning a large execution loop, not after failure number three.
• Distinguish baseline already broken from task introduced a regression.
• If the baseline is red, stop and present options instead of silently proceeding.
• For push-gate workflows, isolate review and repair work from the main working tree when the tooling supports it.

Workflow

1. Identify the mandatory verification surface for this repo.
2. Select the minimum command set that represents that surface.
3. Run the commands once before starting the long task or before publishing the branch.
4. Classify the result:
   • PREFLIGHT_GREEN: baseline acceptable for execution.
   • PREFLIGHT_RED: baseline broken, flaky, or unverifiable.
   • PUSH_GATE_GREEN: branch is clean enough to push or open/update a PR.
   • PUSH_GATE_RED: branch needs a fix, explicit override, or smaller PR slice before publishing.
5. If red, report:
   • which commands failed;
   • whether the failure appears pre-existing or task-related;
   • whether it blocks the planned work or is exactly what phase 1 must fix.
6. Require an explicit proceed-or-fix decision before treating the task as safe for autonomous execution or remote publication.