platform

1,334 Commits 4 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
pastilhas	027b10bd6e	step 4/4: the docs say permissions too, and capability means one thing again 44 files of prose — CLAUDE.md, AGENTS.md, TODO.md, 20 docs, both plugin design documents, and the comment surface the earlier steps could not reach. Applied against an explicit keep-list, not swept, because the word turned out to have SIX meanings in this repository rather than the three the offscale doc recorded: permissions renamed (steps 1–2) $OFFICER_ROOT/capabilities/ KEPT — the item store, and now the only thing the word means that is ours sidecar routing keys renamed to `handles` (step 3) Lightning wallet KEPT — a domain term, and on the wire to the mobile apps terminfo queries KEPT — XTGETTCAP, in the pty sidecar InvoiceShelf KEPT — per-resource { write, bulkDelete } flags The sweep still falsified two things, both caught by checking rather than by review, and both in prose that discusses more than one meaning at once: CLAUDE.md began claiming the item store lives at `$OFFICER_ROOT/permissions`. It does not; that directory is on disk and full of skills and tools. And the offscale doc's own note about the collision became "Named `permissions`, NOT `permissions`" — a sentence that had eaten the thing it existed to warn about. Both restored, and the note rewritten to say what is now true: capability means one thing of ours, and three that belong to somebody else's vocabulary. Verified live after restart: self and admin permission endpoints 200, gated route 200, agent-status 200, 9 grants intact with 6 permissions offered. tsgo clean, 797 tests, 787 pass, same 7. The rename is done. Four steps, no data lost, no client break that survived the step it was introduced in.	2026-08-15 16:31:11 +00:00
pastilhas	2e8ec845c8	step 1/4: the permission engine is called permissions, not capabilities The word meant four different things in this repo, not the three the offscale doc records: 1. the permission registry → RENAMED here 2. $OFFICER_ROOT/capabilities/ items → kept; this is what capabilities are 3. sidecar routing keys → step 3, becoming `handles` 4. Lightning wallet features → kept; a domain term, and on the wire to the mobile apps The fourth was not in the doc and a global find-and-replace would have broken the mobile wallet, which reads `{ kind, capabilities: Capability[] }` from the wallet sidecar. So this renamed against an explicit file allowlist rather than by sweeping the tree, and `CapabilityPage.tsx` — the UI for the item store, and correctly named already — was left alone. Moved: servers/capabilities/ → servers/permissions/, capability-gate.ts → permission-gate.ts, users/capabilities-routes.ts → permissions-routes.ts, hooks/useCapabilities.ts → usePermissions.ts. Identifiers follow. Three breaks the typechecker could not see, all found by exercising it live. The route paths moved with the prose sweep, so the server served /user/permissions while the frontend still called /user/capabilities. A 404 on every page load, and tsgo clean throughout. The response FIELD moved too. `client.get<SelfPermissions>()` is an unchecked cast, so `data.capabilities` became `undefined` at runtime with no compile error — `can()` would have answered "no" to everything and the dock would have emptied itself. And the grants list was passed straight out of the database, so it arrived as `{ role, capability, level }` while the screen read `grant.permission`. Every role would have rendered as holding nothing. It is now mapped in the route: the wire says `permission`, the column still says `capability`, and step 2 therefore changes nothing any client can see. The stale react-query keys were the quiet one: two files still invalidated ['self-capabilities'] after the hook moved to ['self-permissions'], so installing a plugin would have silently stopped refreshing the dock. The database is untouched — `role_capabilities` and its `capability` column are step 2, and the two call sites that cross that boundary say so in a comment. Round-tripped the 9 live grants through the admin endpoint to prove the PUT contract survived: 9 before, 9 after, Member's three intact. Also reverted prettier churn on five landing-page files that a broad --write picked up. Second time today; the lesson is not sticking. tsgo clean. 797 tests, 787 pass, same 7 pre-existing failures — two of which now read "path → permission" rather than "path → capability".	2026-08-15 16:03:22 +00:00
pastilhas	0a55964db5	the player moves to the plugin, and src/ has no music code left officerdev/src/MusicPlayer/ → plugins/music/web/. Engine, state, bar, favourites, lyrics toggle and the library vocabulary — ten files. The barrel stops exporting a player it no longer has, and DashboardLayout stops rendering one. The reasoning that kept it was removed rather than refuted. It stayed because the dashboard widget imported useMusicPlayer from officerdev and the platform cannot import from a plugin, so the state had to stay whatever was decided about the UI. The owner moved the widget into the plugin in the previous commit, and the constraint went with it: the whole remaining dependency became one line, DashboardLayout.tsx:66. MusicPlayerHost is mounted inside the MusicDetail panel. That reads odd until you notice it already returned null on /music — the mini bar is the transport there, and the host existed purely to own the GaplessEngine. In the panel it does exactly that, and the bar code stays intact for whenever there is a slot. [phase 2] Leaving /music unmounts the host and playback stops. Deferred on the owner's call; the bar was "navigating away must not break the application", and that holds: seekPlayer is optional-chained so a call with no host registered is a no-op, registerPlayerSeek clears only its own registration, the host's cleanup destroys the engine and nulls its ref, and the queue is global state so returning to /music remounts and reloads. Solving it properly needs either a shell slot a plugin can contribute to — which reopens "there is no way to export a component" — or the engine hoisted to module scope, which keeps the rule and loses only the off-route controls. Also: the parked widget now imports the player as a sibling rather than through officerdev, and shared.ts stopped being a re-export shim now that the real file is in the plugin. Verified: tsgo clean, 797 tests / 787 pass / same 7. Server restarts, mounts /example /music /offscale, / and /music both 200, and the player is in the built bundle (music.volume, music:lyrics, now-playing?device=web all present — GaplessEngine is a class name and the production build is minified, so grepping for it proves nothing). Not verified by me: what it looks like in a browser. That needs your eyes.	2026-08-15 14:42:13 +00:00

