NextBSD Research

NextBSD

• NextBSD DirectoryServices — the file-level porting plan (directoryservicesd) Plan · top-level goal The top-level goal. Give NextBSD network users spanning Mac OS X 10.3 → macOS 26, via a net-new directoryservicesd — a Path-B C daemon wrapping DirectoryService-621.12's in-process plugins behind the C API, with pam_directoryservices + an nss_directoryservices nsswitch module and org.nextbsd.* Mach names (from a 4-agent source-grounded scope). Home directories for those users are served by NFS (preferred, NextBSD↔NextBSD) and AFP (optional, legacy Macs to macOS 26) — the sequence nested below. Filesystem decisions: UFS is the live-ISO filesystem (plus the case-insensitivity patch for Mac shares); ZFS stays a supported installed-system option delivered via a future separate zfs-img (never the live ISO — NextBSD may eventually ship iso / ufs-img / zfs-img variants); HFS+ is a footnote (read-only Mac-disk migration). Next piece to wire: NFS as launchd daemons. Planning only.
  • Directory services before opendirectoryd — research & source-availability audit Research Background & the audit that drives the port. What Apple's directory stack was across three generations — NeXT NetInfo → OS X Open Directory → the closed opendirectoryd — with local-vs-network user records, storage paths, and home-mount protocols per era, plus the verified reusable code (DirectoryService-621.12, OpenDirectory-146, APSL 2.0; opendirectoryd never released). ~100 primary sources.
  • Native AFP server (afpd) — optional legacy-Mac home/file serving Plan The optional AFP home/file server for legacy Macs (10.3 → macOS 26). A clean-room DSI/AFP daemon (netatalk is GPL → design reference only) with an FS-agnostic fork backend (UFS2 extended attributes / AppleDouble / HFS+-native) so the same server works over any filesystem; auth arm's-length via pam_directoryservices; Bonjour _afpovertcp._tcp + launchd. ~6–9 months. Strategic bound: Apple is removing the AFP client (deprecated macOS 15.5, gone in macOS 27) — so this serves old Macs, never 27+.
  • UFS case-insensitivity patch — Mac case behavior for the shares Plan Mac-friendly case-insensitivity for UFS shares — a tightly-bounded nextbsd-kernel patch: three changes (ufs_lookup compare + ufs_dirhash key/verify) and an FS_CASEFOLD superblock flag. ~4–6 weeks for the ASCII-only version (vs years for an HFS+ port). Precedent is ext4/msdosfs, not Apple — Apple's own UFS was case-sensitive, and even ravynos skipped this. Caveats: NextBSD-only volumes, and fsck_ffs collision-detection is the tail.
  • HFS+ — read-only Mac-disk interop Footnote / deferred Footnote — deferred, not a default/alternate filesystem. Worth revisiting only as read-only disk interop: mounting real HFS+ disks / .dmg / Time Machine volumes to migrate Mac data into NextBSD — and likely moot once UFS is patched. The detailed port research (the entire HFS+ stack is open, APSL 2.0 in apple-oss-distributions/hfs) is retained as reference for that interop case; the original "alternate main filesystem / replace UFS" framing is superseded.
