Phase 8c: drizzle and better-sqlite3 out, one node:sqlite connection, no native module #15

Merged

alex merged 134 commits from refactor/phase-8c-sqlite into refactor/phase-8a-routes-columns 2026-10-29 18:46:29 +01:00

Conversation 0 Commits 134 Files changed 1124 +25808 -29619

alex commented 2026-10-08 11:53:41 +02:00

Owner

Copy link

Phase 8, step c, of the DDD/CQRS refactor: drizzle and better-sqlite3 leave Kanbot. All database access now goes through one connection to Node's built-in node:sqlite, and the desktop bundle no longer contains any native module. Stacked on #14.

What changes

Plain SQL instead of drizzle's builder

• server/database/sql.ts (all, get, run, inTransaction) is the only legacy file that touches the driver. It caches prepared statements and copies rows into plain objects.
• inTransaction behaves like better-sqlite3's .transaction(): BEGIN/COMMIT on its own, a savepoint inside another transaction (a legacy one or an Effect command's), and a rollback before rethrowing.
• Each table's columns are declared once in server/database/tables/<table>.ts, with field names, order, JSON and boolean handling exactly as drizzle mapped them. statements.ts has the insert/update/upsert/delete helpers.
• New test test/infra/tableRows.test.ts: every column the database has must be declared, and every field of every table must survive a write and a read. That closes the "a new field is stored but read back empty" trap for rows.

Migrations without drizzle

