[FEATURE] harmony with spec driven dev.

[kundeng]

Problem

Zeroshot already supports dynamic multi-agent orchestration, but spec-driven workflows (BMAD / Spec-Kit / Kiro-style) could possibly be looped in as custom cluster logic rather than first-class workflow primitives.

Two concrete pain points:

1. load_config resolution is constrained for dynamic orchestration.
   In operation chains, load_config resolves from internal template locations, which makes reusable external workflow packs harder to adopt cleanly across repos/teams.

2. Spec phases and promotion gates are not native concepts.
   Strict flows like requirements -> design -> tasks -> implementation -> validation can be built manually, but there is no built-in phase/gate model to enforce them consistently.

Proposed Solution

Add first-class spec workflow support while preserving backward compatibility.

1. Flexible config/template resolution

• Extend load_config and related resolution to support:
  • explicit absolute/relative file paths
  • configured workflow roots (e.g., repo-local ./workflows, shared pack dirs)
  • existing built-in templates as fallback
• Keep existing template-name behavior unchanged.

2. Native phase/gate model (optional)

• Introduce optional workflow schema with:
  • phases
  • allowed transitions
  • gate checks per phase
• Gate checks should support:
  • required artifacts
  • validator outcomes
  • approval signals
• Block transitions when gate conditions fail (with clear error reasons).

3. Operator visibility (phase/gate focused)

• Surface phase + gate state in existing status surfaces (CLI/TUI/API where applicable):
  • current phase
  • failed/pending gates
  • last transition reason
  • override/audit metadata (if force-transition is used)

4. Built-in starter profiles

• Provide optional starter workflow profiles inspired by common spec-driven patterns (BMAD/Spec-Kit/Kiro-style), implemented as examples/templates on top of the same schema.

Alternatives Considered

1. Keep implementing spec workflows entirely via custom templates/scripts

• Works today, but leads to duplicated logic and inconsistent enforcement across teams.

2. Add only path flexibility

• Improves reuse, but does not address repeatable gate enforcement semantics.

3. Build a separate external plugin/tooling layer

• Avoids core changes, but splits orchestration logic and reduces discoverability/operability.

Additional Context

This request is not asking to remove current behavior. It asks for an optional, backward-compatible layer that makes strict spec workflows easier to standardize, audit, and operate across projects.