• NextBSD monorepo — one freebsd-src tree, feasibility & setup Draft · feasibility Working draft (several topics deliberately unsettled). Feasibility + setup for collapsing the ~10 nextbsd-redux repos into one pkgdemon/nextbsd tree seeded from fresh FreeBSD main with our changes committed on top. Core calls, all precedented: track freebsd/freebsd-src main as a git remote and merge (HardenedBSD model) — never rebase/patch-files/in-network-fork — seeded from a squashed single-branch snapshot (~1–1.5 GB), first merge --allow-unrelated-histories, a scheduled Action opens the sync PR (via git CLI + gh, not the reset-hard fork recipe). Userland into buildworld via the LOCAL_DIRS/LOCAL_LIB_DIRS/LOCAL_MODULES hooks (recon correction: the userland is already mostly bsdmake — only libdispatch + swift-foundation-icu are CMake). pkgbase “compose, don’t strip” — leave unused base (init in must-have FreeBSD-runtime) in-tree, curate ISOs via pkg install, switch nextbsd-freebsd-compat from installworld+tar to make packages. syslog/ASL replaced by stock syslogd + a thin libasl write-shim. Selective/incremental builds (META_MODE+filemon+ccache), Linux cross-build of world/kernel (tools/build/make.py) with ISOs on a real NextBSD host, optional BuildKit layer caching, and a detect-changes CI topology. Explicitly unsettled — slated for breakouts: IOKit / kld-vs-kext (§4, now broken out below), make release targets & the media matrix (live / UFS & ZFS installer / RPi & other images — coordinating with the images survey below), and pkgbase package naming. Planning only.
  • Driver delivery — kld / kext / IOKit scoping Draft · sidebar The IOKit sidebar (provisional; IOKit is the open topic). Should NextBSD reconstruct every driver as a kext, only firmware drivers, or a mixture? And does any of it need Apple's in-kernel IOKit C++ runtime? Verdict: a deliberate three-tier mixture — compiled-in (boot minimum) / plain kld (devmatch-autoloaded: input, ethernet, most drivers) / kext (firmware ∨ multi-version) — and NO IOKit runtime, which is already the direction of the shipped design (the in-kernel matcher is flat-C on newbus, not OSMetaClass; the ko→kext plan scoped the real runtime out as a 3–5 engineer-year newbus collision). Unifies ~14 existing plans + the live ko2kext tooling. Key refinement: of the catalog's 343 kext candidates, only ~50–60 actually need kext treatment (firmware ∨ version); the other ~250 stay plain klds that native devmatch already matches — add a form column as single source of truth, generate build-excludes for one-form-per-device. Firmware offline is solved pkg-free by firmware(9) (FreeBSD 15's raw /boot/firmware); the wired-memory win is honestly tens of MB, not hundreds (the vm_page array dominates), so lead with version-coexistence + modularity. nvidia coexistence works on-disk/per-boot but never two-branches-resident (an EEXIST wall IOKit can't fix either). make buildkernel already emits klds; a NextBSD-owned make extensions target formalizes ko2kext with zero upstream edits. Planning only.
    • The firmware & multi-version driver short-list — the ~50 kext candidates in a table Reference table Which drivers actually earn kext treatment, enumerated. Under kext ⇐ has-firmware ∨ needs-multi-version: 23 WiFi + 3 GPU DRM (i915/amdgpu/radeon) + 6 nvidia branches + 6 ethernet/storage/crypto = ~38 driver kexts, plus ~13 separate firmware-image kexts ≈ ~50 total (so "50–60" holds once the firmware blobs count as their own kexts; the driver count alone is ~38). Per-driver: chips/vendor, whether firmware is base-owned (free, in sys/contrib/dev) or a ports/pkg blob you must bake into the image (net/wifi-firmware-*, graphics/gpu-firmware-*), the proposed org.nextbsd.* kext name, and whether a gen-*-personalities.sh exists. Includes the "looks like firmware but isn't" exclusion list (bxe/qlnxe compile fw in; mlx/sfxge/oce/RAID HBAs are on-card — a catalog over-count to fix), the restricted-license wifi (bwn/bwi/malo/upgt, unbakeable), and the correction that nvidia 304/340/390 all still build on FreeBSD 15/16. Planning only.
      • Kext naming manifest — the static before→after name list Manifest The curated KMOD → kext mapping that drives the build, grounded against FreeBSD main. See also the build model (below) that consumes it. Decision: naming follows build origin — base in-tree drivers take their FreeBSD name (if_iwlwifi.kext, mechanically auto-derived, ~280 modules, zero judgment), out-of-tree ports take custom curated names (IntelGraphics.kext, NVIDIAGraphics595.kext — only 12 hand-named, since they already need bespoke build recipes). Every row shows the FreeBSD KMOD, the prior June-catalog name, and the new name + org.nextbsd.* id. Corrections the main grounding forced: adds the 4 missing USB wifi drivers (run/rsu/uath/upgt), expands mt76 to its 6 real KMODs, drops the non-existent iwmfw, moves nvidia from one NVIDIA to per-branch, and confirms zero driver deltas between main and releng/15.1 for this set. Static manifest = names + wiring; the IOKitPersonalities match tables stay auto-generated. Planning only.
      • Restricted wifi firmware — the 4 drivers no one can ship firmware for Reference Why bwn/bwi/malo/upgt sit apart, and how every OS handles them in 2026. Their firmware isn't redistributable (not merely "non-free"), so nobody bakes it into an install image — not Debian's firmware ISO, not OpenBSD's fw_update. Per-chip verdict (b43 = extract-from-Broadcom-driver via b43-fwcutter; PrismGT/upgt = third-party daemonizer.de blob, NOT in linux-firmware — corrects an earlier claim; Marvell 88W8335/malo = no distribution grant + Linux-orphaned, BSD-only). A distro×driver matrix (Debian/Ubuntu/Fedora/Arch/openSUSE/Gentoo/NixOS/FreeBSD/OpenBSD/NetBSD) showing the universal "ship the driver, not the blob" dodge; the OpenBSD fw_update gray-area model; the b43-fwcutter mechanism; and an EOL note (all dead 2000s silicon, the b43 route itself bit-rotting as Broadcom pulled the URLs). For NextBSD: drop them or carry-driver-only — the wall is redistribution rights no image can climb, so a firmware-included ISO (right for the ~19 redistributable wifi drivers) simply doesn't reach these four. Planning only.
    • Build model — three targets, three tiers Plan How the compiled-in kernel, the loadable klds, and the kexts all come from one tree without patching a stock FreeBSD build file. make buildkernel NO_MODULES=yes makes tier 1 (kernel image, stays stock via a flag); a NextBSD-owned make buildextensions builds in-tree sys/modules → plain klds + firmware kexts; make buildgraphics handles the out-of-tree drm-kmod + nvidia ports (they're not sys/modules, and already need bespoke fetch/patch recipes); make buildworld is untouched. All feed a shared bsd.kext.mk (formalized ko2kext) into /System/Library/Extensions. Load-bearing open decision: Pure vs Mixed — keep /boot/kernel holding the ~250 plain klds (native devmatch carries them, matcher scoped to ~38) vs an empty /boot/kernel with everything a kext (your matcher owns all matching). Also: build-time fetch of nvidia/drm-kmod does not violate base-never-requires-pkg (that's a runtime/target constraint), and an alternatives section for local ergonomics (a make nextbsd umbrella + build.sh, or "local stays stock, kexts are release-only" — the heavy target graph is mostly a Pure-model tax; Mixed lets buildkernel stay stock and bootable). Planning only.
