feat(workflows): propagate step output model to context for evaluator-driven routing

[tbitcs]

Summary

Enables automatic model routing in the workflow engine. When a step's output includes a model field, the engine propagates it to context.default_model so subsequent steps automatically use the routed model.

This is the follow-up to #4390 (evaluator contract extension). Together they enable the full portfolio approach: evaluators recommend a model tier, and the engine applies it automatically.

Changes

• engine.py: 7 lines — after each step, check result.output.get("model") and propagate string values to context.default_model
• test_workflows.py: 5 new tests covering propagation, no-op when absent, non-string rejection, subsequent step inheritance, and explicit override priority

Design

• Only strings propagate. Non-string values (None, lists, dicts) are silently ignored — they're already rejected by step validation.
• Explicit overrides win. A step with model: "sonnet-4" always uses that model, regardless of what was routed.
• Backward compatible. If no step outputs a model, behavior is unchanged — context.default_model stays at its initial value.

Testing

• Tested locally with uv run specify --help
• Ran existing tests with uv sync && uv run pytest

$ uv run pytest tests/test_workflows.py::TestModelRoutingPropagation -v
5 passed in 5.73s

AI Disclosure

• I did not use AI assistance for this contribution
• I did use AI assistance (describe below)

Generated by GitHub Copilot (model: deepseek-v4-pro, autonomous).

Refs: #4290
Depends on: #4390

[mnriem]

Thanks for putting this together and for exploring evaluator-driven model selection. I agree that workflows should be able to use an evaluator's recommendation, but I don't think the engine should apply that recommendation automatically.

Step outputs are already recorded in the workflow context and can be referenced by later steps. A workflow author can therefore make the routing decision explicit:

- id: evaluate
  type: command
  command: speckit.evaluator.route

- id: implement
  type: command
  command: speckit.implement
  model: "{{ steps.evaluate.output.model_routing.recommended_tier }}"

Keeping this connection in the workflow definition has a few benefits:

• The dataflow is visible and intentional.
• Producing a field named model does not unexpectedly change subsequent steps.
• Workflow authors can validate, transform, or ignore the recommendation.
• Each downstream step can independently decide whether to use the output.
• The engine remains neutral about the meaning of extension-defined outputs.

In particular, output.model may describe the model that executed a step rather than a recommendation for future steps. Treating it as both metadata and a command to mutate context.default_model would introduce implicit behavior that may be difficult to understand from the workflow YAML.

For those reasons, I'd prefer that outputs remain data and that applying them to later inputs remain a conscious decision by the workflow author. The existing expression mechanism already supports that, so I don't think this change is needed in the core workflow engine.

Posted on behalf of @mnriem by GitHub Copilot (model: GPT-5.6 Sol).