max / makenotwork

Say what fw13's bentod actually listens on, and that libraries have a recipe The stand-up section described the example config rather than the install. fw13 binds the tailnet address with BENTO_API_TOKEN set, so the documented `curl 127.0.0.1:8765/state` verify step connects to nothing, and the claim that no token is required was true only of the loopback default. A trigger against the wrong address returns no answer at all, which reads as a daemon problem rather than an address one. The token form now reads both the address and the token out of the files that hold them, so neither lands in shell history, and the read endpoints are marked as staying open. bento.env gains a row in the file table. It holds the token, so no example ships and the unit's EnvironmentFile is prefixed `-` to make it optional. The recipe table listed the three apps and implied a per-platform recipe was the only shape. Libraries take a single publish.rhai, all nine configured ones now have it, and it asserts HEAD is exactly a tag: worth saying, because the crates published by hand before they were wired up have no tag to assert.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Max Johnson <me@maxj.phd> · 2026-07-30 02:19 UTC

Signed with PGP, not checked

Commit: e4b96dcf16f2ef6e0ba5503dec2a938b9f39d804

Parent: f92eb50

1 file changed, +32 insertions, -6 deletions

M bento/deploy/README.md +32 -6

			@@ -16,6 +16,7 @@
16	16		\| `bentod.service` \| `~/.config/systemd/user/` \| The user service unit. \|
17	17		\| `bento-daemon.toml.example` \| `~/.config/bento/bento-daemon.toml` \| Daemon-local config (paths + listen). Absolute paths only — no shell expansion. \|
18	18		\| `bento.toml.example` \| `~/.config/bento/bento.toml` \| Build topology (hosts + apps). `repo` paths are tilde-expanded. \|
	19	+	\| (none, hand-written 0600) \| `~/.config/bento/bento.env` \| `BENTO_API_TOKEN=...` for a tailnet bind. Read by the unit's `EnvironmentFile=-`, so a loopback install can leave it absent. No example file ships: it holds a secret. \|
19	20
20	21		## Stand-up (no root except enable-linger)
21	22
			@@ -37,17 +38,33 @@
37	38		systemctl --user daemon-reload
38	39		systemctl --user enable --now bentod
39	40
40		-	# 4. Verify
	41	+	# 4. Verify (address must match `listen` in bento-daemon.toml, see Auth below)
41	42		curl -s http://127.0.0.1:8765/state \| python3 -m json.tool
42	43		```
43	44
44	45		## Auth (CF2)
45	46
46		-	On the loopback bind above, build triggers are reachable only from fw13, so no
47		-	token is required. To operate bentod over the tailnet, bind the tailnet IP in
48		-	`bento-daemon.toml` and set `BENTO_API_TOKEN` via an `EnvironmentFile` in the
49		-	unit — bentod refuses to start on a non-loopback bind without it (same posture
50		-	as Sando's `SANDO_API_TOKEN`).
	47	+	On a loopback bind, build triggers are reachable only from the daemon's own
	48	+	host, so no token is required. To operate bentod over the tailnet, bind the
	49	+	tailnet IP in `bento-daemon.toml` and set `BENTO_API_TOKEN` via an
	50	+	`EnvironmentFile` in the unit. bentod refuses to start on a non-loopback bind
	51	+	without it (same posture as Sando's `SANDO_API_TOKEN`).
	52	+
	53	+	fw13 runs the second form, not the loopback default the example config
	54	+	ships. `listen` is the tailnet address and `/build` and `/retry` require the
	55	+	bearer token, so a `127.0.0.1` curl gets no answer at all rather than an auth
	56	+	error. Read the address out of the config and the token out of its own file
	57	+	rather than passing either on a command line:
	58	+
	59	+	```sh
	60	+	set -a; . ~/.config/bento/bento.env; set +a
	61	+	curl -s -X POST http://$(grep -oP '(?<=^listen = ")[^"]+' ~/.config/bento/bento-daemon.toml)/build \
	62	+	-H "authorization: Bearer $BENTO_API_TOKEN" -H 'content-type: application/json' \
	63	+	-d '{"app":"makeover-webview","version":"0.5.1"}'
	64	+	```
	65	+
	66	+	`/state`, `/status.json` and the log endpoints are read-only and unauthed, so
	67	+	watching a run needs the address but not the token.
51	68
52	69		## Recipes
53	70
			@@ -63,6 +80,15 @@
63	80		¹ BB has no Developer ID signing / notarization infra or iOS project yet, so its
64	81		macOS/iOS recipes are deferred until that lands. BB ships in a later wave.
65	82
	83	+	A library crate (`kind = "library"` in its own `bento.toml`) has no per-platform
	84	+	artifact, so the runner reads a single `publish.rhai` instead of the table above.
	85	+	Every library configured in the topology now carries one: `makeover`,
	86	+	`makeover-geometry`, `makeover-build`, `makeover-webview`, `makeover-layout`,
	87	+	`pter`, `everycycle`, `supernote-push`, `alloy_tui`. That recipe asserts HEAD is
	88	+	exactly a tag before it uploads, so a release wants `git tag -a v<version>`
	89	+	first; a crate published by hand before it was wired up has no such tag, and its
	90	+	next release is the one that gets one.
	91	+
66	92		A `linux.rhai` serves both arches — `build_host()` resolves to the native host
67	93		the topology assigns the target (`linux/x86_64` → fw13, `linux/aarch64` → astra),
68	94		so there is no cross-compilation and no hard-coded host name. macOS/iOS recipes