[finding] three first-party call sites re-spell objectql error codes that #16159 is making importable #16309

Activity

1. claude

   added

   finding

   domain:engine

   on Sep 6, 2026
2. os-zhuang commented on Sep 7, 2026

   

   os-zhuang

   on Sep 7, 2026 – with Claude

   Contributor

   More actions

   Triage: closing not planned — outside the three admission classes (#16351, as refined by PR #16557), and consistent with #16260, closed today on the same reasoning about the same family.

   Against each class:

   • (a) reproducible defect — ⛔ none, and the card says so in its own second line: "Observation, not a runtime defect." All three sites match the codes the engine actually throws today.
   • (b) violation of a declared contract — ⛔ none, and the card is explicit that the opposite holds: check:error-code-provenance counts each as a stamp site in the consumer's own package, and they are listed and legal today, and stay legal after conversion; nothing is red either way.
   • (c) metadata trap — ⛔ not applicable.

   Under the boundary now in the rule — 「(a) 的分界是不完整 vs 错误」 — this is incomplete, not wrong: three call sites that could import a constant and instead spell a string that is currently correct.

   ⭐ The census itself is good and survives the close, especially the two-spellings-in-one-file reading on error-response.ts:1024/:1029 (it matches the refusal, then re-authors the same spelling into the envelope it builds).

   ⚠️ The strongest argument for keeping it open, stated fairly because I am closing against it: "converting the producers without ever converting the first-party consumers leaves the repo demonstrating the pattern it tells customers not to use." That is true and it is a real coherence cost. ⛔ It is not, however, a defect — and admitting coherence arguments is how the queue fills with work nobody is waiting on. The threshold's job is to draw exactly this line.

   承接者: ⛔ none, and I checked rather than assumed. #16159's remaining batches are a producer-side sweep inside @objectstack/objectql; this is a consumer-side change in packages/rest and packages/metadata-protocol, which those batches do not open. The card fenced it out of PR #16308 for precisely that reason and was right to. ⇒ No PR is going to walk past these three lines.

   What I am uncertain about: whether the packages/rest half is cheap enough that closing is a false economy. ⚠️ It genuinely is cheap — that package already declares "@objectstack/objectql": "workspace:*", so its two sites are one import away once #16308 lands. ⛔ But cheapness is not admission; it is a reason for whoever next edits error-response.ts to take it as a free rider, which they can do at any time without this card.

   ⭐ The metadata-protocol half must not be treated as the same edit, and this survives the close as the card's most important warning. That package does not depend on @objectstack/objectql at all. Converting its site would add a dependency from the protocol layer onto the query engine, which may well be the wrong direction on purpose. ⇒ If anyone acts on the rest half later, ⛔ they must stop at the package boundary. Either seed-loader.ts:2081 stays a deliberate wire-string match — in which case a comment saying so is the deliverable, not an import — or the layering question is answered first, on its own card.

   Reopen conditions (either, no approval needed):

   1. Any of the three spellings actually diverges from what the engine throws — e.g. one of these codes is renamed and a consumer's literal is not updated. That is a live defect with a silent failure path (the REST layer stops recognising the refusal and builds the wrong envelope), and it is class (a) the moment it happens.
   2. objectql: 11 error classes still spell their code as an inline literal, so a consumer cannot follow the by code, not instanceof convention the docs already teach #16159 grows an explicit consumer-side phase. At that point a carrier exists and this census is its worklist.

   Reversibility: fully reversible; nothing decays. ⚠️ Note the card carries Blocked-by: #16308 — the constants do not exist on main until that PR lands, so ⛔ nothing could have been done here yet in any case.

   ⛔ Distinct from #16260 (also closed today), which asks which barrel publishes these constants. Different question, same family; ⛔ neither is a duplicate of the other.

   ---

   Generated by Claude Code
3. os-zhuang

   closed this as not plannedon Sep 7, 2026