tt-workflow-run

Tasktracker-native autonomous build-loop orchestrator. Drives a first-class workflow_run end-to-end — create the run (Gate 1 lifecycle completeness + Gate 2 zero-defects-in), then loop while getNextReadyTask(projectId) returns a slice — setActiveTask → record a pre-slice scanArchitectureDrift baseline → delegate the slice to /tt-implement-phase (which does the code work, registers the architecture delta in-slice, and auto-logs defects/learnings/frictions) → re-scan drift (Gate 3 architecture-followed) + re-read getDefectStats (Gate 2 delta) → read getTimeSummary for measured time + classify the slice's layer → workflow_recordIteration (appends an immutable by-layer measured-only projection version) → pauseActiveTask before any human gate — until the backlog drains, then workflow_completeRun. Loose coupling (brainstorm Fork B): the run is pure tasktracker data driven by a thin skill over EXISTING MCP tools + /tt-implement-phase; there is NO backend-callable Workflow API and /loop is only an optional outer cadence. The skill logs the RUN'S OWN insights too — a "no data" friction when heartbeating was off for a slice (principle #11), a learning on notable patterns, a defect for any new error above baseline. Use whenever the user wants to "run the workflow", "start an autonomous build loop", "drive the backlog to done", "dogfood the run", or "/tt-workflow-run" AND the work is tracked in tasktracker with a passable lifecycle. Triggers on "tt workflow run", "/tt-workflow-run", "start a workflow run", "run the build loop", "autonomous loop (tasktracker)", "drive the next-ready backlog". Prefer this over /tt-implement-plan when you want measured-time projection + per-slice drift/defect gates + a versioned remaining-effort series on top of phase execution; /tt-implement-plan just runs phases in order with no run entity, no projection, no per-slice gate ledger.