Cognitum Seed v0.24.3

Patch release reducing steady-state Mesh control-plane reads and hardening CSI accepted-packet state. It preserves the v0.24.2 on-device data, identity, pairing, and cog contracts.

Changes since v0.24.2

• Replace unconditional Mesh peer, CRL, and ACL polling with protocol-v1 versioned snapshots. The Seed persists the last applied scope, versions, and payloads atomically; unchanged heartbeats fetch no snapshots, while legacy server responses remain supported during fleet adoption.
• Apply CRL snapshots before peers, remove revoked peers and routes immediately, retain the last valid same-scope CRL across snapshot failures, and retry missing, malformed, stale, or mismatched snapshots without discarding valid cached control state.
• Persist authoritative CSI accepted-packet state in the dedicated relay data directory. Packet-specific validation, replay high-water reservations, bounded source/type cursors, compatibility preflight, and fail-closed state handling prevent rejected traffic from refreshing data-source availability.
• Reconcile the Seed inference evidence contract with the accepted-packet authority; synthetic and unauthenticated compatibility paths remain explicitly distinguished from verified real-source evidence.

Compatibility and rollout

• The Mesh server must remain in MESH_LEGACY_HEARTBEAT_PAYLOAD=auto while older Seeds are active. Setting it to never is not part of this release.
• OTA replaces only the agent binary. Device identity, TLS and pairing material, WiFi configuration, vector data, installed cogs, and the persisted Mesh control cache are preserved.
• The relay artifact and compatibility preflight are a separate Path-B OTA asset. A missing or incompatible relay update must not prevent the agent update, but ADR-108 relay claims require its signed artifact and hardware preflight to pass.
• Fleet rollout starts with one signed candidate OTA, advances through the supported percentage-gated Path-B channel, and promotes the public Path-A latest.json only after staged health evidence. Path A itself is not cohort-aware.

Publication gates

• Required Seed CI and security checks pass on the exact release revision.
• The canonical Dockerfile.armhf build uses mesh,sparse-llm; the extracted ARM ELF reports 0.24.3, and its SHA-256 matches every published target.
• The Ed25519 signature over the raw 32-byte SHA-256 digest verifies against the public key embedded in the agent before publication.
• A connected physical Seed performs the update through the OTA client—not a manual binary copy—and proves signature verification, atomic replacement, restart, exact hash, retained Mesh cache, protocol-v1 heartbeats, and an executable rollback artifact.
• The v0.24.2 manifests and immutable artifact hashes are preserved before any production pointer changes.
• Legacy Mesh payload retirement remains gated on seven consecutive days of full active-fleet protocol-v1 adoption and the remaining ADR-140 authentication and scope conditions.

Cognitum Seed v0.24.1

Release candidate for standalone Seed ownership and account-backed cloud inference. It includes the v0.24.0 feature candidate plus the final authorization and operational-truthfulness fixes merged before canary verification.

Changes since the v0.24.0 candidate

