jpmschweitzer/settled-reach
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(meta): D-254 SS3 — companion is a generic implant host; available_in_companion opt-out flag (Jeroen, mid-implementation)

Browse Source 
Future implant apps/screens automatically extend the external app; per-app manifest bool (default true) locks out gameplay-dependent apps; in-game implant ignores the flag. Jeroen's suggested name availableInAtlasApp recorded with the rename rationale.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
jpmschweitzer
2026-07-17 08:10:08 +02:00
co-authored by Claude Fable 5
parent b57805d0c6
commit d370ca6044
1 changed files with 2 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
governance/decisions/architecture.md
+2
View File
@@ -2103,6 +2103,8 @@ Technical foundation decisions that constrain implementation: engine, client-ser
5. `ImplantRegistry.instantiate_all(self)` — the same call `hud.gd._ready()` makes in the normal game — populates every installed implant app (Atlas + Economics both come along for free; Economics degrades gracefully since it's reachable but not the entry point, and read-only holds for it too automatically, since it rides the same Reader connection).
6. The Atlas's own `KEY_M`/`KEY_ESCAPE` handling (`atlas_app.gd`) currently calls `HudGroups.close_app()` on M/Escape from the top-level "reach" screen, which would leave the standalone window showing a blank Control with nothing to fall back to (there is no gameplay layer). Two options, left for the implementation ticket to pick: (a) `atlas_standalone.gd` intercepts the close and either quits the app or re-opens `implant/map` instead of demoting to a nonexistent gameplay layer, or (b) `atlas_app.gd` gains a `standalone_mode` flag that no-ops the close-to-gameplay branch. **(a)** is recommended — it does not touch `atlas_app.gd` at all, keeping the in-game and standalone Atlas byte-identical.
**Automatic extension + lockout flag (added mid-implementation per Jeroen, 2026-07-17):** the companion is a generic implant HOST, not an Atlas launcher — every implant app registered with `ImplantRegistry` is automatically available in the standalone shell, so future Atlas screens and future implant apps (the `implant/browser` app of §4, wiki/GTTR, economics dashboards, whatever comes) extend the external app with **zero companion-side work**. The lockout is the exception, not the rule: the implant app manifest (the `app.tres` resource each app already carries) gains `available_in_companion: bool = true` — an **opt-out** flag set `false` only for apps that structurally cannot work without a playing character/gameplay context. The standalone shell consults the flag at `instantiate_all`/app-open time (flagged-off apps are not instantiated and not offered in any app-switching surface); the **in-game implant ignores the flag entirely** — it exists only for the companion host. Apps needing finer granularity may gate individual screens on a standalone-mode query, but v1 needs only the app-level flag (both current apps — Atlas and Economics — are read-only-safe and stay `true`). Naming note: Jeroen's suggested name was `availableInAtlasApp`; recorded here as `available_in_companion` (snake_case per GDScript convention, and "companion" avoids colliding with `client/ui/implant/apps/atlas/` — the Atlas is itself one of the hosted apps, not the host).
**Window title/branding:** `atlas_standalone.tscn` sets its own window title via `DisplayServer.window_set_title()` in `_ready()` (e.g. "The Settled Reach — Atlas"), since `project.godot`'s shared `config/name` would otherwise make the standalone window read identically to the main game window in the taskbar/alt-tab — a second-monitor companion needs to be visually distinguishable at a glance. This is the only project-level Godot config touched; no `run/main_scene` override, no export preset changes in this ticket.
**Dev launch (un-exported):** `make atlas` runs `$(GODOT) --path client client/scenes/atlas_standalone.tscn` — Godot accepts an explicit scene path as a positional argument, overriding `run/main_scene` for that invocation only (the same mechanism `godot --path client -s res://tests/visual_capture.gd` already uses to run a non-default entry script). No `project.godot` edit needed; `run/main_scene` stays `main_menu.tscn` for the normal game. Since discovery (§1) is auto-attach-else-spawn at runtime, `make atlas` itself stays a single simple target — it does not need `make game`'s explicit background-`cargo run` + `sleep` + launch + `make stop` choreography, because `atlas_standalone.gd` owns its own spawn decision and child-process lifecycle internally (§1/§2). `make atlas` is just: build client, launch it.