| 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.
