Workspace-scoped sub-resource filtering not implemented #119

User Impact

When using a filter configuration file (configuration.extractor.yaml) with nested workspace filtering like this:

workspaces:
  - my-workspace:
      apis:
        - important-api
      backends:
        - prod-backend

The CLI silently ignores the nested filters and extracts ALL resources within the workspace. Customers migrating from the APIOps Toolkit who rely on workspace-level sub-resource filtering will get unexpected results — every API, backend, logger, etc. in the workspace will be extracted instead of just the ones listed.

The only workspace filtering that works today is including/excluding entire workspaces:

workspaces:
  - my-workspace    # ✅ works — includes this workspace
  # omitting a workspace excludes it

Technical Details

The APIOps Toolkit supports full nested workspace filtering, including:

• Filtering specific resource types within a workspace (apis, backends, loggers, etc.)
• Nested API sub-filtering within workspaces (workspace → apis → operations/diagnostics/releases)

The CLI currently:

• Parses workspace sub-filters correctly in config-loader.ts (the workspaceSubFilters field is populated)
• Never consumes them — filter-service.ts has no matchesWorkspaceSubFilter() function, and workspace-extractor.ts doesn't pass sub-filters when extracting workspace-scoped resources

Expected Behavior

Nested workspace filters should work the same as they do in the APIOps Toolkit — only the specified sub-resources within each workspace should be extracted.

Related

This was identified during the filter/override format alignment work in #114 / PR #115.