Story

Chapter 1 — Before the first line

6 September 2026, morning

Development journal — narrative, not evidence.

The build did not open with code. It opened with a stack of documents and a rule about what to do if they disagreed with what was on disk.

The frozen inputs are meant to chain: a specification, an architecture baseline derived only from that specification, an implementation plan derived only from the baseline, an owner action schedule that pre-rules the decisions the plan leaves open, an autonomy charter that governs how far the executor may go without waiting, and a runbook that operationalises all of it into 152 packets. Each document is supposed to carry the hash of the one below it. Before any of the fourteen Wave 0 packets could start, that chain had to be checked link by link, because a plan derived from the wrong baseline, or a runbook quoting the wrong packet identifiers, would have been a bad foundation for everything after it.

The check found a real gap. The specification present on disk at the start of the day was an old draft — later work identifies it as v0.1 — while the runbook demanded the frozen v0.3.1 FINAL. The plan and baseline binaries themselves were not present on the host at all; only their expected hashes were. Rather than proceed on a partial match, or quietly substitute a summary for a missing source, the state was written down as an evidence hold: verified inputs, missing inputs, and nothing else attempted until the owner supplied the rest. This is consistent with the source-of-truth manifest's own historical record, which shows the pre-freeze specification recorded as SPEC_v0.1.md, marked non-authoritative, with a note that it "was replaced in place by v0.3.1 on 2026-09-06, hash retained, no copy exists" [commit 36e3b97].

The owner then supplied the frozen specification and one instruction: hash it, and if the hash does not match, stop and do nothing further. It matched: 135edc24a3ca…26b975 for docs/SPEC.md, version "0.3.1 FINAL / FROZEN (2026-09-05)" [commit 36e3b97]. The baseline and plan binaries arrived and matched their expected hashes too, and the owner action schedule and autonomy charter matched theirs. The source-of-truth manifest that resulted records all seven governance documents by hash, records the runbook's five constituent parts by hash under a provenance_not_in_repo section (they stay outside the repository; only their fingerprints are kept), and explicitly marks the old draft and an even older answers file as historical — present in hash only, never to be read as authority [commit 36e3b97]. The owner's next instruction was simply to wait for the goal prompt before doing anything else, which is the shape the whole day would keep: the owner sets a rule, the executor checks the world against it, and the transition between the two gets written down before it is acted on.

With the goal prompt given, packet W0-01 — freeze normative inputs — ran and passed on the first attempt: six of six tests, evidence sealed, commit 36e3b97 [bundle ddd51fb966d8…, migrated at W0-08 into the versioned schema; see Chapter 2]. The canonical repository was created on the external drive as the autonomy charter requires, with the governance documents copied in and their hashes carried forward into the manifest above.

Ahead of W0-01, though, came a packet outside the numbered 152: PRE-00, a public website. The autonomy charter asks for a truthful public window onto the project from day one — every milestone shown grey, nothing claimed that is not backed by evidence, updating only from validated state. The design is deliberately plain: a generator (site/generate.mjs) reads two data files — the site's own content and status/milestones.json — and writes static pages; it is run twice and the outputs are compared byte for byte, because a site that cannot reproduce itself is not a site whose claims can be trusted. A checker (site/check.mjs) refuses to publish a milestone as passed unless it carries an evidence hash and a target label, and separately scans every page for anything resembling a path, a serial, an email address, or a token before it is allowed out the door.

The first publication attempt got as far as a complete, checked, screenshotted build and then stopped: the local generation passed, the reproducibility check passed, and twelve page loads under a headless browser showed zero console errors and no accessibility regressions — but the wrangler deploy --env staging command itself was refused by the coding tool's own permission classifier, twice, before any Cloudflare account was even reached [bundle d54da1b91f17]. The runbook's own rule 22/31 anticipated exactly this shape of stall: keep the built artefact, record the refusal honestly as PENDING-PUBLICATION rather than force it or quietly skip it, and let operating-system work continue regardless, because site publication must never block Wave 0. Two smaller decisions were made in the same attempt and later accepted by the owner permanently: Playwright (via playwright-core, Chrome channel) stood in for the usual browser-extension visual check, since the extension was not connected that morning, and a Workers static-assets deployment with a custom domain was used in place of the Pages product named in the charter, matching the account's existing convention for a sibling site [bundle d54da1b91f17, d54da1b91f17→5bf61d6cffdb].

