T-A7PL-sdlc-p2-workflows

State: closed/done · Impact: high · Complexity: medium

Goal

Today every lifecycle stage (implement, check, review, respond, close-out) is a hard-coded sequence of skill/CLI calls scattered across skills and ops. Phase 2’s orchestrator loops need one runner-agnostic place that says what steps compose each named stage, with sane built-in defaults and a project-level override/append/prepend seam — so sdlc orchestrate run (and, later, flowline) can execute a workflow without knowing which skill or verb backs it.

Today

Location	Role today
solutions/ontological/lib/config/load.ts	SdlcConfigSchema — no workflows: section
solutions/ontological/lib/config/verbs.ts	resolveVerb cascade + trust gating, reused by workflow run: steps
solutions/ontological/skills/orchestrate/SKILL.md	prose loop hard-coding stage order (task-work, pr-check, etc.)
solutions/ontological/lib/registry.ts	op descriptor pattern new ops (workflow list, workflow show) must follow

Proposed

• SdlcConfigSchema gains a workflows: section: a map of workflow name → ordered step list. Each step is a discriminated union: { skill, args? }, { run } (a verb name resolved via resolveVerb), { script } (a path), or { prompt } (literal text). Built-in defaults for implement, check, judge, pr-review, pr-respond, pr-update, close-out, define (two steps: task-ensure-ready then task-auto-define) live in code, not in a shipped sdlc.yaml.
• A project’s sdlc.yaml entry for a workflow name either replaces the whole step list, or supplies prepend:/append: step lists that wrap the (possibly still-default) resolved list. Replacement and prepend/append are mutually exclusive per workflow entry — validate against both being set.
• resolveWorkflow(name, projectRoot) returns the resolved ordered step list plus, per step, its source: 'default' | 'override' | 'prepend' | 'append'.
• sdlc workflow list prints every known workflow name (built-in ∪ project-defined). sdlc workflow show <name> prints the resolved step list with each step’s source, as both a new op in lib/registry.ts and a CLI command.
• The step grammar itself carries no runner logic (no host/engine coupling) so a future flowline runner can execute the same resolved list.

Approach

1. Add the Zod step-union schema and workflows: section to SdlcConfigSchema in lib/config/load.ts, with per-key .describe()s consistent with the rest of the file’s documented style.
2. Add lib/config/workflows.ts: built-in default step lists as a typed const map, plus resolveWorkflow(name, projectRoot, opts?) implementing the override/prepend/append merge and per-step source tagging. Validate the mutual-exclusion rule and surface a clear OpError on violation.
3. Add lib/services/workflow/ops/{list,show}.ts following the existing op descriptor pattern (see an existing simple op such as lib/services/pr/ops/classify.ts for shape), registered in lib/registry.ts, wired into the CLI (sdlc workflow list|show <name>).
4. Update solutions/ontological/skills/orchestrate/SKILL.md only insofar as this task’s step vocabulary needs naming consistency; the full skill rewrite to a thin --once wrapper is T-XRFD’s job, not this one.
5. Unit tests (also tracked by T-REME, but the resolver’s own tests belong with its implementation): default resolution, full override, prepend, append, and the mutual-exclusion validation error.

Areas

Area	Note
solutions/ontological/lib/config/load.ts	add workflows: section to SdlcConfigSchema
solutions/ontological/lib/config/workflows.ts	built-in defaults + resolveWorkflow
solutions/ontological/lib/services/workflow/ops/list.ts	workflow list op
solutions/ontological/lib/services/workflow/ops/show.ts	workflow show <name> op
solutions/ontological/lib/registry.ts	register the two new ops
solutions/ontological/lib/config/workflows.test.ts	resolver unit tests

Acceptance criteria

• AC-1: sdlc workflow list prints all eight built-in workflow names with no project config present.
• AC-2: sdlc workflow show implement on a project overriding implement prints the overridden steps with source: override on each.
• AC-3: a project supplying only append: for check prints the built-in steps first (source: default) followed by the appended step(s) (source: append), and likewise for prepend:.
• AC-4: supplying both a full replacement and prepend/append for the same workflow entry fails config validation with a clear message.
• AC-5: resolveVerb is reused (not reimplemented) for run: steps, so trust gating on an untrusted repo still applies to a workflow’s run: step.

Out of scope

• The claude/codex/cursor per-engine skill-to-first-message mapping (T-AD81 / Phase 6).
• Executing a workflow (that’s sdlc session launch, T-AD81, and the loop engine, T-XRFD) — this task only resolves the step list.
• Making workflows: meta-defined (category/consumers/…) — that’s Phase 5.

Dependencies

• none

Discovery context

Phase 2 of docs/planning/notes/N-S4AJ-sdlc-0-8-plan.md (“Workflows in sdlc.yaml”).

---

← Back to Tasks