Content has no platform metadata, so Windows-only content is offered on macOS and Linux

[bobtista]

Problem

Nothing in the content pipeline knows what platform a piece of content targets, and nothing filters on it:

• GeneralsOnlineProvider has no platform gating
• manifests carry no platform/target metadata
• discovery and the content browser do no platform filtering

The result is that a macOS or Linux user is offered Generals Online, can acquire it successfully, and ends up with a Windows client they cannot launch. Acquisition genuinely succeeds — GeneralsOnlineDeliverer uses ZipFile.ExtractToDirectory, which is cross-platform — so the failure surfaces later and looks like a bug in launching rather than an unsupported combination.

Generals Online is Windows-only by construction, not by omission: EAC_LaunchGeneralsOnline.exe is documented in GameClientConstants as the supported launch target, and Easy Anti-Cheat has no macOS or Linux support. The same applies to other Windows-only content, e.g. the GenPatcher tool in #242.

[coderabbitai]

🔗 Related PRs

#328 - feat(platform): make paths, manifests, and Unix workspaces platform-aware [merged]
#332 - feat(launching): launch the native BGFX client against retail archives [merged]
#343 - fix(generalsonline): launch and track through the Easy Anti-Cheat bootstrapper [merged]
#352 - feat(installations): detect retail installations by archive presence [open]
#366 - fix(generalsonline): forward-port Easy Anti-Cheat launch support from alpha 4 [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• Introduce one [Flags] SupportedPlatform enum and a manifest-level SupportedPlatforms field, threaded through ContentSearchResult and ContentSearchQuery.
• Gate Windows-only providers with a single reusable virtual property on BaseContentProvider composed into IsEnabled, so GeneralsOnlineProvider and CommunityOutpostProvider (ticket #242) share one mechanism.
• Add defense-in-depth checks in discovery, validation, and launch preflight so incompatible content fails early with a clear platform message instead of at launch.
• Expose a platform badge and browser filter following the existing GameType/ContentType UI patterns.

Design Choices

Design Choice 1: Platform enum shape: single value or flags set

Options Considered:

1. Single-value enum (Windows/Linux/MacOS/Unknown).
2. [Flags] enum (SupportedPlatform) that can combine Windows | Linux | MacOS.

Chosen Option: 2

Rationale: A [Flags] enum models cross-platform content and Windows-only content with one field. It supports a simple check to test if the current OS bit matches.

Design Choice 2: Location of primary provider gating logic

Options Considered:

1. Override IsEnabled directly in each Windows-only provider with an inline RuntimeInformation check.
2. Add a shared virtual SupportedPlatforms property on BaseContentProvider (default all platforms) and compose it into the base IsEnabled.

Chosen Option: 2

Rationale: A shared virtual property on BaseContentProvider is reusable for ticket #242 (CommunityOutpost). It avoids duplicating OS logic. It keeps the existing IsEnabled gating semantics used by ContentOrchestrator.

Design Choice 3: Platform declaration scope: per file or per manifest

Options Considered:

1. Add a per-file platform field on ManifestFile.
2. Add a single manifest-level platform field on ContentManifest.

Chosen Option: 2

Rationale: The ticket's concrete cases are whole-provider Windows-only content. Manifest-level platform is sufficient. Per-file platform is deferred to avoid scope creep.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Platform metadata foundation

This phase introduces the platform concept and threads it through the content data models. Every manifest, discovery result, and search query must be able to declare or filter by target platform. Generals Online manifests must declare Windows.

Task 1: Add the platform enum and a current-platform helper

Create the shared vocabulary for platform targeting.

• Add a new [Flags] enum SupportedPlatform in GenHub/GenHub.Core/Models/Enums/. Include Windows, Linux, MacOS, an Unknown/None default (value 0), and a convenience All combination.
• Add a small static helper in a suitable GenHub.Core location that returns the current OS as a SupportedPlatform value using RuntimeInformation.IsOSPlatform(...), mirroring the CanDetectOnCurrentPlatform idiom. This helper avoids duplicating OS-detection logic in the provider, validator, and launcher.

Task 2: Add platform metadata to the manifest model

Give content a first-class platform field alongside TargetGame.

• Add a SupportedPlatform-typed property (for example SupportedPlatforms) to GenHub/GenHub.Core/Models/Manifest/ContentManifest.cs, placed next to TargetGame.
• Default the property to SupportedPlatform.All so existing manifests remain cross-platform and behavior is unchanged unless a manifest declares otherwise.

Task 3: Carry platform through discovery result and search query

Enable discovery and search to express platform.

• Add a nullable SupportedPlatform? property to GenHub/GenHub.Core/Models/Results/Content/ContentSearchResult.cs, following the existing TargetGame property shape.
• Add a nullable SupportedPlatform? filter property to GenHub/GenHub.Core/Models/Content/ContentSearchQuery.cs, following the existing TargetGame filter.

Task 4: Populate Windows platform in Generals Online manifests

Make Generals Online content declare its true platform.

• Update GenHub/GenHub/Features/Content/Services/GeneralsOnline/GeneralsOnlineManifestFactory.cs so every manifest it builds (30Hz, 60Hz, and the QuickMatch map pack) sets SupportedPlatforms = SupportedPlatform.Windows in the same object-initializer blocks that already set TargetGame = GameType.ZeroHour.
• Update GeneralsOnlineDiscoverer to set SupportedPlatform.Windows on the ContentSearchResult it produces, so search results carry platform before full resolution.

🤖 Prompt for AI agents

Implement the platform metadata foundation. The goal is that every manifest,
discovery result, and search query can declare or filter by target platform, and
Generals Online manifests declare Windows.

- Add a new `[Flags]` enum `SupportedPlatform` in
`GenHub/GenHub.Core/Models/Enums/`. Include `Windows`, `Linux`, `MacOS`, an
`Unknown`/`None` default (value 0), and a convenience `All` combination.
- Add a small static helper in a suitable `GenHub.Core` location that returns
the current OS as a `SupportedPlatform` value using
`RuntimeInformation.IsOSPlatform(...)`. Mirror the `CanDetectOnCurrentPlatform`
idiom. This helper must be reused later by the provider, validator, and launcher
to avoid duplicated OS-detection logic.
- Add a `SupportedPlatform`-typed property (for example `SupportedPlatforms`) to
`GenHub/GenHub.Core/Models/Manifest/ContentManifest.cs`, placed next to
`TargetGame`. Default it to `SupportedPlatform.All` so existing manifests remain
cross-platform unless they declare otherwise.
- Add a nullable `SupportedPlatform?` property to
`GenHub/GenHub.Core/Models/Results/Content/ContentSearchResult.cs`, following
the existing `TargetGame` property shape.
- Add a nullable `SupportedPlatform?` filter property to
`GenHub/GenHub.Core/Models/Content/ContentSearchQuery.cs`, following the
existing `TargetGame` filter.
- Update
`GenHub/GenHub/Features/Content/Services/GeneralsOnline/GeneralsOnlineManifestFactory.cs`
so every manifest it builds (30Hz, 60Hz, and the QuickMatch map pack) sets
`SupportedPlatforms = SupportedPlatform.Windows` in the same object-initializer
blocks that already set `TargetGame = GameType.ZeroHour`.
- Update `GeneralsOnlineDiscoverer` to set `SupportedPlatform.Windows` on the
`ContentSearchResult` it produces, so search results carry platform before full
resolution.

Phase 2: Provider-level platform gating

This phase stops Windows-only providers from participating in discovery and acquisition on non-Windows hosts. The goal is a single reusable gating mechanism on the base provider, so Generals Online and CommunityOutpost (ticket #242) share one implementation.

Task 1: Add reusable platform gating to the base provider

Introduce a shared, backward-compatible gating hook.

• Add a virtual SupportedPlatform SupportedPlatforms property to GenHub/GenHub/Features/Content/Services/ContentProviders/BaseContentProvider.cs, defaulting to SupportedPlatform.All.
• Compose this property into the base IsEnabled so IsEnabled returns false when the current OS bit is not present in SupportedPlatforms. Use the current-platform helper from Task 1.1.
• Keep the change additive. Existing subclasses that do not override the new property remain cross-platform and enabled as before.

Task 2: Mark the Windows-only providers

Declare which providers are Windows-only.

• Update GenHub/GenHub/Features/Content/Services/GeneralsOnline/GeneralsOnlineProvider.cs to override SupportedPlatforms to return SupportedPlatform.Windows, and remove the hardcoded IsEnabled => true so the base gating applies.
• Update GenHub/GenHub/Features/Content/Services/CommunityOutpost/CommunityOutpostProvider.cs the same way to close the same gap for GenPatcher content (#242).
• Because ContentOrchestrator.SearchAsync and acquisition already filter by IsEnabled, this change transparently removes these providers from search and acquisition on non-Windows hosts. No orchestrator change is required.

Task 3: Add defense-in-depth in the Windows-only discoverers

Prevent discovery even if a provider is invoked directly.

• In GeneralsOnlineDiscoverer (and the CommunityOutpost discoverer), return an empty result set early when the current OS is not Windows. This protects code paths that bypass provider IsEnabled.

🤖 Prompt for AI agents

Implement provider-level platform gating so Windows-only providers do not
participate in discovery and acquisition on non-Windows hosts. Use a single
reusable gating mechanism on the base provider, shared by Generals Online and
CommunityOutpost (ticket `#242`).

- Add a virtual `SupportedPlatform SupportedPlatforms` property to
`GenHub/GenHub/Features/Content/Services/ContentProviders/BaseContentProvider.cs`,
defaulting to `SupportedPlatform.All`.
- Compose this property into the base `IsEnabled` so `IsEnabled` returns `false`
when the current OS bit is not present in `SupportedPlatforms`. Use the
current-platform helper from Phase 1.
- Keep the change additive: existing subclasses that do not override the new
property must remain cross-platform and enabled as before.
- Update
`GenHub/GenHub/Features/Content/Services/GeneralsOnline/GeneralsOnlineProvider.cs`
to override `SupportedPlatforms` to return `SupportedPlatform.Windows`, and
remove the hardcoded `IsEnabled => true` so the base gating applies.
- Update
`GenHub/GenHub/Features/Content/Services/CommunityOutpost/CommunityOutpostProvider.cs`
the same way, to close the same gap for GenPatcher content (`#242`).
- Do not modify `ContentOrchestrator`: because `SearchAsync` and acquisition
already filter by `IsEnabled`, this change transparently removes these providers
from search and acquisition on non-Windows hosts.
- In `GeneralsOnlineDiscoverer` (and the CommunityOutpost discoverer), return an
empty result set early when the current OS is not Windows, as a defense-in-depth
measure for code paths that bypass provider `IsEnabled`.

Phase 3: Acquisition and launch safety nets

This phase adds compatibility checks at the points where incompatible content would otherwise be silently accepted or fail with a confusing error. The goal is a clear, early platform-incompatibility signal instead of a launch failure that looks like a bug.

Task 1: Add a platform-incompatibility validation issue

Let validation flag platform mismatches.

• Add a PlatformIncompatible value to GenHub/GenHub.Core/Models/Enums/ValidationIssueType.cs.
• Update ValidateManifestStructure in GenHub/GenHub/Features/Content/Services/ContentValidator.cs to add a ValidationIssue with Severity = Error when the manifest SupportedPlatforms does not include the current OS. Use the helper from Task 1.1. The existing severity-driven ValidationResult logic then reports the failure without further changes.

Task 2: Add a launch-time safety-net check

Fail launch early with a clear platform message.

• Add a platform-compatibility check in the launch preflight path. Prefer ProfileLauncherFacade.ValidateLaunchAsync in GenHub/GenHub/Features/GameProfiles/Services/ProfileLauncherFacade.cs, alongside the existing dependency validation, before gameLauncher.LaunchProfileAsync runs.
• If the profile's client manifest declares a SupportedPlatforms set that does not include the current OS, return a failure result with a clear message that the content is not supported on the current platform. Reuse the existing failure-result pattern used by other preflight checks.

🤖 Prompt for AI agents

Implement acquisition and launch safety-net checks so incompatible content
produces a clear, early platform-incompatibility signal instead of a confusing
launch failure.

- Add a `PlatformIncompatible` value to
`GenHub/GenHub.Core/Models/Enums/ValidationIssueType.cs`.
- Update `ValidateManifestStructure` in
`GenHub/GenHub/Features/Content/Services/ContentValidator.cs` to add a
`ValidationIssue` with `Severity = Error` when the manifest `SupportedPlatforms`
does not include the current OS. Use the current-platform helper from Phase 1.
Rely on the existing severity-driven `ValidationResult` logic to report the
failure; no further changes to that logic are needed.
- Add a platform-compatibility check in the launch preflight path. Prefer
`ProfileLauncherFacade.ValidateLaunchAsync` in
`GenHub/GenHub/Features/GameProfiles/Services/ProfileLauncherFacade.cs`,
alongside the existing dependency validation, before
`gameLauncher.LaunchProfileAsync` runs.
- If the profile's client manifest declares a `SupportedPlatforms` set that does
not include the current OS, return a failure result with a clear message stating
that the content is not supported on the current platform. Reuse the existing
failure-result pattern used by other preflight checks.

Phase 4: Browser filtering and platform badge

This phase makes platform visible and filterable in the content browser, satisfying the requirement that the content browser must do platform filtering. Follow the existing GameType badge and ContentType filter patterns.

Task 1: Surface platform in the display model and formatter

Add a platform badge, following the GameType pattern.

• Add a SupportedPlatform property to GenHub/GenHub.Core/Models/Content/ContentDisplayItem.cs, next to GameType.
• Populate it in GenHub/GenHub/Features/GameProfiles/Services/ContentDisplayFormatter.cs from manifest.SupportedPlatforms, mirroring how GameType = manifest.TargetGame is set.
• Add a GetPlatformDisplayName(...) method to IContentDisplayFormatter and its implementation, mirroring GetGameTypeDisplayName, for the badge label.

Task 2: Add a platform filter to the content browser

Let users filter by platform.

• Add a SelectedPlatform observable property to GenHub/GenHub/Features/Content/ViewModels/ContentBrowserViewModel.cs, mirroring _selectedContentType.
• Set Platform = SelectedPlatform on the ContentSearchQuery built in SearchAsync, mirroring how ContentType is applied.
• Optionally default the filter to the current OS so users see only runnable content by default, while still allowing them to view all platforms.

🤖 Prompt for AI agents

Implement browser filtering and a platform badge so platform is visible and
filterable in the content browser. Follow the existing `GameType` badge and
`ContentType` filter patterns.

- Add a `SupportedPlatform` property to
`GenHub/GenHub.Core/Models/Content/ContentDisplayItem.cs`, next to `GameType`.
- Populate it in
`GenHub/GenHub/Features/GameProfiles/Services/ContentDisplayFormatter.cs` from
`manifest.SupportedPlatforms`, mirroring how `GameType = manifest.TargetGame` is
set.
- Add a `GetPlatformDisplayName(...)` method to `IContentDisplayFormatter` and
its implementation, mirroring `GetGameTypeDisplayName`, to provide the badge
label.
- Add a `SelectedPlatform` observable property to
`GenHub/GenHub/Features/Content/ViewModels/ContentBrowserViewModel.cs`,
mirroring `_selectedContentType`.
- Set `Platform = SelectedPlatform` on the `ContentSearchQuery` built in
`SearchAsync`, mirroring how `ContentType` is applied.
- Optionally default the filter to the current OS so users see only runnable
content by default, while still allowing them to view all platforms.

Research

GenHub uses a layered content pipeline: IContentDiscoverer → IContentResolver → IContentDeliverer, wrapped by an IContentProvider, and coordinated by ContentOrchestrator. All providers derive from BaseContentProvider, which exposes virtual IsEnabled and Capabilities. ContentOrchestrator.SearchAsync already filters providers with _providers.Where(p => p.IsEnabled). Content is described by ContentManifest (which has TargetGame but no platform field). Discovery uses ContentSearchResult and ContentSearchQuery, and the browser uses ContentBrowserViewModel and ContentDisplayItem. The codebase gates OS-specific behavior with RuntimeInformation.IsOSPlatform(...), most clearly in IGameInstallationDetector.CanDetectOnCurrentPlatform. No shared platform helper and no platform enum exist today.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the platform metadata foundation. The goal is that every manifest,
discovery result, and search query can declare or filter by target platform, and
Generals Online manifests declare Windows.

- Add a new `[Flags]` enum `SupportedPlatform` in
`GenHub/GenHub.Core/Models/Enums/`. Include `Windows`, `Linux`, `MacOS`, an
`Unknown`/`None` default (value 0), and a convenience `All` combination.
- Add a small static helper in a suitable `GenHub.Core` location that returns
the current OS as a `SupportedPlatform` value using
`RuntimeInformation.IsOSPlatform(...)`. Mirror the `CanDetectOnCurrentPlatform`
idiom. This helper must be reused later by the provider, validator, and launcher
to avoid duplicated OS-detection logic.
- Add a `SupportedPlatform`-typed property (for example `SupportedPlatforms`) to
`GenHub/GenHub.Core/Models/Manifest/ContentManifest.cs`, placed next to
`TargetGame`. Default it to `SupportedPlatform.All` so existing manifests remain
cross-platform unless they declare otherwise.
- Add a nullable `SupportedPlatform?` property to
`GenHub/GenHub.Core/Models/Results/Content/ContentSearchResult.cs`, following
the existing `TargetGame` property shape.
- Add a nullable `SupportedPlatform?` filter property to
`GenHub/GenHub.Core/Models/Content/ContentSearchQuery.cs`, following the
existing `TargetGame` filter.
- Update
`GenHub/GenHub/Features/Content/Services/GeneralsOnline/GeneralsOnlineManifestFactory.cs`
so every manifest it builds (30Hz, 60Hz, and the QuickMatch map pack) sets
`SupportedPlatforms = SupportedPlatform.Windows` in the same object-initializer
blocks that already set `TargetGame = GameType.ZeroHour`.
- Update `GeneralsOnlineDiscoverer` to set `SupportedPlatform.Windows` on the
`ContentSearchResult` it produces, so search results carry platform before full
resolution.
===============================================================================

Task: 2

Implement provider-level platform gating so Windows-only providers do not
participate in discovery and acquisition on non-Windows hosts. Use a single
reusable gating mechanism on the base provider, shared by Generals Online and
CommunityOutpost (ticket `#242`).

- Add a virtual `SupportedPlatform SupportedPlatforms` property to
`GenHub/GenHub/Features/Content/Services/ContentProviders/BaseContentProvider.cs`,
defaulting to `SupportedPlatform.All`.
- Compose this property into the base `IsEnabled` so `IsEnabled` returns `false`
when the current OS bit is not present in `SupportedPlatforms`. Use the
current-platform helper from Phase 1.
- Keep the change additive: existing subclasses that do not override the new
property must remain cross-platform and enabled as before.
- Update
`GenHub/GenHub/Features/Content/Services/GeneralsOnline/GeneralsOnlineProvider.cs`
to override `SupportedPlatforms` to return `SupportedPlatform.Windows`, and
remove the hardcoded `IsEnabled => true` so the base gating applies.
- Update
`GenHub/GenHub/Features/Content/Services/CommunityOutpost/CommunityOutpostProvider.cs`
the same way, to close the same gap for GenPatcher content (`#242`).
- Do not modify `ContentOrchestrator`: because `SearchAsync` and acquisition
already filter by `IsEnabled`, this change transparently removes these providers
from search and acquisition on non-Windows hosts.
- In `GeneralsOnlineDiscoverer` (and the CommunityOutpost discoverer), return an
empty result set early when the current OS is not Windows, as a defense-in-depth
measure for code paths that bypass provider `IsEnabled`.
===============================================================================

Task: 3

Implement acquisition and launch safety-net checks so incompatible content
produces a clear, early platform-incompatibility signal instead of a confusing
launch failure.

- Add a `PlatformIncompatible` value to
`GenHub/GenHub.Core/Models/Enums/ValidationIssueType.cs`.
- Update `ValidateManifestStructure` in
`GenHub/GenHub/Features/Content/Services/ContentValidator.cs` to add a
`ValidationIssue` with `Severity = Error` when the manifest `SupportedPlatforms`
does not include the current OS. Use the current-platform helper from Phase 1.
Rely on the existing severity-driven `ValidationResult` logic to report the
failure; no further changes to that logic are needed.
- Add a platform-compatibility check in the launch preflight path. Prefer
`ProfileLauncherFacade.ValidateLaunchAsync` in
`GenHub/GenHub/Features/GameProfiles/Services/ProfileLauncherFacade.cs`,
alongside the existing dependency validation, before
`gameLauncher.LaunchProfileAsync` runs.
- If the profile's client manifest declares a `SupportedPlatforms` set that does
not include the current OS, return a failure result with a clear message stating
that the content is not supported on the current platform. Reuse the existing
failure-result pattern used by other preflight checks.
===============================================================================

Task: 4

Implement browser filtering and a platform badge so platform is visible and
filterable in the content browser. Follow the existing `GameType` badge and
`ContentType` filter patterns.

- Add a `SupportedPlatform` property to
`GenHub/GenHub.Core/Models/Content/ContentDisplayItem.cs`, next to `GameType`.
- Populate it in
`GenHub/GenHub/Features/GameProfiles/Services/ContentDisplayFormatter.cs` from
`manifest.SupportedPlatforms`, mirroring how `GameType = manifest.TargetGame` is
set.
- Add a `GetPlatformDisplayName(...)` method to `IContentDisplayFormatter` and
its implementation, mirroring `GetGameTypeDisplayName`, to provide the badge
label.
- Add a `SelectedPlatform` observable property to
`GenHub/GenHub/Features/Content/ViewModels/ContentBrowserViewModel.cs`,
mirroring `_selectedContentType`.
- Set `Platform = SelectedPlatform` on the `ContentSearchQuery` built in
`SearchAsync`, mirroring how `ContentType` is applied.
- Optionally default the filter to the current OS so users see only runnable
content by default, while still allowing them to view all platforms.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!