• NextBSD images — shipping UFS and ZFS (options survey) Survey / options How NextBSD could support both UFS and ZFS across its media, judged against three hard constraints — simple installer (keep the cpdup clone, no wizard), no img-vs-installed divergence, and the live ISO stays UFS. A survey, not a decision (deferred). Baseline: build.sh already ships a live-UFS iso + a dd-able rw-UFS img, and the cpdup installer is already filesystem-agnostic — so adding ZFS is a third build artifact (makefs -t zfs; the loader reads ZFS directly, so it's the same GPT + gptzfsboot), gated only on OpenZFS being compiled into the NO_MODULES kernel. Recommended framing: three editions — live (run, UFS) / installer (boots to installer, installs UFS or ZFS) / disk (prebuilt dd/VM image, UFS + ZFS variants) — with ZFS gated to the non-live editions, which cleanly solves both the USB write-endurance problem (ZFS never runs off cheap flash) and the divergence worry (no live ZFS to diverge from). Includes the full artifact filename table, four naming schemes (live/installer/disk preferred), the option-by-option scoring, the ZFS-on-USB-flash caveats (write amplification + flush-lying), and FreeBSD/GhostBSD/TrueNAS precedent.
• NextBSD WLAN — wlan_xauth, wland, and the DHCP gate Plan Source-level review of all six nextbsd-redux repos plus gershwin-components. The headline is a one-line kernel bug: wlan_xauth is absent from config/NEXTBSD, and because assemble-image.sh deletes /boot/kernel/*.ko, net80211’s kldload autoload can’t self-heal — so every WPA/WPA2/WPA3 association fails EINVAL at the first ioctl. Open networks work. Everything else in the protocol stack is already built: wpa_supplicant 2.11 ships in FreeBSD base untouched, IntelWiFi.kext is firmware-bundled and boot-proven in CI, LinuxKPI’s mac80211 shim is statically linked. But there is no zero-glue path: nothing creates the wlan0 VAP (that’s rc.conf’s job, and NextBSD has no /etc/rc.d), and ipconfigd fires DHCP at net80211 RUN state — before the 4-way handshake — then never retries, because the link is already Active. Design: keep wpa_supplicant stock, from base (don’t vendor it, don’t teach it Mach — it never needs to know configd exists); a C + CoreFoundation wland owns the VAP lifecycle, drives the control socket, and publishes State:/Network/Interface/wlan0/AirPort; ipconfigd grows a ~70-LOC gate requiring Link{Active} and AirPort{Authenticated}, with key-absent meaning ready so wired NICs are untouched. Key constraints found in the code: Objective-C does not exist in nextbsd-userland (so the CoreWLAN-shaped API lives above the Mach line, in Gershwin, reached via a C CLI like ipconfig); MIG out-of-line data is broken in this kernel; the store rejects any value over 8 KiB (so scan results can’t go in it); and there is no keychain, so PSKs are plaintext either way. Also documents two latent ipconfigd bugs WLAN forces us to fix — a dead re-arm after lease expiry, and a global single-flight that caps the daemon at one bound interface for its lifetime.
• WLAN on NextBSD — the Apple stack, and why we use wpa_supplicant Research Background for the plan above. What macOS actually runs (closed wifid + IO80211Family + CoreWLAN; the only open piece is eapolclient, which does the EAP exchange and nothing else — no scanning, no association, no 4-way handshake, so there is no seed for a custom supplicant). Function-by-function comparison of Apple’s stack against wpa_supplicant and iwd, and why iwd loses decisively on the two non-negotiable rows — it’s welded to nl80211/cfg80211 with no net80211 backend, and it’s LGPL-2.1 — while still being the better design reference for the autojoin brain wpa_supplicant lacks (its Station/Network/KnownNetwork/Agent objects map almost one-to-one onto CoreWLAN). iwd contributes ideas; wpa_supplicant contributes code. Includes a glossary of the whole 802.11 security alphabet — AWDL, EAP/EAPOL, the 4-way handshake, PMK/PTK/GTK, SAE, OWE, PMF, 802.11r/k/v.
• NextBSD configd — porting plan Serving The Mach-IPC configd port: a MIG server on com.apple.SystemConfiguration owning the SCDynamicStore, with IPConfiguration as a separate daemon beneath it (not an in-process plugin, since there is no plugin loader). Renamed from freebsd-configd-plan — this was never FreeBSD-only work. Reconciled with the WLAN plan (2026-07-14): configd is the store, not the author — wland publishes State:/Network/Interface/<iface>/AirPort itself, so no configd change is needed for WLAN. Two stale claims corrected: an earlier draft had configd reading the wpa_supplicant control socket and populating a …/WiFi key (wrong key, wrong owner), and argued for security/wpa_supplicant from ports superseding base (rejected — it's the same 2.11 and shadows base for nothing; we keep it stock from base).
• NextBSD IPConfiguration — porting plan Shipped through iter 8 Apple's IPConfiguration (DHCPv4/v6, RA/SLAAC, RFC 5227 ARP) as a standalone Mach daemon replacing dhcpcd, publishing leases to configd over Mach RPC. Renamed from freebsd-ipconfiguration-plan. Reconciled with the WLAN plan (2026-07-14): WLAN association state does not come from a wpa_supplicant hook (NextBSD has no dhcpcd, so no such hook exists) — it arrives as the AirPort key wland publishes, and ipconfigd grows a ~70-LOC gate requiring Link{Active} and AirPort{Authenticated}, key-absent meaning ready so wired NICs are untouched. Also now records that "single interface, Ethernet only" is not merely unbuilt but two real bugs — a dead re-arm after lease expiry (#37) and a global single-flight capping the daemon at one bound interface for its lifetime (#38) — both hard blockers for the gate.
• NextBSD & Gershwin — uniquely name the base libdispatch fork Research / decision Why the Gershwin global menu stopped following app-switches on NextBSD, and how it grew two builds of libdispatch. Root cause: NextBSD’s Mach-enabled libdispatch compiles EV_UDATA_SPECIFIC as 0x0100, which on FreeBSD kqueue collides with EV_FORCEONESHOT — so the menu’s file-descriptor watch fired once and was never re-armed (and the “second login fixes it” clue was a red herring: a stale active-window value left on the never-restarted login X display). Settled by on-hardware testing: the base can’t move to Gershwin’s stock build (six components need Mach sources and won’t link), and Gershwin can’t move to the Mach build — the menu still fails even with the event.c/event_kevent.c kqueue patches. So both builds must exist; the only real bug is that they share the name libdispatch.so. From a multi-agent audit across nextbsd-userland, gershwin-developer, and gershwin-components: the fix is a single rename — give the base NextBSD fork the unique soname libsystem_dispatch.so (a build-harness change; the fork is permanently owned and never synced with Apple again) and relink the base consumers onto it, while Gershwin’s stock Apple libdispatch.so is never touched. Distinct names also kill the original launchctl/dbus/sshd “Undefined symbol” poisoning. Safety rule: no single process loads both, guarded by a CI DT_NEEDED check — safe because the only base lib Gershwin consumes, libdns_sd, is a dispatch-free AF_UNIX stub. Includes a plain-language “how to read the per-library disposition” guide, the full disposition table, mDNS reconciliation, risks, and open questions. Companion to the fork-necessity review below.
• Is the NextBSD Mach libdispatch fork still needed? Research / review The prerequisite question behind the rename decision above: can NextBSD just drop its Mach libdispatch fork and use Gershwin’s stock build everywhere? No — six production components (libxpc, launchd, notifyd, and friends) depend on libdispatch’s Mach sources (DISPATCH_SOURCE_TYPE_MACH_RECV / dispatch_mach_t), and a stock HAVE_MACH=0 build can’t even compile or link them; swapping would break boot and all XPC IPC. But the instinct is half-right: the “fork” is barely a fork — a handful of compile-time deltas over stock — which is exactly why it can safely coexist with Gershwin’s stock copy once it carries a distinct soname. Component-by-component review of what actually needs Mach and why the fork earns its keep.
• NextBSD quiet console — kernel/IOKit spew off ttyv0, and an optional boot splash Plan / mockups Make the login console behave like macOS: no kernel / IOKit / driver text on ttyv0 on a normal boot (or on USB-eject), but full output under boot -v, everything still in dmesg+syslog, and panics always visible. The surprise: FreeBSD already does all the hard parts — every kernel printf splits into an always-captured TOLOG sink and a cn_mute-gated TOCONS sink, panic() force-unmutes, and RB_MUTE/RB_MUTEMSGS self-cancel under RB_VERBOSE. So the base case is a one-line loader change (boot_mute="YES" in the nextbsd-overlays fragment); the only real work is making CI boot verbose so the boot-test still sees its markers. Closes with a feasibility read on an Apple-style boot splash and four to-scale mockups (grey/black × static/spinner, real nextbsd.org cube + a CSS 12-spoke throbber) — framed as a layer on top of #272 (seamless vt(4)→drm-fbdev deferred takeover), since a splash shipped before #272 would flash to black when the GPU driver attaches. Ticket nextbsd#363.
• NextBSD path-domain conformance — adopt the gershwin four-domain layout Plan / audit Bounded follow-up to the layout spike (that decision tabled): conform NextBSD's paths to gershwin's four domains — every bare Apple /Library/X becomes /Local/Library/X; /System/Library stays. Org-wide audit of all 9 nextbsd-redux repos: six clean, freebsd-src out of scope by rule, and the rename surface confined to the Darwin userland source — ~12 runtime-behavioral sites across 6 subsystems (launchd PID-1 scan, SCPreferences, CoreFoundation, kext_tools, ASL). Headline finding: that source is duplicated byte-for-byte across nextbsd-userland/src (CI cross-build) and nextbsd/src (the ISO builder, which compiles its own copy), so the change is doubled and must land in lockstep. Includes the two hardcoded strlen traps (20→26, 14), the judgment calls (StartupItems/Logs/Spotlight), and the full file:line surface. Planning only.
• NextBSD system path layout — the Gershwin layout vs a POSIX layout Research / spike Gershwin ships an official named tools-make FilesystemLayout (--with-layout=gershwin) that roots the desktop at /System — and it collides with NextBSD on two exact directories: /System/Library/Libraries (Gershwin's ObjC install target vs NextBSD's rtld Lever-B search path) and /System/Library/LaunchDaemons (Gershwin's session plists interleave with NextBSD's 11 boot daemons). Gershwin's own make uninstall already refuses rm -rf /System on NextBSD. So: keep the domains and move Gershwin off /System (a Gershwin-layout fork — not NextBSD's call), or move NextBSD to POSIX paths (/etc/launchd.d, /usr/local/etc/launchd.d, /boot/kernel/extensions, /var/db) so rm -rf /System removes only the desktop? From a 3-agent source sweep + on-target verification: full per-path inventory, both layouts side-by-side, honest cost accounting, and the exact file:line change surface. Key findings: no /System/Library/Frameworks on the NextBSD side (libs in /usr/lib/system — no dyld/ABI knot), the kernel is filesystem-blind for kexts (zero kernel changes), and the kext cache self-disables on the move. Planning only.
• A cross-built nextbsd-userland repo — split the Apple stack out, slim nextbsd to an ISO assembler Plan ready Move NextBSD's ~2,260 lines of in-chroot Apple-userland compilation out of nextbsd/build.sh into a new nextbsd-userland repo that cross-compiles on a Linux host (like nextbsd-freebsd-compat), publishes a 4th rolling continuous artifact, and drops the in-image build toolchain (cmake/ninja/pkgconf/llvm19) entirely — leaving nextbsd a thin assembler (download 4 tarballs → layer → uzip → ISO, ~3,245→~700 lines). From a 3-agent scope. Key feasibility wins: only 2 components are CMake (libdispatch, swift-foundation-icu); the other 18+ are bsd.lib.mk Makefiles that cross-compile in make.py buildenv with zero source changes. The real work is harness-level: stage the sysroot from compat's continuous, relocate two build-time runs of cross binaries (test_corefoundation/kextdeps) to the boot-test, replace ~26 chroot ldd/ldconfig checks with readelf, and write 2 CMake cross-toolchain files. Phased rollout (parallel non-cascading → dual-source flag → flip cascade → delete) keeps the green chain intact.
• FreeBSD-compat 3-way audit — what we install, overwrite, and could port from Apple Audit Every one of the 99 components the nextbsd-freebsd-compat closure installs into the NextBSD base (srclist.txt), cross-referenced against (1) what NextBSD overwrites with Apple-sourced code and (2) what could be ported from Apple open source instead — each with a port-difficulty rating (Trivial→Impractical). From a 4-agent audit. Headlines: 0/99 currently overwritten (Apple's reboot/shutdown/login/su/mtree are vendored from system_cmds/shell_cmds/file_cmds but deferred behind IOPMLib/BSM shims); libbsm already is Apple's OpenBSM; the UFS tooling (newfs/tunefs/fsck_ffs) is Impractical because Apple has no UFS code (only newfs_hfs/apfs); the libc/loader ABI is Mach-O-incompatible; and krb5 is MIT (not Apple's Heimdal), so that “easy Apple port” doesn’t exist.
• Drop CI caching & purge caches across the build chain Plan ready Remove every caching layer from the nextbsd-redux build chain (ccache in kernel/compat/modules, the distfiles cache in nextbsd, the Docker BuildKit GHA layer cache in nextbsd-kernel-toolchain) via direct commits in build-chain order, then purge the stored caches. From a 3-agent investigation with a key correction: dropping ccache is not just deleting the cache step — each make.py wires the cache in via --cross-bindir=${CCACHE_CROSS_BINDIR}, so every call must be repointed to ${CROSS_BINDIR} (the real Clang 19) or the build rebuilds its own LLVM. And the premise correction that matters: the “freebsd-version stuck at 15.0” symptom was not a ccache replay (the kernel sets RELEASE to a timestamp and keeps REVISION stock at 15.0 by design, so vers.c always misses) — it came from a stale baked GHCR toolchain image plus genuine version pins (nextbsd-kernel-modules on releng/15.0, build.sh default 15.0), none of which a cache purge touches. Cache-drop buys determinism; the version fix is the toolchain-image refresh + the 15.1 base bump.
• NextBSD graphics — bumping drm-kmod 6.6 → 6.12 (and the 15.1 gate) Decision plan Can we move the Intel/AMD/Radeon kexts to the Linux-6.12 DRM backport, and do we need FreeBSD 15.1? A three-agent review of the ports tree, freebsd-src LinuxKPI, and the NextBSD graphics build. Answers: (1) yes, graphics/drm-612-kmod exists (DRM from Linux 6.12 LTS, 6.12.85); (2) yes, 15.1 is mandatory — the port hard-requires __FreeBSD_version ≥ 1500509 and NextBSD’s releng/15.0 (1500068) is excluded by the port’s IGNORE clause and lacks the 6.12 LinuxKPI symbols (fd_file(), fop_flags, the <linux/unaligned.h> move, 6.12 kvrealloc(), expanded folio/dma-mapping/xarray) present on 15.1 and absent from 15.0; (3) the kext bump itself is a one-line --branch 6.6-lts→6.12-lts flip + FW_TAG bump, but it’s gated on moving the kernel base 15.0→15.1 (pkg ABI FreeBSD:15 preserved). Covers NextBSD’s current build (drm-kmod 6.6-lts, baked LinuxKPI, per-vendor firmware bundling), the decoupled date-versioned gpu-firmware, the 6.6→6.12 hardware delta (Meteor/Arrow Lake i915, newer amdgpu — but still no Xe2 / Battlemage / Lunar Lake), a sequenced two-ticket plan, and the baked-MODULE_DEPEND/firmware-size risks.
• NextBSD — executing the releng/15.1 bump & drm-kmod 6.12 (per-repo runbook) Execution plan The execution follow-on to the decision plan above: it takes the verdict as settled (drm-612-kmod hard-requires __FreeBSD_version ≥ 1500509, so releng/15.1 is mandatory, pkg ABI FreeBSD:15:amd64 preserved) and answers exactly what to change, in which repo, in what order, and what to verify for issues #336 (base 15.0→15.1) and #337 (graphics kexts 6.6→6.12 + firmware). From a six-agent scope of the whole build chain: the dispatch topology, per-repo scope across the six nextbsd-redux repos (freebsd-src sync fork, nextbsd-kernel-toolchain, nextbsd-kernel, nextbsd-kernel-modules where both tickets land, nextbsd-freebsd-compat, and the nextbsd ISO assembler), a seven-step ordered runbook (sync → manual checkpoint → toolchain → kernel → base → kext bump → assemble & boot-test), a ranked risk register, and acceptance criteria mapped to the tickets.
• NextBSD input & touch drivers — hms vs utouch spike Research / spike A four-agent code review of freebsd-src and wulf7/utouch answering whether choosing hms over utouch loses any device support — no: same author, hms is the in-base successor and a strict superset (relative + I2C mice plus the absolute VM-tablet pointers utouch existed for), and utouch’s own README says “deprecated on 13+, use hms(4).” The historical “base didn’t work” pain was a default-OFF config (hw.usb.usbhid.enable) flipped ON in 15.0, not a missing driver. Covers why NextBSD must compile in the leaves (no .ko tree to auto-load — GENERIC ships only the keyboard leaves + transports), the hms/ums mouse path with absolute-axis handling and the sysmouse/HUG_TWHEEL/INPUT_PROP_DIRECT gaps, the touch/touchpad/pen stack (hmt/hpen/iichid+ig4/ietp/hconf, with IICHID_SAMPLING mandatory on amd64), QEMU/KVM (USB tablet works, no native virtio-input guest driver), Microsoft Surface (IPTS/ITHC/SAM — won’t work in base), Lenovo ThinkPad I2C-HID + PS/2 TrackPoint, the import timeline (D27777 → 13.0 → 15.0 default-on), and the exact config/NEXTBSD lines to bake in. Background for issue #335 / PR nextbsd-kernel#46.
• NextBSD unionfs inode-collision fix — design plan Design / proposal Permanent kernel-side fix for issue #332: the live unionfs root gives every layer the same st_dev and passes underlying inode numbers through, so an upper-layer header and an unrelated lower-layer header collide on (st_dev, st_ino) — and clang, which keys #pragma once/#import/include-guard dedup on file identity not path, silently skips the second (the GS_EXPORT / cups_lang_t / OBJC_PUBLIC / encode_NSInteger failures, none reproducible on stock FreeBSD). No clang flag can fix it (upstream LLVM calls it a filesystem bug). Fix modelled on Linux overlayfs xino: keep one st_dev, reserve the high bit of the 64-bit fileid as a layer tag in unionfs_getattr(), mirror it onto d_fileno in unionfs_readdir() (two layers ⇒ collision-free by construction). Exact union_vnops.c/union.h touch points, alternatives (per-layer st_dev, separate build FS, the inode-bust sweep), a full risks & implications section (32-bit ino_t EOVERFLOW, readdir bounce-buffer cost, copy-up churn, ZFS bit-63 exhaustion, NFS export), a deliberate-overlap kyua regression test + collision detector, and rollout. Retires the inode-bust build-script workaround.
• Why a live ISO won’t boot under Ventoy / iPXE — the initramfs research Research Why the FreeBSD ISO fails under Ventoy/iPXE (and sometimes real hardware): the bootloader–kernel handoff wall — /dev/iso9660/<LABEL> is created by the kernel after the loader has handed off and exited, so swapping bootloaders (GRUB, Apple’s boot-132) can’t help, and at ExitBootServices the firmware Block I/O dies (amd64 long mode can’t call INT 13h either). Two physics classes: real block devices (CD/DVD/dd-USB/VM — work, modulo discovery timing) vs. firmware-emulated/fragmented media (Ventoy/iPXE/MEMDISK — the kernel can’t re-reach them). How Linux actually fixes it — the initramfs, not a mounted ISO: reconstruct from the real stick (exFAT loop-mount / dm-linear) for Ventoy, network-fetch (dracut livenet / casper netboot=url / NFS / iSCSI+iBFT) for iPXE. The NextBSD equivalent: mfsroot+/init is the initramfs — turn /init into an ordered probe. Includes the geom_ventoy (BSD-2-Clause) / exFAT-gap / isboot assessment, a phased plan, and the single-user disambiguation test for real hardware. Background for #288.
• NextBSD Server Installer — dialog-based installer design Design doc Screen-by-screen design for a text-mode, dialog-driven server installer — amber-on-black TUI mockups for each phase rendered as illustrative box-drawing renders. Flow: Install / Upgrade (Upgrade gated until an existing install is probed), whole-disk selection showing volume labels + filesystem type broken out per disk (not just device ids), account + hostname (username/password/confirm with a hostname auto-suggested as joe-thinkpad-t460 from username + DMI model, still editable), a cpdup clone progress gauge (live filesystem cloned to the destination volume, no archive extraction), and a finish screen with Reboot / Shutdown. Build identity follows the continuous rolling release (timestamp + short commit). Includes the hostname-derivation logic, disk-column source mapping, and a palette/visual-language reference for a bsddialog(1) / ncurses implementation.
• NextBSD CI Pipeline Plan Live Automated FreeBSD cross-build pipeline on GitHub Actions free-tier Linux runners: daily fork sync, Docker-layered toolchain containers on GHCR, kernel/modules/base cross-builds, and the nextbsd ISO assembler. Targets releng/15.0 for pkg ABI compatibility; zero self-hosted runners, no open ports. Now live end-to-end and refactored around rolling, CI-gated continuous releases (producers publish on green main; consumers ingest the release, never in-flight PR artifacts), with PR validation on every repo, arm64 base parity, and a PR-only kernel boot smoke test. See §0 for the June 2026 status.
• Gershwin on NextBSD — build & live-ISO pipeline Design plan How the (currently empty) pkgdemon/gershwin-on-nextbsd repo grabs the latest NextBSD .img.zip, builds the Gershwin desktop into its rootfs, and repackages the result into a live ISO that boots identically to NextBSD’s own — 2-stage MFS, on-demand uzip, unionfs, and vfs.pivot. Covers why the repackage must run inside a FreeBSD VM, the repo layout, the build-iso.yml pipeline and live-ISO repackage stage, and the three launchd services (loginwindow, dshelper, gdomap) the desktop overlay must ship.
• gershwin-developer — NextBSD build CI (vmactions chroot) Plan Add a fourth build target to gershwin-developer’s build.yml — alongside FreeBSD, Arch, and Debian — that verifies Gershwin compiles on NextBSD. The trick earlier lacked: don’t boot the NextBSD image, chroot-build into its rootfs inside a FreeBSD VM. Documents where the job fits in build.yml, the one make-or-break risk, and what the check does and doesn’t prove. The job scrapped two iterations ago, now actually feasible.
• NextBSD — cross-build the Apple userland + image on native Linux Single-PR plan Move the NextBSD image build off the vmactions/freebsd-vm qemu VM (~17 min) onto a native Linux runner that cross-compiles the entire Apple/Darwin userland for FreeBSD with Clang 19 — zero FreeBSD packages, no chroot, the bootable UFS image assembled on Linux, qemu used only to boot-test (which already runs on ubuntu). Reuses the proven cross-build pattern from nextbsd-kernel-toolchain / -kernel / -kernel-modules / -freebsd-compat. Component-by-component plan for all 32 src/ components + mach.ko, the two net-new CMake toolchain files (libdispatch, ICU), Linux image assembly (makefs/mkimg), and a boot-contract parity oracle. Unlocks a faster arm64 ISO as a free matrix leg.
• NextBSD CI — testing coupled cross-repo changes (strategy options) Decision plan Backbone shipped How to boot-test changes that span two repos before either merges — motivating case: a nextbsd-kernel PR raising the dynamic syscall-slot limit plus a nextbsd PR dropping mach.ko’s syscall multiplexor. Visual comparison of five strategies (continuous-release + latest-green pin, artifact-override inputs, full monorepo, partial monorepo, hybrid integration meta-workflow) with a per-stage time-to-test cost model across today’s VM and native-cross worlds, a ratings matrix, and a NOW-vs-after-crossbuild recommendation. Confirms 5 current CI gaps (no PR triggers / no kernel boot test / latest-main-only ingest / a modules patch-ref desync / arm64 asymmetry).
• mach.ko syscall slots — implementation plan (widen the band, drop the mux) Plan ready Now that NextBSD ships its own kernel, the fix for the 10-slot Mach syscall ceiling is to widen FreeBSD’s lkmnosys band in the NEXTBSD kernel (a syscalls.master patch in nextbsd-kernel) so each Mach trap gets its own slot and the multiplexor goes away. Measured need ~32 slots; provision ~48. Includes a measured effort-scope of the XNU-style separate trap table (the kernel hook is a cheap C-only change, but first-of-its-kind on FreeBSD and its Apple-canonical-number benefit is moot because libmach resolves by name), and confirms IOKit needs no XNU libsyscall. Two-PR rollout: widen the band, then drop the mux. Supersedes the audit spike’s “kernel-patch disqualified” verdict.
• IOKit busyState / waitQuiet — implementation plan (Apple-shape kmod autoload) Plan ready The “right way” to drive kmod autoload: a real device-quiescence signal (IOServiceWaitQuiet / IORegistryEntryGetBusyState / IOKitWaitQuiet) over Mach, replacing FreeBSD’s devctl-plus-a-timer heuristic. A balanced device_match_start/device_match_end hook wrapping device_probe_and_attach() in the NEXTBSD kernel feeds a mach.ko bus_busy counter + a mach_wait_quiet syscall; hwregd flips on quiescence and libIOKit implements the Apple APIs. Makes concrete (and corrects the counter design of) the deferred plan in the #67 options doc, now that NextBSD ships its own kernel. Tracked by #176; two-PR rollout like the syscall work.
• FreeBSD .ko → Apple .kext conversion Plan Convert NextBSD’s kernel modules from FreeBSD .ko to Apple .kext bundles in /System/Library/Extensions — the Apple-shaped format, established before the kextd loader port. Code-grounded 3-agent scope: a .kext bundle wraps the unmodified .ko (still kld-loaded), Info.plist IOKitPersonalities generated from MODULE_PNP_INFO feed the userspace matcher NextBSD already has (libIOKit→hwregd); a full XNU OSKext is explicitly out of scope (the path ravynOS left FreeBSD for). Includes the firmware answer (gpu .ko-firmware vs wifi /boot/firmware → Contents/Resources) and the boot-critical caveat. Novel — nobody packages .ko as .kext today.
• Eliminating standalone hwregd — Apple-shaped device matching & autoload Convergence plan How to retire NextBSD’s standalone devctl-socket + timer hwregd daemon and converge toward Apple’s shape — in-kernel matching + match-notifications & busyState/waitQuiet over Mach + a launchd-activated loader (Apple keeps kextd/kernelmanagerd; the win is event-driven, not zero daemons). Umbrella over #67 (settle window), #176 (busyState), and #168 (EVFILT_MACHPORT / fold into configd). Phased roadmap from a 3-agent scope of Apple XNU/IOKit + kext_tools, the NextBSD hwregd/configd/launchd/mach.ko tree, and FreeBSD kqueue internals.
• NextBSD graphics — virtual-GPU DRM kexts, an end-to-end CI test, and the NVIDIA/VirtualBox tracks Porting plan The drm-kmod → Intel/AMD/Radeon kexts autoload via the in-kernel matcher, but that path is untested end-to-end — qemu emulates no real GPU. Port a virtual-GPU DRM driver (bochs first — it binds qemu’s default -vga std as a raw IOPCIPrimaryMatch node) to unlock KMS-in-VMs and the first true match→autoload→bind CI test. Scopes bochs/vboxvideo/virtio-gpu/vmwgfx, the shared blocker (drm-kmod’s missing drm_gem_vram/shmem helpers → a drm_extra_helpers.ko), the repo split (unmodified drm-kmod fork + a nextbsd-graphics kext factory + a recipe-only NVIDIA-legacy repo), and a phased roadmap. From a 7-agent scope.
• NextBSD graphics — porting the NVIDIA driver as per-branch co-existing kexts Porting plan The dedicated follow-on to the graphics plan’s NVIDIA track: one NVIDIAGraphics<NNN>.kext per FreeBSD nvidia branch (595/580/470/390/340/304), tiered by method — drm-kms (595/580, bind drmn, /dev/dri), modeset-only (470/390), core-only (340/304) — each carrying its own de-overlapped PCI match table and (595/580 only) raw GSP firmware, built from NVIDIA’s driver tarball like FreeBSD’s nvidia ports (which ship as binary pkgs). From a 9-agent research+review workflow that caught four defects: a kext wraps multiple .kos so CFBundleExecutable is the top of the MODULE_DEPEND chain per tier (not uniformly nvidia); 390 is modeset-only not core-only; 595 is the proprietary module with GSP default-off (not open-modules/GSP-mandatory); firmware is raw blobs in Resources/firmware/. The permanent wall: every branch’s core is module nvidia, so one branch resident per kernel — multi-GPU works only if a single branch covers all cards. Since validated against real source: matcher confirmed PCI-id personalities; one kext per .ko chained; nvidia-drm-612-kmod/595.84 confirmed real; the drm-kmod stack (Intel/AMD/Radeon + NVIDIA) shares one drm.ko core so going 6.12 moves all four together (gated on the 15.1 base). Step 1 (gen-nvidia-personalities) merged as nextbsd-kernel-modules#17. Shipped end-to-end: the drm-6.12 bump + the full NVIDIAGraphics595 kext (nvidia/nvidia-modeset/nvidia-drm + GSP firmware) are in nextbsd-pkg (build #18–22 + nextbsd-pkg#7).
• NextBSD graphics — the NVIDIA userland / display layer Porting plan The kexts autoload and /dev/dri/card0 is up, but the screen is black — a GPU driver is two layers and only the kernel one shipped. This companion settles the userland/display layer end-to-end from five parallel research passes + on-hardware testing (RTX 3060 Ti). Confirmed dead: modesetting-on-nvidia-drm (EOPNOTSUPP on the generic dumb-buffer path + kernel panic). Recommended: package NVIDIA’s X11 userland from the same 595.84 tarball and drive it with Driver "nvidia" (talks to /dev/nvidia0 directly, never DRM/GBM). Two research surprises: (1) XLibre is not the ABI dead-end it looked like — its ABI-28 aside, it deliberately auto-loads the closed NVIDIA driver (≥570) since 25.0.0.16, and classic xorg-server-21.1.24 (ABI 25.2) is the rock-solid fallback; (2) Wayland dissolves both the X-ABI and GLX problems (compositor uses EGL/GBM/KMS, no DDX, no GLX) but moves the blocker to a FreeBSD userland GBM backend that’s Linux-centric and barely present. Also answers: userland files are a mix of version-unique libs (co-exist) + fixed-name entry points (collide) → per-branch sibling bundles + an install-time activator (Apple ships userland GPU bundles as siblings to kexts, not libs-in-kext); libGLX_nvidia.so.0 is GLX-only (2D/EGL/Vulkan/CUDA run without its code); and 340/304 can’t render X on any modern server (ABI ≤24) so the userland story covers 595/580/470/390.
• NextBSD graphics — GPU readiness & LoginWindow: what actually panics Fix plan Issue #390 asked how LoginWindow should know the GPU is ready — poll ioreg? add Mach/IOKit support? The answer, from a 68-agent workflow plus two rounds of hand-verification: readiness is the wrong question, and the panic is a kernel defect nobody upstream has root-caused. For a vidmem-backed NVKMS surface nvidia-drm hands LinuxKPI the raw VRAM BAR1 physical address as a PFN; on amd64 PHYS_TO_VM_PAGE() bounds-checks against the array span, not validity, and the gap-filling init loop in vm_page.c:783 is #if defined(__i386__) — amd64 never initializes the vm_page_array entries for PCI holes, and pmap_page_array_startup() never zeroes them. So the NULL guard passes and vm_page_busy_acquire() dereferences boot-time DRAM garbage → trap 9 in _rw_wowned (which is literally the frame in drm-kmod#308). Intermittent because the garbage varies boot to boot — the one symptom no deterministic story explains. Two false trails are documented and retracted: NVKMS does not keep initializing after card0 (drm_dev_register() is the last step of a synchronous kldload, so settle delays and drmModeGetResources probes are vacuous, and IOKitWaitQuiet can’t even see nvidia-drm); and the “integer underflow” is real but inert (pfn += page_offset is compiled out on FreeBSD) — so the upstream ports patch (“Fix GPF in some configs”) cannot fix this, and as merged is still wrong on FreeBSD (it drops TTM’s + vma->vm_pgoff term). The real fix is what nvidia-drm alone omits: register_fictitious_range() over the VRAM aperture (amdgpu/i915/radeon all call it), plus hardening lkpi_vmf_insert_pfn_prot_locked(). Separately, four real ordering bugs survive — X starting before kextd has even requested the load (launchd has no ordering key), wrong-DDX selection, hybrid card0 misattribution, and no failsafe — fixed with zero new C by a synchronous kextload barrier (kldfind(2) takes kld_sx exclusive across MOD_LOAD) plus a driver-keyed terminal “no kext claims this GPU” verdict making VirtualBox/VMware/QEMU/headless a sub-second fact. Also: how Apple really does it (registerService(), IOKitWaitQuiet, LaunchEvents→com.apple.iokit.matching) and why an opaque vendor blob can never sign that contract.
• NextBSD — NVIDIA autoload & Linux binaries: LinuxKPI vs the Linuxulator Fix plan Why NVIDIAGraphics595.kext won’t autoload on real hardware (RTX 3060 Ti) and pkg install claude-code aborts — both trace to NextBSD having no Linuxulator (Linux userland ABI), distinct from the LinuxKPI driver shim that’s already baked in (which is why i915/drm/wifi load fine). Verified crux: on amd64 the module name linux is the i386 module and linux64 the 64-bit ABI — and NVIDIA depends on linux (never linux64), so the two symptoms need different modules. Recommended split: disable NV_SUPPORT_LINUX_COMPAT (one line) so the NVIDIA chain autoloads like i915/drm (the compat is only for Linux processes ioctl-ing /dev/nvidia, not KMS); and separately bake linux_common+linux64 into nextbsd-kernel (mirroring the linuxkpi_video/compat_mach precedent) to run Linux binaries. Skips the hard linux32 bake. From an 8-agent workflow + 3 review lenses, grounded in freebsd releng/15.1, the 595.84 kmod source, and on-hardware diagnosis.
• In-kernel IOKit for NextBSD — feasibility & the matching-location decision Decision doc The single fork under the kextd milestone: does driver–device matching live in the kernel (Apple-faithful — the kernel decides, kextd just loads) or in userland (faster, but a divergence)? Deep 2-agent review of FreeBSD newbus internals + Apple’s XNU IOKit / IOCatalogue / kextd, with per-option effort & risk and the “do I edit the kernel to add device IDs?” clarification (no — IDs live in kext personalities). Companion to the hwregd convergence plan; for joint review before any kextd code.
• Native EVFILT_MACHPORT migration & pipe-bridge removal — #168 plan Plan ready Move all Mach-event delivery onto the kernel’s native EVFILT_MACHPORT filter (slot -16) and delete the module-era pipe-bridge (task #39 Path B: register_event_bell + self-pipe + EVFILT_READ) — the workaround from when a .ko couldn’t add a kqueue filter slot, now obsolete since patches/0003 reserves the slot. Synthesized from a 7-agent survey of nextbsd-kernel + nextbsd + freebsd-src. Root-causes the PR #250 boot panic (a use-after-free on the port set in filt_machportattach — drops the pset lock with no reference, then knlist_add touches freed/reallocated memory at 0x70 under concurrent move_member, amplified by uninitialized worker-thread Mach state, #148) and gives the exact kernel fix. Fixes task #41 (unreliable DISPATCH_SOURCE_TYPE_MACH_RECV) at the root, retiring the pthread+mach_msg polling loops in sc_link_watch/IOKitNotify/SCNotify. 6-stage PR-gated rollout + a new concurrency stress test that reproduces the panic.
• mDNS Network browse over Mach — the empty Network-list fix Plan ready A concrete consumer of the EVFILT_MACHPORT doctrine above. The Workspace File Viewer’s Network sidebar is empty on NextBSD: mDNSResponder advertises its own .local name (peers see ThinkPad-T460s) but the dns_sd client protocol was never finished over Mach — mach_bridge.c only claims com.apple.mDNSResponder and discards the receive right, and libdns_sd ships as the AF_UNIX stub bound to a /var/run/mDNSResponder socket the nobody daemon can never create. Fix (Mach, not sockets): a dns_sd.defs MIG IDL + real Mach server wired through EVFILT_MACHPORT, plus a Mach client transport in libdns_sd. File Viewer and NetworkBrowser.app share the same NSNetServiceBrowser backend, so the UI needs zero changes. Primary repo: nextbsd-redux/nextbsd (src/mDNSResponder/); Sharing-pane launchd shim is a separate follow-on in gershwin-desktop/gershwin-components. Filed under Launchd → Mach.
• mach.ko → kernel built-in (options COMPAT_MACH) Scoping Compile the out-of-tree Mach module into the NEXTBSD kernel instead of loading it as a .ko — the answer to “how do we load mach.ko once loader.conf is gone?” and the foundational step of #180 (eliminate loader.conf). Mostly build-system wiring: the MIG server stubs are pre-committed (no codegen in the kernel build) and the syscalls already register via a SYSINIT/kern_syscall_register (no syscalls.master regen). Source migrates nextbsd/src/mach_kmod → nextbsd-kernel sys/compat/mach/, wired by a small sys/conf/{options,files} patch; the fork is never touched. Gated by the boot smoke test.
• Prove kexts work — minimal kextload + converter + PR CI Scoping Walking-skeleton proof that a FreeBSD .ko wrapped as a .kext loads via an Apple-shaped tool, gated by CI. Cheap because nextbsd already ships CFBundle (opens the bundle + Info.plist) and libIOKit — so the proof needs no OSKext: a minimal kextload/kextstat/kextunload trio over kld (Phase 1, in nextbsd) + a converter and PR CI that kextloads one leaf module in a booted VM (Phase 2, in nextbsd-kernel-modules). The full kext_tools/OSKext port is deferred but ticketed so it isn’t lost. Approach (a) chosen. Proven & merged
• Faithful kext_tools / OSKext port Plan (#182) Port Apple’s real OSKext engine (bundle discovery, dependency-graph resolution, validation, personalities) onto NextBSD with a kld backend — the faithful follow-on to the PoC, gating bulk conversion (#179) and kextd (#177). Code-grounded scope: OSKext.c ≈ 21k LOC but ~75% ports unchanged (CFBundle parsing, dep-graph math, validation); only ~25% re-backs from XNU (kext_request→kldload, IOCatalogueSendData→hwregd, KXLD/mkext deleted). Pre-SIP base avoids codesign/kernelcache. Multi-week, phased; Phase 1 (dependency resolution) is the first shippable milestone.
• kld → kext: naming + categorization Plan (#179) Groundwork for the bulk .ko→.kext conversion: a complete catalog of all 474 FreeBSD kernel modules in the tree — what each is, its category (driver / filesystem / network / crypto / KPI / …), and a proposed Apple-style org.nextbsd.* bundle id + .kext name. Built from a read-only review of freebsd-src/sys/modules by parallel agents. Surfaces the open decisions before #179: naming style, kext-vs-built-into-kernel split, sub-component/firmware handling, exclusions.
  • Raw module catalog — all 474 modules The unedited, first-pass per-module table behind the naming plan: one row per sys/modules/ entry — ko name, dir, category, purpose, proposed bundle id + .kext name, notes. Kept verbatim as the groundwork record the polished plan was distilled from.