docs(decisions): D-141 PlatformInfo OS abstraction, resolve Q-059
D-141: client-side PlatformInfo autoload centralizing all OS queries. Q-059: resolved — full interface scope (23 properties, 7 categories). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Claude Opus 4.6
@@ -482,6 +482,14 @@ Technical foundation decisions that constrain implementation: engine, client-ser
|
||||
- **Dissent:** None
|
||||
- **Cross-reference:** [D-114](scope.md#d-114-v02-proof-of-life--generator--graphics-not-hand-built-slice) (generator proof-of-life), [D-119](scope.md#d-119-generator-spike-confirmed-for-sprint-25--critical-path) (Sprint 25 generator spike)
|
||||
|
||||
### D-141: PlatformInfo — client-side OS abstraction autoload
|
||||
- **Date:** 2026-03-13
|
||||
- **Decision:** All OS-dependent queries on the client are centralized in a single `PlatformInfo` autoload (`client/scripts/autoloads/platform_info.gd`), registered first in the autoload order. Individual systems (HardwareDetector, voice pipeline, settings UI) consume PlatformInfo properties and signals — they never call `OS.*` directly. PlatformInfo owns: power state (with `PowerProfile` enum: FULL, BATTERY, POWER_SAVER), memory queries, platform identity, and platform-dependent file paths. Power state is polled on a 30-second timer with a `power_profile_changed` signal; memory is refreshed on demand. The `PowerProfile` enum is the abstraction seam for future power-saver detection (GDExtension) without consumer code changes. PlatformInfo is **client-side only** — the client never relies on the server for hardware info, because the server may not be on the same hardware in multiplayer/remote hosting scenarios. Each side detects independently.
|
||||
- **Rationale:** OS calls were scattered across HardwareDetector, AiDialogueDetector (duplicate), and SimBridge. A central abstraction prevents duplication, provides a single seam for platform-specific behavior, and keeps the client self-sufficient per D-010 (information boundaries) and future multiplayer readiness.
|
||||
- **Raised by:** Team Leader (Jeroen)
|
||||
- **Dissent:** Centralized server detection was considered and rejected — server may not share hardware with client in future multiplayer scenarios.
|
||||
- **Cross-reference:** [D-138](content.md#d-138-llm-re-voicing-pipeline-for-npc-voice) (hardware detection for voice pipeline), [D-010](#d-010) (information boundaries), [Q-059](questions-architecture.md#q-059-platforminfo-full-interface-scope) (full interface scope — open)
|
||||
|
||||
---
|
||||
|
||||
*38 decisions. Last updated: 2026-03-05 (D-133–D-137 added — Where's the Fun? Workshop)*
|
||||
*39 decisions. Last updated: 2026-03-13 (D-141 added — PlatformInfo OS abstraction)*
|
||||
|
||||
@@ -83,6 +83,15 @@ Technical foundation questions: engine, protocols, data structures, performance,
|
||||
- **Source:** Generator Architecture Workshop (#562)
|
||||
- **Assigned to:** Tyre + Miri
|
||||
|
||||
### Q-059: PlatformInfo full interface scope
|
||||
- **Status:** Resolved → [D-141](architecture.md#d-141-platforminfo--client-side-os-abstraction-autoload)
|
||||
- **Question:** What properties should `PlatformInfo` expose beyond power state, memory, and file paths?
|
||||
- **Resolution:** 23 properties across 7 categories (power, memory, CPU, GPU, platform identity, display, locale), 1 signal (`power_profile_changed`), 2 methods (`refresh_memory`, `get_diagnostics`). Researched Unity SystemInfo, Unreal FPlatformMisc, SDL3. Skip: GPU VRAM (not available in Godot), CPU frequency, audio devices (AudioManager owns that), network connectivity (single-player), VM detection. Add properties only when a ticket needs them — no stubs. `get_diagnostics()` returns flat Dictionary for bug reports.
|
||||
- **Date raised:** 2026-03-13
|
||||
- **Date resolved:** 2026-03-13
|
||||
- **Assigned to:** Tyre
|
||||
- **Source:** Sprint 26 client work (#646, #659)
|
||||
|
||||
---
|
||||
|
||||
*12 questions (6 resolved, 1 partially resolved, 5 open). Last updated: 2026-02-28.*
|
||||
*13 questions (7 resolved, 1 partially resolved, 5 open). Last updated: 2026-03-13.*
|
||||
|
||||
@@ -6,7 +6,7 @@ Tracked questions awaiting discussion or resolution. Split by domain, mirroring
|
||||
|
||||
| File | Domain | Questions |
|
||||
|------|--------|-----------|
|
||||
| [questions-architecture.md](questions-architecture.md) | Technical foundation | Q-001, Q-006, Q-009, Q-018, Q-019, Q-020, Q-021, Q-022, Q-023, Q-029, Q-030, Q-046 |
|
||||
| [questions-architecture.md](questions-architecture.md) | Technical foundation | Q-001, Q-006, Q-009, Q-018, Q-019, Q-020, Q-021, Q-022, Q-023, Q-029, Q-030, Q-046, Q-059 |
|
||||
| [questions-perception.md](questions-perception.md) | Player observation | Q-003, Q-014, Q-016, Q-024, Q-025, Q-026, Q-051, Q-053, Q-054 |
|
||||
| [questions-content.md](questions-content.md) | Narrative, NPCs, setting | Q-010, Q-012, Q-013, Q-015, Q-017, Q-028, Q-031, Q-033, Q-040, Q-041, Q-042, Q-043, Q-044, Q-045, Q-047, Q-048, Q-049, Q-050, Q-052, Q-056, Q-057 |
|
||||
| [questions-scope.md](questions-scope.md) | Game concept, prototype | Q-002, Q-004, Q-005, Q-007, Q-008, Q-011, Q-027, Q-032, Q-034, Q-035, Q-036, Q-037, Q-038, Q-039, Q-058 |
|
||||
@@ -15,11 +15,11 @@ Tracked questions awaiting discussion or resolution. Split by domain, mirroring
|
||||
|
||||
| Domain | Total | Resolved | Partial | Open |
|
||||
|--------|-------|----------|---------|------|
|
||||
| Architecture | 12 | 6 | 1 | 5 |
|
||||
| Architecture | 13 | 7 | 1 | 5 |
|
||||
| Perception | 9 | 5 | 1 | 3 |
|
||||
| Content | 21 | 5 | 2 | 14 |
|
||||
| Scope | 14 | 1 | 3 | 10 |
|
||||
| **Total** | **56** | **17** | **7** | **32** |
|
||||
| **Total** | **57** | **18** | **7** | **32** |
|
||||
|
||||
*Updated 2026-03-05: Q-011 resolved (D-117/D-115/D-122), Q-034 partially resolved (D-117), Q-037 partially resolved (D-119), Q-033 partially resolved/reframed (D-122) — Where's the Fun? Workshop*
|
||||
|
||||
|
||||
Reference in New Issue
Block a user