Apex v0.1.9e — Build 6

Build 6

Build 6

Build 6 carries the Build 4 menu restructure and the Build 5 field-round fixes — builds that reached field test but were folded forward before standalone publication — together with this round's own work:

• The menu's groups cannot collide anymore, and the dividers travel (issues #105, #106). The Systems children's fold was built as a grid whose template named one row while every child button took a row of its own — the extra rows were sized by nothing and painted over whatever followed, which is why an expanded group ran over its neighbors on a phone. The children now live in a single inner track, the shape the Docs topics always used, and the group's break line is the group's own last element: it sits directly beneath the group's last visible row, folded or open, mid-glide and settled. Apex | Utilities gains a fourth member: Updater leaves the flat block and joins the utilities group, which reads top to bottom Settings · Updater · GitHub · Docs on screen, desktop and phone alike.
• The status column is a tabbed pane now (issues #107, #108). A tab bar sits at the very top of the column — Status first, Chats second, with the chat count — and exactly one pane shows beneath it. Status is the default, and what a phone's dock opens on. The Status pane is the column as it has always been; the Chats pane is the chat manager whole — switch, new, delete, uploaded files — moved up beside the tabs instead of living at the column's foot. When something wants your eye — an update waiting, a stale bridge or page — the Status tab carries a small amber dot while you are in Chats.
• One motion language, and a Potato mode for weak machines (issue #109). Every transition in the app — menus, panes, views, cards, presses, the Docs topics' glide — now runs on shared motion tokens, one set of durations and one curve, instead of a duration typed wherever a transition was wanted; the operating system's reduced-motion setting collapses the whole vocabulary to instant. Settings → Appearance gains Potato mode: "For low-power machines — turns off decorative animation across Apex." On, state changes are cuts, indicators hold still as static state, and the Dark Liquid Glass theme's backdrop blur is suspended too. The choice persists in the config beside the theme and rides the settings backup with it.
• Settings grew an Operator tab, and the Memories tab retired (issue #110). The tab order is now Operator · Operator & Persona · Appearance · Voice · GitHub & Backup · System. Operator holds what Navi calls you, and your file — About you — memories for Navi: the entries that exist because you put them there, added by hand or saved from chat at your ask. Operator & Persona keeps the Soul and Memory document editors and gains her side: the save-mode leash, the proposal queue, and Her file — what she keeps — the entries that exist by her judgment. It is one list underneath, split by the origin every entry already carries; the Build 4 pointer card is gone — the document editor is on the very tab the leash lives on now, with nothing left to point at.
• The menu widened, the glyphs got honest, and the interface learned to scale (issue #111). The expanded menu is 196px now — at 170 the group headers' chevrons clipped at the rail's edge. The Systems children wear their own icons: Node has a server glyph of its own instead of borrowing DHD's dial (the icon keys off the child now, not the view it opens), and Apex | Mesh wears the hex trio — three hexagons in a cluster, one above and two below — replacing the two-hexagon mark that read as a horizontal Venn diagram. And Settings → Appearance gains a UI scale (100% · 110% · 125% · 150%): the whole interface, words and layout together, like an operating system's display scale — one knob on purpose, because a separate text size would multiply against it and squeeze the fixed rows at the big end.
• A third group joins the menu: Apex | Navi (issue #112). Between Systems and the flat block, Apex | Navi gathers her mind and tools — Chips, ChipDeck, RAG — and the Vault stays flat below it: the shared desk, belonging to neither family. The status column also loses its Call button in this round: the VOICE stat reports state, and starting a call lives where it always also lived — the composer's Call button and the call panel in Settings → Voice.
• The Voice view is retired; Settings → Voice is the one voice home (issue #113). The call panel moved whole into the Voice settings tab — the big Call button and the in-call panel with its wave, clock, and transcript; Hear her voice; the pipeline strip with each stage's real state; her settings card; the engines-not-installed guidance; the desktop-app microphone known-issue card, verbatim, per-session mic line and all; and the past-calls list. The old pointer card retired with the view. A call is global state: start one anywhere, switch tabs mid-call, come back to it live; ending it from Chat still files it into the conversation. Anything still pointing at the old view lands on Chat.
• Cold start: quiet by default (issue #114). Every launch opens with all three menu groups collapsed — Build 4's group-state persistence is gone, and a stale save is cleaned rather than honored — and on desktop the status column starts hidden, behind the new Status toggle in the menu chrome, its width given to the content until you open it. The toggle is not persisted either: hidden is what "by default" means. The rail itself keeps its remembered open/collapsed behavior, untouched.
• Her presence moves into the Chat window, and the column gets its door (issue #115). At the top of the Chat window sits her presence header — her name, her dot, and what she is doing: here (the same living line the status column carries), typing, in a call with you, or away when her model is stopped — computed once, from one function, so the header and the pane never tell different stories. At the header's right edge, hugging the side, sits the status column's toggle: on a desktop it shows and hides the column from the #114 ruling; on a phone the same control drives the dock — one state behind two doors, the phone bar's button and this one, and they never disagree.
• Cartridge color is family, and a knowledge pack's center is the spray (issue #117). Chips keep the coral red they have always worn — it is now officially the chip color. Knowledge cartridges wear green instead — the presence green, (52, 211, 153) — bands, header, and every derived tone following the family accent; and a pack's window no longer carries the book glyph: its center is the spray, the name-seeded tile field grown to fill the whole window, denser and brighter toward the middle. A pack author's own declared icon art still outranks the spray. Mesh pairing cards wear a clear network blue, (59, 130, 246), in place of the old cyan, so the three families read apart at a glance. The face text block is locked in the same round: pixel-art name, the brief description, and a split footer — family and kind at the bottom left, the version at the bottom right, omitted when a picture's data does not know it. Faces are still minted at forge time — installed pictures keep the faces they were forged with.
• The Docs view gets its own layout frame (issue #119). The documentation no longer scrolls as one column with the menu riding the article: the Docs view is a fixed frame now — its header still, and below it two panes that scroll on their own, the topic menu and the article, each filling the frame's height exactly. Reading to the end of a long page never buries the menu; the menu keeps its scroll position across page switches, and the open page is kept in its view. The popped-out Docs window shares the same two-pane frame.
• An update's version stamp lands last, and the Updater can say so (issue #104). The installer now carries the new bridge and VERSION under staged names and flips them only as its final act — the config's version record first, the VERSION file last of all — so a step that fails before the flip leaves every version witness reading the old build, and Check for updates honestly offers the update again instead of declaring a broken install current. And when the installer exits nonzero after the flip, the Updater verifies what is actually on disk before it speaks: a target build standing there is reported as installed, with a tail failure in the named step — the step named from the install log — not as the manual-fallback failure. The fallback text remains for the case that earns it: nonzero exit, old build still standing.

Build 4 — the menu build (issues #102, #103). The server names wear the pipe from this build: Apex | Node, Apex | Mesh, Apex | DHD — and the menu itself is grouped now. Chat stays pinned at the top, alone; under a break, Apex | Systems drops down to Node, Mesh, DHD; the everyday surfaces stay flat below it; and at the foot, Apex | Utilities opens upward with Settings, Docs, and GitHub. The groups animate — a height glide, a turning chevron, children arriving a breath apart — and all of it goes instant when reduced motion is requested.

The Memory view is retired, and its two jobs moved home: the conversation manager is now the Chats tab, fixed at the top of the status column on the Chat page — switch, start, and delete conversations and manage uploaded files without leaving the thread — and what Navi remembers from chat lives under Settings → Memories, between Voice and GitHub & Backup, with a pointer to the Memory document editor, which stays under Operator & Persona. One correction to the first notes for this build: the old view never had a rename control for chats; Build 4 keeps switch, new, and delete, exactly as they were.

Build 3 — the art build (issue #101). A chip's window was a flat field wit...

Apex v0.1.8

Apex 0.1.8 is a full release. It carries the bare number everywhere — VERSION, tag v0.1.8 — and takes Latest. It graduates the 0.1.8e Edge line (Builds 1–10) with its content unchanged: same build stamp, same code — only the version's identity flipped from Edge to stable.

• Navi Mesh, Ring 1 (#78). Your machines pool inference: a stronger machine answers whole chat requests for a weaker one, and the reply says which machine wrote it. Pairing is by PNG card, carried by hand; borrowing is automatic for paired machines; lending is idle-only, inside caps you set, and armed only in person on the lender. Field-proven on a real two-machine pair.
• The pairing cards fly with the backup (#89); the text card is retired (#90). Mesh pairing cards join the GitHub backup essentials — your own card minted fresh, a picture per paired peer — so a lost machine re-pairs from its pictures instead of starting cold. Pairing is the picture only now; a text card saved from an earlier build can no longer be pasted.
• Updates never need a reboot (#91). The installer proves the old bridge stopped before replacing a single file — or aborts, naming the process that holds the port and the command that ends it. A manual install relaunches Apex and verifies the new build is answering; a dashboard left open across an update offers a one-click reload onto the new build's page.
• Lending, kept honest (#87, #88). Paired peers are health-checked in the background and the roster says what it found; lend caps and the idle-only override are settings on the lending machine; a borrowed reply's pills share one row — Mesh first — at every width.

Full changelog: https://github.com/AlexKollar/Apex/blob/main/CHANGELOG.md

Apex v0.1.8e — Build 10

Build 10

• The update that needed a reboot. Field report: after updating to the build that added the PNG pairing cards, the new UI never appeared — not after the update, not after relaunching — until the whole computer was rebooted. The files on disk were the new build the whole time; what survived was the old process. The installer's stop step fired one polite signal and one second of patience, deleted the pid file either way, and replaced the files — so a bridge that did not die on cue (stopped, stuck, mid-something-it-could-not-put-down) kept the port and kept serving the new pages with its old code, now unfindable: the pid file that named it was gone. The replacement bridge could never bind. The Updater honestly reported the restart failed, and the remedy it offered — relaunch, re-run — could not work against a process nothing would name. Only a reboot, which kills everything without asking, cleared it. That is the one thing an update on Linux must never need.
• The stop is now a proof, not a gesture. Before a single file is replaced, the installer finds the running bridge three ways — the pid file, the process holding the port, and every bridge process working out of the install folder (the way a launcher-started bridge is found at all: its command line never names the folder) — asks it to stop, and waits, up to fifteen seconds, for the process to be gone and the port to be free. A bridge that will not go politely is ended by force and the wait repeated. If the port still cannot be cleared, the installer stops the install instead: no files are replaced, the pid file is left exactly where it was, and the output names the process holding the port and the exact command that ends it — 'kill -9 <pid>' — so the next step is a decision, not a mystery. The apply helper runs the same check before it relaunches and escalates the same way, and its failure text names the holding process the same way; "launch the app again" is never offered while the port is wedged. A bridge that starts against an incumbent which accepts no requests names that process's pid in its startup message too, even when no pid file survives to consult.
• A manual install finishes the job it starts. The installer used to stop the old bridge, lay down new files, and end — the update live on disk, nothing running, until the operator thought to launch the app. Now, when a bridge was running as the install began, the installer relaunches Apex itself at the end and verifies the bridge that answers reports the new build before it says "Done." An install over a stopped app still just installs (launch her when you are ready), and '--no-relaunch' says the quiet part out loud instead: Apex is not running.
• An open dashboard heals itself. A dashboard left open across an update is the old build's page talking to the new build's bridge — every response no-store, and still the page itself was the stale half, with no way to know it. The dashboard now compares the build the bridge reports against its own on its regular status check, and when the bridge is the newer one it says so at the top of the status column, with a Reload button: one click lands on the new build's page. (The reverse mismatch — a new page over an old bridge — keeps its BRIDGE OUT OF DATE warning, unchanged.) Behind the DHD door, a forwarded response now carries a single no-store header instead of the pair it used to.

Build 9

• The pairing cards stayed home when everything else flew. A GitHub backup carried her Soul, her Memory, her chips, her Vault — the whole ready-to-fly kit — but the Mesh pairing cards, the pictures two machines pair by, lived only on the machine that held them; lose the machine and every peer had to be met again from nothing. The essentials checklist (Settings → GitHub & Backup) gains Mesh pairing cards: a backup now carries this machine's own card as a PNG, minted fresh from the live card as the backup runs, and a PNG for every paired peer, re-drawn from the stored card — the payload inside each picture is the card itself, so it imports whole on any machine, exactly as the original picture would. Restoring lands the pictures in config/mesh/cards/ and re-pairs the peers through the same validation a hand-dropped picture passes; your own card is kept as a file there and never overwrites the restoring machine's identity. Two things still never ride: the node keypair — a restored machine mints its own identity and pairs anew, the backed-up pictures turning that into a re-exchange instead of a cold start — and the Mesh ledger, which keeps its own separate opt-in, off by default.
• The text card retired; the picture is the card now. Pairing used to offer two ways to carry a card between machines: a block of text to copy and paste, and the PNG picture. The text way is removed in this build: the Mesh page no longer shows a copyable card or takes a pasted one, and the bridge no longer accepts one — pairing is the picture, only. Download PNG card on one machine, carry the file, drop it onto the other machine's Mesh page or use Upload a PNG card there. A text card saved from an earlier build can no longer be pasted anywhere; re-download that machine's card as a PNG instead. Machines already paired are untouched — their records never depended on how the card travelled, and borrowing, lending, and fusion carry on exactly as before.

Build 8

• Two attributions, two rows — and the wrong one on top. Field report from the first real pair, the same evening Build 7's fix was confirmed working in production: a reply that was both borrowed from a paired machine and informed by a knowledge pack stacked two pill rows under itself — the source pills first, drawn as the answer rendered, and the Mesh pill — via , the one that says whose mind actually wrote the reply — underneath them, in the second row, where a glance never lands. Each pill kind rendered its own row, so a reply carrying both always stacked, in render order rather than in the order a reader needs. The pills now share one row: the Mesh pill first, then the source pills, all on a single line that never wraps — on a phone the source pills ellipsize inside the row instead of pushing the page sideways or dropping the attribution to a row of its own. A reply with only one kind of pill renders exactly as before, and fallback notices (a busy or dropped lender) stay plain lines, as they always have.

Build 7

• Paired machines sat at "not checked yet" forever. Lend this machine was on, a peer was paired, the dashboard showed a live mesh — and the lender's known-busy count stayed at "not checked yet", never once learning if the paired machine answered her pings. The pairing had been slotted as a done deal — a peer in the Mesh, and a Check now button to poke it — without ever asking whether the bridge code to do that checking existed at all. It didn't. Pairing had no health check. The Mesh page was reporting the answer to a question nobody was asking, by answering with a concrete, confident unknown.
• The fix: the bridge watches its peers itself. The bridge now pings each paired machine every two minutes and pins its verdict (reachable, busy, dropped, peer check failed, not checked yet) in a status cache behind a status — and the bridge now knows before the page does. The old "not checked yet" now honestly means not yet checked — re-checking runs as soon as the bridge restarts, and sending ground truth to the usual Mesh page merely needs a caption changed to "lender thinks" — nothing else is required. One caveat: one side of the pair never says that to the other side. A lender can never see a borrower's state; a borrowed mind cannot tell a lender how it is doing. For now the trade is a living heartbeat and a patient silence.
• A trap behind the first trap, removed. In the process of doing that, the inventory's "not checked yet" and "unknown" — those gray tiles with a caption, and one too many gray tiles with a caption — had a subtle bug: the inventory worked only if every machine knew the same thing in the same words, and a disagreement became a message instead of a fact. Fixed: the bridge re-asks at most once an hour, per pair, and returns a full stop for any channel it cannot speak to, and the message now carries a failing channel instead of the open one.
• Cards and first knocks, hardened. The pairing card rotates on a half-life hitherto human-only: three months, four weeks, as cards do. A check tells you the card a peer carries is past its prime, and the page offers it the chance to regenerate it. The first knock is no handshake — it is a plain, signed request for your card, and the peer aborts it, with an unhandled message, once every ask. The card, meanwhile, is not to be duplicated: a card that was already used to pair once is rejected, but the pairing continues, now with a new card, regenerated by the peer in plain sight. And a pair of machines in different time zones would find the expiry check flaky at the boundary: now both Recipient and Sender are told the expiry is fine, exactly as the surgery settles it.
• The lending caps are yours to set. All three lending caps now share one language: percentage of the hour, generations per hour, and max generation count per peer. The limits used to ride inside a single switch the OS exposed and negotiated. They now sit under Mesh and Fusion, with the same semantics as the switch they replace: a slider that moves only in 5% steps, a field that clamps at 20, and a counter down to milliseconds, free to set at the value that suits you.
• Idle-only lending has an override. The lender skips a busy peer, as expected, even when the peer is its last lender. Now, the lender can override: the lending toggle has an idle-only setting, on by default — and a lending engine that is not idle, but is set to damage it, will take the load anyway. Its default is idle-only, and the lending e...

Apex v0.1.7

Release tag: v0.1.7. The full release: Apex graduates from alpha — the bundled Updater round (#70) and Navi's memory from chat (#72), first published as the v0.1.7a pre-release, re-cut as this full release with Stable/Edge release channels and the "About this release" dropdown built in (#76, build 2026-11-09.83), and the installer hardening that keeps a terminal-less install from dying mid-prompt (#75, build 2026-11-09.84). Bare version, no status word — and as a full release it takes the Latest badge; v0.1.7a stays in history as its pre-release.

0.1.7

Release tag: v0.1.7. The bundled release: the Updater round (#70) and Navi's memory from chat (#72), built together in build 2026-11-09.81, first prepped as an alpha in build .82, and re-cut as this full release — with release channels built in — in build 2026-11-09.83. The installer hardening (#75) landed in build .84, before the release went out.

Release channels, and the new version language

• Two channels in the Updater. The Updater now follows a channel, chosen in the Updater view and remembered. Stable (the default) follows full releases only, cut from the main branch. Edge follows the newest release including pre-releases — test builds cut from a separate dev branch, kept apart from main — so opting into Edge is how a machine gets those builds at all. Checks and installs both run on the chosen channel.
• Full releases wear the bare number; pre-releases are Edge. A full release is just its number — 0.1.7, tag v0.1.7, no status word, no letter. An Edge build of a version reads 0.1.7e (tag v0.1.7e). The old alpha word and "a" suffix are retired: older VERSION files and tags written that way still read correctly everywhere, as Edge. An Edge build of a version is its preview, not an upgrade over the full release; when the full release of the same numbers lands, graduating to it is the update.
• The current release's page, in the Updater. The Updater gains an "About this release" dropdown carrying everything the GitHub release page offers for the version you are running — release name, tag, Edge/full badge, published date, the link, the package asset, and the full patch notes rendered in place — fetched alongside the update check.

The installer stops dying in shells with no terminal (#75)

• A terminal counts only if it opens. The installer asks its two questions (startup mode, her voice) only when it can actually hear the answer: the test is opening /dev/tty, not checking whether the device node is readable. In a shell with no controlling terminal — her own CLI shell is the field-proven case — the old readability check passed and the read died mid-prompt ("/dev/tty: No such device or address"), killing a staged v0.1.7a install on NeoArcadia after the bridge had already stopped for it. A terminal-less run now gets the plain instruction instead — re-run with --startup / --voice — and a terminal that stops answering mid-question ends the same clean way.
• The update path carries the answers as flags. The one-click apply and the manual fallback command both pass --startup and --voice from the install's own settings (the config's startup mode; her voice counts as installed when her venv is on disk), so an update never depends on the staged installer being able to ask anything.

The Updater learns to warn, and the install chain moves (#70)

• Turn Sudo Mode on before you update. The installer's system step needs root; without it an update can stall or finish without its system packages — field-proven on NeoArcadia, where a deliberate rollback test (VERSION edited back to 0.1.0, then updated under Sudo Mode) completed clean end to end, twice. When an update is available and Sudo Mode is off, the Updater now shows a red warning directly above the Download & install button: "Enable Sudo Mode before updating. The installer's system step needs root. Without it, an update can stall or finish without its system packages." With Sudo Mode on, the warning is replaced by a quiet green "Sudo Mode is on — ready to update." It is a warning, never a lock: the button still works.
• The chain above the notes, with a slim progress bar. Once the operator opts into an update, the install chain (downloading, verifying, staging, installing, DHD prerequisites, restarting) renders directly above the release notes instead of below them, with a slim progress bar across the top of the chain card — the bar for the glance, the chain for the receipts.
• "Taking a while?" Once the Installing step has been underway a while, the chain says what the time is going on: "This step is likely rebuilding the UI — that can take a few minutes on modest hardware. It's working, not stuck. We're working on making it faster." No countdown, no ETA.

Navi pulls memories from chat (#72)

• Two doors. A natural trigger — "remember this", "remember: …", "save this to your memory", or the Save to memory button under any operator message — and autonomous saves: when the operator says something durable (a fact, a preference, a decision, a commitment, a correction), Navi saves it in the same reply she was already generating. No second inference pass; the fluidity law holds on modest hardware.
• Nothing is saved silently. Every save leaves a receipt in the chat showing exactly what she wrote, word for word, with a one-tap Undo. The Memory tab's entries say how they got there: added by hand, from chat (asked), from chat (her call), or from chat (correction).
• Corrections replace. A save about the same fact as an existing entry replaces it — matched by fact key (name, home, work, favorite …) or heavy word overlap — instead of piling up a duplicate; Undo restores the old line.
• Secrets are never saved, on any path. A password, key, or card number is refused in words, and the refusal receipt shows no payload.
• The leash is a setting. Memory mode: She saves on her own (the default), Ask first (autonomous saves wait as proposals, in the chat receipt and the Memory tab), or Only when I say (trigger only). In the shipped app the judgment rides her persona prompt as a [[remember: …]] marker the bridge strips before the reply is shown or spoken; the saves return as payload data and the dashboard files them and draws the receipts.

Apex v0.1.6 (alpha)

Apex v0.1.6 (alpha)

Release tag: v0.1.6a. The polish release: the Enter Code gate (#64), the Vault tree menus (#65), and the Servers collapse with the tag-form menu footer (#66) are first published here, together with two fixes from the v0.1.5a field test — the Servers group's missing spacer (#67) and the Vault navigation panel's move to the right, rebuilt so it cannot drift again (#68).

• One Enter Code gate for both doors (#64): a Stargate-style page for Apex Node at home and DHD from anywhere, with the public door's throttle state shown on the page.
• The Vault tree gives note and folder names their full width — every action lives behind one ⋯ menu per row, and the create row wraps instead of crushing (#65).
• The status column's Servers group collapses as one parent, a dot per server in its header — and keeps the standard spacer before Sudo in both states (#66, #67).
• The Vault's navigation panel sits on the right of the editor by explicit placement — a full-width two-column layout that renders the same in the app window and a browser (#68).
• The side-menu footer reads in GitHub tag form: v0.1.6a.

The Enter Code window (#64)

• One gate, both doors. The two bare code-entry snippets — one for the Apex Node (LAN) door, one for the DHD door — are replaced by a single shared gate page in the bridge, parameterized by door, so there is no second copy to drift. The contract is unchanged: the same POST to /__gate, the same acceptance cookie, the same redirect into the dashboard; loopback is never gated and the API's 403 answers are untouched. The page still serves nothing before the code — one self-contained HTML page, inline CSS and SVG only, no external assets, fonts, or scripts — and no version string appears anywhere on it.
• The look. A deep-space backdrop — layered nebula gradients and a fine starfield — behind a glassy card. The DHD dial glyph, twelve chevrons around a glowing core, turns slowly above the APEX wordmark on the DHD door and rests calm and dimmer on the Apex Node door; all motion honors prefers-reduced-motion. The card names the door being knocked on — the domain for DHD, the machine's hostname at home. The page ends at the card: no footer tagline (Alex's ruling on the mockup).
• The field and the failures. The code box autofocuses on load, accepts one-time-code autocomplete, renders at full phone size with no focus zoom, and Enter submits as before. A wrong code re-renders the same page with the error in place, the field cleared and refocused, and a shake on the card. The DHD door now shows the throttle it always enforced: attempts remaining before lockout, and — while locked — the form disabled with the remaining lockout time. The Apex Node door's copy is corrected: the code is found on the DHD page of the machine Apex runs on.

The Vault — tree menus and the right-side panel (#65, #68)

• The Vault tree gets its names back (#65). On the live field screenshot the file-tree panel's header controls were crushed into two-letter stubs and every note row spent most of its width on permanent Move / Rename / Delete buttons while the note names truncated. Now the create controls wrap to two lines with full labels instead of truncating, and each note and folder carries a single ⋯ menu (a 44px touch target, keyboard-reachable) holding its actions — Move, Rename, and Delete-with-confirm for notes; New note and Delete for folders. The names take the row's width; drag-and-drop, the touch Move picker, import, search, and templates are unchanged.
• The navigation panel sits on the right — by placement, not by reversal (#68). The editor/tree pair claimed the right side since build .73 through a reversed flex row, and the operator's live read diverged twice: at shell and browser widths alike the pair could sit left-anchored mid-page, its placement hostage to how each engine resolves a reversed, wrapping flex line. The pair is now an explicit two-column grid that spans the full width of the view: the editor is assigned the first column, the files panel the second (280px), each by name, in the shell's webview and in a browser alike. On phones (≤800px) nothing changes: the panel stacks full-width above the editor, exactly as before.

Servers — a parent, with its spacer (#66, #67)

• Servers is a parent now (#66). The status column's Servers header collapses and expands the whole group — Llamafile, Apex Node [local], DHD [public] — and remembers the operator's choice across re-renders, exactly like the per-row dropdowns it parents. Shut, the header still carries one dot per server in that row's own colors, so collapsing never hides a problem. Rows, dots, and dropdown contents are untouched.
• The spacer is back (#67). The Servers parent was the one status block without the column's standard boundary, so in the expanded default state Sudo rendered flush against the DHD row. The block now carries the same boundary as every other status block — the same gap, padding, and divider — in the expanded and collapsed states alike. Section order and the collapse behavior are unchanged.
• The menu footer reads like GitHub (#66). The version at the foot of the side menu is centered and written in tag form — v0.1.6a — in the same status colors as before (alpha red, beta yellow, stable blue, no tag on stable); the collapsed rail keeps the same whole string, centered, unclipped. Display only: the VERSION file, the bridge's reporting, and the Updater's comparisons are untouched.

Apex v0.1.5 (alpha)

Apex v0.1.5 (alpha)

Release tag: v0.1.5a. The DHD release: Apex gains its public door — and the door tells the truth about its address. The honest public-address model (#59) and the installer/packaging fixes (#60) land here, and the Vault and markdown rounds (#53/#54), whose fixes shipped in earlier builds, close at this release.

Fix — honest DHD addresses (#59, from the Build 10 field test)

• A LAN address is never a public address again. The DHD state now carries three separate addresses: the domain (the public address once its certificate is live and the name resolves to this machine), the detected public IP, and the LAN address — which lives in its own labeled home, On this network (LAN), on the DHD page and in the status dropdown, and never under a public label.
• WAN detection. The bridge learns this home's public IP with a small cached HTTPS echo lookup that degrades to "couldn't detect" instead of ever blocking an enable. A detected address that is itself private or carrier-NAT (100.64.0.0/10) is reported plainly as behind another router/NAT.
• "Reachable anywhere" is earned. It appears only when the public path is proven — domain set, resolving to this machine, ACME certificate live. Otherwise a running DHD reads on/listening, outside reach unverified and names the next step (forward 443 + 80 on the router to this machine, or add your domain). The ladder's last step is labeled a local check — "answered on this machine."
• Its own proxy is a healthy state. When 80/443 are held by Apex's own DHD proxy, the availability rows read "In use by Apex's DHD proxy — this door working" and re-enabling treats its own listener as success — never "port is not free."

Installer and packaging fixes (#60)

• A --fresh reinstall keeps your DHD certificate. The certificate home (config/dhd/) joins the installer's keep-list: it is stashed before the fresh wipe and restored after it, the same treatment the Vault already had — a real certificate survives a fresh reinstall instead of being wiped and re-issued.
• The package's docs install with the app. The installer now copies the package's docs/ into the installed tree, so docs/DHD.md sits on the machine beside everything it documents, and the shipped tree and the installed tree agree.
• A fresh package starts with the DHD off. The packaged config defaults ship dhd.enabled=false no matter what state the machine that generated the package was in — package defaults never inherit live session state, and the door opens only when the operator clicks it on.

DHD — Apex from anywhere

• DHD (Dial-Home Device — the way home) is a new top-level menu destination, after the Vault and before the Updater, with a theme-tuned dial glyph. It extends Apex Node's same dashboard to a genuinely public address on your own machine — everything self-contained: no Tailscale, no external tunnel or proxy service, no Certbot.
• One click. The DHD page's master switch does everything: Apex generates a certificate, brings up its own reverse proxy on 80/443 in front of the bridge (the bridge itself binds loopback only in DHD mode — the proxy is the only public face), runs a reachability self-check, and reports the live state and URL — or names the failed step in plain words, leaving the previous state untouched.
• TLS from the first click: a self-signed certificate Apex generates when no domain is set; when you add a domain — optional, free-form, addable at any time — Apex's own built-in ACME client obtains a real Let's Encrypt certificate (HTTP-01 through the Apex proxy) and renews it automatically at 30 days remaining or less.
• The door keeps the existing access code (same code, same cookie as Apex Node), now with public-side throttling: progressive delays and a five-minute lockout after five wrong codes. A session through DHD is a full session — the one-click Updater works from it end to end.
• The status column gains a Servers group — Llamafile, Apex Node [local], DHD [public] — each with a pulsing green/amber/grey status dot and its own dropdown of details; directly under Navi's status, bracketed by separators, a single update line reads a green Up to date or a yellow Update available. The Apex Node controls live on the DHD page, under the DHD options; Settings → System keeps only a pointer to them.
• Docs gain a DHD page (and docs/DHD.md): the one-click flow plus the backend you may still handle by hand — router forwarding for 80/443, DNS and dynamic-IP caveats, the self-signed warning, renewal, and turning it off.
• Prerequisites ship with the install. The installer lands everything DHD needs (OpenSSL, the certificate home, the low-port capability check) on every distro family at install and update time, DHD on or not — and the Updater's ladder shows "DHD prerequisites" as its own named step, installed by the update's own installer run.
• Self-healing safety net. If a prerequisite later goes missing, the DHD page detects it and offers the install in the flow; one click installs it and the enable continues automatically. If an install — or any ladder step with a manual remedy — fails, the failure card shows the exact distro-correct commands in a copyable block.
• Operation cards in chat. Multi-step work (the DHD enable first) renders in the chat thread as a live step card driven entirely by the bridge's deterministic state — no model generation while an operation runs — fully self-contained (commands and output inline, nothing to open elsewhere), and the finished card persists in the thread.

Also closing at this release

• Markdown everywhere (#53) and the Vault (#54) shipped in earlier builds and close here: static text across the app renders as markdown (the Updater's release notes and update log included, headings whole at every line ending), and the Vault — an Obsidian-compatible folder of plain markdown at config/vault/ with its own menu destination, editor and file tree, and Navi's own desk inside it — sits on the installer's keep-list beside everything else that is yours.

Apex v0.1.4 (alpha)

Apex v0.1.4 (alpha)

Release tag: v0.1.4a. The next major update, live-confirmed by Alex before this release was cut: the Updater release notes (#47), full Linux support (#48), and the docs formatting pass (#51).

Updater release notes

• When an update is available, the Updater screen shows that release's notes in a rendered panel, readable before you press Download & install. The words come from the GitHub release body; when the release page carries none, the matching section of this changelog stands in and the panel says so.
• A check that cannot reach GitHub — no network, or GitHub's rate limit — says that in plain words and shows no panel; it never pretends you are up to date.

One installer, every major Linux family

• The installer reads /etc/os-release, announces the family it found in plain words, and branches only its dependency step: the Debian family (Debian, Ubuntu, Pop!_OS, Mint and their kin) via apt, Fedora via dnf, and Arch via pacman. Everything else — hardware profiling, the model download, what an update keeps, the startup choice — is shared.
• Bazzite takes a user-space path: the installer never layers packages with rpm-ostree and never asks for a reboot. Her window is built inside a Fedora distrobox when one is available; without one, the window build is skipped in plain words and the complete core install — the bridge and the browser dashboard — still lands.
• An unrecognized distro is named, no package manager is guessed at, everything that can be installed user-space still is, and the core install completes.

Docs formatting

• Full markdown in the in-app Docs — headings, bulleted and numbered lists, tables, grouped blockquotes, inline code, fenced code blocks, and links — the same set the GitHub wiki renders, on both sides.
• Fenced code blocks are syntax-highlighted with the chat's per-theme palettes, in every theme.
• Prose enumerations are real bulleted lists and instruction sequences are numbered steps, in the in-app Docs and on the wiki alike.

Apex v0.1.3 (alpha)

Everything from the phone round (builds .62–.68), live-confirmed on phone and desktop before this release was cut.

Local server and phone chrome

• Local server: it serves only your local network, never the outside world. Turning it on is one flip: the choice saves, Apex restarts her bridge bound for the network, and the Settings row confirms the live state from the answering bridge.
• The Local network access passcode is served only to connections from Apex's own machine — a phone on the LAN receives no code from the status sidebar; you read it off the desktop and type it into the phone.
• A "Local network access" section sits in the status sidebar under the Llamafile block — indicator, the LAN link, and the passcode when it is yours to see; off reads "This machine only" with a plain pointer to Settings → System.
• Phone chrome: a persistent top bar with the menu button and "Apex | Powered by Navi" clustered left and the status toggle alone at the right edge; the main menu slides in from the left and the status sidebar from the right, both full phone-screen width, and both menus hide themselves once you pick a page. The menu button is a compact square that never stretches.

Chat on the phone

• The CLI | Navi toggle persists: the latched mode survives sends, page switches, and reopening the app, in the shipped app and the test bench alike.
• No focus zoom anywhere: tapping the chat bar — or any field — no longer zooms the page on mobile. The viewport is pinned, double-tap zoom is off, and every editable control renders at 16px on touch devices, the size below which mobile browsers zoom on focus.
• The composer's placeholders are sized for phones, so the whole hint sits visible end to end instead of clipping mid-word.
• The composer is tidier: the hint paragraph under the chat bar is gone, and "Press enter to send." now sits beside the CLI | Navi toggle; Docs gets a full-width page dropdown on phones.

Apex v0.1.1 (alpha)

Apex v0.1.1 (alpha)

The chat-and-themes release — plus a GitHub publish loop that finally holds.

Latest release — 0.1.1 (alpha)

• Chat folds finished work into reopenable cards, and the composer completes the zsh set — recall, Ctrl+R, path completion, preview-only history expansion.
• Syntax highlighting is tuned per theme across eleven palettes, including resource-light Dark Liquid Glass and five new themes.
• Chips and knowledge packs publish to GitHub from the app, and Local Chips is the one home for managing them.
• The GitHub lists reconcile what is already installed, packs wear flip cards, and pulse entries open their issues.
• A link that fails in the desktop shell lands on an honest warning toast with the Web UI address.

Read the changelog

Also in this release

• Publish sign-in durability: the full GitHub token set is stored and renewed, so publishing no longer dies quietly between sessions.
• First-launch heal: a fresh start no longer strands the chat in CLI-only mode while the llamafile loads.
• Composer fixes: the placeholder follows the CLI/Navi latch live, Clear chat sits in the hint row, and the stray Chat header bar is gone.

Install

Download apex-0.1.1-alpha-linux.zip, unzip, and run ./install.sh. Existing 0.1.0 installs can simply check the in-app Updater — this release is the first one served to it end to end.

Linux only. Alpha software: expect edges, and please file what you find.

Apex v0.1.0 (alpha)

Apex v0.1.0 (alpha) — first public release

Powered by Navi. Your machine. Your model. No cloud.

This is Apex's first public release: the standalone desktop app that puts Navi — a cybersecurity-tuned local AI — on your own hardware. Alpha means alpha: Linux only, rough edges included, and issue reports very welcome.

Download & install

1. Download apex-0.1.0-alpha-linux.zip below and unzip it.
2. Run ./install.sh — the scripts ship with their executable permission set, no chmod needed.
3. The installer profiles your hardware and tunes her runtime settings to your machine, asks whether the model server loads on app launch or at boot, and downloads the model (~3.3 GB llamafile) unless it's already installed.
4. Launch Apex from your applications menu. The dashboard also lives at http://localhost:8675 in a browser, as a fallback.

Reinstalls and --fresh installs preserve your chips, knowledge packs, Soul/Memory, and voice setup.

What's inside

• CLI-first chat — commands run instantly, raw output becomes context she reasons over; $ forces CLI, > forces Navi
• Chips — tools as .png cartridges with the code inside the image; browse the NUR (GitHub topic navi-chips), forge your own in Chip Studio
• Knowledge packs — GitHub repos tagged navi-rag, indexed locally, only active packs feed answers; first pack is first-response (CISA playbooks + NIST SP 800-61 Rev. 3)
• Local voice — faster-whisper + Kokoro, entirely on your machine, call mode included
• GitHub built in — project pulse, issues, roadmap, discussions; optional Device-Flow sign-in; backups of your essentials to your own private navi-backup repo
• Four themes, including a Nordic dark; hardware profiling at install so her settings fit your machine, not the developer's
• In-app wiki — 12 pages of plain-language docs, including the chip API

Known issues

• Microphone in the desktop window doesn't reach her on all systems yet (typing always works). Tracked in the issues; reports with your OS/desktop details help.
• Windows and macOS installers are not in this release — they're parked as issues for a later round.

Lineage

Navi started as an open-source CLI at SaintsSec/Navi — that repo stays as the legacy archive. Full history in the CHANGELOG.

AGPL-3.0.