Open Cube OS 3.0.0 WP-04 - the L1 migration (development milestone)

Open Cube OS 3.0.0 WP-04 - the L1 migration (development milestone)

Every command of the v2.2.0 baseline now runs from ring 3: one
command = one app = one folder (src/L1/<name>/main.c), discovered
mechanically by tools/gen_userprogs.py into the embedded program
registry. The L0 side is a pure service kernel - drivers, services and
the numbered L1SVC ABI; no user-plane code remains in ring 0.

This is a development milestone on the way to 3.0.0, not the 3.0.0
release (the formal release, its OTA chain and version bump land in
the next work package).

Where the 251 v2.2.0 commands went

Batch	Content	Count
G3-G5	140 SVC wrappers + 31 file tools + the nano/vi editor shells	171
G6	health / dmesg / logcat / logctl / watchdog	5
G7	the l1 family: run, l1test, ldd, help (+ help_*_test invariants)	7
G8	vitals 5 (mem/frag/heap/sched/syncstat) + crash 3	8
G9	18 ring-0 self-tests (diag ops 9-26)	18
G10	13 chipset diagnostics (diag ops 27-39)	13
G11a	ssh + sshd (the RFC 4251-4254 engine pair, revived verbatim)	2
G11b	ime + ime-test (pinyin engine, DISP ops 11/12 revived)	2
G11c	the nine full-screen TUI pages (category "tui")	9
stays in ush	shell-state builtins (cd/export/alias/...) - a subprocess cannot mutate the shell's own process state	9
subcommands	health export / health watch live inside the health app	2

Total migrated: 235 of 251; the remainder are the documented
shell-state / subcommand classes above (plus one audit false-positive
and the dual-homed counting caliber).

Parity proof

A 34-command battery ran against a real v2.2.0 build (same toolchain)
side by side in QEMU - structure is line-for-line identical; only
volatile state (tick counts, free bytes, heap block counts) and
version strings differ. Per-batch evidence (verbatim transcripts,
interactive sessions, VNC page screenshots, SSH e2e with paramiko)
lives under evidence/3_0_0_wp04_*.

New ABI surface (append-only)

• category 19 "diag" - 39 operations (vitals, crash, self-tests, chipset)
• category 20 "tui" - 9 operations (the desktop + classic pages)
• net ops 13/14 (ssh/sshd), display ops 11/12 (ime/ime-test, back on their v2.2.0 numbers)

Live bugs found and fixed along the way: F6 (IRQ-context interrupt
enablement - three reversed IFs, a #DF under pmmrace), F7 (stale RSDP
pointer into loader memory - an ACPI #PF), F8 (a health format that
had drifted from its v2.2.0 source).

Downloads

Asset	Size	SHA256
opencube-3.0.0-WP-04.iso	12,351,488 B	b2697ab8617ed21ec20a541f5f658d62eb6a095a40ca69bf3e7796b96aa153c3
opencube-3.0.0-WP-04.elf	2,077,472 B	31c7c8844ae33d91a4e8dba5653aeb21024f4a626244eddcbab984b7c75125bf

The ISO is hybrid BIOS+UEFI (dual El Torito) and boots straight into
the ring-3 ush> shell on both SeaBIOS and OVMF. The ELF is the
kernel image for direct -kernel boot.

Verified (all gates real runs)

Gate	Result
Compile 0 errors 0 warnings (-Wall -Wextra -Werror)	PASS, two clean builds
Determinism: two clean builds byte-identical	PASS (elf 31c7c884, iso b2697ab8)
BIOS boot to ring-3 ush> (auto-entry)	PASS
UEFI (OVMF) boot to ring-3 ush>	PASS
tui-test	93/93 all green
CI on the release commit and the tagged commit	both success

Version 3.0.0-WP04, build 348 - the build id is the commit count
plus 21 and stays monotonic above the published 316 (2.2.0); the
kernel reports it via the crash header and the sysinfo pages.

---

fix1 update (3.0.0-WP04-fix1)

The WP-04 fix batch: all 11 known bugs fixed (each root-caused,
live-verified before/after on QEMU serial), a four-quadrant
source-tree audit (src/L1 274 programs, src/L0, docs, website) with
every finding fixed on the spot, and an ISO determinism repair found
during the re-check.

The 11 known bugs

#	Fix
1	exit now prints guidance (the shell is the surface; no blank halt)
2	tui serial clean at byte level (4000 SGR pairs, 0 lone ESC, strict UTF-8 decode)
3	serial CSI pre-decode (arrows/Home/End/Del/Ins/PgUp/PgDn; SGR mouse passthrough; physical Esc -> OC_KEY_ESC_KEY)
4	launcher exit message honest (no "recovery shell" claim)
5	help -a / help -w restored: three DISTINCT modes via L1SVC op1 arg
6	help registry-driven - the ~100-line hardcoded list is gone; the registry carries per-program wp tags
7	line editor: prompt-aware redraw + pad-clear to previous length + CJK bias bytes accepted (six symptoms, 18/18 live battery)
8	banner version fetched from the uname service (3.0.0-WP04)
9	OCIRE keyboard maps realigned (1->1, =->=, Tab live; before: 1->2, =->backspace, Tab dead)
10	VGA scroll half-copy fixed (1920 -> 3840 bytes); before/after live-captured
11	g_pipes init memset(NULL) removed

Before/after evidence for every bug: evidence/3_0_0_wp04_fix1/ in
the repository.

Audit & determinism findings (fixed on the spot)

• Docs regenerated to the 285-command surface, all from the command
  registry (no hand-written command list anywhere).
