Skip to main content

Glossary

These terms are used consistently across this documentation.

  • run — A single execution of a recipe on an executor, triggered by a webhook, agent request, or ship-on-green deploy.

  • stage — A named step within a recipe, implemented as a shell command with optional env, timeout, and secrets.

  • recipe — Pipeline as code in .slipstream.json: sequential stages or one-level parallel groups of stages.

  • check — The GitHub required check named RunsGreen (renamed from K2K-Native CI 2026-07-10, then from RunsGreen 2026-08-06) that Agentic Pipeline posts when a run completes.

  • executor — A pre-warmed machine that runs stages; your repo, dependencies, and Docker layers are already present when a run is dispatched.

  • control plane — The orchestrator that receives webhooks, dispatches runs to executors, stores configuration, and posts check verdicts to GitHub.

  • sandbox — An isolated run of an inline recipe that posts no check to your repo.

  • promote — The action of opening a PR with a proven recipe change via slipstream_recipe_promote.

  • ship-on-green — Automatic deploy run after a green check on main when the ship key is on.

  • deploy recipe — Pipeline as code for CD in .slipstream-deploy.json (recipe v2, kind: "deploy"), fetched at the green merge commit that triggered the deploy.

  • prewarm — Waking an executor for a repo before a push via slipstream_prewarm, so the run starts on a hot machine with warm caches. Passing the head sha also requests a speculative dependency install-warm — best-effort, and skipped when the commit is not on GitHub yet (prepare_state). The install-warm never completed on a pre-push sha, so nothing that used to work was removed; warming a cold machine's clone without a pushed sha is a known follow-up.

  • follow — Watching a push's whole chain — CI verdict and merge through deploy/live or intentional CI-only completion — in one slipstream_follow call that streams milestones and returns a per-hop timeline.

  • readiness — The report-only, eight-check onboarding health score (red/amber/green) returned by slipstream_onboard; it informs, never gates.

  • baseline — The immutable, frozen sample of a repo's previous GitHub Actions timings captured at first onboarding, used for honest speed comparisons.

  • preset — A maintained, versioned recipe a repo can extends instead of writing stages (for example std/python-standard@1).

  • runtime — An interpreter (python, node) a recipe declares under runtimes; provisioned into a warm cache before the first stage runs.

  • coverage — The lines-covered percentage a run carries when a stage declares coverage_summary; telemetry only, never a gate.

  • hard ceiling — The kind-specific whole-run wall: 6 minutes for ci, sandbox, and artifact runs; 8 minutes for production deploy runs. Runs that hit their bound are killed, their check says so, and the ceiling never rises to fit a pipeline — the pipeline gets faster.

  • speed budget — The soft per-repo CI time budget (120 seconds by default) below the hard ceiling. A green run over budget still passes; its check summary carries a "stabilize and accelerate" note, and sustained breaches queue an automatic advisor proposal.

  • run kind — Which lifecycle a run belongs to: ci (push check), deploy (ship-on-green production run), artifact (image build), sandbox (isolated recipe trial), scheduled (repo-declared cron). Ceilings, reruns, and cancellation rules are per kind.

  • failure_class / kill_reason — slipstream_diagnose and slipstream_follow classify a red run: failure_class is code (the change), infra (platform or resource fault, retried by the platform), recipe (the pipeline definition — a stage killed by its own declared timeout_s, a command the workspace does not have, or a recipe Agentic Pipeline could not use at all; fix the recipe, not your code, because neither a rerun nor a code change can help), or unclassified; kill_reason is wall_cap (the kind's hard ceiling) or stage_timeout (a stage's own timeout) when a deadline killed the run, else null — a deadline kill says the pipeline is too slow, never that the commit is wrong.

  • error_class: deadline — A run the platform itself force-concluded on its own lifecycle lease deadline. Read it as a platform fault, not a consumer failure. Agentic Pipeline fires at most ONE automatic retry, and only when its retry gate allows: when it does, slipstream_diagnose's retry chain names the successor to follow instead of starting your own; when the retry was refused, the run is force-concluded with no successor and the same error_class, so check the chain before assuming one exists.

  • dispatch_frozen — Fleet-wide dispatch hold reported by slipstream_status while the executor fleet is being re-imaged (a fenced release). Queued runs wait; nothing is lost. The payload itself carries until — the instant the hold lapses on its own even if nothing releases it — plus roll_id and a one-line detail you can repeat verbatim; read until rather than assuming a duration. It is not a scheduling stall and needs no rerun.

  • proof reuse — A stage skipped because an identical prior green proof for the same inputs was reused (skip_reason: proof-reused). Distinct from an if_changed skip: the work was proven, not declared inert. Off by default (slipstream.proof_reuse, fleet default 0) — the one capability Agentic Pipeline does not turn on for you, because its failure mode is a silently wrong green.

  • synthetic run — A heartbeat CI run Agentic Pipeline fires against its own canary repo to prove executor warmth. Excluded from FLEET-WIDE aggregates so a ~1-second heartbeat cannot make the platform look faster than it is; slipstream_trends reports excluded_synthetic alongside the figures it dropped them from. Per-repo series are keyed by repo and keep their own rows, so a repo's numbers are unaffected.

  • auto-scope — Agentic Pipeline's own decision that a push's whole diff cannot affect any stage; see Auto-scope. Repos graduate from annotate to enforce automatically once the evidence bar is met.