Project Manifest v19: Filesystem I/O v3

September 24, 2026 ยท View on GitHub

Status: implemented with local conformance. Project v19 admits the private filesystem-io.v3 profile and its checked atomic-write route.

Audience: compiler, project-tooling, and standard-library contributors.

Project v19 selects the private filesystem-io.v3 profile. Its checked atomic write reports whether publication succeeded, failed before commit, or has an uncertain outcome. Project v18 and filesystem I/O v2 authority and wire contracts remain unchanged. See Host Operation Outcome v1 for operation and provider semantics.

Manifest

The standard-library package selects v19 through this canonical table manifest:

schema = "semaprax.manifest.v1"

[package]
name = "std-fs"
version = "0.1.0"
profile = "filesystem-io.v3"

[modules]
entry = "std.fs.examples"
sources = ["src/examples.spx", "src/fs.spx", "src/tests.spx"]
tests = ["std.fs.tests"]

[exports]
web = []

[command]
function = "std.fs.examples.roundtrip"

[capabilities]
required = ["fs.read", "fs.write"]

[dependencies]
std.io = "^0.1.0"
std.path.value = "^0.1.0"

The profile requires a private fn() -> bool command, explicit filesystem capabilities, and no public Web exports. filesystem-io.v3 is additive: the legacy filesystem-io.v2 profile and its file_write_atomic behavior remain unchanged. The v3 project schema is Project v19 and its semantic graph projection is V46.

Checked operation boundary

file_write_atomic_checked is admitted under FilesystemV3 and returns a checked publication value. Native callbacks and status are separate outputs; invalid or unwritten outcome values fail with status 5, while valid 0, 1, and 2 values are returned. The standard-library std.fs.write_atomic_checked wrapper maps those values to the fieldless WriteOutcome variants.

Wasm appends the import env.spx_filesystem_write_atomic_checked_v3 with seven i32 parameters, an i32 status result, and an out u64 value. The v3 status export is __spx_filesystem_status_v3; the v2 status export remains unchanged.

The physical provider reports 1 for pre-commit failure, 2 only for rename EIO where publication is uncertain, and 0 for known rename success, including cleanup failure after that success. These outcomes make no filesystem durability claim. The authoritative rename contract is the POSIX rename() specification.

Non-claims and acceptance

This document does not claim hosted-green or public filesystem-provider support. The local project harness filesystem_v3 gate executes the interpreter, native, and Wasm routes, the three valid outcomes, invalid and unwritten callback values, and nested path refusal. Provider and legacy filesystem regressions retain their separate owning gates. Network operations, durable job composition, and public Web exports remain outside this profile.