feat(assets): the panel that operates the client-file imports (Phase 8) #41
Reference in New Issue
Block a user
No description provided.
Delete Branch "feat/asset-bridge-p8"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The Asset Bridge, phase 8 — the admin surface.
module-uoonly; protocol stays 8 andEXTRACTOR_VERSIONstays 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:
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
curlwas the only way to load 67,496 names.The four decisions (org lead, 2026-09-14)
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 actx.activity.listhelper and aMODULE_APIbump, to re-read rows the panel can keep itself.forcecheckbox — they cost wildly different things.The review shows each vanished key's picture, because
body/820/a23names 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:
static/landrows 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.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
loadingrefresh), the review banner stayed up after the approve it asked for had already applied, and two different rows shared the label "Creatures matched".Tests
server720 pass,client45 pass, chunk rebuilt,check:imports/check:bundle/check:swagger/check:externalsgreen. 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, andlinked.Docs: RunicGateway/docs#243 —
v8.md§12.2/§14/§16, plusCLILOCS.md,SPAWN_ATLAS.mdandmodules/uo/API.md.AI-assisted contribution
Written with Claude Code (Claude Opus 5). Commits carry the
Co-Authored-Bytrailer.🤖 Generated with Claude Code
https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
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