Complete runner lifecycle refactor

docs/internal/adapters.md

@@ -35,8 +35,9 @@ Adapters do not own:
 
 ## Default Wiring
 
-`internal/app/runner.go` initializes default adapters when not injected and
-only when the selected execution plan needs them:
+The application composes default adapters per invocation when they were not
+injected through the stage environment, and only when the selected execution
+plan needs them:
 
 - WhisperX HTTP client for `transcribe`.
 - Seriatim subprocess runner for `merge`, `normalize`, `trim`, or `render`.
@@ -49,8 +50,10 @@ only when the selected execution plan needs them:
 Remote publish locks are loaded only for a selected, enabled publish that
 uploads a run. Shared session lifecycle setup still applies to every selected
 range, but an unselected integration is neither initialized nor validated by
-runner composition. Each selected stage retains its own fail-fast configuration
-and input validation.
+application-owned composition. Constructor, clock, randomness, remote-lock,
+and post-publish deletion boundaries are scoped to the invocation; stages still
+receive their collaborators through the stage environment. Each selected stage
+retains its own fail-fast configuration and input validation.
 
 `session plan` is outside production adapter composition. It performs
 resume validation and models selected transitions against cloned manifest
@@ -88,7 +91,8 @@ configured filesystem secrets before adapter initialization.
 
 ## Implementation And Tests
 
-- Composition: `internal/app/runner.go`, `internal/app/object_store.go`
+- Composition: `internal/app/runner_composition.go`,
+  `internal/app/runner_dependencies.go`, `internal/app/object_store.go`
 - Shared subprocess mechanics: `internal/adapters/subprocess`
 - Focused adapters: `internal/adapters/{whisperx,seriatim,audita,scriptorium,notarius,storage,notify}`
 - `internal/adapters/whisperx/http_test.go`

docs/internal/manifest.md

@@ -155,11 +155,21 @@ durability guarantee. Callers reload after a returned save error before retrying
 
 ## Execution Semantics
 
-The application runner marks an executing stage running and then succeeded or
-failed in the session manifest, persisting each transition. On success it records
-outputs, logs, generated configuration references, metadata, and—when the
-stage implements the optional contract—a versioned semantic-configuration
-fingerprint. Artifact
+Planning and execution share one pure pre-execution decision over the recorded
+stage status, force selection, and normalized resume-validation result. That
+decision identifies run versus reuse and any required stale and dependent
+invalidation transition. Planning applies it only to a cloned manifest.
+Execution remains the sole owner of observed stage results and persistence.
+
+For each selected stage, the application runner computes semantic evidence,
+performs any eligible resume validation, applies the pre-execution decision,
+and persists required invalidation before either reusing the existing success
+or beginning an attempt. The same one-stage execution owner marks the attempt
+running before invoking the stage and then records and persists its failed,
+skipped, or successful terminal state before a later stage may start. On
+success it records outputs, logs, generated configuration references, metadata,
+and—when the stage implements the optional contract—a versioned
+semantic-configuration fingerprint. Artifact
 records may include optional contract and external provenance objects; old
 manifests remain compatible when those fields are absent. A successful forced
 rerun marks only succeeded transitive dependent session-stage records stale.
@@ -237,9 +247,9 @@ invalidates only stages whose semantic configuration changed. When a private
 external-tool model, module, prompt, or profile changes behind an unchanged
 configured identifier, use `--force` for the affected work.
 
-`session plan` computes the same current fingerprint and applies the same
-comparison and invalidation rules to a cloned manifest. It predicts the runner
-decision without persisting session state. The shared helper
+`session plan` computes the same current fingerprint and applies the shared
+decision and invalidation rules to a cloned manifest. It predicts the runner
+decision without persisting session state. The semantic fingerprint owner
 hashes deterministic JSON from stage-owned typed structs; stage providers must
 exclude secrets, complete effective-configuration dumps, and operational
 values that cannot affect canonical results. Concrete coverage is owned by the

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.

docs/roadmap/implementation.md

@@ -2,11 +2,13 @@
 
 ## Status And Purpose
 
+**Status: Completed**
+
 This is the decision-complete implementation plan for Workstream 5, **Runner
 lifecycle and pre-execution decisions**, in
 [`refactoring.md`](refactoring.md). Workstreams 1 through 4 are complete.
-Workstream 5 is the next pending workstream and is the only feature scope of
-this plan.
+Workstream 5 is complete; Workstream 6 is the next pending workstream. This
+plan's implementation scope remained limited to Workstream 5.
 
 The implementation must reduce the change blast and cognitive load of
 `internal/app.executePlan` without changing the pipeline's observable behavior.
@@ -408,7 +410,7 @@ are easier to read than the former monolith.
 
 ## Stage 6 — Remove Global Runner Seams And Close Workstream 5
 
-**Status: Pending**
+**Status: Completed**
 
 ### Goal
 

docs/roadmap/refactoring.md

@@ -222,7 +222,7 @@ manifest must remain synchronized with the progress ledger.
 
 ### Workstream 5 — Runner lifecycle and pre-execution decisions
 
-**Status:** Pending
+**Status:** Complete
 
 **Audit sources:** H04, H07, H14, H15, H17, H34, and H35.