downstream

name	downstream
description	Guide committed work to readiness and execute CI Sync, CI Async, or the full governed ProdOps delivery flow.

DOWNSTREAM

Downstream is the complete, governed execution mode. Commitment may be declared before every prerequisite exists; the orchestrator must guide the item toward readiness and stop at each missing gate. It must never bypass or invent a prerequisite.

Commands

Command	Scope
/downstream ci-sync <capability>	Readiness → Bootstrap → Hack → Sync → Finish
/downstream ci-async <capability>	Readiness and CI Sync evidence check → Ship → Validate → Promote
/downstream full <capability>	Readiness → CI Sync → CI Async

Until CI Async automation is complete, /downstream without a scope defaults to ci-sync and must report that choice explicitly.

Readiness gate

Before executing either cycle, evaluate the capability against all current Downstream prerequisites:

1. OBC committed in prodops/artifacts/obcs/.
2. BDD Feature committed in prodops/artifacts/bdd/.
3. Risks documented in prodops/artifacts/risks/risks.md.
4. Item committed in the Iteration Plan with status Entrou.
5. Reliability Plan produced by Assessment when there is money movement, an external integration, an SLO change, high/critical risk, or a persistence or security change.

Treat commitment as Downstream Declared. If any applicable prerequisite is missing, stop before execution, identify the owning journey or artifact, and state the next action. Mark Downstream Ready only after every applicable gate passes; Delivery Started begins only when Bootstrap starts for that Ready item.

When all prerequisites exist, generate prodops/exec/cards/<card-slug>/context.md from prodops/templates/delivery/context-capsule.md. The capsule is generated by Downstream readiness, not Bootstrap.

CI Sync

1. Bootstrap — prepare dependencies, local infrastructure and smoke gate only.
2. Hack — run start, tdd, and commit; start owns Git flow and branch creation.
3. Sync — synchronize the branch and align impacted ProdOps artifacts.
4. Finish — execute final quality gates and prepare the PR.

CI Async

1. Confirm successful CI Sync evidence exists.
2. Ship — build, publish and deploy according to the current release policy.
3. Validate — validate BDD, OBC, observability, SLOs and risks in the target environment.
4. Promote — apply promotion gates and append evidence to the Release Trail.

Guardrails

• Do not start a delivery phase while readiness is incomplete.
• Do not treat an Iteration Plan entry alone as readiness.
• Do not invent OBCs, BDD scenarios, risks, reliability targets or acceptance criteria.
• Do not make Bootstrap perform Git flow or product-context work.
• Do not ship work supported only by Upstream evidence.
• Do not skip quality gates without an explicit recorded decision and risk acceptance.
• Do not promote unresolved high-risk items without explicit acceptance.
• Do not create GitHub Issues or PRs without declaring artifact_type, artifact_id, operation, and journey. Follow the Work Item schema: prodops/framework/execution-mapping/work-item-schema.md.
• Use the canonical Work Item title pattern: [Artifact ID]: description. Set operation:<value> and artifact-type:<value> as labels.

References

→ Execution Mapping → Work Item Schema → Mapping Matrix