XCP Studio
Inside XCP Studio
From an editable project to measured execution on Xbox.
XCP Studio is not a dashboard placed above separate scripts. It is the desktop surface of one shared project, toolchain and lifecycle used by people, expert developers and external agents.
Free · local · no account. It ships when public packaging is ready.
Windows only — for now. XCP Studio is a WinUI 3 desktop application.
Project authority
One project. One source of truth.
Every interface edits the same file. There is no Studio-private format and no privileged path for agents, because a second authority is a second set of rules that will eventually disagree with the first.
xcp-project.json is the editable authority
One file
The interface can change. The authority does not.
Portability
A Studio that no longer depends on the repository.
Studio startup does not walk parent directories looking for a source tree. It resolves one exact, manifest-bound toolchain and fails closed if that toolchain is not the one it expects.
What the resolver accepts
Exactly one xcp-agent-kit-manifest-v1 root, from an
explicit environment variable, an application-adjacent
toolchain directory, or the per-user Studio toolchain.
It fails closed on schema, identifier, version or security mismatch, on escaping paths and reparse points, and on any divergence in file set, byte length or SHA-256.
What the shell provides
- Versioned, manifest-bound portable toolchain
- Exact file-set, byte-length and SHA-256 verification
- Native Windows file and folder selection
- A recent project library with explicit states
AVAILABLE,MISSINGandMOVED, never a silent guess- Relink that preserves the original location as provenance
- No persistent authentication material
The portable Studio and toolchain have been validated outside the development repository. Public packaging and distribution remain a separate product step.
Create
From an empty folder to a prepared lifecycle.
- Create project
- Edit
- Validate
- Build deterministic bundle
- Prepare complete lifecycle
- Receive structured correction
Validation and build are the same portable operations the command line and an external agent use. The Studio calls them; it does not reimplement them, so a project that builds in one place builds in all three.
Adapt
Adaptation is a semantic transformation, not a file conversion.
Nothing here copies files or rewrites extensions. The external project is observed, understood as a model, expressed in a neutral intermediate representation and only then reconciled with what the console actually admits.
- External source
- Source observation
- Semantic model
- Creative IR
- Capability reconciliation
- Lowering
- Ordinary XCP project
Why the intermediate representation matters
Ecosystem adapters may only detect, inspect, inventory and extract semantics. Every adapter emits the same Creative IR, and one shared backend turns that IR into a project after comparing it against the measured host profile.
The registry stays open to further engines and source formats without anyone building an engine-to-console converter, and without the console gaining an engine-specific path.
Every element gets one disposition
preserved_directlytranslatedsubstituteddegradedunsupportedhuman_intervention_required
Two of the six are refusals. Work that cannot cross is named, never hidden inside a readiness score.
A real Godot 2 source project, taken at an exact public revision, was adapted and driven through the complete Xbox lifecycle: 14 of 14 operations and 5 of 5 semantic acceptance assertions, closing honestly as playable with declared degradation. See the evidence.
Evolve
A new upstream revision does not discard your work.
Unchanged outputs are reused, changed portions are rebuilt, and the decisions you made by hand are carried across as explicit overlays rather than silently overwritten.
- Base revision
- New upstream revision
- Local overlays
- Semantic diff
- Selective reuse and rebuild
- New immutable version
- Verified update and rollback
The result is a new version, not a mutation of the old one. The previous version stays installed and reachable, which is what makes the rollback exact rather than a rebuild that happens to look the same.
Playtest and observe
Eleven stages, each one accountable.
Every stage exposes its state, its structured errors, the correction that followed, the evidence produced and the exact version identity it applied to.
- discoverFind the device and read its measured host profile
- validateCheck the project against schema, capabilities and budgets
- installPlace an immutable, content-addressed bundle
- activateMake one exact version current, through a hash-chained journal
- launchBind the foreground surface to an exact execution plan
- observeRead structured state, logs and counters
- interactDrive semantic input rather than raw device events
- captureTake a deterministic frame with its own digest
- updateInstall and activate a new version beside the old one
- rollbackReturn to the exact previous version, not a rebuild
- cleanupRemove disposable candidates once unreferenced
Evidence view
Evidence is part of the execution path, not a report written afterward.
Runtime observations
Structured state, logs and counters read from the running project.
Captures
Deterministic frames, each with its dimensions, byte length and digest.
Receipts
What ran, against which version, with what outcome.
Project identity
The digest of the exact project the run came from.
Bundle identity
The digest of the deterministic build that was installed.
Package identity
The exact signed worker the console was running.
Correction ledger
Append-only, hash-chained: what failed, and what was changed in response.
Acceptance results
Semantic assertions, passed or not, per run.
Rollback evidence
Proof that the previous version was restored exactly.