Later the same day, once the owner lifted the deployment restriction, the second attempt ran the same generator output through staging and then production, compared every served byte against the local build across seven sampled paths — the homepage, status, roadmap, runtime and proofs pages, the app bundle and the vendor three.js bundle — and got an exact match on all seven, over TLS, with a strict content-security policy and no analytics or external hosts anywhere in the page set [bundle 5bf61d6cffdb]. ai.itisyou.app went live carrying Phase 0: nothing claimed as done, one milestone gate defined and coloured grey, waiting for the first real evidence to turn it green.

References: git commit 36e3b97 (freeze normative inputs, W0-01); evidence bundles ddd51fb966d8… (W0-01, migrated), d54da1b91f17… (PRE-00 attempt 1, pending publication), 5bf61d6cffdb… (PRE-00 attempt 2, PASS).

Chapter 2 — The flood, and the machinery that says no

6 September 2026

Development journal — narrative, not evidence.

The autonomy charter specifies a loud alert cadence for genuine blockers, because the owner wanted to be reliably found without being buried: ten messages two seconds apart, then sixty seconds of silence, repeating for roughly half an hour, then slowing further. The first version of the alert daemon (tools/alert_daemon.py, commit 1810640) implemented that cadence in the direction it read, but not in the direction it wrote.

At 08:57:59Z the daemon sent the first ACTION REQUIRED alert for ALERT-0001, a genuine W0-01 owner-blocked state. alerts.json had initialised the alert's first_sent_at field to an explicit null. The send path used dict.setdefault to fill in fields — a function that only fills in a key that is missing, and an existing null is not missing, so the field stayed null. The scheduler then called datetime.fromisoformat(None) to compute the next send time and raised, and the exception escaped after the message had gone out but before the daemon's state was saved to disk. Every second thereafter the daemon woke, found no record of having sent anything, and sent again. Thirty-one identical messages reached the owner's phone between 08:57:59Z and 08:58:41Z — one every 1.4 seconds — before the daemon was stopped 42 seconds after its first send [dispatch log, 31 records tagged ALERT-0001; incident report INC-0001].

The owner's response, recorded the same day, was specific rather than punitive: this was an operational bug in execution scaffolding, not a violation of any of the eight Laws, and it should be logged as an incident on that basis [INC-0001]. But the fix could not simply patch the one crash. The owner ruled a ceiling that does not depend on the daemon remembering anything at all: never more than ten sends in any rolling sixty-second window, never more than forty sends for one alert, both counted by re-reading the append-only dispatch log itself on every tick rather than trusting in-memory state — and made the two constants that encode this protected, so that raising them later requires an explicit OWNER-REVIEWED trailer rather than a routine edit [INC-0001; ADR RUL-2026-09-06-01]. The corrected daemon now writes its intent to send before it sends, reconciles history from the dispatch log rather than its own memory, and stops cold at the ceiling with the hold state still visible to the owner [commit b17d858]. An offline test suite and an eight-hour virtual-clock dry run against a sender that delivers nothing were required and produced before the daemon was allowed to run live again; the dry-run schedule is attached to the incident record and shows exactly forty sends, never more than ten in any minute [INC-0001-dryrun-8h-schedule.json]. The fix held up against a second real alert later the same day — recounted in Chapter 3 — which hit its ceiling of forty sends and stopped exactly on cadence [dispatch log, ALERT-0002].

With the incident closed, Wave 0 continued. Its fourteen packets build no part of a phone; they build the apparatus meant to refuse unsafe work before any privileged code exists, and each one earned its own evidence bundle rather than a shared assumption of correctness.

