Anuva Development Policy Phase 6 Implementation Plan

Status

Status: Gate 1 source implementation and its focused checksum-evidence amendment were approved, implemented, locally verified, and delivered in PR #31 on 2026-07-30. Gate 2 machine-one rules installation, rollback, inverse rollback, required restarts, and acceptance are complete. Gate 3 readiness and merge are complete at Product Main main 731782780f7cb11190dc2c976ed33135dfe76f35. The first Gate 4 preview stopped before any machine-two or Cloudflare inspection or mutation because a clean Windows checkout did not preserve the reviewed rules bytes. The focused rules-EOL correction merged as Product Main cbdc3dd900a8d2b1e8c4ea992875f8e20ae3635f. The restarted Gate 4 preview stopped at source verification because two temporary-Git integration tests relied on Bun's implicit five-second timeout. The focused timeout correction is isolated to codex/development-policy-phase-6-repository-change-timeout; that correction merged through PR #33 as Product Main 011f29a884d17825eece19dce8d9bd4c62dd71ae.

The corrected Gate 4 preparation built and verified clean artifact 0.2.1-g011f29a884d1 from that exact commit. It contains 102,319,104 bytes and has SHA-256 2f8f19124742fb2cb2b87716c644d8e7f0a48ae61926ff5bdca128004314211b. It was not installed. The source suite passed 123 tests and 509 assertions, the packaged suite passed 7 tests and 125 assertions, and the canonical rules matrix passed all 48 cases followed by 4 installer tests and 41 assertions.

Read-only route inspection then proved that all six documented machine-two hostnames returned DNS name-not-found. No machine-two or Cloudflare state was changed. On 2026-07-31 the user directed Product Main to defer all machine-two replication and Cloudflare prerequisites because the second machine is not currently available, preserve the exact bootstrap work as a future operational procedure, and allow Phase 7 planning to begin. Phase 6 is therefore closed for rollout sequencing with a recorded machine-two exception; it is not a claim of two-machine acceptance.

Phases 1 through 5 are complete. This plan starts from Product Main main at 2e721860225ba66d86d83ce2baf25899068f56de, after the Phase 5 completion-evidence PR merged. It is a development-process change under the explicit-only $anuva-development:anuva-development-process-change lane and does not use Linear.

The approved branch is codex/development-policy-phase-6, created from the exact baseline above by renaming the planning branch. Gate 1 authorizes only the tracked source, tests, documentation, commit, push, and focused draft PR in this plan.

Gate 1 source evidence

