Execution · Lesson 02 of 03
Native, container, lifecycle, and CI execution
Ota can run tasks natively, inside containers, through CI projection, or under a lifecycle manager. Each mode has different proof guarantees.
Learning objectives
- Describe when to use container execution over native
- Explain what CI projection generates and why
- Compare the evidence boundary and enforced controls of each selected execution mode
Prerequisites
Execution mode is part of repository truth. Native, container, remote, lifecycle, and CI surfaces have different ownership and evidence boundaries; Ota must not silently degrade an explicit mode request into another mode.
Select a declared mode
Native execution uses the host environment and shared worktree. Container execution uses the declared container context and may provide a distinct filesystem, platform, and network boundary. Remote execution depends on a supported adapter. Lifecycle controls apply only where the selected task and provider can honor them.
ota run --native --dry-run --json testota run --container --dry-run --json testCI is a projection, not a second contract
The provider-neutral CI projection carries Ota-owned governance truth into provider adapters. GitHub still owns triggers, permissions, runners, secrets, environments, deployment, and non-Ota jobs. Generated CI must not become a competing source of task truth.
Canonical terminology
Evidence boundary for this lesson
Establishes
- The worked examples establish the lesson's canonical Ota distinctions for its stated scope.
Does not establish
- Reading the lesson does not validate a repository, execute its tasks, or establish organizational acceptance.
Knowledge check
May an explicit container request silently fall back to native execution?
No. Execution mode is contract and admission truth; unsupported explicit requests must refuse rather than degrade to a different boundary.