csharp-oni-runtime

name	csharp-oni-runtime
description	Strict C# development standards for ONI runtime/mod backend code. Use when implementing or refactoring ONI C# HTTP/runtime control paths, especially for endpoint design, hot-reload boundaries, strict schema handling, exception-first logic, and removal of fallback/alias behavior.

C# ONI Runtime Strict Rules

Goal

Implement ONI C# runtime/server code that is deterministic, strict, and production-usable for live game control.

Non-Negotiable Requirements

• Use exception-first flow end to end; do not use silent fallback behavior.
• Reject invalid or incomplete input explicitly; fail fast with clear errors.
• Use canonical field names only; do not support alias keys.
• Remove compatibility chains like a ?? b ?? c for request argument/member resolution.
• Avoid helper naming patterns that hide failure (Try* wrappers for business logic).
• Execute actions immediately through dedicated HTTP endpoints.
• Do not re-introduce generic action queues or deferred plan execution.

API Design Requirements

• Prefer dedicated endpoints per operation (/build, /dig, /deconstruct, /research, /speed, /pause, /priorities, etc.).
• Keep speed/pause as standalone endpoints, not embedded in generic action envelopes.
• Keep request/response contracts explicit and stable; define JSON schema and examples when needed.

Runtime and Data Requirements

• Read real game/runtime data; do not hardcode gameplay values outside mock/testing code.
• Remove fake mutation layers and fallback state synthesis.
• Keep hot-reload support practical for mod/runtime iteration, but do not compromise correctness.

Refactoring Rules

• Prefer concrete typed DTOs for request payloads over field-by-field ad hoc parsing.
• Keep EntryPoint focused; split responsibilities into dedicated files/classes.
• Avoid partial class where it obscures boundaries or hot-reload behavior.
• Remove dead orchestration methods (plan/queue executors) when endpoints are authoritative.

Validation Workflow

• Build after each meaningful refactor.
• Run tests after behavioral changes.
• Confirm endpoint behavior with real ONI runtime data paths, not synthetic fallback paths.

Response Style for This Skill

• Be direct and implementation-first.
• If behavior is unsupported, raise explicit errors instead of degrading silently.
• Prefer minimal, reviewable patches that preserve strictness.