marketplace.officer.dev is live, and the plugin repos have READMEs

The site is up on HTTPS with a Let's Encrypt certificate, proxied to :9100, and
serving the three plugins out of `officer_marketplace`. An Officer install with no
configuration now reads its catalogue from it.

── What is running ──

PM2 entry added to THIS machine's ecosystem only. Deliberately not in
officer-setup's CORE_PROCESSES: the marketplace is one website officer.dev hosts,
not something every install should run — a copy on every machine would serve a
stale catalogue on a port nobody asked to open.

nginx (NPM host id 7) → 172.20.0.1:9100, with a ufw rule for the docker bridge.
That rule is not optional and its absence does not look like a firewall problem:
without it nginx HANGS until proxy_connect_timeout rather than being refused,
which is how the apptest hosts wasted an hour a few days ago.

── READMEs ──

`music`, `offscale` and `example` now have proper READMEs, written against their
own code and pushed to their own repos. They render on the plugin's page in the
store and are what a self-hoster reads before installing. The example's is a
tutorial as much as a shop window — it is the document a plugin author reads
first, and every convention in it was verified in `discover.ts` rather than
restated from memory.

`music`'s remote was HTTPS with no credentials on this box, so it could not be
pushed; switched to SSH like the other two. The catalogue still advertises HTTPS —
`marketplace-sync` converts — which is the property that matters, since an
`ssh://` clone URL only works on the machine that published it.

── Writing them was the cheapest audit available ──

Reading each plugin against its own documentation turned up ~20 real defects, all
recorded in TODO.md and none fixed here. The pattern worth naming: offscale is
still branded "headscale" in user-visible panel names and in a persisted terminal
session id, and its PLUGIN.md states outright that the ACL assistant is
deliberately unwired — while `sidecar/assist.ts`, `claude-proxy.ts` and
`PolicyAssistant.tsx` all ship. Documentation that confidently describes the
opposite of the code is worse than none.

Also fixed the docs on the frozen lockfile: both CLAUDE.md and bunfig.toml named
`bun install --no-frozen-lockfile` as the escape hatch, and bun 1.3.14 has no such
flag — it is ignored and the install fails anyway.

tsgo clean, 873 pass / 7 fail unchanged.

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

This commit is contained in:

pastilhas

2026-08-16 04:15:34 +00:00

co-authored by

Claude Opus 5

parent 1b65b83f1f

commit 53742a256f

4 changed files with 201 additions and 6 deletions

									
										bunfig.toml
									
		+5
		-2
	
												View File
												
				@@ -9,8 +9,11 @@

				# transitive range is all it takes; a frozen lockfile is the difference between "we were not affected"

				# and "we ran `bun install` on the wrong afternoon".

				#

				# When a dependency genuinely needs to change: edit package.json, run `bun install --no-frozen-lockfile`

				# deliberately, READ the lockfile diff, and commit it. The friction is the point.

				# When a dependency genuinely needs to change: edit package.json, comment out the line below for that one

				# command, READ the lockfile diff, and put it back. The friction is the point.

				#

				# It used to say `bun install --no-frozen-lockfile`. Bun 1.3.14 has no such flag — only `--frozen-lockfile`

				# — so the documented escape hatch was ignored and the install failed anyway. Found 2026-08-16.

				[install]

				frozenLockfile = true