• The WP-05 OCBL packer had dropped the G13 staging-tree touch:
  forced rebuilds minutes apart differed in the PVD/directory-record
  mtimes and the RR TF atime/ctime. The packer now pins the staging
  tree to the epoch and zeroes RR TF ctime + atime post-xorriso -
  two forced rebuilds 65 s apart are byte-identical across
  opencube.iso, ocire.iso, src.zip and OCIRE.elf.

Current assets (fix1, build 361, the pinned-tree rebuild)

Asset	Size	SHA256
opencube-3.0.0-WP04.iso	3,637,248 B	b0f348576f61601ba7d7655a0e53e74610e2d36701959187d56f8232e792001d
opencube-3.0.0-WP04-src.zip	4,157,834 B	886bf41200d3165543ffb1f26c1644f286fb4b2ff1b5090d6d11248a4792b98f
opencube-3.0.0-WP04-update.tar.gz	1,153,842 B	9f7a7030b6990c8a3736ba67573293d636d9b4ac18067a7fac4e71ea1d5db2bd
opencube-3.0.0-WP04.elf	2,075,728 B	e7c6ce9796775bd66af52b0f3913c97bde44df8c197e7f6b80ef9734f0ba32fc

The WP04 (no dash) set above is the current fix1 build. The
original WP-04 assets - the 12,351,488 B dual-GRUB ISO and its
ELF - remain attached unchanged as the historical WP-04 milestone
build.

Re-verified after the determinism fix (all real runs)

Gate	Result
BIOS boot to ring-3 ush>	3/3
UEFI (OVMF) same-ISO gate	4/4
ush full battery - banner, arrow keys, Ctrl combos, history ghost, Tab completion, CJK, exit, help three modes, pipes	18/18
OCOS suite regression (incl. tui-test 93/93)	12/12
OCIRE regression - BIOS+UEFI ISO boot, help/syscheck/logread	5/5
OCIRE keyboard (bug 9)	5/5
VGA scroll freeze band (bug 10)	6/6, band md5 identical to the earlier evidence
ELF reproducible-check	PASS (e7c6ce97)
CI on 250fc14 / 44decb4 / a80c4e4	all success

OCIRE core - 3.0.0 WP-01 (development milestone)

OCIRE core - 3.0.0 work package WP-01

OpenCubeOS Independent Recovery Environment - a second L0 kernel,
fully independent of the Open Cube OS (OCOS) kernel. This milestone is
the WP-01 scope only: OCIRE boots independently and runs a minimal
shell. This is a development milestone on the way to 3.0.0, not the
3.0.0 release (recovery features land in WP-02, the OCOS<->OCIRE
interface and process protection in WP-03).

What is in this milestone

• ocire/ - an independent kernel source tree sharing no code with
  OCOS: multiboot2 boot (BIOS + UEFI via GRUB), 4 GiB identity map,
  minimal IDT with real fault diagnostics, serial + VGA text dual
  console, serial + PS/2 polled input, checksum-verified ACPI
  (RSDP/XSDT/FADT) with a tiny \_S5 package reader, and a shell
  with exactly three commands: help, shutdown, reboot.
• Standalone boot image OCIRE-3.0.0-WP-01.iso (attached below, also
  on the website download page) - boots straight into the OCIRE shell
  under SeaBIOS and OVMF.
• Dual-boot disk tooling (make ocire-disk): a GRUB menu disk where
  the user picks Open Cube OS (default) or OCIRE, with the
  OCIRE kernel living on its own disk in a partition OCOS cannot read
  or write.
• CI gate: make ocire-kernel (same -Wall -Wextra -Werror
  zero-warning rule as the OCOS kernel) and make ocire-iso run on
  every push.

Verified (all real QEMU runs, logs in evidence/3_0_0_wp01_ocire/)

Acceptance	Result
Compile 0 errors 0 warnings	PASS (-Wall -Wextra -Werror)
OCIRE boot image produced	PASS (hybrid BIOS+UEFI ISO, 2326528 B)
QEMU boots OCIRE to a shell prompt	PASS, BIOS and UEFI
help lists the commands	PASS
shutdown really powers off	PASS (ACPI S5; QEMU exits)
reboot really resets	PASS (8042/RESET_REG; -no-reboot QEMU exits)
OCIRE partition: OCOS cannot read/write	PASS - measured, see below
OCOS regression unaffected	PASS - full 2.2.0 matrix re-run, all green
Three-way SHA consistent	PASS (see the digest table)
CI green	PASS (8517eeb, 26d401d, 0226e8c, 311877d all success)

