Confirmed live: opening the member list crashed with "TypeError: target is
not callable" inside React's renderWithHooks. afterRendered patched
element.type directly, which works for plain function components but not
for UserRow (React.memo()-wrapped): patching the non-callable memo wrapper
object replaces it with a proxy whose *own* stub is callable, which makes
`typeof element.type === 'function'` true even though the real value is a
memo object - React's reconciler checks that before checking $$typeof, so it
takes the plain-function-component path and calls the proxy directly, whose
apply trap forwards to Reflect.apply(realMemoWrapper, ...) and throws, since
the real wrapper was never callable.
Fix: detect a memo-wrapped type and patch its inner .type (the actual render
function memo hides) instead of the wrapper itself - genuinely callable, and
leaves the wrapper's own shape untouched so React's type detection stays
correct. Shared in lib/afterRendered.ts, so it fixes UserRow now and any
future memo-wrapped target automatically.
The previous deploy (staff-tags 1.0.5) failed CI at this exact step with a
raw "Failed to parse JSON" error, even though the deploy itself had
succeeded seconds earlier (confirmed live) - Cloudflare's edge needs a
moment to propagate a fresh deploy, and the script had no res.ok check to
turn a transient non-OK response into a clear message, let alone retry it.
Two of the three previously-broken module lookups now have well-evidenced
fixes (from live sweeps run during an earlier debugging session that were
never actually applied to the code):
- details.tsx: UserRow is React.memo()-wrapped, so a plain withName('UserRow')
can never match it (memo wrapper objects have no .name). Added
withMemoDefaultName (lib/filters.ts), a custom filter checking the wrapper's
inner .type.name instead, matching on the full module namespace so the
callback gets the wrapper itself - the exact reference afterJSX needs.
- name.tsx: HeaderName doesn't exist under that name anymore; ChannelHeader
is the confirmed replacement (a plain, non-memo function, found via a
name-sweep).
DisplayName (the message-author-name row) remains unresolved - never found
under any name across two live sweep sessions, likely inlined into a bigger
component now. Left as a documented, still-guarded no-op rather than guessed
at.
- Commit bun.lock (removes bun.lock/bun.lockb/package-lock.json/deno.lock
from .gitignore) so CI reads a pinned revision of the git-dependency
@revenge-mod/plugin-cli, which build.gradle.kts already declared as a
buildJs input but never had a committed file to read.
- Pin wrangler as a devDependency (4.120.0, matching the version already
live) so `bunx wrangler deploy` resolves the local pinned install instead
of "latest" at every run; verified empirically that bunx follows the
local pin, not the cache/latest version.
- Pin bun-version in oven-sh/setup-bun@v2 to 1.3.14, the version already in
use, so CI's toolchain isn't a moving target either.
- Add a post-deploy CI step (.github/scripts/verify-deploy.mjs) that fetches
the live index.json, and downloads and sha256-verifies one artifact against
the hash the index claims for it, failing the workflow on any mismatch.
This promotes the manual verification done during implementation into a
permanent regression check.
- Add concurrency (cancel superseded deploys on rapid pushes),
workflow_dispatch (manual redeploy without an empty commit), and an
explicit permissions: contents: read block to deploy.yml.
- Document in README.md that next.jarviscli.dev auto-deploys on every push
to main, and that a plugin change without a manifest.json version bump
silently republishes the same version pointer with different bytes,
so already-installed clients never see the update.
Includes the already-applied package.json fix (build/build:dev/generate-index/serve
now invoke @revenge-mod/plugin-cli via bun directly, bypassing its broken
node-shebang delegation that crashed both bun run build and Gradle's
packageAllPlugins).
Scopes the immediate blocker (no reachable install URL for the phone) separately
from the showcase site and draft-editing phases, which depend on Classic's
single-file plugin model in ways Next's zip+manifest format doesn't share.
