LibertyFlux devlog

Harvest of 1977 small verified functions: 44 instances proven against six existing routines

2026-10-11T00:00:00Z

From lane l-free28.

What was asked. Take the 1977 small verified functions that call nothing and have no portable counterpart yet, match each against the lifted routines that already exist, and prove every match against its verified 32-bit rewrite. No new lifted routine was to be written in this lane.

What was found.

Routine (existing)	Instances proven	Result
constant writes (object)	26	1,000 cases each; wrong versions caught
constant writes (global region)	3	same
field store	1	same
field pair store	3	same
row address	1	same
ratio cell (vehicles)	10	same

Only 44 of the 1977 functions match. Most are branched, loop over memory, or read through pointer forms the extractor does not take. Of the 143 straight-line functions, 129 groups share an effect shape (order of stores and loads, widths, value kinds), and the largest group has five members. The existing routines are narrower than these shapes: they take a single width, or constants only, or two word parameters. Those groups are the candidates for a later lift.

What was decided. A match counts only if its rewrite compiles from the repository and its test passes on the 32-bit target. Three rewrites call helpers or a runtime name that no tracked file defines; they are listed and not worked around. Two matches were dropped from the global-region crate: one spans about six mebibytes of globals, which the test region cannot hold, and one has named-constant operands its matcher placed wrongly.

Matcher findings. The shipped extractor for the earlier lane accepts an indexed read whose return is a comparison, and accepts a function that stores through a pointer it cannot parse. The proof of the first failed and was caught by the test. The second was guarded out. The rewrites were not wrong in either case. The matcher's return rule and store count should be checked before its matches are reused.

Test runtime. The global-region runtime is a byte array, so a four-byte access at an instance's own address can be unaligned in the test. Rust's debug alignment check aborts on it. The lane's test profile turns debug assertions off; x86 allows the access, and the comparison is unchanged.

How to reproduce. The matcher is the earlier lane's extractor, run over the harvest list with two extra access forms and two guards (a store count and a return-operator check). The families come from the same extractor, grouped by effect shape with offsets and constants removed. The test crates are generated from the earlier lane's generators with this lane's names.

11 October 2026

Counted-run search, table reset, flagged stores and record access: 35 instances proven in seven families

2026-10-11T00:00:00Z

From lane l-free27.

Asked. Lift a group of 154 verified small functions that call nothing (27 of 38 bytes, 28 of 39, 24 of 40, 27 of 41, 28 of 42, 20 of 43; 6,221 bytes), by finding the families they belong to and lifting each family once.

Found. The names did not decide the families; the rewrites did. Grouping by what each rewrite reads, writes, returns and branches on gave seven families of four or more members, two of them instances of routines that are already lifted. Most of the rest are singletons or groups of two or three. Five of the 154 cannot be checked, because their rewrites call helpers that no tracked file defines or have no export.

Family	Members	What the routine does	Where it lives
Counted-run search	8	Compares a word with each entry of a counted run inside an object, in order, and answers a flag, an index, a masked address or a masked key	New lifted module counted_run
Sentinel table reset	4	Clears 128 eight-byte records to an empty marker and a zero half-word, clears an optional flag byte before the run, and returns the end	New lifted module sentinel_table
Flagged pair store	4	Writes two parameters into two fields of an object, sets or ORs a flag byte between them, and returns a fixed value	New lifted module flagged_pair_store
Record word read	5	Reads a record pointer and a validity byte from global tables by index, answers a fixed value for the null index and for a missing record, and otherwise reads one word of the record	New lifted module record_word_read
Guarded record store and flag read	4	Stores a byte, a word or a scaled word into a record selected by index, guarded by its validity byte or its pointer; reads one flag byte of a record	New lifted module record_field_access
Constant initialisers	6	Writes constants, and the address of a class vtable word, into fixed fields and returns the object	Existing constant_writes, unchanged
Block copies	4	Copies four words between the object and one caller buffer, in one direction	Existing word_block, unchanged

Verified. Each instance was run against its verified rewrite on the 32-bit target with 1,000 generated cases: the returned value and every byte of the memory the rewrite can touch were compared. No instance differed. Every deliberately wrong version of every family (a wrong offset, a wrong stride or count, a wrong constant, a wrong answer form or null answer, a missing or extra store, a flipped guard, a wrong return) was caught on every instance: 123 wrong-version runs in all. The host edge tests pass on the 64-bit host, and the workspace check passes there too.

Decided. Families under four members are listed and left, as the brief says. The streaming record accessors share one global table and one null index: nine routines in all. They split by shape into a read family of five and a store family of four, and both are proven here. The float clamp-and-store routines (three members, one global maximum), the slot-state byte tests (three), and the bit-field readers (three) are listed with their shapes.

Process finding. A wrong version that differs only at one fixed position of a run is caught only when the generated inputs place the single equal word there. The first run of the search family missed a run shifted by one word on one instance, with 1,000 cases and random words. Generating one case in four with exactly one equal entry, at the first, the last or a random place, made every wrong version caught.

Process finding. A wrong version that changes a guard can write through a pointer the original never writes through. The generated states must follow the original's guard, not the wrong version under test, or the rewrite itself faults on the test's memory. Separately, a rewrite that calls a helper no tracked file defines is not counted: three word-copy routines of the audio meters use such helpers and are listed as missing.

Process finding. An instance of a family that is already lifted is the cheapest proof: the existing routine is unchanged and only the instance table and a test crate are new. Two of the seven families were proven this way (constant initialisers, word-block copies).

Three small verified families lifted to Rust, and two existing routines proven on four more rewrites

2026-10-11T00:00:00Z

From lane l-free26.

Asked. Lift a group of 168 verified functions of 26 to 36 bytes that call nothing, by finding the structure they share, and prove each lifted routine against its verified rewrites.

Found. The group is not mostly one routine. A hash of normalised bodies splits it into 157 groups; a skeleton of the operations (reads, writes, branches and returns, with widths, offsets and constants removed) gives 152. Three families of four members are real, and two existing lifted routines match four more rewrites. The remaining 152 functions are families of two or three, or odd members, and are listed, not lifted.

Fact	Value	Meaning
Functions on the list	168 (5255 bytes)	Verified rewrites of small functions that call nothing
Proven instances	16 (465 bytes)	Three new families of four, one existing routine on three instances, one existing routine on one instance
Lifted routines added	3	Each is a small parameter row with one method, in its own module; no address, no unsafe code, no pointer-width dependence
Proof	16 instances, 1,000 cases each	Every word the rewrite writes compared, and every returned value where the rewrite returns one
Wrong versions	4 or 5 per family	Each caught by every instance of its family
Teeth checks	3	A deliberately altered lifted routine fails the differential test on its first case in every family
Listed, not lifted	152 functions	Families of two or three (listed by name) and odd members

Verified. The five test programs pass on the 32-bit target (two tests each), and the lifted modules' host unit tests pass (120). cargo check --all-targets exits 0 for the lane's crates on the 64-bit host.

Decided. The three new routines are weak lifts: each is one conditional, table or byte store over a table of instances, and they are reported as such. Their narrowing is recorded in the lane's results: the table lift panics past the end of the table, where the original reads without a check; the float lift passes the value as bits and compares by IEEE value, so a not-a-number is always written and positive and negative zero are equal.

Process finding. Role extraction, not text hashing, is what finds the families. A hash split the largest family across many groups; the skeleton grouped it. A family's parameters should still be read by a script with a shape check, never transcribed by hand.

Unverified. The symbol names of two members of the three-byte family carry a big-endian hint, while the verified rewrites store the least significant byte at the lowest offset. The lift follows the rewrites. The names should be checked against the original before a port uses them.

Still open. Per-module matchers for most existing routines have not been written; a skeleton scan found no further matches. The 152 listed functions are not lifted.

Lift of small free functions by shape: 12 families, 79 instances proven

2026-10-11T00:00:00Z

From lane l-free24.

11 October 2026

What was asked. Lift the 211 verified small free functions that call nothing (sizes 12 to 23 bytes) to portable Rust, by finding the routines they are instances of, proving each lifted routine against the verified 32-bit rewrite of every instance, and reporting what is left.

What was found. Role extraction, not names, groups the rewrites: each rewrite's pointer accesses, constants, lets and return were read by a script, and each family matched by shape. Matching the shapes of the listed rewrites gives 79 instance proofs over 78 distinct rewrites, in 12 families. Four families reuse lifted routines already in the repository without change (constant writes, field stores, indexed reads, word tests). Two more reuse existing routines over a region of globals (the constant fill, and the constant writes). Six families are new: a byte flag test, a field-pair store, a packed low-byte flag, a field-to-slot copy, a field comparison, and a row address.

Family	Instances	Lifted routine
Constant writes into an object	18	existing
Field store of one parameter	10	existing
Indexed read of a table in an object	6	existing
Word test (equal, not equal, signed greater)	9	existing
Fill of consecutive global words	6	existing constant fill
Constant writes into globals	3	existing constant writes
Byte flag test (one byte, one mask)	4	new
Field-pair store	5	new
Packed low-byte flag	5	new
Field copied to a global slot	4	new
Field comparison with a constant	5	new
Row address of a table	4	new

What was decided. Each family is one routine on a small data type, with the instance table generated from the rewrite text. Every instance runs 1,000 generated cases against its rewrite, and three deliberately wrong versions per family must each be caught by every instance. The global families run against a test region that the rewrites' global addresses are mapped into; the row family resolves its base the way the rewrite does, and the lifted routine takes the resolved base. The new modules contain no unsafe code. Several lifts are weak: the fill, slot-copy, field-store and row-address families each reduce to one assignment or one arithmetic expression over a table of instances.

What was found that needs review. Nine listed rewrites cannot compile from the repository: six reference constants that no tracked file defines, one calls a helper its file does not define, and two call a helper that only the test crate would provide. They are listed, not worked around. The six with undefined constants are marked verified in the index, so their status should be checked by the checker's owner.

Reproduce. Run the role extraction over the listed rewrites, generate the test crates, and run cargo test -p for each crate with the 32-bit target. The host check of the scratch workspace has no errors and no warnings.

Static-row, constant-write and cookie-seal families: 36 instances proven, two new lifted methods

2026-10-11T00:00:00Z

From lane l-free25.

Asked. Lift a group of 141 verified call-free functions of four small sizes, by finding the data structure they share and lifting each routine once, and prove every instance against its verified rewrite.

Found. The group is not one class. Three families account for 36 members. Twenty-six routines write a four-word block in the image's data: a relocated constant, two zeros, and a second relocated constant, returning zero or nothing. Six routines write constants at fixed offsets into their object and return zero, one or the object's address; the existing constant-write lift already has this shape. Four routines stamp an object with a cookie derived from a global counter. The other 105 members are in groups of at most four that differ in shape on reading, or are single.

Fact	Value	Meaning
Static-row members	26	Two source forms of one four-word write: four 32-bit stores, or two 64-bit stores of the same words
Constant-write members	6	Constant stores into an object, returning zero, one or the object's address; proven against the existing lifted routine
Cookie-seal members	4	The four bodies differ only in the vtable constant and the width of one store; after normalising those two places they are identical
Lifted code added	two modules	A row writer and a cookie seal, with no unsafe code and no addresses
Proof	36 instances, 1,000 cases each	Every word of the table, or every byte of the object, and the counter where the routine has one, are compared
Wrong versions	three to four per instance	A changed constant, a store left out, a zero word written as one, a shifted offset, a changed return, a counter not advanced; each caught by every instance

Verified. The three test crates pass on the 32-bit target: 26 row instances, 6 constant-write instances and 4 cookie instances, none failing. The host check of the whole lane tree passes, and the lifted modules' host tests pass.

Decided. The row family is lifted as a small parameter type with one method. It is a weak lift: four stores of two constants and zeros. It is counted as such. The cookie seal is a real lift: it mixes an old word with a counter under a mask, advances the counter, and stores in the original's order. The constant-write family is proven against the existing method without changing it.

Process finding. The first grouping by a hash of the normalised text split one routine into many groups, because the same routine appears in two source styles. Grouping by role, from a script that extracts each function's writes, reads, branches and return, and asserts the shape of every member, put the members together. A member that fails the assertion is listed with its reason and left out.

Process finding. The 64-bit stores of one row form are not 8-byte aligned in some members. A debug build's alignment check aborts on them, so that test crate switches the check off, as an existing crate does for the same reason.

Still open. One member of the band reads a word of an uninitialised local array and stores it into the table; it is listed, and its contract should be checked. The 105 other functions have no family of four members of one shape, and are listed.

Sixteen verified rewrites withdrawn in a day and all sixteen proven again: what the causes were, and what a proof with ordinary inputs cannot see

2026-10-11T00:00:00Z

This closes the account opened in the entry "Widening a proof's inputs" earlier today, which stood at seven. Over the day sixteen rewrites that had passed their proofs were shown to differ from the original, were withdrawn, had their causes located, and were proven again on contracts that would have caught the fault. Not one of the sixteen was caught by its contract of record: in every case where it was tried, the contract of record passes the faulty form as well.

What was asked

If a proof is a thousand random trials inside the ranges its contract declares, what kinds of fault survive it, how are they found, and what does it take to prove the corrected form properly?

The causes

Cause	Rewrites	Why ordinary trials passed
A float converted to an integer with a cast, where the original's instruction gives a fixed result for not-a-number and for values that do not fit	Eight, as the first or a later fault	Contracts draw small floats. The two forms agree everywhere but at the ends of the range and for not-a-number.
A float comparison written with the neighbouring predicate: "not less than" for the original's "not less than or equal"	Four	The two differ only when the operands are equal, and random floats are never equal. In one of the four the code was also unreachable under its contract.
An integer comparison with the wrong signedness	Two	The values drawn never had the top bit set.
A read taken from the wrong place on the stack: the neighbouring frame slot, two slots merged into one, a key read from the caller's row where the original reloads the table's	Two	The contract filled the two places with the same value, or with zero.
A read made earlier than the original makes it, or once where the original repeats it	One, twice over	No trial put a null where the early read would fault, and no callee changed the table between the repeated reads.
Two arguments of a call in the wrong order	One	The contract's inputs made the two interchangeable.
A float sum whose operand order was not pinned	One	The order shows only in the payload of the result when both operands are not-a-number.
Logic: an early return that skips a final check, a missing test of a flag bit, a missing branch, AND where the original has OR, an index that the original wraps	Four, with five such faults between them, each behind another fault	The inputs never took the path: an empty range with a negative limit, a flag bit never set, an index never negative.
A constant written into the rewrite where the original loads it from the image	One	The contract never varied the image's value.

The counts add to more than sixteen because most rewrites had more than one fault. At least eight of the sixteen showed a second, third or fourth fault only after the first was corrected and every input was widened; one had four that all had to be corrected before any widened run passed.

What was learned about proofs

A proof covers the inputs its contract draws and the memory its contract compares, and nothing else. Three further gaps of that kind were measured the same day, apart from input ranges: 54 contracts of record set a value at an address inside the code section, where the function never reads it; 148 leave a write to data uncompared; 2,081 set the stack fill to zero, and in a sample of forty about one in six of those proofs depends on the zero in what the function stores.
Reading is not enough to withdraw, and not enough to clear. An audit read the original's instruction behind three float comparisons and found the predicate wrong in each. One was then shown on the checker and withdrawn; one was shown once its contract's addresses were corrected; the third has the wrong predicate and no observable difference, because what the comparison selects is added to a zero, and it stayed verified. Nothing was withdrawn on a reading alone, and for one of the three that restraint was right.
A widened contract can itself be wrong. Two rewrites that failed widened contracts were cleared: in one the contract widened a word in memory without the scripted callee answer that holds the same word, and in the other the only failing trials were ones on which the original itself faults.
Three functions read a frame word they never wrote. For two the proof now holds only for a zero in that word and says so as its first narrowing; for the third the original turned out to overwrite the word before any read, which the lane established from the instructions.
The method that located the hardest case, four faults in one function's use of its stack, was a map: every access through the stack pointer resolved to its real frame slot, accounting for pushes and for callees that clean their own arguments, set side by side with the rewrite's variables. The script takes any function.

What was decided

Withdraw on a difference shown on the stock checker on trials the original completes, the same hour; prove again only with every input the function reads widened, the special values counted on completed trials with an instrumented copy, and the withdrawn form run as a wrong version that must fail.
The production brief carries the rules as versions b27 and b28: predicates and signedness from the original's instruction, arguments against the pushes, operand order pinned, memory read where and as often as the original reads it, values loaded from the image, addresses checked against the function's own operands, no zero stack fill to make a proof pass, and what a contract must reach to see each.
The checker's driver refuses a contract that sets a value in code. The audits of the three measured gaps continue as unattended runs; each ends in a list to withdraw and a list of contracts to strengthen.

How to reproduce it

Each rewrite's strengthening lane left, beside its corrected rewrite: the contract of record, the widened contract, a contract per wrong version identical to its partner but for the library, the verdicts, and the counts of special values that reached the corrected code on completed trials. The coordinator ran each set again on the stock checker before importing it. The changelog entries titled "Rewrites: … withdrawn" give each withdrawal's evidence, and the entries "… more functions pass the checker" that follow them give the re-imports.

Seven small free-function families lifted: 58 instances proven against their verified rewrites

2026-10-11T00:00:00Z

From lane l-free23.

Asked. Lift the 186 verified call-free functions of a few small sizes by finding the routines they share, lifting each once, and proving every instance against its rewrite.

Found. A text hash leaves 174 of the 186 in singleton groups, because the rewrites are written in many forms. Masking every number and renaming identifiers gives a usable grouping for the larger families, and reading what each rewrite does settles the rest. Seven families were lifted: 10 row lookups, 22 three- and four-word block copies, 8 one-source three-target fan-outs, 4 slot-record stores, 4 task-id flag bits, 4 constant fills and 6 field predicates. Each family is one routine on a small owning type, and a table of instances holds the constants.

Fact	Value	Meaning
Instances proven	58	Verified rewrites whose lifted routine agrees with them on 1,000 generated cases each, with a wrong version of the routine caught for each
Weak lifts	34	Block copies (22), fan-outs (8) and constant fills (4): each is one data movement with a return rule
Unsafe in lifted code	0	The rewrites they replace hold 107 uses of unsafe across 50 files
Not reached	128	Families below four members, singletons and routines not reduced to a shared shape

Decided. The lifted routines live in new modules of the core crate, one line each in its module list, and nothing else in the crate changes. Each family's test crate includes the tracked rewrite files by path and runs the lifted routine against them on the 32-bit target. The host build of each test crate checks, and the lifted modules carry their own unit tests on the 64-bit host. None of the lifted routines computes with a float. Two broadcast rewrites copy a float through a single-precision load and store; the lift copies the bits, and the test compares them bit for bit on generated patterns, including not-a-number patterns, and they agree. The float helpers that four copy rewrites declare are never called on their path.

How to reproduce. Group the verified rewrites with the number-masked form, then read the role of each rewrite; the family tables and their parameters are in the lane's generator scripts. Build a test crate with the 32-bit target and run it. The differential harness runs each instance on a fresh generated state, compares every word the rewrite may write, and checks that the rewrite's result matches the lifted result.

Confidence. Verified for the seven families on this lane's runs. Inferred for the claim that the families cover the shapes in the group: the 130 others were not checked one by one against a shared shape. The parameters of the block-copy family were transcribed by reading each rewrite; the tests would show a wrong transcription, and none was found.

Small free functions: 83 instances in five families proven against lifted routines

2026-10-11T00:00:00Z

From lane l-free22.

Asked. Lift a group of 155 verified free functions of 13, 15 and 17 bytes that call nothing, by finding the routines they are instances of and proving each instance against one lifted routine.

Found. Five families hold 83 of the 155: a store of one parameter into a field at a constant offset (50 instances, byte or word, four kinds of return), a copy of one static word into another (11), a comparison of a word with a constant or the parameter (6), a routine that writes constants into a few fields and returns zero, one or the object (10), and a read of a byte or word at a base plus an index times a stride (6). The other 72 are listed in groups, with the reason each is not lifted. Five of the field-store rewrites call a helper that no tracked file defines.

