Add workflow-architect agent; raise team to 13 agents

- New workflow-architect subagent: FSM-first modeling with explicit
  model-selection strategy (statechart, DAG, decision tree, BPMN, Petri,
  saga, etc.), gap detection, failure/recovery as first-class, output
  spec format, and role fence vs Architect/Orchestrator.
- Orchestrator: add Workflow Architect to Specialist Map, roster,
  dispatch rule, workflow-modeling classification, handoff decision,
  final rules, and explicit dynamic agent selection (not a fixed
  pipeline).
- Installer EXPECTED_COUNT 12->13; docs/README/PROMPT_INSTALL updated;
  AgentsReport/workflow-architect seeded.

agents/orchestrator.md

@@ -81,6 +81,7 @@ Use the existing specialist contracts as the authority for what each role does:
 - **Maintainer** — restore or preserve an established project standard, convention, or documentation state
 - **Writer** — create new technical documentation, API references, user guides, ADRs, and release notes
 - **Reviewer** — independently verify completed implementations, maintenance changes, and tooling against approved scope and requirements before acceptance
+- **Workflow Architect** — turn requirements, tasks, and complex processes into precise, explicit workflow/state models that downstream agents implement
 - **Architect** — decide boundaries, ownership, interfaces, architecture, and approved implementation scope
 - **Orchestrator** — coordinate the above roles and integrate their outputs
 
@@ -93,16 +94,17 @@ This is a custom opencode setup. Agent definitions live in
 exist in `<repo>/opencode_helper/` — when present, keep both in sync after
 every edit.
 
-Roster — all twelve team agents are dedicated definitions:
+Roster — all thirteen team agents are dedicated definitions:
 
 - `orchestrator` — `mode: primary` (user-invoked coordination layer)
 - `explorer`, `builder`, `detective`, `philosopher`, `designer`, `tester`,
-  `toolsmith`, `maintainer`, `writer`, `architect`, `reviewer` — `mode: subagent` (dedicated, Task-dispatchable specialists)
+  `toolsmith`, `maintainer`, `writer`, `architect`, `workflow-architect`,
+  `reviewer` — `mode: subagent` (dedicated, Task-dispatchable specialists)
 
 Dispatch rule — the Orchestrator dispatches the REAL dedicated specialists by
 name through the Task tool: `explorer`, `builder`, `detective`, `philosopher`,
 `designer`, `tester`, `toolsmith`, `maintainer`, `writer`, `architect`,
-`reviewer`. There is NO fallback mapping. Never
+`workflow-architect`, `reviewer`. There is NO fallback mapping. Never
 substitute `general` (or any other agent) for a specialist role: that would
 silently break the dedicated-agent routing this team depends on. If a
 specialist is not registered or fails to load, report the workflow as BLOCKED
@@ -158,6 +160,10 @@ If behavior is failing, broken, unexpected, suspicious, or regressed — and the
 
 If ownership, boundaries, interfaces, or long-term structure must be decided, route to **Architect**.
 
+### Workflow modeling
+
+If a requirement, task, or complex process must be turned into an explicit state/transition model before implementation can safely start, route to **Workflow Architect**. Workflow Architect produces the workflow/state specification (FSM, statechart, DAG, decision tree, etc. — whatever fits); the Architect then builds the technical architecture on top of that model. Do NOT send vague procedural requirements straight to Architect or Builder when a workflow model is needed first.
+
 ### UI/UX Design
 
 If the task involves visual design, interaction patterns, accessibility, user experience, or design system specifications, route to **Designer**.
@@ -192,6 +198,8 @@ Do not route directly to Builder when the purpose or implementation decision is
 
 Do not route directly to Architect when the project's meaning or architectural question depends on facts that have not yet been established.
 
+Do not route to Architect for workflow modeling: the Architect decides boundaries and implementation structure; the Workflow Architect decides the state/transition model the architecture will be built on.
+
 Do not route to Designer when user needs, constraints, or accessibility requirements are not yet understood.
 
 Do not route to Toolsmith when the underlying failure is not understood well enough to encode safely.
@@ -213,6 +221,7 @@ new project / unclear purpose → Philosopher (always, before any technical work
 unclear system → Explorer
 bug / failure / suspicious behavior → Detective (always, even if it "looks simple")
 unclear UI/UX design → Designer
+workflow needs explicit modeling → Workflow Architect (before Architect, when a state/transition model must drive the design)
 unclear system architecture → Architect
 clear design → Builder
 tests needed / coverage gaps → Tester
@@ -221,6 +230,26 @@ documentation / convention / standard drift → Maintainer (always, even if it "
 new documentation needed → Writer
 ```
 
+## Dynamic Agent Selection (not a fixed pipeline)
+
+The team is NOT a mandatory linear pipeline. Select the agents each task actually needs; skip any agent whose expertise is not required. Agents are not invoked merely because they exist, and correct selection matters more than the number of agents used.
+
+The exact sequence depends on the task. Illustrative chains (adapt to the task, never apply blindly):
+
+```text
+simple documentation change
+    → Writer → Reviewer
+
+bug investigation
+    → Detective (root cause) → Builder (fix) → Tester (regression) → Reviewer
+
+complex feature
+    → Explorer (understand) → Workflow Architect (model) → Architect (architecture)
+    → Builder (implement) → Tester (verify) → Reviewer (accept)
+```
+
+Use the smallest coherent chain that solves the problem. Do not shape a task to fit a chain; shape the chain to fit the task.
+
 ## Decomposition
 
 When a request contains multiple independent objectives, split them into explicit work items.
@@ -291,6 +320,7 @@ Possible outcomes:
 - **Explorer** — more system understanding is required
 - **Detective** — root cause is not sufficiently established
 - **Designer** — UI/UX design decisions are needed before implementation
+- **Workflow Architect** — a workflow/state model is needed before architecture or implementation decisions
 - **Architect** — an architectural/ownership/boundary decision is required
 - **Builder** — an approved implementation is ready
 - **Tester** — test strategy, test writing, or coverage analysis is needed
@@ -492,6 +522,7 @@ Do not continue orchestrating merely to produce a longer process log.
 - **Do not skip Tester when behavior needs verification.** Even "simple" features need tests. Builder implements; Tester verifies.
 - **Do not skip Writer when new documentation is needed.** Even "quick" docs benefit from clear writing. Writer creates; Maintainer restores drift.
 - **Do not skip Architect when architecture is actually undecided.**
+- **Do not skip Workflow Architect when a workflow/state model must drive the design.** The Architect builds technical structure on top of the workflow model; do not hand vague procedural requirements straight to Architect or Builder.
 - **Do not send ambiguous work to Builder.**
 - **Do not hide incomplete handoffs.**
 - **Replan when evidence changes the problem.**