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

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
This commit is contained in:
2026-09-14 08:10:16 -05:00
parent 7dbdaa14ad
commit 675e879b48
13 changed files with 1451 additions and 54 deletions

View File

@@ -102,6 +102,42 @@ test('admin atlas actions use the right methods and bodies', async () => {
assert.deepEqual(calls[1].opts.body, { path: '/srv/servuo' })
})
// ── the Asset Bridge's two stages (docs/link/v8.md §6) ──────────────────────
// Update and Re-import are one route and differ only by `force`, and the
// difference is not cosmetic: one transfers nothing when the client files are
// unchanged, the other fetches the whole catalogue. A binding that sent `force`
// on both would make the cheap button the expensive one, and nothing visible
// would change — the pictures would be correct either way.
test('assets.update asks for the diff and assets.reimport asks for everything', async () => {
await admin.assets.update()
assert.equal(calls[0].url, '/api/v1/admin/shard/assets/import')
assert.equal(calls[0].opts.method, 'POST')
assert.deepEqual(calls[0].opts.body, { approve: false })
await admin.assets.reimport()
assert.deepEqual(calls[1].opts.body, { force: true, approve: false })
})
// Approving a vanished key re-runs the SAME operation the operator pressed, so
// `approve` has to ride on both. Sending the update's approval as a re-import
// would quietly turn "yes, accept those deletions" into a full re-download.
test('approve rides on whichever import the operator ran', async () => {
await admin.assets.update(true)
await admin.assets.reimport(true)
assert.deepEqual(calls[0].opts.body, { approve: true })
assert.deepEqual(calls[1].opts.body, { force: true, approve: true })
})
test('cliloc admin actions use the right methods and bodies', async () => {
await admin.clilocs.import({ force: true })
assert.equal(calls[0].url, '/api/v1/admin/shard/clilocs/import')
assert.deepEqual(calls[0].opts.body, { force: true, approve: false })
await admin.clilocs.setPath('/srv/uo-client')
assert.equal(calls[1].opts.method, 'PUT')
assert.deepEqual(calls[1].opts.body, { path: '/srv/uo-client' })
})
// ── path encoding ───────────────────────────────────────────────────────────
// A city name with an apostrophe and a space is the real case: "Serpent's Hold"
// is a governor city, and an unencoded one would break the route match rather

View File

@@ -120,7 +120,7 @@ const it = (name, fn) => test(name, { skip: skip && 'no dist/entry.js — run np
it('registers routes in all three areas, namespaced under the module id', () => {
const { routes } = registered
assert.equal(routes.public.length, 13)
assert.equal(routes.admin.length, 7)
assert.equal(routes.admin.length, 8)
assert.equal(routes.player.length, 2)
for (const area of ['public', 'admin', 'player']) {
for (const r of routes[area]) {