[FeathBow]

Why

Shared training without --staleness still used the lockstep driver, so it kept no journal and could not resume. Shared execution with explicit --staleness 0 already used the event runtime. Make that path the default and remove the duplicate driver. Refs #26.

What

• All training uses the event runtime. Shared runs default to staleness zero, retain a journal and process transcripts, and support resume and run-directory history admission.
• Shared execution keeps its existing requirements and named errors: both roles select shared mode, use the same executable, script and model cache, and share one session. Positive staleness is refused.
• Remove the lockstep driver and its unused helpers and tests. Keep the configuration types and worker helpers used by the runtime, and preserve admission and comparison of existing training logs.
• Update the lifecycle tests and guides for directory-based history. The publication test checks two generations against the fixture learner's output; shared tests cover default routing, ownership, resume and invalid declarations.

Validation

Before removing the driver, the MLX test model trained the same two-cycle workload with the lockstep driver and with the runtime at staleness zero, with a shifted reference so that the policy changed in each update. invar compare histories found the training log and the run directory equal, including the update schedule, and the published policy descriptions, adapters and learner checkpoints of both generations were byte-identical.

The core suite, formatting, lint, type fixtures and the Hugging Face, MLX and shared worker suites passed on 614ab12. Disabling any of the runtime's shared checks, or either shared-owner invariant, made a test fail. The final removal of an unused forwarding helper and test reset code, plus the documentation clarification, received static review; the suites were not rerun after that cleanup.