W0-02 laid out ten empty Rust crates with a tree checker that rejects any stray directory or dependency outside the declared set [commit 0267546]. W0-03, the first genuinely adversarial packet, defines the protected-path policy and a guard that inspects every commit touching it; the guard's own first version had a hole its own tests caught immediately — it read the protection policy from the commit being checked rather than from the base it was checked against, so a commit that deleted the policy would have approved itself against its own absence. It was corrected to read policy and register from the base ref, with a bootstrap rule for when the base predates any policy at all [commits 549df1b, 34f4a48, 1e18276]. W0-04 through W0-07 added private build provenance, the Binder/stable-AIDL decision proved with the real Android compiler rather than assumed (ADR-IMP-001, commit bd208f0), and the two typed records — CapabilityRequest and Decision/Meter — that carry the system's audit trail: the request schema keeps identifiers to a small closed grammar, closed enumerations, and a prompt that only ever travels as a hash, verified against twenty thousand random mutations that never produced an accepted non-canonical message [commits 0ecbfde, a38e5f2].

W0-08 defined the evidence bundle format itself and immediately put it to a harder test than any later packet would face: the nine bundles written before the format existed had to be migrated and re-validated under the new, stricter validator, and one of them — the PRE-00 site preflight — needed its checks rewritten as an explicit test list before it would pass [commits b0f2cf0, a6220ed]. W0-09 and W0-10 built the fakes the rest of the project tests against — a deterministic registrar, policy table and hash-chained audit log, and a scripted model provider that can be told to behave, misbehave, lie, stall, disappear, or rate-limit on command, all offline. W0-11 built the Law registry: negative tests for every one of the Laws, pinned by hash, with a guard that watches for removal, renaming, skipping, or any quiet softening — reads confirm the guard catches #[ignore], removed tests, renamed tests, and uncovered Laws, and that the protected-diff check will not auto-approve any of them [commit 28b24af, law registry hash 01b30823cc47…]. W0-12 added ten synthetic prompt-injection attempts mapped to the exact denial each should provoke, and W0-13 checked that every subsystem in the No-AI fallback matrix is either tested under five model-failure modes now or explicitly named for the packet that will make it so.

W0-14 turned all of it into one pipeline — static checks, build, unit and Law tests, an honestly-absent device-evidence stage, and a bundle gate — and proved it meant what it said: a branch carrying one Law test marked #[ignore], pushed through as a negative control, was caught on two independent fronts in the same run, the registry-hash pin and the protected-diff weakening check, and the branch was discarded rather than merged [commit dad05f1, f43b964; bundle f224d530fca9…]. With the fourteenth bundle sealed — 171 of 171 tests passing across the wave, zero skipped — M0 was generated deterministically from the validated evidence alone, and the public site turned its first milestone gate green [commit ea02b5a; bundle f224d530fca9…].

References: incident report INC-0001-alert-flood.md and its dry-run schedule; dispatch log entries for ALERT-0001/ALERT-0002; ADR RUL-2026-09-06-01; git commits 1810640, b17d858, 0267546, 549df1b, 34f4a48, 1e18276, bd208f0, 0ecbfde, a38e5f2, b0f2cf0, a6220ed, 28b24af, dad05f1, f43b964, ea02b5a; evidence bundle f224d530fca9… (W0-14 / M0 gate, 171/171 tests, law registry 01b30823cc47…).

Chapter 3 — The phone

6 September 2026

Development journal — narrative, not evidence.

Wave 1 opens with a question the plan will not let anyone answer from memory: which exact source tree boots this phone. The owner's schedule is explicit that only a boot log taken from the physical device — not a document, not an assumption — qualifies a source set as proven.

