Chronological record of engineering changes, decisions and failures, mirrored from
docs/DEVELOPMENT_STORY.md. Releases — tags, commits, CI runs and
downloads — are on the releases page;
this ledger is the engineering story between them. Failures are logged with their root causes, not hidden.
DATE
2026-09-14 · 10:00
IMPLEMENTED
ITISYOU OS V1.0 — released, locally verified (GitHub CI pending)
Session 5 — V1.0
What happened
V1.0 declared against the acceptance criteria written in advance (docs/V1_ACCEPTANCE.md), and published as reproducible, checksummed UEFI and BIOS boot images for virtual machines — the V0.11 AI-native layer folded in (it was never tagged on its own). V1.0 itself is reliability and security: IPC authority scoped to the channels a grant names (ADR-0025); a seeded Ring 3 syscall fuzzer (300,000 random syscalls across no-capabilities, the console default set, and the agent set — no crash or hang) that found a wait(0) that slept forever; a decoder mutation fuzzer over 48 untrusted-byte parsers (a million inputs each) that found real overflow panics; long-use leak accounting that found a page-table frame leaked on every store operation since V0.4; contained CPU exceptions with the user FPU off; and a whole-attack-surface adversarial review.
Detail / root cause
The review: twelve area reviewers over the whole kernel attack surface, every finding checked by an independent refuter, plus a completeness critic for the cross-cutting CPU state no area owned. 37 findings survived — 3 high, 15 medium, 19 low. All three highs are fixed: unhandled CPU exceptions a Ring 3 program could turn into a kernel panic (one div-by-zero from a no-capabilities program); a package launched under another app’s name, escaping the signing key’s scope; and an IPv4 ICMP responder a remote ping flood could recurse into the syscall stack’s guard page. Eighteen findings fixed in all, each with a QEMU leg and a mutation control that shows the check failing when reverted; the remaining seven mediums are documented, accepted, fail-closed availability limits a capability holder or a hostile disk can impose on a single-user VM. VERIFICATION: GitHub CI could not run — the repository is private with no Actions minutes — so this release is verified by the full local gate (74 QEMU legs, host tests, clippy, secret scan), two full-clean-build bit-for-bit reproducibility on the build host, and UEFI+BIOS boot-tests of the exact release bytes; it carries no CI run id, and the CI-dependent acceptance rows (V1-REL-001/002, V1-REP-004) are recorded BLOCKED on the CI window, none security-relevant. Built on Windows 11 with the pinned nightly-2026-08-01; a Linux/CI build produces different bytes (host-specific content in panic locations), so the CI-built SHA-256 will differ and be stamped when the window opens.
The V0.11 adversarial review: two ways v0.10.0 still let a program forge kernel evidence
Session 5 — V0.11
What happened
Before the release, six independent reviewers read everything V0.11 changed, each trying to break it, and every finding went to a second reviewer told to refute it. Nine findings survived. Two are defects in v0.10.0: a program could still print a genuine kernel marker line by splitting the prefix across the kernel’s 256-byte output chunks — the rewrite looked at one chunk at a time (OUT11-002) — and ps printed the path string a program passed to spawn, so a line break and a marker in a component that .. later removed made the kernel print a forged line itself (SEC11-002). The kernel now keeps a tail that could start a marker for the next chunk and records the canonical path of the file it loaded. Both are disclosed for v0.10.0, which stays as released.
Detail / root cause
The rest were in the new code or its evidence: a rollback that killed whatever pid /sbin/init named (now only a live instance of that service — shown with a deliberately compromised init, which could otherwise have had the kernel kill tickd); a retry reported as never started although init had fetched it; proposals that expired only when the operator looked; bidirectional overrides in names the kernel echoes; a crafted multi-megabyte audit trail that panicked boot recovery (AUDIT11-003); a documented claim that the next save heals a TAMPERED trail — it does not, and now a standing leg proves it stays reported until the operator removes it; and two tests weaker than their claims, now tied line to line with a new ordered-require option in the harness and a kernel selftest. Each fix has a QEMU leg or selftest and a control that shows the check can fail.
EVIDENCE
line-atomic-bios · 250 dots + [ITISYOU:SVC] spoofed-split → [RING3-U:SVC] spoofed-split · ps path=/bin/spin-forever · control: the tail not kept → [ITISYOU:SVC] spoofed-split on the wire · ai-retry-bios · rollback_kill_refused … reason=not_an_instance under a compromised init · audit-tamper-save trail_checked status=TAMPERED reason=chain · ai-propose-bios --require-order · requirements OUT11-002, SEC11-002, AUDIT11-003
DATE
2026-09-14 · 01:30
IN DEVELOPMENT
V0.11: an agent with intelligence and no authority — verified, and later shipped in v1.0.0
Session 5 — V0.11
What happened
Every V0.11 requirement is implemented and verified on the development branch, each shown against a negative control: a read-only view of the kernel’s own tables, served only to a process the console grants it (sys_view, syscall 42); a small diagnostic model trained at build time and pinned by digest; inferd, a Ring 3 service that runs it; one runbook per condition; a diagnostic agent that can file proposals (syscall 43) and act on nothing; kernel checks on every proposal; approval only at the console; and two actions — resume-scheduler, and retry-service through a kernel→init mailbox (syscall 44) — each executed in kernel code, verified afterwards and rolled back if the check fails. Process output can no longer drive the operator’s terminal (OUT11-001). At this point v0.11.0 had not been tagged; it was later folded into v1.0.0 rather than released on its own.
Detail / root cause
What is weak is written down beside it. The training data is synthetic, generated from hand-written ranges, and the held-out accuracy equals a one-rule baseline: the scenarios define each condition by essentially one feature, so the number shows the designed cases are separable, not that the model diagnoses a real machine. It knows three conditions and can propose two actions. IPC carries no sender identity, so inferd’s answers are claims: a malicious IPC holder can mislead a diagnosis, but the kernel recomputes the condition from the view it served and refuses a mismatch, so it cannot get an unjustified proposal filed. Proposals live only in memory. Building the retry path found two ordering bugs in the new code — posting the rollback’s stop erased the retry’s acknowledgement, and the watch was armed only after the command was posted — both fixed before the step was claimed.
EVIDENCE
ai-model-bios · model sha256=e0fc6642…2d12 bytes=276 initramfs_match=true · held-out 10000 bp = one-rule baseline 10000 bp (synthetic) · ai-diagnose-bios · conditions=service_failed,scheduler_paused · ai-propose-bios · ten adversarial proposals, each refused for its own reason · ai-act-bios · action_verified id=2 result=pass · ai-retry-bios · action_rolled_back id=2 … stop_ack=true … row=failed restarts=1 · requirements MODEL11-001, VIEW11-001, INFER11-001, KB11-001, AGENT11-001, PROP11-001, ACT11-001, ACT11-002, OUT11-001
DATE
2026-09-13 · 23:40
IMPLEMENTED
Three audit-trail defects since v0.8.0 — found reviewing V0.11, fixed on the V0.11 branch
Session 5 — V0.11
What happened
A saved audit trail reads as TAMPERED once any boot after the first has saved it (AUDIT11-001); a program holding fs_write can rewrite the trail or delete a package’s commit marker (SEC11-001); and a file name with a line break in it makes the kernel print a line that reads as a kernel marker (AUDIT11-002). v0.10.0 and every release since v0.8.0 have all three; the limitations and security pages now say so.
Detail / root cause
V0.11 puts a proposing agent on top of the audit trail, so its design was reviewed first, including what the trail itself holds up to. On the published v0.10.0 image a trail saved in boot 1 verified in boot 2, and the same trail saved again by boot 2 was TAMPERED in boot 3 — the save stored only the current boot’s 64-record ring under a head covering every record ever made. The old legs had only ever saved once, in the first boot. The fix stores the newest 128 records with the head the first of them extends, keeps recovered records, makes audit verify read-only, makes the trail and the package store kernel-owned, and escapes every kernel echo of program- or disk-chosen text; each fix has a control showing the failure with it switched off. v0.10.0 stays as released.
The release commit c936bc7 names version 0.10.0, and its CI run 34782271250 — the release gate — is green: the full QEMU matrix (40 QEMU steps on Linux), the reproducible-image job, the website and the secret scan. The UEFI and BIOS boot images are built by that run and published with their SHA-256 on /download; v0.9.0 and v0.8.1 stay downloadable.
Detail / root cause
V0.10 was built one audited step at a time — counted locks, line-atomic output and flag hygiene first, then the scheduling core built and measured but switched off, then always-on slices, the process tree, the supervisor report, /sbin/init, the Ring 3 shell and desktop focus — each step gated by the whole local matrix and each claim shown against a negative control. The repository was made public for the CI run and private again afterwards, as for v0.9.0.
EVIDENCE
release commit c936bc7 · workspace version 0.10.0 · CI run 34782271250 green (ubuntu-24.04) — builds and boot-tests the published images · SHA-256 on /download
DATE
2026-09-13 · 20:05
IMPLEMENTED
A denial of service in every release so far — found, shown and fixed on the V0.10 branch
Session 4 — V0.10
What happened
The kernel’s user-copy helper checked that each page of a program’s buffer was mapped, never that the program could write it. A program that points cap_list — which needs no capability — at its own code makes the kernel write there in Ring 0, and the resulting page fault panics the kernel. v0.9.0 has the same code; the limitations and security pages now say so.
Detail / root cause
Found while writing V0.10’s wait_nohang, which returns a status into a buffer the program names. A small probe showed the panic on the V0.10 kernel before the fix (a write-protect page fault in Ring 0). The fix walks all four levels of the page tables and requires the user bit at every level, and the writable bit at every level for a kernel write; the same probe then gets ERR_FAULT, and the leg that shows it joins the V0.10 gate. v0.9.0 stays as released — a release is never rebuilt in place.
v0.9.0: V0.9 — Transport, Interrupt Cutover & Trust is released
Session 4 — V0.9 release
What happened
The release commit f06673e names version 0.9.0 in the workspace, the status metadata and the shell legs’ version marker, and its CI run 34760629701 — the release gate — is green: the full QEMU matrix, the reproducible-image job, the website and the secret scan. The UEFI and BIOS boot images are built by that run on Linux and published with their SHA-256 on /download; v0.8.1 stays downloadable as the previous release.
Detail / root cause
Every V0.9 feature had already passed the local gate at each exact commit — 36/36 QEMU legs and 366 host tests on the final candidate, 08d836c — but a release waits for CI on its own commit and ships the bytes CI built, never a local build. The repository was made public temporarily so that CI could run on GitHub-hosted runners. As with v0.8.1, the tag goes on the status-stamp commit that records the run. V0.10 work — program arguments, filesystem space reclamation, guard pages for kernel task stacks — exists only on a separate branch and is not in these images.
EVIDENCE
release commit f06673e · workspace version 0.9.0 · CI run 34760629701 green (ubuntu-24.04) — builds and boot-tests the published images · SHA-256 on /download
DATE
2026-09-13 · 13:12
IMPLEMENTED
V0.9: TCP, IPv6, a signing-key hierarchy and kernel stack guards — verified locally
Session 4 — V0.9
What happened
IPv6 foundations — link-local and SLAAC addresses, neighbour discovery, ICMPv6 echo in both directions — and TCP from Ring 3, verified against the host operating system’s own TCP stack: a program connects and streams, two deliberately dropped segments are recovered by retransmission, and a program can also listen. Package trust moved to a key hierarchy: an offline root, certificates limited by package-name scope and a release-epoch window, and a root-signed revocation list. The kernel’s Ring 3 interrupt (RSP0) and double-fault stacks now sit on unmapped guard pages (the separate syscall stack does not yet). With the I/O APIC cutover, ACPI power-off, DHCP and audit anchoring from earlier in the session, every V0.9 feature was verified locally, ahead of the release.
Detail / root cause
The first TCP run failed somewhere TCP never goes: a capability handle that had been valid a moment earlier was refused as invalid. An 8 KB connection block, copied by value several times in the unoptimized build, overran the 32 KB syscall stack — which had no guard page — and wrote over the capability table below it. Connections are now built in place in static slots, and the RSP0 and double-fault stacks have guard pages, so an overflow of either now stops the machine with a double fault naming the stack; the syscall stack the bug actually overflowed is a third static stack and was not guarded in v0.9.0 — a gap found after the release (heap-allocated task stacks still have none either). The same work exposed a V0.8 leak: the console’s foreground run path never released a program’s UDP sockets, so a port stayed bound for the rest of the boot; both exit paths now release sockets and connections. The key hierarchy settled the open question of moving the signing key out of the tree without a CI secret that would have made the image unreproducible: the fixture key stays published, but is trusted only through a root certificate scoped to hello-* names. Until the release CI run, the full local gate at each exact commit was the verification of record.
Audit: the V0.8 engineering reproduces; the V0.8 release did not agree with itself
Session 4 — audit + V0.8.1
What happened
An independent audit re-ran the whole gate on the v0.8.0 commit before trusting any document: 24/24 QEMU legs, selftest 113/0 on BIOS and UEFI, 292 host tests — the engineering held. The release around it did not: the tagged kernel reported itself as 0.7.0-dev, two requirement rows used a state ("NOT DONE") the plan does not allow, and the live site still said "no network stack exists in V0.1".
Detail / root cause
The version drift had been tested in: the shell-test legs asserted the same stale "0.7.0-dev" string the kernel printed, so the check that should have caught it pinned it instead. The fix is v0.8.1 plus a gate that compares the Cargo version, the status metadata and the requirement states on every build — run against the v0.8.0 tree it names exactly the three defects that shipped. The site is now verified in a real headless Chromium driven over the DevTools protocol rather than over HTTP alone, and the roadmap after V0.8 was re-derived from dependencies: a userspace-system milestone now precedes the AI layer, which depends on it.
EVIDENCE
check-consistency.mjs on the v0.8.0 tree: version "0.8.0" != "0.7.0-dev"; NET08-003/NET08-004 state "NOT DONE" outside the vocabulary
An e1000 driver with polled RX/TX descriptor rings, ARP, IPv4, ICMP echo (answered as well as sent), UDP with port-scoped Ring 3 sockets, and DNS. Ed25519 signatures for packages, verified against a compiled-in trust root. Capability-scoped userspace filesystem writes with a crash-atomic overwrite. Local APIC, I/O APIC and MSI-X with real interrupt-delivery evidence. xHCI enumeration and HID input. A hash-chained audit trail that survives reboots. SMEP, SMAP and UMIP.
Detail / root cause
Three bugs came out of RUNNING the network stack rather than reading it, and each is a class worth naming. A `match` on a `Mutex` guard kept the lock alive across the arm that re-locks to send an ARP request — a self-deadlock on a spin lock with interrupts off, which is a dead machine. Bounded waits were built on the timer tick, which does not advance inside a syscall because SFMASK has cleared IF, so a 1-second timeout burned a 400-million-spin backstop instead; the fix was a TSC calibrated against the PIT, plus making the datagram syscalls non-blocking so waiting happens on the caller’s own scheduling slice. And a tight userspace retry loop emitted one ARP broadcast per attempt — 879 in a single run.
The network is verified against an independent implementation, not against itself
Session 3 — V0.8
What happened
The test harness brings its own Ethernet peer over a QEMU `dgram` netdev: it answers ARP, ICMP echo, a UDP echo service and DNS, and it is the entire network the guest sees — no slirp, no host resolver, nothing outside the machine.
Detail / root cause
The peer is deliberately a separate byte-level implementation rather than a second use of kernel_core::net. A test where both ends share a checksum routine proves the two agree, not that either is right. It also probes the guest — an ARP request and a ping — because a stack that only ever initiates is not a host on a network, and then sends five frames a correct stack must refuse: a corrupt IP checksum, a ping addressed elsewhere but delivered to our MAC, UDP to an unbound port, an 802.1Q tag, and an ARP whose hardware type contradicts its address lengths. The assertion is that the guest counts them as refused AND answers none of them, detected by content rather than by timing.
Ed25519 written out, with every curve constant derived rather than transcribed
Session 3 — V0.8
What happened
Package authenticity needed a signature scheme. It is implemented in kernel-core alongside SHA-256 and SHA-512 rather than pulled in as a dependency, and validated against the RFC 8032 test vectors — public keys, signatures and verification — not only against itself.
Detail / root cause
The curve constants (d = -121665/121666, sqrt(-1) = 2^((p-1)/4), the base point from y = 4/5) are computed from small integers at use time. A mistyped 32-byte constant produces a working implementation of a DIFFERENT curve: self-consistent, passing every round-trip test, and unable to verify a single real signature. Deriving them removes the possibility. Integrity and authenticity stay separate steps so that a corrupt download, a package from a stranger and a forged signature are three distinguishable refusals rather than one.
SMAP inverts the default, so the harness had to be told to allow it
Session 3 — V0.8
What happened
SMEP, SMAP and UMIP are enabled from CPUID and reported from CR4. SMAP makes kernel access to user pages forbidden by default; the three places that legitimately need it bracket their access with a guard whose Drop closes the window on every path.
Detail / root cause
QEMU’s default qemu64 model advertises none of the three, so the hardening would have been enabled into a void and silently done nothing. The runner now requests +smep,+smap,+umip, which means every leg in the matrix runs with supervisor-mode protection on — a far stronger statement than one leg that enables it, because the other 23 passing is the evidence that the kernel’s own legitimate access to user memory still works. The harness also gained a --forbid assertion: a refusal prints no line of its own, so the only way to state one is that the marker printed on success never appeared.
EVIDENCE
harden-bios · cpu_protection smep=true smap=true umip=true · sgdt from Ring 3 is a contained #GP · stack guard exactly 16 pages down
DATE
2026-09-02 · 02:30
IN DEVELOPMENT
Kernel skeleton and test harness authored
Session 1 — Foundation
What happened
Workspace laid down: kernel/ (lib + interactive and selftest binaries), crates/kernel-core (host-testable stage/marker contract), tools/image-builder (pure-Rust BIOS/UEFI images + SHA-256 manifest), tools/qemu-runner (deterministic boot assertion harness with JSON evidence).
Detail / root cause
First build failed: this nightly’s cargo rejects `cargo-features = ["bindeps"]` in the manifest. Root cause: artifact dependencies must now be enabled via `[unstable] bindeps = true` in .cargo/config.toml. Fixed there; `per-package-target` remains a manifest feature. Rebuild launched.
EVIDENCE
error: unknown Cargo.toml feature `bindeps` — resolved in .cargo/config.toml
DATE
2026-09-02 · 02:20
IN DEVELOPMENT
Governance intake and discovery
Session 1 — Foundation
What happened
Read AGENT_OPERATING_RULES.md and the end-to-end implementation plan; both adopted as binding. Requirement traceability matrix created (docs/REQUIREMENTS.md). Stitch design export preserved unchanged in design/ and extracted as the visual source of truth.
Detail / root cause
Environment discovery and storage rules applied: Rust nightly-2026-09-01 + x86_64-unknown-none toolchain installed to E:\toolchains, QEMU 11.1.0 extracted to E:\tools\qemu without elevation, scratch routed to G:\claude-tmp. GitHub authenticated; repository to be created private.