feat: add first-class workflow profiles

[RogerNavelsaker]

Summary

• add first-class workflow aliases for delivery and co-creation across coordinator startup, ov workflow start, ov sling, and ov spec write
• default co-creation task artifacts to openspec/changes/<task-id>/tasks.md while keeping delivery on .overstory/specs/
• fall back to emitted workflow prompt files when canopy is unavailable so workflow-mode prompts still apply

Closes #106.

Testing

• bun test src/workflow.test.ts src/commands/spec.test.ts src/commands/workflow.test.ts src/commands/coordinator.test.ts src/commands/completions.test.ts
• bun run typecheck
• bun run lint

[jayminwest]

Review

Overall direction is strong — workflow profiles are a natural extension of the canopy profile system. A few issues to address before merge:

Must fix

1. Missing --workflow validation on ov sling and ov coordinator start — ov workflow start correctly validates via normalizeWorkflowName and throws ValidationError for unknown values. But ov sling --workflow bogus and ov coordinator start --workflow bogus silently pass through — resolveProfileName("bogus") returns "bogus" (the passthrough branch), which then gets used as a canopy profile name that probably doesn't exist. Either validate on all three entry points, or at minimum emit a warning.

2. repoRootFromCommandDir is fragile for installed packages (src/workflow.ts:87-89) — join(dirname(commandDir), "..") assumes the file layout is <root>/src/commands/. Other code in the repo uses join(import.meta.dir, "..", "..") directly (see update.ts:89, init.ts:753). Consider inlining the two-level .. join at the call site as other commands do, or renaming to something clearer like resolveOverstoryPackageRoot with a doc comment explaining the layout assumption.

3. specWriteCommand now loads full config (src/commands/spec.ts) — Changed from resolveProjectRoot (lightweight) to loadConfig (heavyweight, requires valid config.yaml). This could surface errors in edge cases like partially initialized .overstory/. Consider whether resolveProjectRoot + a targeted config read for defaultProfile would be less risky.

Non-blocking suggestions

• discover.ts change adding workflow: undefined is redundant since the property is optional — consider removing.
• Consider adding ov-delivery.md to the agent manifest if profiles should be discoverable via ov agents.
• Shell completions for ov workflow start include --monitor but the help text doesn't describe what monitor does in this context.

[RogerNavelsaker]

I finished a Trellis-native replacement branch for this work and verified it locally.

Replacement branch:

• RogerNavelsaker/overstory:rn/workflow-profiles-trellis-main
• head: 683bce3

What it contains:

• the workflow-profile stack from this PR, rebased/cherry-picked onto current main
• Trellis instead of OpenSpec for co-creation spec output
• richer ov spec write Trellis bootstrap flags: --title, --seed, repeated --reference, --constraint, --acceptance
• safer overwrite semantics: existing Trellis specs are refused by default; --force is the explicit override
• keeps plan creation in Trellis

Local verification on the replacement branch passed:

• bun test src/workflow.test.ts src/commands/spec.test.ts src/commands/workflow.test.ts src/commands/coordinator.test.ts src/commands/completions.test.ts
• bun x tsc --noEmit
• bunx @biomejs/biome check ...

Downstream dogfooding result is that the Trellis boundary is now stable:

• ov spec write --workflow co-creation is a good bootstrap path
• trellis spec update is the right ongoing-edit path
• trellis plan create remains the right plan-authoring path

I have not opened the replacement PR yet because there are two reasonable paths and I wanted to leave the choice with you:

1. keep this PR as the workflow-profiles base and stack the Trellis follow-up on top
2. replace this PR with a new Trellis-native PR to main

I think option 2 is cleaner now that the downstream shape is proven, but either path works.

Separately: Trellis itself is now in a presentable standalone state and is already being dogfooded downstream with Overstory. If you want it under the jayminwest / os-eco umbrella rather than living in my fork, I’m happy to transfer repository ownership once you’ve had a chance to review the direction.

[RogerNavelsaker]

Opened the replacement PR here: #133

Link: #133

That branch is the Trellis-native path rebased onto current main, so if you prefer the replacement route over stacking on top of this PR, that is ready for review.