The device is a Samsung Galaxy S20 FE (codename r8q), and LineageOS maintains it under that codename with a published branch, kernel tree and firmware precondition. Its build service also publishes, for every nightly, the exact manifest used to build it — every one of roughly 1,169 sub-projects pinned to a commit — which is the fastest honest way to obtain a genuine boot log for a known revision set before committing days to a from-source build. The flashing method itself was a discovery of its own kind: the LineageOS wiki's current instructions point to samloader-rs, a LineageOS-affiliated tool, rather than the Heimdall or Odin path the runbook had assumed, and it worked on the laptop with the vendor driver already present and no administrator elevation — removing a physical touchpoint the plan had budgeted for [ADR DEC-2026-09-06-02].

The wave's first real mistake followed almost immediately. A read-only probe of the device's partition table was issued with samloader's --no-reboot flag, on the reasoning that a read should leave the device alone. This device does not support a second Odin-protocol handshake inside the same download-mode session: the next command failed with an unexpected handshake response, adb had nothing to talk to, and the phone sat in Download mode, unusable by any tool on the laptop [state journal, seq 54–55, kind: device-hold]. The alert daemon — now running under its corrected ceiling from Chapter 2 — raised ALERT-0002 and, this time, stopped itself cleanly at forty sends on the proper ten-per-minute cadence rather than flooding [dispatch log, 40 records tagged ALERT-0002, 2026-09-06T10:59:15Z–11:03:53Z]. The device came back only when the owner physically held Volume Down and Power for about eight seconds; the runbook gained a line the same day saying never to issue --no-reboot on this device again, and print-pit — which reboots by design — became the standing read-only probe instead [seq 55–56].

The install itself, once the owner returned, ran as a short duet rather than a fully unattended operation. The agent flashed the recovery and vbmeta images, confirmed the device's stock fingerprint first, then pushed a signed 1.0 GB-class Lineage 23.2 nightly package over USB sideload; the owner formatted the data partition, rebooted, skipped the setup wizard, and re-enabled USB debugging — steps that need a hand on the glass and cannot be scripted around [state journal, seq 58–61]. Minutes later adb reported sys.boot_completed=1 against a Lineage 23.2 (2026-09-05 nightly) fingerprint with verified-boot state orange, and W1-01 passed on physical-device evidence: the first packet in the register accepted against something other than a host [seq 62; commit 5e0fa31; bundle 293c007e5254…, target device].

The next seven pushes to main all came back red. The install tool's serial-identification helper had shipped with a literal fallback device serial as its default value — meant only to save typing during the session — and the CI pipeline's own secrets scanner is written to catch exactly that shape of string in any tracked file. Once the pattern landed in a tracked file, every subsequent push failed the same STATIC gate regardless of what else that push changed, because the gate does not care what a commit is about; it fails the whole pipeline until the offending line is gone. Seven consecutive runs on main — spanning about an hour, from the W1-01 acceptance itself through unrelated story and job-reconciliation commits to a sync-ceiling change — came back failure before the fix landed: the serial is now read from an environment variable or a private, untracked state file, and the tool raises rather than falls back to anything printable if neither is set [CI runs 34030749492 through 34034071080, all failure; fix at commit 100eb23, run 34035090130, success]. Whatever number this chapter's brief expected here, the traceable count from the run history is seven, not three; it is recorded as measured, not adjusted to fit.

Meanwhile, on the external drive, the pinned manifest from the official build had begun a full repository sync inside the Linux build environment, launched from a Windows scheduled task so it does not depend on any agent's session staying alive [seq 57]. An interim 250 GB watchdog ceiling, raised by the executor without a ruling behind it, was explicitly withdrawn once the owner reviewed it [seq 69, 73]. The ruling that replaced it capped the checked-out tree (excluding the sync's own .repo metadata) at 90 GB and left the question of decimal or binary gigabytes open until it mattered [ADR RUL-2026-09-06-04]. It mattered immediately: the finished sync — 1,171 projects checked out, zero missing, zero mismatched against the pinned revisions [seq 78, inventory hash b5f1149ce58c…] — measured at 93,328,020,422 bytes, which is 93.33 GB by the decimal reading and 86.92 GiB by the binary one: over the cap one way, under it the other. The agent did not pick the reading that let it proceed; it held the build, kept a second sync running for reproducibility (which adds nothing, since every project was already at its pinned revision), and sent the owner a top-20-by-size report to rule on [seq 79]. The owner ruled the binary reading: 86.92 GiB is under a 90 GB cap read as GiB, and W1-03's detached build was started the same hour [ADR RUL-2026-09-06-07, seq 80–81].

