Add module-specific OpenAPI documents

[PANiXiDA]

What changed

• Added opt-in module-specific OpenAPI documents and Scalar document selection.
• Changed module registration to accept presentation assemblies in code while reading each document Name and Title from HttpModules configuration keyed by the assembly simple name.
• Kept HttpModule and HttpModuleRegistry internal under Modularity: the module is resolved endpoint metadata, while the registry validates and indexes it by assembly.
• Simplified OpenAPI document registration with modules.Select(static module => module.Name).
• Kept the existing combined /openapi/v1.json behavior when no module assemblies are registered.
• Updated Asp.Versioning.Http and Asp.Versioning.OpenApi to 10.0.1, Microsoft.AspNetCore.OpenApi to 10.0.10, and both Scalar packages to 2.16.17.
• Promoted the library version from 2.0-preview to stable 2.0 and updated the README package reference to 2.0.0.
• Added validation and tests for missing configuration, null and duplicate assemblies, duplicate document names, endpoint metadata, document isolation, Scalar sources, and assembly mapping deduplication.

Why

Applications composed from multiple presentation modules need focused OpenAPI documents without coupling document grouping to API versions. Assemblies remain type-safe code references, while document identifiers and UI titles can now vary by environment without recompilation.

Usage

builder.Services.AddHttp(
    builder.Configuration,
    typeof(IdentityPresentationAssembly).Assembly,
    typeof(CompendiumPresentationAssembly).Assembly);

{
  "HttpModules": {
    "PANiXiDA.TacticalHeroes.Identity.Presentation": {
      "Name": "identity",
      "Title": "Identity API"
    },
    "PANiXiDA.TacticalHeroes.Compendium.Presentation": {
      "Name": "compendium",
      "Title": "Compendium API"
    }
  }
}

Each HttpModules key must equal Assembly.GetName().Name. Name and Title are required for every registered assembly.

Local verification

dotnet restore
dotnet format --verify-no-changes --no-restore
dotnet build --configuration Release --no-restore
dotnet test --configuration Release --no-build --no-restore
dotnet test tests/PANiXiDA.Core.Presentation.Http.UnitTests/PANiXiDA.Core.Presentation.Http.UnitTests.csproj --configuration Debug --no-restore -- --coverage --coverage-output-format cobertura --coverage-output coverage.cobertura.xml
dotnet pack --configuration Release --no-build --no-restore
dotnet package list --project PANiXiDA.Core.Presentation.Http.slnx --vulnerable --include-transitive --no-restore

Result: Release build succeeded with no warnings, all 70 tests passed, Cobertura coverage is 100% for lines (555/555) and branches (151/151), package creation succeeded, and no vulnerable or prerelease dependencies were reported.

Compatibility

• Migrations: none.
• Configuration changes: no configuration is required for the existing combined document; every assembly passed to the new overload requires a matching HttpModules section.
• Public contracts: the unreleased HttpModule overload is replaced by AddHttp(IConfiguration, params Assembly[]); HttpModule is now internal.
• Package versioning: the library moves from the 2.0-preview line to stable 2.0.
• Breaking changes: none relative to the currently published package. Existing AddHttp(configuration) and combined v1 behavior remain unchanged.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d698e77a7b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Reject document names that cannot form route segments

When a configured Name contains / (for example, sales/v1), it passes the whitespace-only validation and is registered as an OpenAPI document, but MapOpenApi exposes only the single-segment route /openapi/{documentName}.json. Consequently, /openapi/sales/v1.json cannot resolve that document, leaving both direct access and its Scalar source unusable; validate module names as safe route-segment values before registration.

Useful? React with 👍 / 👎.