OCIRE battery: 14/14 (BIOS + UEFI). Dual-boot + isolation battery:
11/11 (menu default -> OCOS and menu pick -> OCIRE, both firmwares;
isolation probes below). OCOS regression: host 17 + 2 declared fixture
skips, reproducible-check PASS, wp12 14/14, wp10_tui 37/37 (no #DF),
chinese 21/21, tuiqa 32/32 + 32/32, native 36/36 + 36/36, l1_per_app
35/35 (two runs each with one stray runner-side serial row on a
different app - the same declared phenomenon from the 2.2.0 release;
three logs kept), wait4 fresh-boot battery 20/20 CLEAN, boot gates
BIOS + UEFI PASS.

Partition isolation - what was measured

OCIRE's disk carries a single MBR entry of type 0xEE ("GPT protective
shadow") with no GPT header. From inside a running OCOS:

partscan: 1 partition device(s) registered     <- the OCIRE disk contributes ZERO devices
parted hdb  -> Partition table (MBR) listed   <- control disk: visible
parted hda  -> no partition table found        <- OCIRE disk: table refused
mkfs.fat32 hdap1 confirm -> device not found   <- no node to write through
disk_rw_test hdap1       -> device lookup FAIL <- no node to read through

Honest boundary, measured too: whole-disk device nodes still exist
(disk_rw_test hda, mkfs.fat32 hda confirm work on a throwaway
copy) - the same semantics Linux root has with /dev/sdb. Blocking
those administrator-level whole-disk operations requires an OCOS
block-layer policy change, which this work package's "do not touch
OCOS" rule forbids; that hardening belongs to WP-03.

Asset digests

Asset	Size	SHA256
OCIRE-3.0.0-WP-01.iso	2326528	155b01f6652df6ac9788906df8344a4a50db96592e95ff698ed600eaa6fcbca4
ocire.elf (CI artifact)	15736	59011bd8c081a02c63faee78704005481a4d2f4372b8ac8e9ba620e18ed6a4cd

Engineering notes

Two integration lessons found by live testing are encoded in the tree:
GRUB 2.12's msdos partmap skips 0xEE entries (the dual-boot menu loads
the OCIRE kernel with a whole-disk blocklist instead), and the UEFI
El Torito entry must be the ESP FAT image (OVMF cannot boot a bare
BOOTX64.EFI payload). Design document: docs/dev/ocire.md.

Apache-2.0 - Copyright cubestudio-dev <cubestudio@qq.com>

Open Cube OS 2.2.0

Open Cube OS 2.2.0 - the fix release closing both 2.1.0 open items with real kernel root-cause fixes (no test-side workarounds, no timeout inflation). The itemized record lives in KNOWN_ISSUES.md.

Fix 1: the wp10_tui post-suite kernel-stack #DF (O-01)

Present identically in 2.0.0 and 2.1.0: after the wp10_tui suite's closing SVC round (checkupdate --local from ush), the kernel double-faulted and HALTed - after all 37 checks had already passed.

Root cause (measured, not guessed): the deepest real kernel call chain runs SYS_L1SVC -> ota_update_check -> http_get_body (6000 B frame) -> net_tls_https_get (2144) -> net_tls13_do_handshake -> crypto_x509_verify_chain (1872) -> crypto_rsa_verify_pss (2704) -> crypto_bn_mod_exp (4160) -> mont_mul (1200) -> mont_redc (1856) - a -fstack-usage sum of ~23.6 KB. The recorded crash had rip = crypto_bn_mont_redc+0x2A with rsp 20,880 B below the stack top, inside the guard page, on a 20 KiB usable window (24 KiB alloc minus the unmapped guard page); a timer/e1000 IRQ nesting its frame on the same stack pushes past it, and the guard-page #PF push (with the stack already spent) escalates to #DF.

Fix: OC_KTHREAD_STACK_PAGES 6 -> 10 (40 KiB window / 36 KiB usable) - covers the measured worst chain + worst IRQ nesting with ~8 KiB headroom; costs 512 KiB of the ~505 MiB PMM pool across all 32 tasks. The corrupted #DF panic banner (andled -> handled) is fixed too. Verified: the exact crashing chunk now runs to 12/12 checks passed with the real checkupdate report (Current version is up to date) and no panic.

Fix 2: the wait4-vs-fork flake (O-02) - which was not a timing race

2.1.0 declared this as a rare interrupt-timing race. It was actually deterministic bookkeeping: when a process died, g_procs entries still pointing at it as parent (living orphans AND dead-but-unwaited zombies from earlier crashed/killed children) kept parent_tid = the dead parent's tid. The reaper freed that tid; a later task REUSED it; the new task's wait4(pid=0, any-child) matched the stale zombie, collected its exit code and returned before the caller's own child was ever scheduled (observed live: child status = 142 = 128+SIGSEGV of a #PF-killed unwaited child, with the verdict printed ahead of the child's first output line).

Fix, two points (commit 11d2127):

1. user_process_reap_resources(): orphan-detach - every entry whose parent_tid equals the dying tid goes to the sentinel -1 (a value no task can own); wait4's parent scan, the exit/wake > 0 checks and the usershell == 0 flag test are all safe for -1.
2. sys_fork() half-product paths (address-space copy failure / task-creation failure): the corpse entry detaches too - the living parent never collects a child POSIX says was never created.

Verified: fresh-boot battery 20/20 boots clean (pre-fix: 2/2 boots hit the anomaly with the zombie sources ahead of the victim); same-boot marathon g6_exec_a = 138 both rounds; same-boot stress (zombie sources + wait4 family x 8 rounds = 80 runs) zero anomalies.

Also in this release

• 2.0.0 mirror assets restored: the 2.1.0 mirror sync had deleted the 2.0.0 ISO/SRC from the private mirror's downloads tree (rsynced from the public tree, which never carried them). Both files are restored from this GitHub Release with byte-exact SHA256 verification against the Release API digests.
• Build-id caliber, exact in three places: 2.1.0's tree carried a stale version_gen.h stamp (build 308) against a release build of 309 (the header is a build-time dependency-graph marker; the -D flags are authoritative). 2.2.0 closes the ambiguity: the tag tree's version_gen.h, the ELF immediate (movq $0x13c = 316 in core_dump_save) and update.json all read build 316 = the tag commit's rev-list count (295) + the documented +21 offset.
• BUILDING.md freeze literal corrected (still said 2.0.0).

The numbers (unchanged interface surface)