Two more decisions landed the same afternoon. The product was named — ITISYOU OS, short form AIOS, applied to the site, the milestone files and the Telegram labels — with one loose end recorded honestly rather than quietly dropped: the owner referred to an updated AUTONOMY.md with a new hash that no copy on either drive actually carries yet, so the manifest refresh for that document stays held until the real file turns up [ADR RUL-2026-09-06-05; commit 8cf0572]. And because nothing in Wave 2 or beyond can be accepted until the Wave 1 device packets clear, the remaining budget went into preparation rather than idling: seven branches, each its own worktree, each forbidden from touching another's protected paths, drafting the flash-and-recovery runbook with a stock-firmware rollback path, a battery of offline device probes, the Wave 2 authority core (registrar, audit chain, epoch counter, key-handle table, ten add-only Law negatives), the evidence-tooling re-verification runner, a network-enforcement workbench, the L2.5 inference-runtime seam with its call meter, and an Agent City skeleton [seq 70–72, 75–76; branches prep/w1-04-runbook (4d4999b), prep/w1-probes, prep/w2-authority-core (b9303c2), prep/evidence-tooling (cdb01c0), prep/w2-a77-harness (3e0a3f5), prep/w25-inference-core (88d0ff3), prep/w4-agent-city (c577b3d)]. Every file out of these branches carries the same header: prepared, not accepted. Each will still be reviewed on its own evidence when its packet's turn comes.

References: git commits 5e0fa31, 100eb23, 8cf0572, 4d4999b, b9303c2, cdb01c0, 3e0a3f5, 88d0ff3, c577b3d; evidence bundle 293c007e5254… (W1-01, device target); GitHub Actions runs 34030749492–34034071080 (failure) and 34035090130 (success); state journal seq 54–83; dispatch log entries for ALERT-0002; ADRs RUL-2026-09-06-04, -05, -07, decision DEC-2026-09-06-02.

Chapter 4 — The build fights the disk, and the core fails review

6 September 2026, afternoon

Development journal — narrative, not evidence.

By mid-afternoon the day had split into three simultaneous problems: get a from-source build running at all, find out whether the Wave 2 security core being prepared in parallel was actually sound, and keep a shared external drive from choking every agent working on it at once. None of the three produced an accepted packet this chapter — everything below is PREPARED, held, or ruled, not PASS — and that distinction is itself part of the story.

The disk-cap question from the sync (Chapter 3) reached its owner exactly once more before it was settled for good. The checked-out tree, excluding the sync's own metadata, measured 93,328,020,422 bytes: 93.33 GB by the decimal reading, 86.92 GiB by the binary one, against a 90 GB cap that did not yet say which GB it meant. The build stayed held rather than start on a convenient reading [state journal seq 78–79]. The owner ruled binary: 86.92 GiB is under a 90 GB cap read as GiB, and raised the parallel-agent ceiling to eight in the same ruling [ADR RUL-2026-09-06-07; seq 81].

The detached build itself needed three attempts to leave the gate. The launcher calls into the tree's own envsetup.sh, and the first two launches exited immediately: the script reads an environment variable the launcher's strict shell mode (set -u) treats as fatal when unset, and it is unset until envsetup.sh itself sets it. The fix was to relax strict mode around that one call rather than around the whole script, and the third launch is the one that actually started compiling [state journal seq 90]. It has not finished; as of this chapter it is still building the host-side Go toolchain the rest of Android's build system depends on, not Android itself [build log checkpoints].

