cursus.steps.interfaces.io_view

Per-step connection / I-O view (FZ 31e1d3d / 31e1d3b1 follow-up).

The Strategy+Facade collapse means a step is no longer a readable builder class — the container source/destination paths, the runtime property-path references, and the (handler-derived) nested training-channel expansion all live in the step’s .step.yaml + its bound handler instead. This module reads BOTH and renders one structured “what wires into / out of this step” view that the cursus steps io CLI and the steps.io MCP tool share.

It is the path/wiring analogue of catalog.step_spec (which gives the ports but NOT the container paths or the channel fan-out): for each dependency it reports container_path (where the input lands in the container) + the SageMaker training channel(s) it maps to; for each output it reports container_path (source) + property_path (the runtime properties.* reference a downstream step resolves against). Pure introspection — no config, no SageMaker session.

describe_step_io(step_name, job_type=None)

Return the connection/I-O view for one step, resolved from its .step.yaml (+ job_type).

Raises whatever load_interface raises for an unknown step (FileNotFoundError) — callers convert it to their own not-found envelope.

describe_step_patterns(step_name, job_type=None)

Return the per-axis PATTERN view for one step — the ‘plugins’ the TemplateStepBuilder uses (FZ 31e1d3j).

Everything is DERIVED from the data that actually drives the build — the registry binding (sagemaker_step_type + step_assembly → handler/verb) and the per-step .step.yaml contract DATA the handlers read (env_vars, job_arguments, circular_ref_check, skip_inputs, input_source_overrides, sink, include_job_type_in_path, source_dir) — plus the output S3 prefix DERIVED from the step name (canonical_to_snake(step_type)). So this view CANNOT drift from behavior: there is no separate patterns: field — the pattern is the consequence of the data.

Where a builder still hand-overrides a method (a genuine per-step deviation), that axis is marked custom_override so the user sees exactly where the step departs from the declarative patterns.