• Command homes: 251 = 99 L0 (oc>) + 133 ring-3 SYS_L1SVC + 19 ush built-ins (the ush SVC_CMDS table carries 142 rows; 9 dual-homed names attributed to L0 by the first-home rule, callable from both shells).
• v1.0.0 baseline: 233 commands, all mapped (INTERFACES.md Part 1c).
• L1SVC: 17 categories / 158 numbered ops; kernel-side declarations: 144; syscalls: 54.
• v1 interface surface per-entry: 278 declarations compared - 267 public, 6 internalized, 5 gone (declared in Part 2d, each with its verified replacement).
• Source: 130,572 lines / 379 files (the +46 over 2.1.0 are the two kernel fixes' code + documentation).

Test matrix (real runs, skip counts declared)

Gate	Result
host unit tests (make test)	17 passed, 2 skipped (openssl fixtures absent - declared)
wp12 watchdog/logging/health E2E	14/14 (Intel TCO real reset + ACPI WDAT)
wp10_tui command-surface E2E (BIOS)	37/37, no #DF - the suite runs to its closing summary and the shell stays alive (the fix verified on the release build)
chinese console E2E (BIOS)	21/21
tuiqa desktop apps	32/32 BIOS + 32/32 UEFI
native desktop E2E	36 PASS / 0 FAIL BIOS + UEFI
L1 per-app record	35/35
wait4 fresh-boot battery (new gate)	20/20 boots clean - the O-02 acceptance on the release build
boot gates	BIOS PASS + UEFI PASS (banner + ring-3 ush> + uname + oc> fallback + poweroff), re-verified on the final shipped ISO
reproducible build	PASS - ELF byte-identical across two clean builds

Evidence: evidence/2_2_0_release/ in the repo.

Honest deviations (declared, not hidden)

• The two host-test skips are the rsa/x509 openssl fixtures (absent from this host; same declared state as 2.1.0).
• The same-boot marathon's round-1 g6_test T5 FAIL is the test's own fixed-name-directory EEXIST limitation when re-run in the same boot (round 0 passes; the directory names are by design not randomized) - a test-harness property, not a kernel defect; declared here and in the evidence README.

Assets (build 316)

File	SHA256	Size
opencube-2.2.0.iso	20f93fee8c791af7ac9ec1b6b53a525bef2ac2d5697b829721b28bbe0fd950f9	12,392,448 B
opencube-2.2.0-src.zip	a2041daaf3b1f5ff72cbbf161f3e90718da2adf16605cbb9ae29b8c24f2ed01b	4,716,252 B
opencube-2.2.0-update.tar.gz	ac9a6ec2c3dd679977ad1c716dbacb26ae84119ddc75751fb30712effa6ad19e	1,080,741 B

The website download page, this Release and the repo tree hold byte-identical copies. Boot it: qemu-system-x86_64 -m 512 -cdrom opencube-2.2.0.iso (BIOS and UEFI alike).

Open Cube OS 2.1.0

Open Cube OS 2.1.0 - the 17-issue fix release on top of the 2.0.0 ring-3 re-architecture. Every finding from the 2.0.0 postcheck is fixed; the itemized table with evidence pointers lives in KNOWN_ISSUES.md.

The numbers (self-consistent, machine-verified)

• Command homes: 251 = 99 in the L0 recovery shell (oc>) + 133 ring-3 SYS_L1SVC service commands + 19 ush built-ins. The ush SVC_CMDS table itself carries 142 rows; the 9 dual-homed names (rtc/hpet/pmtimer/tsc/shutdown/poweroff/reboot/halt/sleep) are registered on both sides, attributed to L0 by the first-home rule and callable from both shells.
• v1.0.0 baseline: 233 commands - all mapped (INTERFACES.md Part 1c, 233 rows, zero missing; the 2.0.0 table missed health export / health watch).
• L1SVC surface: 17 categories / 158 numbered ops; kernel-side declarations across the service headers: 144; syscalls: 54.
• v1 interface surface, per-entry (new in Part 2c): all 278 callable declarations of the v1 surface headers compared against this tree - 267 public, 6 internalized (register-class hooks moved into services/*/drv_internal.h), 5 gone. Part 2d is the declared deletion register: driver_block_init, driver_nic_init, driver_nic_probe_all, driver_snd_init, driver_snd_probe_all - init/probe plumbing, each rebuilt inside the collected-declaration service model (*_svc_init / *_svc_probe_all).
• Source: 130,526 lines / 379 files (regenerated from docs/data/stats.json at release time).

CI green again - and now a hard release gate

2.0.0 shipped source that compiled on the release host but not on CI. 2.1.0 fixes all four runner-environment traps and turns the gate hard: the tag points at a CI-green commit (kernel -Wall -Wextra -Werror 0E0W, hybrid BIOS+UEFI ISO, deterministic src zip, OTA package, host tests, reproducibility gate - all green on ubuntu-26.04 / gcc-15-gnu23 / grub 2.12).

1. tui/tui_core.c port I/O constraints (ports >= 0x100 must go through %dx) - the P0 that broke all 15 v2.0.0 CI runs.
2. GRUB >= 2.12 dropped efi_uga.mod - the ISO module lists are now filtered against the installed GRUB (essential modules still hard-fail).
3. C23 made bool a keyword (gcc >= 15 defaults to gnu23) - core/types.h keeps the compiler's bool under C23, the classic u8 under gnu11.
4. The documented CONFIG_TUI=n CONFIG_CHINESE=n off-path image failed to LINK - the display dispatch now guards the 8 locale ops (op numbers stable, clean -1 when off).

Test matrix (real runs, skip counts declared)

Gate	Result
host unit tests (make test)	17 passed, 2 skipped (openssl fixtures absent - declared)
wp12 watchdog/logging/health E2E	14/14 (Intel TCO real reset + ACPI WDAT)
wp10_tui command-surface E2E (BIOS)	37/37
chinese console E2E (BIOS)	21/21
tuiqa desktop apps	32/32 BIOS + 32/32 UEFI
native desktop E2E	36 PASS / 0 FAIL BIOS + 36 PASS / 0 FAIL UEFI (the 10-minute host runner cap cut after the final checks - declared)
L1 per-app record (new gate)	35/35 - every embedded l1apps/ program executed via run from oc>, one fresh boot per row
boot gates	BIOS PASS + UEFI PASS (banner + ring-3 ush> + uname + oc> fallback + poweroff)
reproducible build	PASS - ELF byte-identical across two clean builds

Evidence: evidence/2_1_0_release/ in the repo (the five suite logs the 2.0.0 evidence README referenced now exist, plus the rest of the matrix and the raw per-app capture).

Honest deviations (declared, not hidden)

• The wp10_tui battery leaves the kernel in a #DF HALT after its last check (kernel stack exhausted in the ush task). The same tail occurs on the 2.0.0 ISO (verified live) - a pre-existing 2.0.0-era defect, declared in KNOWN_ISSUES.md, fix deferred to the next batch.
• A rare wait4-vs-fork timing flake was observed in same-boot test marathons (a wait4-sensitive program once read an uninitialized status word). Not reproducible in isolated runs; declared in KNOWN_ISSUES.md.
• One postcheck sub-item (the "ost-tests" link) turned out to be a false positive at byte level - recorded honestly in KNOWN_ISSUES.md rather than "fixed".

Assets (build 309)

File	SHA256	Size
opencube-2.1.0.iso	808b5423127fa6ee802f84d9edd2db2639052a57946ff554512787638cdcb9de	12,392,448 B
opencube-2.1.0-src.zip	8dba53d3fe6bd3d3c0615aa025a406616b4a72d23877e9eb3429eb6c4588aa14	4,709,022 B
opencube-2.1.0-update.tar.gz	21b52c98d9224574674f4fbea31fbe71b411e2e5618281cf545376abe4bc480b	1,081,570 B

The website download page, this Release and the repo tree hold byte-identical copies. Boot it: qemu-system-x86_64 -m 512 -cdrom opencube-2.1.0.iso (BIOS and UEFI alike).

Open Cube OS 2.0.0

Open Cube OS 2.0.0

⚠ BREAKING CHANGES (read this first)

2.0.0 boots into ring 3. The kernel no longer drops you at the oc> recovery shell: the launcher starts ush (the default L1 entry, a ring-3 user shell) automatically, and falls back to oc> only when the ring-3 world cannot start. The interactive recovery surface is now 99 commands (self-tests, watchdog, crash policy, kernel log readers, chipset diagnostics, interactive sessions) - 134 of the 251 commands moved to the ring-3 service surface (133 SYS_L1SVC ops + the NETCMD bridge), 19 run as ush built-ins.

The register-class L1 interfaces of 1.0.0 are gone (driver_block_register, etc.): drivers and services now declare their identity in-file (OC_DRIVER_DECL / OC_SERVICE_DECL) and the linker collects them. Modules written against the 1.0.0 registration API need the v1→v2 mapping (INTERFACES.md "Command homes" table is the compatibility contract - every 1.0.0 command has exactly one v2 home).

L0 is restructured: core/ drivers/ services/ boot/ recovery/ arch/ (one folder per rule; services/ categories mirror the L1 interface surface). Out-of-tree build tooling that referenced the old layout must be updated.

The service surface

• SYS_L1SVC (syscall 110) is the bridge: 17 service categories / 158 numbered ops - time, fs, block, nic, snd, ota, power, display, input, camera, usb, net, crypto, health, watchdog, recovery, l1.
• ush gains pipe/redirection/wildcards/env/aliases/jobs plus 133 service commands; exit returns to the recovery shell.
• The TUI desktop's command bridge, storage/network panels and sshd exec path route through a kernel-side bridge so v1 TUI flows keep working.

Fixed on the way (real bugs, QEMU-verified)

• ota: incremental-build trap: stale ISO shipped over new kernel (the 1.0.0 Makefile comment's known issue - real fix: the ota target now depends on the ISO).
• Scheduler deadlock: SVC-frame timed waits spun with interrupts disabled (11 sites).
• UTF-8 continuation bytes dropped by the TUI capture path; IME compose wait; run-ush input park.
• VFS cross-directory move: false "target exists" / silent in-place rename; mount-root fs_type identity; ramfs two-parent move op.
• TUI form-pool leak (4 static slots) - the real cause behind the v1 long-session FAILs.
• #DF attribution depended on a heap-layout coincidence.
• Extension-page registration lost in the group B refactor (Clock/System/Lab pages).

Numbers

Commands	251 = 99 L0 + 133 ring-3 SVC + 19 ush built-ins
L1SVC	17 categories / 158 ops
Syscalls	54 (SYS_L1SVC added)
Source	130,495 lines / 379 files, Apache 2.0
Build id	302 (commit count 281 + 21 offset)

Verification on the release tree

Reproducible build (ELF byte-identical across two clean builds); host tests 17/17; wp12 watchdog/logging/crash E2E 14/14; wp10_tui 37/37; chinese E2E 21/21; tuiqa desktop apps BIOS 32/32 + UEFI 32/32; native TUI E2E BIOS 36/36 + UEFI 36/36 (files/editor/processes/panel/terminal rounds, shot rounds, zh sweep - shell-verified).

Assets

File	SHA256	Size
opencube-2.0.0.iso	efb650e25481a7b0ce9961c21c9747942d79e7b4417eb80ec41719a7bdec3854	12,392,448 B
opencube-2.0.0-src.zip	92b415a0bb476cdd2539681cd5a3fd5d4b02620115006007e03af26e61a3d672	4,632,445 B
opencube-2.0.0-update.tar.gz	327c57766785d48347de780713f93b0f63d5f3786cda0d78849ede544772d691	1,080,687 B

The website download page, this Release and the repo tree hold byte-identical copies. Boot it: qemu-system-x86_64 -m 512 -cdrom opencube-2.0.0.iso.

---

ERRATA (2026-10-25, added with the 2.1.0 release; superseded by 2.2.0 below)

2.0.0 shipped with unresolved defects. Use the newest release instead.

• Supersession note (2026-10-26, with the 2.2.0 release): all seventeen
  postcheck findings are fixed by
  2.1.0,
  whose two remaining open kernel defects (the wp10_tui post-suite
  kernel-stack #DF and the wait4-vs-fork stale-zombie race) are fixed
  by 2.2.0.
  Use 2.2.0.

• The release code failed to compile on the CI runners
  (tui/tui_core.c port-I/O constraints); all 15 CI build runs on the
  v2.0.0 chain were red while the release host's toolchain accepted
  the code - the "CI green" release claim did not hold.

• The docs carried v1-era content and self-contradictory numbers
  (a 231/233 baseline gap, a 162-vs-158 interface figure, an
  over-general "register-class gone" statement without a deletion
  register, stale command reference pages).

• Five suite logs referenced by the evidence README were not in the
  repository.

All seventeen postcheck findings are fixed by 2.1.0 (see
KNOWN_ISSUES.md in the 2.1.0 tree for the itemized table). The
2.0.0 tag and these assets stay untouched for the record.

Open Cube OS 1.0.0

Open Cube OS 1.0.0

The first public, SemVer-numbered release. This is L0 complete: a
from-scratch, self-contained x86_64 kernel with a WinRE-style recovery
shell, built from 140,672 lines of original C/assembly under Apache 2.0.

What Open Cube OS 1.0.0 is

• A real kernel, not a Linux fork. Preemptive priority +
  round-robin scheduler, 4-level paging, kmalloc heap with #PF growth,
  256-gate IDT with IST stacks, LAPIC, 100 Hz PIT + HPET/PM-timer/TSC.
• Ring 3 out of the box. ELF loader, 53 syscalls, signals,
  fork/exec/pipes/select/mmap, dynamic linking (in-tree ld.so, PIE,
  dlsym) - user programs run unprivileged.
• Boots everywhere the PC platform goes. GRUB 2.12 hybrid ISO
  (BIOS El Torito + UEFI image), multiboot2 protocol, 512 MiB RAM is
  comfortable, disk optional, A/B slot menu.
• A recovery shell by design. 233 commands covering inspect,
  diagnose, repair, install and update - the system is the
  WinRE-style environment (oc> is the prompt).
• 16 driver families. NVMe, AHCI, ATA-DMA, virtio-blk, USB MSC,
  SCSI (LSI); e1000/e1000e/igb/ixgbe/rtl8139/rtl8169-family/BCM57xx
  NICs; HDA/AC97/SB16/ES1370/virtio sound; UVC cameras; UHCI/OHCI/EHCI/
  xHCI USB stacks; ACPI with a real AML walker and S3 suspend/resume.
• A full TCP/IP stack. ARP/IPv4/ICMP/UDP/DNS/TCP with congestion
  control, sockets, firewall, an HTTPS client (TLS 1.2/1.3 + X.509
  chains), and SSH both as client and server.
• Filesystems. FAT32 with LFN, exFAT, ext4, ramfs; GPT/MBR
  partitions; A/B update slots.
• A TUI desktop. Desktop, taskbar, menus, forms, editor and system
  apps - plus a Chinese console layer (16x16 font, pinyin IME).
• Reliability. Crash dumps to serial + /etc crashlog, kernel log
  with rotation/levels/filters, health monitor (CPU/mem/tasks/IO +
  JSON export), hardware watchdogs (Intel TCO + ACPI WDAT), OTA
  updates with SHA256 + signatures and rollback.
• The L1 extension surface. 162 numbered interfaces (the contract
  upper layers build on; see INTERFACES.md) and a shared-object loader
  that makes L1 modules loadable at runtime. L1 itself is not shipped
  with L0 - the surface is the product.

What changed since WP-14-docs_release

• The release version is now a fixed Makefile literal
  (OC_RELEASE_VERSION ?= 1.0.0) instead of a git describe --tags
  derivation - the banner, uname -a, the OTA manifest and the ISO
  volume id all read Open Cube OS 1.0.0.
• Versioning switched to SemVer (docs/release/versioning.md, bilingual).
• The public-facing surfaces (website facade, README, docs center, wiki
  sources) no longer carry the internal work-package naming; it
  remains in the engineering history (git, changelogs, code comments).
• Website/docs fixes: docs index table link typo (en/zh), facade
  fallback version strings, arch-page L1 origin column made
  tech-area based.

The numbers (machine-verified at build time)

Metric	Value
Shell commands	233
L1 extension interfaces	162 numbered + documented unnumbered groups
Syscalls	53
Source lines	140,672
Build number	278 (commit count 257 + the +21 alignment offset)

Known issues

• The OTA package embeds the build date (UTC day granularity): it is
  reproducible within a day, not across days.
• The Windows build path (build.ps1) forwards to WSL2/MSYS2 and is
  statically verified only - no native Windows host was available.
• TUI=n / CHINESE=n builds ship 216 commands (17 Chinese/TUI commands
  compiled out) - documented in BUILDING.md.

Verification (this release, on the release ISO)

Reproducible build PASS (byte-identical across two clean builds) |
BIOS boot gate PASS (233 commands, oc> ready) | UEFI boot gate PASS
(q35 + OVMF, 233 commands, oc> ready) | regression 28/28 | watchdog/
logging/health E2E 14/14 (TCO and WDAT real resets) | website verified
in a real browser (bilingual, dark mode, 390px, search, zero console
errors).

Assets

File	Size	SHA256
opencube-1.0.0.iso	12,326,912	cee135aa49d2c62f8fce5bd39444867e169bb9ee62419846454d386c297b82e3
opencube-1.0.0-src.zip	4,279,323	17cfb67b03c0ca75537275995efffa8c0765af720936a94725d1563ce3ed3ba8
opencube-1.0.0-update.tar.gz	1,058,350	3061d1be9893b0782636ebd3cd4ebb77d8c22d17a847e9d367ec804e4f3e90a9

SHA256s are filled by the release pipeline (tools/update_website.sh
output + the download page). Verify any copy with sha256sum.

WP-14-docs_release

WP-14-docs_release

Documentation and release system: the complete documentation set, the
website rewrite, the GitHub wiki, and the release engineering process,
built strictly from the current code (nothing inherited from old docs).

What changed

• Root documentation set, rewritten from scratch (7 files): README,
  BUILDING, INTERFACES (every one of the 162 L1 interfaces and the 233
  shell commands), ARCHITECTURE, FAQ, CONTRIBUTING, LICENSE (Apache-2.0).
• docs/ knowledge base, 365 pages: user manual (244 pages including
  a page for every shell command), developer handbook (10), architecture
  deep dives (13), L1 extension guide (12), driver family manuals (15),
  troubleshooting (6), subsystem internals (7), release engineering (5),
  plus the generated data/ (commands.json, interfaces.json, stats.json)
  and the historical archive (44).
• Website rewritten: the facade is pure HTML/CSS/JS (no framework);
  the docs center is VitePress over the repository docs/ tree (322
  rendered pages with full-text local search). Responsive from 390px
  phones to desktop - verified in a real browser at both widths.
• GitHub Wiki: 76 curated pages mapped from docs/ and synced by
  tools/sync_wiki.sh (single source of truth: the docs/ tree).
• Release engineering: the SOP (docs/release/process.md) with gates
  at every step; tools/build_release.sh (one-command gated release
  build), tools/update_website.sh (release data -> website), and
  tools/gen_api_docs.py (real-data extractor: 278 interface declarations
  parsed from 13 surface headers, 233-command table from a live
  help -a capture, per-directory line stats).
• SPDX headers across the tooling; versioning and release-note
  conventions documented (docs/release/versioning.md).

New interfaces

None - WP-14 is documentation and release engineering only. The
command surface stays 233; L1 stays 162; syscalls stay 53. This is a
docs release: the kernel binary is unchanged from WP-13-build_system
(ELF byte-identical build, same boot banners).

Known issues

• The OTA package embeds the build date (UTC day granularity): it is
  reproducible within a day, not across days.
• The Windows build path (build.ps1) forwards to WSL2/MSYS2 and is
  statically verified only - no native Windows host was available.
• TUI=n / CHINESE=n builds ship 216 commands (17 Chinese/TUI commands
  compiled out) - documented in BUILDING.md.

Verification (this release, on the release ISO)

Reproducible build PASS (ELF byte-identical across two clean builds) |
BIOS + UEFI boot gates PASS (233 commands, oc> ready) | regression
28/28 | watchdog/logging/health E2E 14/14 (TCO and WDAT real resets) |
dhtest 5/5 | SSH E2E 5/5 | HTTPS E2E 7/7 | website verified in a real
browser (desktop + 390px, zero console errors, search works, downloads
HTTP 200 with matching SHA256).

Assets

File	Size	SHA256
opencube-WP-14-docs_release.iso	12,326,912	3f876901db0af0b5b1779207e9faef77dc9f00cdb7731a7f47339e1ac0e00328
opencube-WP-14-docs_release-src.zip	3,976,264	91169570191b1d5a348169b602ee70b2bc4a7e7a5de82a79b4f047acdf7fb1c3
opencube-WP-14-docs_release-update.tar.gz	1,058,345	0873224deff05a6838aa80ea1bc26a7648f64ac3b1273a0746d4345d076c5117

Build 274. Apache-2.0, (c) cubestudio-dev cubestudio@qq.com.

WP-13-build_system

Engineering build system: one-command builds (Linux build.sh / Windows build.ps1 / make all), reproducible builds (byte-identical ELF across clean builds, deterministic SRC zip), ARM64 + RISC-V cross-compilation with live-verified bring-up shells, content-addressed compile cache (3.2x), multi-configuration builds (.config / menuconfig / CONFIG_TUI=n boots 216 commands), CI pipeline, BUILD.md guide. Gates on this ISO: 0 errors 0 warnings, WP-12 E2E 14/14, regression 28/28, dhtest + cryptotest, SSH E2E 5/5, HTTPS E2E 7/7, BIOS + UEFI (233 commands).

WP-12-watchdog_logging

WP-12-watchdog_logging: watchdog (hardware TCO/WDAT + software) + unified logging + health monitor

Hardware watchdog: Intel TCO discovery (LPC PMBASE +0x60, RCBA enable via PCI config 0xF0, GCS NO_REBOOT at RCBA+0x3410 cleared on arm - the iTCO_wdt update_no_reboot_bit step, found live via -trace tco_timer_expired) plus a full ACPI WDAT parser (24-byte entries, Header Length honoured, SystemIO + SystemMemory GAS with the table's own value/mask), WDAT taking precedence when present. watchdog hw start N arms the real countdown and expiry hard-resets the machine (QEMU q35: REAL reset -> second boot reaches the shell; a synthetic 164-byte WDAT injected with -acpitable drives the same register path). The default pc machine reports none honestly.

Software watchdog: 16 monitored slots (watchdog_register/start/feed/stop/set_timeout) on a 1 s kernel tick with four timeout policies - PANIC through the full WP-11 crash path, REBOOT, KILL task-only (kernel keeps running), LOG once per episode. Slot 0 wraps the WP-11 system heartbeat; the health sampler feeds it every second (boot default stays DISARMED, the documented WP-11 decision).

Unified five-level kernel log: DEBUG/INFO/WARN/ERROR/FATAL with independent per-level switches, a 1024-entry ring (64-entry static bootstrap ring keeps the identity-window ASSERT), serial + VGA live channels, the /var/log/kernel.log file channel (task-context appends, IRQ writers set dirty, panic flush for non-#DF sources - the 15.13 boundary unchanged), flush-first rotation at a runtime threshold (kernel.log -> .1 -> .2 -> .3, keep 3) and a level/module/keyword filter scoping live output AND replay.

Health monitor: a 1 s sampler (CPU busy% from new scheduler idle/total counters, PMM + heap memory, task states, disk + network counters) with rising-edge alarms (mem > 90%, tasks > 64, cpu >= 90% for 10 consecutive samples) and a JSON export (/var/log/health.json).

New commands: dmesg, logcat (-l/-m/-k/-t/-n + -f follow), logctl (status/level/enable/disable/clear/flush/rotate/threshold/export/filter/test), watchdog (status/slots/hw family + test kill|panic|log), health, health watch, health export - 226 -> 233 total (SHELL_MAX_COMMANDS 232 -> 256 after 232 filled exactly and silently refused the last registration, found live at the boot banner). L1 extension interfaces: 146 -> 162 (klog 6 + watchdog 5 + health 5).

Gates, measured on this exact release ISO: WP-12 E2E 14/14 across pc/q35/q35+WDAT (tools/wp12_watchdog_logging_e2e.py; both TCO and WDAT really hard-reset the machine), regression 28/28, dhtest 5/5, cryptotest, SSH E2E 5/5, HTTPS E2E 7/7, BIOS + UEFI boots, 0 errors 0 warnings.

Assets: ISO 12,326,912 B (sha256 5e1d231de96c8681ff872df5dabff35454126e58252da151972af0e8ffb93314), SRC zip 3,797,140 B (07fc65b24aa93271b89e0b6cf8241f90090b9455e8a5c6c23362d37e10e8ff9d), update package 1,063,428 B (e1967c4cb5ddcaad5996fa44a1e304d255d76d688cc90d3dbc7b2233a4d31034) - 3-way identical with the site downloads. Build 250.

WP-11-crash_recovery

Crash recovery: the kernel no longer just dies.

• Panic capture: unified kernel_panic_frame - banner + 16-GPR register snapshot + call traceback, serial AND the red VGA console; L1 panic-handler chain (a handler claiming recovery resumes the frame); OC_ASSERT source.
• Core dump: oc_dump_hdr_t + register block + kernel-stack window; persisted to /var/crash/core.dump (ramfs or FAT32) or hex-dumped on serial with no filesystem; dumpinfo decodes the header.
• Crash log: 32-entry ring (vector/ring/err/rip/rsp/cr2/task/tid/pid + RTC), crashlog command + flush to /var/log/crash.log.
• Recovery policy: HALT safe loop or production REBOOT (8042 + 0xCF9) - QEMU-verified panic -> reset -> second boot.
• Watchdog: 1 s tick, boot-disarmed (documented decision), crashtest wd drives the real tick path.
• Kernel-stack overflow: guard pages on every kthread stack, scheduler rsp bounds check, KERNEL STACK OVERFLOW attribution with the task name (crashtest ovf).
• Ring-3 SIGSEGV: shared delivery primitive - a faulting process with a handler gets a real signal (3-delivery ping-pong guard, reset on exec); run sigsegv_test / stackovf / badapp.
• TUI containment: a real ring-0 fault inside a guarded TUI page longjmps back to the surviving desktop (Control Panel -> Crash test).
• Commands: crashtest (panic/exc/pf/assert/wd/ovf/dump/policy) + dumpinfo; crashlog completed (224 -> 226). L1 interfaces 138 -> 146.

Acceptance (on this exact ISO): WP-11 E2E 14/14 (tools/wp11_crash_e2e.py), regression 28/28, dhtest, cryptotest, SSH E2E 5/5, HTTPS E2E 7/7, BIOS + UEFI boots, 0 errors / 0 warnings. Boundary stated honestly in KNOWN_ISSUES 15.13 (#DF path records no dump/log entry - destroyed-stack context).

ISO sha256 032dd175cc28b67d82bb5edf8623437d9202012e6191f86f6ce3bf4d77cf5890 (12,294,144 bytes)
SRC sha256 40a32924e4689c7f5e8694fd6a4cc2e0c283cdc572b674191a77de515411d9a4 (3,754,846 bytes)