[HugoXK]

Fixes #2101

Written-by: Dev-2
Owner: Dev-2
Reviewer: Reviewer
Claim-Id: 1dcfee666d624428ae95d5d57a0e3185
Branch: dev/2-memory-blocked-empty
Base: 1778add
Tip SHA: b2d5d52

What changed

A refused memory folder and a Bot that never saved anything answered the same view: entries: [],
and nothing else. folderKind() already knew the difference — real / absent / other, with the
path of the segment that failed — but the read path threw that answer away, so the panel told the
user to save something that could not be saved, and a silent refusal was indistinguishable from a
fresh Bot.

• memory-view gains blocked: one { scope, path } per scope the host refused, built from the
  existing folderKind() result (path is its at, the folder that failed). Only other counts —
  absent is the ordinary first-run home and stays out. The field is [] when nothing was refused.
• The memory panel renders one line above the existing empty title when entries is empty and
  blocked is non-empty, naming the folder and saying it is not a plain directory so it cannot be
  read. With nothing blocked the copy is byte-identical to today's.
• The decision itself is a pure, exported helper (memoryEmptyNotice(view) in
  core/src/client/memory-empty.js), because the suite has no React renderer: it is tested
  directly, like bot-row-title and the board rows.
• The new string has its DICTIONARY.zh entry; core/test/i18n.test.js fails otherwise.

Nothing about the refusal itself changed: the same other folders are refused, the same once-per-folder
keeping it empty warning is still the only host log line, and no permission, entry, summary or
archive behaviour moved.

Red first — base 1778add0, implementation absent, three runs

core/test/memory.test.js + core/test/memory-empty.test.js + core/test/i18n.test.js, three
times: 98 tests / 93 pass / 5 fail, exit 1, identical each run.

failing test	fact asserted on base
#2068: a refused memory folder is named on the memory view, not read as nothing saved (#2101)	view.blocked deep-equals [{ scope: 'own', path: <home>/memory }, { scope: 'team', path: <home>/memory }]; base answers undefined
#2101: a plain or missing memory folder blocks nothing	view.blocked deep-equals [] for an empty folder and for a home with no memory/; base answers undefined
test/memory-empty.test.js (the file)	the helper module does not exist on base
#2068: every path built from memory/ is one of the reviewed sinks	the probe list names blockedScopes, which base has no function for
#2068: every sink has its own probe, and every probe its own sink	same — a new sink without a probe is exactly what that guard refuses

The two behaviour cases came first and are the ones that matter; the last two are the module's own
sink guards, which fire because the base has no blockedScopes at all. With the implementation:
101 tests / 101 pass / 0 fail, three identical runs, exit 0.

The host case also carries its controls: the same linked folder still reads as entries: [],
fresh stays true, and the folder is still named in exactly one warning, so blocked reports the
refusal without changing what the reader answers.

Mutations

mutation	red
M1 — blockedScopes answers [] always	1: the refused-folder case (blocked is [])
M2 — blockedScopes treats absent as refused too	1: #2101: a plain or missing memory folder blocks nothing
M3 — memoryEmptyNotice answers null always	2: both blocked-view cases of the client helper

Each mutation was run alone on the fixed tree and reverted with git checkout HEAD -- <file>, so the
field, the absent distinction and the notice are each held by a test.

Verified on the tree this tip carries

TZ=UTC ARCH_DOCS_BASE=1778add0ace4254ae4d1d5290b980d024bc83de4 npm run verify, exit 0, on the
clean tree of the single commit this tip carries (one parent, 1778add0).

• core 2576/2576, plugins/social 541 (540 pass, 1 skip: social web entry activates under real Cordis once ds-bot provides flybot), plugins/tree 127 (126 pass, 1 skip: tree web entry activates under real Cordis once ds-bot provides flybot, and exposes flybot.tree.forest), plugins/timeline 135
  (134 pass, 1 skip: timeline web entry activates under real Cordis once ds-bot provides flybot),
  plugins/workflow 336, .github/scripts 598, interop 37, live-e2e 24; fail 0 in every suite

  Each of those three skips is Cordis 4 not installed on this machine — CORDIS_PATH is unset and
  setting DSH_HARNESS does not change it (re-run here just now: one skip, fail 0, per suite). The
  Test advisory for this tip runs with Cordis installed and reports 541 / 127 / 135 with
  skipped 0: the same totals, no failures on either side.

• lint: core 73 warnings / 0 errors, plugin lints 36 / 9 / 2 / 16 warnings with 0 errors, interop
  1 warning / 0 errors, live-e2e 0 / 0

• arch-docs: OK (14 changed file(s)) against base 1778add0

• ds-bot-patches.mjs check: ok ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70 (tree 5834c00, v0.1.5),
  ok 10 patches apply cleanly in order, ok core/ equals ds-bot/ + patches/ds-bot/; canonical:
  ok patches/ds-bot/ is what generate writes (generate is a no-op) — a second generate after the
  commit leaves git status empty

• build-client --check runs inside verify and exits 0

• changelog.mjs check: 8 fragments in changelog.d/ are well formed

• 14 files, +295/−47, one commit, one parent, not a draft

The edits to the existing host, client and test files travel inside
patches/ds-bot/0001-core-fixes.patch; the two new files (src/client/memory-empty.js and
test/memory-empty.test.js) are patches/ds-bot/files/ mirrors, and the rebuilt bundle is
patches/ds-bot/0008-client-bundle.patch. client.js is committed, so it was rebuilt with
npm run build in core/ and generate was run after it — the patch products are the generated
ones, not hand edits.