• runMigrations() runs only Kanbot's migrator. Its first migration, 0001_legacy_handover, already applies the drizzle-era migrations from the now-frozen legacy.generated.ts.
• A fresh database comes out with the same schema as before; only the whitespace of drizzle's ledger table's CREATE differs.
• Removed: server/database/schema.ts, server/database/migrations/, drizzle.config.ts, the generator script, db:generate, and KANBOT_MIGRATIONS_DIR (from the server, Electron, tests and the packaged app's resources).
• One change for very old installs: drizzle's table-rebuild migrations now run inside Kanbot's migrator with foreign keys off, as #14's rebuild does. drizzle ran them with keys on.

One node:sqlite connection

• DatabaseSync with WAL, foreign keys on, a 5 s busy timeout, plain-object rows and numbers rather than BigInts. Effect's SqlClient (SharedSqliteClient, with its guard against yielding inside transactions) runs on the same connection.
• No experimental warning on Node 24.19 or on Electron 44's Node 24.20.
• Nitro now treats node:sqlite as external, which silences a "could not be resolved" build warning.

Packages removed: drizzle-orm, drizzle-kit, better-sqlite3, @types/better-sqlite3 and @electron/rebuild. desktop-prepare no longer trims prebuilds, and now fails if a .node file ever appears in the server bundle.

Checks

• 962 tests, lint, typecheck, Storybook, and a Nuxt build with no warnings.
• No test expectation changed. Test plumbing moved to the new helper and to node:sqlite. sqliteLocks.test.ts keeps what can still be tested: two node:sqlite connections respect a held lock, and better-sqlite3 stays uninstalled.
• Real data: a copy of the real database with secrets stripped first (the Discord setting, connections, plugin secrets; running tasks moved to backlog), booted with the base build and with this one, each on its own copy.
  • 98 reads compared: every Electron REST route, plus RPC for tasks, time, the timesheet, reports, standups, views, projects, machines, workflows, settings and notifications.
  • 97 were byte-identical. The other differs only in Machines.list's lastSeenAt, which is boot time.
  • After boot, the schema, the row counts in every table and the contents of the task-related tables were identical, and integrity_check passed.
• Desktop:
  • macOS: electron-builder --mac --dir and desktop-verify passed.
  • The packaged server, run through Electron's Node, booted and answered /api/status, /api/tasks, /api/projects and RPC.
  • The Windows cross-build passed.
  • Neither bundle contains a .node file.

Not done

• Hardened runtime stays off. The native module that was why it was off is gone, but turning it on is untested.
• The Windows app still hasn't run on Windows. There is still no Forgejo runner.

🤖 Generated with Claude Code

Phase 8, step c, of the DDD/CQRS refactor: drizzle and better-sqlite3 leave Kanbot. All database access now goes through one connection to Node's built-in `node:sqlite`, and the desktop bundle no longer contains any native module. Stacked on #14. ## What changes **Plain SQL instead of drizzle's builder** - `server/database/sql.ts` (`all`, `get`, `run`, `inTransaction`) is the only legacy file that touches the driver. It caches prepared statements and copies rows into plain objects. - `inTransaction` behaves like better-sqlite3's `.transaction()`: `BEGIN`/`COMMIT` on its own, a savepoint inside another transaction (a legacy one or an Effect command's), and a rollback before rethrowing. - Each table's columns are declared once in `server/database/tables/<table>.ts`, with field names, order, JSON and boolean handling exactly as drizzle mapped them. `statements.ts` has the insert/update/upsert/delete helpers. - New test `test/infra/tableRows.test.ts`: every column the database has must be declared, and every field of every table must survive a write and a read. That closes the "a new field is stored but read back empty" trap for rows. **Migrations without drizzle** - `runMigrations()` runs only Kanbot's migrator. Its first migration, `0001_legacy_handover`, already applies the drizzle-era migrations from the now-frozen `legacy.generated.ts`. - A fresh database comes out with the same schema as before; only the whitespace of drizzle's ledger table's `CREATE` differs. - Removed: `server/database/schema.ts`, `server/database/migrations/`, `drizzle.config.ts`, the generator script, `db:generate`, and `KANBOT_MIGRATIONS_DIR` (from the server, Electron, tests and the packaged app's resources). - One change for very old installs: drizzle's table-rebuild migrations now run inside Kanbot's migrator with foreign keys off, as #14's rebuild does. drizzle ran them with keys on. **One node:sqlite connection** - `DatabaseSync` with WAL, foreign keys on, a 5 s busy timeout, plain-object rows and numbers rather than BigInts. Effect's `SqlClient` (`SharedSqliteClient`, with its guard against yielding inside transactions) runs on the same connection. - No experimental warning on Node 24.19 or on Electron 44's Node 24.20. - Nitro now treats `node:sqlite` as external, which silences a "could not be resolved" build warning. **Packages removed:** drizzle-orm, drizzle-kit, better-sqlite3, @types/better-sqlite3 and @electron/rebuild. `desktop-prepare` no longer trims prebuilds, and now fails if a `.node` file ever appears in the server bundle. ## Checks - 962 tests, lint, typecheck, Storybook, and a Nuxt build with no warnings. - No test expectation changed. Test plumbing moved to the new helper and to node:sqlite. `sqliteLocks.test.ts` keeps what can still be tested: two node:sqlite connections respect a held lock, and better-sqlite3 stays uninstalled. - **Real data:** a copy of the real database with secrets stripped first (the Discord setting, connections, plugin secrets; running tasks moved to backlog), booted with the base build and with this one, each on its own copy. - 98 reads compared: every Electron REST route, plus RPC for tasks, time, the timesheet, reports, standups, views, projects, machines, workflows, settings and notifications. - 97 were byte-identical. The other differs only in `Machines.list`'s `lastSeenAt`, which is boot time. - After boot, the schema, the row counts in every table and the contents of the task-related tables were identical, and `integrity_check` passed. - **Desktop:** - macOS: `electron-builder --mac --dir` and `desktop-verify` passed. - The packaged server, run through Electron's Node, booted and answered `/api/status`, `/api/tasks`, `/api/projects` and RPC. - The Windows cross-build passed. - Neither bundle contains a `.node` file. ## Not done - Hardened runtime stays off. The native module that was why it was off is gone, but turning it on is untested. - The Windows app still hasn't run on Windows. There is still no Forgejo runner. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

alex added 5 commits 2026-10-08 11:53:41 +02:00

The legacy code reads and writes through plain SQL, not drizzle's builder ... 5cfd2409f1

Phase 8c replaces drizzle and better-sqlite3 with node:sqlite. The first
half is getting every query off drizzle's query builder, so the driver
underneath can change in one place.

- server/database/sql.ts: all/get/run with positional parameters over the
  shared connection, and inTransaction, which opens a transaction outside
  one and a savepoint inside one (a legacy write called from a command's
  transaction), as better-sqlite3's .transaction() did. It is the only
  file that knows the driver.
- server/database/table.ts and tables/: one descriptor per table, with the
  fields in drizzle's order and how each is stored (JSON, 0/1 booleans).
  Rows decode to the same objects drizzle produced, so the task JSON and
  the Electron routes stay byte for byte; statements.ts holds the
  select/insert/update/delete-returning shapes the stores repeat.
- taskRows.ts keeps the task's parts as SQL subqueries (TASK_COLUMNS) and
  composes the task as before.
- The infra tests replay drizzle's migrations from the same snapshot the
  handover uses (test/support/sqliteFile.ts) instead of running drizzle;
  checked against drizzle's own migrator before it goes.
- tableRows.test.ts: every column the database has is declared, and every
  field survives a write and a read, so a new column cannot read back
  undefined unnoticed.

drizzle's migrator and schema.ts are still there; the next commit removes
them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Drop drizzle: Kanbot's migrator alone brings a database up to date ... 7526fc450b

With no query left on drizzle, its migrator was the last thing boot ran
from it. Kanbot's 0001_legacy_handover already applies whichever of
drizzle's migrations a database lacks, from the snapshot in
legacy.generated.ts, and records them in drizzle's ledger, so
runMigrations() now runs only Kanbot's migrator.

A fresh database comes out with the same sqlite_master as before
(compared table by table; only the whitespace of the ledger table's own
CREATE differs), and the migration tests cover a database drizzle
migrated, a fresh one and one stopped at drizzle's twelfth migration.
One difference for an old install: drizzle's recreate migrations now run
inside Kanbot's migrator, with foreign keys off, where drizzle ran them
with keys on.

Gone with it: server/database/schema.ts, drizzle-kit's migrations folder
and config, scripts/gen-legacy-migrations.mjs (the snapshot it wrote is
now the only copy, frozen), the db:generate script, KANBOT_MIGRATIONS_DIR
(server, Electron shell, tests) and the migrations the desktop app
shipped as extra resources. drizzle-orm and drizzle-kit leave
package.json.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

One SQLite connection on node:sqlite: better-sqlite3 leaves ... ca01bf36e4

The shared connection is now Node's built-in DatabaseSync. The legacy
code reaches it through server/database/sql.ts and Effect through
SharedSqliteClient, still one connection, so the rule that a transaction
holds SQL only (and the client's guard against the scheduler yielding
inside one) stands unchanged; sharedSqlite.test.ts still shows the guard
is needed.

What differs from better-sqlite3, and how it is met:
- Rows come back with a null prototype; both sides copy them into plain
  objects, so readers and strict equality see what they saw before.
- Integers read as numbers and rows as objects (readBigInts and
  returnArrays off, said explicitly); SafeIntegers maps to setReadBigInts.
- No .pragma(), .transaction(), .reader or .raw(): pragmas go through exec,
  transactions were already ours (inTransaction), a statement returns rows
  when it has result columns, and returnArrays stands in for raw mode.
- The busy timeout defaults to 0; it is 5 s, as better-sqlite3's was.
  Extensions stay off.
- Errors carry SQLite's numeric code (errcode) rather than a string code;
  effect/sql classifies either.
Node 24.19 and Electron 44's Node 24.20 print no experimental warning for
node:sqlite. Nitro's bundler does not list node:sqlite as a built-in, so
it is named external in nuxt.config.ts instead of being warned about.

better-sqlite3 and its types leave package.json. sqliteLocks.test.ts,
which showed two SQLite copies in one process ignore each other's locks,
now pins that two node:sqlite connections do respect one and that
better-sqlite3 stays uninstalled. The lint boundaries name node:sqlite
where they named the old driver.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The desktop bundle has no native module: drop what packaged one ... d37aa69959

With SQLite built into Node, the server bundle carries no .node file, so
one .output runs on every platform:
- desktop-prepare no longer keeps one better-sqlite3 prebuild per target
  (its --platform/--arch arguments are gone, and desktop:build:win stops
  passing them); it now fails the build if a .node file ever appears in
  the bundle, since that would load on one platform only.
- @electron/rebuild leaves devDependencies; nothing called it
  (electron-builder runs with npmRebuild: false and keeps its own copy).
- electron-builder.yml and the README stop describing a native SQLite
  module. Hardened runtime stays off as CLAUDE.md requires; its comment
  says the reason it was off (library validation refusing the .node) is
  gone but turning it on is untried.

Checked: the macOS app (electron-builder --mac --dir) passes
desktop-verify and its bundled server boots under ELECTRON_RUN_AS_NODE on
Electron's Node 24.20 and answers /api/status, /api/tasks and RPC; the
Windows x64 build (--win --x64 --dir) cross-builds from macOS. Neither
bundle, nor either app.asar, contains a .node file.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md: one node:sqlite connection, migrations without drizzle, no native module ... 7c6cc57492

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

alex referenced this pull request 2026-10-08 12:31:39 +02:00

Phase 8d: npm workspaces, a publishable plugin SDK, a core with declared dependencies only #16

alex added 129 commits 2026-10-29 18:46:22 +01:00

The core owns the types and the workflow graph it shares with the app ... 22cb977d1e

packages/core reached into shared/types and shared/workflows by relative
path some fifty times, and shared/types reached back into the core's
schemas, so the two were one module graph split across folders. Before the
core can become a package with declared dependencies, one side has to own
them. The core uses them, so it does: shared/types moves to
packages/core/src/types (a module open to every context, like the kernel)
and shared/workflows to the workflow context's graph/. shared/types and
shared/workflows stay as barrels re-exporting them, so `#shared/types`,
`#shared/workflows` and Nuxt's auto-imports read the same names as before.

WorkflowWithUsage stays in shared: it is the contracts' WorkflowView, and
the core may not depend on the contracts.

Two leftovers of the same kind go too: execution reached into board's
errors/ instead of its schemas, and the server took McpServerConfig from
the Claude Agent SDK, which belongs to the claude-code plugin.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

npm workspaces: every package and plugin declares what it depends on ... 36438c8bbd

packages/{core,contracts,infra-sqlite,plugin-sdk} and plugins/* become
workspaces (@kanbot/core, @kanbot/contracts, @kanbot/infra-sqlite,
@kanbot/plugin-sdk, @kanbot/plugin-<id>), each with the dependencies it
imports and nothing else: effect pinned at the repo's exact version, the
workspace packages as "*" (npm links a workspace whose version satisfies
the range; it has no workspace: protocol). Only the SDK is not private.

The plugins take effect and the SDK as peers: the host supplies the one
copy of each, which is also what a prebuilt plugin bundle leaves external.
zod and the Claude Agent SDK leave the root for @kanbot/plugin-claude-code,
the only code that imports them. A plugin's package version is its
manifest's.

Each package's exports point at its TypeScript sources: the app, Nitro,
vitest and Storybook compile them as they did, through the workspace
symlinks. Imports still use relative paths; the next commit switches them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Imports across packages by name; lint keeps them there ... 45380e0f05

Every import that crossed a package boundary by relative path, about nine
hundred of them, now names the package: @kanbot/core/<context> for a
context's index, @kanbot/core/<context>/schemas for its browser-safe
face, @kanbot/contracts/<context>, @kanbot/infra-sqlite/<module>,
@kanbot/plugin-sdk and /testing, @kanbot/plugin-<id>. Each package's
exports map lists exactly those entries, so the context boundaries are
the resolver's now, not only ESLint's: a deep import does not resolve.
Inside the core, contexts reach each other the same way (the package
importing itself), which is what lets lint hold a relative import inside
its context; the one that did not (execution reaching into board's
errors/) went in the previous commit.

The core's types/views.ts goes back to shared: SavedView carries the
board's filter, which is shared/filters' and which the core never reads.

Two ESLint rules (scripts/lint/packageBoundaries.mjs) do what
no-restricted-imports cannot, since they depend on where the importing
file is: kanbot/relative-imports (a relative import stays in its
package, in its context inside the core, and the app never reaches into
packages/ or plugins/ by path) and kanbot/declared-dependencies (a
workspace imports only what its package.json declares and Node's
built-ins). The latter replaces the per-plugin regex of allowed packages,
which package.json now says. The per-context patterns match package
specifiers, and now cover the app, shared and Storybook too.

gen-plugins resolves the plugins and the SDK as packages. esbuild's
`packages: 'external'` would leave @kanbot/* outside the bundle, as
TypeScript Node cannot run, so scripts/pluginBundle.ts compiles them in
and leaves the rest outside. `npm run build:plugins` also writes each
plugin as it would be published (plugins/<id>/dist: one ESM bundle with
its peers, effect and the SDK, left to the host). gen-plugins checks a
plugin's package name and version against its @Plugin.

Nitro inlines @kanbot/* (nitro.externals.inline): it does already, as
their real paths are outside node_modules, and now it is a rule. The
built server has no .ts file, no symlink and no @kanbot package.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@kanbot/plugin-sdk is publishable to the Forgejo npm registry ... 742989c302

Outside plugin authors install the SDK from Forgejo's npm registry
(publishConfig.registry; README "Installing the SDK": the @kanbot scope
line for .npmrc, peers, versions, decorators, the test kits, and how a
plugin is bundled for publishing).

The build is tsc alone (tsconfig.build.json, NodeNext): ESM .js and .d.ts
in dist/, file for file, so the main entry and ./testing share one module
graph and one metadata registry, which two bundles would not. No new
dependency: a bundler would also need a declaration bundler to give
consumers types they can resolve. The sources import each other as
'./X.ts', which tsc rewrites to './X.js' (rewriteRelativeImportExtensions)
and scripts/build.mjs rewrites in the declarations, where tsc leaves it.

In the repository, exports still point at src/, so Vite, vitest, Nitro and
vue-tsc read the SDK as it is, with no build step and no custom resolve
condition to keep in step across them. npm has no per-publish exports, so
prepack builds and swaps in the published manifest (exports to dist/, no
scripts or devDependencies) and postpack restores the workspace's. The
tarball holds dist/, the README and package.json.

Peers: effect at the exact release Kanbot ships, since Effect 4 is still a
release candidate whose APIs change between candidates and the host
supplies the one copy (a second would not recognise its services and
Schemas); a range once Effect 4 is stable. @effect/vitest, which the test
kits import, is an optional peer, so the main entry never brings a test
runner. The version is 1.0.0: its major is API_VERSION, which a test now
holds, with the plugins' peers.

Checked outside the repository: a scratch project installs the packed
tarball with effect@4.0.0-rc.118, compiles a @Plugin + @TrackerType class
with tsc (NodeNext and Bundler, experimentalDecorators, skipLibCheck off)
and reads its manifest; the prebuilt redmine and discord bundles load
against the same SDK.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CI packs the SDK as it would be published ... 26faa7be32

npm ci installs the root and every workspace in one go, so the steps stay
as they were; one is added: `npm pack --dry-run -w @kanbot/plugin-sdk`
runs prepack (the tsc build to dist/ and the published manifest) and
postpack, so a change that breaks the published SDK fails CI without
anything being published.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Declare what the root's tests import; CLAUDE.md for workspaces and the SDK ... fb49357486

The root's tests mock the Claude Agent SDK and lint-test with the
typescript-eslint parser; both resolved only because npm hoisted them from a
workspace, so the root now declares them as devDependencies.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The Devices context: what a paired device and a pairing offer are ... 4a2400c47c

The contract Phase 9 builds on: a Device (only its token's hash is stored),
a PairingOffer (one-time six-digit code, expiry, address, the hub's
certificate fingerprint), one PairingRefused for every way a code fails so a
guesser learns nothing, and the Devices RPC group Settings uses.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The app reaches the Devices group, and pairs over REST ... 3bb852311f

Settings › Devices needs the list, a pairing code and revoking, and the
/pair page needs the one call that arrives without a token. The RPC side
follows the other contexts: an api module (composables/api/devices), a
query composable refreshed on `devices.changed`, and a command composable
that re-reads the list after a revoke so the row greys without waiting for
the live message. usePairing is plain $fetch to POST /api/auth/pair: it is
the request that sets the HttpOnly cookie, so it cannot go through the RPC
client, and it maps the answers to what the page says (400/401 refused,
429 too many tries, anything else a failure to show).

The client merges `Devices` into KanbotRpcs on its own side until the
server serves the group (Phase 9 A adds it to KanbotRpcs with its
handlers; the merge goes then). DeviceNotFound and PairingRefused get
their catalogue keys, and the catalogues carry every string the pairing UI
uses, in English and Spanish.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

/pair: a browser without a token pairs with a six-digit code ... 284dec7c96

A protected Kanbot sends a browser it does not know to /pair, so the page
must render with nothing the auth would refuse: it reads no query (no
settings, no plugins, no live updates), uses a bare layout with no header,
tour or shortcuts, and the setup middleware leaves it alone. Its one
request is the pairing POST; on success it reloads the app at `redirect`,
a same-origin path only (safeRedirect refuses //host, /\host, schemes and
/pair itself), so everything afterwards goes out with the new cookie.

The code is one numeric field that keeps only digits, so a pasted
"123 456" works, and it pairs the moment the sixth digit arrives. A code
prefilled from the pairing address waits for the user, who should compare
the hub's fingerprint (`fp`, shown when the address carries it) first.
The device name defaults to the browser and system the User-Agent names.
Whoever opens /pair is not yet someone this Kanbot knows, so the page
speaks their browser's language rather than the hub owner's setting.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Settings › Devices: the paired devices, revoking, and pairing a new one ... e1275c1961

A section like the others (rail entry, searchable by its keywords) lists
the devices with their kind, when they were paired and last seen, and
"This device" on the one the page is open on; revoked ones are greyed and
hidden behind a toggle. Revoking asks first and warns when it is this
device, which the page then sends to /pair. "Pair a device" asks the hub
for a code when it opens and shows it big with its countdown, the address
and its QR code, and the hub's fingerprint to compare. Reopening keeps the
same code while it lasts, since asking again would end it; an expired one
offers a new one, and a device that pairs while the code is on screen
closes it with a toast.

The page passes the list and the commands as props, so every component
has a story with a fake hub. The QR code is uqr (pure JS, already in the
tree through Nuxt, now a direct dependency) drawn as one inline SVG path
on a white tile, which stays scannable in dark themes. The tour gains a
short step on the section. Component tests cover typing and pasting the
code, auto-submit, each outcome the /pair card shows, the countdown and
how usePairing reads the server's answers.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The pairing modal hides the address once its code has expired ... 6befc2256c

The address and its QR code carry the code, so after the countdown runs
out they only lead the other device to a refusal. They step aside until
"New code" brings a live one; a component test drives the expiry and the
renewal with fake timers.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The hub's certificate, made once into the data dir ... 8bf34fb875

Phase 9 gives the hub an identity a device can check when it paires,
Syncthing-style: a self-signed certificate whose SHA-256 fingerprint is shown
beside the pairing code. It is an ECDSA P-256 key from Node's WebCrypto, signed
by pkijs (pure JS, already in the tree through electron-builder): no native
module and no OpenSSL to shell out to, so the desktop bundle stays portable.

hub.crt and hub.key (0600) are written once, for this machine's id, valid ten
years, and read back on every boot; they are only remade when a file is
missing or the key is not the certificate's, since a new fingerprint is a new
identity to every paired device. HTTPS stays off until hub mode (Phase 11);
hubCertificatePaths is what it will read.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Paired devices: the devices table, pairing and revoking ... c6afe39080

The Devices context's server half. A device is a row in `devices` (migration
0020) holding only the SHA-256 of its token: the token (32 random bytes,
base64url) exists in clear once, in pairDevice's answer, and a request's token
is checked by hashing it and finding that hash (compared again in constant
time). Revoking keeps the row and stops the token for good.

The pairing code lives in memory (PairingOffersMemory): it lasts five minutes,
so a restart withdrawing it only costs a new code, and nothing secret reaches
the disk. Six digits from crypto.randomInt, compared in constant time; a newer
offer replaces the older, a right code is spent, and five wrong tries burn it.
Every way a code fails is the one PairingRefused, so a guesser learns nothing.

DevicePaired and DeviceRevoked reach screens as `devices.changed`; pairing and
revoking are logged without tokens or codes. The 0013 migration moved verbatim
into its own file to keep the list under its size limit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Every request proves who it is: the auth middleware, pairing, Devices RPC ... 88a8bf9fc4

server/middleware/auth.ts runs before every route and page (after Nitro's
static files, which are the public build), and decides with one pure rule,
decideAccess (packages/core/src/devices):
- From another machine, by the socket's address (never X-Forwarded-For): a
  paired, unrevoked device's token, as the kanbot_device cookie or a Bearer
  header. Otherwise a page goes to /pair?redirect=…, anything else is 401 JSON.
- From this machine, with KANBOT_LOCAL_TOKEN set (the packaged app): that
  token (kanbot_local cookie or Bearer, compared in constant time) or a device
  token. The variable leaves the environment when boot reads it, so agents and
  setup commands do not inherit it.
- From this machine without it (dev, tests, scripts): open as before, but the
  Host must name this machine and port (DNS rebinding), and a foreign Origin,
  a cross-site request other than a top-level navigation, or an unsafe one
  from another site is 403 (CSRF from web pages).
- Open to anyone: /pair, POST /api/auth/pair, /_nuxt and /_i18n assets, the
  icons, and the browser handoff link; dot segments and encoded separators
  never count as open.

Nuxt renders pages by calling /api/rpc in process with the page request's
headers. The middleware gives each let-through request a random caller id,
in a header only this process writes (a client's is removed), so those calls
carry the page's caller; the RPC handlers read it for Devices.list's
isCurrent, and offerPairing/revoke die without one.

POST /api/auth/pair is rate-limited per address (IPv6 by /64): the eleventh
try in ten minutes is 429 before the code is read. A browser gets only the
HttpOnly SameSite=Strict cookie; a node or script the token, once. A device
may revoke itself (signing out): the hub's own window is never a device, so
no one is locked out. A stale device cookie is dropped. "Open in browser"
trades a one-minute, single-use nonce the shell asks for (local token only)
for the per-launch cookie, on this machine only.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The desktop app carries a per-launch token to its server ... 677f9d7253

With the server now refusing this machine's requests unless they show
KANBOT_LOCAL_TOKEN, the shell makes one for each launch (32 random bytes)
and is the only holder: it passes it to the server it forks, sets it as the
HttpOnly, SameSite=Strict `kanbot_local` cookie on the window's session before
loading the board, and sends it as a Bearer header from its own REST calls,
the boot poll of /api/status and the SSE client. Other local programs and
web pages can no longer drive the app.

"Open in browser" (tray and Help menu) asks the server for a one-time link
that gives the system browser the cookie, since a plain URL would now be
refused. desktop:dev (ELECTRON_DEV_URL) has no token, as its dev server has none.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge the pairing UI (wip/p9-ui) onto the auth server side ... ee0e0f7551

The app's client takes Devices from KanbotRpcs again, now that the server
serves it. Both tracks added the same error strings; the translation files
also carried a duplicate machineUnavailable key from Phase 7. JSON keeps the
last of each, so the shorter pairing message and the machine message that
names the machine were being overridden. One of each is kept.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The shell's live feed carries the launch token ... 58290fa22a

The packaged app's tray and notifications listen to /api/events, and
since Phase 9 every request from this machine must carry the per-launch
token. main.js subscribed without it: the stream was answered 401 and
retried forever, so the tray never refreshed on its own and no desktop
notification was ever shown.

All of the shell's requests (the boot poll, the REST calls, the live
feed) now go through one client, electron/shellClient.js, made with the
launch's headers, so no call can be the one that forgets them. A test
checks all three carry the token and that main.js makes no request of
its own.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The app window stays on the app's own origin ... 8ab0f7457c

main.js let the window follow a link or open a popup when the target
string started with the server's address. `http://127.0.0.1:PORT@evil.com/`
starts with it but is evil.com (the part before the @ is a user name), and
`http://127.0.0.1:PORT1` is another port: a link in a task's description,
an agent's output or a tracker issue could load another site inside the
Kanbot window, where it looks like Kanbot and can phish.

The window now compares parsed origins (electron/navigation.js), and
everything else opens in the system browser as before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

RPC handlers read the caller off the HTTP request, not the message ... f60cfbef0d

The Devices handlers learnt who was calling from the `headers` the RPC
server hands them. Those are the HTTP request's headers with each
message's own headers concatenated after them, and the last value of a
name wins (RpcServer: requestHeaders.concat(message.headers)). The
message's headers are part of the NDJSON body the client writes, so a
client could put its own `x-kanbot-caller` there and override the id the
auth middleware set. Today that only lets a caller lose its identity (an
id it cannot know resolves to nobody), but any id it ever learnt would
let it act as that caller, and a device could make itself look like
someone else to list/revoke.

Handlers now read the caller from the HTTP request itself (rpcCaller):
the RPC server runs each handler with the request fiber's context, where
HttpServerRequest is the request server/api/rpc.ts passed, carrying only
the middleware's id. The headers-based helper is gone. The test sends a
paired device's Devices.list with a forged caller header in the message
and checks the handler still knows it is that device.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Only this computer offers pairing codes and revokes other devices ... df74f91674

Any paired device could call Devices.offerPairing and Devices.revoke on
any device. A phone left unlocked, a stolen laptop or a compromised
script token could therefore mint codes and pair more devices of the
attacker's choosing (persistence that outlives revoking the first one),
or revoke every other device to lock the owner's laptop and phone out.

mayManageDevices (a core rule) now lets the computer Kanbot runs on (the
packaged app's window or, with no per-launch token, loopback) do both,
and a paired device only revoke itself (signing out). Anything else is
NotAllowedFromDevice, a domain error in the Devices contract with its
catalogue key. Settings › Devices, opened on a paired device, hides
"Pair a device" and the other devices' Revoke and says where to do it.

Tests: over HTTP a paired script lists devices and signs itself out but
gets NotAllowedFromDevice for offering a code and revoking another, while
loopback and the per-launch token may; the section hides the buttons on
a device.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Revoking a device ends its open streams ... 4872659fb4

Revoking a device stopped its next request, but not the ones already
open: the SSE feed (/api/events) and the RPC LiveUpdates stream kept
delivering every task, question and notification to the revoked device
until it happened to reconnect, which a stolen laptop left open never
does.

The callers registry now remembers, for every open request, how to cut
it off, and Devices.revoke closes all of the device's requests except
the one asking (a device signing itself out still gets its answer).

Cutting the connection was not enough for the RPC stream: h3 pipes a
streamed Response into the socket and never cancels it when the socket
goes, so the RPC server went on feeding a subscription nobody read,
one bus listener and an unbounded queue per closed tab, revoked or not.
server/api/rpc.ts now relays the body and cancels it when the connection
closes, which ends the RPC's scope and the subscription behind it.

The test opens a revoked device's SSE feed and LiveUpdates stream and a
bystander's feed, revokes, and checks the first two end at once, the
third stays open, and no bus listener is left behind; and that a device
revoking itself gets its answer while its feed ends.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Pairing reads at most 4 KB of body ... 249d942400

POST /api/auth/pair is the one request anybody may make, and it read the
whole body into memory before looking at it (h3's readBody buffers it),
whatever its size: the review sent 400 MB and the server's memory grew by
1.2 GB, and nothing stops a stranger on the network from doing that
again and again until the hub runs out.

The route now reads the body through readBodyWithin before decoding it: a
Content-Length over 4 KB is answered 413 unread, and a chunked body stops
being read the moment it passes 4 KB, with Connection: close so the rest
is never read either. Pairing is the only open route that reads a body
(the others are GET), so it is the only one that needs it.

The test sends a declared 5 KB body, a chunked one that passes 4 KB and
stops (413 straight away), and 64 MB in 64 KB chunks, which is cut off
long before it is all sent; a normal pairing still works.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Attachments can never run as Kanbot's page ... 43232ab622

A task's attachments come from whoever can comment on it, from agents,
from Discord and from trackers, and GET /api/attachments/:id served them
with the type their name implied and nothing else. An SVG with a
<script> in it, opened from the task page (its file link opens it in a
new tab), ran as Kanbot's own origin: stored XSS with the whole API in
reach, Devices.offerPairing included, so one uploaded file could pair the
attacker's device.

Every attachment is now served with:
- X-Content-Type-Options: nosniff, so the browser takes the type we give
  and never runs a "picture" that is really HTML;
- Content-Security-Policy: default-src 'none'; img-src 'self' data:;
  media-src 'self'; style-src 'unsafe-inline'; sandbox, so whatever does
  open has no script, no requests and an origin of its own;
- Content-Disposition: inline only for a closed list (png, jpeg, gif,
  webp, avif, pdf, plain text, mp4, webm), attachment with the file's
  name (RFC 6266) for everything else.

SVG is a download, still served as image/svg+xml: a picture in a page
(the gallery's <img>) ignores the disposition and never runs script, and
opened by itself it is saved, not rendered; if a browser rendered it
anyway, the sandbox stops its script (checked in headless Chrome: script
runs without the headers, is blocked with the CSP, the navigation
downloads with the disposition, and <img> still shows it).

A PDF keeps the CSP without `sandbox`: the browser's PDF viewer is a
plugin, which a sandboxed document may not load, and a PDF's own scripts
run inside that viewer, never as the page's origin.

Every answer also gets a baseline beside X-Frame-Options: nosniff and
Referrer-Policy: same-origin. No site-wide CSP: Nuxt's pages need inline
scripts and styles, so one strict enough to matter would break them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A request a proxy on this machine forwards is not this machine ... c649e8a770

Without a per-launch token (npm run dev, npm start, a server someone
runs by hand), a request from this machine's socket is trusted. Put a
reverse proxy on the same machine in front of it (nginx, Caddy, a
tunnel, `tailscale serve`) and every client of the proxy arrives from
127.0.0.1 with a loopback Host: anyone who can reach the proxy had the
whole API.

A request from a loopback socket that carries X-Forwarded-For,
X-Forwarded-Host, X-Real-IP or Forwarded now counts as another machine
when no per-launch token is set: a paired device's token works, the
open routes (/pair and its POST, the assets) stay open so devices can
pair through the proxy, and anything else is refused 403 with its own
key, error.behindProxy, which says to pair the device or run Kanbot with
a per-launch token. The headers are only checked for presence, never
believed: who the client is stays unknown. With a per-launch token set
the token decides, as for any request from this machine.

Known limit: through the proxy every client shares one pairing rate
limit bucket (127.0.0.1).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

nuxt dev knows who each client really is ... 108faed7ef

Under `nuxt dev` the app runs in a worker on a Unix socket, behind Nuxt's
listener and Nitro's dev proxy. The socket has no address, so the auth
middleware counted every request as this machine: with `nuxt dev --host`
(or NUXT_HOST/HOST set), anyone on the network who sent a loopback Host
had the whole API, no token needed.

The forwarding headers cannot fix that: Nitro's dev proxy passes a
client's own X-Forwarded-For through untouched and adds one only when
there is none (nitropack createHTTPProxy, `if (!hasHeader)`), so a client
that sends `X-Forwarded-For: 127.0.0.1` is believed. Reading the last
entry would have kept the hole.

Instead the dev listener itself says who the client is: nuxt.config's
`listen` hook (dev only, given the real listener, forked or not) adds a
request listener that runs before anything else and writes the socket's
address, its local port and whether the request carried forwarding
headers into x-kanbot-dev-peer, overwriting whatever the client sent,
signed with a random key put in the environment the Nitro workers
inherit (and taken out of the worker's at boot, so agents do not get it).
In dev the worker believes only a stamp with that key; a request without
one (someone talking to the socket directly) is another machine, never
this one. Outside dev the stamp is removed and ignored. The address also
feeds the pairing rate limit (event.context.clientAddress), which counted
every dev client as one 'unknown'.

The test puts a real listener with the stamp and a proxy that behaves
like Nitro's in front of the middleware on a Unix socket: this machine
gets in, another machine with a loopback Host, a forged X-Forwarded-For
or a forged stamp does not, it can pair and use its token, and a request
straight to the socket proves nothing. Checked against a real
`nuxt dev --host 127.0.0.1`: loopback 200, a forwarded request 403
behindProxy (the stamp's flag got through), a request straight to the
worker's socket 401.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The per-launch token comes over the message port, not the environment ... 1f87ee6d4d

Electron passed the per-launch token to its server as KANBOT_LOCAL_TOKEN,
and the server deleted it from process.env at boot. Deleting it changes
only the copy JavaScript sees: the process's initial environment, which
`ps -E` (macOS) and /proc/<pid>/environ (Linux) show to every program of
the same user, still has it. Those programs include the agents the
server runs on arbitrary repositories, so a prompt-injected agent could
read the token and drive the app (approve its own commands, offer pairing
codes) as if it were the window.

The shell now starts the server with only KANBOT_LOCAL_TOKEN_VIA=parentport,
which carries no secret, and answers the server's request for the token
over the utility process's message port (electron/localAuth.js). At boot
the server marks the token as pending before Nitro listens, so every
request from this machine is refused until it arrives (the shell's boot
poll simply retries), then asks for it on process.parentPort; the first
well-formed answer is the token and nothing changes it afterwards.
Started with the flag but without a parent port, it stays shut rather
than open. KANBOT_LOCAL_TOKEN is still read (tests, a server run by hand).

Chosen over a 0600 file in the data dir: a file is readable by the same
user's programs for as long as it exists and leaves the token on disk if
the server dies before unlinking it; the port is private to the parent
and the child and never touches disk or the environment.

Tests: the server asks over a fake parent port, refuses everything until
the token arrives, takes only the first well-formed one and the token is
in no environment variable; without a port it stays shut; the shell
answers the request on the port and main.js puts no token in the env.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The desktop app answers under its own name, kanbot-<random>.localhost ... 6765b4d88c

Cookies are not scoped by port. The packaged app set its per-launch
cookie (kanbot_local) on 127.0.0.1, and after the tray's "Open in
browser" the system browser had it too: it then sent it to every server
on 127.0.0.1, whatever the port, for instance a dev server an agent
started from a cloned repository's code, which could log it (and drive
Kanbot with it) or overwrite it with a Set-Cookie of its own.

The shell now makes a name for this machine once per install,
kanbot-<16 hex>.localhost (kept 0600 in the user-data folder), and the
window, its cookie and the browser handoff all use it; the shell's own
REST calls and boot poll stay on 127.0.0.1 with the Bearer header. The
name goes to the server with the token over the message port (it is not
secret, but must be known), and hostIsLoopback accepts exactly that name
besides the loopback names; the server takes no name the shell could not
have made (/^kanbot-[a-z0-9]{12,32}\.localhost$/). Nothing changes in
how the server listens: it still binds 127.0.0.1.

Browsers resolve *.localhost to this machine by themselves (Chromium,
Firefox), and Safari asks macOS's resolver, which does too (getaddrinfo
answers 127.0.0.1 and ::1 here), so the handoff needs no fallback to
127.0.0.1. Checked in headless Chrome against a server bound to
127.0.0.1: the name resolves, and a cookie set under it is not sent to
127.0.0.1 or localhost on another port.

Remaining: the cookie still goes to the same name on another port, so a
program that reads the name from the user-data folder and gets the
browser to open it on its own port could still read the cookie; it is
one more step than before, not a wall.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md: authentication, as built and as reviewed ... 3d34b19495

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A run reaches the engine in the turn it is started ... 7dc9b30d66

startRun went through TaskRun.execute, which computes the execution id by
hashing the idempotency key with crypto.subtle.digest. WebCrypto runs that
digest on libuv's thread pool, so the run was handed to the engine only when
the pool answered: after an unbounded number of event-loop turns, and for
runs started together, in whichever order their digests came back. The task's
state already names the execution (executionIdOf, the same hash done
synchronously with node:crypto), so the run now goes straight to
WorkflowEngine.execute under that id, as Workflow.execute would after its
hash.

That hop is what made the scheduler and gate tests flaky in full-suite runs,
where the forks contend for the pool: settle() only lets event-loop turns go
by, so a sweep's runs were sometimes not started yet when the test looked
(test/machines/scheduler.test.ts: "expected null to be 'slot'", "expected []
to deeply equal [1, 2]"; test/characterisation/scheduler.test.ts: enqueuePlan
"called 0 times"), started b before a, or were a stage behind at the gate
(test/rpc/workflow.test.ts: "expected 'agent' to be 'human'"). Delaying the
digest by a few milliseconds reproduces all of them on every run.

test/workflow/runStart.test.ts makes the digest never answer: two runs
started one after the other still reach their first stage within settle(),
in order, under the execution id their state names.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A run stopped underneath itself runs no more actions ... 90cc8f7e90

RunHost.record writes the run's state only while its runId is still the
task's, so a stopped run can never put its state back (nothing else in the
run writes the read model, it has no finalizer or onInterrupt, and an
interrupt's replay answers every activity from the engine's record). But a
step is recorded in one activity and its action runs in the next, and the
action did not check: a stop landing between the two (the human finishing at
the gate, a card dragged away, a run dropped) still ran the node. At a gate
that moved the finished card back to the gate's column, set it waiting and
notified; at a stage it started an agent for a run nobody had any more.
parkOnCap and blockOnFailure, which follow a wait, had the same gap.

The node kinds now return Stop when the task's run is not theirs, and
parkOnCap and blockOnFailure take the runId and do nothing for a stale run,
as stopLooping already did.

test/workflow/staleRun.test.ts stops the run from inside the step's own
write (the task.workflow message saveState sends), which is exactly between
the two activities every time: finishing at the gate leaves the task
finished, not waiting, and dropping a run as it reaches Develop starts no
agent.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge branch 'wip/p9-flakes' into refactor/phase-9-auth 3919da69e0

CLAUDE.md: how a run reaches the engine, and why its actions check their run ... 1b53a50242

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Refuse to start on a Node older than 24 ... f400664f0b

On Node 22 node:sqlite has no DatabaseSync.isTransaction, so the dev worker
died at boot and every page answered a bare 500 with no reason given.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

No bare @ in the catalogues ... 1c2f11f08b

vue-i18n reads @ as a linked message, so plugins.problem.noMetadata and
undecorated failed to compile and took the dev page down with them. They are
reworded rather than escaped as {'@'}, which the server's translate() would
print verbatim. A test compiles every message, the plugins' included.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Phase 10 contract: what a node serves the hub ... f48d583454

NodeRpcs (NodeHello, NodeSessions, NodeWorkspace) over the WebSocket a node
dials. The hub is the client; a session's messages are the stream of the
call that started it, numbered so a reconnect attaches after the last one
seen, and the SessionSpec's callbacks (tools, gate, ask) are messages the
hub answers with NodeSessions.reply.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

NodeLinks: the hub's registry of connected nodes ... 3d1c540c06

The seam between the transport, which registers a link per open socket, and
everything that reaches a node through it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Plugin host: the app's part of a plugin's context is a PluginSurface ... f547405d07

The board, the host's notifications and the app's text read the Kanbot
database (settings, tasks), so the host took them in through pluginContext
and could not run where there is none. They are now handed in with the
host's options: appSurface on the hub; a node will hand in its own.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Auth: the node socket is its own route kind, open to a paired device only ... b8a1072317

classifyRoute names GET /api/nodes/ws 'nodeSocket'; decideAccess lets
nothing but a valid device token through it (not loopback, not the
per-launch token). NodeLinks' device ids are strings, as devices' are.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Node handlers: SessionHost, NodeWorkspace and Node.hello ... 7bb4fcfaba

NodeHandlersLive serves NodeRpcs on a node. Sessions run as fibers of a
FiberMap in the layer's scope, detached from the call that started them;
their messages are numbered per session and journalled in memory until the
hub acks them (JOURNAL_LIMIT unacked messages ends the session). Tool calls,
gate requests and questions are messages the hub answers with reply.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Test the node's handlers through an in-memory RPC client ... aedc52690a

Sessions (events, callbacks, stop, drop and re-attach, concurrent
attaches, ack, errors, the journal bound), Node.hello, NodeWorkspace over
a real repository, the runtime contract through the handlers, and a guard
that the handlers' module graph reaches no database.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md: a node's handlers and its sessions ... 598ddbd6c2

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Component tests read the catalogue's text, not its keys ... 1850fccc19

They were written while en.json failed to compile (a bare @), when every
message rendered as its key. Now the catalogue loads, so they look text up
through the app's own i18n (test/support/text.ts) and check what is shown.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge branch 'refactor/phase-9-auth' into refactor/phase-10-nodes 4ae242ad76

test/support/text.ts typechecks under the test tsconfig ... fc61c05f69

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge branch 'refactor/phase-9-auth' into refactor/phase-10-nodes 3856ca5e29

Machines and sessions for nodes: online, connect events, unreachable and lost ... 5edf15e9ff

A machine is online (this one always, a node while it has a link: read,
never stored); MachineConnected/MachineDisconnected with the Machines port's
registerNode and seen; machines.device_id (0021). A session can be
unreachable (it keeps its slot) or lost, and a task's agent unreachable.
MachineRuntimes chooses a session's runtime by its machine.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Hub side of nodes: remote workspace, RemoteRuntime, re-attach and leases ... b93d7a9c09

MachineWorkspaces and MachineRuntimes reach a connected node over its link;
RemoteRuntime drives NodeSessions, answers callbacks once per call id,
acknowledges what it passed on, waits a dropped link out for a lease and
re-attaches after the last message, else the session is lost and its task
resumes by external id when the node is back. Node links register their
machine (followLinks, in the background). A node away takes no work.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Show nodes online or offline, and tasks whose node is unreachable ... d11f35095a

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge remote-tracking branch 'origin/refactor/phase-10-nodes' into wip/p10-hub 836d0e5ce5

Merge remote-tracking branch 'origin/wip/p10-node' into wip/p10-hub b1075d6d4c

Hub: accept nodes on /api/nodes/ws and hold their links ... 614abfa5e0

Nitro's websockets are on. The upgrade checks a node device's Bearer
token itself (upgrades never reach the auth middleware); the open peer
becomes an Effect Socket, and the accept runs on the app's runtime: an
RpcClient for NodeRpcs over it, Node.hello, the protocol and hub-id
checks, then NodeLinks.register until the socket closes. NodeLinksLive
keeps the links by machine, a newer one replacing the older, and revoking
a device closes its links.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Node process: kanbot-node, dialling the hub and serving NodeRpcs ... 59b9a1d42f

A SocketServer whose run dials the hub with the node's token and dials
again with backoff (500 ms doubling to 30 s, reset by a connection that
lasted 10 s), under RpcServer's socket protocol. The node's layer runs
the runtime plugins on an in-memory store with no board, settings or
HostOS, and the stub handlers until track N's NodeHandlersLive. main.ts
pairs (node.json, 0600) and runs; scripts/build-node.ts bundles it to
.output/node/index.mjs without the Nitro server or the database.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Tests: the node socket over real HTTP, and the node's entry ... c5a781d947

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge refactor/phase-10-nodes 7341e4c061

CLAUDE.md: Nodes, the socket's transport and auth ... 4051fe6cfa

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge remote-tracking branch 'origin/wip/p10-node' into refactor/phase-10-nodes f70de43e89

The node process serves the real handlers ... 2928c13ba3

nodeLayer builds NodeHandlersLive over the node's identity, its local
workspace and the runtime plugins, in place of the stub (kept for the
transport tests). One NodeIdentity: the plain type is the service's shape.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Test the hub against a linked node: machines, workspace, sessions, drops, leases ... e81b703fe8

linkedNode registers the node's real handlers into the app's NodeLinks and
cuts the link like a dead socket; the runtime contract passes through
RemoteRuntime; the scheduler's second machine is a connected node.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge remote-tracking branch 'origin/refactor/phase-10-nodes' into wip/p10-hub 30e674fa70

Hub on the real NodeLinks; CLAUDE.md: remote workspace, RemoteRuntime, runtime by machine, unreachable and lost ... dee7984985

The merged base serves NodeLinksLive (string device ids), so the in-memory
stand-in goes and the hub's layers sit on it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

End-to-end: a session from the hub to a node over the real socket ... 4e694f2f9f

nodeLayer takes a runtimes layer in place of the plugins' (tests only).
That exposed a bug: Node.hello read AgentRuntimes from the RPC server's
context at call time while the session host used the layer's, so hello
could announce runtimes other than the ones sessions start. Hello now
uses the runtimes its layer was built with.

The test pairs a node built from nodeLayer, runs a scripted session
(events, tools, the gate, a question answered over RPC) on a project on
the node, cuts the socket from the hub with the question pending and
from the node while the runtime keeps emitting, checks the timeline
line by line, and revokes the node.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A node's token opens the node socket and nothing else ... bb33c48f76

decideAccess now sees the device's kind: a node device is refused
(Forbidden: nodeDevice) on every route but the node socket, from anywhere,
as a Bearer or a cookie, and the node socket lets in only node devices.
A node taken over is no longer the user on the hub.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Projects.create can put a project on a connected node ... a08d14adc9

ProjectInput takes an optional machineId; the core already checked the
folder on that machine and recorded it, but the contract dropped the field,
so there was no way to make a project on a node but by hand.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A machine id is its first device's: the hub binds a node's machine to its device ... 4ca5430427

A node's hello names its machine id; the hub took its word, so another
paired node could say the same id and take its projects, sessions and
prompts. claimNodeMachine now decides, in one transaction before the link
is registered, whether the device may be that machine (decideNodeClaim):
a machine bound to another paired, unrevoked device is refused
(machineTaken), and a device is one machine for good (deviceTaken); the
row is bound in the same step. Revoking the device frees the machine for
the device paired next. A refused node is closed 4403 and logged.

NodeInfo is bounded: machine id-like and at most 64 characters, a name of
1-80, at most 32 runtimes and 1000 held sessions; a hello that does not
decode is refused.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

attach_screenshot reads only images inside the session's folder, on its machine ... 1e8fe9f00e

The tool resolved any path the agent gave and read it on the hub, so a
node (or a prompt-injected agent) could attach the hub's secrets.key, its
database or ~/.ssh keys as a screenshot. MachineWorkspace.readImage now
reads it on the session's machine: the path must stay inside the working
folder once symlinks are followed (outside as written is refused without
looking), be a PNG, JPEG, GIF or WebP by name and bytes, and be at most
5 MB. A node serves it as NodeWorkspace.readImage (base64, bounded), so a
node's screenshots now work, and the hub checks the bytes again. The agent
is told why an image was refused.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

WebSocket upgrades only on the node socket's path, frames capped at 8 MiB ... bd98b6f610

With Nitro's websocket support on, crossws accepted an upgrade on any path
without hooks of its own, past the auth middleware, with ws's 100 MiB
frames: anyone on the LAN could hold sockets open on / or /api/rpc. A
Nitro plugin (server/plugins/websockets.ts) now sets crossws's global
upgrade hook (guardWebSockets) before the upgrade listener is made: 404 on
every path but /api/nodes/ws, whose own hook decides, and maxPayload 8 MiB
(a 5 MB screenshot as base64 fits). The test app uses the same guard.

Checked by hand against nuxt dev (the dev proxy reaches the worker's
crossws: node socket opens, other paths 404) and the production build
(also: an oversized frame closes the socket with 1009).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Bound what one node can cost the hub ... 98b0fcea06

- Orphans a node's hello lists are stopped in the background, eight at a
  time, off followLinks' change loop: a node listing many fake sessions no
  longer stalls every other node's connect (each stop waited 5 s, in turn).
- The peer socket closes (1008) when more than 32 MiB or 4096 frames wait
  unread, instead of buffering without bound.
- A node device may upgrade 30 times a minute; past that, 429 with
  Retry-After before a socket opens (error.tooManyConnects).
- At most 64 callbacks per session wait on an answer; past that a call is
  Rejected at once. The once-per-call-id set is now the calls in flight
  (replays are already skipped by seq), so it no longer grows forever.
- NodeInfo's runtimes and sessions were bounded in the binding commit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Markdown: links only to the web or mail, no remote images ... b4ad20ddc5

Escaping < kept raw HTML out, but [x](javascript:alert(1)) still rendered
as a link (marked 18 outputs the href), and text from a tracker, an agent
or now a node is rendered in the app. renderMarkdown now uses its own
Marked instance whose renderer writes a link only for http(s) and mailto
hrefs (anything else is its text) and never an <img>: an image is a link
to it, so no remote image loads by itself.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A device revoked while its node's hello is in flight gets no link ... 33c2b092c5

Revoking closed the device's links, but a node whose hello was still on
its way registered right after and stayed up. NodeLinks now remembers the
devices it closed for good: a link of one registered later is closed at
once and never announced.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A node's AskRequest reaches the board only as its kind's payload ... 8807642a67

The payload crossed the wire as Schema.Unknown and was handed to spec.ask
as is, so a node could put any shape on the board as a question. It is now
decoded against its kind's Schema from the SDK (FreeQuestion,
ChoiceQuestions, PlanQuestion, ApprovalQuestion; extra keys dropped);
one that does not decode is Rejected.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kanbot-node pair: http(s) hubs only, no redirects, a warning in clear ... 864445e9f3

fetch followed a 307/308 and re-POSTed the pairing code to wherever it
pointed. pairNode now refuses redirects (redirect: 'error') and any hub
address that is not http(s); the CLI warns that a plain-http hub sees the
code and the token cross the network in clear until Phase 11.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

node.json is written atomically, 0600 from the start, in a 0700 data dir ... 24cf1dc5bb

writeNodeConfig wrote over an existing node.json and narrowed its mode
afterwards (readable by others for a moment if it was), and could leave it
half written. It now writes a new 0600 file beside it and renames it over;
the data dir it (or kanbot-node at start) creates is 0700. main.ts says to
prefer node.json to KANBOT_NODE_TOKEN, which same-user processes can read.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A pairing code pairs the kind of device it was offered for ... bbd979b6ba

Any code from Settings › Devices could pair a node, so a code offered for
someone's phone could become a node the hub sends prompts to. An offer is
now for a node or, by default, for a browser or a script
(Devices.offerPairing takes an optional { kind }; no payload still works),
and redeeming it as the other kind fails like a wrong code (it counts
towards burning it; every failure is the same PairingRefused / 401).

Settings › Devices' pairing card has a "For a node" switch: it asks for a
node's code and shows the kanbot-node pair command to run there instead of
the address and QR code.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A node's project does not open on the hub's editor or read the hub's disk ... 45177f5b3c

Opening a project or task on a node ran the hub's editor or terminal on a
path that is the node's (it could name one of the hub's own folders), and
the project list read the launcher labels from the hub's file system at
that path. openFolder now refuses a project not on this machine with
HostActionFailed error.opensOnItsMachine (naming the machine) before
anything is read or launched, and the labels of a node's project are the
global ones until they are read through its workspace (Phase 11).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md: the node hardening, and what a node and the hub trust by design ... 5016c14fb9

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge remote-tracking branch 'origin/wip/p10-security' into refactor/phase-10-nodes b5ff7ecf6e

End-to-end test pairs its node with a node code ... e04457cf78

A pairing code now pairs only the kind it was offered for.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A node's session never sends a frame over the hub's cap ... 3c38c97867

The node's session streams went out as whatever the RPC server took from
the queue at once, written as one WebSocket frame: a backlog replayed after
a reconnect, or one large event, passed the hub's 8 MiB cap, the hub closed
the link (1009), the node redialled and was attached after the same seq,
forever.

- followSession streams one message per chunk (Stream.rechunk(1)).
- clipEvent holds an event under 1 MiB (strings cut with a truncation
  marker, a tool's input as its cut JSON); a tool call, gate request or
  question over 4 MiB is settled on the node, failing closed.
- boundReply holds the hub's replies under the cap too.
- Backstop: the peer socket keeps its close code (ws reports the cap as an
  error before closing 1009); three links in a row closing 1009 with the
  session's messages pending and none through fail the session with
  error.nodeMessageTooLarge instead of re-attaching forever.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The node socket's upgrade guard compares the raw path ... 6a805c5a60

The guard compared `new URL(request.url).pathname`, which resolves `..`,
`.` and `%2e`, while h3 picks a route's websocket hooks from the path as
written. `/x/../api/nodes/ws`, `/api/nodes/./ws` and `/api/nodes/%2e/ws`
passed the guard, resolved to no route, and crossws accepted them with no
token (101). The guard now takes the path exactly as the request line wrote
it (and a plain Host), and lets through only `/api/nodes/ws` with an
optional query, so h3 always resolves what it lets through to the node
route and its token check.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A screenshot may come from the temp folders or the task's attachments ... b8f1178722

attach_screenshot read only inside the working folder, so a screenshot
saved where browser tools save them (Playwright MCP under the OS temp
folder, Chrome DevTools often /tmp) was refused, and so were the human's
files in the task's attachments folder. readImage now also accepts the
machine's temp folders (Platform.tempDirs: the OS's, /tmp, /private/tmp on
macOS) and, for a session on the hub's own machine, the task's attachments
folder, each checked after symlinks as the working folder is; the image
checks are unchanged. The tool's description says where images may be read
from.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A node's question is bounded before it reaches the board ... efa98cede5

The hub decoded an AskRequest's payload against the SDK's question
Schemas, whose strings and arrays are unbounded, so a node could put a
question of megabytes on a task. The hub now decodes it against bounded
copies (askPayloads: text, context, plan and command up to 20,000
characters, headers, questions, labels, descriptions, tool and reason up to
500, at most 20 options and 10 questions); past them the call is Rejected.
The SDK's public Schemas are unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Nothing the hub forks for a node outlives its link or session uncounted ... 37097fbf8e

Orphan stops were forked detached, so they outlived the link that listed
them; they are now forked in the link's scope (NodeLink.scope: the accept's
scope, the socket's lifetime). Callbacks refused past
MAX_CALLBACKS_IN_FLIGHT were each forked uncounted, every one waiting for a
link to send its refusal; the refusals waiting are now counted
(RemoteState.refusing) and capped at as many again, past which a call is
dropped with a warning.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

readImage checks that the file it opened is the one its path leads to ... 4991c16027

readImage resolved the path, checked it was inside an allowed folder, then
opened the resolved path, following symlinks again: a folder on the path
swapped for a symlink out between the check and the open handed over a
file outside. It now opens with O_NOFOLLOW (where the OS has it) and, after
the open, resolves the path again, checks it is still inside, and refuses
unless the opened file and that one have the same device and inode.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A node may not claim a machine that was never a node ... 49948ef511

decideNodeClaim refused a machine bound to another live device, but a
machines row with no device that is not this hub's current id (the hub's
own row under an earlier machine id, with its projects) could be claimed by
any node device, which then took over its projects. The claim now also
reads the row's role and refuses one that is not `node` (`notANode`).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Phase 11 contract: hub settings, Discovery, Shell, NodeHost ... fcd67bfc76

The hub section (off, port 7433) switches on the LAN listener and the
announcement; Discovery lists the hubs mDNS sees; Shell asks the desktop
shell to switch to Connect; NodeHost is a node's HostOS, for the desktop a
person sits at. The groups are wired by the tracks that implement them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Add bonjour-service 1.4.4 for LAN discovery ... 3d534b496b

Pure JS (multicast-dns); announces and finds hubs as _kanbot._tcp.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Hub mode's HTTPS listener, opened and moved live from the hub settings ... 0f5c61efdd

A second listener on hub.port with the data dir's certificate serves the
same app (pages, RPC, upgrades through crossws behind the same guard);
every socket it accepts is another machine's to the auth check. Hub.status
and Discovery.hubs over RPC; the LAN behind a Lan port (bonjour-service).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Desktop pairing: one code pairs a window and its node, revoked together ... c9f900da06

A code offered for a desktop (Devices.offerPairing({ kind: 'desktop' }))
pairs two devices in one transaction: the window's browser device (its
token is the kanbot_device cookie, Secure over HTTPS) and the node it
runs (its token in the answer: { deviceId, nodeDeviceId, nodeToken }).
devices.companion_id (migration 0022) points each at the other.
Revoking either revokes both and cuts both off. A code for another kind
fails like a wrong one. Settings › Devices offers the three kinds and
shows a desktop as one entry.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Host actions follow the person: NodeHost on the node, routing on the hub ... a69d68ee22

A node serves NodeHost over its link, from a HostOS that reaches no
database (the local machine's, with English text); HostOSNone is gone.
On the hub, Host.* and openProject/openTask ask hostOfCaller: this
machine opens on its own desktop, a window paired together with a
linked node opens on that node's, anyone else is refused
(error.opensOnYourComputer). A project opens only from the machine it
is on. The test RPC client carries a caller (loopback by default).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Shell.openConnect asks the desktop shell for its connect screen ... 8e37b69758

Over the utility process's parent port ({ type: 'kanbot-shell',
action: 'open-connect' }), only from the desktop app's own window (a
Local caller) and only when the shell started the server to talk over
that port; anything else is ShellUnavailable.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Desktop shell: connect to a hub ... be25b37386

shell.json says whether this computer runs its own board or a hub's. The
connect screen (a local page) lists hubs mDNS finds, shows the certificate
fingerprint an address presents, and pairs as a desktop over a connection
pinned to it: the window's device cookie goes into the session, the node's
pairing into userData/node/node.json, and the app restarts in connect mode,
with no local server, the hub's board in a window whose session accepts only
the pinned certificate for the hub's host, and the bundled node forked as a
utility process. An offline page offers Retry and Use this computer only;
the tray says which hub this is and can disconnect (best-effort revoke).
desktop-prepare ships the node's external packages and a bundled
bonjour-service; desktop-verify checks they are in the app.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A project picks its machine, and moves to another when idle ... 96d1cbbf59

The project form has a machine picker (reachable machines, this one by
default) for a new project, and Projects.update takes machineId: the
project moves only to a machine that is reachable (MachineUnavailable),
has its folder (NotADirectory, checked there), and while none of its
sessions is open (ProjectBusy, error.projectBusy). Its tasks forget their
resume ids (those were the old machine's). ProjectChanged with machineId
tells the screens.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md: Desktop modes ... 4eb5af018a

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Nodes pin the hub's certificate; kanbot-node discover ... f1401b65d9

kanbot-node pair reads the https hub's certificate first: --fingerprint must
match it, or a person confirms it at a terminal; the code goes over a
connection pinned to it and node.json keeps the pin. Every wss dial is
pinned (undici's WebSocket over an Agent whose connector checks
fingerprint256), KANBOT_HUB_FINGERPRINT overrides. Tests over real HTTPS:
remote treatment on the hub listener (dev too), Secure cookies, pairing,
the node over pinned wss end to end, discovery over a fake and real mDNS.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

One hub certificate for callers at the same moment; CLAUDE.md on hub mode ... d4c72deed5

The identity and hub mode's listener both ensure the certificate as the
runtime starts: on a first boot each made a pair, and one went on with a
fingerprint the files no longer had. CLAUDE.md: hub mode, remote treatment
on its listener, LAN discovery, node pinning; the real-mDNS test is skipped
under CI.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Machines page: the computers, sharing this one as a hub, the hubs around ... 89532433fd

/machines lists the machines (role, reachable, last seen, agents
running from Machines.activity, each one's limit), switches the hub
sharing (hub.enabled, port) with where the listener stands, lists the
hubs on the network, and offers Connect to a hub through the desktop
shell (off, and saying why, outside the desktop app's own window).
Linked from Settings › General and the app menu.

Hub.status and Discovery.hubs are track A's: useHubStatus and
useDiscoveredHubs are stand-ins (settings only, no hubs) to swap at
the merge.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge remote-tracking branch 'origin/wip/p11-electron' into refactor/phase-11-discovery 6d9293819f

Setup step Machines: this computer alone, shared as a hub, or connected ... da5c0abcd9

A core step (since 2, right after welcome), so a fresh install sees it
in order and an install set up before (version 1) sees it once with the
end. Three choices: this computer only (default; sharing off), share as
a hub (sharing on, with its addresses and fingerprint), connect to a hub
(the desktop shell's connect screen; off in a browser, saying why). The
summary at the end says which. The story fixture for a step no screen
knows is now 'backups'.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ESLint leaves .worktrees alone ... ad5b34b2e0

Agents' checkouts of the repo live there; linted from the main checkout,
their files missed the suppressions baseline and failed lint.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The runtime test knows migration 0022 ... 79318f15a3

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge refactor/phase-11-discovery (tracks A and B) into wip/p11-app ... 0aec577d64

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The Machines page and setup read the real Hub.status and Discovery.hubs ... d1793d9e2c

The stand-ins go: useHubStatus reads Hub.status (refreshed on
settings.changed and every 3 s on screen, since the listener follows the
setting by itself) and shows its hubMode.error key; useDiscoveredHubs
polls Discovery.hubs. A test pins the desktop shell's Disconnect
(Devices.revoke as the window's Bearer, no Origin) revoking both devices.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md: desktop pairing, host routing, Machines page, project moves, setup step ... 115643d51b

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Phase 11's exit end to end: a desktop finds, pairs with and works through a hub in hub mode ... ff55aef75e

test/hub/desktopEndToEnd.test.ts runs it over real sockets with the shell's own
modules (discovery, hubPin, pairing, hubLink) and the node process's layer: a
desktop code over pinned HTTPS, the node over pinned wss, a project on the
node's machine in a real git repo, a scripted session answered from the window,
Host.openProject reaching the node's (recording) desktop and refused for a
browser paired alone, an impostor pin never linking, and Disconnect revoking
both devices. nodeLayer takes a host desktop for tests; startNode keeps its logs,
so nodeOverHub waits on the refusal instead of sleeping.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Hub mode no longer renames the Mac: announce under the hub's own host name ... 343d497b46

bonjour-service publishes the SRV target with A/AAAA records for
os.hostname() by default, a name macOS's mDNSResponder owns; answering for it
from a second responder is a conflict macOS settles by renaming the computer
(Alexs-Mac-mini-691 -> -746 on turning hub mode on, and again on every run of
the real-mDNS test). The announcement now points at kanbot-<machine id>.local,
which only this hub answers for; hubs are reached by address, so nothing
else changes. The real-mDNS test checks the heard host name.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md: the hub announces under its own host name ... 1e306a1608

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

desktopEndToEnd: type the shell's pairing outcome ... f9bb98b9e5

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Discovery keeps a hub's announcements apart from one posing as it ... f8c5b0f3b9

Announcements are kept per service identity (fqdn, port, addresses), not
per the machine id they claim; one id announced with different
fingerprints is listed once per fingerprint, each marked conflict, on the
Machines card, the shell's connect list and kanbot-node discover. The
announced fingerprint is labelled unverified, and discover no longer says
to pair with it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The hub listener bounds handshakes and connections, and closes at once ... 6dfc18c6a7

A 10 s TLS handshake timeout, header and request timeouts, at most 256
connections and 32 per address; every TCP connection is tracked from
'connection', so closing the listener ends those still handshaking instead
of waiting up to 120 s for them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Browse the LAN for hubs only while someone looks for them ... 96d983161c

Discovery.hubs starts browsing and it stops 60 s after the last ask, instead
of every server process browsing mDNS from boot; LanBonjour closes its
multicast socket once nothing announces or browses.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge origin/refactor/phase-11-discovery into wip/p11-security ... c75f195bb7

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The shell keeps at most 64 announced hubs and tells changes in batches ... a7388e4336

electron/discovery.js drops the announcement heard longest ago past 64 (the
server's cap) and publishes a burst of changes as one list after 250 ms.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Another desktop opens folders for the hub only with a preset ... 8d7da23a06

The hub's launcher settings are hub-wide and any paired device can change
them, so a custom command or picked app sent over NodeHost would run on
someone else's computer. remoteHost sends the node platform's default
preset instead, and NodeHost refuses a custom or app choice from the wire
(error.remoteLauncherRefused). This machine keeps its custom launchers.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Only this computer may change hub sharing and Open with ... 8165d9b93a

Settings.update refuses the hub and launchers sections to a paired device
(mayChangeSettings -> SettingOnlyHere, error.settingOnlyHere), so a device
cannot switch hub mode off, move its port, or choose the command folders
open with. The sharing card and Settings > Open with show locked, with the
reason, when the page is not on this computer.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A project move checks again for open sessions inside its transaction ... c18e588bd2

The check before the target's networked folder call could go stale: the
scheduler's sweep may start a session meanwhile. The transaction that
moves the project now re-reads its open sessions (SQL only) and refuses
ProjectBusy, writing nothing.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The desktop's node never inherits KANBOT_HUB_FINGERPRINT ... 2521ef0814

It overrides node.json's pin, so nodeEnvironment drops it with the hub URL
and token variables.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The window hands only web and mail links to the system ... 51aa30e897

setWindowOpenHandler and will-navigate passed any scheme to
shell.openExternal; in connect mode the page is the hub's. They now go
through mayOpenExternally (electron/navigation.js): http, https, mailto,
and VS Code's file links in local mode only.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The window's pin matches an IPv6 hub's host name ... 12f04da7ef

Chromium hands setCertificateVerifyProc the bare address (fd00::1) while
new URL(pin.url).hostname keeps the brackets, so an IPv6 hub's pinned
certificate was left to Chromium and refused. Both sides are compared
without brackets, case-insensitively.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

"Connect to a hub" looks disabled when it is ... 67604691c2

Outside the desktop app the Machines card's button was disabled but kept
the primary fill (Nuxt UI only dims it to 75%); it now turns neutral and
subtle. In the setup step a disabled choice's card is dimmed too, and
from a paired device the share / alone choices are disabled (the server
refuses the hub section to a device since the previous commits).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Connect mode leaves out "Open in browser"; CLAUDE.md says who trusts whom ... 60d4d12b10

In connect mode the system browser would reach a self-signed hub with no
pin, so the tray and the Help menu offer it in local mode only. CLAUDE.md
records the trust model: a connected hub runs code on the desktop, pairing
is trust on first use (the fingerprint on the hub itself is the only check
against a relay), all devices are equally trusted, a moved project sends
its task text to the node, and a LAN neighbour can burn the code.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Headless hub: hub mode and local agents from the environment, kanbot-hub CLI, first-pairing hint ... e944dea5a6

KANBOT_HUB_ENABLED / KANBOT_HUB_PORT force the hub settings section (the
environment wins, Settings.update refuses it with SettingFromEnvironment,
Hub.status says setByEnvironment and the card shows it locked).
KANBOT_LOCAL_AGENTS=0 gives this machine a capacity of 0 (Machine.agentsOff).
kanbot-hub offer/status/health/backup talks to the server over loopback,
bundled on its own to .output/hub-cli (npm run build:hub-cli), sharing
desktop-prepare's externals vendoring (scripts/bundleExternals.mjs). The
log says how to get a first code while hub mode listens with no browser paired.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Headless hub image: Dockerfile, compose example, docs ... 3c4391d718

Multi-stage build on node:24.19.0-bookworm (pinned by digest), runtime on
bookworm-slim with git, ca-certificates and tini, as uid 1000, data in the
/data volume, hub mode forced on 7433 (the one EXPOSE), the plain listener
on the container's loopback, no local agents, kanbot-hub on PATH and as the
HEALTHCHECK. docs/headless-hub.md covers building, pairing browsers, nodes
and desktops, backups (kanbot-hub backup), upgrades, limits and security.
test/hub/dockerImage.test.ts keeps the files consistent.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md: Headless hub ... 75a3072b3f

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

KANBOT_HUB_PUBLIC_URL: where a containerised hub is reached ... 2387d3e94f

Inside a container the hub only sees its Docker address (172.17.0.x), which
it gave out in Hub.status, the pairing link, the first-pairing hint and
kanbot-hub offer. The variable (https origins, comma-separated) is given out
instead; the compose example reads it from .env.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge pull request 'Phase 12: a headless hub in Docker' (#20) from refactor/phase-12-headless into refactor/phase-11-discovery ... 5079b2df8a

Reviewed-on: https://git.selene.acl.sh/alex/Overlight/pulls/20

Merge pull request 'Phase 11: hubs on the LAN, desktop Connect mode, Machines page' (#19) from refactor/phase-11-discovery into refactor/phase-10-nodes ... df6b9a4b93

Reviewed-on: https://git.selene.acl.sh/alex/Overlight/pulls/19

Merge pull request 'Phase 10: nodes connect to the hub' (#18) from refactor/phase-10-nodes into refactor/phase-9-auth ... a76074d757

Reviewed-on: https://git.selene.acl.sh/alex/Overlight/pulls/18

Merge pull request 'Phase 9: authentication — pairing, device tokens, a per-launch token for the desktop app' (#17) from refactor/phase-9-auth into refactor/phase-8d-workspaces ... 37e66bb5de

Reviewed-on: https://git.selene.acl.sh/alex/Overlight/pulls/17

Merge pull request 'Phase 8d: npm workspaces, a publishable plugin SDK, a core with declared dependencies only' (#16) from refactor/phase-8d-workspaces into refactor/phase-8c-sqlite ... b97cbb648a

Reviewed-on: https://git.selene.acl.sh/alex/Overlight/pulls/16

alex merged commit 77b028e329 into refactor/phase-8a-routes-columns 2026-10-29 18:46:29 +01:00

alex referenced this pull request from a commit 2026-10-29 18:46:32 +01:00

Merge pull request 'Phase 8c: drizzle and better-sqlite3 out, one node:sqlite connection, no native module' (#15) from refactor/phase-8c-sqlite into refactor/phase-8a-routes-columns

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Overlight/App!15

No description provided.