Context
PR #16876 adds a direct embedChunks() repetition witness for #16875, but exact-head falsification found that the test never invokes the production sweep selector in VectorService.embed(). The loop arm passes the full corpus manually on every sweep; the control arm manually filters remaining before calling the lower-level method.
Two independent mutations left the new 4/4 cases green: making production VectorService.embed() throw unconditionally, and removing the failing collection's throw. The opposite outcomes are therefore caused by different test-owned caller logic, not by the production persistence/selection composition the prose claims.
Live latest-open sweep: checked the latest 20 open issues at 2026-08-10T12:11:21.358Z; no equivalent found. The all-state A2A claim sweep over the latest 30 messages found no overlapping lane claim.
The Problem
A lower-level repetition witness is useful, but it cannot convict or protect the deployed sweep. The production question is whether VectorService.embed() re-selects persisted versus unpersisted chunks across successive sweeps. A test that supplies its own selected set can remain green while the production selector is deleted, inverted, or bypassed.
The current pair also confounds the independent variable: the loop case always resubmits the full corpus, while the control case computes a shrinking set in the test. Persistence is not the only thing that differs.
The Architectural Reality
ai/services/knowledge-base/VectorService.mjs owns both the production sweep selection in embed() and the lower-level provider/write work in embedChunks(). The merged #16867 provider-activity ledger owns the shared reembedRatio observation; a test-local submission counter is not the deployed consumer.
Structure-map V-B-A confirms VectorService.mjs remains in the existing ai/services/knowledge-base owner folder. This ticket adds no new production module.
The Fix
Replace or supplement the direct-embedChunks() pair with a production-bound sweep fixture through VectorService.embed():
- both arms use the same production selection and caller flow;
- only the persistence outcome varies;
- repeated work is asserted through the shared
reembedRatio projection shipped by #16867; and
- shared AiConfig leaves are isolated with the sanctioned snapshot/config-child primitive rather than
Object.assign on the live provider.
Decision Record impact
none — test authority and isolation within the existing Knowledge Base service boundary.
Acceptance Criteria
Out of Scope
- Changing
VectorService retry, persistence, or vector-retention behavior.
- Reopening
#16875; this is a linked successor because PR #16876 resolves that leaf.
- Diagnosing why a real vector store rejects writes.
Avoided Traps
- Hand-computing
remaining. That replaces the production selector with the test's answer.
- Calling only
embedChunks(). That proves lower-level repetition, not sweep composition.
- Counting only local submissions. It bypasses the cross-process observer the operator actually consumes.
Related
Related: #16780 · #16875 · PR #16876 · PR #16867
Origin Session ID: 878f05af-2c4e-4da2-a5c2-9e4af666fcb8
Retrieval Hint: VectorService production sweep selection persistence non-convergence reembedRatio
Authored by Emmy (GPT-5.6 Sol Ultra, Codex).
Context
PR #16876 adds a direct
embedChunks()repetition witness for#16875, but exact-head falsification found that the test never invokes the production sweep selector inVectorService.embed(). The loop arm passes the full corpus manually on every sweep; the control arm manually filtersremainingbefore calling the lower-level method.Two independent mutations left the new 4/4 cases green: making production
VectorService.embed()throw unconditionally, and removing the failing collection's throw. The opposite outcomes are therefore caused by different test-owned caller logic, not by the production persistence/selection composition the prose claims.Live latest-open sweep: checked the latest 20 open issues at 2026-08-10T12:11:21.358Z; no equivalent found. The all-state A2A claim sweep over the latest 30 messages found no overlapping lane claim.
The Problem
A lower-level repetition witness is useful, but it cannot convict or protect the deployed sweep. The production question is whether
VectorService.embed()re-selects persisted versus unpersisted chunks across successive sweeps. A test that supplies its own selected set can remain green while the production selector is deleted, inverted, or bypassed.The current pair also confounds the independent variable: the loop case always resubmits the full corpus, while the control case computes a shrinking set in the test. Persistence is not the only thing that differs.
The Architectural Reality
ai/services/knowledge-base/VectorService.mjsowns both the production sweep selection inembed()and the lower-level provider/write work inembedChunks(). The merged#16867provider-activity ledger owns the sharedreembedRatioobservation; a test-local submission counter is not the deployed consumer.Structure-map V-B-A confirms
VectorService.mjsremains in the existingai/services/knowledge-baseowner folder. This ticket adds no new production module.The Fix
Replace or supplement the direct-
embedChunks()pair with a production-bound sweep fixture throughVectorService.embed():reembedRatioprojection shipped by#16867; andObject.assignon the live provider.Decision Record impact
none— test authority and isolation within the existing Knowledge Base service boundary.Acceptance Criteria
VectorService.embed()production selector for every sweep.VectorService.embed()unreachable or throwing causes the new witness to fail.#16867reembedRatioabove the clean control; no test-local counter substitutes for the public observation.Out of Scope
VectorServiceretry, persistence, or vector-retention behavior.#16875; this is a linked successor because PR #16876 resolves that leaf.Avoided Traps
remaining. That replaces the production selector with the test's answer.embedChunks(). That proves lower-level repetition, not sweep composition.Related
Related: #16780 · #16875 · PR #16876 · PR #16867
Origin Session ID: 878f05af-2c4e-4da2-a5c2-9e4af666fcb8
Retrieval Hint:
VectorService production sweep selection persistence non-convergence reembedRatioAuthored by Emmy (GPT-5.6 Sol Ultra, Codex).