• Scope the USB-established owner-browser bearer to owner OAuth routes. It cannot authorize controller/admin endpoints; V0 controller pairing remains independent.
• Return 503 Service Unavailable when the live cog registry cannot be fetched or parsed instead of returning a success response containing an error object.
• After applying cog configuration, verify that a restarted cog survives its initial startup window before reporting restarted: true.
• Log unsupported cog configuration types when their values are deliberately withheld from the command line.
• Report Cognitum account connection truthfully: account-backed Cloud AI additionally requires a compatible cloud-inference cog v0.1.1 or newer.
• Reap cog children after ordinary exit and use the same zombie-aware liveness predicate for app listing and restart decisions (#298).
• Distinguish a reachable Seed whose hub/provider cog failed from a genuinely offline Seed in Tier-3 failure messages.

Verification required before publication

• All required CI lanes must pass on the exact release revision.
• Build the exact armhf artifact from that revision and record its SHA-256 digest.
• Retain and verify the v0.23.3 rollback artifact before canary installation.
• Install the exact candidate on the USB canary and verify reported version and executable digest.
• Verify USB owner claim, Cognitum sign-in state, account-dashboard link, logout, and absence of token material in browser-visible output.
• From LAN, verify the owner bearer can access owner OAuth status but cannot authorize a controller/admin endpoint.
• Verify V0 controller pairing remains independent.
• Verify cog-registry outage behavior and a representative cog configuration restart on the device.
• Do not publish account-backed Tier-3 capability until cloud-inference v0.1.1 or newer is production-published and verified separately.

Cognitum Seed v0.23.0

Cloud inference release. A seed can now answer with a full-size model instead of its on-device one, by forwarding to the metered Cognitum completions plane through the new cloud-inference provider cog. This is the first release where a seed reaches Tier-3, and the first where the seed carries an owner credential at all. Minor bump rather than a patch: this is new user-facing capability, not a fix. Lands under ADR-106 (seed side) and ADR-090 §e (provider-cog model).

Highlights

• Tier-aware completion — the seed dispatches to Tier-3 (ADR-090 §e, PR #255, #268). /api/v1/llm/route-complete now decides between local and cloud from X-Cognitum-Min-Tier / X-Cognitum-Max-Tier, and forwards to the cloud-inference cog when cloud is asked for and the device is online. Offline with cloud requested degrades to local and says so (downgraded: true) rather than failing silently.

• The dispatch actually ships now (ADR-106 §2b, PR #268). tier_router was gated behind #![cfg(all(feature = "agents", feature = "local-llm"))], and the canonical armhf release builds --features mesh,sparse-llm — so the module compiled out of every shipped binary. The routing code existed, was tested, and was dead on the fleet. It is now ungated and in the release build.

• The local leg is honest (ADR-106 §2b, PR #268). On a build with no on-device model, local_complete previously implied a local answer was possible. It now returns a 503 that states plainly that the seed has no on-device model and points at X-Cognitum-Min-Tier: 3 for cloud. We do not claim inference we cannot perform.

• Seed carries an owner cog_ key, scoped to one cog (ADR-106 §4, PR #269). New POST/GET /api/v1/llm/cloud-key plus a Cloud AI step in /setup. The key is validated for shape (cog_ + 64 hex) at the boundary, stored 0600 via atomic tmp→rename, and surfaced only as a 12-char prefix — never echoed back. Least privilege is enforced by cog id: env_for_app_dir hands COG_CLOUD_INFERENCE_KEY to cloud-inference and to nothing else, because cogs are third-party code and no other cog has any business holding the owner's billing credential.

  The key is pasted, not signed-in for. A seed's primary surface is a network-isolated USB-gadget API, Firebase ID tokens live ~1h against a rotating JWKS, and someone standing at an offline seed cannot obtain one. Paste matches what the V0 wizard already does (ADR-258 §4).

Also in this release

• app-registry.json reconciled with the live fleet catalog (PR #270). Both repo copies were pinned at v2.1.0 / 105 cogs while the catalog seeds actually read had moved on. The documented "bump it by hand and upload" path would have deleted presence-field from the live store and regressed sha256 for six cogs including health-monitor. Now byte-identical to live v2.3.1.

Validation

• Host unit tests: cargo test (foundation), cargo test (default-features), cargo llvm-cov all green on each merged PR (#255, #268, #269, #270). cloud_key.rs ships 7 tests covering shape validation, 0600 round-trip, rotation, absent/whitespace keys, prefix non-leakage, and the least-privilege matrix (only cloud-inference receives the key).
• armhf cross-compile: built via Dockerfile.armhf with the canonical --features mesh,sparse-llm.
• On-hardware (cognitum-8b40, Pi Zero 2 W), 2026-07-17 — full flow end-to-end:
  • cloud-inference installed from the live store; downloaded binary sha256 matched the published artifact byte-for-byte (418b128f…).
  • Key pasted via the API; stored 0600 root:root; GET returned {"configured":true,"prefix":"cog_b0610613"} with no key tail in any response.
  • Least privilege confirmed by reading /proc/<pid>/environ as root: cloud-inference held COG_CLOUD_INFERENCE_KEY; the concurrently-running health-monitor did not.
  • Tier-3 completion originated on the seed → HTTP 200 → billed on the prod completions plane: usage_ledger row 085d4ccd-02d2-425f-a688-f9c9e3596788, tier low, z-ai/glm-5.2, 63 tokens, $0.00012465, 1593 ms.
  • Malformed key rejected 400 at the boundary with a message pointing the owner at cognitum.one/order.

Known issues / deferred

• Local fallback is not a real answer on a stock seed. The shipped build carries sparse-llm, whose weight_mode is stub; ADR-094 measures the gguf-tied path at 0.69–0.98 tok/s via a layer-0 attention + 29×FFN approximation, and full 30-layer inference does not fit the Pi Zero 2 W's 512 MB envelope. Tier-3 is therefore the only path to a genuine full-size answer today; offline degrade is honest about this rather than serving plausible garbage.
• No CI check catches "module gated out of the shipped build" — the class of defect #268 fixed. Nothing would fail today if a feature-gated module silently left the release binary again.
• OAuth device onboarding (ADR-259) remains Proposed/BLOCKED and post-launch; paste is the launch mechanism.
• Promo/sponsored allowances are a cloud-side concern on the owner's account (ADR-258 §6), not a device header. No device change is involved.

Cognitum Seed v0.22.22

Fixes FAT corruption of the USB trust certificate file, which is very likely the actual root cause of the original "Not Secure" browser report — the trust installer was silently failing on macOS even when a customer ran it correctly.

Fixed — trust/cognitum-ca.pem corrupted by an unsafe gadget-image write

sync_ca_to_gadget() (auto-ca-cert.sh) loop-mounted gadget.img read-write while cognitum-gadget.service still had it bound as the active USB mass-storage backing file — the exact FAT corruption pattern seed#244 already identified and worked around in auto-first-boot.sh and update-gadget-docs.sh, but sync_ca_to_gadget() never got the same fix.

Confirmed on hardware: a device's trust/cognitum-ca.pem had 163 trailing NULL bytes appended after a valid PEM footer (785 bytes of real content in a 948-byte file). openssl silently ignores the trailing garbage and reports the certificate as fine — which is why every fingerprint check earlier in this investigation looked correct — but macOS's Security framework rejects the whole file outright (SecCertificateCreateFromData: Unknown format in import), so security add-trusted-cert fails with no visible error. This means the trust-install step could fail silently for any customer, independent of the onboarding-instructions fix shipped in v0.22.20.

• sync_ca_to_gadget() now uses the same stop-service/mount/write/unmount/restart-service pattern as the other two gadget writers.
• update-gadget-docs.sh (doc-rev 2 → 3): while already safely mounted for the README/STATUS rewrite, compares trust/cognitum-ca.pem against the source /var/lib/cognitum/tls/ca.pem byte-for-byte and repairs it if different — this is what actually fixes already-corrupted files on the fleet without waiting for a fresh cert issuance.
• Migration sentinel bumped to v3 so devices already migrated to rev 2 (from v0.22.20/v0.22.21) get re-triggered for this repair too.

Validation

• Host: cargo check clean, all 1051 unit tests pass; bash -n clean on both modified scripts.
• On-hardware: confirmed the corruption directly (948-byte file, 785 bytes of valid PEM, 163 trailing NULL bytes) on a fielded test seed, then verified the repaired sync_ca_to_gadget() and the doc-rev 3 migration against it.

See also

• v0.22.20 (trust-install onboarding regression fix)
• v0.22.21 (force re-issue of old 1825-day-validity certs)
• platform-docs ADR-093

Cognitum Seed v0.22.21

Forces re-issuance of TLS leaf certificates signed under the pre-v0.22.20 5-year (1825-day) policy. Binary-compatible with paired clients and existing cog manifests.

Fixed — old 5-year certs never self-corrected, breaking Safari indefinitely

v0.22.20 reduced device leaf certificate validity to 825 days (Apple's browser-trusted TLS cap) and fixed the corresponding source in the cognitum-cert-signer Cloud Function. That fix was merged but the live Cloud Function was never actually redeployed until today — every cert issued between the merge and the redeploy (and every cert issued before it) was still a 5-year cert, confirmed live on a fielded test seed that connected to WiFi for the first time today and received a fresh 1825-day certificate from the not-yet-redeployed function.

Separately, and more durably: the existing renewal checks (auto-ca-cert.sh's -checkend skip-check, and the agent's periodic check_cert_renewal()) only look at time-to-expiry. A 5-year cert with 4+ years left on it would never trigger renewal on its own, so simply redeploying the Cloud Function does nothing for certs already issued — they'd sit there, still breaking Safari, for years.

Added an independent check: total validity span (notAfter - notBefore), not time-to-expiry. Any cloud-issued leaf with more than 825 days of span is force-reissued, the same way the seed#197 CA-migration guard forces a re-issue on a bad CA. Convergent: a cert issued under the now-fixed policy already has <=825 days of span, so this check becomes a no-op from then on.

Validation

• Host: cargo check clean, all 1051 unit tests pass; bash -n clean on the modified script.
• On-hardware: deployed the updated script to a fielded test seed carrying a live 1825-day cert issued earlier the same day. Confirmed it logged the pre-ADR-093-policy detection, force-reissued through the redeployed cert-signer, and the resulting cert measured exactly 825 days. A follow-up run against the fresh cert correctly skipped (idempotent). Agent health confirmed via /api/v1/status after restart.

See also

• v0.22.20 (original 825-day validity fix + trust-install onboarding fix)
• platform-docs ADR-093

Cognitum Seed v0.22.20

TLS trust-install onboarding fix + device leaf certificate validity reduction. Binary-compatible with paired clients and existing cog manifests.

Fixed — browser "Not Secure" warning surfaced by an external contributor

An external contributor reported their Seed's https:// link shows as "Not Secure" with no trust chain the browser recognizes. Investigation found the private CA architecture (ADR-061) works correctly, but two real defects were compounding the symptom — see platform-docs ADR-093 for the full writeup.

1. Trust-install onboarding regression

auto-first-boot.sh's USB gadget README.txt/STATUS.txt generator had regressed the ADR-075 trust-install step (trust/install-trust.*) — never mentioned, omitted from the file listing — and leaked internal provisioning language ("TLS Status: TEMPORARY (run sign-device-cert.sh)") to customers. Every seed that had already completed first-boot carried this permanently, with no trigger to ever refresh it.

Fixed by extracting the generator into a new, idempotent update-gadget-docs.sh (doc-rev gated) embedded in the agent binary, so this OTA delivers the corrected README/STATUS to already-provisioned seeds via a one-time migration sentinel — no new SD image required. guide.html/open.html onboarding now leads with the on-drive trust/ installer instead of a manual ssh + cat ca.pem workaround.

2. Leaf certificate validity exceeded Apple's browser cap

Device leaf certs were issued at 1825 days (5 years), exceeding Apple's 825-day maximum for browser-trusted TLS — Safari rejected the certificate even after a user correctly installed and trusted the Device CA. Reduced to 825 days across every issuance path (cloud cert-signer, local-CA fallback, legacy manual provisioning), with expiry-aware renewal (openssl -checkend) added to auto-ca-cert.sh and the agent's existing 6-hourly OTA-check loop, replacing the previous unconditional skip.

Validation

• Host: cargo check clean, all 1051 existing unit tests pass; all modified/new shell scripts pass bash -n.
• On-hardware (cognitum-8b40): deployed the built binary, confirmed bootstrap_helpers() installed the new script + systemd unit and the migration fired — README.txt/STATUS.txt rewritten live, observed via the mounted USB drive; guide.html serves the corrected text; /api/v1/status healthy; the checkend-gated skip/renew logic validated against both the live cert and a synthetic near-expiry cert; a forced OTA loop iteration (POST /api/v1/ota/check-now) exercised the new renewal-check code path with no regression.

See also

• platform-docs ADR-093 (full investigation + design rationale, including why a public-cert/ACME path was evaluated and rejected for the primary USB flow)
• cognitum-one/mesh#7 (matching cognitum-cert-signer validity fix)

Cognitum Seed v0.22.19

Setup-AP stability fix for BCM43430/1 seeds, found while onboarding cognitum-3ffe over WiFi (2026-06-29). Binary-compatible with paired clients and existing cog manifests.

Fixed — Setup AP flapping on BCM43430/1 (seed#250)

On Pi Zero 2 W units with the BCM43430/1 WiFi chip, the first-run Cognitum-Setup-XXXX AP flapped — present in the WiFi list one moment, gone the next, and "not started" in the UI when caught mid-cycle. The API was honest (setup_wifi.active toggled per cycle); the AP genuinely cycled. Stable on BCM43436b0 seeds. Two compounding causes, fixed together:

1. Chip-aware AP mode (cognitum-setup-wifi.sh)

BCM43430/1's only AP-capable interface combination is #{ managed } <= 1, #{ AP } <= 1, … #channels <= 1 — AP and station must share one channel. While wlan0 scans/channel-hops, the driver tears the virtual wlan0_ap down (unmanaged-link-not-init). The old logic chose VIRTUAL mode because iw dev wlan0 interface add wlan0_ap type __ap succeeds (but the interface isn't sustainable).

Now setup-wifi.sh inspects iw phy interface combinations: if AP is only offered at #channels <= 1, it uses the exclusive AP path (hostapd directly on wlan0). BCM43436b0 (AP combo with #channels >= 2) keeps the concurrent virtual AP.

2. auto-mesh no longer flaps the Setup AP (auto_mesh_loop)

The mesh auto-formation loop stopped cognitum-setup-wifi.service after 3 client-less minutes to rescan for peer seed APs — tearing down the human-onboarding AP even on a lone seed with no peer to join. It now only abandons the AP to join if a peer seed AP (Cognitum-Setup-* or the configured custom prefix) is actually present in the pre-AP scan cache; otherwise it keeps the Setup AP up.

Validation

• Host: cargo check clean.
• On-hardware (cognitum-3ffe / BCM43430/1): AP comes up in EXCLUSIVE mode; auto-mesh logs no peer seed AP in scan cache — keeping setup AP up for onboarding; hostapd stays up (uptime 294s, no teardown); GET /api/v1/network/status → setup_wifi.active: true.

Cognitum Seed v0.22.18

V0 ↔ seed discovery + pairing fixes, found while testing seed adoption from V0 appliances on dev3 (2026-06-29). Binary-compatible with paired clients and existing cog manifests.

Fixed

mDNS discovery (seed#247, pairs with v0-appliance#250)

A live, reachable Wi-Fi seed (cognitum-c8ab @ 192.168.1.96) returned scanned:0 from a V0's "Discover seeds". Root cause: the seed advertised no mDNS service — /etc/avahi/services/ was empty. v0.22.18 bakes a _cognitum._tcp avahi service file into the image, so every seed is discoverable on the LAN (wlan0 + usb0) from first boot.

Adoptable after AP setup (seed#248)

A seed set up over its own Setup AP was discovered + reachable from a V0 but un-pairable — Pair returned 403 "pairing window can only be opened from localhost, USB, Setup WiFi AP, or with a valid Bearer token". Root cause: the setup wizard claimed the device with a throwaway setup-wizard pairing it never needed and never cleaned up, leaving an orphaned client that blocks V0 adoption. The wizard no longer creates that pairing, so the seed finishes setup unpaired and adoptable. (setup.html is bundled into the agent binary, so this ships in the v0.22.18 agent.)

Validation

• Host: cargo test + armhf cargo check (both PRs CI-green pre-merge).
• On-hardware: golden image flashed — seed advertises _cognitum._tcp and is adoptable by a V0 over WiFi without a manual unpair.

Cognitum Seed v0.22.17

Seed-side half of cognitum-one/v0-appliance#238: the proper RVF export contract endpoint so seed vectors reach the V0 aggregator store. Binary-compatible with paired clients and existing cog manifests.

Added — GET /api/v1/rvf/export (seed#241)

The V0 cognitum-rvf-aggregator pulls seed vectors via GET /api/v1/rvf/export?since=&limit=, expecting:

RvfExportPage { vectors: [{ id, embedding, meta }], next_epoch, total_remaining }

The seed never served that path → 404 every sync pass → seed vectors never reached the V0 store (confirmed live on a released-firmware seed over USB). The only existing surface, /api/v1/store/sync, was lossy — [u64,[f32]] tuples with no metadata.

This adds the contract endpoint with metadata + correct cursor paging:

• rvf_bridge.rs — RvfExportRecord { id, embedding, metadata } + records_since_epoch(since, limit) filtering write-epoch > since, sorted by (epoch, id), returning (page, total_matching, next_epoch).
• api.rs — GET /api/v1/rvf/export wired to the bridge, with since/limit query params.

Infrastructure — golden image now functional (seed#232)

Independent of the agent binary, the pi-gen CI golden-image build was repaired to match the live OTA fleet. Affects freshly-flashed images only; OTA-updated seeds are unchanged. Fixes:

• Trixie base — the agent is cross-compiled against glibc 2.39 (Debian Trixie); the image was being built on Bookworm (glibc 2.36), so the agent crash-looped with GLIBC_2.39 not found. Now RELEASE=trixie.
• Real agent binary — a cp -r was clobbering the cross-compiled agent with a Python reference stub.
• USB composite gadget — dwc2 + libcomposite modules, first-boot gadget.img build, and a first-boot reboot so the agent starts cleanly.
• Setup AP — bundle hostapd + dnsmasq (+ mask the stock services) so the Cognitum-Setup-XXXX AP broadcasts.
• SSH — genesis user is now /bin/bash + working password (was locked + nologin).
• Self-bootstrap — the cognitum-agent --bootstrap-helpers drop-in so the agent deploys its embedded helper units (gadget/usb-keepalive/usb-watchdog/auto-cert).

Validation

• Host: cargo test + armhf cargo check.
• On-hardware: golden image flashed to a Pi Zero 2 W — agent runs (Trixie), USB gadget enumerates (COGNITUM drive + 169.254.42.1 API), SSH works; GET /api/v1/rvf/export returns the paged contract.

Cognitum Seed v0.22.5 — Gold Image

Cross-platform onboarding stabilization release. Successor to the v0.22.4 gold image plus 4 code fixes uncovered during QE.

Downloads

What's new vs v0.22.4

• PR #150 — ADR-098/099 cross-platform onboarding (USB gadget DHCP for Linux zero-touch; first-run setup-AP + /setup wizard with captive portal; OTA-signing fix).
• PR #154 + cogs#19 — Tailscale Mesh VPN cog (ADR-100). Userspace-mode tailscaled runs as genesis, installable on demand from the cog store's new Network category.
• PR #162 (closes #161) — /setup wizard now stops the setup-AP before station-connect. Pi Zero 2 W brcmfmac chip can't reliably keep AP+STA on different channels — pre-fix the WPA 4-way-handshake silently failed with a misleading "no secrets" error. Wizard now stops AP, waits for connect, restarts AP on failure.
• PR #158 (closes #157) — Agent honors manifest executable: true for cog assets. Cogs shipping pre-fetched native binaries per ADR-095 §4 get +x at install time.
• PR #156 — Cog-store filter pills derive from live registry (v0.22.4 shipped with hardcoded "All 66", no Network category, mutually-inconsistent counts). Now self-healing as the registry grows.
• PR #156 — Gold-image sanitize step rewrite. v0.22.4 image shipped with bundled state from the source Pi: gadget-dhcp.leases (broke Mac DHCP for ~1h after every flash), mesh-config.json, measurements.json, update-log.json, ota-config.json. All wiped now. Post-sanitize assertion gate refuses to capture if state drifts.
• PR #159 / #160 / #163 — create-release-image.sh build-script fixes (case-pattern parse bug, dd-truncate to last-partition end, --sanitize-only flag for workstation-side capture).

Bundled cognitum-agent: v0.22.5

Binary sha 61b504cd1b3c22cca85d9d510a0f3517d6704ba9e70c29f9f5f59b5b77c15b1b (also published as the agent release at seed-v0.22.5 and live on fleet auto-update via gs://cognitum-apps/firmware/latest.json).

Image provenance

Image is xz-compressed, zerofree'd, partition-truncated — captured via the manual workstation-side flow (per PR #163's --sanitize-only) which produces ~50% smaller output than the in-script dd+gzip path. Raw .img would be 14.56 GB (just the partitioned region of a 29 GB SD card); xz output is 1.14 GB.

Quick install

Fresh SD card (Linux / macOS):

xz -d -c cognitum-seed-v0.22.5.img.xz | sudo dd of=/dev/sdX bs=4M conv=fsync status=progress
sync

Windows: Raspberry Pi Imager → "Use custom" → select the .img.xz directly.

First boot

1. Power on the Pi Zero 2 W (~30-45 s).
2. Join WiFi Cognitum-Setup-XXXX (XXXX = last 4 of fresh device-id), password cognitum.
3. Captive portal auto-opens http://192.168.4.1/setup.
4. Scan → pick your home WiFi → password → "You're all set". The AP self-tears-down (PR #162 fix) and the seed joins your network.
5. Reach the seed at https://cognitum.local:8443/ afterwards.

Or onboard over USB

Plug the seed's inner micro-USB into a host, wait ~30 s, browse http://169.254.42.1/guide.

• Linux gets DHCP automatically (ADR-098).
• macOS / Windows APIPA still works as before.

Verified

• ✅ cognitum-3ffe (Pi Zero 2 W, 29 GB SD): full v0.22.5 flash + boot + setup-AP + phone-wizard + station-connect + persistence over reboot.
• ✅ cognitum-8b40 (canary): sideload agent + mesh/witness/MCP regression sweep — all green.
• ✅ Fresh-flash on a different SD card: new device-id 4f6b5b0d-…-c9f1, gadget-DHCP from boot, setup-AP broadcasting, all 7 critical endpoints 200.

Known issues

• BCM43430/1 brcmfmac chip variant still falls back to exclusive AP mode (kicks station off) per #152. BCM43436b0 fleet works correctly with #162.
• framework.html Identity card 403 on AP-side paired phone (#151) — separate MCP auth issue, fix pending.

🤖 QE pairing session