-
Notifications
You must be signed in to change notification settings - Fork 0
Roadmap
The authoritative, full-length roadmap is
ARMA3_EXILE_CODEX\ROADMAP.md in the Obsidian vault - it carries the reasoning,
the struck-through wrong turns and the measurements. This page is the summary
you can link to.
2026-08-07 planning sync: GitHub now carries the current planning backlog from the XCSV GUARD / Gauntlet design session. The desktop/Obsidian roadmap remains authoritative and is pending manual reconciliation by Architect. Until that happens, any disagreement between this page and the desktop roadmap is an explicit planning-state divergence, not evidence that the desktop copy has already been updated.
Guiding rule: performance before content, always. Adding content to a server running at 22 FPS makes it worse, not better.
| phase | outcome |
|---|---|
| 0 - Stabilise | 219-restart loop resolved (corrupt PBO entry paths); 419 MB RPT stopped (x64 + extDB2); credentials rotated across five locations; reboot survival |
| 1.5 - Lootbox deadlock |
LB_WaitSysBusy 40 -> 15. Map population 66/103 -> 103/103. Server FPS 22 -> 46. The largest single win so far |
| 2.3 - FuMS on HC | FuMS installed on the live server and HC; active first slice is PlayerWatch plus Tanoa CommsAlpha, Help_Helo, and Georgetown. A3XAI and FuMS both hand off to HC owner 4; FuMS heartbeat started |
| 2.4 - x64/extDB3 production | production migrated to arma3server_x64.exe + extDB3 with -maxMem=12288; old extDB2 and 32-bit rollback artifacts removed by policy |
| 2.5 - Memory/RAG first slice | vault/wiki memory index generated by D:\XCSV\tools\build-memory-index.ps1; public docs now include Memory Index
|
| 2.6 - RAG pulse in GUARD | local RAG search now writes D:\CAGE\xcsv-rag\last-query.json; GUARD top bar shows a rag chip and pulses after searches |
| 2.7 - GUARD database views | Database tab now has grouped read-only presets for overview, players, territories, vehicles, and economy, using extDB3 config |
| 2.8 - GUARD release/capture subsystem |
deploy.ps1 now owns build numbering, current-release manifests, live Desktop deployment and taskbar shortcut cleanup; capture.ps1 can capture named tabs across responsive viewports |
| 4.7 - Out-of-band alerts & noise filter | disconnect notifications, configurable scheduled restart alerts, and central benign RPT error filtering (is_known_benign) added to GUARD |
| 10.1.2 - Player Inspector (App20) | admin XM8 App20 for account details (UID, respect, K/D, locker, session) + territory flag membership, plus custom extraApps_onOpen grid override |
| 7.5 - Stack orchestration | one button starts database -> integrity gate -> server -> headless client -> local model, and one stops them cleanly in reverse |
| 8 - Mistake prevention |
CLAUDE.md at each project root, doctor.ps1 with executable assertions, this wiki, the Lessons page |
Also fixed along the way: the invisible safezone ring, a dead Exile_Scavenge
caused by a lost CfgExileCustomCode merge, database query defects, launcher
landmines, and several supervision/verification gaps.
GUARD operator views. The GUARD refactor is committed and running. AI/FuMS live-log detection and read-only database probing exist. The first richer AI slice parses A3XAI source counts, server-vs-HC ownership, FuMS active mission names, completed mission count, and FuMS object transfer totals. The Database tab has grouped read-only operator presets across players, territories, vehicles, and economy.
Headless-client hardening. HC joins and A3XAI/FuMS handoff are verified after the 2026-08-05 mission header fix. Keep watching owner 4 heartbeat and AI ownership under real player load.
infiSTAR cloud. Local infiSTAR logs work, but hosted panel uploads still return 403. Treat local logs as the audit trail until that account/API issue is solved.
Version control for every artifact. GUARD has the first slice: crate version + local build number, archive\CURRENT.json, SHA256, source commit, single live Desktop exe, and taskbar shortcut ownership. Next apply the same pattern to addons, scripts, mods and packed PBOs so stale builds cannot silently duplicate.
The next major development programme is no longer just a list of isolated GUARD tabs or addons. It is a coordinated refoundation across AI development workflow, GUARD reliability, operator UX, server instrumentation, performance engineering, deployment identity, and curated player systems. Detailed design notes live in XCSV GUARD Development Plan.
Build one canonical, versioned development protocol and expose it through thin adapters for Claude Code, OpenCode, Antigravity, and development-local LLMs. Do not maintain independent drifting copies of the same philosophy.
Core flow:
TARGET LOCK -> RECON -> DECOMPOSE -> WORKERS -> ADVERSARIAL CRITICS -> INTEGRATION -> MEASUREMENT -> EVIDENCE -> VERDICT
Risk-scaled depth:
- G0 documentation / trivial local work
- G1 isolated implementation: worker + critic
- G2 cross-component work: specialists + critic + integration review
- G3 production-affecting Arma/Exile change: recon + specialists + security/performance review + rollback + runtime evidence
- G4 architecture, persistence, database mutation, BattlEye/security or deployment infrastructure: full Gauntlet and independent verification
Rules:
- worker may not self-certify
- confidence is not proof
- separate EVIDENCED / INFERRED / UNKNOWN
- loop only on concrete failure or unresolved requirement
- failed experiments and refuted hypotheses become durable project knowledge
- anything deterministic/checkable should migrate into executable assertions rather than relying on prompt memory
Primary invariant:
Closing XCSV GUARD must never erase operational truth. Reopening it must reconstruct the same server state from authoritative sources and continue supervising it without launching duplicates, resetting schedules, fabricating health, or generating false incidents.
State must be classified explicitly:
- Durable state - settings, UI preferences, absolute restart deadline, warnings already issued, saved DB queries/history, acknowledged incidents, operator context.
- Reconstructable state - server/HC/model/MariaDB process state, PIDs, memory, RCon, players, RPT, PBO integrity, missions, AI ownership, DB contents, RAG state. Re-probe; do not persist as truth.
- Ephemeral state - animation/interpolation/transient UI details. Discard safely.
Planned reliability work:
- startup reconciliation phase before declaring GUARD ready
- attach/reconcile with already-running server/HC/model/database
- make closing GUARD distinct from Stop Everything
- persist absolute restart deadlines rather than process-local
Instantschedules - persist warning/restart intent enough to avoid duplicate warnings and schedule reset after relaunch
- auto-connect and auto-reconnect RCon with bounded backoff
- recover from MariaDB, RCon, HC, model, infiSTAR-log and RPT-rollover failures without restarting GUARD
- remove dependence on a live
Childhandle as the sole source of server identity; treat OS/process discovery as an authoritative recovery path - no false crash incident when GUARD itself restarts while the server remains healthy
- no duplicate server process launch during reconciliation
Introduce a stable service/backplane layer so tabs render backend contracts rather than individually knowing how RCon, logs, DB and process discovery work.
Conceptual flow:
Collectors -> Evidence/Observations -> Derived State/Services -> UI
Candidate services:
- Process / Stack Service
- RCon / Player Service
- Telemetry Service
- Mission / AI Service
- Database Service
- Integrity / Artifact Service
- Notification Service
- Docs / RAG Service
Every observation should eventually be able to carry source, timestamp, freshness/age, severity, raw-evidence reference and proof state.
Every GUARD tab must define:
- required data
- authoritative source(s)
- freshness expectation
- healthy/degraded/stale/offline/error behavior
- permitted actions
- proof that an action reached its backend
Standard visual states:
LOADING / HEALTHY / DEGRADED / STALE / OFFLINE / ERROR
A tab must never silently show blank data or convert UNKNOWN into zero.
Build mocked/tab-level contract scenarios and separate live integration checks. Add a GUARD diagnostics screen that proves GUARD itself is correctly wired before GUARD claims the server is healthy.
Examples:
- Players/RCon
- Players/infiSTAR
- Database/MariaDB
- AI/server RPT
- AI/HC RPT
- Metrics/sysinfo
- Metrics/infiSTAR
- Integrity/PBO scanner
- Docs/wiki
- RAG
- Notifications
Formal restart-survival test:
- server + HC + MariaDB + model running
- RCon connected
- restart deadline established
- close GUARD
- leave GUARD closed
- reopen GUARD
- prove same server PID rediscovered, HC/model/DB rediscovered, RCon reconnects, current RPT/missions/players rebuild, deadline remains unchanged, warnings are not duplicated, PBOs are rescanned, operator UI context returns, no false crash is recorded, and no duplicate server launches
Do reliability work before cosmetic polish, then refactor the shell around operator tasks.
Proposed navigation groups:
- OPERATE: Overview, Players, Restarts
- INTELLIGENCE: AI / Missions, Metrics, future map
- DIAGNOSTICS: Integrity, Server Log, Consoles, infiSTAR
- ADMIN / DATA: Database, RCon
- KNOWLEDGE: Docs / RAG
- SYSTEM: Settings / Diagnostics
Overview should answer in seconds:
- Is the server healthy?
- Are players online?
- What needs attention?
- What happens next?
Planned overview structure:
- global stack health strip: server / HC / DB / RCon / model / RAG / integrity
- core KPIs: FPS / players / memory / world load
- Needs Attention area containing only actionable warnings/errors
- active missions and AI ownership
- joins/departures
- restart deadline
- recent operational timeline
Global status chips should be clickable and route to the owning tab. Consider a Ctrl+K command/search palette as GUARD grows.
Destructive operations should follow a consistent consequence-based confirmation model: immediate for low-risk actions, one confirmation for medium-risk actions, explicit target/consequence confirmation for permanent bans, force-stop, Stop Everything and any future DB write path.
Add a local GUARD telemetry/history store separate from the Exile gameplay database. Purpose: reconstruct incidents and compare before/after changes.
Desired historical questions:
- what was FPS before a crash?
- what changed before degradation began?
- what were AI group counts and ownership?
- what was object count and RPT growth?
- which PBO/build was deployed?
- was HC handoff healthy?
Operational phases should be understood explicitly: BOOTING / POPULATING / SETTLING / STEADY STATE / DEGRADED / RESTARTING. Performance comparisons should not be accepted while the world is still changing.
Turn changes into experiments:
Hypothesis -> Baseline -> Bounded Change -> Gauntlet -> Runtime Observation -> Result -> Durable Memory
Integrate Bohemia profiling/slow-frame capture as an explicit maintenance tool rather than guessing from FPS alone.
Define subsystem budgets instead of adding features until aggregate cost becomes invisible.
Track at least:
- AI: A3XAI / DMS / FuMS / Occupation group counts, server-owned vs HC-owned
- World: vehicles, constructions, loot, mission objects, bodies, containers, temporary objects
- Scheduler: recurring tasks, frequency, origin, approximate runtime
- Network: high-frequency messages/remote execution/public variables
- Database: query frequency, latency, rows touched, index expectations
Do not add HC2 merely because it exists as an option. First measure HC saturation, group ownership and server-side AI headroom; add HC2 only when evidence says it is the correct scaling move.
Move the GUARD Database tab from raw text output toward structured columns, sortable/searchable tables, saved views and recent query history.
Longer term, introduce operator objects:
- Player - account, current character, connections, deaths, territories, vehicles, market state, moderation history
- Territory - owner, members, rights, level, protection/decay status, constructions, containers, vehicles
- Vehicle - owner, location, damage, fuel, territory, last update, persistence state
Player Inspector should become a central GUARD concept, not only an in-game XM8 app.
Create a chronological Incident Mode that links process exits, FPS/RPT anomalies, mission/HC state, PBO identity, recent deployment state and relevant logs.
Create a read-only Tanoa operations map showing eligible data such as active missions, AI concentration/ownership, helicopter crashes, loot/world events, travelling trader, territories and other server event markers where source data exists.
Extend GUARD release identity to every operational artifact:
- mission PBO
- server PBOs
- custom addons
- scripts
- BattlEye filters
- extDB query files
- deployment bundles
Desired fields: artifact ID, version, source commit, build timestamp, SHA256, deployed SHA256 and status.
Build a deterministic Documentation / State Drift Auditor comparing roadmap Done/Next state, XM8 shipped/backlog state, README counts, submodule revisions, release manifests and eventually deployed hashes. Current documentation drift proves this is needed.
Do not respond to a large existing addon estate by blindly adding more mods. Prefer integration, progression and coherence.
High-value backlog:
- Territory Manager
- Contract / Job Board: salvage, delivery, recovery, smuggling, reconnaissance, bounties, trader resupply, supply recovery, faction work
- Bounty system
- Turn existing faction standing into selective gameplay consequences: contracts, trader access, cosmetics, information, discounts, radio responses; avoid crude combat buffs
- Server Chronicle of meaningful persistent world events
- asynchronous message board/community features
- choreographed rotating world events connecting existing storms, FuMS/DMS, crashes, traders and faction radio
- investigate ZCP/Capture Points before another heavy AI framework
Keep Zombies and Vcom parked until HC/AI performance evidence changes the decision.
- XCSV Gauntlet Protocol architecture
- Canonical AI rule distribution + drift detection
- GUARD state ownership model
- startup reconciliation and process reattachment
- persistent absolute restart scheduling
- RCon auto-reconnect
- GUARD backend health registry/backplane
- tab backend contracts and tests
- GUARD self-diagnostics
- shell/navigation redesign
- Overview command-center redesign
- structured database/browser work
- historical telemetry + experiment framework
- Incident Mode
- live mission/AI operations map
- estate-wide Artifact Registry
- curated player systems / progression
| Richer GUARD AI / mission tab | deeper per-mission drilldowns and alerts, now under the broader tab-contract/backplane work |
| Richer GUARD database console | structured tables and saved/recent query history, now part of the operator-object/data-browser direction |
| BattlEye enforcement | 8 of 51 script rules enforcing; triage remaining exceptions before raising more rules |
| infiSTAR cloud 403 | determine whether account/licence/API configuration is responsible and preserve local logs meanwhile |
Player chat with AI only if strictly isolated and non-load-bearing; lore/world voice; second headless client only when measured need exists; CI on repos; deeper RAG/search over the estate.
Zombies, VcomAI. Both are large simulation costs on a single-threaded server. Not until measured HC/server headroom supports the decision.