fix(docs): match Helm values, backup Secret namespace and OIDC role mapping to the code

[ValgulNecron]

Summary

Fixes the four findings Qodo raised on ValgulNecron/Gameplane#520, the submodule bump to this site. I checked each one against the Gameplane chart and code.

• installation.mdx, network policies example:
  • networkPolicies.kubeletCIDRs is now a YAML list. The chart ranges over it (templates/networkpolicies.yaml), so the old comma-separated string broke rendering.
  • gameEgress.ports entries are now { protocol: TCP, port: 443 } objects. The chart reads .protocol and .port from each entry, so the old bare integers failed.
• installation.mdx, OIDC example: the snippet is now split by chart version.
  • The v0.2.0-beta.8 block has only enabled, issuer, clientID, clientSecretRef and redirectURL. The redirect URL points at the /auth/oidc/callback path that beta.8 serves. On beta.8, group mapping is set per provider under Admin Settings → Authentication.
  • A separate v0.3.0+ block adds displayName, groupsClaim, defaultRole and roleMappings.
• backup-restore-crds.mdx:
  • The restic repository Secret must be in the Backup's namespace. backup_controller.go looks it up in b.Namespace and fails the Backup if it isn't there.
  • The page said gameplane-system, and its example Secret now sets namespace: gameplane-games.
• sign-in-recovery.mdx:
  • The page said group-to-role mapping "is not available in beta.8". It has been available since beta.6: per-provider groups claim, role mappings and default role (api/internal/auth/oidc.go at v0.2.0-beta.8).
  • The "Coming in v0.3.0" callout and the effective-role bullet now describe only seeding the mappings from Helm values as new in v0.3.0.

Verification

• astro build succeeds (93 pages).

🤖 Generated with Claude Code

https://claude.ai/code/session_01UshpSigdLccuYZi7oFJX9y

[qodo-code-review]

PR Summary by Qodo

Correct Helm, backup Secret, and OIDC documentation

📝 Documentation 🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Correct network policy Helm examples to use CIDR lists and protocol-and-port objects.
• Place backup repository Secrets in the Backup namespace, matching operator lookup behavior.
• Clarify beta.8 provider role mapping versus v0.3.0 Helm-based mapping.

Diagram

graph TD
  Install["Installation guide"] --> Chart["Helm chart"] --> Policies["Network policies"]
  Backup["Backup guide"] --> Controller["Backup controller"] --> Secret[("Repository Secret")]
  SignIn["Sign-in guide"] --> Auth["OIDC provider settings"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Separate version-specific OIDC examples

• ➕ Prevents readers using the guide’s beta.8 install command from copying v0.3.0-only values.
• ➖ Adds duplicate examples and ongoing documentation maintenance.

Recommendation: Keep the targeted contract corrections, but consider splitting the OIDC snippet by chart version: the guide still pairs a v0.3.0-only snippet with a beta.8 install command. Also reconcile the unchanged sign-in callout and recovery text, which still describe provider role mapping as unavailable before v0.3.0.

Files changed (3) +15 / -7

Documentation (3) +15 / -7

backup-restore-crds.mdxPlace restic credentials in the Backup namespace +3/-2

Place restic credentials in the Backup namespace

• Corrects the repository Secret requirement from the operator namespace to the namespace of the referencing Backup or BackupSchedule. The example Secret now explicitly uses the default games namespace.

src/content/docs/backup-restore-crds.mdx

installation.mdxCorrect network policy values and version OIDC options +11/-4

Correct network policy values and version OIDC options

• Changes kubelet CIDRs to a YAML list and game egress ports to protocol-and-port objects. Clarifies that beta.8 supports basic Helm OIDC configuration, while Helm-seeded role mappings require v0.3.0.

src/content/docs/installation.mdx

sign-in-recovery.mdxClarify existing provider-level OIDC role mapping +1/-1

Clarify existing provider-level OIDC role mapping

• Corrects the OIDC overview to explain that providers can already map groups to roles and assign a default role in beta.8. Distinguishes that capability from Helm-based mapping seeding planned for v0.3.0.

src/content/docs/sign-in-recovery.mdx

[qodo-code-review]

Code Review by Qodo

≡ Correctness (1) ☼ Reliability (0) ⛨ Security (0) ✧ Quality (0) ⚙ Maintainability (0) ➹ Performance (0) ◔ Observability (0) § Compliance (0) ❖ Design (0) ⌂ Architecture (0) ☑ Accessibility (0) ▣ Testability (0)

No findings for this group

1. OIDC mapping remains falsely marked unavailable 🟠 Medium ●● Moderate 🔗 Cross-repo conflict ≡ Correctness

Description

The updated OIDC text says Gameplane providers already support mapping identity-provider groups to
roles, but the following callout still says that capability is coming in v0.3.0. This contradicts
beta.8 authentication behavior and can lead readers to believe the Admin Settings configuration is
unavailable and miss the supported setup path.

Code

src/content/docs/sign-in-recovery.mdx[49]

+**OIDC** (OpenID Connect) delegates authentication to a third-party identity provider (Keycloak, Authentik, Google Workspace, Okta, etc.). The provider handles password storage and MFA; Gameplane stores only the OIDC subject ID (issuer + subject claim). Each provider can map IdP groups to dashboard roles (a groups claim, per-role group lists and a default role); a user with no matching group gets the default role, `viewer` unless you change it. Seeding these mappings from Helm values arrives in v0.3.0. Providers are configured under **Admin Settings → Authentication** and take effect on the next user login (no API restart required).

Evidence

The changed paragraph states that each Gameplane provider can map IdP groups to roles, with only
Helm seeding arriving in v0.3.0, while the unchanged callout immediately below says OIDC group-claim
role mapping itself will arrive in v0.3.0. Gameplane's provider policy and role computation
implement group claims, role mappings, and default-role behavior directly, confirming that the two
availability claims describe the same capability inconsistently.

gameplane-website -> Gameplane
/pr_repo/src/content/docs/sign-in-recovery.mdx[49-53]
src/content/docs/sign-in-recovery.mdx[49-52]
External repo: ValgulNecron/Gameplane, api/internal/auth/oidc.go [37-51]
External repo: ValgulNecron/Gameplane, api/internal/auth/oidc.go [179-207]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The updated OIDC paragraph correctly documents per-provider group-to-role mapping as available in beta.8, but the unchanged callout immediately below still describes the same mapping as a v0.3.0 feature. This contradictory status misleads users about which version supports the functionality and leaves the documentation inconsistent with the Gameplane authentication implementation.

## Fix Focus Areas
- src/content/docs/sign-in-recovery.mdx[49-53]

## Recommended Fix
Remove the obsolete `Coming in v0.3.0` OIDC group-mapping callout, or rewrite it to describe only Helm-based seeding of mappings as the v0.3.0 feature.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

No findings for this group

Context sources

✅ Cross-repo context — repo relationships

  Explored: repo: ValgulNecron/Gameplane (branch: chore/bump-website-heroui, sha: 85487bb2) — View relationship

Review mode: 🚀 Fast: This is a localized, three-file documentation-only correction with no runtime or configuration behavior changes.

Tip of the day

💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