start-memory-core.sh aborts on macOS: full-width ） after a variable reference is parsed as part of the name

[GvAiSuperAdmin]

Summary

deploy/global-images/start-memory-core.sh fails on macOS at line 175 with:

start-memory-core.sh: line 175: ADMIN_KEY_FILE?: unbound variable

This happens after memory-core is up and healthy, so the container is left
running with no admin user created — start-all.sh never reaches memory-hub or
proxy.

Cause

Line 175 is:

info "初始化 admin user（username=${MEMORY_CORE_ADMIN_USERNAME}, key 持久化 → $ADMIN_KEY_FILE）..."

$ADMIN_KEY_FILE is immediately followed by ） (U+FF09, bytes EF BC 89).
macOS's character tables classify that as an identifier character, so bash folds
its first byte into the variable name, giving an undefined ADMIN_KEY_FILE\xEF
and aborting under set -u. glibc classifies it as punctuation, which is why
Linux is unaffected.

It is the locale, not the bash version — 3.2 and 5.3 fail identically:

for L in C en_US.UTF-8 en_IN.UTF-8; do
  printf '%-14s ' "$L"
  LC_ALL=$L bash -c 'set -u; V=works; echo "→ $V）"' 2>&1 | tail -1
done
# C            → works）
# en_US.UTF-8  bash: V?: unbound variable
# en_IN.UTF-8  bash: V?: unbound variable

Suggested fix

Brace the references wherever CJK punctuation follows one — ${ADMIN_KEY_FILE}）
— which is unambiguous in every locale. A blanket export LC_ALL=C at the top
of _lib.sh also works and is what we did locally, but bracing is the more
targeted fix.

Other scripts in deploy/global-images/ use the same pattern and will hit this
as soon as execution reaches them.

Related

verify.sh reports success with an unfunded API key, because its
OpenAI-protocol check is GET /models, which does not require credit. The first
real request then fails with 402. A minimal chat completion, or a note in the
output that /models does not prove billing, would catch this at install time.

[Maxwell-Code07]

We really appreciate your valuable feedback! Our team will conduct an internal review and assessment promptly.