Skip to content

test(DEN-1614): certify Windows zed develop process boundaries - #16

Merged
ORESoftware merged 32 commits into
mainfrom
agent/den-1614-zed-develop-windows-clean-room
Aug 4, 2026
Merged

test(DEN-1614): certify Windows zed develop process boundaries#16
ORESoftware merged 32 commits into
mainfrom
agent/den-1614-zed-develop-windows-clean-room

Conversation

@ORESoftware

@ORESoftwareORESoftware commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Linear

Summary

Adds the independent native-Windows consumer contract that DEN-1518 intentionally did not claim.

The workflow builds the immutable merged CLI commit on Windows Server 2022, imports no implementation test helpers, consumes no secret, contacts no registry or AI provider, and executes the real zed.exe through PowerShell 7 and cmd.exe.

Immutable candidate stack

  • merged zed-cli: fd3b3e487b2bdd129dd67403ad51f7299cfe6828
  • zed-interfaces: c2e049006453c26ca8ca291783f681fce75cb01f
  • flags-2-env: 2f62e40932a0fcb8b9bf1b4c84473e34fa3c51c7

Functional coverage

The external suite verifies:

  • byte-identical zed develop --print-env and zed dev --print-env output;
  • global options before the alias and nested project-root selection;
  • a real PowerShell profile fixture that loads without -NoProfile but is suppressed through zed dev -c;
  • PowerShell managed environment, project-root cwd, and child exit-code propagation;
  • cmd.exe managed environment, project-root cwd, and child exit-code propagation;
  • default shell resolution through COMSPEC with SHELL absent;
  • environment-only flags-2-env configuration and explicit CLI precedence;
  • project-local Python venv creation and Scripts activation through sys.prefix;
  • HOME and USERPROFILE isolation without copying fake Codex, AWS, GCloud, GitHub CLI, npm, or registry credentials;
  • no implicit .env, .envrc, production dotenv, or PowerShell-profile values;
  • bounded --no-install writes and no .zpkg.toml / .zpkg.lock creation;
  • missing-shell, invalid-enum, conflicting-mode, and redirected-interactive diagnostics;
  • retained-evidence canary scanning and clean source checkouts.

Semantic path assertions

Windows path identity is not reduced to string equality. The fixture starts in project/src/nested, which owns no manifest. PowerShell and cmd.exe must find package.json and the nested fixture from their own current directory, proving the child was launched at the owning project root even when canonical identity and process cwd use equivalent \\?\ and ordinary spellings.

Native cmd.exe harness

cmd.exe uses two fixed-name batch files created at the nearest manifest-owning project root:

  1. zed-develop-cmd-contract.cmd performs one native statement per managed-env, cwd, and exit assertion;
  2. zed-develop-cmd-launcher.cmd calls the assertion, captures ERRORLEVEL on the next statement, and returns it unchanged.

Zed executes call zed-develop-cmd-launcher.cmd. Relative fixed names avoid an incidental inner absolute-path quoting layer under /S /C; the test still exercises Zed's real /D /S /C arguments, selected cwd, managed environment, and exact child status propagation. A policy test rejects nested-caller batch placement, standalone quoted batch invocation, quoted absolute CALL, and loss of explicit ERRORLEVEL propagation.

Workflow-policy ratchet

The static suite contains 11 checks that reject mutable Actions, floating source pins, windows-latest, write permissions, secret or OIDC channels, persisted credentials, missing timeouts, unsafe artifact retention, cleanup-based masking, weakened locked builds, removal of the PowerShell/cmd/venv/profile/canary assertions, or regression from project-root relative cmd CALL plus explicit ERRORLEVEL capture.

Exact evidence

The final source head 144d17e28afa9586bc71ec43f340a0e0328a54b4 was checked out verbatim by the cross-organization Windows acceptance run 30903855437. That run:

  • passed all 11 imported workflow-policy checks;
  • built merged CLI fd3b3e487b2bdd129dd67403ad51f7299cfe6828 with the committed lockfile;
  • passed 19 real Windows assertions;
  • scanned every retained file for all 11 fake credential canaries;
  • proved the E2E, CLI, interfaces, and canary checkouts remained clean; and
  • uploaded exactly two bounded evidence files.

The report records:

  • assertion count: 19;
  • managed-environment SHA-256: 24903e36d446a5dbe15018a7ced801fbbb164ab7ca26149930b58fecfc4d9525;
  • credential_canaries_retained = false;
  • external_registry_required = false;
  • temporary_home_retained = false.

Artifact windows-develop-cross-org-30903855437-1 has ID 8890260522, size 1563 bytes, and ZIP digest sha256:f253e73fe7a3a6c2062b818ce6d45db6b8de9ee5b29fe7c996ddc9631bbaa2dd. The downloaded archive was independently scanned again and contained no canary value.

The primary repository's own final-head runs were queued for hosted-runner capacity, not failing. The exact source, product, policy, and retained-evidence boundary was nevertheless executed successfully by the purpose-built cross-organization release canary, which imports this commit without implementation helpers.

CI boundary

  • explicit windows-2022 runner;
  • contents: read only;
  • immutable Action and source revisions;
  • 40-minute timeout and concurrency cancellation;
  • fixtures and evidence under runner temporary storage;
  • evidence retained for seven days and scanned before upload;
  • source checkouts remain clean without reset or cleanup.

@linear-code

linear-codeBot commented Aug 4, 2026

Copy link
Copy Markdown

DEN-1614

DEN-1634

@ORESoftwareORESoftware changed the title test(DEN-1614): certify Windows zed develop shell boundariestest(DEN-1614): certify Windows zed develop process boundariesAug 4, 2026
@ORESoftware
ORESoftware marked this pull request as ready for review August 4, 2026 10:54
@ORESoftware
ORESoftware merged commit 6807fce into mainAug 4, 2026
3 checks passed
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@ORESoftware