The memory box accepts empty and over-long text and reports Memory saved., while the assistant's own writer refuses both #1847

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 343b79bd78cd44939e49af1d77bc3931
Branch: dev/1-p237-memory-write-bounds
Base: b4e05ac
At: 2026-10-30T15:06:00Z

Baseline

Re-read on live main b4e05acf9c2785eced88e94f1b70e4f15c860c9f (2026-10-30). core/src/host/store.js case 'project-memory-write' :645-650 (gate :647, appendProjectMemory call :648), appendProjectMemory :500-510 (kind check :502, the stored text :507); core/src/host/project-assistant.js const entry = text(body.text) :186, the two refusals :187-188; the panel quotes the host through hostText in run() core/src/client/project-board.js:460-469.

What happens

The Project settings memory box accepts text the product itself refuses elsewhere, and tells the owner it worked:

• An empty textarea + Save memory → status line Memory saved., and a memory row of length 0 is appended.
• More than 600 characters → the same Memory saved., and the entry is silently truncated to 600.

After #1823 this path is user-reachable for the first time (the panel now sends a kind the host accepts), so an owner can accumulate blank "memory entries" she never wrote — and once P-228's read-back lands, those rows appear in the panel as entries with no text.

Why the endpoint does not refuse (live main b4e05acf)

• The endpoint only checks the kind and the owner gate: core/src/host/store.js:645-650 — case 'project-memory-write' → requireProjectOwner(readProject(id), actor) (:647), then appendProjectMemory(id, projectText(body.kind, 20), body) (:648).
• appendProjectMemory (store.js:500-510) validates the kind only — :502 if (kind !== 'decision' && kind !== 'question') throw projectRefusal(...). The text is stored as :507 text: projectText(entry.text, 600): projectText trims and slices, so '' stays '' and 700 chars becomes 600, and both return ok.
• The product's own two refusals live in the assistant writer, which is a different door: core/src/host/project-assistant.js:187-188 — throw refusal('A Project memory entry needs text') when empty, and throw refusal(\A Project memory entry is at most ${MAX_ENTRY} characters`)when over the cap. That writer is onrt.projectAssistant` and never runs on the endpoint path.

So the two boundaries exist in the codebase and are enforced on the road nobody takes.

Reproduction

Probe run by FlyBot Product on a clean tree at 6d969ea5 (core/test/probe-memory-write.test.js = a copy of the panel suite plus two probe cases; 8 pass, exit 1):

PROBE A empty text: ok, decisions=1, last.text.length=0
PROBE B 700 chars: ok, decisions=1, last.text.length=600

And through the panel with an empty textarea: status line "Memory saved.", decisions grows by {"len":0,"head":""}. The anchors above were re-read on live main b4e05acf and are unchanged.

Expected

1. Empty text is refused by the host with the existing sentence (A Project memory entry needs text) and nothing is written: the memory table is byte-for-byte what it was.
2. Text over the cap is refused with the existing sentence (A Project memory entry is at most 600 characters) and nothing is written — no silent truncation.
3. Text of exactly the cap is accepted and stored verbatim (length 600, no trim surprise beyond the existing projectText handling).
4. The panel shows the refusal instead of Memory saved.: the status line is the host's sentence, in zh when the UI is zh, and no row is added.
5. The kind gate and the owner gate keep their current behaviour (#1820/#1823 fixed the kind; do not move it).

Fix shape

Validate in appendProjectMemory (the single write door) against the same bound the assistant writer uses, rather than only in the endpoint, so any future caller inherits the rule. Two refusals, same wording as project-assistant.js:187-188. MAX_ENTRY should be one exported constant used by both writers, not two literals.

The panel needs nothing added for correctness — it already quotes the host's message through hostText (core/src/client/project-board.js:460-469); it needs the two zh entries so a zh reader reads them in Chinese.

Scope

• core/src/host/store.js — the two refusals in appendProjectMemory (:500-511); no change to project-memory-write's gate order.
• core/src/host/project-assistant.js — only if MAX_ENTRY moves to a shared export; its behaviour stays as it is.
• core/src/client/i18n.js — two zh entries: an exact key for A Project memory entry needs text, and a regex for the capped sentence (it carries the number: [/^A Project memory entry is at most (\d+) characters$/, …]).
• core/client.js — regenerated bundle.
• one test — extend core/test/project-board-panels.test.js through the real projectEndpoint: empty (refused, table unchanged), 601 (refused, table unchanged), 600 (accepted, stored length 600).
• generated files, never hand-edited: node scripts/ds-bot-patches.mjs generate, then commit exactly what it rewrites — patches/ds-bot/0001-core-fixes.patch for the host and i18n.js, patches/ds-bot/0008-client-bundle.patch + patches/ds-bot/files/src/client/project-board.js for the bundle side. check's three ok lines must be green.
• a changelog fragment in changelog.d/, named after this issue's number with -memory-write-bounds.fixed.md, carrying the issue link in its text.

Acceptance

• project-memory-write with text: '' → rejected with A Project memory entry needs text; projectMemory(id).decisions.length unchanged; project.updatedAt unchanged.
• text of 601 characters → rejected with A Project memory entry is at most 600 characters; nothing written.
• text of exactly 600 characters → accepted; stored text length 600 and the content matches what was sent.
• Panel, zh: empty box + Save → status line is the Chinese refusal, Memory saved. never appears, no row added.
• npm run verify green, check green, build-client --check green.

Duplicate check

search/issues on repo:ThinkFlowLab/FlyBot, open and closed: "Pause the daily digest" / memory kind searches return #1820 (the Save memory button always failing), #1823 (its fix), #1733/#1759 (assistant settings) — none about bounds on the memory text. git grep -n "needs text\|at most" b4e05acf -- core/src shows the two refusals exist only in project-assistant.js, so no fix is pending elsewhere.