Author

SHA1

Message

Date

pastilhas

027b10bd6e

step 4/4: the docs say permissions too, and capability means one thing again

44 files of prose — CLAUDE.md, AGENTS.md, TODO.md, 20 docs, both plugin design
documents, and the comment surface the earlier steps could not reach.

Applied against an explicit keep-list, not swept, because the word turned out to
have SIX meanings in this repository rather than the three the offscale doc
recorded:

  permissions          renamed (steps 1–2)
  $OFFICER_ROOT/capabilities/  KEPT — the item store, and now the only thing
                               the word means that is ours
  sidecar routing keys renamed to `handles` (step 3)
  Lightning wallet     KEPT — a domain term, and on the wire to the mobile apps
  terminfo queries     KEPT — XTGETTCAP, in the pty sidecar
  InvoiceShelf         KEPT — per-resource { write, bulkDelete } flags

The sweep still falsified two things, both caught by checking rather than by
review, and both in prose that discusses more than one meaning at once:

CLAUDE.md began claiming the item store lives at `$OFFICER_ROOT/permissions`.
It does not; that directory is on disk and full of skills and tools.

And the offscale doc's own note about the collision became
"Named `permissions`, NOT `permissions`" — a sentence that had eaten the thing
it existed to warn about.

Both restored, and the note rewritten to say what is now true: capability means
one thing of ours, and three that belong to somebody else's vocabulary.

Verified live after restart: self and admin permission endpoints 200, gated
route 200, agent-status 200, 9 grants intact with 6 permissions offered.
tsgo clean, 797 tests, 787 pass, same 7.

The rename is done. Four steps, no data lost, no client break that survived
the step it was introduced in.

2026-08-15 16:31:11 +00:00

pastilhas

2e8ec845c8

step 1/4: the permission engine is called permissions, not capabilities

The word meant four different things in this repo, not the three the offscale
doc records:

  1. the permission registry              → RENAMED here
  2. $OFFICER_ROOT/capabilities/ items    → kept; this is what capabilities are
  3. sidecar routing keys                 → step 3, becoming `handles`
  4. Lightning wallet features            → kept; a domain term, and on the wire
                                            to the mobile apps

