feat(onboarding): configure bounded M1-M6 mission workforce

[Aparnap2]

Context

Bounded onboarding workforce: missions M1–M6 plus the 3-analyst config, all config-driven against the frozen Onboarding aggregate and Control Plane authority boundary (ADR-010, ADR-011). No new workflow engine; reuse existing Temporal primitives.

Branch state

apps/ai/config/missions.yaml + apps/ai/config/employees.yaml exist; apps/ai/config/archive/missions.generic.v6.yaml + employees.generic.v6.yaml hold the superseded generic versions. Reconcile — extend, do not fork.

Scope

• Define M1–M6 missions plus 3-analyst config as data (config rows, not classes). Each entry: id, employee, trigger, goal, evidence requirements, context-checkpoint requirements, skills, capabilities, authority, risk tier, success criteria, verification spec, escalation path.
• Mission/employee code emits ActionIntent only and imports no connector SDKs (enforced by the architecture test in the intent-contracts issue).
• Hard test: adding a 7th mission == adding config, not a new class.
• Risk/success/verification specs per mission must be executable by the vertical slice (authorization → policy → approval → executor → verification).

Acceptance

• All M1–M6 + analyst configs load and validate; bypass test still green; config-addition test green.
• Generic 9-mission/3-intern class hierarchy stays archived; nothing on the onboarding path references it.

Verification

• uv run pytest apps/ai/tests/ -k "mission_config or employee_runtime or workforce" -v (from apps/ai)

Supersedes

• #3 Employee Runtime #55 (generic employee runtime reframed as bounded config-driven workforce) and #4 Mission + Autonomy #56 (9-mission catalog reframed as M1–M6), [WS-DECISION] Decision Runtime — option generation, trade-off/cost/risk/feasibility analysis, stakeholder impact, recommendation, confidence/readiness scoring, decision brief #47 (standalone decision runtime — decision-support outputs are per-mission success/verification specs, not a separate runtime).

---

Tightening — per-mission spec bar

Rationale: per hygiene ruling the close stands on superseded duplicates; the stricter criteria below are folded into this replacement instead of resurrecting duplicates.

• Every mission row specifies: trigger, goal, evidence/context requirements, allowed skills/capabilities/intents, authority/risk limits, verification + completion + escalation.
• All of the above is config-driven; adding a mission adds config rows, never new agent classes.

[Aparnap2]

Sprint D evidence (branch feature/ontologyai-onboarding-restructure, commit c87bc32): MissionSpec gains trigger_types/goal/required_context/allowed_skills/allowed_capabilities/success_criteria/action_constraints/approval_policy (all defaulted); roles gain tenant_scope; run_mission enforces type→plan→caps→read_only gates; m-blocked-work-01 enriched as M3 reference; M1/M2/M4/M5/M6 configs added (all plans ⊆ frozen role skills); 15 contract tests green (6 mission contracts, config-only addition, shared runtime, 3 negative gates, trigger routing). No new agents/skills/runtimes. Registry pinning suites still green.