-
Notifications
You must be signed in to change notification settings - Fork 0
AI Start Here
XCSV-AI-CONTRACT: 1.0.0
This is the canonical operating contract for AI-assisted work across the XCSV Arma 3 Exile estate.
Core rule: Never begin from what the roadmap says needs building. Begin by proving what remains to be built.
The desktop C:\Users\Architect\Desktop\ARMA3_EXILE_CODEX\ROADMAP.md remains the authoritative full roadmap for priority, decisions, sequencing, refuted hypotheses and live operating memory. This GitHub document defines how an AI must interpret and reconcile that roadmap before acting.
When Architect says any equivalent of:
- read the GitHub
- read GitHub
- read the roadmap
- get caught up
- resume XCSV
- see what is next
enter READ_ONLY_BOOTSTRAP first.
Do not implement, repair, deploy, commit, pull over dirty work, repack PBOs, change the database, change BattlEye, or mutate the live server during bootstrap unless Architect explicitly combines the request with authority to proceed.
- Read this contract completely.
- Read the local authoritative desktop
ROADMAP.mdif available. - Run
D:\XCSV\tools\ai-reconcile.ps1and inspect every repo it reports. - Use
D:\XCSV\tools\search-rag.ps1 -Query "<target terms>"before broad filesystem archaeology. - Inspect the relevant local working tree before trusting GitHub: current branch,
git status, current commit, uncommitted changes and relevant target files. - Compare the local commit to the remote branch without assuming GitHub is newer or authoritative for live state.
- Inspect recent relevant commits and existing implementation before proposing new code.
- If the claim is operational, inspect the relevant live evidence: deployed artifact, RPT/HC RPT, database query, process state, GUARD state, BattlEye/infiSTAR logs or other source of truth.
- Classify the requested/next roadmap item using the reconciliation states below.
- Identify only the remaining delta.
- Select the Gauntlet risk level.
- Report a concise XCSV BOOTSTRAP REPORT before implementation.
Different sources answer different questions. Do not flatten them into one truth source.
| source | authority |
|---|---|
Desktop ROADMAP.md
|
priority, intent, decisions, sequence, rejected/refuted paths |
| Local working tree | what code/files actually exist on this machine now |
| Local git history | what has been committed locally |
| GitHub remote | what has been published/pushed |
| Hub submodule pointers | which member-repo commits the hub currently references |
| Live server/deployed artifacts | what is actually deployed/running |
| Runtime evidence | whether the deployed behavior actually worked |
| Wiki/README/site | durable explanation and public/operator navigation; not proof by itself |
If these disagree, the disagreement is the finding. Do not silently choose the most convenient source.
Before implementation, assign exactly one state to the target:
Equivalent functionality exists and the required verification evidence exists.
Action: do not rebuild. Correct stale roadmap/wiki/issues if needed.
Implementation appears to exist, but required test/runtime/deployment proof is missing.
Action: do not rebuild. Verify the existing implementation.
Some required behavior exists.
Action: identify and implement only the missing delta. Do not create a parallel subsystem.
Roadmap/design exists but implementation does not.
Action: implementation may proceed after Target Lock and the appropriate Gauntlet.
Roadmap, local source, GitHub, submodules, docs or runtime evidence disagree materially.
Action: stop implementation, record the conflict and resolve authority/state first.
A required dependency, permission, environment, evidence source or decision is unavailable.
Action: preserve what is known and report the blocker without fabricating progress.
After reconciliation ask:
What is the smallest remaining delta between the target behavior and what already exists?
Do not restart from a blank-sheet design when 70-90% of the target already exists. Extend, repair, verify or document the existing path unless Architect explicitly authorizes replacement.
This is especially important for Exile because duplicate CfgExileCustomCode registrations, duplicate schedulers, duplicate network handlers and parallel mission systems can actively break production.
Keep it short and factual:
XCSV BOOTSTRAP REPORT
Contract: XCSV-AI-CONTRACT 1.0.0
Mode: READ_ONLY_BOOTSTRAP
Target: <roadmap item or requested area>
Roadmap: <what it says>
RAG/history: <relevant prior result/refuted hypotheses>
Local repo: <branch / clean-dirty / commit>
GitHub: <same commit / mismatch / unknown>
Live evidence: <verified / unavailable / not required>
Classification: VERIFIED_DONE | PRESENT_UNVERIFIED | PARTIAL | PLANNED_ONLY | STALE_OR_CONFLICTED | BLOCKED
Remaining delta: <smallest actual missing work>
Gauntlet: G0 | G1 | G2 | G3 | G4
Conflicts/UNKNOWN: <only material items>
If Architect only said read the GitHub, stop after the bootstrap report and wait for the next instruction.
Reconciliation happens before the Gauntlet.
READ -> RECONCILE -> CLASSIFY -> DELTA -> TARGET LOCK -> GAUNTLET -> VERIFY -> DURABLE SYNC
Canonical Gauntlet flow:
TARGET LOCK -> RECON -> DECOMPOSE -> WORKERS -> ADVERSARIAL CRITICS -> INTEGRATION -> MEASUREMENT -> EVIDENCE -> VERDICT
Risk levels:
- G0 documentation/trivial local work
- G1 isolated implementation; worker + critic
- G2 cross-component work; specialists + critic + integration review
- G3 production-affecting Arma/Exile work; recon + specialists + security/performance review + rollback + runtime evidence
- G4 architecture, persistence, DB mutation, BattlEye/security or deployment infrastructure; full Gauntlet + independent verification
Worker may not self-certify. Keep EVIDENCED / INFERRED / UNKNOWN distinct. Record refuted hypotheses.
To avoid double work, XCSV uses GitHub Issues + GitHub Projects as the execution tracker. The roadmap remains the priority/decision memory; an issue is the active execution record.
Do not introduce Trello, Jira, Asana, Monday, Wrike, Kanban Tool or another board as a second task authority unless Architect explicitly changes this rule.
For material roadmap work:
- Give the item a stable ID when it becomes active, e.g.
GUARD-REL-002. - Use one GitHub issue as the execution record.
- Use sub-issues for genuinely separable work, not every tiny code edit.
- Link commits/PRs to the issue or stable ID.
- Do not mark Done until verification and durable-sync requirements are satisfied.
Recommended GitHub Project workflow:
BACKLOG -> RECONCILE -> READY -> IN PROGRESS -> VERIFY -> DONE
Use BLOCKED as an explicit state, not a hidden comment.
Useful fields:
- Roadmap ID
- Owning repo
- Priority
- Reconciliation state
- Gauntlet level
- Verification state
- Target date only when real
GitHub Projects supports table, board and roadmap views; keep the same issue as the underlying work item rather than duplicating cards.
Implementation is not complete merely because code exists or was pushed.
For applicable work, close the loop in this order:
- verify the implementation and print/read back changed regions
- run required tests/checks
- collect runtime evidence where the claim is operational
- commit the owning repository
- update authoritative desktop roadmap and owning area note
- update Git-tracked wiki/source documentation
- run
D:\XCSV\tools\build-memory-index.ps1 - run
D:\XCSV\tools\build-docs.ps1 - run
D:\XCSV\tools\build-rag-index.ps1 - update the GitHub issue/project state
- commit/push the hub docs and member-repo/submodule pointer changes as appropriate
- verify local vs remote state and report exact commits plus remaining UNKNOWNs
If the desktop roadmap cannot be updated in the current environment, say so explicitly and leave a visible GitHub planning-state divergence marker rather than pretending synchronization happened.
The XCSV hub contains CLAUDE.md, which imports this contract automatically. Member repositories must route Claude back to this contract. Claude Code project instructions are Git-tracked; do not rewrite global %USERPROFILE%\.claude settings unless Architect explicitly asks.
The hub AGENTS.md points here and opencode.json includes this file as project instructions. OpenCode uses AGENTS.md as its primary project rule source.
The hub includes .agents/rules/00-xcsv-ai-entrypoint.md. Workspace rules should be Always On. If Antigravity has not activated that committed workspace rule, set it to Always On once; do not create a competing copy of this contract.
Give them this contract plus the specific target evidence they need. Runtime GUARD local models are excluded: they remain tool-less, untrusted, non-load-bearing classifier/explainer components.
When Architect returns to SOVRAN-1/XCSV and starts Claude Code:
- Start Claude from the relevant XCSV repo.
- Say "read the GitHub".
- Claude should discover its repo-local adapter, read this contract, locate the desktop roadmap and run
D:\XCSV\tools\ai-reconcile.ps1. - If a member repo adapter or local checkout is missing, Claude should report exactly what is missing and repair only the Git-tracked project setup after checking for local uncommitted work.
- Do not run
/initblindly over existing instruction files. Existing XCSV instruction files are deliberate and should be extended, not replaced.
No additional global Claude configuration is required for the normal XCSV workflow.
Roadmap status is intent, not implementation proof.
GitHub absence is not proof that local/live work does not exist.
Source presence is not proof of runtime success.
Do not duplicate substantially equivalent functionality. Find the delta.
If sources disagree, reconcile before implementation.
A completed change leaves code, evidence and durable memory aligned.