HeiKyu/Rendezvous
2
0
Fork 0
Code Issues 27 Pull Requests Actions Packages Projects Releases Wiki Activity

Publish TestClient workflows, integration guides, and operator runbooks #20

New Issue
Open
opened 2026-07-15 10:04:30 +02:00 by Kyuubi · 2 comments
Kyuubi commented 2026-07-15 10:04:30 +02:00
Owner
Copy Link
Copy Source

Parent: #1
Depends on: #17, #19, #25

Outcome

Make the service usable and diagnosable without requiring either game as undocumented reference code.

Scope

  • Use the thin TestClient as the executable host/browser/join reference and document its interactive, scripted, JSON-output, exit-code, and diagnostic workflows.
  • Add focused SDK snippets only where they explain integration seams not visible from TestClient usage; do not create competing sample implementations.
  • Document local development, game provisioning, metadata policy, key rotation, package use, API/SDK versioning, and secure deployment.
  • Add troubleshooting that distinguishes authentication, compatibility, directory, host-presence, mediation, NAT, and host-admission failures.
  • Add operator runbooks for abuse spikes, key compromise, revocation, restart, rollback, saturation, privacy incident, and dependency upgrade.
  • State traversal limitations and non-goals prominently.
  • Clarify that polished server-browser UI belongs in each game repository.

Acceptance criteria

  • A new consumer can start the service, publish, browse, authorize, punch, connect, and observe failure using only documented steps.
  • TestClient and all SDK snippets reuse the same LiteNetLib socket for mediation and gameplay.
  • TestClient examples and snippets contain no reusable production credentials or insecure bypass defaults.
  • Runbooks contain concrete detection, containment, recovery, and verification steps.
  • Documentation matches the generated OpenAPI and released SDK.
  • Relay, accounts, matchmaking, gameplay authority, and guaranteed traversal are not implied.
Parent: #1 Depends on: #17, #19, #25 ## Outcome Make the service usable and diagnosable without requiring either game as undocumented reference code. ## Scope - Use the thin TestClient as the executable host/browser/join reference and document its interactive, scripted, JSON-output, exit-code, and diagnostic workflows. - Add focused SDK snippets only where they explain integration seams not visible from TestClient usage; do not create competing sample implementations. - Document local development, game provisioning, metadata policy, key rotation, package use, API/SDK versioning, and secure deployment. - Add troubleshooting that distinguishes authentication, compatibility, directory, host-presence, mediation, NAT, and host-admission failures. - Add operator runbooks for abuse spikes, key compromise, revocation, restart, rollback, saturation, privacy incident, and dependency upgrade. - State traversal limitations and non-goals prominently. - Clarify that polished server-browser UI belongs in each game repository. ## Acceptance criteria - A new consumer can start the service, publish, browse, authorize, punch, connect, and observe failure using only documented steps. - TestClient and all SDK snippets reuse the same LiteNetLib socket for mediation and gameplay. - TestClient examples and snippets contain no reusable production credentials or insecure bypass defaults. - Runbooks contain concrete detection, containment, recovery, and verification steps. - Documentation matches the generated OpenAPI and released SDK. - Relay, accounts, matchmaking, gameplay authority, and guaranteed traversal are not implied.
Kyuubi changed title from Publish reference host/browser/client samples and operator runbooks to Publish TestClient workflows, integration guides, and operator runbooks 2026-07-15 10:07:10 +02:00
Kyuubi added reference codex/issue-20-guides-runbooks 2026-07-16 17:52:48 +02:00
Kyuubi self-assigned this 2026-07-16 17:52:48 +02:00
Kyuubi commented 2026-07-16 17:53:03 +02:00
Author
Owner
Copy Link
Copy Source

Started on codex/issue-20-guides-runbooks, stacked on verified issue #19 commit cc5793f. I am grounding the documentation and runbooks in the existing TestClient/OpenAPI/SDK behavior, then will verify every documented workflow and failure classification before pushing evidence.

Started on `codex/issue-20-guides-runbooks`, stacked on verified issue #19 commit `cc5793f`. I am grounding the documentation and runbooks in the existing TestClient/OpenAPI/SDK behavior, then will verify every documented workflow and failure classification before pushing evidence.
Kyuubi commented 2026-07-16 18:25:38 +02:00
Author
Owner
Copy Link
Copy Source

Implementation is complete on codex/issue-20-guides-runbooks at 7fb8505 (stacked on the verified #19 release branch).

Evidence:

  • Added an executable clean-checkout TestClient path for service startup, fixed-scope local credential minting, publish/browse/authorize/punch/connect/direct traffic, stable JSON/exit automation, and a deliberate protocol-incompatibility failure.
  • Added focused same-socket SDK/package/provisioning/metadata/rotation/versioning/deployment guidance and concrete detect/contain/recover/verify runbooks for all requested incident classes.
  • Added documentation contract gates against released OpenAPI methods/request bodies and the package/framework/LiteNetLib/wire compatibility matrix.
  • Removed duplicated local minting and eliminated signing-key material from child process arguments; the helper is fixed to the disposable Compose scope and rejects unsafe secret boundaries.
  • Adversarial branch audit found 10 actionable documentation/test defects; all were fixed, none deferred.
  • dotnet format passed; Debug and Release builds passed; Debug 296/296 and Release 296/296 tests passed with 0 skipped/failed.
  • Real hardened Compose verification passed live/ready, publish, compatible browse, protocol-999 count 0 + exit 11, authenticated UDP mediation, direct connection/traffic, outcome report, deregistration, and cleanup.

The issue remains open only until the stacked roadmap branches are landed/reconciled.

Implementation is complete on `codex/issue-20-guides-runbooks` at `7fb8505` (stacked on the verified #19 release branch). Evidence: - Added an executable clean-checkout TestClient path for service startup, fixed-scope local credential minting, publish/browse/authorize/punch/connect/direct traffic, stable JSON/exit automation, and a deliberate protocol-incompatibility failure. - Added focused same-socket SDK/package/provisioning/metadata/rotation/versioning/deployment guidance and concrete detect/contain/recover/verify runbooks for all requested incident classes. - Added documentation contract gates against released OpenAPI methods/request bodies and the package/framework/LiteNetLib/wire compatibility matrix. - Removed duplicated local minting and eliminated signing-key material from child process arguments; the helper is fixed to the disposable Compose scope and rejects unsafe secret boundaries. - Adversarial branch audit found 10 actionable documentation/test defects; all were fixed, none deferred. - `dotnet format` passed; Debug and Release builds passed; Debug 296/296 and Release 296/296 tests passed with 0 skipped/failed. - Real hardened Compose verification passed live/ready, publish, compatible browse, protocol-999 count 0 + exit 11, authenticated UDP mediation, direct connection/traffic, outcome report, deregistration, and cleanup. The issue remains open only until the stacked roadmap branches are landed/reconciled.
Sign in to join this conversation.
codex/issue-20-guides-runbooks
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Kyuubi schmidt.florian (Florian Schmidt)
No Assignees Kyuubi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: HeiKyu/Rendezvous#20
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?