Reconcile roadmap docs after merged foundations

[AviBackToBlack]

Summary

• reconcile the roadmap status snapshot with merged PRs Add managed pipx application profile and exposure #74–Add native Windows ARM64 CI #78
• mark RM-26 complete only because Add managed pipx application profile and exposure #74 is merged
• distinguish merged foundations from remaining overlay, signed-registry, image-trust, self-update, WSL, and ARM64 qualification work
• remove completed foundations from the recommended implementation queue while preserving their shipped contracts
• keep unmerged PR coverage explicitly non-authoritative for completion

The authoritative issue #2 was updated in parallel with the same merged-state facts.

Validation

• gofmt -l .
• go vet ./...
• go test -race ./...
• python -m unittest -v internal/registry/pipx_wrapper_test.py internal/cli/pipx_discovery_test.py
• git diff --check

---

[devin-ai-integration]

Devin Review found 3 potential issues.

[CherylSnowVeil]

Review summary

Docs-only reconciliation of the roadmap status after PRs #74–#78. I verified each merged-state claim against the current tree: the RM-26 completion (#74), enterprise-policy foundation (#75), RM-31 selection/check slice (#76), WSL fail-closed host boundary (#77), and native ARM64 CI (#78) entries are accurate, and the renumbered queue is consistent across both documents and the issue #2 status block. Two claims overstate what actually shipped.

Findings

[important] PR #78 did not ship "release plumbing" — RM-29 release work is silently dropped from the queue

docs/roadmap-decisions.md:26, docs/roadmap-decisions.md:256, docs/roadmap-decisions.md:296, docs/roadmap-implementation-requirements.md:72, docs/roadmap-implementation-requirements.md:314, docs/roadmap-implementation-requirements.md:650

The updated text claims "native Windows ARM64 CI and release plumbing" / "release-architecture plumbing" shipped in PR #78. That is not what merged:

• PR #78 touched only .github/workflows/ci.yml, README.md, and docs/release-matrix.md. Its own description states: "This does not add ARM64 release assets and does not claim Windows ARM64 support."
• .github/workflows/release.yml still builds only GOOS=windows GOARCH=amd64 and produces container-bin-VERSION-windows-amd64.zip — no windows/arm64 matrix entry, no per-arch artifacts/attestation.
• docs/release-matrix.md says the ARM64 job "publishes no ARM64" release assets/attestations and that support "remains gated on the RM-29 release work."
• The issue #2 status block updated in parallel correctly says only "native Windows ARM64 CI (#78)" — the docs go further than the source of truth.

Consequence: this document's own RM-29 "Required implementation" section still lists "Add an explicit windows/arm64 release matrix entry", per-arch cb.exe/checksums/attestation through the release workflow — none of which exists — while the recommended queue (docs/roadmap-implementation-requirements.md:659) now reduces RM-29's remainder to "real Windows-on-Arm + Docker Desktop qualification" only. A reader following the queue would conclude the release-matrix/release-workflow slice is already done.

Suggestion: drop "release plumbing" from these entries and keep the release-matrix/architecture work in RM-29's remaining scope (e.g., "native hosted ARM64 CI shipped in PR #78; release matrix entry, per-arch artifacts and real Windows-on-Arm + Docker Desktop qualification remain").

[important] Enterprise-policy claim overstates shipped scope — no host-mount/environment controls exist

docs/roadmap-implementation-requirements.md:478 ("PR #75 shipped the machine-owned policy foundation: … and restricted host-mount/environment controls")

The merged policy schema v1 (internal/policy/policy.go) supports exactly policy_version, require_lock, allow_local_images, allowed_repositories, and expires_at; the parser fails closed on any other key. docs/enterprise-policy.md and PR #75's description document only mandatory locks, local-image exceptions, and canonical repository allowlists, and every enforcement point (AuthorizeImage, AuthorizeResolvedImage, AuthorizeLockTarget, authorizeRegistrySnapshot) is image/lock authorization — there is no policy-level control over host_mounts or env_names/env_prefixes.

Consequence: follow-up slices (overlays, image trust) would be designed against a policy boundary that does not exist; a reader could assume schema 1 already restricts mounts/environment when those knobs are registry/overlay concerns today.

Suggestion: remove "and restricted host-mount/environment controls" from the shipped list, or explicitly note such controls as remaining follow-up scope.

Notes

CI checks were still pending at review time; this does not affect the findings above, which are documentation accuracy issues verified against the merged code.