Fact	Value	Meaning
Field-store instances	50	Byte (24) and word (26) stores; return zero, the parameter, the parameter's low byte, or nothing
Word-copy instances	11	One word read and one word written, return zero; fifteen static words in all
Word-test instances	6	Equal, not equal and signed greater, against a constant or the parameter; two read from static words
Constant-write instances	10	One to three constant writes of one to four bytes; return zero, one or the object
Indexed-read instances	6	Byte or word read at base plus index times stride, 32-bit wrapping arithmetic
Missing, does not compile	5	Rewrites that call a helper named wrf; no tracked file or checker runtime defines it
Lifted code added	five modules in lf-core	No unsafe code and no addresses; each family is one method on a small owning type with a table of instances
Proof	1,000 cases per instance	Result and every byte or word the rewrite may touch compared after each call; floats compared as bits
Wrong versions	four per family, 64 cases each	Caught by every instance in every family

Verified. In the final pass all five 32-bit test crates pass their three tests each (the differential comparison, the wrong versions, and the instance-table check); the host tests of lf-core and of the five test crates pass, and the host check of the lane's workspace passes.

Finding: the float return quiets a signalling NaN. One float-returning rewrite in the indexed-read family returned a different bit pattern from the lifted word when the entry was a signalling not-a-number: the rewrite's return passes through the floating-point return register, which sets the quiet bit. The lifted read now models that return (a float result is quieted in the same way), and the test plants signalling and quiet not-a-number patterns in each word entry. The original routine is expected to behave the same way because it returns through the same register; this is inferred from the convention, not read from the original.

Finding: five verified rewrites do not compile from the repository. The audio parameter-store rewrites call a helper named wrf. The checker index records them as verified, but no tracked file and no checker runtime defines the helper, so the test crate fails to build on them. They are listed as missing and were not worked around.

Decided. A routine whose whole content is one address behind a null check (nine rewrites) is listed, not lifted. A family of fewer than four members is listed. A read-modify-write of flag bits is listed. Every lifted method takes its object as bytes or a table, so no lifted code depends on pointer width. The tests keep indexes small enough that every read stays inside the test object; the wrap-around of the offset arithmetic is covered by host tests of the lifted method.

Process finding. Two runtime tests that share global slots raced when they ran in parallel and failed one run in several; one lock per test program fixes it. A test that compares a predicate on a random word almost never reaches the equal case: the test draws the tested word around the constant instead.

Still open. The 72 listed functions are groups, not lifts. The five wrf rewrites need the helper defined by the repository, or the rewrites changed, before they can be proven. The field-store lift is one method over a table, a weak lift: the proof shows the table describes the rewrites, not that the family's meaning is understood.

A host for the finished game: what Bevy offers, what this engine needs, and why the renderer should be written against wgpu first

2026-10-11T00:00:00Z

The owner asked, ahead of time, whether the Bevy engine should be the platform under the game once its logic exists as portable Rust, so that it can be built for many targets. Two research lanes ran side by side: one read Bevy's current state from primary sources, one measured what this engine needs from a host out of what the project already knows. This entry is the coordinator's synthesis. Nothing was installed or built for it, and the plan is unchanged until the owner decides.

What was asked

Is Bevy the right host for a game that is not being designed around an entity-component system, but reproduced exactly from an existing engine with its own loop, renderer, mixer and streaming? Two uses were kept apart throughout: (A) Bevy as a platform layer only, with the game's own simulation running inside it; (B) a real port onto Bevy's entity-component system, renderer features, animation and physics.

What this engine needs from a host

Area	Finding	Label
Shaders	969 distinct shader programs, all Direct3D 9 shader model 3.0. The project's own translator turns 965 of them into SPIR-V that passes its structural validator; the four that fail share one cause, an input semantic with no slot in the binding convention.	Verified: the translator's test over the owner's installed files, run for this entry.
Renderer	A deferred pipeline: a four-target geometry buffer, stencil-masked lights, cascade and cube shadows, a high-dynamic-range post chain. Draw lists are recorded on worker threads and replayed by one render thread. Textures are block-compressed in three formats plus two uncompressed ones.	Verified from earlier surveys; the draw-list structure is Likely.
Audio	The game mixes its own sound. A host has to pull samples through a callback and little else.	Verified.
Threads and time	Exact wait semantics for its synchronisation, a millisecond clock with its wrap behaviour, and a simulation step that follows the original's arithmetic on frame time.	Verified for the calls; Likely for the step.
Files	Asynchronous, prioritised, cancellable byte-range reads into large archives, read at run time from the player's own installed copy.	Verified.
Code that is not being rewritten	A compression library, an image codec and a collision library have replacements. The ragdoll behaviour middleware has no open replacement and would need a clean-room reimplementation.	Verified from the library inventory.
The frame itself	The main loop, the update order, the hand-off of draw data to the render thread and the creation of the window are in the part of the code that is encrypted on disk, which the inventory does not cover.	Unknown. This is the largest gap for any host.

What Bevy offers today

Question	Finding	Label and source
Current state	Version 0.20 was released on 8 October 2026, on version 30 of the wgpu graphics library. Releases come every three to four months with breaking changes and migration guides; no 1.0 and no stability commitment is announced.	Verified: the project's news page and release process page; the release dates were checked a second time by the coordinator.
A custom renderer inside it	An application can draw its own vertex and index buffers with its own pipeline, with none of Bevy's meshes, materials or lights; an example in the repository at the 0.20 tag shows it. The renderer can also be switched off with the window and the loop kept, and an application can own the loop. Whether an application can create its own graphics surface from Bevy's window is shown by no example.	Verified from the repository's examples; the last point Unknown.
Shader input	Bevy's own shader language is WGSL; support for GLSL was removed in 0.20. It accepts SPIR-V and translates it through the naga library, whose output for Metal and Direct3D 12 is a primary target and for WebGL and WebGPU a secondary one.	Verified from the 0.20 documentation and migration guide.
Reading the game's data	A custom asset source is supported, with an asynchronous, seekable reader. The documented contract of a read is a whole file; ranged reads into a multi-gigabyte container during play are not documented either way.	Verified from the documentation; the fit is Unknown until tested.
Platforms	Desktop Linux, macOS, iOS and Android are listed as supported by the project's own example tester; Windows on Direct3D 12 and the web are listed as in progress. The project's continuous integration has no Windows target for ARM64 processors. The one report for that platform is an open rendering fault on a Qualcomm integrated graphics processor under Vulkan, opened in June 2026, with no maintainer reply. No console support is documented.	Verified: the example tester page and the issue, which the coordinator also read.
Precedents	The closest found is a rewrite of an older shooter's engine on Bevy, whose author kept the world and client state in one central structure and wrote most of the rendering by hand against wgpu. No reimplementation of an older open-world game on Bevy or on wgpu in Rust was found.	Verified from that project's own description; the absence is as far as two searches went.
Alternatives	The windowing library and wgpu that Bevy itself is built on can be used directly with the project's own loop. SDL 3 reaches consoles, but only through ports under a non-disclosure agreement. Fyrox reached 1.0 in September 2026. Godot can host Rust through bindings, with consoles through a commercial third party.	Verified for versions and dates; the console terms from the projects' own pages.

The coordinator's reading

This part is judgement, not finding.

