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
- Identify which execution mode provides the strongest isolation proof
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.