[FE] AsyncAPI: API Change Classification- reuse JSON Schema compatibility suite cases/tests

[b41ex]

Is your feature request related to a problem? Please describe

No response

Describe the solution you'd like

Refactor JSON Schema samples in compatibility suite to be generated for required scope from base JSON schema changes cases for OAS:

• parameters schema
• request body schema
• response body schema
• response headers schema

Add scopes for JSON Schema object in AsyncAPI in compatibility suite:

• operation message headers
• operation message payload
• operation reply object message headers
• operation reply object message payload

Add tests to api-diff for JSON schema in AsyncAPI cases
Add stories/screenshot tests in api-doc-viewer

Describe alternatives you've considered

No response

Additional information

No response

[vOrigins]

Proposed logic

• Keep CS external contract unchanged:
  • getCompatibilitySuite(suiteType, suiteId, testId, specificationVersionPair?) -> [before, after]
  • getCompatibilitySuites(specType?) -> Map<suiteId, testIds[]>
  • getCompatibilitySuiteSpecificationVersionPairs(...) -> [beforeV, afterV][]
  • Note: when specType is omitted, suiteId must be unique across suite types or later entries overwrite earlier ones.
• Keep existing OpenAPI schema suite suite directories under bin/comparison-base-suite/openapi/:
  • parameters-schema, request-body-schema, response-body-schema, response-headers-schema
• Add an in-place suite template to each schema suite directory:
  • bin/comparison-base-suite/openapi/<suiteId>/template.yaml.tpl
  • Template contains a minimal valid OpenAPI skeleton + a single placeholder line __SCHEMA__.
  • Canonical version in templates: openapi: 3.0.4.
• Add AsyncAPI schema suite suites under bin/comparison-base-suite/asyncapi/:
  • operation-receive-message-headers
  • operation-send-message-headers
  • operation-receive-message-payload
  • operation-send-message-payload
  • operation-reply-receive-message-headers
  • operation-reply-send-message-headers
  • operation-reply-receive-message-payload
  • operation-reply-send-message-payload
  • Each has template.yaml.tpl with canonical asyncapi: 3.0.0 and a single placeholder line __SCHEMA__.
• Deduplicate schema deltas into a base store:
  • bin/comparison-base-suite/schemas/json-schema/<testId>/{before.yaml,after.yaml} (schema fragments only)
  • For schema suites: testId == testId.
• Keep OpenAPI metadata files in place:
  • bin/comparison-base-suite/openapi/<suiteId>/<testId>/metadata.yaml (if any)
  • Generator must populate CompatibilitySuiteMetaMap even when full samples are absent (rendered cases).
  • If metadata exists for a testId in any schema suite, ensure the same metadata.yaml exists in all 4 schema suites (copy; do not move).
• Handle $ref -> #/components/... cases as full-spec exceptions:
  • Keep full before.yaml/after.yaml samples in each OpenAPI schema suite for those case IDs (see cs-consumers.md list).
  • These cases are returned from CompatibilitySuiteMap as-is and are not rendered from templates.
• Runtime behavior (schema suites):
  • If full sample exists in CompatibilitySuiteMap for caseKey -> return it (covers exceptions).
  • Else if a template exists for <suiteType>/<suiteId> -> render from JsonSchemaCaseMap.get(testId) into template.yaml.tpl.
  • specificationVersionPair keeps existing semantics: OpenAPI-only, patch only the root openapi: line, and only for cases that have metadata.
  • Template rendering expects a single line-only placeholder token and fails fast if it is missing or duplicated.
• Generator validation:
  • Schema-suite templates are accepted only for known schema suites (fail fast on unknown suiteId).
  • For schema suite suites, cases without full samples must exist in the JSON schema base store (rendered via templates).
  • Full-sample exceptions (e.g. $ref -> #/components/... cases) do not require base-store fragments.
  • metadata.yaml must be a YAML mapping with version_combinations as a non-empty array of string pairs; OpenAPI versions are restricted to 3.0.x and 3.1.x.

[vOrigins]

Implementation plan - Part 1

• Phase 1 - Base store + OpenAPI templates + runtime render
  • Create bin/comparison-base-suite/schemas/json-schema/<testId>/{before.yaml,after.yaml} for template-injectable JSON Schema fragments (129)
  • Keep 4 $ref sibling ("rich ref") case IDs as OpenAPI full-sample exceptions (not in base store)
  • Add template.yaml.tpl to all 4 OpenAPI schema suites (canonical openapi: 3.0.4)
  • Keep $ref/components cases as full samples in all 4 schema suites
  • Update CS generator to export JsonSchemaCaseMap + SchemaSuiteTemplateMap and keep generating meta for rendered cases
  • Update CS runtime (suite-service.ts) to render schema suite cases on demand
• Phase 2 - Keep existing tests/stories green (no new api-diff tests yet)
  • api-diff: all existing OpenAPI CS tests pass
  • apispec-view: regenerate stories + update screenshot baselines (headers suite grows 11 -> 133)
• Phase 3 - Add missing OpenAPI test coverage in api-diff
  • Ensure full 133-case coverage for all OpenAPI schema suites: parameters-schema, request-body-schema, response-body-schema, response-headers-schema
• Phase 4 - Finalization
  • Resolve unexpanded nodes
  • Self-review and refactoring
  • Update documentation
  • Create PRs
    feat: reuse JSON Schema compatibility suite cases for OpenAPI qubership-apihub-compatibility-suites#32
    refactor: reuse JSON Schema compatibility suite cases for OpenAPI qubership-apihub-api-diff#60
    refactor: reuse JSON Schema compatibility suite cases for OpenAPI qubership-apihub-apispec-view#51
    refactor: consolidate generators into config-driven module qubership-apihub-api-doc-viewer#49

[vOrigins]

Implementation plan - Part 2

• Phase 5 - Add AsyncAPI suiteType + templates in CS + JSON Schema dialect grouping
  • Add asyncapi suiteType in compatibility-suites (data + API)
  • Add 8 AsyncAPI schema suite directories with template.yaml.tpl (canonical asyncapi: 3.0.0, split by operation action: receive/send)
  • Analyze JSON Schema dialects and define test grouping accordingly
• Phase 6 - Design test refactor + add AsyncAPI CS tests in api-diff
  • Design test refactor for api-diff CS tests (grouping/parametrization)
  • Add AsyncAPI CS tests for the 8 AsyncAPI schema suites (receive/send variants)
    • Expected status: tests will fail because comparisons are currently incorrect
• Phase 7 - Add AsyncAPI CS stories + screenshot tests in api-doc-viewer
  • Design (Phase 7)
  • Implement shared compatibility-suite generators in api-doc-viewer (GraphQL first)
    • Keep existing GraphQL CS screenshot tests green after refactor
  • Add AsyncAPI CS stories + screenshot tests
    • Generate stories for all 8 AsyncAPI schema suite suiteIds (receive/send variants)
    • Generate screenshot tests for the generated stories
  • Expand AsyncAPI schema suite suiteIds for operation actions (receive + send)
  • Temporarily disable AsyncAPI test generation (until AsyncApiOperationDiffViewer is implemented)
• Phase 8 - Finalization
  • Self-review and refactoring
  • Update documentation
  • Create PRs
    feat: reuse JSON Schema compatibility suite cases for AsyncAPI qubership-apihub-compatibility-suites#33
    feat: reuse JSON Schema compatibility suite cases for AsyncAPI qubership-apihub-api-diff#61
    feat: reuse JSON Schema compatibility suite cases for AsyncAPI qubership-apihub-api-doc-viewer#48