Both are pluggable seams (dev-plan-4.md §1.2 items 1-2), same shape as
T20's sendVerificationEmail: a fixed env var gates a real vendor call
that isn't implemented yet (none has been picked), and the no-vendor
path is what actually runs today.
describeGarmentImage() — mode 2 has no admin around to hand-write
garments.appearanceDescriptor the way admin_seed garments do, so it
needs *something* non-empty to fill that field; today that's a fixed
placeholder string, swapped for a real vision-model call once a
vendor's picked.
moderateGarmentImage() — the requirements doc flags image-content
moderation as vendor-TBD but never actually lists it as its own task;
this fills that gap. Every call writes a moderation_log row (new
dressup-store.js export, M.9 schema) regardless of which branch runs,
so the audit trail exists before a real vendor does. Default-permissive
when unconfigured — T2's upload endpoint already enforces the real
trust-boundary checks (magic-byte type check, 8MB cap, EXIF-stripped
re-encode); this only covers the *content* check, which nothing here
can perform without a vendor.
Neither is unit-tested standalone (server.js doesn't export internal
functions, matching sendVerificationEmail's existing precedent) — T27
integration-tests both through the actual upload endpoint.
Also adds pricing.js to the tmpdir file-copy list in every test that
spawns server.js in isolation — server.js now requires it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011DUiYs6UjxDMkfvnjtsKFo