Skip to content

T-Z56F-orchestrate-routing-table

Status: closed/superseded · Impact: medium · Complexity: medium

Dispatch treats every task identically regardless of size or autonomy; DarkFactory proved that two small enums on the work item can drive an automatic model/timeout policy. Add a config-plane routing table keyed off the existing complexity / autonomy axes (D-3PDM-cross-project-data-model-adoption P8).

sdlc.yaml gains a routing table mapping complexity (and optionally autonomy) to model, effort level, and timeout budget; orchestrate / task-work dispatch reads it when launching implementations. Absent config means behavior unchanged. Axes stay in data, mapping stays in config (P-0008 harness-agnosticism).

  • AC-1: the sdlc.yaml schema accepts a routing table; invalid entries fail config validation.
  • AC-2: orchestrate / task-work dispatch applies the routed model, effort, and timeout when the table is present.
  • AC-3: with no routing table configured, behavior is unchanged.
  • AC-4: doctor/config output surfaces the resolved routing.
  • A separate difficulty axis on task — only if routing off complexity proves miscalibrated (D-3PDM-cross-project-data-model-adoption open question).
  • Per-run manual overrides beyond existing CLI flags.
  • none
  • D-3PDM-cross-project-data-model-adoption P8: DarkFactory’s capability → model map (haiku…opus) and effort × capability → timeout budgets were used corpus-wide and config-overridable.

← Back to Tasks