From 1c098dc48cd94751ca4adcca69d93b2c46d34e95 Mon Sep 17 00:00:00 2001 From: "A.Shakhmatov" Date: Mon, 10 Aug 2026 22:30:04 +0300 Subject: [PATCH] plan: the index corpus is M3's last gate 42 cases at 3/39, and the two rows where recording it corrected the review: `$in` in a partial filter is allowed, and a same-key different-filter clash with no explicit name is IndexKeySpecsConflict (86) rather than 67. Everything else at this commit is unmoved: 249/249 unit tests, operators 125/0, positional 51/0, aggregation 70/0, pinned crud 228/63/196. --- PLAN.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/PLAN.md b/PLAN.md index a9a3feb..14ff3b0 100644 --- a/PLAN.md +++ b/PLAN.md @@ -1143,6 +1143,14 @@ has to be its own commit with its own re-recorded scorecard. contrast, was honestly missing -- refused, with the wrong code (2 where mongod says 67) but the right answer. + **`tests/spec/indexes/` is the gate**, recorded red at 3/39 across 42 cases. + A case there is a *sequence* -- create, insert, read, list -- because an + index outlives a `deleteMany` and every case is about which indexes exist. + Recording it corrected two of the review's own guesses: `$in` in a partial + filter is **allowed** (the review grouped it with `$ne` and `$regex`, which + are 67), and the same key with a different filter and no explicit name is + **IndexKeySpecsConflict (86)**, not 67. + `docs/M3_INDEX_TYPES_DESIGN_REVIEW.md` measures both features' rules and argues the planner rule that decides the design: a partial index may only answer a query whose predicates *imply* its filter, so until that test