Complete command pipeline extraction (#170)

docs/developers-guide.md

@@ -622,14 +622,13 @@ did not match a workspace crate. `plan_publication()` builds that object by
 filtering non-publishable crates, applying `publish.exclude`, validating
 `publish.order` when present, or deriving a deterministic dependency order.
 
-`publish_manifest.py` owns staging-time manifest mutations. It contains
-workspace preparation types and helpers that copy the workspace tree and apply
-the `publish.strip_patches` strategy to the staged `Cargo.toml`. These
-operations run before any `cargo package` or `cargo publish` command, so the
-command runner works against a prepared snapshot rather than the source
-workspace. Workspace README adoption is not performed here; the `lading bump`
-command transposes the workspace README into each opted-in crate before
-publication.
+`publish_staging.py` owns workspace preparation types and helpers that copy the
+workspace tree. `publish_manifest.py` owns the `publish.strip_patches`
+staging-time manifest mutation. These operations run before any `cargo package`
+or `cargo publish` command, so the command runner works against a prepared
+snapshot rather than the source workspace. Workspace README adoption is not
+performed here; the `lading bump` command transposes the workspace README into
+each opted-in crate before publication.
 
 `publish_diagnostics.py` owns compiletest failure enrichment. When a cargo
 pre-flight test failure mentions compiletest-style `*.stderr` artefacts, the
@@ -860,6 +859,12 @@ responsibilities live in dedicated modules, imported by their original homes:
 - `lading.commands.bump_manifests` — per-manifest version and
   dependency-section rewriting plus the `_BumpContext` construction contract
   (imported by `bump`).
+- `lading.commands.bump_pipeline` — bump run-sequence orchestration across
+  manifests, documentation, readmes, and lockfiles (imported by `bump`).
+- `lading.commands.publish_pipeline` — per-crate package and publish execution,
+  result handling, and live/dry-run dispatch (imported by `publish`).
+- `lading.commands.publish_staging` — workspace copy preparation, cleanup, and
+  staged crate path resolution (imported by `publish`).
 - `lading.workspace.graph_build` — builders converting `cargo metadata`
   output into workspace models; the error-bound coercion helpers live in
   `lading.workspace._coercion` (both imported by `workspace`).
@@ -963,6 +968,11 @@ with a descriptive message.
 
 ### Per-crate publication helpers
 
+`lading.commands.publish_pipeline` owns `_package_crate`, `_publish_crate`,
+`_CrateAction`, `_for_each_publishable_crate`, `_PublicationPipelineState`, and
+`_dispatch_publication`. Tests patch these symbols at their canonical module;
+`publish.py` does not provide compatibility aliases.
+
 `_package_crate` and `_publish_crate` are the atomic units of the publication
 pipeline. Both accept the crate entry, publication state, and command runner
 explicitly, then execute exactly one `cargo` invocation against the crate's
@@ -1009,9 +1019,9 @@ accordingly. It is the sole branch that decides between the interleaved
 per-crate flow and the historical two-phase batch flow, keeping `run()` free of
 that decision.
 
-`lading.commands.publish_execution` loads the optional `cmd_mox` command-runner
-module with `importlib.import_module("cmd_mox.command_runner")`. Keeping the
-module in an `object | None` variable avoids relying on
+`lading.cli` loads the optional `cmd_mox` command-runner module with
+`importlib.import_module("cmd_mox.command_runner")`. Keeping the module in an
+`object | None` variable avoids relying on
 `from cmd_mox import ...  # type: ignore` when the package is absent, and it
 prevents conflicting type declarations when `cmd_mox` is present in the type
 checker environment.

docs/lading-design.md

@@ -186,16 +186,18 @@ available during packaging. Any parse errors or missing manifests surface as
 
 #### Publish data flow
 
-The publish data flow shows how the publish command orchestrates manifest
-preparation, crate planning, and command execution. The workflow splits
-configuration-driven patch stripping logic (all vs. per-crate) based on dry-run
-and live modes, and feeds the resulting plan to execution helpers.
+The publish data flow shows how the publish command coordinates crate planning,
+workspace staging, manifest preparation, and command execution. The coordinator
+delegates live and dry-run sequencing to `publish_pipeline`, which uses the
+`publish_execution` command adapter through an injected runner.
 
 ```mermaid
 graph TD
     A["CLI: lading publish"] --> B["Module: lading.commands.publish"]
     B --> C["Module: lading.commands.publish_plan (publish_plan.py)"]
     C --> C1["Build PublishPlan with publishable_names"]
+    B --> S["Module: lading.commands.publish_staging (publish_staging.py)"]
+    S --> S1["Copy workspace and resolve staged crate paths"]
     B --> D["Module: lading.commands.publish_manifest (publish_manifest.py)"]
     D --> D1["_apply_strip_patch_strategy(staging_root, plan, strategy)"]
     D1 --> D2{"strip_patches configuration"}
@@ -206,11 +208,10 @@ graph TD
     G --> H
     H --> I["Updated staged manifest used for publish"]
 
-    B --> J["Module: lading.commands.publish_execution (publish_execution.py)"]
-    J --> K["_invoke: subprocess execution with error adaptation"]
-
-    B --> N["Module: lading.commands.publish_preflight (publish_preflight.py)"]
-    N --> O["Compose final publish plan and execute commands"]
+    B --> P["Module: lading.commands.publish_pipeline (publish_pipeline.py)"]
+    P --> P1["Dispatch live or dry-run package/publish pipeline"]
+    P --> J["Module: lading.commands.publish_execution (publish_execution.py)"]
+    J --> K["Run cargo command through the subprocess adapter"]
 ```
 
 ### 2.3. Workspace Discovery and Model
@@ -528,25 +529,28 @@ crate-by-crate publishing.
 sequenceDiagram
     participant Caller
     participant publish.py
-    participant publish_execution
+    participant publish_preflight
     participant publish_plan
-    participant publish_diagnostics
+    participant publish_staging
+    participant publish_pipeline
+    participant publish_execution
 
     Caller->>publish.py: publish(…, forbid_dirty=…)
-    publish.py->>publish.py: _build_preflight_environment(config.preflight)
-    alt aux_build configured
-        publish.py->>publish_execution: _run_aux_build_commands(...)
-        publish_execution-->>publish.py: (rc, stdout, stderr)
-    end
-    publish.py->>publish_execution: _invoke(cargo test --lib, ...)
-    publish_execution-->>publish.py: (rc, stdout, stderr)
+    publish.py->>publish_preflight: _run_preflight_checks(...)
+    publish_preflight->>publish_execution: _invoke(cargo check/test, ...)
+    publish_execution-->>publish_preflight: (rc, stdout, stderr)
     alt rc != 0
-        publish.py->>publish_diagnostics: _append_compiletest_diagnostics(...)
-        publish_diagnostics-->>publish.py: augmented_message
-        publish.py-->>Caller: PublishPreflightError(augmented_message)
+        publish_preflight-->>publish.py: PublishPreflightError
+        publish.py-->>Caller: PublishPreflightError
     else rc == 0
         publish.py->>publish_plan: plan_publication(workspace, configuration, workspace_root)
         publish_plan-->>publish.py: PublishPlan
+        publish.py->>publish_staging: prepare_workspace(plan)
+        publish_staging-->>publish.py: PublishPreparation
+        publish.py->>publish_pipeline: _dispatch_publication(plan, preparation)
+        publish_pipeline->>publish_execution: _invoke(cargo package/publish, ...)
+        publish_execution-->>publish_pipeline: (rc, stdout, stderr)
+        publish_pipeline-->>publish.py: Success
         publish.py-->>Caller: Success
     end
 ```