5cfc982f39dd1faffc28f12ebebc24c609b85017
76 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 5cfc982f39 |
fix(memory): count blocks dropped BEFORE the candidate pool exists (D2, second hole)
|
|||
| 7ad76167c5 |
fix(memory): separate "not enough blocks yet" from "no common direction" (C5)
MIN_SAMPLE (added in
|
|||
| 5462934a84 |
test(memory): pin the reason at the TOOL surface, the fourth place it can vanish (C5)
C5's reason now has three layers of coverage:
1. store — six fixtures, one per cause (`centroidStatus`)
2. plugin — `stats().centroid_state`, read-only (no rebuild scheduled)
3. tool — `ctx.tools.execute('stablemem_stats')`
Layer 3 is the one that matters in dsh: the model does not call `mem.stats()`, it
calls the tool. And the tool's handler is a single `return mem.stats()`, so a
later refactor that cherry-picks fields would keep layers 1 and 2 green while the
only surface anyone actually reaches goes silent.
That is the fourth instance of one shape in this branch:
P1 queryVector computed, dimension-checked, then dropped
D2 drop counters computed, then not printed
C5 the reason computed, read by nobody
C5 the reason surfaced on the service, but not pinned at the tool
Each time the value existed, the criteria were green, and no operator could see
it. So the criterion asserts on the tool's own envelope.
## Criterion
Drives the real ToolRuntime exactly as `test/phase-b-h.test.js` does, with a real
`AbortSignal` (`ToolRuntime` reads `callerSignal.aborted`, so `undefined` throws):
empty space -> centroid_state present, reason 'no_centroid'
after 8 commits -> reason 'ok', available true, sibling fields intact
drift past ratio -> reason 'stale', rebuildScheduled FALSE
The last assertion doubles as the read-only proof at this layer: a tool an
operator polls must not drive the rebuild loop.
Mutation — handler returns a cherry-picked subset:
not ok 10 - C5: the stats TOOL returns the reason, not just the service method
error: 'C5: the tool must expose centroid_state — that is the surface the model
and the operator actually call. ...'
## Two of my own assertions were wrong first
Recorded because both are the failure mode this branch keeps hunting:
- `assert.equal(s.centroid, s.centroid, ...)` — a tautology; can never fail.
- `assert.equal(typeof x !== 'undefined', 'boolean', ...)` — compares `true` to
the string `'boolean'`; fails for a reason unrelated to its subject.
Replaced with `assert.ok('last_recall' in healthy, ...)`, which states the actual
precondition. A criterion that cannot fail, or that fails for the wrong reason,
is worse than no criterion — it consumes attention and proves nothing.
Gates: npm test 301/301 (0 skipped), c5 10/10, npm run check 12/12.
|
|||
| 16cfdb75d6 |
docs(memory): say what centroidRecallState is NOT, and why it has no caller
The C4 slice reported this method as dead code: `grep -rn centroidRecallState lib/` returned nothing but the definition, and the instruction was "wire it into recall or delete it — do not leave it as furniture". Neither, and the reason is worth writing down rather than re-deriving: - It cannot be wired into recall. It calls `centroidStatus`, whose first line is `countVectored` — a COUNT that C3-k forbids on the per-turn pre-step path. The scoring path therefore uses `loadCentroid` (one indexed SELECT). - It should not be deleted. `assertC3RecallUnusable` in test/phase-b-h.test.js runs the SAME predicate against every C3 mutant, so this method is what pins Go's `LoadCentroid` semantics (`centroid_store.go:179-185`: a zero-sample centre is unusable, and the recall side carries no stale bit). So it is a diagnostic seam, like `StableMem#saveSpaceCentroid`. The name "Recall-facing projection" was the actual defect — it invites exactly the wiring C3-k forbids. The name stays (renaming would churn a mutation-shared predicate for no behavioural gain); the doc now says what it is and what it is not. Comment only, no behaviour change. Gates: npm test 300/300, npm run check 12/12. |
|||
| 44f883745f |
feat(memory): give C5's reason an outlet, with a read that cannot schedule (C5 follow-up)
|
|||
| 0bc160b1bd |
docs(memory): list the new drop counters in the log-format table (D2)
The JSDoc table above `logRecallTurn` documents which fields the degradation group contains. It still listed only `degraded` / `skipped` / `skippedDim` / `err` after |
|||
| bdd91234a5 |
test(memory): pin that a NON-ZERO drop counter survives to both surfaces (D2)
L2 asserts the three D2 counters are printed when every one of them is zero. That
proves the format string mentions them; it does not prove a real value makes it
through. Two things sit between the counter and the operator:
`segmentRecallBudget` slices the hits array — and `slice` does not copy
non-enumerable properties, which is what all the counters are;
`lastRecall` is assembled separately from the log line.
So "correct in the returned array" and "visible to an operator" are different
claims, and only the second one is what D2 is about.
## Fixture
Three blocks on separate axes, query mostly on axis 0, default `minScore`:
block0 cosine ~0.95 -> hit
block1 cosine ~0.30 -> skippedScore
block2 cosine 0 -> skippedNoEvidence
Measured through the real plugin path (apply + commit + contextForStep):
log : ... skipped=0 skippedDim=0 skippedScore=1 skippedNoEvidence=1 truncated=0 err=- ...
last: {"mode":"hybrid","skipped_score":1,"skipped_no_evidence":1,"truncated":0,...}
All three destinations are non-empty at once, so the criterion cannot pass by
accident of an empty fixture.
## Mutation
Removing the three fields from the log line turns both criteria red:
not ok 2 - L2: debugLog=true emits one line covering recall, budget, degradation and injection
not ok 4 - L2b: non-zero drop counters appear in the log and in last_recall
L2 alone would already catch that; L2b is what catches the other half — a counter
that survives the log formatting but dies in the slice, or lands in one surface
and not the other.
Gates: npm test 299/299 (0 skipped).
|
|||
| 891582041d |
fix(memory): print the downstream drop counters, not just compute them (D2 follow-up)
|
|||
| 07f8438964 |
fix(memory): count every dropped candidate, not just the two upstream ones (D2)
`recallBlocks` could make a candidate disappear in three downstream places, and
none of them incremented anything:
· MinScore gate it scored, but below the threshold
· structural gate neither a usable vector score nor a symbol hit
· caller topK survived everything, fell outside the requested count
Measured before this change, 6 blocks in one space, `minScore: 0.99`:
hits=0 skipped=0 skippedDim=0
That reading is indistinguishable from "the space holds one block". An operator
whose threshold is swallowing the whole corpus is told "nothing was excluded",
and goes looking at the wrong subsystem. Only the space filter and the width
filter were ever counted — the two that are decided before scoring.
## What this adds
Three non-enumerable counters, each named after its own remedy:
skippedScore lower the threshold
skippedNoEvidence re-embed: there was nothing to score
truncated not a defect — reported so the totals reconcile
Plus the invariant that makes the next silent path impossible:
**hits + skipped + skippedDim + skippedScore + skippedNoEvidence + truncated
=== the candidate pool.** A future `continue` that forgets a counter breaks it.
## Criterion
`test/recall-accounting.test.js`, one fixture per path, asserting each counter's
own value (not a merged total — "scored too low" and "nothing to score" have
opposite remedies). The fourth test is the reconciliation above.
Mutations, both in a scratch copy:
remove `gatedByScore += 1` -> criteria 1 and 4 red
remove `gatedNoEvidence += 1` -> criterion 2 red
## Collateral: two static mutation anchors moved
`test/phase-b-a.test.js` pins the V5 gate and the caller-topK truncation by
rewriting `lib/recall.js` text. Making the gate multi-line (to hold a counter)
and threading `drops` through `withSkipped` changed those exact strings, so the
anchors are updated to the new text — same mutations, same properties pinned.
Running the file confirms 38/38 afterwards; without the update three V5†
mutations failed on a stale anchor rather than on their subject.
Gates: npm test 298/298 (0 skipped), npm run check 12/12. Frozen faces untouched.
|
|||
| 68775d327f |
fix(packaging): ship lib/embed/, without which the published tarball cannot load
`package.json` declared
"files": ["lib/*.js", "lib/loop.js", "lib/loop/*.js", "lib/types/*.d.ts"]
`lib/*.js` matches ONE level. `lib/embed/http.js` therefore never entered the
tarball, while `lib/index.js:35` imports it:
import { createHttpEmbedder } from './embed/http.js'
## How this survived
Every test in this repo runs from the source tree, where the file obviously
exists. `npm pack --dry-run` printed "10 files" — a plausible number nobody had
reason to read through. The defect is only reachable from the one path that
ships: installing the tarball.
Measured, extracting the tarball and importing it:
IMPORT FAILED: ERR_MODULE_NOT_FOUND
Cannot find module '.../package/lib/embed/http.js'
imported from '.../package/lib/index.js'
After the fix, the same command:
IMPORT OK, exports: StableMem,apply,default,defaultPath,inject,instanceKey,lastUserText,name
## Fix
`lib/embed/*.js` added to the allowlist. The tarball goes from 10 to 11 files
(86.1 kB) and `lib/embed/http.js` is in it.
## Criterion
`test/packaging.test.js`:
1. every `.js` under `lib/` must be matched by at least one `files` pattern.
The patterns compile to regexes the way npm treats them (`*` does not cross
`/`), so the criterion needs no hand-maintained file list and cannot drift.
2. every relative import in `lib/index.js` must resolve on disk — otherwise
criterion 1 could pass vacuously for a file that does not exist.
Reverting `files` to the old list turns criterion 1 red:
not ok 1 - packaging: every file under lib/ is covered by package.json "files"
these files live under lib/ but no "files" pattern reaches them ...
lib/embed/http.js
## Why it belongs in this branch
V6 made the embedder assembly load-bearing (two instances, one per side). A
release that cannot import `lib/embed/http.js` has no embedder at all, so the
distinction V6 introduced would never reach a user. The bug predates this
branch; its blast radius is the shipped artifact.
Gates: npm test 294/294 (0 skipped), npm run check 12/12, npm pack 11 files.
|
|||
| c97775bd18 |
feat(memory): encode stored blocks on the document side, questions on the query side (V6)
The HTTP protocol carries a `side` field — `query` or `document`, HA's
`PurposeQuery`/`PurposeDocument` (`http_embedder.go:105` / `:109`). The port made
it a construction-time setting of the adapter (default `query`) and then **no
call site ever supplied it**: both the write path (`lib/index.js`) and the recall
path (`lib/recall.js`) took the default.
So every stored block was encoded as if it were a question. Nothing fails when
that happens — both sides produce unit vectors of the declared width — which is
exactly why it survived: the corruption is only visible in retrieval quality,
and retrieval quality was already the known-unmeasured part.
## Why two instances and not a per-call argument
`side` is a property of what you are encoding, so a per-call parameter is the
more natural shape. It is not the shape used here, for one reason: the adapter
travels `side` verbatim in the request body from a closure, and giving it a
second, per-call way to receive the same field would leave two sources of truth
for one wire value. Creating two adapters over the same endpoint/model/dimension
— identical fingerprint, differing only in `side` — keeps the wire contract as it
was and puts the distinction where it belongs: in assembly.
`lib/embed/http.js` is therefore **unchanged**.
An injected `config.embedder` (tests, a future local adapter) has no second
instance, so the write path falls back to it (`documentEmbedder ?? embedder`).
That is the previous behaviour, not a second code path — and it is pinned.
## Criterion
`test/phase-b-v6-sides.test.js` starts a real HTTP server that records the `side`
of every request, then drives the **production assembly** (`apply()` with
`config.embed`):
commit → request body side === 'document'
recall → request body side === 'query'
The assertion is on the field that actually went out on the wire, not on an
internal variable. A second test pins the injection fallback: a single injected
embedder must still serve both paths, or every existing test and every
single-sided adapter breaks.
Mutation M-V6 — pointing the write path back at `this.embedder`:
not ok 1 - V6: storing a block encodes it on the document side, asking encodes the query side
error: V6: a block being STORED must be encoded on the document side. ...
+ actual - expected
+ 'query'
- 'document'
## What this does NOT establish
That the provider actually encodes the two sides differently. `side` is a
request field; what the endpoint does with it is the endpoint's business, and
this repo has no model whose asymmetry is measurable. What is now true is that
the distinction reaches the wire instead of being silently defaulted away.
Gates: npm test 292/292 (0 skipped), npm run check 12/12. Frozen faces untouched.
|
|||
| 28866ac6e6 |
feat(memory): name why centring is disabled, instead of only reporting that it is (C5)
`centroidStatus` computed four distinct ways for centring to be unavailable and
then flattened all of them into `available: false`. The result was that
`no_centroid` and `dim_mismatch` both looked like `stale: null`, and `isotropic`
was indistinguishable from a healthy space except by `available`. That answers
"may I centre?" and says nothing about "why is semantic recall never
correcting?" — four different operator actions (build a centroid, fix the
dimension, wait for a rebuild, accept that this space has no common direction)
collapsed into one symptom.
Every branch now carries `reason`:
ok available: true
no_centroid no row for this space at all
dim_mismatch a centroid exists but its width is not this query's
zero_sample a row exists but was built from zero vectors
stale usable in principle, no longer describes the space (drift > 20%)
isotropic permanent property of the space: no common direction to remove
`zero_sample` is a fifth cause beyond the four the plan names, because the Go
branch has it too (`centroid_store.go:179-185`) and it is not the same problem
as a missing row.
## Criterion
`test/phase-b-c5-reasons.test.js` — one fixture per reason, asserting **the
reason value itself** (not `available`, which is multi-valued). Plus:
- an invariant test: `available === (reason === 'ok')`, so `reason` cannot drift
into decoration that disagrees with the conclusion it explains;
- a test that `centroidRecallState` still projects `stale: null` (the scorer must
not start reacting to staleness) *while* `reason` travels through, so an
operator can still see why.
Every call injects `schedule: () => {}`. `centroidStatus` schedules a rebuild
when it judges a space stale — a criterion that calls it without isolating that
side effect ends up triggering the very behaviour it is inspecting. C4e's first
version proved that the hard way.
## Mutation
Collapsing all six reasons into one value (`reason: 'unavailable'`) turns all
eight criteria red:
not ok 1 - C5: a space with blocks but no centroid row reports no_centroid
not ok 2 - C5: a centroid of the wrong width reports dim_mismatch
not ok 3 - C5: a centroid row with zero samples reports zero_sample
not ok 4 - C5: a centroid that drifted past the ratio reports stale
not ok 5 - C5: an isotropic space reports isotropic, not stale
not ok 6 - C5: a healthy space reports ok, and only ok carries available=true
not ok 7 - C5: reason and available never disagree
not ok 8 - C5: centroidRecallState keeps its stale:null projection but carries the reason
## What this does NOT change
Scoring, gating and the recall path are untouched: nothing reads `reason` to
decide whether to centre, and `centroidRecallState` keeps `stale: null`. This is
a reporting seam, not a behaviour change — C4's own criteria (C4a/b/c/d/e/g/h/i)
and phase-b-h's C3 assertions stay green.
Gates: npm test 290/290 (0 skipped), npm run check 12/12. Frozen faces untouched.
|
|||
| 5cb97edf39 |
fix(memory): stop scoring renormalised floating-point dust as a direction (C4 follow-up)
`centerVector` treated any positive norm as a direction:
norm = Math.sqrt(norm)
if (!(norm > 0)) return null
for (...) out[index] /= norm
A block that IS the space mean differs from it only by floating-point residue
(~1e-17). That residue passes `norm > 0`, gets normalised to unit length, and
then scores against the query as if it were signal.
## Measured
Space of two identical blocks, query deliberately off the block direction (if
the query equalled the mean, its centred form would collapse and centring would
fall back to raw scores, hiding the defect):
raw cosine, no centroid 0.8608
with centroid, before this fix 0.2183 <- dust, renormalised
with centroid, after this fix no hit <- dust judged "no direction"
At the default `minScore = 0.5` the 0.2183 scores were filtered anyway, so the
user-visible outcome (0 hits) does not change. What changes is that the number
is no longer manufactured: with `minScore: 0` the earlier build would surface
those blocks at a noise-derived score, and a future change to the threshold
would have made that reachable.
CENTER_EPSILON = 1e-9 is the floor. It also matches the Go side, where the
cosine of a zero vector is 0 rather than a random angle.
## Criterion C4i — and what it deliberately does not pin
C4i asserts the invariant: **every returned hit must carry the raw cosine
(0.8608); a value near 0.22 means dust was renormalised.** It therefore accepts
either of two future policies — drop such blocks (what this commit does), or
skip centring entirely for a space with no variance. The only thing it forbids
is continuing to score dust.
Reverting the guard (`norm > CENTER_EPSILON` -> `norm > 0`) makes C4i red, which
is the mutation this criterion exists for.
## KNOWN LIMITATION — reported upward, not fixed here
A space whose blocks are all identical now returns NO hits where it previously
returned them at 0.8608, because centring subtracts the only direction the space
has. That is not introduced by this commit — epsilon only made it deterministic —
but it is a real recall loss for a realistic case (the same note stored twice),
and it is a C4 regression against the pre-C4 behaviour.
Two candidates, deliberately NOT applied here because both change scoring
semantics and one departs from HA:
(a) keep dropping them (current, HA-consistent: Go's cosine of a zero vector
is 0, so those blocks fall below any threshold too);
(b) do not centre a space whose mean norm is ~1.0 — there is no variance to
remove — which preserves the 0.8608 raw scores. This adds an upper
threshold HA does not have, so it is the parent's call.
No criterion pins "0 hits" for the duplicate space: pinning it would encode the
limitation as intended behaviour.
Gates: npm test 282/282 (0 skipped), frozen faces untouched.
|
|||
| 363b1ba21a |
docs(memory): record what the C4 write path costs, and two "unwired" calls that aren't
Three comments that were either wrong or silent. No behaviour change.
## The first-build cost claim was false
`#ensureCentroid` said "首次建的代价很小：那时块还少" (the first build is cheap —
there are few blocks then). That is exactly backwards for the situation the code
exists to fix: a production database that already holds thousands of vectored
blocks while `graph_centroid` is empty. The W8 scenario IS a database with many
blocks and no centroid.
Measured on a real database (512 dims, 2000 vectored blocks, empty centroid
table, first commit through the production path):
FIRST commit after upgrade 105.1 ms (synchronous SELECT + parse + mean)
STEADY commits 8.7-9.4 ms (loadCentroid SELECT + centroidStatus COUNT)
and the first build grows linearly with the space (~420 ms at 8000 blocks). The
number is now in the comment, together with the decision it justifies: keep the
one-time stall rather than move the build to the async path, because an async
first build leaves the first recalls after an upgrade silently uncorrected —
precisely when n is large enough for centring to matter. A bounded stall is
easier to notice than a silent degradation.
The steady-state ~9 ms is new with C4 and is now stated as such: every commit
pays one `loadCentroid` SELECT plus the `countVectored` COUNT inside
`centroidStatus`. C3-k forbids that COUNT on the recall path, not on the write
path.
## Two calls with no production caller, and why neither is a dangling wire
`saveSpaceCentroid` and `#centroidRebuiltAt` both looked like the defects this
round kept finding (code written, never wired). They are not, but leaving that
unwritten meant the next reader had to re-derive it — and the two live cases
(`saveSpaceCentroid` in `lib/`, the throttle state on disk) really were dangling.
- `saveSpaceCentroid` is the public programmatic seam for a caller that computed
a centroid elsewhere. Production centroids are derived from the blocks by
`store.rebuildCentroid`, driven from `commit` via `#ensureCentroid`. Stated in
its JSDoc, along with the fact that the only in-repo caller is a test.
- `#centroidRebuiltAt` stays in memory, and the reason `graph_centroid.built_at`
cannot replace it is now written down: `built_at` records a BUILD, the throttle
needs the last SCHEDULE, and the two diverge precisely when a rebuild throws.
Throttling on `built_at` would re-schedule on every commit after a failed
rebuild — write amplification on the failure path. The cost of the in-memory
map (one extra bounded async rebuild after a restart, measured 85.5 ms at
2000x512) is smaller, and it is stated next to it.
Gates: npm test 281/281, npm run check 12/12. Frozen faces untouched.
|
|||
| febf9f6f3c |
test(memory): pin the C4 gates that were left unguarded (C4 follow-up, supervision)
Three of C4's control surfaces had no criterion at all: deleting them left every
suite green. This commit adds the criteria, and the two defects they exposed.
## What was unguarded, measured
Each mutation below was applied to a scratch copy of lib/ and run against the
suite as it stood at
|
|||
| 05e93b2f5c |
fix(memory): let the write path refresh a drifted centroid (C4 follow-up)
|
|||
| 0a6adff5cb |
fix(memory): wire centroid centering into both the write path and scoring (C4)
C4 的判据原文：「校正时查询向量与块向量都去均值，不能只处理一边」
（docs/phase-b-criteria.md:253，依据 HA centroid_store.go:443-451 的 centerBoth）。
C4 缺的不是一半，是两层都没接
1. 中心从来不存在。`saveSpaceCentroid`(lib/index.js) / `centroidStatus` /
`centroidRecallState` 在整个 lib/ 里没有生产调用者，`rebuildCentroid`
只有测试在调。所以生产库的 `graph_centroid` 永远是空表，`loadCentroid`
永远返回 undefined，`isAnomalous` 永远 false —— 校正一次也不会发生。
实测：`/tmp/p1/e2e.db` 的 `graph_centroid` 零行。
2. 打分不用中心。`lib/recall.js` 全文没有 centroid 一词，
`scoreVectorCandidates` 只算裸余弦。`centerBoth` 全仓零命中。
只做第 2 层就是又一个「代码写了没接线」：判据会绿、实现会绿、生产永远 false。
写入侧：lib/index.js
· 新增 `#ensureCentroid(fingerprint)`，在 commit 成功后调用
· 只在「本空间没有中心行」时建一次；有行就交给已有的 stale 判定
· 失败吞掉：一次重建失败不能让写入失败（同 D1：向量侧故障不得带走主路径）
· 不放在召回侧：rebuildCentroid 是 O(n·d)（实测 dim=512、2000 块 85.5ms），
而召回每轮 pre-step 都跑；C3-k 也明令 countVectored 不得进热路径，
而 centroidStatus 第一行就是它
打分侧：lib/recall.js
· `scoreVectorCandidates` 读一次中心（loadCentroid 纯读，一次索引查询）
· 仅当 `isAnomalous === true` 且 `centroid.dim === queryVector.length` 时启用
· 两侧同时减均值 + 重新归一化（新增 `centerVector`，对齐 HA CenterVector）
· 维度不符 ⇒ 不校正也不报错；减完是零向量 ⇒ 退回未校正路径
· 门控是正确性不是性能：各向同性空间无条件校正会毁掉结果
（实测 8 块正交 mean norm 0.3536：命中数 8 → 1，7 块余弦 +0.0496 → −0.1416，
且因 V5 结构性门（vectorScore <= 0 且 symbolHit === 0 直接丢弃）
minScore 调到 -1 也救不回来）
判据：test/phase-b-c4-centering.test.js（283 行，已登记进 npm test）
C4-0 前置：空间真的会被判为各向异性（mean norm 0.9729 >= 0.6）
C4a born-RED：去均值把 top-1 从 hub 翻到 target
红原文（28e18d0）：hub=0.6949(v=0.9928) target=0.6901(v=0.9859)
绿后： target=0.6300(v=0.9000)
C4b mutation-GUARD：同值对余弦恒为 1（纯代数，不依赖语料）。
未实现时本来就绿（裸余弦同值对 = 1），只有「只减一边」能让它红。
这条不可省：实测只减 query 时 C4a 的 top-1 仍然是 target，C4a 抓不到。
C4c guard：没有中心时照常返回结果（hub 仍然赢），不是让召回失败
C4d 第一层的守门人：走真 apply() + commit() + recall()，不手工 rebuildCentroid，
断言写完 8 条后 loadCentroid 必须已存在，且端到端 top-1 是 target
—— 没有这条，前三条的绿只能证明算术，证明不了接线
变异自证（三档，全部在临时副本做，真改 lib/）
M1 去掉中心化（loadCentroid 恒 undefined） → C4a + C4d 红（5→3 pass）
M2 块侧不中心化（只减 query，即 M-C4） → C4a + C4b + C4d 红（5→2 pass）
C4b 红原文：got 0.18974704073471832 —— 只减一边的签名
M3 去掉写入侧 #ensureCentroid → 仅 C4d 红（5→4 pass）
C4d 红原文：after commits through the production path a centroid must exist
这一档证明 C4d 是唯一守住第一层的判据
一处必要适配（不是削弱）
test/phase-b-h.test.js 的 `ticket②-strong mutation` 原本依赖「commit 之后
本空间没有中心」来让「用错 key 查不到」成为可观测事实。C4 让 commit 自动
建中心之后，这个前提变了，它会因为「本来就有一个中心」而红 —— 红的原因
与它要守的约束无关。改法：commit 之后显式清掉本空间那一行，并加一条
前置断言。用例语义完全保留，只是把前提重新立起来。
★ What this does NOT establish
中心化改变的是向量间的夹角，因此能改变排序。它不能让未校准的绝对分数
变得可用：去均值之后余弦仍然是余弦，而 DEFAULT_MIN_SCORE = 0.5 从来不是
从中心化后的分布推出来的。阈值校准仍是
phase-b-p1-vector-wiring.test.js:51-58 记录的已知未解问题。
三门：npm test 277/277（0 skipped）、npm run check 12/12、npm pack 10 files 79.0 kB。
冻结面：docs/、README.md、scripts/、lib/loop* 零改动。
|
|||
| 28e18d0258 |
test(memory): bound what P1's green does and does not establish (P1 follow-up)
Two discipline holes left after |
|||
| 09be4de0eb |
test(memory): pin that ORDINARY_DEGRADATIONS decides the log LEVEL (P1 follow-up)
P1 registered two healthy modes in `ORDINARY_DEGRADATIONS` — `hybrid` (the wired
success path) and `no_vector_space` (a space with nothing comparable to score) —
and the commit message claimed that meant "a healthy wired recall does not log a
warning every turn". Nothing tested it. Measured on
|
|||
| 1309afec93 |
fix(memory): wire the computed query vector into recall scoring (P1)
`recallBlocksHybrid` computed `queryVector`, verified its length against the
declared space, and then threw it away:
return withDiagnosis(recallBlocks(store, query, scoped), 'vector_ready_unused')
`scoped` carries only `topK` / `signal` / `fingerprint` / `dimension`. So every
V1–V7 scoring branch inside `recallBlocks` was live code reachable ONLY from
unit tests that hand-built a `vectorScores` Map — `vectorScores:` appeared 10
times in test/phase-b-a.test.js and ZERO times under lib/. Production recall was
pure symbol/FTS: the whole vector half of phase B was unreachable, and the only
symptom was a diagnostic label nobody was watching.
Why BOTH options are now passed (structural, not stylistic)
· `vectorScores` alone reaches only the V1 exact-band tie adjustment (:438).
The fused candidate assembly at :233 is gated on `Number.isFinite(minScore)`,
so without a threshold the vector route can never admit a block the symbol
path missed — which is exactly what V5 exists for.
· `minScore` alone does nothing: :299 additionally requires `vectorScores` to
BE a Map before it builds vector candidates.
One seam, three guards. Half of it is a no-op, which is why measuring the
half-wiring mutation below matters.
Scheme A, and why not B
A: keep the existing API (`vectorScores: Map<string, number>` + `minScore`), and
have `recallBlocksHybrid` score the query vector against the space's stored
vectors before calling `recallBlocks` once.
B: change `recallBlocks`'s signature to accept a `queryVector` and score inside.
Chosen: A. B would touch a signature that phase A's golden fixture and nine call
sites depend on being synchronous and vector-free (`recallBlocks` MUST NOT return
a thenable — A1 pins it structurally), and it would move cosine arithmetic into a
function whose contract is literally "store + query text". A leaves
`recallBlocks` byte-untouched: the seam it already exposes is driven, so A2's
45-case golden comparison cannot drift. Both routes must also be fused in ONE
scoring pass anyway (V5 admits vector-only candidates; V7 forbids truncating
before fusion), so "call twice and merge" was never an option.
Cost, measured before choosing (this box, 2000 blocks x 512 dims)
narrow `SELECT id, vector` 21 ms (vs 70 ms for `allBlocks(-1)`)
parse + cosine over 2000 60 ms
⇒ ~81 ms per recall; at 8000 blocks ~310 ms.
Affordable because it runs once per TURN (pre-step), not per candidate, and
because the scan is bounded by SQL: `fingerprint = ?` and `vector_dim = ?` are
pushed into the store so rows from a retired space or a wrong width are never
decoded. A phase-A store (no embedded blocks at all) pays one indexed SELECT
returning no rows. It does not add a new order of cost either: the fused path
already walks every block for symbol union (`allBlocks(-1)`); this replaces that
blind decode with a narrow one for the vector half. The remaining ceiling is a
single very large space — a number to measure before raising topK, not a reason
to ship a path that never runs. Fail-closed per §0.2/F5: blocks with an empty
fingerprint are deliberately not scored.
New diagnostic modes, both non-faults
`hybrid` the healthy wired path (symbol + vector fused). Explicit
`case` in `degradationNotice` because `default:` exists to
make an UNKNOWN mode say "unknown, not absent" — routing the
healthiest mode through it would print a false degradation
notice on every turn that had a vector hit.
`no_vector_space` a space is configured and the embedder answered, but no
block in it carries a usable vector (fresh space). Says
"nothing was scored" without claiming a provider failure.
An empty Map must NOT be passed to the fused route: it would
open candidate assembly and score symbol matches as
`0.7*0 + 0.3*coverage`, the V2 regression.
The criterion (test/phase-b-p1-vector-wiring.test.js)
End-to-end, because a unit test cannot see this bug: the defect is that nobody
passes the options, so asserting the options work proves nothing. The chain is
real sqlite file → real `apply()`/`commit()` write path (no hand-built vectors,
no injected embedder object: the plugin's own HTTP adapter is used) → real
`recallBlocksHybrid` → real headless `dsh --profile headless` with the shipped
`cordis.patch.yml` loop overlay (so P0 still applies) → the persisted
`session.v4.jsonl.zstd` → the stub LLM's answer, which is a pure function of the
system prompt it received.
Corpus, MEASURED before any assertion was written. Deterministic keyword-family
projection into 8 unit axes: family 0 is the target's vocabulary, families 1..7
are one axis per distractor, unmapped text → zero vector. Query
「上次说的那个四位数是什么来着？」:
symbol path hits (target) 0 ← precondition 1
hand-built vectorScores top1 = target, score 0.70 ← precondition 2
query shares no CJK 2-gram with any block
Both preconditions are asserted in-suite (P1-0) so a later corpus edit cannot
make the e2e criterion unfalsifiable. An earlier attempt used the real
chinese-clip-vit-b16 model; its top-1 for the same kind of query was an unrelated
block (0.83 "入职培训"), so that corpus could never have gone green — the fake
embedder makes the question decidable instead of probabilistic.
The access code is `QP47-812` rather than a bare number so the stub's extractor
(`[A-Z]{2}\d{2}-\d{3}`) cannot collide with anything else in the prompt.
Born red against
|
|||
| c1f7e06b22 |
test(memory): 补 377e02c 的判据假绿 —— multiCarrier 名不符实，真多块零覆盖
`multiCarrier(texts, convention)` 名叫"多块"，实际 `content: [{ type: 'text',
text: joined }]` 恒为 1 个 block。所以 S2a/S2b 读起来是"多块路径已覆盖"，
实际一条都没走多块分支：
M1 在 `const rendered = ...` 前插 `if (blocks.length > 1) return null`
（即 V2 那个错误实现）→ 22 条判据 pass 20 / fail 0，全绿。
这正是上一轮 375→377e02c 留下的假绿：不是缺测试，是 helper 名字把人骗了。
名字夸大覆盖范围比没有测试更毒，因为它读起来像有。
改法（只动 test，lib/loop.js 零改动，sha256 f28c5564… 前后一致）：
- `multiCarrier` → `singleBlockCarrier`，实现不动，JSDoc 写明
"产出：1 个 text block 承载 N 个 section（lib/index.js:932 的真实形状）"
并记下它曾叫 multiCarrier 这段历史。
- 新增 `trueMultiCarrier(texts, kind)`：N 个 text block，每个 block 一个
section，rendered = texts.join('')（glued）。注释写明真多块没有 spaced 变体。
- S2a/S2b → singleBlockCarrier；S3 标题改成 "single content block carrying N
sections != those sections …" 并改用 singleBlockCarrier。
- S2c/S2d → trueMultiCarrier(['a','b'])，断言不变。
变异自证（两条都咬住，且撤净后 sha256 回到基线）：
M1 `if (blocks.length > 1) return null` → S2c 红（"got 1 message(s)"）
M2 删掉 glued 分支（只剩 `rendered !== spaced`）→ S2b 红（"got 1"）
对
|
|||
| 377e02c943 |
fix(memory): make the loop actually promote real recall into system
`promoteSnapshotSections` accepted only ONE carrier spelling: `content: []`.
The plugin never emits that shape. `lib/index.js:932` always attaches exactly
one `{ type: 'text', text: injected }` block whose text IS `sections[0].text`,
so `promotedSection`'s `if (blocks.length > 0) return null` matched on every
real recall and the promotion was a no-op in production. Recall stayed in
user/message history — the exact defect
|
|||
| 5c6aaf53cf |
feat(memory): land the loop ports without wiring them
The four files under lib/loop/ were written against 0.2.1-rc.2 and have been
verified to import on their own; they are the substrate a replacement loop
needs to take over step(). This commit only puts them in the tree — lib/loop.js
is untouched, so nothing imports them yet and behaviour is unchanged.
Two packaging facts they bring with them:
files `lib/*.js` does not recurse, so lib/loop/ was shipping nothing.
`lib/loop.js` and `lib/loop/*.js` are now listed separately because
neither glob covers the other.
peer runtime-context.js imports @deepseek-ai/dsh-session, which the peer
table never declared. G2b's allowlist covered it, so the static guard
passed over a real declaration gap.
test/loop-ports.test.js pins the port interface rather than its behaviour: the
modules import alone, the export names survive, and the inbox projection keeps
key "inbox" / stateVersion 1. That literal pair is a wire format shared with
stock-loop sessions — a different key silently reads as "no pending input", a
different version makes stateSchema.parse refuse stored rows. The schema's
parse() is also exercised against seven malformed persisted rows, since
replacing a zod schema with a hand-written check is exactly the kind of change
that can be a no-op and still look fine.
|
|||
| f1b74a35ef |
feat(memory): ship the profile overlay that mounts the replacement loop
|
|||
| 6d9ad62a8f |
feat(memory): surface recall as a system section instead of history
Per-turn recall currently enters through the `agent/pre-step` waterfall, and
that hook can only return `messages`. The recall block therefore lands in
conversation history as a user message: the model reads its own memory as if a
user had said it. `systemPrompt.context` cannot fix this — it runs before the
turn text is known, so it can only render input-independent text.
The loop's `preStep` is the first seam holding BOTH the assembled prompt and
this turn's claimed messages. `lib/loop.js` subclasses the harness AgentLoop and
wraps that seam on the agent instance: a pure snapshot carrier message is moved
out of `messages` and into `assembly.sections`, so it becomes part of the system
prompt for that turn and never enters history.
Deliberately decoupled from the memory plugin: nothing imports it or matches its
name. Promotion keys off the shape every snapshot-style injector already uses
(`source.sections`, the same shape `dsh-time-context` emits).
Constraints honoured, each of which was a measured failure elsewhere:
- The promoted section carries `interpolate: false`; recalled text is free text
and may contain `{{...}}`, which the strict interpolator rejects.
- The subclass defines no constructor and no static `inject`. The parent already
registers the turnBoundary + inbox projections, calls `setFactory(this)`, and
declares `{{provider}}`/`{{model}}`; re-registering any of them throws at
startup.
- Only the instance's `preStep` is patched, never the prototype, which other
agents share.
Also wires the new peer: `scripts/link-dsh.sh` gains dsh-agent/dsh-agent-loop
(without them the package cannot resolve at test time), package.json declares
dsh-agent-loop as a peer and adds the new test file, and G2b's allowlist admits
dsh-agent-loop as a first-party harness package, with the reason recorded.
npm test: 247 pass, 0 fail.
|
|||
| 783a7f87bb |
feat(memory): observable recall log behind config.debugLog
The plugin shipped with zero console.* and zero ctx.logger calls, so a
production recall failure left no trace: `degraded` is a return value the
caller sees once, and the injected text is only visible if the model quotes
it. Everything below is observability — no scoring, no DDL, no docs/README,
no new dependencies.
## The line
One summary per recall turn, covering the four fact groups asked for:
recall query=<n>ch hits=<n> topK=<n> zeroHit=yes|no
budget budget=<n> source=explicit|host|fallback kept=<n> singleHitOverBudget=yes|no
degrade degraded=<mode> skipped=<n> skippedDim=<n> err=<summary>
inject inject=<n>ch
`query` is LENGTH ONLY (code points, so CJK is not double-counted). The query
is the user's own message and a memory log is the last place it should be
copied; length beside `hits` is enough to tell "searched nothing" from
"searched the skill catalog".
`source` reads straight off segmentRecallBudget's own decision, and `kept` is
the post-slice count, so the line cannot disagree with what was injected.
`inject` is measured AFTER rendering, i.e. the exact string contextForStep
returns — not a re-derived estimate.
## Level policy (and why it is not always info)
· fault — degraded not in {ok,no_embedder,aborted,vector_ready_unused}
-> warn, emitted EVEN WITH debugLog OFF. A failed search is the per-turn
event where absence of evidence is not evidence of absence.
· zero injection -> debug (the commonest case on the shipping default must
cost nothing at normal verbosity, but still be one greppable line).
· otherwise -> info, only when debugLog is true.
`no_embedder` and `aborted` are deliberately NOT faults: the former is the
shipping configuration, the latter a deliberate stop. This is the same
judgement W11e already made for the model-facing notice — a constant warning
trains the reader to skip the channel.
## Logger source, and why ctx.logger alone was not enough
Source is ctx.logger('dsh-memory'); if the cordis build has no logger service
the code falls back to a console.warn/console.error shim (debug/info also go
to warn — stdout is never written, since `dsh --profile headless` prints the
ANSWER on stdout, so a line there is not noise but a corrupted answer).
★ Measured, and the reason this change installs its own sink: cordis ships
exactly ONE default exporter, an in-memory ring buffer
(cordis/lib/index.js:594-603), and no dsh bundle adds a terminal one. Calling
ctx.logger.info(...) in a real profile therefore writes to a buffer nobody
drains — the plugin would have looked instrumented while a headless run still
printed nothing. installStderrSink registers a scoped exporter on that same
service: it filters by message.name (the exporters map is process-wide, so
without the name check it would reprint every other plugin's warnings under
this prefix) and by severity, then renders with Logger.format and writes to
stderr. Disposal rides on ctx.effect inside LoggerService.exporter.
Two robustness details, both earned the hard way:
· the whole line travels as ONE `%s` argument — Logger.format expands
%s/%d/%o in the format string, so a provider error containing `%s` would
otherwise truncate the rest of the line (verified: "50% off %s" came out
"50% off undefined NaN");
· err is flattened to one line and cut at 80 chars — a log line must stay a
line;
· every logging path is wrapped, because a throwing logger would turn an
observability feature into a recall outage.
## Verification
test/memory-log.test.js (L1–L8b, 12 tests) pins: default is silent; the
summary carries all four fact groups in exactly ONE line; the query text
never appears; explicit/host/fallback source naming; a fault warns with
debugLog off; a zero-injection turn is debug not info; log-on equals log-off
for both the injected text and lastRecall; stdout is never written; the line
reaches stderr; foreign loggers are not reprinted. L4† is a real mutation —
it patches lib/index.js on a copy and asserts L4 goes red — because a guard
that cannot fail is not a guard (the W11d† lesson).
Self-tested in a real headless profile (dsh 0.2.1-rc.2, llmsproxy), same
question, only debugLog differing. Answer stayed "4471" on stdout in both:
debugLog=true dsh-memory: info: recall query=21ch hits=1 topK=3 zeroHit=no
| budget=838860 source=host kept=1 singleHitOverBudget=no
| degraded=no_embedder skipped=0 skippedDim=0 err=-
| inject=144ch
debugLog=false (no dsh-memory line; stderr carry only node's
ExperimentalWarning)
zero-hit turn dsh-memory: debug: recall ... zeroHit=yes ... inject=0ch
fault, OFF dsh-memory: warn: recall ... degraded=embed_error
err=fetch failed | inject=290ch <- speaks without opt-in
npm test: 237 tests, 237 pass, 0 fail (the W11d†ctx failure is gone — see
below). npm run check: 12/12 checkpoints.
## One test edit, forced by the caller change
W11d†ctx's mutation anchor was `const hits = await this.recall(query, { signal })`,
which no longer exists: contextForStep now rebinds as `const raw` because the
hits it renders come out of segmentRecallBudget (the preceding commit's work,
not this one). The anchor moves to the `raw` binding it would sit beside. The
mutation still flips W11d; only the anchor text changed.
|
|||
| ca0b5ff813 | fix(memory-b): keep non-enumerable recall diagnostics through budget slicing | |||
| 2069cd5f25 | feat(memory-b): budget-segment recall injection in the real host path | |||
| 771a053eea |
docs(CL-1F): restore A1 semantics and cite V7 logs for G1
A1: revert to the
|
|||
| 7fc3d46b9a | docs(CL-1): revert V2 documentation changes | |||
| 591f34070d | feat(memory-b): port V7 largeTopK candidate bound before fusion | |||
| 06155d4bcc | feat(memory-b): expose text document side as interface only | |||
| 8a87c973d2 | test(memory-b): add self-built tier-3 flip case | |||
| e2536f14f3 | feat(memory-b): port V5 candidate assembly and asymmetric MinScore | |||
| 5b217c1f78 | feat(memory-b): expose V3 vector and symbol attribution | |||
| b7eff5db66 | test(memory-b): strengthen C3 recall and corruption mutants | |||
| d73d47c081 | feat(memory-b): port C3 centroid staleness and async rebuild scheduling | |||
| d57c9dc798 |
feat(memory-b): port V2 non-exact fusion weights
Also clear three stale counts the release train authorised: criteria A1 wording (sync + hybrid), criteria G1 counts (173/12), README test-site count. |
|||
| fc92db9f5b | feat(memory-b): port V1 exact vector pin adjustment | |||
| 8bdd9f5ce0 | test(memory-b): make F8 mutants bite the positive criteria | |||
| 96adb172eb | test(memory-b): add F8 checkpoint for width validation | |||
| b5d3f6ec73 | feat(memory-b): add F7 fingerprint space stats | |||
| f62b826c64 |
test(memory-b): 补 unknownSpace / dimensionMismatch 的文案判据（四态齐）
你的复核成立：renderUnavailableTail 每态一个 clauses.push，但只有
spaceMismatch（D5b）与 noVector（D5c）有判据。删掉另两段，全套仍绿 ——
它们在渲染层是装饰，与恒 0 的 skipped_dim 同型。
我复现时先得到「各红 1 条」，查下去发现那是副本缺 README 导致
「README states no counts」那条报 ENOENT 的噪音，不是判据咬住。
去掉噪音后确认：你的结论正确，两态确实全绿。
补四条（每态一条判据 + 一条抑制变异）
D5e unknownSpace：断言「1 without a space label」，且断言文本里
**不含** browse / exact text —— 该态走语义路，借用 noVector 的
「可浏览」说法会误导（这是 F6 那条 browse≠recall 口径的第三次复用）
D5f dimensionMismatch：断言「1 whose width does not match this provider」
**且**指向「fix the config」这一补救，且不含 browse
D5e† 删 unknownSpace 的 clauses.push ⇒ 必须红
D5f† 删 dimensionMismatch 的 clauses.push ⇒ 必须红
真变异实测（删整段 clauses.push）
删 unknownSpace → not ok D5e、not ok D5e† （2 红）
删 dimensionMismatch → not ok D5f、not ok D5f†（2 红）
每条变异同时咬住「本体判据」与「自己的 suppression 测试」，不是只红一条。
两处写作教训
- D5f 的构造必须走 raw putBlock：F8 正确地拒绝显式传错宽度，
所以「库里有窄向量行」现实中只来自历史数据或修复脚本
- D5e†/D5f† 初版只 new Context() 没装 systemPrompt/tools 服务，
dispose 时 "Cannot read properties of undefined (reading 'context')"
—— apply() 的 inject 需要它们，已补
现状：四态 noVector / unknownSpace / spaceMismatch / dimensionMismatch
在**渲染层**各有判据与抑制变异，不再有装饰态。
验证
- npm test 166/166（162 + D5e/D5f/D5e†/D5f†）
- npm run check 10/10
- 干净副本实数见后续消息
|
|||
| 99d0670ebe |
fix(memory-b): 返工 ③④ —— trigger 直判据 + skipped_dim 不再是假字段
③ trigger 补直写判据（此前只有间接覆盖）
你的复核准确：摘掉 trigger 的 WHEN 会让 F3/D3 红，所以「间接有守卫」——
但没有一条盯 raw-writer。而 trigger 存在的全部理由就是防 raw-writer
（修复脚本、迁移、运维手敲 sqlite3）。putBlock 自己就能把列写对，
所以真实风险是「trigger 全没了也没人发现」。
MIG5 三条：
- raw UPDATE 把 vector 改成长度不符 ⇒ vector_dim 被拉回真值；清空则归 0
- raw INSERT 带错误 vector_dim ⇒ 被 trigger 覆盖为真值
- MIG5† 分别 DROP 两个 trigger，各自断言「谎言能存活」
真变异：从 DDL 里删掉整段 trigger ⇒ MIG5 前两条红（MIG5† 仍绿，因为它
主动 DROP，不依赖 DDL 是否存在 —— 这是两者分工正确的标志）。
④ skipped_dim 恒 0 是假字段，选 (a) 补维度过滤
你的诊断对，且比我的注释更狠：一个永远不能非零的字段，配合
`typeof === 'number'` 的断言，把 F4「维度失配与指纹失配分开计数」
做成了摆设。这与更早那处 assert.equal(skipped, 2) 是同一类。
实现：
- searchFts / 包含兜底都携带 dimension（来自 vector_dim 列）
- recallBlocks 新增 dimension 选项，在**空间过滤之后**做维度过滤
★ 顺序有意：先空间后维度，保证一块同时 stale 且窄时只计一次（记 space），
否则两个计数会重复计同一行、谁也加不出「被丢弃的块数」
- skippedDim 与 skipped 分别挂在返回数组上（F4 要分开）
- recallBlocksHybrid 把 space.dimension 注入 scoped，六个降级分支自动继承
- lastRecall.skipped_dim 改为读真实值
判据 F4b 四条：
- 同指纹不同宽度 ⇒ skippedDim=1 且 skipped=0（不串桶）
- 同时存在旧空间块与窄向量块 ⇒ skipped=1、skippedDim=1，不双计
- last_recall.skipped_dim 能非零
- F4b† 变异：删维度过滤 ⇒ skippedDim 归 0、窄向量被召回 ⇒ 红
实测：hits=[C 正常]，skipped=1，skippedDim=1，两者都能非零。
一处测试构造的调整：窄向量块用 raw 写入而非 commit —— F8（正确地）
拒绝显式传错的宽度，所以「库里存在窄向量行」在现实中只能来自
历史数据或修复脚本，与 trigger 那条判据的假设一致。
文档
- criteria: F4 补「两个都能非零」与恒 0 字段的教训
- dev-notes 增第 6 类「恒为 0 / 恒为真的字段」，含自查问句
「这个字段的取值集合里，有没有一个能让我这条断言失败？」
验证
- npm test 162/162（155 + MIG5 三条 + F4b 四条）
- npm run check 10/10
- 干净副本实数见后续消息
|
|||
| d9280773aa |
fix(memory-b): 返工 —— last_recall 可查询 + renderIndex 按态分述
① embedFailure 有落点了（此前只有注释）
你的判断准确：degraded 是**单次调用的返回值**，调用方看得见但运营方查不到；
criteria:282 要的是「可查询」，两者不能互相顶替 —— 就像 states 不能顶替 skipped。
实现：
- StableMem.lastRecall：最近一次 recall 的 {mode, skipped_fp, skipped_dim,
embed_error, at}，由 recall 路径写入
- stats() 增加 last_recall 字段（形状照 criteria:282）
- 健康召回记 'vector_ready_unused'（A 组语义），失败记 'embed_error'/'aborted'
- **不进四态**：那是从行派生的库状态，塞进单次事件会让同一时刻读两次
得到不同数字 —— 正是 D4 要避免的
判据 3 条：真 adapter 抛错后 stats().last_recall.mode 读得到该次降级；
干净召回会覆盖；D3b† 变异（删掉写入）⇒ 判据红。
② renderIndex 按态分述，不再一句包四态
你实测的四态揉成一句是真的错：旧句尾「still searchable by exact text」
对 noVector 成立、对 spaceMismatch 在生产召回路径上**不成立**
（带 fp 召回 0 条，不带 fp 浏览 1 条 —— 与 F6 裁定的 browse≠recall 同一条口径）。
改成分态子句：
spaceMismatch → 「from a retired space (reachable by browse only, not by recall)」
unknownSpace → 「without a space label (semantic recall unavailable)」
dimensionMismatch → 「width does not match this provider (fix the config, then re-embed)」
noVector → 「not yet embedded (still reachable by exact text)」
③ 无 embedder 走常态静默（P2，一并改）
无 embedder 是出货默认，不是异常。原来 2 块 noVector 每轮都被告知一次
「召回不了」，而与 exact recall 仍能命中相冲突，且与 W11e 的静默口径相反。
现在 space() === null 直接返回 ''（只留计数行）；运营侧从 stablemem_stats 查。
测试用 reportNoVectorAlways 钩子单独覆盖该措辞，生产默认 false。
判据 4 条：D5b（mismatch 必须说 browse、不得说 still searchable）、
D5c（noVector 说 text recall，且先实证 exact recall 真能命中）、
D5d（无 embedder 时不重复告知）、D5b†（单句尾部 ⇒ 红）。
另把 D5/D5† 改为需要配置空间——它们原来在无 embedder 下断言，
与 D5d 的新口径直接冲突。
实测两场景
A 无 embedder：renderIndex 只报「2 durable note(s)」，无警告；states noVector=2
B 旧空间块：renderIndex 报「1 from a retired space (reachable by browse only,
not by recall)」；states spaceMismatch=1；生产召回 0 条 skipped=1
验证
- npm test 155/155（151 + 返工 4 条）
- npm run check 10/10
- 干净副本实数见后续消息
|
|||
| 160b5b5139 |
fix(memory-b): 三项验收整改 —— 去写死数字 / F8 硬报错 / blockStates 去 JSON.parse
一、skipped 断言不再写死数字
原 assert.equal(hits.skipped, 2) 属于「手抄数字」——与刚删掉的 README 计数同类：
fixture 一改就悄悄不再描述事实。
改为从构造库现算：expectedSkipped = counts.unknownSpace + counts.spaceMismatch，
并先断言 expectedSkipped > 0（防止变成「0 == 0」的假通过）。
二、F8 从「事后统计」改成「写侧硬报错」
原状：写侧维度校验只降级成「不嵌入」，坏向量仍能落库，靠 blockStates
的 dimensionMismatch 事后兜住 —— 那是 accounting，不是 validation，
与 criteria:165 的「硬报错」不符。
实现：putBlock 新增可选 expectedDimension，声明了宽度且不符 ⇒ 抛错不落库。
commit 在「调用方显式传 vector」时传 expectedDimension。
★ 两个入口必须分清，否则会与 W4 打架：
- 调用方 bug（显式传了宽度不对的向量）⇒ **必须抛**，否则它以
「块在、召回不了」的形式沉默很久
- provider 异常（embedding 返回宽度不对）⇒ 按 W4 降级为不嵌入，块仍写入
（把上游抖动抛给用户 = 让一次 provider 故障变成写入失败）
判据含三例：显式传错宽度抛；显式传对宽度通过；provider 返回错宽度降级不抛。
F8† 变异：把宽度检查改成恒不触发 ⇒ 坏向量落库 ⇒ 判据红。
三、blockStates 不再解析向量（性能账）
实测 2000 块 × 2048 维：
改前 354ms/次（其中 255ms 是纯 JSON.parse）
改后 4ms/次（约 90×）
而 renderIndex 每轮都调它 —— 这是挂在 pre-step 热路径上的固定成本。
做法：memory_blocks 新增 vector_dim 列（维度是行事实，不是负载内容），
- putBlock 写入时一并写
- 迁移时为存量行回填一次（只此一次，不在读路径）
- 加两个触发器保证 vector 与 vector_dim 永不脱节：
★ 理由：既然这一列的存在就是为了「不解析负载」，那每个写入者都背上了
保持一致的义务。漏一个写入者（修复脚本、测试 fixture、未来迁移）
就产生一行「维度是谎话」的数据 —— accounting 报它 active，
而召回静默跳过它。用触发器让这个状态**不可表示**，而不是只劝阻。
- 静态判据：blockStates 函数体内不得出现 JSON.parse（防以后「顺手简化」改回去）
四、embedFailure 记账
不进四态（它是单次调用事件，不是库状态），criteria 已补说明：
四态是库状态、从行派生；embedFailure 属于 recallBlocksHybrid 的 degraded，
由 W 组覆盖。塞进库状态会让「同一时刻读两次得到不同数字」，正是 D4 要避免的。
顺带修：F4† 的变异锚点因 blockStates 改写而失效（withMutatedCopy 显式报
「anchor not found」——这条守卫按设计响亮失败，没有静默变绿）。
验证
- npm test 148/148（143 + F8 四条 + 性能守卫一条）
- npm run check 10/10
- 性能实测见上
- 干净副本实数见后续消息
|
|||
| b73607ed02 |
feat(memory-b): F3/F4 四态派生计数 + D3 工具面 + D5 提示渲染
顺序遵守裁定：F2 过滤先落地（上一条 425c441），这一条才加计数。
先做计数会数出一个恒为 0 的假指标。
四态定义与归属
noVector vector 为空 回填
unknownSpace 有 vector 但 fp 为空 重嵌（说不出来属空间）
spaceMismatch 有 vector、有 fp ≠ active 重嵌到当前空间
dimensionMismatch 有 vector 但宽度不对 改 provider 配置（F4：与上面分开）
embedFailure 本次调用拿不到向量 ← 不在这里，它是单次事件不是库状态
F3/F4 判据（4 条行为 + 3 条变异）
F3 四态从库派生；skipped 非零（实测 skipped=2，不是恒 0）
F4 dim 与 fp 分开计数，且不互相重复计入
F3 改库/删库后计数跟着变（证明不是内存累加，D4）
F3 skipped 在符号路也计（fusion.go:495 同款：只测向量路等于没测）
F3† 内存累加器实现 ⇒ 「跟随数据库」断言红
F3†symbol 计数只挂在向量路 ⇒ 符号路的 skipped 断言红
F4† 把 dim 并进 spaceMismatch ⇒ 分桶断言红
D4：从 DB 派生，不累加
store.blockStates(activeFp, activeDim) 每次扫行计算，无缓存无累加。
判据用「绕过插件直接 UPDATE / DELETE，计数必须跟着变」证明。
D3/D5：两个消费者，一个来源
- renderIndex() 与 stablemem_stats 都调 blockStates()，不各留一份
- D5 的提示读同一个 unavailable 计数（noVector+unknownSpace+
spaceMismatch+dimensionMismatch），说明「N 条暂不可语义召回，
仍可按精确文本检索」
- D3 判据含无空间/有空间两例：无 active space 时 mismatch 必然为 0
（没有参照物），这条我第一版判据写错了，已按实际语义修正
★ 一处新工具引入的回归（已修）
新增 stablemem_stats 时把工具名硬编码，第二个实例挂载时撞名
"tool 'stablemem_stats' is already registered" —— 与之前 prompt context
名同型：isolate() 不分区工具名。已改为可从 config.statsToolName 覆写，
loader 测试同步传参。
★ 一处「注册了但跑不到」的坑（已修）
registerTools 里我用了 return ctx.tools.register(...)，后续第二个
register 永远不可达，但文件读起来像注册了两个。已去掉 return 并注释。
验证
- npm test 143/143（138 + F3/F4 四条 + 变异三条 + D3/D5 两条）
- npm run check 10/10
- 实测数字（5 块构造库）：
blockStates('fp-cur',3) = {total:5, active:1, noVector:1,
unknownSpace:1, spaceMismatch:1, dimensionMismatch:1}
recall("缓存", fp-cur) → 返回 1 条, skipped=2
recall("4324", fp-cur) → 返回 2 条, skipped=2
- 干净副本实数见后续消息
|
|||
| 48c52497c2 |
feat(memory-b): F6 三段口径固化成判据 + A1b 降级记账
裁定：F6 选 (a)，措辞改写，不留互斥读法
原措辞「仍可按文本调出、不参与向量召回」读起来像互斥。实际是三层：
「按文本调出」= store 级无空间浏览，**不是生产召回路径**。
不改 F2 去迁就 F6 字面自洽的理由：F2 是 fusion.go:495 同款安全缺陷修复，
优先级高于 F6 的措辞。所以 F6 改成三段并列，每段一条断言，
**同一个用例内全断言**：
数据层：指纹变更后旧块仍在库中 —— 块数不减、按 fp 分组两行都在
浏览层：store 级不带空间参数的文本查询仍能取到旧块
召回层：带 fingerprint 的生产召回路径必须把旧块过滤掉（F2 承担）
为什么必须一个用例：只断言「过滤掉了」会漏掉数据被误删
（删库在召回层看起来就是「过滤正确」）；只断言「能调出」会把 F2 挡回去。
F6 判据 3 条
F6 三段全断言 + 反向对照（当前空间块两层都能取到，
防止断言因为「什么都找不到」而假成立）
F6†data 变异：putBlock 顺手 purge 其它空间的行走道 ⇒ 数据层断言红
F6†recall 变异：去掉空间过滤器 ⇒ 召回层断言红
两条变异各自只咬自己那一段，与 F6†data/†recall 的分工一致。
★ F6†data 的变异写法踩了三次坑（据实记）
1. 只写 form（没真改代码）—— 那不是变异，是自测
2. 注入 SQL 里的转义引号把测试文件写成 SyntaxError
3. 最终用 String.fromCharCode(39) 拼引号 + 数组 join 构造注入文本，
避开嵌套模板字符串的转义地狱
裁定 2：A1b 降级要记账
A1b 原先逐字节锁死 recallBlocks 源码，F2 合法地要改它，已降级为
「不传 fingerprint 时行为不变」。但降级后的 A1b-behaviour 只跑 golden
**前 5 个** case，变异 A（非精确带分数微调）下它可能是绿的。
已在判据注释写明：**结论不由 A1b 单独给出，由 A2 兜**
（A2 走全部 45 例、比精确分数）；A1b-behaviour 只是烟测，不是权威。
同步进 memo：docs/dev-notes-mutation-criteria.md 增第 5 条
「判据降级时，覆盖面必须一起交代」—— 这不是失效模式，是记账纪律。
自查问句：这条判据降级后，原本由它兜住的结论现在由谁兜？
答案必须是一个具体的、覆盖更广的判据名。
验证
- npm test 131/131、npm run check 10/10
- 干净副本（git archive + link-dsh）实数见后续消息
|
|||
| 425c441470 |
feat(memory-b): F5 固化为 fail-closed 判据 + F2 符号路空间过滤
裁定 1（F5）：fail-closed，写侧直接拒收
docs/phase-b-criteria.md §0.2 从「待拍板」改为「已定」：
无名向量的块直接拒收，比放过再靠下游兜更能守住空间隔离；
安全语义优先，**不为 HA 的疑似缺陷同构**
（HA 的 block_recall.go:140 三个 && 让空 fp 被放行，这是要修正而非复刻的行为）。
落点分两层并写明「缺一层都不算落实」：
写侧 putBlock 抛错（已实现）
读侧存量行归 unknownSpace、不参与向量召回（F 组）
F5 判据（5 种输入形态 + 变异）
省略 / 空串 / undefined / 数字 / null 一律抛错，且都不落库
合法形态仍工作（无向量无 fp；有向量有 fp）
F5† 变异：删掉写侧守卫 ⇒ 无名向量被接受 ⇒ F5 必红
顺带修一处：lib/store.js 的 vectorFP 加 String() 归一。
原先变异摘掉守卫后会以 SQLite bind 错误崩，掩盖了真正的断言失败
（变异因为错误的原因变红 = 不算证据）。
裁定 2（F2）：先过滤，后计数
F2 —— 空间过滤必须覆盖符号路，不只向量路
- store.searchFts 现在返回 fingerprint / hasVector，
两条 intake 路径（FTS 与包含兜底）都携带身份字段
★ 兜底路径第一版漏了这两个字段，导致过滤器看到 hasVector === undefined
而放行 —— 正是「过滤器只覆盖两个入口中的一个」那种 bug
- recallBlocks 新增 fingerprint 选项，在 pool 构建后统一过滤
刻意**不复刻** HA 的三连 &&：本仓 fail-closed，
带向量但无法命名空间的块一律排除（§0.2 裁定）
无向量的块不受影响（它们本来也不参与向量路，文本仍可检索）
- recallBlocksHybrid 在函数入口解析一次空间并注入 options，
六个降级分支全部经 scoped 调用 —— 逐调用点设置会在加第七个分支时漏掉一条
F2 判据（4 条行为 + 2 条独立变异）
F2 符号路命中旧空间块 → 被排除
F2 不传 fingerprint → 过滤器不生效（phase A 行为不变）
F2b 有向量但 fp 为空 → fail-closed 排除（HA 此处会放行）
F2 hybrid 在所有降级路径上应用同一过滤
F2† 删掉过滤器 → 旧空间块回来
F2†b 让 searchFts 不携带身份 → 过滤器失明（过滤只剩一个入口）
A1b 的调整（必须说明）
A1b 原先逐字节锁死 recallBlocks 源码，而 F2 合法地需要改这个函数。
改为守它真正要守的东西：**不传 fingerprint 时行为不变**
- 静态：过滤器必须 gated 在显式传入的 fingerprint 上
- 行为：golden fixture 前 5 例逐字段一致
依据：golden 语料 12 个块全部没有 fingerprint，
所以 F2 对 phase A 是纯增量；A2 仍全绿即为证。
验证（干净副本：git archive → 空目录 → link-dsh → 自跑）
见下一条消息附实数。
未 amend / 未 force push。
|
|||
| e2c2bb41b7 |
docs: 删掉 README「nothing to install」假声明，改正 peer 叙述
|
