Windows Development Machine Bootstrap
Status and authority
This is the Phase 6 clean-machine procedure for an Anuva Windows development machine. It defines the intended final state and the exact order in which later approved machine replication must proceed.
Gate 1 delivers and tests this procedure only. It does not authorize a toolchain installation, PATH change, Codex configuration or rules change, plugin installation, CLI installation, repository clone, secret creation, Cloudflare mutation, or machine-two operation.
The controlling gate and rollback details are in the Phase 6 implementation plan. Each live transaction must be previewed with exact versions, hashes, paths, current state, proposed effects, and rollback before it is separately approved.
Machine-two execution was deferred by user direction on 2026-07-31 because the machine is not currently available. Nothing on this page has been accepted on machine two, and the six documented machine-two DNS names were unresolved at the final preflight. This page remains the complete deferred work package; the deferral authorizes no Cloudflare repair, secret creation, installation, or machine mutation.
Deferred re-entry checklist
When machine two becomes available, do not resume an old command or artifact. Restart with a new exact preview that:
- resolves the then-current Product Main commit and all five reviewed
repository
maincommits; - rebuilds and verifies a clean CLI artifact from that exact Product Main source;
- records Windows architecture, bootstrap substrate, current PATH, toolchain, CLI, plugin, rules, Codex policy projection, and configuration state;
- inspects the
anuva-machine2tunnel, six routes, DNS, certificates, Access application and policy, token-file existence, and ACL without exposing a secret; - reports every missing prerequisite and stops before repair;
- presents exact install, rollback, inverse-rollback, and restart effects for CLI, plugin, and rules;
- names the complete local, HTTPS, fresh-task, repository, and snapshot acceptance matrix; and
- obtains a new live-transaction approval before any mutation.
The superseded uninstalled artifact 0.2.1-g011f29a884d1 is evidence only and
must not be installed after Product Main changes.
Target
A completed machine has:
- the five Anuva repositories under
C:\Anuva\dev; - the fixed toolchain in
config/toolchain.v1.json; - one validated machine-local development configuration;
- the Product Main local plugin marketplace and installed
anuva-developmentversion0.2.0; - one clean packaged Anuva CLI build with a valid previous target;
- the tracked minimal Codex rules file;
- the approved Codex sandbox, trust, marketplace, and plugin settings;
- its own Cloudflare Tunnel token file and connector;
- the six Access-protected machine-specific routes; and
- a non-secret snapshot comparable with the other development machine.
The machine identity changes paths, hostname suffix, tunnel name, token-file name, process IDs, logs, and receipts. It does not change repository identities, ports, tool versions, plugin version, active CLI source identity, canonical rules bytes, or policy-owned Codex settings.
Bootstrap substrate
The procedure begins with:
- Windows 11 x64 with current security updates;
- Codex Desktop installed from the official OpenAI distribution;
- Git, GitHub CLI, and Bun installed from their official distributions;
- an interactive Windows user account that can use its own profile and
%LOCALAPPDATA%; and - access to the private Shoonya Game Technologies repositories.
Git is needed to obtain Product Main, GitHub CLI establishes repository authentication, and Bun starts the source CLI that applies the fixed toolchain manifest. These are the documented bootstrap substrate, not ad hoc project packages. Record their versions before continuing. Do not install Node.js, pnpm, Python, MkDocs, Material for MkDocs, cloudflared, Unity, or another tool from an improvised command; use only the actions produced from the committed toolchain manifest after approval.
If the substrate itself differs from the Gate 4 preview, stop before cloning or installing anything.
Repository layout
Create C:\Anuva\dev, then clone these repositories into these exact paths:
| Repository | GitHub source | Local path |
|---|---|---|
| Product Main | Shoonya-Game-Technologies/anuva-main-video-creator |
C:\Anuva\dev\anuva-main-video-creator |
| Bento | Shoonya-Game-Technologies/anuva-bento |
C:\Anuva\dev\anuva-bento |
| Web | Shoonya-Game-Technologies/anuvax-cms |
C:\Anuva\dev\anuvax-cms |
| Python | Shoonya-Game-Technologies/anuva-python-server |
C:\Anuva\dev\anuva-python-server |
| Unity | Shoonya-Game-Technologies/anuva-unity-video-creator |
C:\Anuva\dev\anuva-unity-video-creator |
Gate 4 must name the exact reviewed main commit for each clone. Require a
clean working tree, origin equal to the table, and main/origin/main equal
to the reviewed commit. Do not copy working trees, .git directories,
dependency folders, build output, plugin caches, logs, or credentials from
another machine.
Authenticate GitHub with:
If gh auth status fails only inside a managed sandbox, repeat that read-only
check in a keyring-capable approved context. Do not reauthenticate when that
check succeeds.
Machine-local development configuration
For machine two, copy:
to:
Replace only:
YOUR_USERwith the interactive Windows profile directory name; andYOUR_VERSIONwith the reviewed installed Unity Editor version.
The example already fixes:
machine: machine2;- the five repository paths and GitHub identities;
- documentation ports
4001,4005,4002,4013, and4004; - machine-two documentation hostnames;
- Web port
3000andhttps://anuva2.girishd.com; - tunnel
anuva-machine2; and - token filename
cloudflared-anuva-machine2.token.
Do not add a token value, API key, password, database credential, email address, OTP, cookie, or GitHub credential. Validate the resulting file through the Product Main source CLI before any live service operation:
Pass --config <absolute-path> only when validating an isolated candidate.
Fixed toolchain
From clean Product Main at the Gate 3 merge commit:
bun run src/cli.ts toolchain doctor --json
bun run src/cli.ts toolchain snapshot --json
bun run src/cli.ts toolchain bootstrap --dry-run --json
Gate 4 records every proposed fixed package and version. Gate 5 may run
toolchain bootstrap --confirm only for that exact nonempty plan. Repeat
doctor, snapshot, and dry-run afterward; the final dry-run must propose no
action.
Do not substitute winget, pip, npm, pnpm, Bun, PowerShell, or a browser
installation command that was not returned by the committed manifest and
included in the approved preview. Repository dependencies remain governed by
their lockfiles and repository instructions.
Codex configuration
Configure only these non-secret policy fields:
- approval policy
on-request; - sandbox mode
workspace-write; - network access disabled inside the workspace sandbox;
C:\Anuva\devas the Anuva writable root;- trusted project entries for all five exact repository paths;
- the Product Main local marketplace; and
- enabled plugin identity
anuva-development@anuva.
Do not copy another machine's raw config.toml. Recreate the reviewed safe
fields and compare a sanitized representation. Exclude tokens, credentials,
private environment values, unrelated plugins, MCP secrets, model history, and
machine-specific transient settings.
Restart Codex after a confirmed configuration or active-rule change. A restart is part of the approved transaction and a required verification boundary.
Minimal Codex rules
Product Main owns:
First test the tracked file without installing it:
Preview the fixed target transaction:
The dry run returns the active SHA-256 or absent, candidate SHA-256, target,
byte counts, proposed current and previous, and restart requirement. Gate 5
must present and receive approval for those exact values before running:
After restart, rerun bun run check:rules. Preview and confirm rollback:
& .\scripts\install-codex-rules.ps1 -Action rollback
& .\scripts\install-codex-rules.ps1 `
-Action rollback `
-ExpectedCurrentSha256 '<exact-active-hash>' `
-Confirm
Restart, verify the previous state, then repeat the same rollback operation as the inverse rollback. Restart again and require the tracked minimal file to be active.
The installer may touch only %USERPROFILE%\.codex\rules\default.rules and its
checksum state under %LOCALAPPDATA%\Anuva\codex-rules. It never edits
config.toml, another rule file, PATH, a plugin, or a repository. Do not copy
or hand-edit active rules.
Source launcher and packaged CLI
A clean machine needs a source launcher before its first packaged installation
so the installer can preserve legacy-source as a real rollback target.
From clean Product Main, preview:
Require current=absent, no existing CLI pointers or legacy target, the exact
Product Main merge commit, pathUpdated=false, and the expected launcher
checksum. After the exact effect is approved:
Require:
The script verifies that stable source-runtime identity. The stable launcher writes no PATH entry.
Build and test the exact clean packaged artifact:
Gate 4 must record its build ID, full source commit, clean state, bytes, SHA-256, artifact directory, live version directory, PATH effect, and expected pointer transition. The packaged installer has no dry-run; its closed artifact schema, checksum validation, tested transaction, exact effect table, and separate approval are its boundary.
After approval, install only that exact artifact. Require:
current=<approved-build-id>;previous=legacy-source;- a checksum-manifested preserved source launcher;
- the stable launcher to dispatch to the packaged target; and
- the approved PATH result.
Then run anuva cli rollback --dry-run, confirm the separately approved
rollback, verify the source runtime, preview the inverse, confirm it, and finish
on the packaged build. Never delete version directories or edit pointers to
simulate recovery.
Machine one receives the same exact clean Phase 6 artifact only through the
Gate 4/5 transaction. Its previous target is the currently active packaged
build, not legacy-source.
Plugin
The marketplace source is:
The plugin source is:
Gate 5 installs only anuva-development@anuva version 0.2.0 through the
Codex plugin manager after the local marketplace is registered. Before and
after installation, require:
Verify the repository source, installed cache, twelve-skill inventory, and a
new Codex task in each repository. Gate 4 must record the machine-two
pre-install state. On a clean machine, rollback returns to the exact absent
plugin state through the plugin manager and inverse rollback reinstalls
0.2.0; an unexpected pre-existing plugin is a stop condition. Do not edit
cache files or config.toml by hand.
Cloudflare Tunnel and Access
Machine two uses:
The token must be obtained directly from the already configured
anuva-machine2 remotely managed tunnel, pasted without entering it in shell
history, and restricted to the interactive user and local administrators. Do
not copy machine one's token or reuse its tunnel.
Phase 6 verification is read-only. Confirm the existing dashboard and Access configuration described in Cloudflare Tunnel and Access Setup, then run the connector through the configured token-file path. Verify:
https://anuva2.girishd.com;https://main2.girishd.com;https://bento2.girishd.com;https://web2.girishd.com;https://python2.girishd.com; andhttps://unity2.girishd.com.
An authenticated response or expected Access login redirect proves the route. An unprotected public response, wrong origin, missing route, certificate failure, absent tunnel, absent Access application, or absent token is a stop condition. Do not repair Cloudflare under Phase 6 without a focused amendment.
Repository and documentation acceptance
From each of the five repositories:
- require the configured repository context and clean Git state;
- validate plugin source/cache and fresh-task skill discovery;
- run the repository's required read-only GitHub inspection;
- start or reuse its CLI-owned documentation preview;
- strictly verify its index or another stable page; and
- check its machine-two HTTPS hostname.
Expected documentation bases:
| Repository | Machine one | Machine two |
|---|---|---|
| Product Main | https://main1.girishd.com/ |
https://main2.girishd.com/ |
| Bento | https://bento1.girishd.com/ |
https://bento2.girishd.com/ |
| Web | https://web1.girishd.com/ |
https://web2.girishd.com/ |
| Python | https://python1.girishd.com/ |
https://python2.girishd.com/ |
| Unity | https://unity1.girishd.com/ |
https://unity2.girishd.com/ |
No acceptance step may edit a sibling tracked file or publish canonical docs.
Non-secret snapshot
Capture the fields defined in the Phase 6 machine snapshot contract. Compare machine one and machine two after both are on the exact Phase 6 source and active CLI artifact.
Never capture raw Codex configuration, environment variables, token contents, email addresses, OTPs, cookies, GitHub or Linear credentials, database credentials, or unredacted logs. A snapshot containing a possible secret is invalid and must not be committed.
Completion condition
Bootstrap is complete only when:
- fixed toolchain doctor and snapshot pass and bootstrap dry-run is empty;
- the five repository commits and registry match;
- the exact packaged CLI, plugin
0.2.0, and minimal rules are active; - CLI, plugin, and rules rollback plus inverse rollback have passed;
- Codex was restarted after each active policy transition;
- all ten documentation routes and both application-route identities are correct and Access-protected;
- cross-machine snapshot comparison passes; and
- no repository, secret, Linear, Cloudflare, or Phase 7 mutation occurred outside its approved gate.
Until every item passes on machine two, report this procedure as deferred or
incomplete, never as accepted.