The first CI run: Linux code executes for the first time, and a Windows test assumes one drive

What was done

A private GitHub repository was created and the main branch, holding Phases 1 and 2, was pushed. The push triggered the first CI run the project has had: four jobs across Linux and Windows, completed in 4 minutes 48 seconds. Three passed, among them the Linux Rust job, where the Linux hardware providers ran for the first time, as root, on a GitHub-hosted Ubuntu runner. The Windows Rust job failed on a single test; the failing log was read, the cause traced to the test's own premise rather than the product code, and the failure classified as a test defect.

 GitHub-hosted Windows runner
   checkout       D:\a\...        (job log)
   temp directory another drive   (panic message)
 
 the test builds a RELATIVE path from the
 current directory to the temp directory:
   shared leading components = 0
 
 Windows has no relative path between drives,
 so the test's helper panics before any write.
 On the development PC, one drive: it passed.

The failing test never reached the store code it was written to check; its premise was wrong.

Status

Ran 4 October 2026, 00:15 to 00:20 BST (23:15 to 23:20 UTC on 3 October): CI run 37161206756 on commit f4a0b67. Conclusion: failure, three of four jobs passed.

Why this run mattered

Until this point the CI workflow had been written but never run, because no remote repository existed. So the Linux providers had never executed, only been type-checked, and two protections from Phase 2 had never run where they are meant to: the Linux real-hardware step that runs as root, and the registry test that stops a stable schema being edited in place.

The owner, Stephen Ukaegbu, decided the repository would be private and asked for the push. The diagnosis was carried out by Anthropic's Claude Code, working as lead engineer.

The four jobs

What it showed

The Linux code ran, and passed. The Linux providers and the Linux strong-identity path executed for the first time. GitHub-hosted runners are virtual machines, so these real-hardware tests ran against virtualised hardware, not a physical machine.

The registry protection now runs in CI. The test that Phase 2 showed to be the only defence against an in-place edit of a stable schema ran for the first time in CI, comparing against the previous commit, and passed.

The counts reconcile. The Phase 2 gate lists 26 core-library tests; Linux CI ran 25, because the drive-dependent test is compiled only on Windows. CI's 949 TypeScript tests are the 948 from the local gate plus the registry test that had to be skipped before the commit existed. The verifier's 138 files are the 133 generated fixtures plus 5 READMEs.

The failure

One Windows-only test, which checks that long, relative and forward-slash paths can all be written, panicked with the message that the temporary directory is on another drive than the current directory. The test built a relative path from the current directory to a temporary directory. The job log shows the checkout on the runner's D: drive, and the panic places the temporary directory on another drive. No relative path can cross drives on Windows, so the premise of the test, not the store code, was wrong. The same test passed in the local Phase 2 gate on the development PC.

The coverage this cost. Cargo stops at the first failing test binary, so after the core library the remaining Windows test binaries did not run in this job. Windows CI evidence from this run is therefore partial.

The correction. The test was changed to create its temporary directory under the current directory, with a comment explaining the drive split on the runners. At the time of this record the change was in the working tree, not yet committed, and its effect on CI had not been demonstrated.

Also reported

The run's annotations noted that three of the GitHub Actions used target the deprecated Node.js 20 runtime and were forced onto Node.js 24.

Open questions

Whether the corrected test, and the Windows test binaries that did not run, pass on a GitHub runner had not been shown at the time of this record.

The code

The helper that failed: it walks the shared leading components of the current directory and the target, and asserts there is at least one. Across two drives there are none.

/// A path relative to the current directory that names `target`, through `..` components.
#[cfg(windows)]
fn relative_to_cwd(target: &Path) -> PathBuf {
    let cwd = std::env::current_dir().unwrap();
    let (cwd, target) = (cwd.components().collect::<Vec<_>>(), target.components().collect::<Vec<_>>());
    let common = cwd.iter().zip(&target).take_while(|(a, b)| a == b).count();
    assert!(common > 0, "the temporary directory is on another drive than the current directory");
    let mut rel = PathBuf::new();
    for _ in common..cwd.len() {
        rel.push("..");
    }
    for c in &target[common..] {
        rel.push(c);
    }
    rel
}

Not shown. The corrected test is not quoted, because at the time of this record it was not in any commit. The CI workflow's root step, the runner identifiers in the job logs and anything about repository access are withheld.