Complete runner lifecycle refactor

docs/internal/overview.md

@@ -22,6 +22,14 @@ session safety controls, and runs commands. Pipeline commands execute the
 canonical stage sequence through adapter interfaces, while manifests record
 progress and artifact services resolve durable inputs and outputs.
 
+The pipeline runner follows one explicit invocation lifecycle: inspect bounded
+prerequisites without mutation, prepare the workspace layout, acquire one
+session lock, load or create the authoritative session manifest, compose only
+the collaborators needed by the selected range, execute each selected stage in
+order, complete any required post-publish cleanup, and then return the summary.
+The lock remains held from manifest initialization through finalization, and a
+failed stage or required manifest save prevents later stages from starting.
+
 ## Components
 
 | Area | Implemented owners | Responsibility |
@@ -44,9 +52,11 @@ adapters. The normative rules for these relationships remain in
 [Architecture](../policy/architecture.md).
 
 Pipeline execution and `session plan` share the same inclusive contiguous-range
-model. Planning clones session state and applies selected-stage transitions and
-resume validation in memory; it does not create invocation state or initialize
-stage-execution adapters. Command configuration loading can still retrieve a
+model and the same pure pre-execution decision over recorded status, force, and
+normalized resume validation. Planning applies that decision and modeled
+selected-stage transitions to cloned session state; it does not persist, create
+invocation state, initialize stage-execution adapters, or claim to observe an
+execution result. Command configuration loading can still retrieve a
 missing session file through configured remote storage. It retains the initially
 composed pipeline and selected campaign while resolving either a local or
 downloaded remote session, so one invocation cannot mix pipeline revisions.