Crash-Proof Flash Filesystem

Filesystems for NOR flash live under constraints that desktop filesystems never face: writes only flip bits one way until a whole block is erased, blocks wear out after a bounded number of erase cycles, and embedded devices can lose power at any instant. A correct design must guarantee that power loss between any two operations never corrupts the filesystem, while spreading erases across the device and keeping RAM usage tiny.

The task workspace is derived from a production embedded filesystem, de-branded so the agent cannot simply recall the implementation: the test and bench suites define the behavior, and the agent has to reconstruct the design from what they pin down.

Implement the filesystem in Zig inside /app/flash-fs/, exporting C-compatible symbols (export fn, callconv(.c)) that match what the test suites call. Using @cImport to wrap existing C code is not allowed; the filesystem itself must be written in Zig.

• The tests/ suites are white-box: they read raw on-disk metadata directly, so correctness means reproducing the exact on-disk block-device state they pin down, not merely passing at the API surface.
• Survive simulated power loss at every point the suites inject it, across multiple block-device geometries.
• The benches/ suites measure bytes read, bytes programmed, and blocks erased; lower is better.
• Every suite runs under a fixed per-suite time cap that counts as failed if exceeded.

A ready-to-run Zig project at /app/flash-fs/: the correctness suites in tests/, the flash-I/O efficiency suites in benches/, an emulated block device, the test runner, and a build system driven by ./build_and_test.sh (all suites) or ./build_and_test.sh <suite> (one). The machine is offline; everything needed is preinstalled, including the Zig toolchain.

A clean-room verifier, separate from the agent's environment, rebuilds the submission and runs the hidden versions of the suites. The scored answer key is the reference implementation's per-permutation block-device checksums across four flash geometries, so credit requires a genuinely working filesystem that produces the exact on-disk state; a recalled description of the original design is not enough.

• Correctness comes from the hidden test suites; efficiency is scored on deterministic emulated-flash I/O counters (bytes read/programmed, blocks erased), not wall-clock time.
• Build failures, missing symbols, and anti-cheat violations zero the result.