The local Gate 1 candidate changes exactly the 22 allowed paths. It changes no src/**, plugin, marketplace, checked-in skill, sibling-repository, product, or historical docs/changes/** path.

The tracked candidate config/codex/default.rules is 9,924 bytes, contains 25 prefix_rule declarations, and has SHA-256 35eed0fb26bae95c7a45a4a1c83c119dcb012a4e5082758c1e02ef51379a4077. At Gate 1 close it was not installed.

Local verification:

Check	Result
Candidate execpolicy matrix	48 cases: 19 allow, 16 prompt, 5 forbidden, 8 no-match
Isolated rule transaction suite	3 tests, 38 assertions
Machine config unit suite	4 tests, 13 assertions
TypeScript typecheck	passed
Full source suite	122 tests, 617 assertions
Packaged/installer suite	7 tests, 125 assertions
Strict documentation structure/build/served pages	passed for all changed pages
Exact path allowlist and `git diff --check`	passed

At Gate 1 close, the machine-one user rules remained the recorded 63,004-byte baseline with SHA-256 ebf0accf7700ee41f0334ed29d74f61c03a79d18221d73e367a6762179c26360. Active CLI, previous CLI, plugin source/cache, sibling repositories, Linear, Cloudflare, PATH, and machine-two state were unchanged.

The raw user Codex configuration changed during Gate 1 verification:

Field	Baseline	Verification
Bytes	`5143`	`5222`
SHA-256	`e96a59f44fae8c4f285368c10f4f900f86bc2abee11408b629b08efcf9ef6dc8`	`1ec9a8459abadbee72087968cdf4d4270d9b95f0b3ecc3522f6aa5a87574d7c3`
Verification last-write UTC	not applicable	`2026-07-30T07:11:40.2170899Z`

No Gate 1 command intentionally edited config.toml. Read-only structural inspection confirms the policy-owned approval mode, sandbox mode, network boundary, Anuva writable root, five trusted repositories, Product Main marketplace, and enabled Anuva plugin still match the baseline. The raw file also contains desktop and connector-owned state outside the Phase 6 policy scope, and no baseline copy exists for a safe content comparison.

The user approved a focused evidence amendment on 2026-07-30: accept this as out-of-scope desktop/connector-owned drift, rebaseline only the raw checksum to 1ec9a8459abadbee72087968cdf4d4270d9b95f0b3ecc3522f6aa5a87574d7c3, and resume the exact Gate 1 draft-PR delivery. The amendment does not authorize editing or restoring config.toml; the recorded 5,143-byte hash remains the historical pre-drift observation.

Gate 2 machine-one acceptance evidence

Gate 2 ran against reviewed draft PR #31 source head 151231e71c16e18497aa0530094362c595117424. Before every live transition, the branch was clean, the PR remained open and draft, the tracked 9,924-byte rules source matched 35eed0fb26bae95c7a45a4a1c83c119dcb012a4e5082758c1e02ef51379a4077, and the active 63,004-byte baseline matched ebf0accf7700ee41f0334ed29d74f61c03a79d18221d73e367a6762179c26360.

The approved rules lifecycle completed in three checksum-bound transactions:

Transition	Resulting `current`	Resulting `previous`	Receipt
Install minimal over baseline	`35eed0fb26bae95c7a45a4a1c83c119dcb012a4e5082758c1e02ef51379a4077`	`ebf0accf7700ee41f0334ed29d74f61c03a79d18221d73e367a6762179c26360`	`20260730T075045Z-rules-install-6332`
Roll back to 134-rule baseline	`ebf0accf7700ee41f0334ed29d74f61c03a79d18221d73e367a6762179c26360`	`35eed0fb26bae95c7a45a4a1c83c119dcb012a4e5082758c1e02ef51379a4077`	`20260730T081119Z-rules-rollback-72e5`
Inverse rollback to minimal	`35eed0fb26bae95c7a45a4a1c83c119dcb012a4e5082758c1e02ef51379a4077`	`ebf0accf7700ee41f0334ed29d74f61c03a79d18221d73e367a6762179c26360`	`20260730T082549Z-rules-rollback-bf05`

Each transaction preserved immutable copies of both rule files and reported restartRequired=true. Codex was restarted after every confirmed swap. After the first and final restarts, the active-file matrix passed all 48 cases with 19 allow, 16 prompt, 5 forbidden, 8 no-match, and no failures. After the rollback restart, the 134-rule baseline loaded with its exact hash and declaration count; representative decisions were direct Anuva allow, GitHub merge prompt, PowerShell wrapper no-match, arbitrary Node.js no-match, and hard-reset prompt.

The first required restart rewrote volatile desktop/runtime state in config.toml from the approved Gate 1 observation to a new raw checksum. The user approved a focused Gate 2 evidence amendment: retain raw hashes only as observations and guard every remaining restart with a deterministic projection of the policy-owned fields. The observations were:

Observation	Raw `config.toml` SHA-256
Gate 1 approved baseline	`1ec9a8459abadbee72087968cdf4d4270d9b95f0b3ecc3522f6aa5a87574d7c3`
First required restart	`1c43f5d1595b31eec4cb086d6197c3909c7f7b32844ff3aa9aff925fa34d1845`
Baseline restart	`e7a1c7007cb4ea220d67f3b3be285406fc35b6791fdd458d42f8d7284d045493`
Final minimal-rules restart	`75d87505faa3048d3fa8d1c7cbac73f178f562e69b36b95bf8d66f71c13dc3fd`

The sanitized projection remained 01d84ecb1aa8ca1d1b208f03b5f90b5a54738378cd626f967c797f0c87ece4f0 through the rollback, inverse rollback, and all remaining restarts. It includes only the approval and sandbox modes, writable root and network boundary, Windows sandbox setting, five trusted Anuva repositories, Product Main marketplace source/type, and enabled Anuva plugin identity. No Gate 2 command edited or restored config.toml.

Final machine-one state is the tracked minimal rules as active/current, with the 134-rule baseline retained as previous. Packaged CLI build 0.2.1-g2fecf51439fc remains active with 0.2.1-g3dd30bca40f1 as previous. Plugin source and installed cache remain byte-identical at version 0.2.0 with twelve skills. No plugin, CLI, PATH, machine-two, Cloudflare, Linear, sibling-repository, product-code, readiness, or merge mutation occurred.

Gate 3 merge and pre-Gate-4 rules-EOL evidence

PR #31 was squash-merged only after exact-head review. The reviewed source head was bf72e575c35c1ba8781f89ded3d46a6df2b45f2e, its tree was 20e0ca0714c05fb429f79b99b671b5360af9c757, and Product Main main became 731782780f7cb11190dc2c976ed33135dfe76f35. The merge tree equals the reviewed tree. Product Main was synchronized and only codex/development-policy-phase-6 was deleted.

The exact Gate 4 preview began from that merge. With Windows core.autocrlf=true, the tracked Git blob remained the reviewed 9,924-byte LF file with SHA-256 35eed0fb26bae95c7a45a4a1c83c119dcb012a4e5082758c1e02ef51379a4077, but the clean working-tree file contained 10,187 bytes, 263 CRLF sequences, and SHA-256 c7016030e576b7d43a45cc3f792ae54601a027e2db072bf434117ed5a7022666. Removing only the CR bytes reproduced the reviewed Git blob. The repository had no .gitattributes, so a clean Windows clone could install bytes that differed from the reviewed source and active machine-one rules. Gate 4 stopped before the mismatch could enter any machine-two transaction.

The approved focused amendment adds only an exact config/codex/default.rules text eol=lf attribute, a regression assertion in the existing installer integration test, and these two evidence-page updates. A clean Windows verification checkout with core.autocrlf=true produced exactly 9,924 bytes, no CR bytes, and SHA-256 35eed0fb26bae95c7a45a4a1c83c119dcb012a4e5082758c1e02ef51379a4077. The complete rules verification passed all 48 cases with 19 allow, 16 prompt, 5 forbidden, and 8 no-match decisions, followed by 4 installer tests and 41 assertions with no failure.

The previously prepared uninstalled CLI artifact 0.2.1-g731782780f7c is not eligible for Gate 5 because the authoritative Product Main source commit will change when this correction merges. Gate 4 must restart from the exact correction merge and build a new clean artifact. No active rule, Codex configuration, CLI, plugin, PATH, machine-two, Cloudflare, Linear, sibling-repository, or product state changed during the stopped preview or this source-only correction.

Restarted Gate 4 source-verification stop

The rules-EOL correction was delivered in PR #32. Its reviewed head was d66c6461e15d8faeb05286267d2482641cbf5f84, its tree was dc5ae64114b6affe38c95fb636564f3d015d0ba8, and the squash merge became Product Main cbdc3dd900a8d2b1e8c4ea992875f8e20ae3635f with the same tree.

The restarted Gate 4 preview built clean Windows x64 artifact 0.2.1-gcbdc3dd900a8 from that merge. It contained 102,319,104 bytes, had SHA-256 28c5ba9c1949f4db018a1a549a54f0d8a280304074dc395e35bad244000699e0, and reported the exact clean embedded source identity. It was not installed.

The required native-PowerShell source suite cleared the known Bun child-process PowerShell module-path anomaly but repeatedly stopped when the first temporary-Git repository-change integration test exceeded Bun's implicit five-second default. The unchanged behavior passed with a 30-second runner limit in approximately 5.15 seconds, proving a timing boundary rather than a repository-change defect. Gate 4 stopped before packaged verification, toolchain, machine-two, Cloudflare, or route inspection.

During the resumed amendment preflight, selecting Codex's persistent Allow similar commands option had appended five approval rules to the active user file. The user removed only those additions, restored the missing final LF newline, and restarted Codex. Read-only verification then proved active, current, and the immutable current version all matched canonical SHA-256 35eed0fb26bae95c7a45a4a1c83c119dcb012a4e5082758c1e02ef51379a4077; previous remained ebf0accf7700ee41f0334ed29d74f61c03a79d18221d73e367a6762179c26360. The 48-case matrix and 4-test, 41-assertion installer lifecycle passed, and the installer correctly refused a redundant install because the tracked candidate was already active.

The approved focused source amendment adds an explicit 30-second timeout only to the two temporary-Git repository-change integration tests and changes no runtime behavior. Exact native-PowerShell source, packaged, and rules checks, plus strict verification of the two evidence pages, passed before its draft PR was delivered. The uninstalled artifact above becomes ineligible when the authoritative Product Main commit changes; Gate 4 must restart from the timeout correction merge and build a new clean artifact.

Outcome

Phase 6 leaves:

one reviewed, tracked, minimal Codex rules file with a repeatable direct and wrapped-command test matrix;
one closed installer and rollback path for that rules file;
one documented clean-Windows bootstrap that produces the same repository registry, plugin, CLI, toolchain, Codex, and preview topology on machine two;
one closed source-launcher bootstrap so a first packaged CLI installation on a clean machine has legacy-source as a real rollback target;
verified machine-one rule replacement, rollback, and inverse rollback;
a deferred, exact machine-two setup procedure with no ad hoc package or issue-specific rule;
a deferred cross-machine snapshot contract; and
this explicit exception record.

The original exit criterion required a second Windows development machine to reproduce the workflow. That criterion remains unverified and may not be reported as passed. The 2026-07-31 user decision changes only rollout ordering: Phase 7 may proceed on machine one while machine-two setup remains a separately gated deferred operation. Resuming it must restart at Gate 4 from the then-current Product Main commit, rebuild the clean artifact, revalidate every identity, and obtain new exact approval before any Gate 5 mutation.

Authority and exclusions

Phase 6 may change only the Product Main process assets and machine-local state named in this plan. It must not:

create, read for workflow purposes, or mutate a Linear issue;
modify Bento, Web, Python, or Unity tracked files;
modify Product Main product behavior or any src/** file;
change the anuva-development plugin source, marketplace entry, installed cache, enablement, or version 0.2.0;
remove or recreate checked-in shared skills;
add a general workflow engine, arbitrary shell wrapper, or broad command permission;
install an unlisted package or use an issue-specific Codex rule;
create, delete, or change a Cloudflare tunnel, route, DNS record, Access application, policy, identity provider, certificate, or token;
publish canonical documentation to anuva.girishd.com;
ready or merge a PR without its exact later gate approval; or
begin Phase 7.

If a required effect falls outside these boundaries, stop and prepare a focused amendment. Approval of one gate never authorizes a later gate.

Exact baseline

Gate 1 must reconfirm this Product Main baseline:

Field	Exact value
Branch	`main`
`HEAD` and `origin/main`	`2e721860225ba66d86d83ce2baf25899068f56de`
Working tree	clean
Installed plugin	`anuva-development` `0.2.0`, source and cache valid, twelve skills
Active CLI	`0.2.1-g2fecf51439fc`
CLI rollback target	`0.2.1-g3dd30bca40f1`
Active CLI SHA-256	`e2f5bf820b0c1dd35eef6103a5335265387c9919cbd19f8bf4ab14f29186a90b`
Machine-one preview	`https://main1.girishd.com/`

The machine-one user rules baseline recorded on 2026-07-30 is:

Field	Exact value
Path	`%USERPROFILE%\.codex\rules\default.rules`
Bytes	`63004`
Lines	`220`
`prefix_rule` declarations	`134`
SHA-256	`ebf0accf7700ee41f0334ed29d74f61c03a79d18221d73e367a6762179c26360`

The file begins with a small reusable policy and then contains approximately 119 accumulated exact command approvals. It remained untouched until Gate 2.

The non-secret machine-one Codex baseline has approval_policy="on-request", sandbox_mode="workspace-write", network_access=false, C:\Anuva\dev as a writable root, trusted entries for the five repositories, the Product Main marketplace, and enabled anuva-development@anuva. The approved raw configuration file SHA-256 is 1ec9a8459abadbee72087968cdf4d4270d9b95f0b3ecc3522f6aa5a87574d7c3. The raw configuration must not be copied into Git or evidence because other fields may be private.

The machine-one toolchain snapshot recorded at 2026-07-30T06:25:48.862Z reports Git 2.41.0, GitHub CLI 2.96.0, Bun 1.3.14, Node.js 24.18.0, pnpm 11.9.0, Python 3.14.5, MkDocs 1.6.1, Material for MkDocs 9.7.6, and cloudflared 2025.11.1. The committed config/toolchain.v1.json remains the version authority; the snapshot is evidence, not a second manifest.

Machine-one user-owned state, logs, receipts, tokens, caches, generated artifacts, and ignored dist/ output remain outside Git.

Codex rules contract

The canonical source will be config/codex/default.rules. It follows the official Codex rules contract: rules use prefix_rule, the most restrictive matching decision wins, inline match and not_match examples validate intent, codex execpolicy check tests a command, and Codex must be restarted after its active rules change.

Allowed reusable prefixes

The file will allow only these reusable command families:

anuva;
gh auth status;
gh repo view;
gh issue view;
gh pr view, list, status, checks, and diff;
gh run view, list, and watch;
gh workflow view and list;
git diff --check;
git ls-remote --heads origin;
pnpm test:e2e; and
pnpm stack:status.

Arguments that select a repository, PR, workflow, run, or output format remain variable only after one of these exact read-only prefixes. No command is allowlisted merely because it contains one of these strings later in a shell payload.

Prompted boundaries

The file will explicitly prompt for:

Git mutations, including add, commit, push, switch/checkout branch creation, merge, rebase, revert, tag, stash, and branch deletion;
GitHub API access and GitHub issue, PR, repository, workflow, secret, variable, and release mutations; and
PowerShell, pwsh, and cmd.exe command-string wrappers.

Wrapped anuva or GitHub commands remain prompted. Skills must prefer direct, separate commands so a reusable direct prefix can be evaluated without granting the wrapper itself.

Forbidden boundaries

The file will forbid at least:

git reset --hard;
destructive git clean force forms; and
gh repo delete.

The most restrictive result must remain forbidden when a broader Git or GitHub mutation prompt also matches.

Deliberate non-matches

The file will not create reusable rules for:

arbitrary powershell, pwsh, or cmd payloads beyond the wrapper prompt;
arbitrary node, python, bun, or patch-helper execution;
Copy-Item, Move-Item, Remove-Item, or other general file operations;
temporary exact commands, hashes, PR numbers, or issue numbers; or
direct GitHub mutations.

A no-match result means Codex continues through its normal sandbox and approval policy. It is not converted into an allow.

Durable rule tooling

scripts/check-codex-rules.ts will run the candidate file through codex execpolicy check --pretty --rules <candidate> -- <command>. Its fixed table will cover:

Expected result	Required cases
Allow	direct Anuva, each GitHub read family, `git diff --check`, remote-head read, and the two named pnpm commands
Prompt	Git mutations, GitHub mutations/API, and PowerShell, pwsh, and cmd wrappers
Forbidden	hard reset, forced clean, and repository deletion
No match	arbitrary Node.js, Python, Bun, patch helper, and file-operation commands

The checker will fail on a changed decision, missing match, unexpected match, Codex execution error, or absent candidate. It will also prove that variable read-only arguments still match and that lookalike or wrapped commands do not inherit direct-command allowance.

scripts/install-codex-rules.ps1 will be a fixed-purpose rules installer, not a shell wrapper. It will:

accept only the tracked candidate and the single Codex default.rules target, with isolated roots allowed for tests;
validate the candidate with the checker before mutation;
stage immutable copies by SHA-256 under %LOCALAPPDATA%\Anuva\codex-rules\versions;
keep closed current and previous identities plus a redacted receipt;
preview every pointer, target, byte count, and SHA-256 change by default;
require -Confirm for an atomic replacement;
reject a changed target between preview and confirmation; and
provide the same dry-run/confirm pointer swap for rollback and inverse rollback.

It will never edit config.toml, any other .rules file, plugin state, PATH, or a repository. The operator must restart Codex after each confirmed swap.

An isolated integration test will prove install, rollback, inverse rollback, checksum rejection, stale-preview rejection, atomic failure recovery, and scope rejection without touching the real user profile.

Clean-machine CLI rollback prerequisite

The current packaged installer preserves legacy-source only when a valid source-backed %LOCALAPPDATA%\Anuva\bin\anuva.cmd already exists. On a clean machine with no launcher, the packaged install succeeds but has no previous target. That cannot prove the required first-install rollback.

Phase 6 will close this gap with scripts/install-anuva-source-launcher.ps1. The script will:

resolve Product Main only from its own checked-out script location;
require Bun, src\cli.ts, a clean Product Main checkout, and a successful source --version smoke check;
accept only the default Anuva install root, with an isolated root allowed for tests;
refuse any existing packaged current pointer, previous pointer, preserved legacy target, or unrecognized launcher;
preview the exact launcher path and Product Main path by default;
require -Confirm for one atomic launcher write;
write no PATH, config, package, plugin, or repository state; and
verify 0.0.0-development (source development) after the write.

The existing packaged installer will then preserve those exact bytes, create the closed legacy manifest, and set previous=legacy-source. The existing rollback command will prove rollback and inverse rollback. The source-launcher script does not change the packaged installer contract or add a CLI command.

tests/integration/cli-install.test.ts will exercise the new script from an empty isolated install root through source launch, first packaged install, rollback to legacy-source, and inverse rollback to the packaged target.

Tracked Gate 1 scope

After separate approval, Gate 1 may change only these files:

AGENTS.md;
config/codex/default.rules (new);
config/development.example.yaml;
config/development.machine2.example.yaml (new);
package.json;
scripts/check-codex-rules.ts (new);
scripts/install-codex-rules.ps1 (new);
scripts/install-anuva-source-launcher.ps1 (new);
scripts/README.md;
tests/integration/cli-install.test.ts;
tests/integration/codex-rules-install.test.ts (new);
tests/unit/config.test.ts;
docs/development/AnuvaDevelopmentPolicyPhase6ImplementationPlan.md;
docs/development/AnuvaDevelopmentPolicyImplementationPlan.md;
docs/development/DevelopmentProcessPolicy.md;
docs/development/MachineBootstrap.md (new);
docs/development/DevelopmentEnvironment.md;
docs/development/CloudflareSetup.md;
docs/development/index.md;
docs/engineering/AgentInstructions.md;
docs/engineering/AnuvaCli.md; and
docs/engineering/CodexDevelopmentProcess.md.

config/development.machine2.example.yaml will contain the exact five repository identities, ports, machine-two hostname suffixes, anuva-machine2 tunnel name, and token-file naming convention. Only the Windows user segment and installed Unity version remain operator substitutions. The config test will parse both examples with the production schema and prove their repository sets and ports agree.

MachineBootstrap.md will be the ordered clean-machine procedure. The other listed instruction and documentation pages may only replace stale machine-one, CLI, rules, or bootstrap statements with links and requirements from that procedure. No historical docs/changes/** page is edited.

Implementation gates

Gate 1: source, tests, documentation, and one draft PR

Gate 1 approval was granted on 2026-07-30 for this exact scope:

Reconfirm the exact baseline and clean working tree.
Rename codex/development-policy-phase-6-plan to codex/development-policy-phase-6.
Implement only the exact tracked scope above.
Test the candidate rules file without installing it.
Run the two isolated installer suites, config tests, typecheck, full source suite, packaged suite, strict docs verification, link validation, git diff --check, and an exact path-allowlist comparison.
Reconfirm the real user rules hash, active CLI pointers, plugin identity, Codex config hash, sibling Git state, Cloudflare state, and Linear state were not mutated.
Commit and push one focused change and create one draft Product Main PR.
Review its exact head, checks, files, comments, review threads, and rules test output, then present the exact Gate 2 machine-one rules transaction.

Gate 1 does not install rules or a launcher, restart Codex, build or install a new live CLI, touch machine two, mutate Cloudflare, ready, or merge.

Gate 2: machine-one rules install, rollback, and inverse rollback

The Gate 2 preview must name the exact reviewed PR head, canonical rules SHA-256 and byte count, current user-rules SHA-256, dry-run receipt, backup identity, target path, restart requirement, acceptance commands, rollback transition, and inverse transition.

After separate approval:

Recheck every identity and run the candidate rules matrix.
Confirm the exact install and stop for a Codex restart.
In the resumed task, prove the installed hash and all direct, wrapped, forbidden, and no-match cases.
Preview and confirm rollback to the recorded 134-rule baseline, then stop for a Codex restart.
In the resumed task, prove the baseline hash, preview and confirm the inverse rollback to the minimal file, then stop for a final Codex restart.
In the resumed task, repeat the complete matrix, inspect redacted receipts, and update only Phase 6 evidence on the same draft PR.

Stop if any restart does not load the expected hash or any rule result differs. No other user rule or Codex configuration field may change.

Gate 3: exact source PR readiness and merge

Review the exact post-acceptance PR head, allowed paths, checks, review state, threads, rules receipts, and machine-one final state. Present its commit and tree identities and the revert plan.

Only after separate Gate 3 approval, mark that exact head ready, squash-merge it, synchronize Product Main main, prove the merge tree equals the reviewed head tree, and delete only the managed Phase 6 source branch.

Gate 4: exact machine replication transaction preview

From the exact Gate 3 merge commit, prepare but do not execute one machine replication transaction. It must report:

machine-two Windows architecture and the documented bootstrap prerequisites;
exact five repository URLs, target paths, and main commits;
exact fixed toolchain actions from anuva toolchain bootstrap --dry-run;
the clean packaged CLI build ID, full source commit, bytes, SHA-256, source launcher effect, PATH effect, install pointers, rollback, and inverse rollback;
plugin marketplace identity, source version/tree, expected installed cache, and the exact pre-install rollback target (absent on a clean machine);
canonical rules hash, current machine-two rules hash or absence, install, rollback, inverse rollback, and required restarts;
sanitized Codex configuration changes;
machine-two development config checksum and repository registry;
Cloudflare tunnel token-file path, existence and ACL checks, the twelve already documented routes, and Access behavior; and
the complete local, HTTPS, fresh-task, and snapshot acceptance matrix.

Every nonempty toolchain action, PATH change, plugin install, CLI install, rule replacement, Codex configuration edit, and secret-file creation must be visible. Gate 4 is preview-only and stops for Gate 5 approval.

Gate 5: approved machine-two replication and two-machine acceptance

After exact Gate 5 approval, perform only the previewed transaction:

Establish the documented bootstrap prerequisites from official fixed sources; clone the five repositories at the reviewed commits.
Create and strictly validate the machine-two development configuration and sanitized Codex configuration.
Create the source launcher, build or transfer the exact approved clean CLI artifact, install it, and prove rollback to legacy-source and inverse rollback.
Install plugin 0.2.0 from the Product Main marketplace and prove source, cache, twelve-skill, rollback to the reviewed pre-install state, inverse rollback, and fresh-task discovery.
Install the canonical minimal rules file with its approved restart, rollback, inverse rollback, and command matrix.
Run only the fixed toolchain actions previewed by Gate 4, then require doctor, snapshot, and bootstrap dry-run to be healthy with no remaining action.
Verify the existing machine-two Cloudflare token file, tunnel, routes, Access redirects/session, and all five documentation previews without changing Cloudflare.
Run repository context, GitHub read, skill routing, docs, CLI, and rollback acceptance from all five repositories.
Capture machine-one and machine-two non-secret snapshots and compare every policy-owned field.
Stop for a revised amendment on any difference outside the explicitly documented machine identity, paths, host suffixes, tunnel name, or rollback-target kind.

If a Cloudflare object, route, Access policy, certificate, or token is absent or incorrect, stop. Gate 5 does not authorize its repair.

The exact merged Phase 6 CLI artifact should become active on machine one as well as machine two so both machines use one clean source identity. Machine one retains its current packaged build as previous; machine two retains legacy-source. Each machine requires its own exact artifact and live-effect preview before Gate 5 approval. A build identity or checksum difference is a stop condition unless a focused amendment explains and approves it.

Gate 6: completion evidence PR

After Gate 5 acceptance, prepare an exact docs-only completion plan from the then-current Product Main main. After separate approval, create codex/development-policy-phase-6-completion, update only:

docs/development/AnuvaDevelopmentPolicyPhase6ImplementationPlan.md;
docs/development/AnuvaDevelopmentPolicyImplementationPlan.md;
docs/development/DevelopmentProcessPolicy.md;
docs/development/MachineBootstrap.md; and
docs/development/DevelopmentEnvironment.md.

Record only redacted hashes, versions, commits, receipts, route outcomes, and snapshot comparisons. Strictly verify and deliver one focused draft PR. Its readiness and merge require another exact approval. Phase 7 remains stopped.

Machine snapshot contract

Each machine snapshot records:

machine identifier, Windows build, architecture, and timestamp;
tool versions from the committed toolchain manifest;
five repository identities, paths, commits, cleanliness, and config hash;
CLI runtime, current and previous target kinds, source commit, artifact checksum, launcher status, and redacted receipts;
plugin marketplace identity, version, source/cache hashes, skill count, and fresh-task discovery;
active rules checksum, rule count, and matrix result;
safe Codex policy fields, trusted repository set, enabled plugin identity, and a sanitized config checksum;
tunnel name, token-file existence and ACL result, connector health, expected hostname set, and Access-protected route results;
local and HTTPS documentation results; and
anuva doctor, toolchain snapshot, bootstrap dry-run, and repository-context results.

It excludes usernames where not required for path comparison, email addresses, tokens, cookies, OTPs, GitHub credentials, Linear credentials, raw Codex configuration, environment values, database credentials, and file contents that may hold secrets.

Allowed machine-specific differences are machine ID, Windows user path, machine hostname suffix (1 or 2), tunnel name/token path, live process IDs, timestamps, logs, receipts, and CLI previous-target kind. Tool versions, repository commits, CLI current source/checksum, plugin source/cache, canonical rules checksum, repository registry, ports, and policy-owned Codex settings must match.

Verification matrix

Source

candidate rules checker passes every allow, prompt, forbidden, and no-match case;
rules installer isolated install/rollback/inverse/failure tests pass;
source-launcher to packaged-install rollback lifecycle passes in an isolated root;
both development config examples pass the production schema;
bun run typecheck, bun test, and bun run check:packaged pass;
strict MkDocs page and link verification passes;
git diff --check and the exact path allowlist pass; and
the draft PR has no unresolved blocking review or check.

Each machine

active rules bytes equal the tracked canonical file and the matrix passes after a fresh Codex start;
active CLI is the exact approved clean merged build and rollback/inverse rollback succeeds;
plugin source and cache are version 0.2.0, contain twelve skills, and a fresh task discovers the qualified identities;
toolchain doctor and snapshot pass, and bootstrap dry-run proposes no action;
all five repository contexts and GitHub read operations succeed;
all five local documentation pages and machine-specific HTTPS routes pass;
Cloudflare Access protects all six machine-specific public routes; and
no tracked repository file changes during machine acceptance.

Cross-machine

all policy-owned snapshot fields match;
all ten repository documentation hostnames route to the intended machine;
the two application hostnames route to the intended machine when the Web service is running;
each machine uses its own tunnel and no tunnel replica crosses machines; and
no secret appears in Git, receipts, logs, snapshots, or Codex rules.

Rollback

Before Gate 3, source rollback is abandonment of the managed branch and draft PR. Machine-one rule rollback uses the installer's exact previous pointer and the recorded baseline checksum.

After Gate 3, source rollback is a revert of the single Phase 6 source PR. If the minimal rules are active, first restore the recorded pre-Phase-6 rules bytes and restart Codex, then revert the source PR. Do not hand-edit the active rules file.

Before machine-two packaged CLI installation, source-launcher rollback removes only the just-created launcher after verifying its previewed checksum and only if no packaged pointer or legacy target exists. After packaged installation, use anuva cli rollback --dry-run and --confirm; never delete targets to simulate rollback.

Plugin rollback uses the Phase 4 proven local marketplace reinstall procedure and only if plugin acceptance fails. Repository or rules failures do not authorize plugin downgrade.

Machine-two configuration rollback restores only the exact backed-up machine-local files created or replaced by the approved transaction. It never deletes repositories, user data, credentials, shared tools, Cloudflare objects, or an unrecognized pre-existing file.

Stop conditions

Stop and request a revised plan if:

Product Main baseline, working tree, or allowed paths differ;
the plugin identity, source/cache validity, or twelve-skill inventory differs;
an implementation requires src/**, plugin, marketplace, sibling, product, or historical-record changes;
a rule allows a wrapper, arbitrary runtime, file operation, Git mutation, or GitHub mutation;
a forbidden command is only prompted or a prompted wrapper is allowed;
the user-rules target changes between preview and confirmation;
a Codex restart loads a different rule hash;
source-launcher bootstrap finds any unrecognized existing install state;
CLI or rules rollback cannot be demonstrated before inverse rollback;
a toolchain action is not fixed by the committed manifest and preview;
a machine snapshot would expose a secret;
machine-two Cloudflare or Access state requires mutation;
a required check, strict documentation build, review, or route fails;
an exact reviewed PR head changes; or
Phase 6 cannot finish without beginning Phase 7.

Approval prompts

Gate 1 request:

Approve the exact Phase 6 Gate 1 Product Main source plan: rename the current planning branch to codex/development-policy-phase-6, add only the listed tracked minimal-rules source and closed rule/source-launcher tooling, update only the listed config, tests, instructions, and docs, run the complete source, packaged, rules, and strict-docs verification, and deliver one focused draft PR. Do not replace user rules, restart Codex, install or rollback the CLI or plugin, touch machine two, Cloudflare, Linear, sibling repositories, product code, PR readiness, or merge state.

Gate 2 request template:

Approve the exact machine-one rules install at the presented reviewed PR head and canonical SHA-256, followed by the specified Codex restarts, acceptance matrix, rollback to the recorded 134-rule baseline, inverse rollback to the minimal file, and evidence-only draft-PR update. Stop on any hash, decision, target, receipt, or scope difference. Do not change other Codex configuration, CLI, plugin, repositories, Linear, Cloudflare, PR readiness, or merge state.

Gate 3 request template:

Approve readiness and squash merge of the exact reviewed Phase 6 Product Main source PR head, followed by tree-equality verification and managed branch cleanup. Stop on any head, check, review, rules evidence, path, plugin, CLI, or rollback difference. Do not begin machine-two mutation.

Gate 5 request template:

Approve the exact Phase 6 two-machine transaction presented at Gate 4, including only its fixed toolchain actions, sanitized config changes, canonical rules lifecycle, exact CLI artifacts and rollback lifecycles, plugin 0.2.0 lifecycle, read-only Cloudflare and route verification, and non-secret snapshot comparison. Stop on any identity, checksum, action, route, Access, secret, or scope difference. Do not mutate Linear, Cloudflare, product code, sibling tracked files, or begin Phase 7.