feat(planner): grounded ESS rollout planner skill, roles attestation, and WeveNova/WorkIQ MCP integration

[Harsheet jain (jainharsheet77)]

Description

Adds the grounded ESS rollout planner to the ESS Maker Skills kit, along with the supporting roles-attestation skill and the WeveNova/WorkIQ MCP integration that backs them.

Highlights:

• /planner skill — a grounded, interview-driven ESS rollout planner (Step 1): scenario-first interview, Learn-supported native-connector grounding, editable plan Markdown round-trip, dependency-ordered tasks, and eager eval preview.
• Shared planner sync — persists the plan to the shared planner service automatically once built and resolves the single active plan via project.activePlanId.
• /roles skill — role attestation, a shared two-tier person resolver (user-consentable Graph scope with a WorkIQ people-resolution fallback), and task assignment that reuses person resolution.
• AgentConfig MCP — mirrors the full WeveNova attestable-role registry (Entra + Power Platform), pins the WorkIQ MCP to @microsoft/workiq@1.0.0, and surfaces clearer planner error detail.
• Onboarding — /setup branches by persona so makers route into planning, and non-setup personas are nudged to /setup into the plan's environment.
• Tests — extensive new coverage across tests/planner, tests/roles, tests/mcp/*, and tests/scripts (~4.9k lines of tests).

Scope: solutions/ess-maker-skills/ (skills + workspace), tests/, dev-specs/, and one .github/ change. No samples/ content is touched.

Related issue

Refs #253

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor / cleanup

Testing

• New unit/contract test suites added under tests/planner/, tests/roles/, tests/mcp/planner/, tests/mcp/agentconfig/, and tests/scripts/ (plan model, capture, sync, research, roles, person resolution, MCP client/server contracts, widget protocol).
• Review feedback from the internal planner PR (feat(agentconfig-mcp): WeveNova planner MCP for planner-skill integration #253) was addressed across both the skill side and the MCP side.

Checklist

• My code follows the existing style
• I have added/updated tests where applicable
• I have updated documentation as needed

Static validation (samples/ only)

This PR does not touch anything under samples/ (changes are under solutions/, tests/, dev-specs/, and .github/), so sample static validation is not applicable.

Validation
- YAML parse: N-A
- AdaptiveDialog kind: N-A
- XML parse: N-A
- Filename convention (new): N-A
- Folder convention (new, incl. README.md): N-A
- Diff scope (samples/ only): N-A
- Secrets / internal URLs: N-A

[amilandi]

Telemetry gap: /planner doesn't emit ADK capability telemetry

Reviewed the branch for telemetry coverage. The new skill will not appear on the ADK Capability Usage donut (or any ADK cube). Every other maker-facing skill in solutions/ess-maker-skills/src/skills/ either emits capability.use in-process (setup, connect, discover, evaluate, backup/restore template configs, push, publish) or via a python scripts/emit_capability.py <cap> step in its SKILL.md (topics/{create,update,delete,review,test}, workflows/{create,update,delete,test}, cleanup, troubleshoot, onboarding, evaluations/{create,update,delete}). /planner does neither — I grepped the whole feature branch for emit_capability, adk_telemetry, and adk_capability and found zero hits across all 23 planner source files and 12 test files.

Consequence: when this merges as-is, every /planner run will be silently invisible on the dashboards used to track ADK adoption and capability usage. It won't even land in the unknown bucket — the emit call has to happen for that.

Recommended fix

Match the /discover pattern from PR #238 (Apurva's TestCapabilityTelemetry class is the model). It's a one-place, in-process emit right after argparse succeeds:

1. Add "planner" to ADK_CAPABILITIES in solutions/ess-maker-skills/scripts/adk_telemetry.py (and to the comment header block). Note that PR Split capability taxonomy so every user-facing command has its own dashboard wedge #259 already has this pending — you may want to coordinate with that PR or with amilandi to avoid a merge conflict on ADK_CAPABILITIES.

2. Emit once per invocation in scripts/planner/cli.py::main, right after parser.parse_args(argv):

   def main(argv: list[str] | None = None) -> int:
       _configure_io()
       parser = build_parser()
       args = parser.parse_args(argv)
   
       # Anonymous capability telemetry, emitted here — right after argparse
       # succeeds, so `--help` and bad arguments don't count — rather than at
       # the end. The "Capability Usage by Type" donut measures that a maker
       # *used* /planner, not whether the command happened to succeed; gating
       # the emit on a clean exit would silently undercount precisely the
       # runs worth looking into.
       try:
           import adk_telemetry
           # block=True: short-lived CLI process, emit synchronously so the
           # event isn't dropped when the interpreter exits and kills a
           # daemon thread.
           adk_telemetry.emit_capability_use("planner", block=True)
       except Exception:  # noqa: BLE001 — telemetry must never break the flow
           pass
   
       try:
           return args.func(args)
       # ...

3. Do NOT also add a emit_capability.py planner step to SKILL.md. emit_capability_use() doesn't dedupe, so wiring both would double-count every run. This is called out in Apurva's SKILL.md guardrail for /discover — same reasoning applies here. scripts/planner/cli.py is always the entry point, so the in-process emit is sufficient.

4. Add a test file tests/planner/test_cli_telemetry.py modeled on Apurva's TestCapabilityTelemetry from tests/scripts/test_discover_inventory.py:

   • test_planner_is_canonical_so_it_cannot_bucket_to_unknown — asserts "planner" in ADK_CAPABILITIES and normalize_capability("planner") == "planner".
   • test_a_run_emits_the_capability_exactly_once — spies emit_capability_use, runs cli.main(...), asserts exactly one ("planner", ...) call.
   • test_the_emit_is_synchronous — asserts block=True.
   • test_bad_arguments_do_not_count_as_usage — main(["nonexistent-cmd"]) raises SystemExit; assert no emit.
   • test_a_telemetry_failure_never_breaks_the_flow — monkeypatch emit_capability_use to raise; assert main(...) still returns 0.

Note on subcommand granularity

/planner has many subcommands (init, add-scenario, add-task, assign, claim, capture-setup, pin-output, research, summary, validate, sync, etc.). Emitting a single "planner" capability for all of them is the right first cut — it matches how the rest of the taxonomy works today (one value per maker-facing skill/command, not per sub-action). If PMs later want finer breakdown (e.g., "how many plans got past add-scenario?"), that's an additive change: add adk_capability as an already-present dimension and stamp the subcommand into a new planner_subcommand dimension on a follow-up telemetry event, without breaking the donut.

Happy to help review the fix.