flightcheck: re-point WD-WF-CAT-001 + WD-REF-001 to Declarative Agent components API

[Dawn Jeong (daeunJe0ng)]

Summary

Re-points two Workday FlightCheck checks to the Declarative Agent components API:

• AB#7852505 / WD-WF-CAT-001: enumerate Workday topic components from botComponentChanges by matching schema names that contain .topic.Workday.
• AB#7852513 / WD-REF-001: enumerate Workday reference-data structure from botComponentChanges by matching .variable.*LookupTable variables plus WorkdaySystemGetReferenceData and WorkdaySystemRefreshReferenceData topics.

This PR stacks on the shared reader in #326 and on #304. Merge order: #326 -> #304 -> this PR. Until they merge, the diff shows their commits.

What changed

• Reads the top-level botComponentChanges list from the validated components payload via runner.agentbuilder.fetch_components(agent_id).
• Updated WD-REF-001 to produce a deterministic structural verdict without Dataverse:
  • Passed when LookupTable variables and both reference-data topics are present.
  • Failed when the structural components are absent.
  • Skipped when AgentBuilder or the active botId is unavailable.
  • Warning when the components payload has a malformed botComponentChanges shape.
• Updated WD-WF-CAT-001 to produce a deterministic Workday topic inventory from Declarative Agent topic component schema names.
• Registered WD-REF-001 and WD-WF-CAT-001 for single-checkpoint execution with AGENTBUILDER only and requires_dataverse_endpoint=False.
• Rewrote the two checks' tests against tests/mocks/agentbuilder_connectivity.py and extended that mock with a botComponentChanges builder.
• Removed 8 now-dead module-level items left by the re-point (_WD_REF_KEY_LABELS, _WD_REF_SUPPORTED_RE, _WD_REF_REQUESTED_RE, _ref_key_label, _extract_requested_reference_keys, _extract_supported_reference_keys, _format_unknown_scenarios, _WD_WF_CAT_CHECKLIST): the old Dataverse reference-key reconciliation and catalog-checklist output that the structural DA verdict no longer calls (git history retains them if US 7792327 restores semantic classification).

Design rationale

The source of truth is the AgentBuilder components payload returned by AgentBuilderClient.fetch_components(agent_id). botComponentChanges is a top-level list in the same validated payload used by #304 for connectionReferenceChanges.

These checks are intentionally structural and flowless. They verify that the Declarative Agent contains the expected Workday topic and reference-data component shapes without depending on the old Dataverse botcomponents table, workspace-local extracted files, or cloud flow inventory.

The shipped-vs-custom classification catalog and final reference-data key rules are external inputs owned by Skantha's follow-up work, US 7792327. This PR does not block on that catalog. Classification remains gated out, and the result text explicitly notes that the current verdict is structural enumeration only pending US 7792327.

Testing

• python -m pytest tests\flightcheck -q
  • Result: 1114 passed in 5.62s
• python -m ruff check solutions\ess-maker-skills\scripts
  • Result: All checks passed!

Live DA-environment validation (partially complete)

Live run 2026-09-22 against ESS GA env 258bd301 (prod ring; non-Workday agent): the shared DA component reader fetched botComponentChanges from a real DA agent; with no Workday components present, WD-REF-001 returned the documented FAIL (checked below) and WD-WF-CAT-001 produced a deterministic empty Workday-topic inventory (0 .topic.Workday*). The Workday-present PASS paths need a Workday-bound DA agent (none reachable this run).

To be checked once a published Workday-bound Declarative Agent is provisioned in the test env. Blocked on that agent; these are read-only components reads on the prod-audience AgentBuilder token and do NOT depend on the TIP2 (Test-In-Production ring 2) auth issue. Structural enumeration only until the classification catalog lands (US 7792327). Each box is marked when the scenario is confirmed on a live DA env.

• WD-REF-001 against a DA Workday agent whose components include .variable.*LookupTable variables plus WorkdaySystemGetReferenceData and WorkdaySystemRefreshReferenceData topics -> PASSED.
• WD-REF-001 against a payload missing those structural components -> FAILED.
• WD-WF-CAT-001 against a DA Workday agent -> deterministic Workday topic inventory from .topic.Workday* schema names in botComponentChanges.
• No-AgentBuilder-client / no-active-botId -> SKIPPED, no crash.
• Malformed botComponentChanges shape -> WARNING (fail loudly).

Follow-up

• US 7792327: add the external shipped-vs-custom classification catalog and finalize reference-data key rules.
• After flightcheck: add canonical DA connection-reference reader + contract test #326 and flightcheck: fail loud on malformed DA connection-ref payloads (reader hardening) #304 merge, rebase/update this stack so the PR diff shows only the Workday component-inventory changes.

[Dawn Jeong (daeunJe0ng)]

Closing as superseded.

While this PR was queued, main independently re-implemented WD-WF-CAT-001 and WD-REF-001. This PR re-points those checks to read Workday from the DA bot components API (_da_components.read_component_schema_names -> _workday_topic_schema_names). That is the wrong layer: Workday DA is flow/solution-scoped (connection ref new_sharedworkdaysoap_ff0df) and does not surface in botComponentChanges, so the re-pointed checks would look for components that structurally cannot appear.

main now handles Workday DA at the correct layer via checks/workday_da.py (WD-DA-PKG-001, _check_workday_da_package_installed), verifying the Workday DA solution/package is installed, and keeps the topic + Dataverse OOTB catalog reconciliation for WD-WF-CAT-001 / WD-REF-001.

This PR's unique deltas (_da_components.py reader, the agentbuilder connectivity mock, and ~1,765 lines of removed topic/catalog test scaffolding) all serve the superseded bot-components approach and have no consumer once main's approach is in place. Nothing to salvage.

Same disposition as #328.