feat(assets): the panel that operates the client-file imports (Phase 8) #41

Merged
whitlocktech merged 2 commits from feat/asset-bridge-p8 into edge 2026-09-14 16:15:17 +00:00
Member

The Asset Bridge, phase 8 — the admin surface. module-uo only; protocol stays 8 and EXTRACTOR_VERSION stays 3, because nothing on the wire changed.

What shipped

Admin → Client Files, one page over the three things that come out of the operator's UO client:

Section What it does
Creature portraits Status, the last import's summary, Update / Re-import everything, and the vanished-key review
Item and land pictures Counts, which families the shard's overlay serves, and a warm pass on demand
Item and title names (clilocs) Status, Update / Re-import, and the overlay path setting

One page rather than three because they are one job: same client install, same bridge, and every one of them changes at the same moment — when the operator patches that client. Boot never asks the shard for any of it, so these buttons are the only thing that imports.

The cliloc pair had had no UI at all since phase 2. On a bridged install, where boot deliberately stopped calling the shard, that meant curl was the only way to load 67,496 names.

The four decisions (org lead, 2026-09-14)

  1. One page, three sections, one nav row.
  2. §14's "activity view" is the last import's own summary (shard_asset_meta.last), not a filtered feed — which kept this to one repo. The rejected alternative was an action-prefix filter on core's activity list plus a ctx.activity.list helper and a MODULE_API bump, to re-read rows the panel can keep itself.
  3. A vanished key is reviewed in the page, not in a table. The atlas persists its equivalent because boot re-parses and would re-prompt forever; an asset import only happens because someone pressed a button here.
  4. Two named buttons, §6's own vocabulary, rather than one button and a force checkbox — they cost wildly different things.

The review shows each vanished key's picture, because body/820/a23 names nothing a human recognises and "is it right that these disappear?" cannot be answered from a list of keys.

The live walk, and the two deletions it found

Against the real rig (ServUO → sidecar → site): 1,095 portraits in 3.5 s, 313 item pictures warmed in 0.6 s, 67,496 cliloc rows in 1.7 s, and the bestiary rendering portraits afterwards.

It also found two defects that predate this phase and that no test could see, because only a screen showing the numbers together makes them visible — both of them deletions:

  • Every item picture reported as vanished. The import diffs what the site holds against a manifest, and a manifest is of one family by construction — but the held side read the whole table. Correct when phase 3 wrote it; wrong from phase 5, which put static/land rows beside the body catalogue. On the rig, all 313 item pictures were staged for deletion under a sentence saying the shard had stopped offering them.
  • An approved vanish deleted the file and kept the row. The catalogue went on counting a picture that was gone, the atlas derivation could point a creature page at a missing file, and the next forced import staged the same key again — reporting "nothing was changed" about a file it had already deleted. Removals now go into saveAssets's own transaction.

The same whole-table read made the panel's first render announce a 1,408-row creature catalogue on an install holding 1,095 portraits and 313 item pictures.

Three UI defects the walk found and fixed as well: the page threw the operator back to the top and lost its result message after every action (a full loading refresh), the review banner stayed up after the approve it asked for had already applied, and two different rows shared the label "Creatures matched".

Tests

server 720 pass, client 45 pass, chunk rebuilt, check:imports / check:bundle / check:swagger / check:externals green. New coverage: the family-scoped diff and count, the row-deleting approve, the vanished rows carrying their file, the import summary and its best-effort write, and linked.

Docs: RunicGateway/docs#243v8.md §12.2/§14/§16, plus CLILOCS.md, SPAWN_ATLAS.md and modules/uo/API.md.

AI-assisted contribution

Written with Claude Code (Claude Opus 5). Commits carry the Co-Authored-By trailer.

🤖 Generated with Claude Code

https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4