The fourth was not in the doc and a global find-and-replace would have broken
the mobile wallet, which reads `{ kind, capabilities: Capability[] }` from the
wallet sidecar. So this renamed against an explicit file allowlist rather than
by sweeping the tree, and `CapabilityPage.tsx` — the UI for the item store, and
correctly named already — was left alone.

Moved: servers/capabilities/ → servers/permissions/, capability-gate.ts →
permission-gate.ts, users/capabilities-routes.ts → permissions-routes.ts,
hooks/useCapabilities.ts → usePermissions.ts. Identifiers follow.

Three breaks the typechecker could not see, all found by exercising it live.

The route paths moved with the prose sweep, so the server served
/user/permissions while the frontend still called /user/capabilities. A 404 on
every page load, and tsgo clean throughout.

The response FIELD moved too. `client.get<SelfPermissions>()` is an unchecked
cast, so `data.capabilities` became `undefined` at runtime with no compile
error — `can()` would have answered "no" to everything and the dock would have
emptied itself.

And the grants list was passed straight out of the database, so it arrived as
`{ role, capability, level }` while the screen read `grant.permission`. Every
role would have rendered as holding nothing. It is now mapped in the route:
the wire says `permission`, the column still says `capability`, and step 2
therefore changes nothing any client can see.

The stale react-query keys were the quiet one: two files still invalidated
['self-capabilities'] after the hook moved to ['self-permissions'], so
installing a plugin would have silently stopped refreshing the dock.

The database is untouched — `role_capabilities` and its `capability` column are
step 2, and the two call sites that cross that boundary say so in a comment.
Round-tripped the 9 live grants through the admin endpoint to prove the PUT
contract survived: 9 before, 9 after, Member's three intact.

Also reverted prettier churn on five landing-page files that a broad --write
picked up. Second time today; the lesson is not sticking.

tsgo clean. 797 tests, 787 pass, same 7 pre-existing failures — two of which
now read "path → permission" rather than "path → capability".

2026-08-15 16:03:22 +00:00

pastilhas

0a55964db5

the player moves to the plugin, and src/ has no music code left

officerdev/src/MusicPlayer/ → plugins/music/web/. Engine, state, bar,
favourites, lyrics toggle and the library vocabulary — ten files. The barrel
stops exporting a player it no longer has, and DashboardLayout stops rendering
one.

The reasoning that kept it was removed rather than refuted. It stayed because
the dashboard widget imported useMusicPlayer from officerdev and the platform
cannot import from a plugin, so the state had to stay whatever was decided
about the UI. The owner moved the widget into the plugin in the previous
commit, and the constraint went with it: the whole remaining dependency became
one line, DashboardLayout.tsx:66.

MusicPlayerHost is mounted inside the MusicDetail panel. That reads odd until
you notice it already returned null on /music — the mini bar is the transport
there, and the host existed purely to own the GaplessEngine. In the panel it
does exactly that, and the bar code stays intact for whenever there is a slot.

[phase 2] Leaving /music unmounts the host and playback stops. Deferred on the
owner's call; the bar was "navigating away must not break the application", and
that holds: seekPlayer is optional-chained so a call with no host registered is
a no-op, registerPlayerSeek clears only its own registration, the host's
cleanup destroys the engine and nulls its ref, and the queue is global state so
returning to /music remounts and reloads. Solving it properly needs either a
shell slot a plugin can contribute to — which reopens "there is no way to
export a component" — or the engine hoisted to module scope, which keeps the
rule and loses only the off-route controls.

Also: the parked widget now imports the player as a sibling rather than through
officerdev, and shared.ts stopped being a re-export shim now that the real file
is in the plugin.

Verified: tsgo clean, 797 tests / 787 pass / same 7. Server restarts, mounts
/example /music /offscale, / and /music both 200, and the player is in the
built bundle (music.volume, music:lyrics, now-playing?device=web all present —
GaplessEngine is a class name and the production build is minified, so grepping
for it proves nothing).

Not verified by me: what it looks like in a browser. That needs your eyes.

2026-08-15 14:42:13 +00:00