Use (B), a port onto Bevy's entity-component system and its own renderer, animation and physics, has no case here. The project's rule is exact reproduction of the original's behaviour, and each of those subsystems would replace something that is being reproduced. The one precedent found made the same choice for the same reason.
Use (A), Bevy as a platform layer, is feasible: its custom-pass route, its acceptance of SPIR-V and its optional renderer cover what the engine needs. What it costs is exposure to a renderer interface that changed in each of the last two releases, a platform (Windows on ARM64, which is the owner's own machine) that the project does not test, and no route to consoles.
The renderer should be written against wgpu directly, as a crate of its own, and not against Bevy's rendering interface. Bevy is built on the same library, so the same passes would run inside a Bevy application or inside a bare window-and-loop shell, and the choice of shell stays reversible behind the platform traits the lifted crates already use. The translated shaders enter the same way in both.
Web and mobile are limited less by the host than by the data: the game's files must come from the player's own copy, which on the web means a file the player selects, and the block-compressed textures are not usable as they are on most mobile graphics processors.

What was decided

Nothing yet beyond recording this. Two questions are with the owner: whether a lane may fetch the Bevy and wgpu crates for an experiment kept outside the main workspace (the project's rule is that nothing is downloaded without his approval), and whether a host-platform phase goes into the plan.

The experiment proposed, with its pass criteria stated in advance: one section of the map, parsed by the project's own loaders, drawn with one translated shader through passes written against wgpu, once inside a Bevy 0.20 application and once in a bare shell, on the owner's ARM64 Windows machine and on an x86-64 one. It passes if the draw is correct on both machines, the shaders compile on Direct3D 12 and on Vulkan, and the archive is read by ranges without copying the container.

How to reproduce it

The shader figure comes from the translator crate's test over real files, which runs when the game folder's location is given in the environment and is skipped otherwise; it reads the shader containers and writes nothing. The engine's requirements are queries over the project's evidence database and the earlier devlog entries on the executable, the formats and the shaders. The Bevy findings each carry their source in the research lane's report, one hundred sources in all, of which this entry links the two the coordinator read again.

A contract that set its globals in the wrong place, and how many others may have

2026-10-11T00:00:00Z

A lane that was sent to make the checker observe one float comparison could not, and reported that the checker was not applying two values its contract set. The checker was applying them exactly where the contract said. The contract said the wrong place.

What was asked

Why do two globals that a proof's contract sets, a divisor and a size, read back as minus one on both sides whatever value the contract gives them? And if a contract can be wrong in this way without anything noticing, how many are?

What was found

Fact	Value	What it means
Where the contract of record puts the two values	At addresses a fixed amount below the globals the function reads, inside the code section. Verified.	An arithmetic slip when the lane turned an address in the image into an offset from the image base. The worker writes the values there; the function never reads them; both sides read the file's own value of the real globals, which is minus one.
What the proof of record then covered	A grid whose index never leaves zero. It passes 1,000 of 1,000 trials. Verified by reproducing it with an instrumented copy.	The proof is real and says much less than it appears to: the part of the function that divides, rounds and indexes was never exercised with a usable divisor.
The same contract with the two addresses corrected	The verified rewrite fails 30 of 1,000 trials; with a positive divisor and size, 85 of 1,000. A copy with one float comparison corrected passes. Verified on the stock worker with an unchanged copy of the driver; the lane wrote its predictions down before running.	The rewrite was wrong: a rounding helper compares with "not less than" where the original's instruction is "not less than or equal", which differ for whole-number inputs. An audit had read that from the instruction earlier in the day and could not show it. The rewrite had already been withdrawn on the ground that its proof did not reach the code in doubt; that is now a shown difference.
A deliberately wrong version on the corrected contract	Fails 494 of 1,000. Verified.	The corrected contract sees the code. Under the contract of record a wrong version of that code would have passed.
Contracts of record scanned for the condition	16,381 read; 238 functions have no contract file where the index says and were not scanned.	The scan follows each verified function to its proving lane's contract; it does not search.
Contracts that place a value or a range in code	54 functions.	Certain faults in the contract: nothing is ever meant to be set there. Each of those proofs is narrower than it says. Whether the rewrite is right on the wider input is not yet known for any of them.
Contracts that set words the function's body never refers to	738 functions, 5,674 words.	Some are slips of the same kind, some are values meant for a callee, some are an image address written where an offset is wanted. Not yet separated.
Functions that write to data the contract neither declares nor compares in full	148.	A rewrite could write something different there and no check would see it.
Functions with the same signature as the one that started this	288. In a sample of ten read by hand, nine of the values gate a branch, index a table, feed arithmetic or reach an unchecked output; one is harmless. Inferred from reading listings.	The condition usually matters where it occurs.

Correction to an earlier statement

The lane that first met this wrote that the checker does not apply a contract's values at those two addresses. That was wrong, and the changelog entry of the withdrawal repeated the doubt. The checker writes a value where the contract names it and checks nothing about whether that is a place the function reads. That is the gap: not a fault in what the checker does, but something it never looked at.

What was decided

The rewrite stays withdrawn and a strengthening lane is proving the corrected copy, with every other address in its contract checked the same way.
The investigation lane continues from counting to measuring: for the 54 certain cases first, then the 148, it corrects the contract and runs the verified rewrite through it on the stock checker. A rewrite that then fails on trials the original completes is withdrawn; one that still passes gets the corrected contract as its contract of record.
The lane wrote a check for the driver that refuses a contract which places a value outside writable data, with tests. It will be adopted in a narrower form: a refusal for code, gaps and addresses outside the image, which can never be meant; a warning for read-only data, because varying a constant the original loads from there is a legitimate test and one the day's other findings call for; and a verdict file that records the refusal.
The production brief will tell lanes how to turn an image address into the offset a contract wants, to check that every address they set is one the function's body refers to, and to confirm with a deliberately wrong version that each value they set is seen.

How to reproduce it

For a contract, take every address it sets or declares and find the section of the image it falls in; then decode the function and list the absolute data addresses its instructions refer to. An address the contract sets that is in code, or that no instruction of the function refers to, is a candidate. The lane's script does this for one contract or for the whole verified set and writes the list.

Head-swap and constant-store families: 170 instances proven against two lifted methods

2026-10-11T00:00:00Z

From lane l-free21.

Asked. Lift a group of 198 verified 21-byte functions that call nothing, by finding the data they share and lifting each shape once.

Found. Most of the group is one routine: read a global list head, store the old value into a second word, point the head at a static node, and return the old value. One hundred and sixty-two rewrites have this shape. Eight more write two constants into two global words and return zero or nothing. The other 28 members are different shapes (branching readers, bit tests on a record, clears and copies through a record pointer) and are listed, not lifted.

Fact	Value	Meaning
Head-swap members	162	Verified rewrites with one head read, one save write, one head write to a node, and a return of the read value
Textual groups	11 for the same routine	A hash of the normalised text splits one routine into eleven groups; extracting the roles of each rewrite groups them correctly
Constant-store members	8	Two constants written to two global words, returns zero (seven) or nothing (one)
Lifted code added	two methods in one new module	One list-head method and one two-word store, with no unsafe code and no addresses
Proof	170 instances, 1,000 cases each	Every returned value and every word compared, rebuilt through the same addresses
Wrong versions	head left unchanged; save takes the node; a store left out	Caught for every instance

Verified. The four test crates pass on the 32-bit target (59, 59, 47 and 9 tests, none failing). The 64-bit workspace check and the host edge tests pass.

Decided. Prove the list family as one method on a table of link words, with words named by index, rather than as a class. The store-order version of the list routine is equivalent on every input the instances can reach, because the save word and the head are always different words. It is asserted to agree, and it is not counted as a caught wrong version.

Process finding. A differential test shows a wrong version is caught only if it can differ on a reachable input. Any order-only mutant over distinct words is equivalent, so the next brief should name that case instead of requiring a catch.

Still open. The 28 odd members need separate lifts with their own proofs. The return value of the constant-store family is checked by the test, not carried by the lifted method.

Quotient-store family: 229 more instances proven against one lifted routine

2026-10-11T00:00:00Z

From lane l-free20.

Asked. Lift a group of 265 verified 25-byte functions that call nothing, by finding the data they share and lifting each instance family once.

Found. Most of the group is one routine: read two single-precision globals, divide, and store the quotient in a third global. Two hundred and twenty-nine rewrites have this shape. Their return is absent, a dead integer zero, or the stored quotient. The other 36 members are different shapes (branching accessors, pointer-arithmetic setters, store-only copies) and are listed, not lifted.

Fact	Value	Meaning
Members of the routine	229	Verified rewrites with one division, two global reads, one global write
Return kinds	125 none, 85 dead zero, 19 quotient	The dead return is checked to be zero and not compared further
Lifted code added	none	The existing quotient routine in the vehicle module is proven for each instance
Proof	229 instances, 1,000 cases each	Every effect compared bit for bit, including sources and not-a-number payloads
Wrong versions	operands swapped, wrong destination	Both caught for every instance

Verified. All four test crates pass on the 32-bit target. A deliberately swapped lift fails 58 of 58 instances in one batch. The 64-bit host edge tests (7) pass.

Decided. Prove the instances against the existing routine rather than write a second copy. Batches are at most 58 rewrites per test crate. Non-vehicle instances are tested against the vehicle module for now; a move to a neutral module is a coordinator decision.

Process finding. A copy of a tracked source into a build tree keeps its old modification time, and cargo then reuses a stale binary. The generator now gives copies a new time. Any future generator that copies sources must do the same.

Still open. Six flag-gated field setters depend on a shared record lookup that is not a verified function. They wait until that lookup is verified.

One red pipeline run, three causes, and a fourth thing it uncovered: 706 verified rewrites whose published file is not the code that was proven

2026-10-11T00:00:00Z

The pipeline on the public repository failed on an afternoon commit after passing all morning. The failing jobs had three unrelated causes, two of them faults in the project's own tooling, and following the third to its end showed that 3.7% of the verified rewrites cannot be built into the assembled library from the file that is published for them.

What was asked

Why did a commit that only added three lifted routines break the job that assembles every verified rewrite into one library, and the job that checks the rewrite tree against its index?

What was found

Fact	Value	What it means
Index rows lost	Five verified rewrites had a file and no row in the index. Verified.	Three finishers and the coordinator ran the importer at the same moment. Each read the index, added its rows and wrote the whole file back; the last writer's copy dropped the others' rows. The fault was on the safe side, verified work not counted, and the consistency check caught it within the hour.
Files the assembler dropped on the failing commit	35 in one shard, of which 5 were at fault. Verified by replaying the shard locally.	When a shard fails to build, the assembler reads the compiler's messages and drops the rewrites they point at. It took any position in a file named `lib.rs` to be in the shard's own root file. The checker runtime's export macro lives in a file of the same name, so an error reached through the macro was looked up by line number in the wrong file and blamed on a rewrite that compiles. Each round dropped another innocent file, the two that really failed were never dropped, and after 30 rounds the job gave up.
Had the assembler done this before?	Unknown. The earlier manifests are not kept.	Earlier passing runs may have left out rewrites that compile. It cost nothing but their place in the library, and the next run includes them.
Verified rewrites left out of the assembled library, with the assembler corrected	706 of 19,026. Verified from the manifest of the first passing run.	472 do not compile on their own and 234 are refused before compiling. This is the finding that matters.
Why the 472 do not compile	248 call a function that is not in the file, 72 use a constant and 64 a type that is not there, 13 import something that does not exist, 18 use a reserved word as a name, 13 have an unclosed bracket, 7 define a name twice, 3 define a second panic handler.	A lane proves a function with a library built from its own crate, where helpers, constants and types may sit in a shared module. Only the one file is published. In two cases the published file is a three-line wrapper and the whole body stayed in the lane's folder.
Why the 234 are refused	206 use a runtime of the lane's own in place of the shared one, 17 have no export the assembler recognises, 5 still carry a wrong version beside the right one.	Mostly early lanes, from before the shared runtime was the rule.
When they were proven	346 on the second checker version, 213 recorded on the current one.	128 of the 213 are old files whose proofs the regression lanes have re-run; 85 come from production and queue lanes working on the current checker. It is still happening, slowly.

What this does and does not say

It does not say these 706 rewrites are wrong. Each passed its trials, with its wrong version rejected where the checker version required one, as a library built by its lane. What it says is narrower and still serious: for these functions the file in the repository is not the thing the checker ran. The coordinator's independent re-run has the same blind spot, because it runs the lane's built library and never builds the published file. A reader who takes the published file as the verified code is, for 3.7% of the set, reading something that does not build.

What was decided

The importer and the withdrawal script now hold one lock from reading the index to writing it. The five rows are restored.
The assembler counts an error position only when it is in the shard's own root file or the shard's own copy of a rewrite, with three tests. On the failing commit it then drops exactly the files that do not compile and builds in two rounds. The pipeline passes again.
The 706 stay counted as verified for now, with this entry as the statement of what that count includes. A tool lane is classifying them by what a repair takes, writing a check the importer can run on every file before it is published (does it compile alone, against the shared runtime, as the assembler would place it), repairing two of each class from the proving lane's own source and proving each repaired file by building it alone and running the contract of record against that build. What a script can repair is repaired by script; the rest goes to lanes; what cannot be made whole is proven again.
Once that check exists, a published file that does not compile on its own is held at import with the reason, and the production brief says so.

How to reproduce it

The assembled library's manifest is an artifact of every pipeline run: its excluded list has one record per file left out, with the stage and the compiler's first message. Grouping that list by message gives the table above. The assembler's fault is covered by the tests added with the correction: an error reached through the runtime's macro is attributed to the rewrite it came from and not to the rewrite that owns the same line number in the shard.

Widening a proof's inputs: seven verified rewrites differed from the original, and only four were the fault being looked for

2026-10-11T00:00:00Z

An audit that began with one question, how verified rewrites convert floats to integers, ended the day as a general test: take a verified rewrite and its contract of record, widen the contract so that every float the function can read takes extreme values on a share of trials, and run it again on the stock checker. Seven rewrites that had passed their proofs differ from the original under that test, on trials the original completes. All seven were withdrawn; five are already proven again with the cause corrected or are with a lane for it.

What was asked

A proof here is thousands of random trials inside the ranges its contract declares. What does a proof with ordinary ranges fail to see?

What was found

What differed	Functions	Status
A float converted to a 32-bit integer with Rust's cast, where the original's truncating instruction gives a fixed result for not-a-number and for values that do not fit.	Two.	Verified on the stock checker. Both corrected and proven again with widened contracts, the old form failing as the wrong version.
A float converted through a 64-bit integer store whose low half is used: the two sides differ for positive infinity and beyond the 64-bit limit.	Two, one from a single and one from a double.	Verified. One corrected and proven again; the other has a corrected copy that passes and is with a strengthening lane.
A clamp the original does with a signed comparison and the rewrite did unsigned: they differ when the value has its top bit set.	One.	Verified: the original's conditional instruction was read and a one-line change passes both contracts. With a strengthening lane.
The final sign of one value in a bank of floats.	One.	The difference is verified on a trial both sides complete; the cause is not located. With an investigation lane.
An argument to a later call, when an earlier callee answers a float of large magnitude.	One.	The difference is verified; the cause is not located. The checker's report shows only the first few calls of a trial, which hides the call that differs.

Scale, as far as it is known. Of 15,700 verified rewrites, 291 contain a float-to-integer cast. In 193 of those every cast is guarded exactly as the instruction behaves, which is safe by construction: the audit computed both forms over the special values and a million random bit patterns, and no unguarded form agrees with the instruction on positive overflow, whatever is done with the result. Of the 95 that needed the test, 56 have been tested; in 28 the test passed without an extreme value reaching the conversion, which settles nothing; 39 are being tested now. A further 66 files convert through a 64-bit integer with no guard at the limit and are candidates. Nothing comparable has been counted yet for signed and unsigned comparisons.

Why the proofs of record passed

None of them was wrong about what it tested. Their contracts drew small, ordinary values, so a conversion never met a value that did not fit and a sum never had its top bit set. The first lane to look at this took a passing run for a blind spot in the checker; it was the inputs.

What was decided

A rewrite known to differ from the original on an input the original handles is withdrawn, whether or not the game is known to produce that input. In every case here that is unknown.
Briefs carry two rules. A float is never converted with a bare cast unless the code bounds it first as the original does; otherwise the conversion is written to match the instruction, and the function's contract must reach the special values with the bare cast as a wrong version that fails. A comparison or clamp on an integer takes its signedness from the original's conditional instruction, read from the original.
The widened test becomes a standing tool, not a one-off: after the conversions, the same run over rewrites that compare integers near their limits.
A pass counts for this test only when the extreme values are shown to have reached the code in question, by counting them in an instrumented copy.

How to reproduce

The audit lanes' folders hold the detector for casts, the classifier, the tool that widens a contract and runs it, the widened contracts, the corrected rewrites and the conversion functions with bit-level references and tests.

How many lanes this machine can run: measured at thirty, sixty and over a hundred

2026-10-11T00:00:00Z

The machine has 18 logical processors and 48 GB of memory. For most of the project the lane count was set by memory, because a lane's agent process is small and memory was what ran out first in the early weeks. On 10 and 11 October the count was taken to sixty and then to over a hundred, and the result was measured each time. Memory is not the limit for lanes that verify; the processor is.

What was asked

The owner asked for lanes to fill memory down to a 2 GB reserve, first to finish naming and then to keep verification moving, and later asked directly whether adding more agents speeds verification up.

What was found

Lanes of the main model	Newly verified code	Per lane-hour	What else was seen
About 12 (earlier in the week)	Not measured by the hour then	About 4,000 bytes	Memory to spare, processor not saturated.
30 (four hours of the night of 10 to 11 October)	25,000 to 51,000 bytes an hour; 129 to 403 functions	1,000 to 2,300 bytes	Processor at 100%, 8 to 10 GB of memory unused, small-function lanes finishing most of their batches.
About 60 (two hours the same night)	About 19,000 bytes an hour	400 to 500 bytes	The coordinator's own commands took up to ten minutes; lanes deferred functions for time.
90 to 115 (the afternoon of 11 October)	About 19,000 bytes an hour over two hours, most of it imported after the count had fallen	359 bytes	181 to 244 threads waiting for 18 processors. Lanes' checker runs hit their time limits. The supervisor took fifteen minutes between imports. The regression runner needed 290 seconds a proof against 13 on a free machine. One coordinator command did not start for 23 minutes. Memory at the reserve, with the floor guard stopping lanes' link steps.

All figures are verified from the hourly scorecards and the system's own counters. The comparison across rows is not perfectly clean: the lanes of the last row included many that had sat through a standby, and batches differ in difficulty. The direction is the same in every measurement.

Why naming is different

A naming lane is one agent reading code, with no compiler and no checker. Forty of them at once named 1,164 functions in two and a half hours, and filling memory with them worked. A verification lane compiles Rust and runs the original and the rewrite thousands of times in checker workers; three such workers per lane, across a hundred lanes, is several times what 18 processors can serve.

What was decided

The lane count for verification is the owner's decision and the figures above were put to him with a recommendation of about thirty. Until he answers, the count is held at thirty, which both of the options before him include.
Whatever the count, these now hold: lanes of the main model and the regression runner run below normal priority; the coordinator's supervising and importing processes run above normal; lane starts pause when available memory is under 4.5 GB and resume at 6 GB, so that lanes already running do not push the machine under the reserve; a second and, in a wave, a third finisher import ended lanes.
Naming lanes and Haiku lanes are counted apart from the thirty: the first are light, and the second are few.

What it cost to find out

About four hours of reduced output across the two days, and lanes whose batches came back a quarter done. Nothing false was recorded: a lane that runs out of time defers, and a re-run that times out imports nothing.

Lift: task record sub-object tables and the aim blend (ped_task group, two shapes)

2026-10-11T00:00:00Z

Asked. Lift the 90 verified routines of the ped task group, grouped by the data they share, one shape at a time, each lifted routine proven against its verified 32-bit rewrite.

Found (Verified). The name group holds about nineteen data shapes. Most shapes have one routine. Two shapes had clear data and were lifted: the four sub-object tables of the task record (two routines that walk them), and the aim blend of the record (one routine with two gate calls and a hook on the target).

Shape	Routines lifted	Proof	Narrowed
Task record sub-object tables (frame remap, matrix transform)	2	3,000 generated cases per routine; calls in order, record bytes and the answer compared; 17 wrong versions, all caught	A stack word the transform stores is taken as zero; callees are scripted, not the sub-objects
Aim blend	1	3,000 generated cases; calls, record bytes and answer compared; 8 wrong versions, all caught	The hook's scratch argument is masked; the hook's answer is its three floats

Found (Verified). The transform stores a word its routine never writes: it is an uninitialised stack scratch in the original, and the checker's stack fill makes it zero. The lift stores zero and records this as a narrowing. Whether the game reads that word is open.

Found (Verified). The four tables share their flag bytes: table k, slot i reads the byte at k plus i, so the first table's second slot and the second table's first slot are the same byte.

Not reached. The zone list routine needs a larger memory window in the differential runtime than the runtime has. The other shapes were triaged by call counts and offsets only.

Written by lane l-free19; integrated by the coordinator.

A fault blamed on an unrelocated read was undeclared callees, and a pass that depended on a mis-sized stack (lane a-H31)

2026-10-11T00:00:00Z

Surprise 1 (Verified). A checker run that faulted on an unrelocated read was not a relocation problem. The relocation audit reported every absolute operand of the function relocated. The cause was native code: the probe's second argument took a polled-call block whose three callees had no declared stub or call-site patch, so the worker ran that original code directly and it jumped into an unrelocated address. Declaring the stubs (the same ones stage 20 used) and scripting the helper's answer as a valid heap object made the original complete 60 of 60.

Surprise 2 (Verified). A callee whose stack-word count is wrong does not show as an error in the stub; the run stalled. Setting the count to the six words the original pushes fixed it, and the stack check (esp) then passed on both sides.

Surprise 3 (Verified). A stage that matched by coincidence: the query threshold read the frame's scale word where the original reads the gate word. The mismatch appeared only after the stack count was corrected, so the earlier pass had been produced by the mis-sized stack.

Decision: the function stays deferred (partly_proven); steps 3, 4, 5 and the dl = 1 route in the rewrite are open. Probe s29r is in retry\probe for the next lane.

An outside reverse-engineering toolkit evaluated from its documentation: not adopted, one idea taken

2026-10-11T00:00:00Z

The owner asked whether REA, an open-source toolkit that gives AI agents reverse-engineering tools over the Model Context Protocol, could speed this project up. A research agent read its documentation; nothing was installed or run. The answer is that the product does not fit this project as it stands, and that its central idea is worth building here from what the project already has.

What was asked

Where do lanes lose time that a shared tool could save? Every lane that names a function or maps a large one first writes its own throwaway script to collect the same evidence: the strings a function references, its callers and callees, the class whose virtual table points at it, the names of its neighbours. A naming lane spends 10 to 30 minutes on that before it names anything, and sixty lanes do it at once.

What was found

Question	What the documentation says	Status
Can it use the project's analysed disassembler project?	No. Each session imports a private copy of the binary into a temporary project and analyses it again; it never opens an existing project.	Verified from its installation and provider pages.
Does it work on this machine?	Its Windows support is described as experimental, read-only and for x64 hosts. This machine is an ARM64 host running x64 tools under emulation, which the documentation does not mention.	Verified for what it says; unknown for this machine.
Can many lanes share it?	Not stated. Each connection starts its own analysis engine with a default heap of 2 GB.	Inferred: sixty lanes would each pay an import and a virtual machine.
Can it dump evidence for many functions in one run?	No batch command is documented. Batch decompilation exists as an agent tool inside one session; a session's evidence can be exported once and read later without the engine.	Verified for what is documented; three reference pages could not be read.
Does it help name functions that reference no strings?	No similar-function search, no library signature matching, and no virtual-table or type-information recovery for Windows programs are documented.	Verified as absent from the pages read.
Does its showcase's verification apply here?	The showcase that runs thousands of cases against original code uses a harness written by the case study's author, not part of the toolkit.	Verified. This project's checker already does more.
Stability and set-up	Five releases with breaking changes in one week; set-up edits agent configuration for the user account, not per project.	Verified.

What was decided

Not adopted. Nothing was installed.
The idea taken: one shared, queryable source of evidence for every lane. A tool lane is building one database for all game functions from the mapped image (calls, data references, strings, virtual tables, names, neighbours, and a simple signature for finding instances of one routine), with a script that prints a compact dossier per function. It holds no disassembly and no decompiler output and stays in the build area. Once proven on a real naming list it goes into the naming, production and large-function briefs.
For the owner to decide: the project's own disassembler could export pseudocode and basic-block listings for every function in one unattended run, kept out of the repository as all decompiler output is. That is several hours of processor time and has not been started.

What was confusing

An export of the call graph and cross-references made on 3 October was on disk all along (30,900 functions, 79,000 call pairs, 151,000 references) and no brief pointed lanes at it. It is older than the inventory and misses about 6,500 functions, so the new database is built from the image and checked against it.

Three questions about the checker settled in a day, and an audit that withdrew two verified rewrites

2026-10-11T00:00:00Z

Three things that lanes reported about the checker on 11 October were each given to an investigation lane before anyone acted on them. Two came back settled inside twenty minutes of work. The third, an audit of how verified rewrites convert floats to integers, found a real fault: two verified rewrites were withdrawn the same afternoon, and 288 more functions are being tested.

A scripted callee's writes are the same on every call within a trial

What was asked: two lanes on two large functions (a file parser that reads a token per line, and a search loop that calls one callee per candidate) stopped on the belief that a scripted callee cannot write different words through its pointer argument on each call within a trial. Is that so?

Fact	Status	What it means
A callee's return value can follow a sequence that advances with each call inside a trial.	Verified on the stock checker: a three-step sequence passes 200 of 200 where a once-per-trial answer fails 200 of 200.	Use the per-call form for a callee that is called several times; use the per-trial form for one that is called once (an earlier entry records the opposite mistake).
The words a callee writes through a pointer are one row per trial.	Verified from the worker's source and by experiment: each call writes the same words at its own destination. They do not depend on the call's index, on an argument, or on the call site for one stub.	The two lanes were right about the limit.
What a lane can do today, with no change.	Verified in a private copy, inferred for the stock build: a callee that returns a pointer can be given a sequence of pointers to different words, so its caller reads a different answer per call. Calls at different sites can have a stub each. A handler can be proven in a stage of its own with the token fixed for the trial.	A stage with the token fixed proves that handler's code. It does not prove the transitions between handlers within one run, their order, or that one handler's exit state is valid for the next: those are listed as not covered.
A candidate extension: a per-call list of write rows.	Built in a private copy only. Its regression contract fails to load on the stock driver and passes on the private build with a wrong version caught; the checker's own set gives identical verdicts on both builds for 61 of 62 contracts, the other being the absolute-read self-test that cannot run on this machine.	Not adopted. It changes the worker and the driver, so it needs a checker review lane and a new checker version before any proof may use it.

The same lane found that the manual's line on scripted writes gives the count in the wrong unit: the count is in 32-bit words and the destination offset in bytes. An earlier lane lost an hour to exactly that.

The option for unrelocated absolute reads

Settled the same morning and recorded in its own entry: the option cannot set up on this machine. A follow-up worth recording here: the lane whose route seemed to need it ran the relocation checker on its function and found all 52 absolute operands relocated. The fault on that route has another cause, as every earlier claim of this kind had.

Float-to-integer conversions written with Rust's cast

What was asked: a lift lane noticed that two verified rewrites convert a float to an integer differently when the value is not a number or does not fit. The original's instruction gives a fixed result there; Rust's cast gives zero or the nearest end of the range. How many verified rewrites use the cast where the original's instruction behaves differently, and do their proofs cover those inputs?

Fact	Value	Status
Float-to-integer casts found	326 certain, in 291 of 15,700 verified rewrites; 465 more that the detector could not type, not counted.	Verified: a hand check of 30 flagged and 30 unflagged files found no false alarm and no miss on the final pass.
A random sample of 40	28 are guarded in the rewrite so that it gives the processor's value; 5 agree on the bits that are used; 7 have no guard, in three functions.	Verified for the 33; the 7 are unsettled.
The seven	The lane's pairing of each cast with the original's instruction was unreliable, and a checker run on one of the three functions, whose contract should draw floats that overflow the cast, still passed 300 trials.	Unknown: either the rewrite is wrong and the proof cannot see it, or the classification is wrong.
Estimate if the seven are real	About 51 verified rewrites (25 to 93); about 7 if they are not.	Inferred from the sample.

What was decided at first: nothing is withdrawn on an estimate. A second lane settled the three functions one by one: the original's conversion identified exactly by following the data, both sides computed on the special values, and any difference shown on the stock checker with a contract widened to reach them.

Settled the same afternoon

Function	What the original does	Result on the stock checker
An audio query routine: six values converted and stored as 16-bit words	A 32-bit truncating conversion, of which 16 bits are kept. For a positive value too large for 32 bits the original stores zero; the rewrite's cast stored the largest 16-bit value.	Verified. The contract of record passes because its floats are small. With only two inputs steered out of range, the tracked rewrite fails 439 of 1,000 trials; a corrected conversion passes 1,000 of 1,000 with the old form failing as the wrong version. Withdrawn.
A small task routine: one value converted through a 64-bit integer store	An x87 store of a 64-bit integer under truncation, of which the low half is used. The two sides differ only for positive infinity and values too large for 64 bits.	Verified. With a global the game fills at run time steered that high, the tracked rewrite fails 67 of 1,000; the corrected form passes. Withdrawn. Whether the game can produce such a value there is unknown.
A fill routine with five conversions	Five 32-bit truncating conversions whose operands the code itself bounds: a counter that never exceeds 64.	Verified safe. An instrumented run logged 24,984 operands, all in range. Not withdrawn.

The first lane's puzzle is explained: the proof that passed with inputs that "should overflow" never drew such inputs; its float cycles were small. That is the general lesson. A contract's ordinary float ranges do not reach the values on which a cast and an instruction differ, so a proof with ordinary ranges says nothing about them.

What was decided

The two rewrites are withdrawn; the verified count went down by two, with the reason in the changelog. A strengthening lane is proving the corrected copies with the contract of record and the widened contract together.
Production, queue and large-function briefs now carry the rule: a float is never converted with a bare cast unless the code bounds it first; otherwise the conversion is written to match the instruction, and the function's contract must reach not-a-number, the infinities and values past each end of the range, with a wrong version that uses the bare cast.
A scripted version of the widened test is being built and run over the other 288 functions that have such a cast. A pass counts only if the special values are shown to have reached the cast. The verified count may go down again.

How to reproduce

The two audit lanes' folders hold the detector for such casts, the list of 326, the classified sample, the widened contracts, the corrected rewrites, and the two conversion functions with their bit-level references and tests.

Six operating faults of one night, five of them in the coordinator's own tooling

2026-10-11T00:00:00Z

This entry records what went wrong in running the lanes between the evening of 10 October and the afternoon of 11 October, so that the next coordinator does not find each of them again. None of them produced a false result. Together they cost about nine hours of machine time.

What happened	Cause	What was changed
The machine went into standby from 07:06 to 11:33 and from 13:06 to 15:16. Nothing was verified for eight hours. Four Haiku lanes failed for want of a network and every background window ended at once.	Verified from the system's power events. The request that keeps the machine awake is held by the coordinator's session and lapses when the session has been idle for five minutes. One interrupted turn of the coordinator was enough.	The request was renewed and everything restarted; the lanes of the other model survived the standby and resumed by themselves. A hold on sleep that does not depend on the coordinator's session is the owner's decision and has been put to him.
Naming stood still for five hours with 1,300 functions unnamed and no naming lane running.	Verified. The second naming pass left alone any function handed out in the last twelve hours, in case its lane was still running. After a burst of 35 naming lanes that covered nearly all of what was left, so the pass saw nothing to do. Naming had also been left out of the rotation of lane kinds.	The pass asks the lane's log whether it is still running. Naming is in the rotation. The final pass uses small batches and tells each lane to read every function in full, since a survey of strings and neighbours had already failed on them.
The coordinator's re-run of a finished lane's proofs broke without cause, several times in the night, and one lane's twice in a row.	Verified. The watchdog that stops processes left behind by ended lanes matched the re-run itself, because the re-run names the ended lane's contract. A broken re-run imports nothing and holds nothing, so nothing false was recorded.	The watchdog skips any process whose command line names the coordinator's own folder.
Regression lanes were about to be told there was nothing left to re-run.	Verified. See the entry on the regression runner: proofs handed to a lane and never reached counted as taken for good.	What an ended lane did not reach is handed out again.
With sixty and more lanes, output fell to half of what thirty produced, and the coordinator's own commands took ten minutes.	Measured over four hours: about 19,000 bytes of newly verified code an hour at about sixty lanes against 25,000 to 51,000 at thirty. The machine has 18 logical processors; memory was never the limit.	Lanes of the other model and the regression runner run below normal priority; two finishers work the list of ended lanes from both ends, each lane claimed before it is worked on. The lane count itself is the owner's decision: he has chosen to fill memory, and each hour's figure is reported so the effect can be seen.
A lane left a search running over every lane folder for eighty minutes; another lane's command reached 3.2 GB.	Verified. A recursive search of the whole scratch tree (2,500 folders) started by a lane and abandoned when its command timed out.	The first was stopped by hand, by process id; the second by the guard that stops a project process above 3 GB. Lane prompts for investigation lanes now say never to search the whole scratch tree.

Signs worth knowing

A Haiku lane can hang with nothing running and no notice. The sign: no log line for fifteen minutes, no process whose command line names the lane, and no new file in its folder. Stop it and resume it with its context; if it hangs again, start a fresh session in the same folder with a short finishing prompt.
A lane of the other model that writes nothing to its lane log for half an hour is usually working: its own session log is the thing to look at.
After a standby, runs that were in progress are void: the drivers' time limits expire and the re-run records a timeout, which holds the claim until it is cleared and repeated.

Old proofs are now re-run by a script, and the list of what was left had been wrong

2026-10-11T00:00:00Z

About 13,700 functions are recorded as verified on an earlier version of the checker. Re-running each proof of record unchanged on the current checker, with its wrong version, is the regression the plan calls for. Until this morning lanes did it, slowly. A tool lane turned it into a script in 43 minutes, and wiring the script in showed that the process had been about to run out of work it could see.

What was asked

Six regression lanes settled 27 to 95 proofs each of the 350 each was given, in a hundred minutes: about 80 an hour for the project, a week for the backlog. Each lane wrote its own preparation, build and run scripts before running anything. Can the mechanical part be one resumable tool that needs no model?

What was found

Fact	Value	What it means
The runner on its 123 test functions	123 hold, every wrong version rejected, about 13 seconds a function with three workers. Stopped by process id in mid-run and restarted, it skipped what was settled and repeated nothing.	Verified. The tool builds tracked rewrites in crates of thirty (a crate that fails is split in half, so one bad file costs only itself), runs each contract of record on the stock driver in a process of its own with a time limit, then the saved wrong version at 100 trials.
Its first full list: 350 proofs first recorded on checker version 5	311 hold; 33 pass but have no saved wrong version; 5 could not run; 1 fails.	Verified. The 311 are recorded on the current checker. The one that fails goes to the queue of old proofs that do not hold.
Proofs first recorded on checker versions 1 to 4	5,395 functions. Of 350 tried: 83 pass unchanged, with no wrong version to run; 2 hold.	Verified. A wrong version per function was not required until version 5. These need one written, which is a lane's work; the runner can do the build and the thousand trials first.
The list maker for regression lanes	It reported 1,636 proofs left to hand out. 13,700 were still to re-run.	Verified. It counted every proof ever handed to a regression lane as taken for good, and lanes reached a quarter of what they were given. After the correction it sees 6,857: what an ended lane did not reach is handed out again.

Three faults in the tool, found on real lists and corrected

Rewrites of the first weeks name the runtime's macros without a path, because their proving crates imported them at the crate root. The tool's crates did not, and 257 of 350 early rewrites failed to build for that one reason.
Some lanes' tracked rewrites carry their wrong version in the same file. The tool added the lane's saved copy as well, the name was defined twice, the build failed, and the tool dropped the wrong version and reported that none was saved: 19 of the first 30 proofs of one list.
The tool recorded what it could not settle as deferred. Its first list would have put 348 verified functions into the deferral queues as if they had failed. Such rows are now written as not reached, with the reason; the rows of that first list were corrected before anything imported them.

What was decided

The runner works through the proofs recorded on versions 5 to 7 (5,599 functions) in lists of 150, one list after another, below normal priority; the coordinator's import records each hold.
Regression lanes take the proofs without a wrong version, oldest first.
Nine proofs that a lane had recorded as unable to run (its worker was lost on them) hold under the runner; they are not counted until they have run once more.

What went wrong

In its first hour the runner ran at normal priority beside thirty production lanes that run below normal, and the hour's newly verified code halved. A re-run of old proofs must not take the processor from new work.

How to reproduce

The runner, its wrapper and the loop that makes lists and imports them are in the coordinator's scratch folder; the tool lane's folder has the agreement table against two regression lanes and the stop-and-resume test.

Eight large functions closed in one night, and what each close taught about proofs

2026-10-11T00:00:00Z

Between the evening of 10 October and the afternoon of 11 October, Claude Haiku 5.5 lanes closed eight functions of 2,200 to 4,500 bytes that lanes of the other model had left partly proven in stages: 26,000 bytes of code in all. None closed in one session; they took one to five sessions each. The coordinator re-ran every one before importing it. Five of the eight were sent back at least once after being reported as verified, and the reasons for sending them back are the useful part of this entry.

What was asked

The owner's rule of 10 October: Haiku lanes take the higher difficulties when the other model is struggling. The question for the night was whether a function left in stages can be closed at all, and what a lane must be told to do it.

What was found

Finding	Status	What it means for the next lane
A wrong version that passes is a fault in the contract, not a limitation to list.	Verified. A lane reported a function verified while listing that a version with one subtraction reversed still passed. Sent back to find out why, it found in six minutes that its 47 contracts placed a table of floats at the wrong address (the image address had not been turned into an offset from the image base), so the table read as zero on both sides and everything multiplied by it vanished.	When a wrong version passes, find out why before anything else: a fixture at the wrong address, a value multiplied by a zero fill, cycles of equal length that pair two paths, a word that no check compares. Every lane's brief now says so.
A function with unwritten branches is not verified, however good the proof of the rest.	Verified. One rewrite was reported verified with nine deliberate faults in it, seven marked as not written. Sent back, the lane showed by experiment that five of the seven are paths on which the original itself faults (it dereferences a null it was just handed), and wrote and proved the other two.	Each deliberate fault left in a rewrite is classified: a path the original faults on or can never take, with the evidence, may stay and is listed; a path the original completes must be written and proven.
"Partly proven" can mean untested inputs, not unwritten code.	Verified. A lane ended with a 4,490-byte function recorded as partly proven and a list of open items. A fresh session asked to classify them found that none was unwritten code: they were combinations of inputs passing through code already proven on other inputs, and two branches the original can never take. The function closed in 17 minutes.	Before a function is left as partly proven, the question is asked of every open item: is it code that is not there, or inputs that were not run? Only the first keeps a function open; the second is listed as a narrowing.
The published rewrite must not carry its wrong versions.	Verified. Two lanes kept their wrong versions as switches inside the function body (sixteen in one file). The file was folded to its correct arms, rebuilt, and re-proven before import; the wrong versions stay in a second build.	One export, no wrong-version parameter, and the clean file is the one the clean build compiled, byte for byte.
An earlier stage can be wrong and still pass.	Verified, several times: a callee modelled as writing nothing when it increments the count a later loop reads; a contract that pinned two values equal so that reading the wrong one could not show; a contract in which half the trials faulted identically on both sides and proved nothing; a probe that never reached a route because one scripted lookup always answered zero.	Re-run the inherited stages on your own build first, then distrust them where your new stage disagrees. A trial that faults on both sides is not a pass: the original must complete.
The coordinator's re-run must read a proof in the form the lane kept it.	Verified. One function was held by the re-run for a reason of form: its wrong versions were kept as 33 contracts of their own, each identical to a passing contract except for the library and the export, and the re-run read them as failing claims. The re-run now recognises such pairs by content and requires the wrong one to fail on a comparison.	Either form is accepted: a wrong version declared in the contract, or a paired contract that differs only in library and export.

What worked as a way of briefing

An ordered list of small routes where the function is mapped; one narrow job where it is not (a frame map by experiment, one loop pass, one block built call by call against a probe that checks the first mismatch has moved); a checker investigation lane before anyone believes a reported checker fault.
Sending a lane back with the open items in order works: lanes stopped with most of their time unused in most first sessions, and continued when told what was left.
When a lane has grown long and stalls, a fresh session in the same lane folder with a short finishing prompt (reproduce the logged runs, replace the stale files, record the result) finished two functions in 10 and 17 minutes.

What was confusing or went wrong

Two functions took six and seven sessions and are still open, one with five routes left. The same belief about the checker stopped two lanes on two functions (see the entry on scripted writes). A lane session can hang with nothing running and no notice: the sign is no log line, no process of the lane's own and no new file for fifteen minutes.

How to reproduce

The briefing forms are in the coordinator's scratch folder as the per-lane additions to the queue brief; each closed function's lane folder holds its stage contracts, wrong versions and verdicts, and the coordinator's re-run of each is beside them.

Lift: task block, turn, aim, flag, entry and record-scan routines (ped_task group, eight shapes)

2026-10-11T00:00:00Z

Asked. Lift the 118 verified routines named as the ped task group that the earlier lane had not settled, grouped by the data they share rather than by name, one shape at a time, each lifted routine proven against its verified 32-bit rewrite.

Found (Verified). The names do not match the structures. Four names are shared by different routines: the aim update (four routines), the range check (two), the heading update (two) and the state initialiser (two). Grouping by what the rewrites read and write through their first argument gives eight shapes that could be lifted with a small owned type each, a set of forwarders with constant arguments, a set of routines whose target is computed from an index, and a set of routines that walk several objects. Nine routines in eight shapes were lifted; the rest is listed by reason in the lane's results.

Shape	Routines lifted	Proof	Left out, and why
One task object: two read-only predicates	2	4 differential tests; 9 wrong versions caught	Index-computed pool accessors (3); a forwarder
Task state block reset	1	2 differential tests; 5 wrong versions caught	None in the shape
Task block constructor (seven callees)	1	2 differential tests; 6 wrong versions caught	A 170-entry preset id table (decision needed)
Turn tracker (two trigonometric callees)	1	2 differential tests; 10 wrong versions caught	Double-precision callee (not callable from stable Rust)
Typed-record table scan	1	2 differential tests; 7 wrong versions caught	A link-chain range check (two hops) and a global-row range check
Aim record update (two collaborators)	1	2 differential tests; 7 wrong versions caught	Other aim updates (different objects)
Owner subject-flag update (six collaborators)	1	2 differential tests; 6 wrong versions caught	None in the shape
Entry initialiser (four collaborators)	1	2 differential tests; 6 wrong versions caught	None in the shape

Finding (Verified). Two verified rewrites in this group convert a float to an integer in different ways. The block constructor's rewrite uses the Rust conversion, which gives zero for a not-a-number and saturates outside the signed 32-bit range. The entry initialiser's rewrite gives the processor's truncating result, the most negative integer, for both. The lift of each follows its own rewrite. For the block constructor the difference cannot arise in the game: the two factors it reads from the image are one over 2^15 and minus 500, so the product stays between minus 500 and zero for any sixteen-bit draw. The proof of each shows the difference is measured, not assumed.

Finding (Verified). In the aim update, a not-a-number first direction component kept a different sign in the lift until the operand order of the single-precision operations was pinned with the same opaque-operand helper the rewrite uses. The rewrite was not changed.

Finding (Inferred). One routine copies a 170-entry preset table into the task system. The table is game data, so copying it into tracked source needs a decision; it is left out.

Decided. Each shape gets its own owned type, named for its data, in a separate module: none of the shapes shares a structure, so no single class was lifted. Collaborators travel as one trait per routine; their constant arguments are supplied by the implementation, and the proof compares the calls in order with their arguments. Callee-written scratch words are compared as non-null tokens; the proof does not compare their contents. Wrong versions each change one thing, and the proof prints how often each wrong version differs from its rewrite.

How to reproduce. Build the eight differential test programs of the test crate for the 32-bit target and run them one at a time; then run the host tests of the peds-tasks crate on the 64-bit host. The include paths in the test crate are local to the lane's scratch tree and are shortened by the integration script.

Written by lane l-free18; integrated by the coordinator.

Lift: task event table, task manager slots and the audio task record (ped_task group)

2026-10-11T00:00:00Z

Asked. Lift the 149 verified routines named as the task family, grouped by the data they share rather than by name, one shape at a time, each lifted routine proven against its verified 32-bit rewrite.

Found (Verified). The name group is not one structure. Grouping by what the rewrites read and write through their first argument gives at least seven unrelated shapes, a family of forwarders with constant arguments, and receiver routines. Three shapes had clear data and were lifted, and one single owner-slot routine was lifted with them: a 32-record table of event and deadline records (9 routines), the task manager's pointer arrays and bomb requests (5 routines), and the audio task record (8 routines, three of them one generic release and two of them one generic stamp).

Shape	Routines lifted	Proof	Left out, and why
Event table (owned table of records)	9	18 differential tests; 17 wrong versions caught	A forwarder with one constant call; two receiver routines
Manager pointer arrays	5	10 differential tests; 8 wrong versions caught	One routine on an embedded sub-object
Audio task record	8	13 differential tests; 12 wrong versions caught	A pointer walk; two indexed-table writes
Owner slot (one routine)	1	2 differential tests; 2 wrong versions caught	Nothing; the sibling receiver routines are listed in the lane report

Finding (Verified). One rewrite's comment says its return value is the address just past its table. The constant it returns lies 24 bytes beyond the end of the table. The lift follows the constant, and the lift does not return the value at all; no caller was checked.

Finding (Verified). The window routine's comments name two deadline words "first" and "second", and the stamp routines that write the same words name them the other way round. The lift names the words by what writes them and documents the window routine's reads.

Finding (Inferred). An indexed-table write routine, on the branch where its index byte is all ones, computes a zero base and writes at a small absolute address. This routine was not lifted. Whether that branch can be reached in the game is not established.

Decided. Helper addresses that a routine passes to a helper are rebuilt in the proof from the record index the lift passes. Each helper is a trait method; no operating-system call is in any lifted routine. Callee effects are assumed not to write the table or the record, and that assumption is listed in each routine's registry row.

How to reproduce. Build and run the four differential test programs of the test crate for the 32-bit target, then the host tests of the peds-tasks crate on the 64-bit host. The test crate's include paths are local to the lane's scratch tree.

Written by lane l-free17; integrated by the coordinator.

Ped task mover, seek record and task id lookup lifted and proven

2026-10-11T00:00:00Z

Asked. Lift the group of verified free functions named as the peds-tasks part of the ped task family (109 routines, about 93 KB), starting with the simplest sub-group, and say what the group is. Method: triage by data shape, then one owning type per shape with the unlifted callees behind a trait, proven against the verified 32-bit rewrites.

Found (Verified). The 109 names are not one structure. Triage by callee count and by the constants and offsets each rewrite uses through its first argument gives about nine shapes, and the largest of them have 8 to 26 callees each. Four shapes were small enough to take first:

Shape	Routines lifted	Proof
Task pose and blend state block (pose at a fixed offset, a state block with its own virtual height slots)	lerp, drive blend, commit blend (3)	6 tests, 4000 generated cases each; wrong versions caught
Seek-target record (no callees)	seek target setup (1)	3 tests; wrong versions caught
Task id lookup (two keyed tables, id word, default id)	id or default (1)	3 tests; wrong versions caught
Task request gate (vtable word, two globals, candidate words, one status probe)	gate (1)	3 tests; wrong versions caught

Findings: a rewrite's comment gave 10000.0 for a constant whose verified bits read 9999.5; the lift follows the bits. A turn-tracker routine reads its sine and cosine results from the integer return register while its contract declares a float result in the SSE register; this is not resolved and that routine is not lifted.

Decided. The owning types are the pose (with the blend state and a callee trait), the seek record and the key; the gate has no owned data and is a free function over the words it reads. Float operations keep the original operand order by passing each operand through an optimisation barrier. The drive step's blend callee is an opaque method: its shape matches the lerp routine but no callee map proves that. Lifted code has no unsafe and no addresses.

Reproduce. Build the test crate for the 32-bit target and run each test program alone; the host tests run on the 64-bit host. The triage is a script that reads the work list and the rewrites and prints each routine's callee count and its constants.

Status. Proofs pass on the 32-bit target (15 of 15) and host tests pass (36 of 36). The other 103 routines are not lifted; the largest families are the aim and pose solvers and the dispatch builders.

Written by lane l-free16; integrated by the coordinator.

Lane a-H30: three things the staged proof did not expect

2026-10-11T00:00:00Z

Verified (the lane ran each check): on the stock v8 checker, a path that skips a loop pass without storing its node and its float block leaves stale frame words for the next pass. The next pass's first-node argument and its previous block are then the values stored by the last pass that merged, not the values of the pass before. Two checks found this, and the fix is a pair of variables updated only on the merge back-edges.

Finding	Status	What it means
Scan-accepted continue jumps past the merge block that stores the current node and block	Verified (stage 4c, 1000 trials, wrong version caught)	A rewrite that reads the previous node from the global table is wrong once a pass is skipped.
Entry-match hit links the previous node of that pass	Verified (stage 4b)	The link differs between passes; a constant link fails.
A checker callee gives one out-word row per trial, shared by every call of that callee	Verified (by a failing probe, then a second stub id)	Two calls of one callee in one trial cannot differ in their out-words unless the second call has its own stub id. This blocks the query-loop variant with two hit candidates.
The first key's remap steering needs a float block on the remapped key	Verified (fault in the original, then a clean pass)	A fault in the original during steering, not a rewrite error; the remapped key reads its float block through the key's own pointer.

Decided: the stub ids for repeated calls are a checker-side label; the real callee is the same function at each site. Recorded in the narrowed list.

A probe pin that answered zero hid a whole route

2026-10-11T00:00:00Z

What was asked: a lane probe had to get the original to call a new helper on at least 20 of 60 completed trials, and the probe had been run for 60 trials with the helper's call site stubbed. It never fired the helper.

What was found (Verified): the probe scripted the lookup callee that the original calls just before the helper (a state-word record lookup) to answer zero. The original then takes a different branch and never reaches the helper. Scripting that one callee to answer a record on odd trials made the helper fire on 30 of 60 trials. The probe had been pinned on the object words and the other callees, and the lookup callee was the one that had been missed.

What it means: when a probe shows a route vacuous, check the scripted answer of every callee on the route before concluding the route is unreachable. A cycled script indexes by trial number, so a branch that only odd trials reach needs an odd index in its script.

Also (Verified): a helper answer and a region object answer scripted on the wrong parity left the branch unreached for a whole probe run, and a callee whose call site was left unpatched ran the real code natively.

How to reproduce: the probe contract and its generator are in the lane's retry folder (mkprobe.py, contracts28).

Written by lane a-H28; integrated by the coordinator.

A checked contract passed with the wrong stack-word count

2026-10-11T00:00:00Z

Asked. Lane a-H23 was to write the shared convergence block of a partly proven function (a task update routine) and prove its entries against the stock checker.

Fact	Value	What it means
Zero arm of the block, first call	three words pushed before the call: a constant, the object and zero	Verified: the z contract declares three words and passes 1200 trials with the call arguments compared.
Two earlier replay contracts	declared four words for the same callee	Verified: both passed on the earlier stage rewrite, which pushed four words (the fourth a float constant).
Why the earlier contracts still passed	Not established	Inferred: the fourth logged word matched by chance on both sides. Not checked further.

Decided. The replay copies were corrected to three words and the count is recorded in the lane's narrowed list. The earlier stage files were not edited.

Reproduce. Run the checker on the z contract and on the corrected replay of the stage 12 contract, and compare the callee's declared word count with the original's three pushes.

A callee's write into the caller's frame faulted the rewrite: the contract asked for eight words where two fit (lane a-H21, corrected)

2026-10-11T00:00:00Z

What was asked. Finish a partly proven rewrite whose remaining branch calls a stdcall callee that writes its result through a pointer into the rewrite's frame.

What was found. Verified on the stock worker: when the callee is declared stdcall with its out-parameter write going to a pointer into the rewrite's own frame, the rewrite faults on the rewrite side in about a third of the trials, while the original side runs cleanly. Pointing the same write at a heap object does not fault. Declaring the callee thiscall with the register argument not compared removes the fault but the rewrite returns a corrupted value. The same write through a thiscall callee elsewhere in the same function works, so the cause is not the frame layout alone. Cause not found.

Item	Value	Status
stdcall, stack-pointer write	rewrite faults in 10 to 20 of 60 trials	Verified
stdcall, heap-pointer write	no fault	Verified
thiscall declared, stack-pointer write	no fault, corrupted return value	Verified
Cause	not found	Unknown

What was decided. Recorded as a checker gap. The worker is not edited. A checker investigation lane should take it before the branch is closed.

How to reproduce. Run a 60-trial probe with the callee's out block in the rewrite's frame, then the same probe with the block on the heap.

Correction by the coordinator

11 October 2026, 04:05. A checker investigation lane examined this the same night and found the fault is in the contract, not in the checker. In a contract, the count of a scripted write through a pointer argument is in words, not bytes. The contract asked for eight words to be written through a pointer to a local that is two words long in the rewrite, so the write ran over the rewrite's frame; the original's frame happened to have room. With a count of two the same branch passes 1,000 of 1,000 trials and a wrong version with the two words swapped is caught. The function was finished on that basis the same morning. What stands from this entry is the method of reduction; what does not stand is the conclusion that a callee's write into the caller's frame cannot be proven on the stock checker.

Partly proven rewrites can assume away whole branches

2026-10-11T00:00:00Z

Asked. Lane a-H20 continued the deferred function ped_task_update from lane a-H16 (18 stages).

Found. The earlier stage-17 rewrite never reads the five scan slots that the original checks before its bit-21 test, and it ignores the scan-site answer of the state word's bit-21-set arm. Both branches are reachable in the original but no stage contract sets them, so the stage-17 contract passed without exercising them. Verified: the rewrite and the contract have no read of the slots; the checker still passes with the slots zero.

Fact	Value	Meaning
Scan slots read by the original before the bit-21 test	five words	a nonzero slot takes another route; a rewrite must read them or declare the route
Bit-21-set arm's answer	ignored by the earlier rewrite	a nonzero answer calls a further helper

Decided. Stage 22 adds guards that panic on either route, so a reach is a fault and not a silent pass. The guards do not change behaviour on the zero routes, and the 21 earlier contracts still pass.

How to reproduce. Read the scan loop and the bit-21 arm in the original's listing; compare with the rewrite's flag-set branch; run the stage 22 contract with the slots set nonzero (not done in this lane).

Status. Verified by reading the code and by the checker's zero-slot runs. Not yet tested with nonzero slots (the next lane's first experiment).

An earlier stage read the wrong cursor on its second pass (lane a-H19)

2026-10-11T00:00:00Z

What was asked. Continue the partly proven rewrite of one particle-effect evaluator (the loop over the rule count) from the stages left by earlier lanes.

What was found. The stage that covers the path where the clamped count is zero or negative takes its second pass from the header callee's answer. The original takes the second pass from the rule cursor argument. Every contract for that stage pins the header answer to the cursor argument, so the two are equal in every trial and the stage passes. With a different header answer the stage failed in all 300 trials. Verified: the stage fails with a header answer that differs from the cursor (300/300, a global write the original does not make), and passes after the one-line correction in this lane's copy (1000/1000 with the pinned header answer, 300/300 with a different one).

Item	Value	Status
Earlier stage, as recorded	passes only with the header answer pinned to the cursor	Verified
Earlier stage, with a different header answer	300/300 trials fail	Verified
Corrected stage (this lane's copy only)	1000/1000 pinned; 300/300 with a different header answer	Verified
Other earlier stages (JE, S3, S4 with pinned header, S4 no-backtrack)	1000/1000 each, mutants caught	Verified

What was decided. The earlier lanes' files are not changed. The corrected stage is in the lane's retry folder. Future stage contracts for this function should vary the header answer, not pin it, so that a stage like this cannot pass by construction.

How to reproduce. Derive a stage contract from the S4 contract with the header callee's script set to a heap segment other than the cursor's, run the checker with 300 trials, and compare the verdicts before and after the one-line change.

Lane trap: copied sources keep old timestamps, and checker pins with different periods hide routes

2026-10-11T00:00:00Z

Asked. Continue a deferred function from its last stage. Each stage edits the rewrite source and the contract, then the stock checker runs the stage and its wrong version.

Finding	Status	What it means
Copying a file in PowerShell keeps the source's last-write time. A restored source can look older than the library built from the edited copy, so cargo skips the rebuild.	Verified (the lane rebuilt after touching the file; the diagnostic library had been running)	Several probes ran a diagnostic library and looked like rewrite faults for about twenty minutes. Set the time to now after any copy, or delete the crate's output before a build.
Contract scripts cycle with the trial number modulo their own length. Two scripts with periods two and four cannot reach every combination when the trial groups are coupled, and a route that needs a particular pair stays unreached and the verdict goes vacuous.	Verified (decoupling by period four removed one vacuity and exposed a mismatch that the earlier pins had hidden)	Choose one cycle length for every script that must line up, and check the call coverage for each callee after a change.
A pinned float route (nibble two) with a positive entry value and a flag-set trial mismatched on the constructor block only when both were present.	Verified by decoupling (the mismatch disappears when the nibble pin is one); cause not yet located	Left open for the next lane; the route is recorded in the lane's notes.

Decided. Touch copied sources before every build; keep every script's cycle length equal within a stage.

How to reproduce. Restore a source with copy, build with cargo, and compare the library's time with the source's time. For the coupling, print the call-coverage map of the verdict and look for callees that never fire.

Checker trap: a global written on every pass is compared only at its final value

2026-10-11T00:00:00Z

2026-10-11, lane a-H15. Verified.

What was asked. Continue a particle-effect evaluator (one of the functions an earlier lane deferred as partly proven) to a loop stage, with the checker on version 8 and strict contracts.

Fact	Value	What it means
Global words written on each pass of a loop	Two 4-byte ranges, written on every pass	The globals check compares only the final value of each range, not what earlier passes wrote.
Last pass of the loop in the stage contract	Writes zero to both words	A swap of the two words is invisible in that contract (the wrong version passed 1,000 of 1,000 trials).
Single-pass twin of the same contract	Swap caught in 3 of 4 trials	The swap is visible only when the last pass writes a nonzero word.

What was decided. A global that a loop writes on every pass needs a stage where the final pass writes a nonzero value, or a single-pass twin contract, to show that the neighbour-swap wrong version fails. The two-pass contract keeps its own wrong version (no second pass), which is caught.

Correction to an earlier lane. The earlier lane pinned an incoming register to zero because the function was thought to read its upper bits. The instruction bytes show that the function zeroes that register before the flag test, so the incoming value is never read. The pin was removed and the stage still passes 1,000 of 1,000 trials.

How to reproduce. Run the stock checker on the stage-4 contract and its single-pass twin; compare the globals check in both verdicts. The contract generator and both verdicts are in the lane's scratch folder.

Occlusion group update: the stage proofs hold, but a stack word and the closed-gate return keep it partly proven

2026-10-10T00:00:00Z

Asked. Finish the deferred occlusion group update function from the earlier stage work.

Fact	Value	Meaning
Stage proofs re-run on the stock worker	7 stages, 1000/1000 each, wrong export 3/3	Verified (ran it)
Closed-gate return register compared	59 of 60 trials differ	Verified (ran it). The original returns the incoming EAX; the rewrite returns 0.
Stack fill 1 on the positive ID1 and ID3 stages	60/60 fail each	Verified (ran it). The positive lane-1 path reads an uninitialised frame word and writes it to the object; the rewrite stores zero.
Stack fill 1 on the ID4 and zero stages	pass	Verified (ran it). Those paths do not read that word.

Decided. Deferred as partly proven. Full verification needs the game's value of that frame word and whether any caller reads the closed-gate EAX; neither can be settled by the checker.

Unknown. The game's value of the uninitialised word; whether callers use the closed-gate return.

Written by lane a-H03; integrated by the coordinator.

A checker callee's seq list answers only its first step in each trial

2026-10-10T00:00:00Z

What was asked. A lane continuing a deferred function had to extend an earlier stage contract so that a callee alternates its answer between the two sides of a branch, so that the branch the callee guards is exercised.

What was found. The earlier contracts used a seq list for the callee. A seq list is consumed per call, and its position is not carried from one trial to the next. A callee that the original calls once per trial therefore always answered its first step, and the second step never ran. The earlier proof reported that the callee alternated. It did not. The branch guarded by the second answer was never executed, though the function's proof was reported as covering it.

Fact	Value	Status
Callee called once per trial, `seq` [0, 1]	Answer was 0 in every trial (the ID12 callee fired in every trial)	Verified (verdict coverage counts)
Same callee with `script` [0, 1]	Answered 0 and 1 across trials; the callee guarding the second answer fired in half the trials	Verified (verdict coverage counts)
Rewrite that had passed the earlier contract, run against the alternating contract	Failed 30 of 60 on the second answer's tail; passed after its return value was changed to keep the callee's upper return bits	Verified

What was decided. Every alternating answer in this lane's contracts uses script, which the driver cycles per trial. The earlier stage contracts for the same function are not changed here; the next lane should re-derive them with the same rule before relying on them.

How to reproduce. Run the driver on one contract with a callee given seq [0, 1] and one with script [0, 1], both called once per trial. Read the callee's entry in the verdict's coverage block (callees_fired_on_ok) and the branch shapes.

Also learned. A rewrite that keeps only the low byte of a callee's return loses the callee's upper bits. When the original's return value is compared in full, the callee's upper bits are part of the result and must be kept. The checker reproduces them only when the rewrite calls the same stub.

Written by lane a-H02; integrated by the coordinator.

Encrypted callees are stubbed like plain ones; no live capture is needed for them

2026-10-10T00:00:00Z

Asked. A deferred renderer function (its earlier lanes proved only the early exits) was said to need a live capture of the owner's running game, because one of its direct callees lies in the encrypted first megabyte of code and faults when the checker runs it natively.

Fact	Value	What it means
Direct callee in the encrypted range faults when run natively	Verified	The checker reports a read fault at the callee's first instruction.
A call site can be replaced by a scripted stub through the contract's patch list, even when the callee is encrypted	Verified	With every direct call site of the function patched, the original completes 60 of 60 trials without a fault.
Indirect calls through a vtable can be scripted by planting a stub in a heap vtable, and in a game vtable slot through the globals list	Verified	The eight indirect sites of the function run through one stub id; the game's own vtable code is never executed.
Whole-function rewrite with 35 callee ids passes six stock-v8 contracts	Verified	1,000 of 1,000 positives on each, with a same-contract wrong version failing 3 of 3 for each.

Decided. Encrypted callees are handled by stubs exactly like plain callees. A capture is needed only if a callee's real behaviour must be proven, which a stub never does. The earlier deferral's reason, that the mapped image is ciphertext at the callee, is correct about the bytes but was not a blocker for the checker. The function is recorded as verified with its narrowed list (stub semantics, null-receiver fault paths not proven).

Reproduce. Patch each direct call instruction of the function (its relative address in the image) to a scripted callee id in the contract, and plant the stub in each indirect target slot. Run the stock checker in a 60-trial probe: the original reports ok, orig_ok equal to the trial count.

Limits: the proof covers the function under the stub model only; a callee's real effects on its pointer arguments are not compared.

Written by lane a-H01; integrated by the coordinator.

The checker's option for unrelocated absolute reads has never set up on this machine

2026-10-11T00:00:00Z

The checker has a contract option for an original that reads an absolute address which the loader did not relocate: the worker holds the address range of the original's preferred base, so such a read lands on a copy of the image. A lane on a large function asked for the option, was refused, and reported that the repository's own self-test contract for it fails the same way. A checker investigation lane took 15 minutes to settle it. The option fails at set-up on this machine every time, it has done so since the day it was added, and nothing a lane can do changes that.

What was asked

Is the refusal a fault in the checker, a fault in the lane's contract, or the machine? Twenty deferred functions, 27,343 bytes, were queued behind this option, so the answer mattered beyond one lane.

What was found

Question	Finding	How it is known
Does the self-test contract fail?	Yes, at set-up, before any trial: 10 of 10 fresh driver runs, 40 of 40 set-up attempts counting the driver's own retries.	Verified: run on the stock driver and worker.
What holds the range?	One block mapped by the system, present at the first line of the worker's own code, covering the whole range. It is not the worker's image, which sits elsewhere. None of the 768 pieces of the range can be reserved, and the block cannot be released.	Verified: a private copy of the worker that lists the regions in the range before it reserves anything.
Does it depend on how the worker is linked?	The layout changes and the outcome does not. Linked at a fixed base, as the worker is, the block is always there. Linked to load at a random base, some pieces of the range are free on some starts, never all of them: 0 of 40 set-ups.	Verified: two small 32-bit probe programs, one linked each way.
Is it new?	No. The first lane log that records the worker holding none of the range is from 4 October, the day the option went live. Forty-one lane logs record a deferral for it since. No log of a contract passing with the option was found on this machine.	Verified for the logs; that it never passed is inferred from finding none.
Does it depend on load, or on how the worker is started?	No: the same with 25 other workers running and with none started by the driver.	Verified.
Would it work after a restart, or on a machine with an x86 processor?	Unknown. This machine runs 32-bit x86 code under emulation, which may be what maps the block; that was not tested.	Unknown.

Repairs tried and ruled out: linking the worker differently, reserving earlier (the block is there before the worker runs), releasing the block, and retrying. Covering only the pieces that can be held was not tried, on purpose: the worker refuses a partial cover by design, because a read that lands on a piece it does not hold would silently read the worker's own memory.

What was decided

No lane is sent at a contract that needs this option, or at its self-test contract. The self-test's failure is a known condition of this machine, not a regression in the checker.
The twenty queued functions stay deferred with this as the stated reason. Before any of them is believed to need the option, its claim is checked with the relocation checker: an earlier devlog entry records that every such claim examined so far was wrong, and the worker already relocates absolute immediates so that most data reads work without the option (see the entry of 5 October on a production lane).
Getting the option to work is a design change to the checker, for the owner to decide: for example loading the original at its preferred base in a process built for that purpose. It is not a lane repair.

Correction

Lane notes since 4 October say the range is taken "in every 32-bit process". That is true only of programs linked at a fixed base. It does not change the outcome, and it is corrected here so the next investigation does not start from it.

How to reproduce

Run the self-test contract for the option from the checker's contract folder on the stock driver, ten times, each in a fresh driver process, and read the set-up message. The investigation lane's commands, outputs and the region listings are in its scratch folder.

Hourly reviews, 11 October

2026-10-11T00:00:00Z

The coordinator reviews the project critically once an hour. Since this night the review runs from its own timer on a checklist the owner supplied, and starts from a scorecard a script prints: verified code in bytes per hour that held on the coordinator's own re-run is the measure, lifts are counted separately, and every exception the scorecard lists is acted on in the same hour. One row is added here per review. The day before's rows are in "Hourly reviews, 10 October".

What was asked

To check every hour that the project is going in the right direction and to improve the process from what was just learned.

What was found

Time	Main finding	Decision
00:20	First review on the owner's checklist. In the 1.2 hours since 23:05: verified code up by 10,098 bytes in 11 functions imported after re-run (8,300 bytes an hour), nothing withdrawn, no portable lift, and 3,503 functions named, which took the named count from 32,227 to 35,730 of 37,413. The owner lifted the lane limit twice in the hour, first for naming and then for all Luna lanes, down to 2 GB of spare memory: the lane count went from 12 to 67. No lane stalled. Four Haiku lanes on large functions ended, each further along and none closed, and were continued by fresh lanes from their kits, except a 5,042-byte function that has had three sessions and is parked for a stronger lane. Every imported claim held on the re-run. Blockers, in order: the processor, at its ceiling for the whole hour with up to 21 compilers and 23 checker workers at once, so that a status command took ten minutes; the pipeline on the public repository, failing since 8 October; large functions, of which 384 of 1,807 of 1,000 bytes and more are verified and each takes several lane sessions; and the trust backlog, with 11% of the verified functions recorded on the current checker.	The review got its own timer and a scorecard script, and the checklist went into the agent rules. Production brief version b24: a call into the part of the program encrypted on disk, or through a pointer, is replaced by a stand-in, not deferred (eight of one batch's seventeen functions had been deferred for it). A repair lane was put on the pipeline's two failures and a lift lane was started, the first since 6 October. The runaway guard was taught to recognise a script started by a lane's agent, and stopped seven over 3 GB. A filler starts Luna lanes while memory allows and the supervisor finishes them. Verified bytes per hour rose from about 4,300 to 8,300 while lanes rose fivefold: the extra lanes pay much less than in proportion.
01:25	The best hour since work resumed. In 1.1 hours: verified code up by 14,183 bytes in 105 functions (13,500 bytes an hour, against 8,300 the hour before and 615 over the last 58 hours), five more routines lifted to portable Rust, 273 more functions named (36,003 of 37,413). The pipeline on the public repository passed for the first time since 8 October: a repair lane found both causes (a test received Python's own queue module because a checker import left it in the module cache; a lift test crate included a rewrite that had been withdrawn) and the coordinator tested and installed its candidates. Haiku lanes closed two more large functions, of 3,313 and 2,215 bytes, which makes four tonight; in the second the lane first showed, with realistic output values, that the earlier rewrite was wrong, then corrected and proved it. By model, for lanes that ended in the hour: Luna, 121 functions and 30,041 bytes in 19.7 lane-hours, 1,524 bytes per lane-hour; Haiku, 5,528 bytes in 3.0 lane-hours, 1,831 per lane-hour, all of it in functions Luna's lanes had left partly proven. Proof integrity: the re-run held eleven claims of one Luna lane, and that was the re-run's fault for the third time tonight: one slow contract ran the batch of fifteen into its time limit and the ten after it were never run. Run one at a time, all seventeen hold. Deferrals: 31 with the reason given only as "other" and 21 for time, in lanes that are slowed by the load. Three Luna lanes had written nothing for over twenty minutes; they run below normal priority and are slow, not stopped.	Fixed in the hour. Every Luna lane's processes run below normal priority, so the steps that turn finished work into counted work get the processor first: thirteen finished lanes had been waiting, two for over half an hour, and the backlog cleared within minutes. Commits go one at a time and each takes only its own paths, after a pipeline repair went into the history inside an import commit that happened at the same moment. The re-run runs one contract per driver process with its own time limit, reports a missing verdict as its own failure, accepts a contract without a wrong version when the lane's other contracts reject theirs, and takes a wrong version as equivalent only when the coordinator has recorded why. Next, with owners: the two large functions still partly proven (fresh Haiku lanes when the load allows; the 5,042-byte one waits for a stronger lane); the deferrals marked "other" (the coordinator reads a sample before the next review and the brief gets the missing reasons); the 14,997 proofs still to re-run on the current checker (nine Luna lanes running); one verified function whose contract and rewrite disagree about the register a callee's result is read from, found by the lift lane (a checker-reading lane). Accelerating: yes, against both the previous hour and the baseline, with the lane count unchanged from the hour before; the gain came from clearing the finishing backlog, not from more lanes.
02:05	Scorecard for the 0.7 hours since 01:25: verified code up by 14,152 bytes in 155 functions (17,262 verified; 21,200 bytes an hour against 13,500 the hour before and 850 over the last 58 hours), no lift, 27 functions named, nothing withdrawn, the pipeline passing, no lane stalled, 4.0 GB of memory available. Throughput in total is up; throughput per lane has collapsed. The 56 Luna lanes that ended in the last 65 minutes verified 253 functions and 38,200 bytes in 80.4 lane-hours: 475 bytes per lane-hour, against 1,524 the hour before and about 4,000 when twelve lanes ran. Small-function lanes finished 27% of their batches (175 of 637): 250 functions were not reached and 123 were deferred for time, in lanes that each get a small share of a saturated processor (18 logical processors, about sixty lanes with up to three checker workers each). Another 100 deferrals gave the reason only as "other"; read, most are lanes that counted every checker worker on the machine against a limit of three meant for their own, and did not run the checker at all. Queue lanes had also been handed the same functions several times over: thirty lanes, fourteen distinct functions. Proof integrity: the re-run held two claims of one Luna lane, and this time the finding is real: run again by hand, the original faults on a fifth of the trials where the rewrite returns normally, 60 and 67 of 300. Those two stay out. They are the first Luna claims that do not reproduce, 2 of about 550 tonight. Haiku: two more large functions closed in the window; one lane on a function whose main loop is still unmapped proved four stages and then declined the loop twice, the third function tonight where that happened.	Changed in the hour. The limit of three checker workers is stated as a lane's own in the agent rules and in brief version b25, and the 68 functions left drafted and untested got a queue of their own, with five lanes on them. The queue brief maker counts the Luna queue series as taken; the ten duplicate lanes still running were stopped. The re-run takes the newest library that actually holds the function's export, after two lanes' claims could not be re-run. New Luna starts are paused and the count is left to fall from about sixty to thirty. The owner's instruction was to fill memory to within 2 GB; the reason to depart from it is in the numbers above and in the project's own record, whose best hour (56,000 bytes) was made with 28 lanes, and one word from him restores it. Next, with owners: the two claims that do not reproduce go back to the pool with the re-run's finding (Luna); a lane with one narrow step, a probe that settles where the stack frame starts, for the function whose loop was declined (Haiku); the 14,702 proofs still to re-run on the current checker (Luna, ten lanes running); the next review compares bytes per hour and per lane-hour at the lower count. Accelerating in total, yes; per lane, no, and the per-lane figure is the one that says whether the machine is being used well.
03:00	Scorecard for the 0.9 hours since 02:05: verified code up by 17,653 bytes in 108 functions (17,370 verified; 19,300 bytes an hour against 21,200 the hour before), no lift, nothing withdrawn, the pipeline passing, no lane stalled, 9.1 GB of memory available. New Luna starts have been paused since 02:06 and the count fell from about sixty to 33; total output per hour stayed about level while lanes halved, which is the answer to whether the extra lanes were adding anything. Output per lane-hour is still low, 404 bytes, because the lanes ending in this hour all started in the crowd: small-function lanes finished a quarter of their batches (83 of 335, with 163 not reached and 44 out of time). One lane that started after the worker rule was corrected verified 23 of 23. Proof integrity: nothing held this hour; 19% of the verified functions are now recorded on the current checker (3,303 of 17,475), up from 15%. Haiku: four lanes ended on large functions, none closed, all further along. A lane given one narrow job, to settle a function's stack frame by experiment, did it in 17 minutes where the lane before had declined the function's loop twice; the frame disagreement that stopped the earlier lane turned out not to exist. One function is at 32 stage contracts on one rewrite after four sessions and a few named routes from done; another went from 11 to 18 stages and its lane found a latent error in an inherited stage. Deferrals: 70 for time and 67 marked other, both from lanes started in the crowd.	Changed in the hour: the re-run handles a contract whose name cannot be a file name; a finished lane whose leftover monitors kept waking it was stopped. For large functions the method is now explicit: where the routes are mapped, a fresh lane gets the remaining routes as an ordered list of small steps; where a body is unmapped, a lane gets one narrow job (a probe, a frame map, one pass built call by call against a prepared probe) and is not asked to finish the function. Next: when the filler's window ends in a few minutes it is restarted with a ceiling of thirty Luna lanes and the pause is lifted, so that lanes started at the lower count, on the corrected brief, can be measured; the 04:05 review compares their yield per lane-hour with tonight's. Owners: Luna for small functions, the re-runs of old proofs (14,172 left) and the drafted-but-untested queue; Haiku for the three large functions in hand. Accelerating: level with the previous hour in total at half the lanes, and well above the baseline.
04:05	The best hour of the night, at half the lanes. In the 1.1 hours since 03:00: verified code up by 55,828 bytes in 403 functions (17,773 verified; 51,500 bytes an hour, against 19,300 the hour before), nothing withdrawn, nothing held on the re-run, the pipeline passing, no lane stalled, 9.3 GB of memory available. The Luna count was held at thirty for the whole hour. Luna lanes that ended in the hour verified 404 functions and 51,941 bytes in 51.2 lane-hours, 1,015 bytes per lane-hour against 404 the hour before; small-function lanes finished 59% of their batches against 25%. Lanes started after the count came down and the worker rule was corrected finished full or nearly full batches (28 of 28, 27 of 28, 28 of 30, 23 of 23), and the queue of functions that had been drafted and never run is paying: 28 of 28 in one lane. The hour's figure includes work from lanes that ended earlier and waited to be counted, so the next hour is the cleaner measure. Haiku closed its fifth large function of the night, 4,512 bytes, in five sessions; the coordinator's re-run passed all 70 of its contracts, and three stage variants whose wrong version cannot be seen on that variant are recorded as not counted, with the reason. A second function is one branch from whole: the branch had been taken for a fault in the checker, and a checker investigation lane showed in 16 minutes that it was the contract: a scripted write through a pointer counts words, and the contract asked for eight through a pointer to a two-word local. Recorded on the current checker: 23% of the verified functions, up from 19%. Deferrals for time fell from 70 to 39.	Kept: thirty Luna lanes. The owner's instruction was to fill memory; the measured result of holding at thirty is more than twice the output of sixty, and it stays at thirty unless he says otherwise. Changed in the hour: a second finisher works the list of ended lanes from the other end, with each lane claimed before it is worked on, after eleven finished lanes had been waiting for one finisher; the re-run records, with a reason, stage contracts whose wrong version is not rejected and which the lane itself does not count. For large functions three briefing forms are now in use and each has closed work tonight: an ordered list of small routes where the function is mapped; one narrow job where it is not (a frame map, one loop pass or one block built call by call against a prepared probe); and a checker investigation when a lane reports a checker fault, before anyone believes it. Next, with owners: the last branch of the 3,440-byte function (Haiku, running); the block three routes converge on in the 3,422-byte function (Haiku, running); a lift lane on one narrow data shape, since no lift ran this hour (Haiku, started with this review); 13,808 proofs still to re-run on the current checker (Luna, four lanes). Accelerating: yes, against the previous hour and the baseline.
05:05	A steadier hour, and two faults found in the coordinator's own tooling. In the hour since 04:05: verified code up by 24,334 bytes in 129 functions (17,902 verified; 25,200 bytes an hour, against 51,500 the hour before, which had counted lanes waiting from earlier, and 19,300 the hour before that), nothing withdrawn, nothing held on the re-run, the pipeline passing, 10 GB of memory available. Thirty Luna lanes throughout. Luna lanes that ended in the hour verified 150 functions and 35,137 bytes in 15.1 lane-hours, 2,331 bytes per lane-hour against 1,015 the hour before. Haiku closed its sixth large function of the night, 3,440 bytes, and the way it closed is the hour's lesson: the lane reported it verified while listing, as a limitation, that a version with one subtraction reversed still passed. Sent back to find out why, it found in six minutes that its contracts had placed a table of floats at the wrong address, so the table read as zero on both sides and the whole product it feeds was multiplied by nothing. All 47 contracts were corrected, the reversed version is caught, and the coordinator's re-run holds. A wrong version that passes is never a limitation to list. A portable lift of 23 routines was integrated (four data shapes, 43 differential tests, 39 wrong versions caught); the lane reached 27 of the 149 functions sharing a name prefix, which were at least seven unrelated shapes. Recorded on the current checker: 24% of the verified functions, 13,727 still to re-run. Functions of 1,000 bytes and more: 398 of 1,807 verified.	Fixed in the hour: the watchdog that stops processes left behind by ended lanes was also stopping the coordinator's own re-run of an ended lane's proofs, because the re-run names the lane's contract; it broke one lane's re-run twice (nothing was imported and nothing held, and the lane is being re-run), and it explains the re-runs that broke without cause earlier in the night. Changed: the queue of functions drafted and never run is empty, so its slot goes to the queue of functions that ran out of time (295 functions, nothing blocking them). The three blockers. First, the processor, at 100% all hour with 10 GB of memory unused: finishing one lane took the supervisor up to sixteen minutes. Second, the re-run of old proofs on the current checker: six lanes tonight settled 27 to 95 proofs each of 350 in a hundred minutes, about 80 an hour for the project, because each lane writes its own preparation, build and run scripts first and then waits for the processor; at that rate the backlog is a week. This is scripted work that needs no model, so a tool lane now builds one resumable runner from those lanes' scripts, for the coordinator to run in the background; lanes then take only the proofs that fail. Third, the large functions: 118 partly proven ones hold 192,000 bytes, and three Haiku lanes close about one an hour. Kept: thirty Luna lanes. Next, with owners: the regression runner (Haiku tool lane, started with this review); three large functions in progress (Haiku); the lane count against the processor is the owner's decision and is put to him. Accelerating against the baseline; level with the average of the last three hours.
06:05	The hour's work was on the re-run of old proofs, and it found the process had been quietly running out of work it could see. In the hour since 05:05: verified code up by 33,808 bytes in 270 functions (18,172 verified; 33,300 bytes an hour against 25,200 the hour before), nothing withdrawn, nothing held on the re-run, the pipeline passing, 8 GB of memory available, thirty Luna lanes. Luna lanes that ended in the hour verified 352 functions and 41,297 bytes in 38.5 lane-hours, 1,071 bytes per lane-hour. No large function closed in the hour: two went from 8 to 23 and from 33 to 41 proven stages and stay partly proven, and a third was reported verified with seven branches unwritten and was sent back; five of the seven turned out to be paths on which the original itself faults, the other two are now written and proven. The tool lane delivered a regression runner in 43 minutes: a script that rebuilds tracked rewrites in small crates, re-runs each proof of record unchanged on the current checker with its saved wrong version, and can be stopped and resumed. On 123 functions every outcome was a hold with the wrong version rejected, at about 13 seconds a function with three workers, against about 80 proofs an hour from all the regression lanes together. Wiring it in showed three things. The list maker counted every proof ever handed to a regression lane as taken for good, and lanes reached 27 to 95 of the 350 each was given: it reported 1,636 proofs left of 13,700. Proofs first recorded on checker versions 1 to 4 (5,395 functions) have no saved wrong version: of 350 of them, 83 passed unchanged and wait only for a wrong version to be written. And 257 of those 350 did not build in the tool for one missing import, a gap in the tool and not in the rewrites.	Fixed in the hour: the list maker gives out again what an ended lane did not reach (6,857 proofs available where it saw 1,636); the runner's crates import the runtime's names the way the first weeks' proving crates did; and the runner records what it cannot settle as not reached, with the reason, after its first list would have put 348 verified functions into the deferral queues as if they had failed (corrected before anything imported it). The runner now works through the proofs recorded on versions 5 to 7 (5,599, all with saved wrong versions) with three workers and no model. A Haiku lane that had produced nothing for 24 minutes, with no process of its own alive, was stopped and resumed with its context. The three blockers. First, the processor, still at 100% with memory to spare. Second, the 5,395 old proofs without a wrong version: the runner can do the build and the thousand trials, and a lane then only writes the wrong version; the brief for that kind of lane is next. Third, the large functions: Haiku lanes add stages steadily and close few; three lanes are on three functions with ordered lists. No lift ran in the hour, for want of a lane and not for a blocker: a lift lane is started with this review on the 118 functions the last one did not reach. Kept: thirty Luna lanes. Accelerating against the baseline and against the previous hour.
15:20	Eight hours with nothing verified, because the machine was asleep for six and a half of them. The 07:05 review had measured the hour before (verified code up by 17,550 bytes in 75 functions, half the hour before it, with the processor shared between thirty production lanes, twelve naming lanes, five Haiku lanes and the new regression runner at normal priority) and was being acted on when the coordinator's turn was cut off. With the coordinator idle the request that keeps the machine awake lapsed, and the machine went into standby at 07:06. It woke at 11:33, when every background window ended at once and four Haiku lanes failed for want of a network, slept again from 13:06, and woke at 15:16. Between 07:04 and 15:18: no function verified, none named, none lifted, nothing withdrawn. The regression runner finished its list across the gap: of 350 proofs first recorded on checker version 5, 311 hold with their saved wrong version rejected, 33 have no saved wrong version, 5 could not run and 1 fails. The 38 Luna lanes survived the standby and resumed by themselves; they are hours past their deadlines by the clock and are closing. One large function (4,490 bytes) had been reported verified before the gap; the coordinator's first re-run held it for a reason of form (its wrong versions are kept as contracts of their own, which the re-run read as failing claims), the rule was corrected to recognise such pairs by content, and the second re-run was cut by the standby.	Recovered in the first minutes: the request to stay awake renewed; supervisor, filler, both guards, finisher and registry restarted; the four Haiku lanes resumed with their context and new deadlines; the re-run of the large function and the import of the regression list restarted, with the regression loop to follow. Changed: the regression runner now runs below normal priority like the Luna lanes, after its first hour at normal priority coincided with the halving of new verified code. The three blockers. First, the machine sleeping: the hold on sleep depends on the coordinator's session staying active, and one interrupted turn cost six and a half hours; a hold that does not depend on the session, or a power setting, is the owner's decision and is put to him. Second, the processor, once the lanes are back. Third, the old proofs without a saved wrong version, now about one in ten even among the newer ones. Two questions raised before the gap are with lanes that were cut off and are resumed: whether a scripted callee can write different words on each call within a trial (two lanes stopped on that belief), and how many verified rewrites convert a float to an integer with Rust's cast where the original's instruction behaves differently. Not accelerating: zero for eight hours against a baseline of 7,100 bytes an hour.
16:05	The first 44 minutes after the standby, with the lane count taken from thirty to over a hundred on the owner's instruction to fill memory. Named functions rose by 728, to 36,817 of 37,413: the final naming pass, forty lanes of about 33 functions each with a brief that has each lane read every function in full, named in half an hour what a survey of strings and neighbours had failed on twice. Verified code rose by 6,168 bytes in 96 functions (8,400 bytes an hour, against 25,000 to 51,000 in last night's hours at thirty lanes); most lanes that ended in the window had sat through the standby and came back nearly empty, so the figure understates what a clean hour at this count would give, and the next hour is the measure. Two verified rewrites were withdrawn: an audit of float-to-integer conversions showed on the stock checker, with contracts widened to reach values that do not fit, that both differ from the original there (439 and 67 of 1,000 trials); their proofs of record drew only small floats. 288 more functions with such a conversion are being tested by script. One large function closed (4,490 bytes), the eighth by Haiku lanes: its lane had left it partly proven, and a fresh session found that nothing open was unwritten code. The shared evidence database is built (all 37,410 functions, rebuilt from the image in 90 seconds, a dossier per function in under a second) and is in the briefs. Memory is at the 2 GB reserve: the guard that stops a project process above 3 GB acted 14 times, all on naming lanes running the evidence collector the final-pass brief had pointed them to, and the floor guard has begun stopping lanes' link steps when available memory dips under the floor.	Changed: the naming brief no longer points lanes at an earlier lane's collector, which takes 5 GB a run; it points at the shared database. Production, queue and Haiku briefs carry the database and the rule for conversions (brief version b26). Lane rules in the agent rules file gained eleven lessons from the large-function work, and the night's findings are in the devlog as entries of their own with fourteen lane entries, after the owner asked that findings be documented as they are made. One claim was held on the re-run because its lane had lost the rewrite file; five from another lane were returned to the pool because its library no longer held them. The three blockers. First, the processor: over a hundred lanes on 18 logical processors, with memory at the floor so that the floor guard now costs lanes their builds; the lane count is the owner's decision and the measured figures are put to him with a recommendation. Second, the conversion audit: 288 functions not yet tested, and the verified count may fall again. Third, the large functions still open after six and seven sessions. No lift ran in the window, for want of a lane and not for a blocker; a lift lane follows when naming ends. Accelerating against the 29-hour baseline (7,100 bytes an hour, which includes the eight idle hours); not against last night's hours.
18:05	Two hours with the machine overloaded and then recovering, measured for what it cost. Between 16:02 and 18:00: verified code up by 38,121 bytes in 238 functions (19,400 bytes an hour), named functions up by 436 to 37,253 of 37,413, one withdrawal, no lift. The Luna lane count went from 115 at 15:55 to 30 at 17:50. At its worst, at 16:51 with 93 lanes, 181 threads were waiting for 18 logical processors: lanes' checker runs hit their time limits, the supervisor took fifteen minutes between imports, the regression runner needed 290 seconds a proof where it needs 13 on a free machine, and one command of the coordinator's did not start for 23 minutes. Luna lanes that ended in the two hours verified 281 functions and 33,842 bytes in 94 lane-hours, 359 bytes per lane-hour, against 1,000 to 2,300 in last night's hours at thirty lanes; most of what they did not finish is recorded as out of time or not reached. So the figure for more than a hundred lanes is now a clean one, and it is a third of what thirty lanes give. Naming is all but done: the final pass named 1,164 functions in two and a half hours, and one lane has the 160 that are left. The conversion audit withdrew a third rewrite and all three withdrawn today are proven again with corrected conversions and widened contracts; of 95 functions that needed the audit's test, 48 are tested. The audit also turned up something wider: on widened inputs, several verified rewrites differ from the original for reasons that are not the conversion. The first one examined is a clamp the original does with a signed comparison and the rewrite with an unsigned one.	Changed in the window: starts were paused when memory reached the floor and the floor guard began stopping lanes' link steps; the coordinator's own supervising processes run above normal priority; and when the filler's window ended, with the owner asking whether more agents would help, it was restarted with a ceiling of thirty, which both of his options include, pending his answer. The re-run was corrected three times for the form in which lanes keep wrong versions: several contracts per function, paired contracts that share a name (the wrong one's verdict overwrote the right one's), and wrong versions built as a second library beside the output folder; 27 claims of two lanes held for that last reason are being re-run. The three blockers. First, the lane count, which is the owner's decision: every measurement now says thirty production lanes verify about three times what a hundred do. Second, rewrites that differ from the original outside the range their proofs drew: the conversion class is being closed, the signed and unsigned comparison is a second class, and an investigation lane is on four functions. Third, large functions: two are being worked state by state and route by route, and neither closed in the window. No lift ran, for want of a lane. Accelerating against the 31-hour baseline; below last night's hours.
19:05	The first clean hour at thirty lanes since the overload, and the day's audit of proofs came to a head. Between 18:00 and 18:59: verified code up by 18,824 bytes in 291 functions net of six withdrawals (19,100 bytes an hour), three routines lifted, nothing named. Half the game's functions are now verified: 18,888 of 37,413. Luna lanes that ended in the hour verified 326 functions and 31,716 bytes in 67 lane-hours; most of those lanes had started during the overload. The audit that widens a proof's inputs has now tested every function it listed. It has withdrawn nine verified rewrites today: six whose float-to-integer conversion differs from the original out of range, one that clamps with the wrong signedness, one with a float comparison that differs when the operands are equal, and one whose cause is not yet located. Five are proven again, and each of the strengthening lanes found a second fault behind the first once it widened every input: a constant the original reads from the image, a second conversion, a branch the rewrite did not have. Eight more rewrites differ on widened inputs and are being reduced one by one before anything is done to them. Sixty passed the widened test without an extreme value reaching the code in question, which settles nothing. Naming has reached what can be read: of the 160 functions still unnamed, the final-pass lanes found them to be jumps into the part of the image that is encrypted on disk, entries that are not functions, and bare thunks. The pipeline on the public repository failed on the afternoon's last lift commit, for three reasons.	Fixed in the hour. The pipeline's consistency check failed because five verified rewrites had files and no row in the index: three finishers and the coordinator had run the importer at once, and the last writer's copy of the index dropped the others' rows. The rows are restored and the importer and the withdrawal script now hold one lock from reading the index to writing it. The fault was on the safe side: verified work was not being counted. The second failure, the assembled library of all rewrites not building in one shard, is with a repair lane, and nothing further is integrated into the workspace crates until it reports; the third, formatting, is advisory. The coordinator's re-run was corrected twice more for the form of lanes' proofs (one library per group of functions; contract families under several claims), and 36 good claims held for those reasons were re-run and imported. A count in a changelog entry was wrong by the coordinator's own addition and was corrected. Naming lanes are no longer started for a function three lanes could not name. The three blockers. First, proofs with ordinary input ranges: nine rewrites withdrawn, eight under examination, sixty unsettled, and two classes (comparisons' signedness, float comparisons at equality) not yet searched for across the verified set; this is now the main trust item. Second, the pipeline. Third, the lane count, still the owner's decision and held at thirty. The 160 unnamed functions need either a capture of the encrypted code from the owner's own running copy or a decision on systematic names: both are his. Accelerating against the 32-hour baseline; level with the 16:00 to 18:00 window.
20:05	An hour in which production held its rate and the audits kept finding things. Between 18:59 and 20:04: verified code up by 19,088 bytes in 53 functions net of seven removals (17,620 bytes an hour, against 8,559 over the last 33 hours), nothing lifted, five functions named. Luna lanes that ended in the hour verified 95 functions and 19,840 bytes in 20 lane-hours. The pipeline is green again: its assembler had been blaming compile errors on the wrong files, and with that corrected its manifest shows something larger, that 706 of 19,026 verified rewrites are left out of the assembled library because the published file does not build alone (helpers, constants and types that stayed in the proving lane's crate; in two cases the whole body). The two investigation lanes on widened inputs settled their eight functions: six are real differences and were withdrawn, each shown on the stock checker on trials the original completes, and two are cleared (an inconsistent widened contract; a failure only where the original itself faults). The causes add four classes to the morning's three: a float comparison's predicate at equality (now in two rewrites, with three more suspected from the instructions and not yet shown), call arguments in the wrong order, a float sum with unpinned operands, and a field read before the test that guards it. One rewrite proven again this morning was withdrawn a second time on a wider contract. One function withdrawn earlier was proven again, with a second fault found behind the first. Fifteen withdrawals of fourteen rewrites today; seven of the fourteen are back.	Acted on in the hour. The assembler's correction, found by a repair lane, was reviewed and applied with three tests. The production brief is now version b27: six rules from the withdrawn rewrites with what a contract must reach to see each, and a rule that a lane builds its proving library from the files it publishes and nothing else. A tool lane is classifying the 706, writing a self-containment check for the importer, and proving repairs from the lanes' own source; they stay counted until it reports, with a devlog entry saying what the count includes. Three strengthening lanes have the withdrawn rewrites that have corrected copies, one of them charged with making the checker observe the three suspect comparisons before anything is withdrawn on a reading. The coordinator made two errors and corrected both: it imported one function by hand without its re-run (in the verified set for two minutes, taken out with a changelog entry), and its re-run was holding good claims for the way lanes store wrong versions, 36 of the hour's 39 held claims and 63 of the 83 held in all; the re-run now recognises four more layouts, requires the wrong version to be rejected by the same contract as the proof, and eleven lanes are being re-run. The three blockers. First, how much of the verified set differs from the original outside its proofs' ranges: every lane that widens inputs finds more, and no audit yet bounds it. Second, the 706 files that are not the code that was proven. Third, the coordinator's own re-run, corrected seven times today for the form of a lane's output: each correction was on the safe side, and each cost verified work an hour or more. Lifting had no lane this hour and gets one now. The lane count stays at thirty until the owner decides. Accelerating against the 33-hour baseline; level with the last three hours.
21:05	The best hour for portable code so far, and two more ways found in which a proof can say less than it appears to. Between 20:04 and 20:59: verified code up by 20,549 bytes in 206 functions (22,417 bytes an hour, against 8,935 over the last 34 hours); 399 routines lifted, where the hour before had none. The lifts came from choosing lists by shape: every verified function of one small size that calls nothing. Two lanes took sixteen minutes each to show that 229 functions of 25 bytes are the ratio routine lifted five days ago and that 170 functions of 21 bytes are two small list and store routines; the coordinator ran all 456 differential tests itself before committing. 922 verified routines now have a portable counterpart. Of the sixteen rewrites withdrawn today for differences outside what their proofs covered, fourteen are proven again and counted, several with a second, third or fourth fault found behind the first once every input was widened. The first new gap: a contract of record that set two globals at addresses inside the code section, so that its proof never exercised the code it was about. With the addresses corrected the rewrite fails, as an audit had predicted from the original's instruction. 54 contracts of record place a value in code, 148 leave a write uncompared, and 288 share the signature. The second: by default the checker fills unused stack with a pattern, the manual lets a contract set the fill to zero, and 2,081 contracts of record do (11 per cent); three functions examined today passed only because of it, each reading a frame word it had not written. Luna lanes that ended in the hour verified 226 functions and 22,832 bytes in 44 lane-hours. An owner's request began in the hour: research into the Bevy engine as the platform under the finished game, in two lanes, one on Bevy's current state from primary sources and one on what this engine needs from a host.	Acted on in the hour. The import now checks that every published file builds alone, with the tool lane's check wired into the finisher; an unattended prover has started on the 550 repaired files, each built alone and run against its lane's contract and wrong version before it may replace the published one. The lane that found the misplaced globals is correcting each such contract and running the verified rewrite through it, the 54 certain cases first, and will return a list to withdraw and a list to strengthen; its check for the driver will be adopted in a narrower form than it proposed (refuse code, gaps and addresses outside the image; warn for read-only data, where varying a constant is a wanted test). The production brief is now version b28: one stated layout for wrong-version contracts, how to turn an image address into the offset a contract wants and prove each value is seen, and a rule that the stack fill is not set to zero to make a proof pass. The coordinator's re-run was corrected for the eighth time today and now finds a wrong-version contract by its content in any folder of the lane; 22 claims held in the hour, 19 of them for that reason, are being run again. A fourth lift lane follows the third. The three blockers. First, proofs that cover less than they say: sixteen withdrawals on widened inputs, 54 to 288 contracts with misplaced or uncompared globals, 2,081 with a zero stack fill; each needs its own audit run and none is bounded yet. Second, the 706 published files that are not the proven code, now with a gate and a prover. Third, old proofs: the script that re-runs them confirms about nineteen an hour under this load, a third of what it tries, and its three workers go to the repaired-file prover when its current list ends. Stop doing: lift lanes on groups chosen by name. Accelerating against the 34-hour baseline; the highest verified rate at thirty lanes today.
22:05	A steady hour of production, the day's withdrawals closed out, and a pipeline failure of the coordinator's own making. Between 20:59 and 22:04: verified code up by 18,039 bytes in 197 functions (16,651 bytes an hour, against 9,174 over the last 35 hours); 177 more routines lifted, to 1,099. Luna lanes that ended in the hour verified 216 functions and 16,782 bytes in 38 lane-hours. All sixteen rewrites withdrawn today for differing from the original outside what their proofs covered are proven again and counted, and the day's account is written up: none was caught by its contract of record, and at least eight had further faults behind the first. The lane on misplaced globals finished with no withdrawals: of 54 contracts that set a value inside the code section, 32 rewrites still pass once the contract is corrected, 5 have an original that faults on the corrected value, and 17 have no mechanical correction; of the 148 with an uncompared write, 45 were run and none fails. Its check is now in the driver: a contract that sets a value in code is refused. The first measurement of the zero stack fill, on 40 of 2,081 contracts: a third pass with the patterned fill as well; half fail only the comparison of calls, where the original hands a callee a buffer it has not yet filled; one in six fails on stored memory or globals, a real dependence on the zero. The unattended prover of repaired published files has settled 277 of 529: 82 hold with their wrong version rejected, 177 pass where the proving lane has no wrong version to run, 14 cannot run, and 4 fail, the two examined being an old vacuous contract and a repair that is not a pure renaming for one shape of script native. The largest function in hand had its ninth Haiku session and gained one stage.	Acted on in the hour. The pipeline failed on two commits because the coordinator adopted the driver's placement check without moving the pinned hash of the reviewed driver that its own stock runner checks; the pin is corrected, the 296 script tests pass, and a change to the driver and its pin now go in one commit. Two more of the coordinator's slips were caught before they were committed or were corrected the same hour: a workspace-wide format run that reformatted four verified rewrites through a lift crate's path modules (restored; the modules are now marked so the formatter cannot follow them), and two figures run together in a changelog entry (corrected in an entry of its own). The integration script learned the path-module form and reviewed additions to the core crate. Lift lanes keep going on lists chosen by shape while they yield: five lanes gave 576 routines in the evening, with the yield falling as the functions get larger (229 and 170 of the two smallest sizes; 36 of 141 at 37 to 62 bytes). Stop doing, for tonight: the nine-session function. It has taken a Haiku lane for most of a day at one stage a session, its remaining blocks have each resisted a lane, and 197 other partly proven functions wait in the same queue; two lanes now take the next two of those, and the large one keeps its plan file for a later session with the stack map. The three blockers. First, proofs that cover less than they say, now with three measured audits and one of them closed without a withdrawal. Second, the 706 published files, with the prover two fifths through. Third, the coordinator's own process: three slips in an hour, each caught by a guard or a second look, none reaching a verified count. Accelerating against the 35-hour baseline; below the hour before, which had the re-imports.
23:05	Production steady, the leaf functions lifted out, and two faults of the coordinator's own found in what it had changed during the evening. Between 22:04 and 23:02: verified code up by 14,859 bytes in 156 functions (15,371 bytes an hour, against 13,557 over the last 24 hours); 170 more routines lifted, to 1,269. Luna lanes that ended in the hour verified 192 functions and 18,408 bytes in 28 lane-hours, with one claim held. Nothing was withdrawn. Nine lanes on lists chosen by shape lifted 749 routines between 20:10 and 22:57; the last three showed the supply ending: a tenth of the functions of 26 to 36 bytes fell into families, and a harvest that matched all 1,977 remaining leaf functions against the lifted routines found 44. What remains is mostly one of a kind. The unattended prover finished the repaired published files: of 549 settled, 129 hold with their wrong version rejected, 371 pass their contract of record where the proving lane has no wrong version to run, 41 could not be run and 8 fail, the three examined being an old vacuous contract and a repair that is not a pure renaming for tail-jump script natives. Two partly proven functions were taken from the queue in place of the nine-session one: the first, of 973 bytes, was verified whole in one contract with four wrong versions; the second, of 2,781 bytes, gained six proven stages and stays open.	Two faults of the coordinator's, both from the evening's own changes, found and corrected. First, the paragraphs added to the production brief as versions b27 and b28 were inserted into the brief makers with their backslashes unescaped, so that in every brief generated from 20:00 three paths lost a letter to a control character (the contracts folder, the verdicts folder, the rewrites folder). Luna lanes inferred the right names and their imports went through; one Haiku lane followed the text literally and wrote its contracts under a mangled name. The makers are repaired on validated copies and a freshly generated brief was checked; the fault was found by reading a lane's report, not by any guard, and the makers' output is now checked for control characters. Second, the adoption of the driver's placement check broke the pipeline twice (the unmoved pin of the driver's hash, then two packages the module imported at load); both are fixed and the pipeline has a green run since. The coordinator's re-run gained a fallback for a lane whose wrong-version library does not export the right version, which had blocked a lane of 13; and it showed its own limit: at 300 trials it missed a wrong version that fails on 6 trials in 1,200, held a good claim, and passed it at the contract's own count. Next: the 500 repaired files that pass go into the verified tree as one reviewed change, each checked to build alone; the stack-fill audit runs through the night; lifting moves to classes, where 117 with four or more verified methods and none lifted hold about 105,000 verified bytes, and two such lanes have started. The three blockers. First, proofs that cover less than they say: the zero stack fill (2,081 contracts, audit running), uncompared writes (103 of 148 not yet run), old proofs with no wrong version (371 in the prover's sample of the unbuildable files alone). Second, the coordinator's process under its own pace of change: five slips in two hours, each small, two reaching lanes. Changes to the brief makers and to the checker folder are now made on a copy, validated, and only then put in place. Third, the lane count, still the owner's decision and held at thirty; and the host platform questions put to him. Accelerating against the 24-hour baseline, slightly.

Haiku lanes on three large functions that earlier lanes left partly proven

2026-10-10T00:00:00Z

Three lanes run by Claude Haiku 5.5 each took one function of 2,200 to 2,900 bytes that three or four lanes of another model had left partly proven in stages. One closed its function in 36 minutes; two moved theirs further and stopped. None of the three is counted as verified today: the one proof that closed is held back because of the form of its rewrite. Each lane also found something the earlier lanes had got wrong.

What was asked

The owner asked for Haiku lanes on the harder work where the other model's lanes are struggling. The first test was the queue of functions partly proven in stages, which holds the most deferred code: 72 functions, 186,000 bytes.

What was found

Lane's function	Result	Time used of 95 minutes	What it found
A renderer set-up routine, 2,491 bytes, 60 call sites	One rewrite passes six contracts at 1,000 trials each; every wrong version fails. The coordinator re-ran all six: they reproduce.	36	The earlier deferral was wrong. It said the main path needs a capture from the running game because a callee lies in the part of the program that is encrypted on disk. A call site can be replaced by a scripted stand-in whether or not its target is encrypted: with all 52 direct call sites replaced and one function-table slot planted, the original completes every trial.
A proximity sweep, 2,215 bytes	Partly proven, further than before: two new stages at 1,000 trials, four earlier ones replayed. The loop, the visited-set check and one flag branch remain.	31	An earlier stage's claim was wrong. Its contract gave a callee an answer sequence to alternate between two answers, but a sequence is consumed per call within a trial, and this callee is called once per trial, so only the first answer was ever given and one of the two paths never ran. The manual describes the sequence this way; the earlier contract misused it.
An audio occlusion update, 2,924 bytes	Partly proven: six earlier stages replayed and one new mixed stage, each at 1,000 trials. Two things block the whole function.	22	Two gaps in the earlier stages. On the early-exit path the original returns whatever was already in the return register and the rewrite returns zero; the stage that "passed" did not compare that register. And two paths store a stack word the function has not written; the rewrite assumes zero, and the stages fail when the stack is filled with anything else.

Verified The six contracts of the first function were re-run by the coordinator on the stock checker against the lane's library: 6,000 trials pass and each wrong version is rejected.

Verified The answer-sequence behaviour is as the driver's manual states it. Whether other accepted proofs used a sequence for a callee that is called once per trial has not been counted yet.

Inferred The unwritten stack word in the third function is probably filled by a callee through a pointer argument: the lane's contracts leave the callees' writes through pointers unmodelled. The lane did not test this.

What was decided or recommended

The first function's rewrite is not imported. Its proof holds, but the rewrite keeps the original's stack as an array and mirrors every push into it. That carries the original's instruction sequence over instead of writing the behaviour as Rust, and the project's first rule allows only the second in the repository; a doubtful case stays out. It is recorded as held, with the reason, and needs rewriting in the project's form and proving again on the same six contracts. The lane very likely chose this form to reproduce stale stack words exactly, which is the same problem that stopped the third lane.
Two lanes stopped with most of their time unused while a named next step remained: read the callers to see whether the return value is used; model the callee's write through its pointer argument; continue to the loop. The launch note for these lanes gets a rule against stopping early, and a rule about the form of a large rewrite, before any more are started.
A count of accepted proofs that use an answer sequence for a callee called once per trial goes on the list of open trust work.
A deferral that says a function needs a capture from the running game because a callee is encrypted is to be re-read: 38 functions are in that queue.

How to reproduce it

Each lane's folder holds its stage contracts, the rewrite and its wrong versions, and a note for the next lane. The coordinator's re-run takes the contracts unchanged and runs them with the repository's driver.

What was confusing or went wrong

The work was paused by the owner after this batch, so the two unfinished functions were not sent back to their lanes. Lanes were not told what form a large rewrite must have beyond the standard for small ones, and the one lane that finished solved a hard problem in a form that cannot be published.

Hourly reviews, 10 October

2026-10-10T00:00:00Z

The coordinator reviews the project critically once an hour: whether the work is still pointed at the goal, what the last hour produced, what weakened confidence in the results, and what changes because of it. One row is added here per review. These rows are the Claude coordinator's; a second coordinator session runs lanes of another model on the same repository and keeps its own reviews. The last rows before these are in "Hourly reviews, 6 October".

What was asked

To check every hour that the project is going in the right direction and to improve the process from what was just learned.

What was found

Time	Main finding	Decision
11:10	Work resumed today with a different lane model on this side: Claude Haiku 5.5 subagents, by the owner's instruction, first as a trial and then for the harder functions the other session's lanes are not getting through. 16,958 functions are verified, 45.3% of the functions. Throughput: one Haiku lane on 20 small functions verified 19 in 30 minutes (910 bytes, about 1,800 bytes per lane-hour, limited by the size of its batch), level with the earlier model's record per function; the entry "A smaller model on the production brief" has the comparison. Trust: the coordinator re-ran all 19 proofs on the stock checker before importing them, and all hold with their wrong versions rejected. One of the 19 is narrower than it looks (a store into the function's own argument slot is invisible to the checker) and says so in its result. Direction: three Haiku lanes are now on large functions that three or four lanes of the other model each left partly proven; the queue of such functions holds 186,000 bytes in 72 functions, the largest queue of deferred work. From their logs after five minutes, all three had read the earlier stage material and one had a combined stage contract passing 1,000 trials with its wrong version caught. The largest risk nothing runs against: two coordinators commit to one working tree with no lock between them, and the pipeline on the public repository has failed on every run since 8 October (a script test that loads the wrong module, and a lift test that includes a rewrite withdrawn on 7 October). Workstation: 13 GB of 47.6 free, no paging, nothing left behind; the registry shows 15 lanes of the other session and 3 of this one, which is at or just over the owner's limit of 15 depending on whether the other session's dispatcher and monitor are counted.	Changed in the hour: a lane-by-name import (a broad pass would take rows the other session is holding for review); a re-run of a new model's claims before import; a launch note for Haiku lanes (a log line every five minutes, one checker worker and one build at a time, since the machine is shared); the queue brief builder can make a lane for chosen functions under its own lane series; the dashboard shows Claude subagent lanes with their model and prompt. The importer now keeps the indentation it finds in the verified index, after its first commit today rewrote the whole file in a different one (content checked identical). Stop doing: the re-run at the full trial count as a gate for small-function lanes; it took 17 minutes for a 30-minute lane, and 300 trials with the wrong version is enough to catch a claim that does not reproduce. No more Haiku lanes are started while the registry is at the limit. The pipeline failures are flagged to the owner as their own piece of work.
22:10	Work started again at 20:30 at the owner's word, with a mix he asked for: Luna lanes for the bulk and Claude Haiku lanes for the harder functions, and 8 GB of memory kept available for his own use. Ten lanes were running by 20:48: seven Luna (four on small functions, one on larger ones, one re-running 350 proofs made on early checker versions, one on deferred functions that pass doubles in vector registers) and three Haiku (the two large functions left partly proven in the morning, and a rewrite of the held function in the project's form). Then the laptop went to sleep at about 20:57 and woke at 22:06. Every lane stood still for 70 minutes; the three Haiku lanes lost their connection and ended, and one push failed. Throughput for the hour is therefore close to nothing: 16,958 verified, unchanged, with 9 functions recorded as verified in lanes that are still running and not yet imported. Trust: nothing new was imported, so nothing to weigh; the Luna lanes run on the plain production brief for the first time from this coordinator, and their claims will be re-run before import as the first Haiku lane's were. One early sign from the Haiku lanes after they were resumed: the lane on the audio function found that the only caller discards the return value that stopped the morning's lane, which is the check the new launch note tells lanes to make. Workstation: 15.8 GB available of 47.6, no paging, both guards alive.	Changed in the hour. The laptop is asked to stay awake while the session works, and the watch never waits more than four minutes, since the hold lapses after about five idle ones; a closed lid still stops everything, and the owner knows. The three Haiku lanes were resumed from their own state with a new time limit. A launcher for Luna lanes as plain Codex processes replaces the Muse launcher for now, with the same restart rule. A floor guard keeps 8 GB available: no lane is started under 10 GB, and if available memory stays under 8 GB for half a minute the project's largest build is stopped. Launch note h2 for Haiku lanes: do not stop while time and a next step remain; write the behaviour as Rust and never mirror the original's stack; a stack word read before it is written usually comes from a callee's pointer argument; check whether any caller reads a return value before deferring over it. The dashboard and the status script count Luna processes. Stale rows of the morning's other session, 26 still marked as running, are marked stopped when their lane has been silent for an hour. Stop doing: nothing dropped this hour. The Luna lanes' time limits ran through the sleep, so most will stop short of their batches; what they did not reach goes back to the pool. Held at ten lanes until the first Luna claims pass the re-run.
23:05	The first full hour of the evening's mix. 16,992 functions verified, 45.4% of the functions and 32.6% of the code by size: 35 more than at the last review, after one withdrawal. Twelve lanes ran, eight Luna and four Haiku. Throughput by lane kind, in the lanes' real working time (three of the first Luna lanes lost 70 minutes to the laptop's sleep, so their own clocks say less than they did). Luna on small functions: 43 verified in seven lanes that have ended or are well along; the uninterrupted ones are making 10 to 27 functions per lane-hour, against 29 to 38 in the earlier model's record and 37 in this morning's one Haiku lane. Luna on larger functions: 1 of 5, with 4 deferred. Luna on the queue of deferred functions that pass doubles: 4 verified in two lanes, 1 deferred. Luna re-running old proofs: 291 of 312 run hold on the current checker in the first lane, 522 of 522 so far in the two that are running. Haiku on large functions left partly proven: two closed and imported (2,924 and 2,491 bytes, the second being the function held in the morning, now written in the project's form), four more in progress. Trust: every claim was re-run by the coordinator's scripts before import, 40 of 40 from Luna and 2 of 2 from Haiku holding. The re-run itself failed twice in the hour, both times by running a lane's contracts against the wrong library, and the second time it marked nine good claims as not holding before the fault was seen; nothing was imported or withdrawn on it. One function was withdrawn: its old proof is vacuous on the current checker. Twenty old proofs could not be run at all and stay counted as an open item, fourteen of them because their contracts give a stack argument in a form the current driver refuses, which may mean they were made on a private copy of the driver. Direction: the Haiku lanes keep finding errors in earlier stage work (a stage that read two helpers' answers from the wrong register and so always saw zero; sixteen replayed stages that never reach the part of the function they were taken to cover; a second deferral for an encrypted callee that was no blocker). The largest risk nothing runs against is unchanged: the pipeline on the public repository has failed since 8 October. Workstation: 16.4 GB available of 47.6, no paging, processor at 100% for much of the hour.	Changed in the hour. A supervisor for the Luna side finishes each lane when it ends (re-run, hold, import by lane name, publish) and keeps eight running while 10 GB or more is available. The re-run finds a lane's library whether the contract names it or the lane passed it through the environment, handles a function proven by several stage contracts, and reports a run in which every trial fails with no failed comparison as its own fault, which can no longer hold a claim. The importer commits the index when only the recorded checker version changed. All four Haiku lanes on large functions stopped between minute 18 and minute 37 of 95 with their next step named in their own reports, despite the launch note's rule; each was sent back in with its context and the steps in order, and the note now says the limit is a deadline to compute and check, and that an early report with work open is sent back. Stop doing: taking a Haiku lane's first report on a large function as its result. Held at twelve lanes although the owner's limit is fifteen: the limit exists for heat and the processor is already at its ceiling. Open and recorded: the fourteen unrunnable contracts, three tracked rewrites that do not compile, three missing contracts, and a count of accepted proofs that script a once-per-trial callee with an answer sequence.

A smaller model on the production brief: the first Haiku lane

2026-10-10T00:00:00Z

One lane run by Claude Haiku 5.5 took a batch of 20 small functions through the unchanged production brief and verified 19 of them in 30 minutes. The coordinator then re-ran all 19 proofs itself on the stock checker: all 19 hold and every deliberately wrong version is rejected. On small functions it is level with the lanes the process was tuned on. Nothing is measured yet for large functions.

What was asked

The owner asked for Haiku subagents to be tried in place of the earlier lane model, starting with one lane, and for a judgement of whether it is better or worse. The earlier model could not be run alongside, so the comparison is against its recorded lanes of the same kind: small-function production lanes on checker versions 6 to 8.

What was found

Measure	Haiku lane	Earlier model, same lane kind	What it means
Share of the batch verified	19 of 20	92% over its last five lanes, 98% over all lanes on checker versions 6 to 8	Level. The one function not verified calls into the part of the program that is encrypted on disk, which the inventory also flags.
Lane time	30 minutes	41 to 51 minutes	The lane finished its whole batch with most of its time unused, so the batch was the limit, not the model.
Functions per lane-hour	37	29 to 38	Level.
Code per lane-hour	about 1,800 bytes	2,600 to 3,300 bytes	Lower, because this batch's functions were about half the usual size (985 bytes in 20 functions). Not a fair figure until a full-sized batch is run.
Wrong version per function	19 of 19, each a different, specific change	all, by its own record	Level. The changes were well chosen: a store one byte off, a wrong bit toggled, an argument four bytes further on, a scale constant off by one.
Proofs that state what they do not cover	16 of 19	4 of 14 in its last lane of this kind	More forthcoming. Mostly the range of an index the inputs were drawn from.
Independent re-run by the coordinator	19 of 19 hold, 19 wrong versions rejected	14 of 14 on the lane used to test the re-run script	The lane's word for "verified" was right every time.

Verified The figures for the Haiku lane are from its results file, its log and the coordinator's re-run. The earlier model's are computed from its lanes' results files and launcher logs.

Verified The lane reported a limit of the checker that no lane of the earlier model had reported: a function that stores into the stack slot of its own last argument is not seen doing so, because the worker's return path overwrites that word before the comparison. The lane read the worker's source to confirm it, kept the one affected function as verified and listed the gap in that function's result. Another session's notes from 8 October describe the same limit, so the finding is independent, not new. An argument slot belongs to the called function, so a store there is not behaviour its caller can observe; the proof is narrower than it looks and says so.

Unknown Whether this holds for large functions. One lane of 20 small functions is a thin sample, and most of the code still to verify is in functions of 1,000 bytes and more.

What was decided or recommended

The 19 rewrites were imported after the re-run, by lane name.
Three Haiku lanes were started on large functions that several lanes of another model had left partly proven in stages. That is where the owner wants Haiku used, and it is the measurement that is missing.
A lane of a model with no record here has its claims re-run by the coordinator before import. For small functions the re-run is cut from the full trial count to 300 trials: at the full count it took 17 minutes for a lane that itself took 30.
The note given to a Haiku lane at launch now asks for a log line at least every five minutes. The first lane wrote five lines in half an hour, and the coordinator's five-minute report had nothing to show.

How to reproduce it

The baseline is every small-function production lane with a checker version 6, 7 or 8 marker: batch size from its list, verified rows from its results file, minutes from the launcher's lines in its log. The re-run takes each contract the lane wrote, unchanged, and runs it with the repository's driver against the library the contract names; the driver runs the declared wrong version with it.

What was confusing or went wrong

The brief is given whole to a lane of the earlier model. A subagent reads it from a file, and its file reader cuts lines after about 2,000 characters; the brief has longer ones. The lane was given a copy with line breaks added at sentence ends and nothing else changed. The lane also wrote its report under a different file name than the brief asks for, because of a rule of its own environment about that file type; the launch note now says the brief's name is allowed in its scratch folder.

Record a one-word thiscall boundary in differential tests

2026-10-08T00:00:00Z

Verified: the differential runtime now supplies a typed recorder for an object receiver and one stack argument. The existing two-argument cdecl recorder remains available. An i686 regression compares recorded receiver and argument order, return values, and the stack pointer before pushing the argument and after the call returns.

Root review found the first assembly probe did not declare all caller-clobbered registers. The corrected test declares the C ABI clobber set and passed its focused test. The prior nine-test library run predates this test-only correction; no redundant full-suite replay was required. Exact copied runtime and package inputs, reduced path-only lockfile scope and all failed runner attempts remain recorded.

This is a differential-test adapter, not a stock-checker change or native object-class binding. It adds no function credit. Reproduce with the lf-lift-diff library tests on i686; the permanent regression is in its runtime module.

Preserve float callback payload words in a portable seam

2026-10-08T00:00:00Z

Verified: the new pointer-free forwarding module carries binary32 words through FixedLayout and exact equality, preserving NaN payloads and signed zero. A caller supplies the collaborator; ordered integer arguments and the return word are retained.

An i686 differential fixture compared the proposed module to the unchanged verified Rust wrapper across twelve edge words and a four-call sequence. An AArch64 compilation check passed. Both ran under the global three-job memory guard. This establishes a forwarding seam, not the native callback implementation or binding, and adds no verified-function or portable-function credit.

The first import check rejected CRLF patch context against LF source; normalizing only patch line endings repaired the import. The imported module matches the tested source after newline normalization. Reproduce with the lf-lift crate on the installed targets; scoped differential logs and input hashes remain in the coordinator evidence archive. Source: forwarding module.

Hourly review: repair shared lane-state writers and replace repeated blocked reviews

2026-10-08T00:00:00Z

Verified: the previous review was 1.01 hours earlier. Accepted functions increased by one to 16,936, and effective verified bytes increased by 141 to 2,494,687. Portable counterparts remain 483 routines and 45,417 bytes: zero portable throughput this hour. These numbers join the verified index to inventory effective sizes and differential-test imports. The accepted repair passed all nine declared comparisons over 1,000 completed originals; its same-contract field mutant failed three times at the stock failure cap. The complete target body is covered only inside the declared synthetic heap and fixed collaborator fixture.

Verified: reservation, registration and route-refresh helpers previously used separate unlocked read-modify-write operations. A private regression showed registration could publish a running row before discovering a malformed or mismatched claim. The corrected protocol validates the claim first, holds stable file locks in a fixed order, and leaves an explicit pending registration across interrupted multi-file publication. Core contention and crash tests passed. Independent review rejected the first fourth-writer proposal because it embedded old observations and assumed the wrong script directory.

Verified: the actual native-state publisher was adapted to the same transaction helper. Six guarded tests passed, including separated script directories, concurrent registration, pending-row protection, stale and contradictory snapshots, malformed history, and replay of an older running observation after a newer completion. Existing history, preimage backups, encoding and result/log receipts remain. The coordinator installed the pinned helper and four active writers after both writer owners acknowledged a brief quiet window. The obsolete hardcoded writer was excluded, and prior failures and preimages are preserved.

Verified: the native pipeline repeatedly remained below its target of fifteen. Reservations and proposed jobs were never counted as successful native launches. Several short bridge reviews repeated existing production-binding blockers and ended before replacements launched. The brief now requires distinct implementation chains with concrete adapter or harness changes and guarded tests; pending proof acceptance reviews remain separate from portable progress. The historical launcher's zero completed production lanes and error count do not measure native task completions or failures.

Verified workstation check: 6.7 GB physical memory was free, with 19.5 GB commit headroom. All three resource-slot owner records were released, and no large abandoned project process was found. Non-paged kernel memory remained 21.4 GB; two previously identified stuck test processes remained reported. The three-job cap and memory guards remain enforced, and the historical supervisor stays paused.

Verified dashboard inspection: current counts and an opened live lane's test receipts and latest logs were readable through the browser. Screenshot capture failed, so visual rendering has not been confirmed. Live post-deployment registration and snapshot receipts are still being checked. Decision: stop repeated read-only reviews that merely restate a blocker; repair concrete boundary seams, keep snapshots truthful, and integrate only exact source/build/positive/mutant evidence.

Resume review: three accepted proofs; dashboard freshness failure remains visible

2026-10-08T00:00:00Z

Verified: since the previous review, 2.84 hours earlier, three complete target-body proofs were accepted within declared fixtures. Verified functions increased by three to 16,935, with 423 additional effective bytes, reaching 2,494,546. Portable counterparts remain 483 routines and 45,417 bytes. The interrupted interval has no reconstructed hourly entries. Counts come from the verified index joined to inventory effective sizes and differential-test imports.

Verified: the latest accepted proof passed all declared comparisons over 1,000 completed originals. Its same-contract pointed-store mutant failed three times across 26 completed originals. The source projection removes only the mutant export; it is unbuilt, while acceptance binds the preserved tested source and byte-identical owned binary. Native collaborator effects and broader engine states remain outside the fixture proof. The rejected ownership continuation produced zero trials and remains excluded.

Verified: interrupted native tasks were resumed and produced interface repair packets. These unbuilt preparations earned no new portable credit. The dashboard showed current worker log lines but an expired registry, so active states were unknown rather than counted. The monitor was instructed to refresh actual native states immediately and replace finished reviews with distinct implementation tasks. Historical supervisor counts are not native activity measurements.

Verified workstation check: physical memory free was 2.5 GB, commit headroom 8.2 GB, and non-paged kernel memory 21.3 GB. No large abandoned project process was found. The three-job cap and fresh memory checks remain required for every build or checker run; the Muse supervisor remains paused.

Decision: serialize reservations through one dispatcher until the shared claim-ledger race is repaired and tested. Move from repeated proposal reviews to narrowly scoped harness implementations and guarded tests. Refresh the dashboard registry before reporting pipeline health; reservations alone never count as launches.

Hourly review: proof progress resumed; repeated blocked dispatches stop

2026-10-08T00:00:00Z

Verified: since the previous 04:54 review, four complete-body proofs were accepted within explicit collaborator fixtures. Verified functions increased from 16,928 to 16,932; effective verified bytes increased by 461 to 2,494,123. Portable counterparts remain 483 routines and 45,417 bytes, with no increase. These proofs establish the declared observations, not arbitrary engine states or native helper implementations. Reproduce by joining the verified index to the inventory using effective_size and deriving portable counterparts from differential-test imports.

Verified: independent reviews and root checks bound the accepted source, build, preserved binary, contract and stock positive/negative records. The most recent proof passed 1,000 completed originals across all nine comparisons; its deliberately wrong version failed three of four completed cases. Earlier semantic and setup failures remain excluded. Candidate projections remove mutant exports while retaining tested positive helper bytes.

Verified: native dispatch repeatedly fell below the requested 15 tasks as completions arrived. Reservations were sometimes recorded minutes before actual launches. Wrong prompt digests, wrong reviewer references and a misplaced result file caused avoidable work. Corrections and misplaced artifacts were preserved. One root instruction requested a cross-lane binary path that the runner ownership guard correctly rejects; that rejection remains recorded, with no guard bypass.

Verified workstation check: physical memory free was 2.8 GB and commit headroom 5.8 GB, below the 6 GB start guard; non-paged kernel memory was 21.3 GB. No large abandoned project process required stopping. The health report includes two previously stuck processes. Historical supervisor lane counts and error totals do not measure the native workers; the Muse supervisor remains paused. The three-job cap and ownership guards remain enforced.

Decision: brief version luna-recovery-v6 requires machine-derived task pins, explicit absolute output paths, target-matched reviewer references and actual native launch confirmation. Stop replacing memory-blocked workers with repeated guard-only retries. Fill vacancies with distinct preparation and final integration packets, and allocate a portable-counterpart preparation task so progress serves the portable game goal. Preparation and unbuilt projections earn no new proof or portable credit.

Hourly review: accepted proofs grew; dispatch still falls behind

2026-10-08T00:00:00Z

Verified: since the previous 03:52 review, four complete-body proofs were accepted under explicit collaborator fixtures. The verified total is 16,928 and effective verified size is 2,493,662 bytes: increases of four functions and 191 bytes. Portable counterparts remain 483 and 45,417 bytes, with no increase. These fixture proofs do not establish arbitrary engine states or native collaborator implementations.

Verified measurement correction: an initial invocation used raw inventory sizes rather than the established effective-size calculation and reported an incorrect 23,129-byte increase. Its output and snapshot were preserved; the current review snapshot uses the established calculation. Reproduce by joining the verified index to the function inventory through effective_size, and deriving portable counterparts from the generated differential-test imports.

Verified: workers completed successful positive and same-contract negative runs after semantic repairs, with earlier failures retained. A log was overwritten during a native task startup; its earlier contents remain unknown and unrecovered. Exclusive identity reservations now precede dispatch, and a further concurrency patch is proposed but untested.

Verified: the dispatcher repeatedly fell below the requested 15 active tasks as workers completed. Root directly launched ten distinct replacement tasks and restored the roster temporarily. Continuous refill remains necessary; proposals and independent audits are not counted as new proofs. Historical supervisor measurements do not describe the native workers.

Verified workstation check: no large abandoned project process required stopping. Physical memory free was 3.0 GB, commit headroom 5.8 GB, and non-paged kernel memory 21.3 GB. The existing three-job limit and memory guards remain enforced. Production waits below the commit guard rather than bypassing it.

Decision: integrate only exact reviewed evidence and unchanged positive-source projections, preserve exclusions and failures, keep the native roster filled with distinct useful work, and test the reservation proposal before adopting it. The historical supervisor stays paused.

Hourly reliability and integration review

2026-10-08T00:00:00Z

Asked whether native workers are producing accepted progress and whether the allocation loop stays filled. Verified from the review snapshot: the preceding 1.01 hours added zero integrated functions and zero verified bytes. The total at that snapshot was 16,924 functions and 2,493,471 bytes. Portable counterparts remained 483 routines and 45,417 bytes, with zero increase.

Time	Main finding	Decision
03:52	Completed candidate runs were awaiting evidence review; repeated dispatcher hesitation left vacancies. Legacy supervisor totals do not measure native worker throughput.	Refill from distinct proof reviews, source projections and concrete repairs without waiting for renewed permission. Review raw evidence before importing; keep fixture limits and failed attempts explicit.

Verified process changes: the Cargo lock preparation fix passed 39 merged tests and a real fresh build. The dashboard review-activity and recent-finished changes passed 39 tests and visual inspection. A wrong support dependency caused one recorded checker startup stall; cleanup was checked by owned process identity. A separate candidate formula mismatch remains failed evidence while a fresh generation repairs it.

Trust: some top-level preparation records conflicted with final generation evidence. Preserve the original records and reconcile current fields against immutable build and run receipts. The later dated brief confirmed an earlier build-gate release; do not backdate it or interpret its append time as the initial authorization. Missing invocation-time wrapper hashes remain explicit gaps.

Direction: a stock comparison of a complete function body under scripted collaborators does not establish a portable engine or collaborator behavior. The largest unmeasured risk remains end-to-end native game execution. Stop repeatedly reading the full historical agent tree and waiting for another task list when useful completed evidence already awaits review.

Verified health at the snapshot: 4.0 GB physical memory free, 6.7 GB commit headroom, 130 GB disk free and no large, old busy or abandoned project processes found. Kernel nonpaged memory was 21.1 GB. User applications were left untouched, and the historical Muse supervisor remained paused. Local jobs retain the global three-job cap and memory guards.

Reproduction: run the coordinator review metrics and health check, inspect the fresh native registry and slot-owner records, then compare raw positive and same-contract negative verdicts with build and stock-input receipts. The first accepted wrapper after this snapshot was committed separately and does not alter this hourly measurement.

Hourly review: useful work and fail-closed launches

2026-10-08T00:00:00Z

Verified: since the 01:50 review, the canonical game ledger gained eight verified functions and 785 verified bytes in 1.04 hours, reaching 16,924 functions and 2,493,471 bytes. The measured rates are eight functions and 752 bytes per hour. Pending reviews, bounded stages and failed controls receive no credit.

Verified: proven portable counterparts remain at 483 routines and 45,417 bytes. Three newly integrated streaming ownership tests cover cancellation, close and untracked completion while reads are Running; they do not add game-function or portable-counterpart counts. Inferred: continued wrapper throughput alone will not establish a portable engine. The largest uncovered risk remains integration of real subsystem behavior beyond scripted helper fixtures.

Verified: sampled source, contracts and raw pairs exposed a wrongly assigned virtual-call argument count, an unobserved stack write, stale generation references, disabled return comparisons and missing build lineage. Incorrect and bounded evidence remains preserved and excluded. Accepted results state their helper, return, pointer and branch limits explicitly.

Verified: fresh native tasks now have current prompt, results and log routes in the dashboard. Reused contexts confused task scopes, so new preparation workers start with fresh context. Dispatch and reactivation now have one owner to avoid capacity races. Read-only reviews do not replay unchanged thousand-trial batches.

Verified: the first lockfile-preparation proposal failed seven of thirty existing runner tests during root validation. Besides mock incompatibilities, it launched metadata before checks that should reject unsupported dependencies without a child process. The trial patch was reversed, and the original runner identity was restored. The corrected proposal must preserve those guards and pass the complete regression suite before publication. Real offline metadata behavior still needs a bounded smoke check.

Decision: keep new production builds gated while the lockfile and contract preflight fixes are reviewed. Preparation workers can map complete bodies and write scoped Rust and contracts. Stop repeated unaffected probes and reviews; use the released capacity for concrete portability work and actual reliability gaps.

Verified: the workstation health check found no large, old, busy or abandoned project processes. It reported 5.0 GB free physical memory, 7.9 GB commit headroom and 130 GB free disk space. A 20.8 GB nonpaged kernel pool remains a machine-level constraint. The three-job cap and memory guards remain active. Legacy supervisor counters do not represent the native task tree, and the intentionally paused supervisor was not restarted.

Hourly reviews

Time	Main finding	Decision
02:52	Accepted wrapper proofs increased, but portable counterpart totals did not; a launch fix regressed fail-closed checks.	Preserve exclusions, stop unchanged repeats, centralize dispatch, gate builds and require complete regression evidence.

Hourly review: reliable counts and bounded proof claims

2026-10-08T00:00:00Z

From 00:28 to 01:50, about 82 minutes, the verified game-function count rose by five, to 16,916. The verified-size ledger increased by 763 bytes, to 2,492,686 bytes. These totals come from the verified index only; pending work and partial stages receive no count credit.

Measure	00:28	01:50	Change
Verified game functions	16,911	16,916	+5
Verified bytes	2,491,923	2,492,686	+763
Portable counterparts	483 / 45,417 bytes	483 / 45,417 bytes	No change

Proof workflow

The shared stock-runner queue-shadow fix has now been exercised by real 1,000-trial native runs. Fresh receipts show complete original runs and caught same-contract semantic negatives. A passed stage remains partial when its inputs, helpers, or native paths are only sampled.

Manual manifest-path and native-address mapping mistakes still appear in setup records. Briefs should require a resolved-path preflight and a known-function RVA cross-check before a build or checker is queued. Keep immutable source and library generations with their driver, worker, contract, and candidate hashes. Rerun only regressions affected by a change; broad repeated control batches and duplicate reviews are consuming time without adding evidence.

Current work samples

Portable file-read ownership lifecycle tests: 86 focused tests pass. The synchronous test backend does not expose the Running state, so that path remains unclaimed.
Independent review of a new native proof: validate mapped behavior, exact runtime provenance, all required original completions, and a meaningful same-contract negative before acceptance.
Dashboard result handling: show task-level and partial-stage evidence when no function row exists, while keeping proof acceptance separate from throughput counts.

Resource snapshot

At 01:50, the machine reported 5.1 GB free memory, 10.1 GB of commit headroom, and a 20.8 GB nonpaged kernel pool. The legacy supervisor process counter was excluded because it does not represent the current native task tree.

Hourly reviews

Time	Main finding	Decision
01:50	Manual launch and mapping mistakes consume work; accepted x86 proofs still outpace portable integration.	Use one guarded runner, pin resolved paths and mapped addresses, stop unchanged control repeats, and integrate the portable read lifecycle.

Follow-up reviews found an incorrectly mapped global fixture and a stack-formal write excluded by the return trampoline. Their proof promotions were held. Recovery brief version three requires explicit mapping checks, reuse of successful launch arguments and review of stack exclusions before acceptance.