The Asset Bridge, phase 8 — the admin surface. `module-uo` only; protocol stays **8** and `EXTRACTOR_VERSION` stays **3**, because nothing on the wire changed. ## What shipped **Admin → Client Files**, one page over the three things that come out of the operator's UO client: | Section | What it does | |---|---| | Creature portraits | Status, the last import's summary, **Update** / **Re-import everything**, and the vanished-key review | | Item and land pictures | Counts, which families the shard's overlay serves, and a warm pass on demand | | Item and title names (clilocs) | Status, Update / Re-import, and the overlay path setting | One page rather than three because they are one job: same client install, same bridge, and every one of them changes at the same moment — when the operator patches that client. Boot never asks the shard for any of it, so **these buttons are the only thing that imports**. The cliloc pair had had no UI at all since phase 2. On a bridged install, where boot deliberately stopped calling the shard, that meant `curl` was the only way to load 67,496 names. ## The four decisions (org lead, 2026-09-14) 1. **One page**, three sections, one nav row. 2. §14's "activity view" is the **last import's own summary** (`shard_asset_meta.last`), not a filtered feed — which kept this to one repo. The rejected alternative was an action-prefix filter on core's activity list plus a `ctx.activity.list` helper and a `MODULE_API` bump, to re-read rows the panel can keep itself. 3. A vanished key is reviewed **in the page, not in a table**. The atlas persists its equivalent because *boot* re-parses and would re-prompt forever; an asset import only happens because someone pressed a button here. 4. **Two named buttons**, §6's own vocabulary, rather than one button and a `force` checkbox — they cost wildly different things. The review shows each vanished key's **picture**, because `body/820/a23` names nothing a human recognises and "is it right that these disappear?" cannot be answered from a list of keys. ## The live walk, and the two deletions it found Against the real rig (ServUO → sidecar → site): **1,095 portraits in 3.5 s**, **313 item pictures warmed in 0.6 s**, **67,496 cliloc rows in 1.7 s**, and the bestiary rendering portraits afterwards. It also found two defects that **predate this phase** and that no test could see, because only a screen showing the numbers together makes them visible — both of them deletions: - **Every item picture reported as vanished.** The import diffs what the site holds against a manifest, and a manifest is of one family by construction — but the held side read the **whole table**. Correct when phase 3 wrote it; wrong from phase 5, which put `static`/`land` rows beside the body catalogue. On the rig, all **313 item pictures were staged for deletion** under a sentence saying the shard had stopped offering them. - **An approved vanish deleted the file and kept the row.** The catalogue went on counting a picture that was gone, the atlas derivation could point a creature page at a missing file, and the next forced import staged the same key again — reporting *"nothing was changed"* about a file it had already deleted. Removals now go into `saveAssets`'s own transaction. The same whole-table read made the panel's first render announce a **1,408-row creature catalogue** on an install holding 1,095 portraits and 313 item pictures. Three UI defects the walk found and fixed as well: the page threw the operator back to the top and lost its result message after every action (a full `loading` refresh), the review banner stayed up after the approve it asked for had already applied, and two different rows shared the label "Creatures matched". ## Tests `server` 720 pass, `client` 45 pass, chunk rebuilt, `check:imports` / `check:bundle` / `check:swagger` / `check:externals` green. New coverage: the family-scoped diff and count, the row-deleting approve, the vanished rows carrying their file, the import summary and its best-effort write, and `linked`. Docs: **RunicGateway/docs#243** — `v8.md` §12.2/§14/§16, plus `CLILOCS.md`, `SPAWN_ATLAS.md` and `modules/uo/API.md`. ### AI-assisted contribution Written with Claude Code (Claude Opus 5). Commits carry the `Co-Authored-By` trailer. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
wtclaude added 1 commit 2026-09-14 13:11:20 +00:00
feat(assets): the panel that operates the client-file imports (Phase 8)
Some checks failed
PR Checks / frozen-manifest (pull_request) Successful in 1m3s
PR Checks / server-tests (pull_request) Successful in 8m4s
PR Checks / client-build (pull_request) Failing after 14m21s
675e879b48
Admin -> Client Files: one page over the three things that come out of the
operator's UO client -- creature portraits, item and land pictures, and the
cliloc table. One page rather than three because they are one job: same client
install, same bridge, and all of them change at the same moment, when the
operator patches that client. Boot never asks the shard for any of it, so these
buttons are the only thing that imports.

The cliloc pair had had no UI at all since phase 2. On a bridged install, where
boot deliberately stopped calling the shard, that meant `curl` was the only way
to load 67,496 names.

Update and Re-import everything are section 6's two stages as two buttons rather
than one button and a checkbox, because they cost wildly different things. A
vanished key is reviewed in the page and not in a table -- an asset import only
happens because someone pressed a button here, so the review is already in front
of the person who caused it -- and it shows each key's PICTURE, since
`body/820/a23` names nothing a human recognises. `shard_asset_meta` gained a
`last` block (what the import did, who ran it) so the panel can answer "did last
week's import do anything" without scrolling core's whole activity log.

The live walk against a real shard imported 1,095 portraits in 3.5 s, warmed 313
item pictures in 0.6 s and reloaded 67,496 cliloc rows in 1.7 s -- and found two
DELETIONS that predate this phase and that no test could see, because only a
screen showing the numbers together makes them visible:

  * The body import diffed its manifest against every family's rows. Phase 5 put
    item and land art in the same table, and a body manifest never mentions
    them, so all 313 item pictures were staged for deletion with a sentence
    saying the shard had stopped offering them.
  * An approved vanish unlinked the sprite and kept the row. The catalogue went
    on counting a picture that was gone, the atlas could point a creature page at
    a missing file, and the next forced import offered the same key for review
    again -- reporting "nothing was changed" about a file it had deleted.

Both fixed here, with the removals now inside `saveAssets`'s own transaction.
The same whole-table read made the panel announce a 1,408-row creature catalogue
on an install holding 1,095 portraits and 313 item pictures.

Protocol stays 8 and EXTRACTOR_VERSION stays 3: nothing on the wire changed.

Refs: docs/link/v8.md sections 12.2, 14, 16 (phase 8)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
wtclaude added 1 commit 2026-09-14 16:07:59 +00:00
ci: re-run the client checks
All checks were successful
PR Checks / server-tests (pull_request) Successful in 27s
PR Checks / frozen-manifest (pull_request) Successful in 1m1s
PR Checks / client-build (pull_request) Successful in 7m59s
5705aa9c23
Run 68's client-build spent 14m21s in "Set up job" and then failed every step
at 0s with no log uploaded — the runner died during container setup. The same
commit's server-tests and frozen-manifest jobs passed, and frozen-manifest built
this very chunk on the same runner. Nothing in the tree changed; this is the
push the workflow needs to run again (pr-checks has no workflow_dispatch).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
whitlocktech merged commit 5c35b4fe97 into edge 2026-09-14 16:15:17 +00:00
whitlocktech deleted branch feat/asset-bridge-p8 2026-09-14 16:15:19 +00:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: RunicGateway/Module-uo#41
No description provided.