That third launch shared the same physical drive with a second full repository sync, running again purely to prove the first sync was reproducible. It never got to prove it. The second sync reached its "finalizing" stage and then stalled behind three concurrent directory-size scans competing for the same disk; before its receipt could be written, the WSL virtual machine was restarted to apply a memory-configuration ruling, and the restart ended the sync mid-flight. The reproducibility test this was meant to satisfy is still open, deferred until after the build finishes so the tree is not touched twice at once [state journal seq 91].

The contention showed up directly in the build's own checkpoints. For six checks in a row, roughly every five minutes between 15:03 and 15:39, the build's output directory barely grew — from about 104.0 to 104.02 megabytes — while system load sat near 24 to 25 on a twelve-processor host; one checkpoint a few minutes later recorded a load of just over 102. Eight parallel Rust builds from the Wave 2 preparation agents were writing to the same HDD the AOSP build was reading from, and none of them were winning [build log checkpoints]. The owner's fix was structural rather than a temporary throttle: Rust build output no longer touches the shared drive at all. Compilation output for every Wave 2 preparation branch moves to a dedicated location on the host's other drive, run at reduced process priority, with the agent ceiling cut to three until that redirection exists and restored to eight once it does — and the AOSP build keeps I/O priority throughout [ADR RUL-2026-09-06-14]. The next two checkpoints show the difference: output jumped from about 150 megabytes to 1.26 gigabytes between 15:49 and 16:01, and load eased to the high teens [build log checkpoints].

The same afternoon, a dedicated review branch (prep/w2-review, commit 62e08ba) was pointed at everything the Wave 2 authority-core preparation had produced, and it did not pass. Four blockers, fifteen major findings, ten minor and seven notes — and, more pointedly, three mutations deliberately planted in the code (a free-text trait parameter, a rank-based authorisation branch, an inverted admin-tier fold) all survived the project's own protected Law test suite untouched. The protection boundary and the actual coverage boundary are not the same thing yet. Seven of the branch's own candidate decisions were marked disputed rather than accepted on the reviewer's say-so [ADR w2-review entry; seq 95]. The response was dispatched inside the hour rather than left for later: the key-handle blocker went to its own branch and was closed the same afternoon — private fields, no Copy/Clone, a sealed constructor, four compile-failure proofs that the old bypasses no longer compile [commit 3792375] — and one of the two Tier-3 authorisation blockers landed on the token-format branch alongside it [commit 39d5b1b]. The policy-encoding fix and two more of the l2 blockers were still queued, not landed, as this chapter was written.

Two loose ends from earlier chapters closed. The owner's promised updated AUTONOMY.md, held since the naming ruling, never actually arrived — the only change in it had been the naming decision itself, already applied by message — so the file's hash stays exactly what it was and the hold was simply released rather than chased further [ADR RUL-2026-09-06-12]. And the network-enforcement branch's open question — whether a hybrid of eBPF identity matching and iptables destination rules counts as an acceptable "selected mechanism" — was ruled yes, under three conditions, and filed as a formal decision; the owner's own requested number for it collided with a number the Plan had already reserved for something else, so the conflict was written down rather than silently resolved [ADR RUL-2026-09-06-13, docs/adr/ADR-IMP-010-network-enforcement-mechanism.md].

Underneath all of it, a migration plan waits on hardware that has not arrived yet. A drive is due the next day, and the instruction was to prepare, not to wait: a dry-run-only tool now exists that can export the whole build environment, move it, verify document and evidence hashes before and after, and re-point every path that depends on the old location — with the old drive's copy renamed rather than deleted, so a failed migration is recoverable [ADR RUL-2026-09-06-10; prep/ssd-migration]. It stays unexecuted by rule until the owner confirms the drive is physically connected.

References: state journal seq 78–101; git commits 3792375, 39d5b1b, 62e08ba; build log checkpoints (2026-09-06, 15:03–16:06); ADRs RUL-2026-09-06-07, -10, -12, -13, -14; docs/adr/ADR-IMP-010-network-enforcement-mechanism.md.