Not run

• The GitHub Test workflow (CI runs verify itself; nothing here ran on another machine).
• The package job's pack check, typecheck and actionlint, and the smoke test — npm run verify does
  not run them.
• Nothing against a live instance, and no browser check of the panel: the suite has no renderer, which
  is why the decision is a pure helper and the JSX path is a two-line render of its answer.

Scope and limits

• The panel now says why the empty state is empty. It does not retry, repair, or offer a way to fix
  the link; that stays out of scope, as the issue says.
• The path shown is the home's own memory folder — the folder the panel already belongs to — and
  nothing else about host paths becomes visible.
• blocked is per scope, so a linked memory/ (which fails above both scopes) names the same folder
  twice with own and team; the panel prints that path once.
• Not touched: folderKind / readFolder / writeFolder, the entry and summary writers, the
  once-per-folder warning, docs' memory-folder contract except the one sentence that now says what
  the view carries.

Checkpoint

{
  "pr": 2105,
  "claim": "Dev-2",
  "issue": 2101,
  "summary": "A refused memory folder answered exactly what a folder that was never written answers, so the panel told the user to save something that could not be saved. memory-view now carries blocked, one { scope, path } per scope whose folderKind() is 'other'; absent, the ordinary first-run home, stays out. A pure client helper turns an empty view with blocked scopes into one line naming the folder above the empty title. An ordinary empty view renders byte-identically to before.",
  "files": [
    "core/src/host/memory.js",
    "core/src/client/memory-empty.js",
    "core/src/client/memory-panel.js",
    "core/src/client/i18n.js",
    "core/client.js",
    "core/test/memory.test.js",
    "core/test/memory-empty.test.js",
    "docs/subsystems/core-client.md",
    "docs/subsystems/core-host.md",
    "changelog.d/2101-memory-blocked-empty.fixed.md",
    "patches/ds-bot/0001-core-fixes.patch",
    "patches/ds-bot/0008-client-bundle.patch"
  ],
  "checks": {
    "ran": "TZ=UTC ARCH_DOCS_BASE=1778add0 npm run verify",
    "result": "green",
    "at": "b2d5d5266947d6b8a6618a6814c6995a8a851bde"
  },
  "next": "none — ready for the reviewer, and for the Security advisory at this tip"
}

[HugoXK]

@Birfy review request — pull request #2105 at b2d5d5266947d6b8a6618a6814c6995a8a851bde

Fixes #2101 (the memory view cannot say the memory folder was refused). 14 files, +295/−47, non-draft, maintainer_can_modify on. Check-runs at this tip: 12 of 13 green; the only red is enqueue-guard, which reports no Verifier verdict naming this tip yet — that is what this request asks for. Advisory self-tests are still pending and are not a gate.

Please review this tip.

[Birfy]

Verdict: PASS at b2d5d52
Written-by: Reviewer
Attestation: b2d5d52 role=Reviewer

Ran at this tip:

$ cd core && npm ci --no-audit --no-fund && TZ=UTC node --test test/memory.test.js test/memory-empty.test.js test/i18n.test.js
# tests 101  # pass 101  # fail 0
$ cp ../../p2105base/core/src/host/memory.js core/src/host/memory.js && cp ../../p2105base/core/src/client/i18n.js core/src/client/i18n.js && cp ../../p2105base/core/src/client/memory-panel.js core/src/client/memory-panel.js && rm -f core/src/client/memory-empty.js && TZ=UTC node --test test/memory.test.js test/memory-empty.test.js test/i18n.test.js
# tests 98  # pass 93  # fail 5

Tier T2 (risk-gate report-only, PR #2105).

Red first, reproduced exactly as the body claims: with the three touched sources back at the base 1778add0 blobs and core/src/client/memory-empty.js removed, the same suite is 98/93/5 — the two behaviour cases (blocked undefined on the refused-folder view, blocked not [] on the plain/absent one), the missing helper module, and the two #2068 sink guards that fire because blockedScopes does not exist. Fix applied, 101/101 green.

Scope: compare 1778add0...b2d5d52 is ahead 1 / behind 0, 14 files, one commit — the 14 files this PR lists and no others. main is still 1778add0, so the base is current.

Checks at this tip: 12 of 13 green (tests-ok, package, judge, merge-gate, reviewed-tip, plugins social/tree/timeline/workflow, agent-audience, risk tier, node 24). The only red is enqueue-guard: do not enqueue #2105: no Verifier report names the tip b2d5d5266947 — the pre-verdict state, which this comment clears.

What I read in the diff:

• core/src/host/memory.js:498 blockedScopes is additive: it re-uses the existing folderKind() and only reports other, so absent (the ordinary first-run home) stays out and readFolder/writeFolder/scopeDir, the warning and the writers are untouched. The view field is [] when nothing was refused.
• core/src/client/memory-empty.js:7 is pure and returns null for a non-empty view or an empty blocked; memory-panel.js renders its answer only inside the entries.length === 0 branch, so an ordinary empty view is byte-identical to today.
• The new string has its DICTIONARY.zh entry, which i18n.test.js enforces — green here.

Metadata repaired in the body (no effect on this verdict): the checkpoint had "pr": 2101 (the issue) instead of 2105 and 14 files entries against the 12-entry cap, so both are corrected to a compliant block (summary 454 chars, block under 1500); the body's Reviewer: line named a shared account, and now reads Reviewer.