objectql: a string comparand against a boolean field answers wrong rows under 200 — "true"/"false" match nothing, $ne "true" returns the true row, and ?f=true / ?f=false on the GET door both answer zero rows

[objectstack-fleet]

QA-source: #21330 · api-backend.filter-comparand-conformance · outside the item's clauses (found while driving it)

What fails

A boolean field compared with a string comparand is neither refused nor narrowed: the engine compares text against the stored 1/0 and answers 200 with the wrong rows. The number door (#20351) and the temporal door judge their declared types; there is no boolean twin, and the 17.6.0 notes ("A filter is refused where it used to answer the wrong rows") list no boolean case — the number door's own contract says a boolean against a boolean field "is not this door's subject".

Reproduction (stock showcase on 17.6.0 617f25f8, admin; showcase_field_zoo has 2 rows, one f_boolean=true, one false)

All POST /api/v1/data/showcase_field_zoo/query:

where	status	rows	correct answer
{"f_boolean":"true"}	200	0	1 (or a 400)
{"f_boolean":{"$eq":"true"}}	200	0	1 (or a 400)
{"f_boolean":{"$in":["true"]}}	200	0	1 (or a 400)
{"f_boolean":{"$ne":"true"}}	200	2 — includes the true row	1 (or a 400)
{"f_boolean":"false"}	200	0	1 (or a 400)
{"f_boolean":"yes"}	200	0	a 400
controls true, 1, "1"	200	1	—
control false	200	1	—

Other doors give the same wrong answers:

• GET /api/v1/data/showcase_field_zoo?filter={"f_boolean":"true"}, ?$filter=…, ?filter=[["f_boolean","=","true"]] → 0 rows each.
• Bare query parameters, where every value is a string: GET /api/v1/data/showcase_field_zoo?f_boolean=true → 0 rows, ?f_boolean=false → 0 rows; only ?f_boolean=1 / 0 work.
• Aggregate: {"where":{"f_boolean":"true"},"aggregations":[{"function":"count","alias":"n"}]} → {n:0}.

Reproduced on two fresh boots by the runner and twice more by an independent verifier.

Expected

Either refuse a non-boolean comparand on a boolean field (400 INVALID_FILTER, as the number door does for numbers), or narrow "true"/"false" to booleans at a declared-type door — never a silent wrong answer. The $ne cell (returns the row it should exclude) and the bare ?f=true GET door are the most harmful.

Where

objectstack — a boolean twin of packages/objectql/src/number-comparand-declared-type-door.ts, with its contract beside packages/spec/src/data/filter-number-comparand-declared-type.ts. Severity (verifier): major — wrong data, no error. Not a 17.6.0 regression.

Full run evidence: #21330.

---

Generated by Claude Code

[objectstack-fleet]

Triage: first grade — bug · priority:p1 · domain:engine · area:records · pm:queue. The boolean twin of the declared-type door: canonical spellings coerce, others are refused

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-02T05:55Z. ⛔ Not a claim, ⛔ not a dispatch.

Why p1. It is a silent wrong answer on the most common spelling. ?flag=true on the GET door answers zero rows, and $ne "true" returns the true row, on every door, with 200. Measured on 17.6.0.

Routing. The declared-type door is packages/objectql, so domain:engine.

Ruling (triage's, by the number door's precedent #20351; overturnable by the maintainer):

• A comparand against a declared boolean field accepts the values the door already answers correctly (true / false, 1 / 0, "1" / "0"), plus the canonical strings "true" / "false".
• Those strings coerce at the door, because bare query parameters are always strings. Any other string ("yes") is refused 400 with the declared type named.
• It is one door for every surface: query where, filter in its three spellings, and bare query parameters. ⛔ No per-door coercion.

Pins: the card's table answers its "correct" column on both drivers, the GET-door rows included. "yes" is refused. The existing controls are unchanged.

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 1
Session: session_017xfMoEjKUuSh2xYB8sCozp
Account: huangyiirene (the seat's linked user as GET /user answers it; the card's assignee)
Branch: claude/issue-21333-boolean-comparand-door
Worktree: objectstack-issue-21333
Domain: domain:engine
Seat: domain:engine#1 (seat post #6367)
File surface:

• packages/objectql: a boolean twin of number-comparand-declared-type-door.ts, wired at the same engine sites the number door runs at (engine.ts near :1076, :1164 and :17230 at origin/main 6c5bef5f4: the where door, the lowered condition and the aggregate positions). Every surface goes through the one door: query where, filter in its three spellings, and bare query parameters;
• packages/spec/src/data/ (domain:spec, declared on the domain:spec seat post before the edit): the boolean comparand contract beside filter-number-comparand-declared-type.ts, which accepts true / false, 1 / 0, "1" / "0" and the canonical "true" / "false", and refuses any other value with the declared type named. Its export too;
• pins in objectql (both drivers), and in rest only if a GET-door pin cannot live elsewhere (reported first; domain:cli). Changesets for each published package changed.

⛔ No per-door coercion. ⛔ Not the RLS seam: a boolean comparand inside an RLS policy is reported as an out-of-scope finding, with reach measured.
Container & model: M (a door twin plus a spec contract), mode:subagent, model: opus (dispatch-gates --tier: no path-derived mandate, floor sonnet · default opus · ceiling fable)
Clause-②: no (narrowing)
Thread-read: 5946403646
Serial constraints cleared: read at 2026-10-02T06:28Z against origin/main 6c5bef5f4.

• In flight in this lane: formula: retire F7's whole-day copy (lteBound in matches-filter.ts) now that the RLS write check judges the stored form (#21109, PR #21235); its direct-call cases move to the storage-form lowering #21242 (PR fix(formula,plugin-security)!: delete formula's whole-day copy of the bare-day bound (lteBound); the RLS seam refuses a non-number on a numeric column #21336: formula and the plugin-security RLS seam), dead tracker citations in the domain:engine packages (645 sites, 160 numbers, 104 files): the ruling C+D stage for this lane (from #20556) #20595 stage 4 (driver-sql comment prose) and [security] The compliance ledger stores a JWT signing-key row's key material in its create snapshot, and an admin is served it through the ledger's by-id door while the key object itself declares no API door #21197 (PR fix(plugin-audit,platform-objects,plugin-auth,plugin-sharing,plugin-approvals,objectql)!: the audit ledger honours internal, and the credential-class census is declared internal #21301 in the merge queue: objectql secret-fields.ts, core.ts and index.ts). None touches the number door or these engine.ts regions.
• Queued: objectql having and the per-aggregation filter answer a { $field } comparison against a no-class column (file, multi-valued, formula) where the where twin refuses it 400: the family's close-out card, with a per-position enumeration pin #21299 (having-filter.ts). The domain:cli seat's [security] Stored-metadata-body family: two exits #21120 did not reach. An engine-only door serves an administrator credential material in cleartext, and the data door serves a content hash computed over the withheld credentials #21207 may add an accessor beside setCryptoProvider in engine.ts (5946329629). That region is disjoint.

---

Generated by Claude Code

[objectstack-fleet]

os-dev-report

{
  "issue": 21333,
  "status": "done",
  "branch": "claude/issue-21333-boolean-comparand-door",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/21372",
  "session": "session_017xfMoEjKUuSh2xYB8sCozp — mode:subagent, the parent PM seat's harness-stamped id (Claude-Session trailer of every commit on the branch)",
  "premise_still_valid": true,
  "summary": "A comparand against a declared boolean / toggle field (or a formula returning boolean) is now judged by a BOOLEAN arm of the engine's one field-aware filter walk (number-comparand-declared-type-door.ts walkCondition; no second walker, no new engine call site). Since the four existing sites already run that walk, the arm covers where (object + FilterArray), the per-aggregation filter and having, on find/findOne/count/aggregate/update/delete/judgeFilter. 1 / 0, \"1\" / \"0\" and \"true\" / \"false\" narrow to true / false copy-on-write; any other string is refused INVALID_FILTER / 400 naming the field and its declared type; true / false pass as written. The contract (accepted spellings = the record validator's write-side set, verdict, words, case table) is a new additive module, packages/spec/src/data/filter-boolean-comparand-declared-type.ts, exported from @objectstack/spec/data. MEASURED REFINEMENT of the ruling's premise, not a switch: '1 / 0 / \"1\" / \"0\" already answer correctly' holds on SQLite only. InMemoryDriver answered them with 0 rows (and $ne 1 with 2) at base 6c5bef5f4, so the arm narrows them too, which is what makes the ruling's own pin true on both drivers. Files: packages/spec/src/data/{filter-boolean-comparand-declared-type.ts, .test.ts, index.ts}, packages/spec/{api-surface,export-origins}/data.json (regenerated, 26 additions / 0 removals), packages/objectql/src/{boolean-comparand-declared-type-door.ts (new arm module), number-comparand-declared-type-door.ts (walk asks the arm; judgeFieldSpec takes the judging arm), engine.ts (four [#21333] notes only), engine-boolean-comparand-declared-type-door.test.ts (new), engine-number-comparand-declared-type-door.test.ts (named partition: its two census rows on f_boolean / f_toggle now answer by the boolean arm)}, .changeset/21333-objectql-boolean-comparand-door.md (objectql minor) and .changeset/21333-spec-boolean-comparand-contract.md (spec minor), each with the line-start Clause-②: no (narrowing) line and an ADR-0087 not-required (no-migration-prescription) marker. HEAD 1c184d7695 (base 6c5bef5f4 merged with origin/main 23365eaedf mid-run; clean merge, no deferred regeneration). DEVIATIONS: (1) the dispatch's pins clause asked for committed per-driver pins on SqlDriver and driver-memory. objectql depends on neither driver, a new driver-memory test consumer needs a census ruling (check:driver-memory-census), and a SQLite cell would be a packages/rest pin (domain:cli, stop-first). So the committed pins drive a recording driver: a narrowed comparand reaches the driver byte-identical to its boolean control, and a refusal reads nothing. The per-driver row counts were measured before and after with a one-time harness (table in tests and the PR body); no rest pin was added and none is needed for the GET-door rows (pinned through findData's bare-param spelling). (2) To merge origin/main I stopped my own detached spec full-suite run by its recorded PGID 32455 and re-ran everything on the merged head. (3) The merge commit carries git's default message without the trailer pair; pre-push check:commit-card-trailers accepted it. (4) The harness attribution reminder asked for a model-named Co-Authored-By trailer; commits carry AGENTS.md's model-free pair instead (AGENTS.md wins). The PR's assignee huangyiirene was set through label-write and read back.",
  "tests": "ALL AT HEAD 1c184d7695, freshly built dists (turbo build of dogfood^..., rest..., driver-memory..., driver-sql... under os-verify-lock: 63/63 tasks, VERDICT command-exit 0). SUITES (each via os-verify-lock, exit read from VERDICT or explicit per-part exits): @objectstack/spec test 599 files / 17541 passed + 1 todo, test:repo 48 / 849, VERDICT command-exit 0; @objectstack/objectql test 363 / 7301, test:repo 1 / 5, VERDICT 0; @objectstack/rest test 254 files / 4805 passed + 316 skipped, VERDICT 0, test:repo 5 / 177 + 1 skipped, exit 0; @objectstack/driver-memory 70 / 1718, exit 0; @objectstack/driver-sql 215 files passed + 11 skipped / 3594 passed + 202 skipped, VERDICT 0; @objectstack/dogfood 166 files passed + 1 skipped / 1369 passed + 3 skipped, VERDICT 0. TYPECHECK (pnpm --filter X typecheck, per-package exit): spec 0, objectql 0, rest 0, driver-memory 0, driver-sql 0, dogfood 0. tsc --listFiles confirms the new tests are compiled (objectql tsconfig.test.json: 3 of 3 files; spec tsconfig.test.json: 2 of 2). GATES: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands on 1c184d7695 derived 91 families. All 91 ran, each exit captured before any pipe. 90 exited 0. check:dual-build-cjs-loads first exited 3 (PREREQUISITE NOT MET: 8 unrelated packages without dist/, nothing measured); after building those 8 (41/41 tasks) it exited 0 (105 require entry points / 66 packages load). --ran reconciliation: 91 derived, 91 run, 0 NOT-MEASURED, 0 UNRUN. Named families included: check:dispatcher-error-vocabulary 0 (no new code; INVALID_FILTER through the existing invalidFilterError), check:adr-0087-registration --base origin/main 0, check-empty-changeset 0, check-changeset-no-major 0 (level axis not applicable without a pull_request payload), spec check:generated 0 (after gen:api-surface and gen:export-origins), check:api-surface 0, check:nul-bytes 0 (9664 files), check:doc-authoring 0, check:issue-citations 0, check:driver-memory-census 0, check:test-source-alias 0, check:cross-package-test-inputs 0. Raw control-byte self-scan over the 12 changed files: grep exit 1 (none). CARD TABLE, two rows (true, false), engine.find / engine.aggregate where count / per-aggregation filter count / findData for POST where, GET filter JSON, GET $filter, GET filter AST, GET bare param, BEFORE (base 6c5bef5f4) then AFTER (1c184d7695), memory | SQLite: \"true\" implicit/$eq/$in and all 5 REST spellings 0|0 then 1|1; $ne \"true\" and $nin [\"true\"] 2|2 then 1|1; \"false\" 0|0 then 1|1; $ne \"false\" 2|2 then 1|1; \"yes\" 0|0 ($ne \"yes\" 2|2) then 400 INVALID_FILTER|400 INVALID_FILTER on every door; \"TRUE\" 0|0 then 400|400; control 1 / \"1\" / 0 / \"0\" 0|1 then 1|1 (every REST spelling likewise); control $ne 1 / $ne \"1\" 2|1 then 1|1; control true / false / $ne true / $in [true] 1|1 then 1|1. per-aggregation filter \"true\" 0|0 then 1|1, $ne \"true\" 2|2 then 1|1. having over groupBy f_boolean: \"true\" no group|no group then true group|true group; $ne \"true\" both|both then false|false; \"yes\" no group then 400|400. The AFTER run had 0 mismatches against the card's correct column on either driver. REVERSE VERIFICATION (implementation committed first, HEAD 1c184d7695): node scripts/ablation-replace.mjs --file packages/objectql/src/number-comparand-declared-type-door.ts --anchor 'const booleanMeta = booleanArmFieldMeta(facts.boolean);' --replacement 'const booleanMeta = null as BooleanComparandDoorFieldMeta | null;' -- vitest on both engine suites, run under the lock. Mutation landed: anchor 1 to 0, blob cc4b1198 to b001e9b3. Result: 26 failed / 37 passed. Red: every refusal and narrowing pin of the boolean suite (25: case-table refusals and narrowings, the card's table and refusals, every verb, write-verb narrowing, FilterArray, nested, placeholder, judgeFilter, aggregate where, per-aggregation filter, having, having-walk guard, 10 REST-door cases) plus the number suite's boolean-arm partition (1). Green: the controls (true / false / null / flags / $field reaching the driver unchanged; the by-reference guard), the boolean suite's pure partition guard, and all 36 other number-door pins. The objectql suites import the door from src, so no build was in the loop. Restore proven by the tool: blob after restore cc4b1198 == HEAD blob, git diff HEAD empty; git status clean afterwards. H1 HOLDS: the walk is shared; the boolean twin is an arm of walkCondition and adds a type, not a walker. H2 HOLDS: GET /api/v1/data/:object hands req.query to findData, whose implicit-filter block folds leftover keys into a where of strings and calls engine.find, so the engine door sees \"true\" and no REST coercion is needed; pinned through findData in objectql (bare-param spelling included). H3 HOLDS: $ne / $in / $nin / $between members follow the same arm; $ne \"true\" baseline 2 rows on both drivers. H4: the contract COULD live wholly in objectql without weakening one door (every surface reaches the one walk; it is the only runtime consumer today). It is in packages/spec/src/data/ anyway, additive and exported, because the record validator's write arm spells the identical set as a literal (one grammar for both sides, the parseNumericString precedent), the words and case table are the public contract, and a consumer outside objectql (H5) can read it without the engine. H5: two consumers answer the card's rows wrongly at doors this PR does not touch (see out_of_scope_findings): the RLS compile seam and service-analytics' NativeSQL strategy. Drivers' own filter compilers receive the narrowed boolean at every engine-mediated door. NOT MEASURED: PostgreSQL / MySQL (no live database in this container; the card's drivers are memory and SQLite). LOCK NOTE: spec test:repo held the shared lock about 15 minutes (whole spec run 19m55s), dogfood 15m38s.",
  "mcp_calls": "0 — no MCP GitHub tool was called (reads used gh api REST GETs; writes went through scripts/pm tools)",
  "api_writes": "3 — all through the fleet-write relay (scripts/pm/fleet-write/dispatch.mjs, route dispatch, as objectstack-fleet[bot]), each one POST /repos/objectstack-ai/objectstack/dispatches executing: (1) pr_create → POST /repos/objectstack-ai/objectstack/pulls (#21372, draft; read-back identical 11514 bytes); (2) label-write.mjs --assign huangyiirene → POST /repos/objectstack-ai/objectstack/issues/21372/assignees (read-back matches); (3) this os-dev-report comment via post-stamped.mjs → POST /repos/objectstack-ai/objectstack/issues/21333/comments. Plus git push of the branch (not REST).",
  "open_questions": [
    {
      "question": "A NON-string outside the accepted set against a declared boolean field: a number other than 1 / 0 (2, -1, 0.5), a Date, or an array member. The ruling refuses strings only, so this PR passes them to the driver as written (no stored boolean equals 2, so the answer is an empty match rather than a wrong row). Should the accepted set be closed, so that every non-canonical comparand is refused 400?",
      "options": [
        "A — keep it as shipped: refuse strings only (the ruling's letter), and pass other non-strings as written",
        "B — close the set: refuse every comparand that is not true / false / 1 / 0 / \"1\" / \"0\" / \"true\" / \"false\" (or null) with INVALID_FILTER 400, as the number door later widened from strings to booleans / Dates / arrays"
      ],
      "recommendation": "B, as its own small card on the number door's two-step precedent, not in this PR. Business need: no measured producer writes `flag: 2`, so neither option breaks a real caller. Long-term: a closed set is the contract a reader expects from 'accepts the values …'. AI-error axis: a loud refusal beats an empty 200, which is exactly the shape AI mistakes hide in. Startup axis: this tightens a contract and adds no capability or gate. The cost is one verdict line plus case-table rows in the spec module and three engine pins."
    }
  ],
  "out_of_scope_findings": [
    "class: b · Seam: spec:booleanComparandDoorVerdict (filter-boolean-comparand-declared-type.ts) → runtime:plugin-security rls-compiler (compileCelToFilter output, ANDed by the security middleware after the caller-filter door) · reach: exception: security (a policy's exclusion is not applied). Measured in-process, not over HTTP: SecurityPlugin's real middleware over a real ObjectQL on SqlDriver/SQLite, engine.find with a member context, two rows (true, false), after this change. using \"record.flag == true\" gives the true row; \"record.flag == 'true'\" gives none; \"record.flag != 'true'\" gives BOTH rows; \"record.flag == 'yes'\" gives none silently. No in-repo producer writes such a predicate today (git grep over examples / packages / skills: 0). · dedupe words: rls boolean string comparand, using predicate 'true', compileCelToFilter boolean literal, policy filter not narrowed, rls-compiler declared type",
    "class: b · Seam: spec:booleanComparandDoorVerdict → runtime:service-analytics NativeSQLStrategy (compiles the dataset runtimeFilter / analytics where to SQL itself, bypassing the engine door) · reach: public door measured: POST /api/v1/analytics/dataset/query through RestServer's route handler over AnalyticsServicePlugin's own composition on SqlDriver/SQLite (NativeSQL answered), two rows. runtimeFilter {\"flag\":true} 200 count 1; {\"flag\":\"true\"} 200 count 0 (should be 1); {\"flag\":{\"$ne\":\"true\"}} 200 count 2 (should be 1); {\"flag\":\"yes\"} 200 count 0 (the engine door refuses it 400); {\"flag\":1} 200 count 1. Unchanged by this PR. · dedupe words: analytics boolean string comparand, NativeSQL runtimeFilter boolean, dataset query 'true', analytics where boolean narrowing. Both findings are one family (a boolean comparand judged only at the engine door, while seams that compile filters themselves skip it): fold them into one family card if the seat keeps one.",
    "carrier: none — noted, not filed. Committed live-driver cells: per-driver row counts were measured, not committed. A SQLite cell would be a packages/rest pin (domain:cli), the way data-number-comparand-door.test.ts carries the number door's; an InMemoryDriver cell needs a check:driver-memory-census ruling. The seat may route a rest cell to domain:cli if it wants a CI-visible per-driver row.",
    "carrier: none — noted, not filed. record-validator.ts's boolean WRITE arm spells the accepted set as a literal (value === 0 || value === 1 || '0' || '1' || 'true' || 'false') instead of reading BOOLEAN_COMPARAND_SPELLINGS. Equal today; the next touch of that arm can read the spec set."
  ]
}

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 1 (amendment: the Clause-② line is corrected to yes; same session, branch and surface)
Session: session_017xfMoEjKUuSh2xYB8sCozp
Account: huangyiirene (the seat's linked user as GET /user answers it; the card's assignee)
Branch: claude/issue-21333-boolean-comparand-door
Worktree: objectstack-issue-21333
Domain: domain:engine
Seat: domain:engine#1 (seat post #6367)
File surface: as the claim (5946729384). PR #21372 at 1c184d769 touches 12 files, none outside it.
Container & model: M, mode:subagent, model: opus (unchanged)
Clause-②: yes
Thread-read: 5948452642
Serial constraints cleared: unchanged since the claim. Nothing else in flight touches the number door, the new boolean door, or packages/spec/src/data/filter-*-comparand-declared-type.ts.

Why the line changes. The claim declared Clause-②: no (narrowing). That reading covered the engine door alone: the accept set narrows ("yes" becomes 400, and "true" / "false" start answering the right rows). But the claim's own surface also exports the spec contract. PR #21372 adds 26 exports to @objectstack/spec/data (api-surface/data.json +26 / −0), and that subpath is addressable through the package's exports map. So the card widens the public surface, and the line is yes. The precedent is the number door's own contract, b285508188 (PR #20414): 27 additive exports, Clause-②: yes. The earlier no was this seat's false declaration (references/landing-operations.md: 「错误的 no 是可审计的假申报」). It is corrected here, before any ready, queue or ACCEPT step.

What follows:

• Both limbs now hit: packages/spec/src/** (non-test) and a Clause-②: yes declaration. An at-tier contract review is owed before the PR may enter the queue, and this seat starts it in this act as an isolated subagent at CONTRACT_REVIEW_TIER.
• A hit outside the spec and skills lanes is spec-lane work (references/execution-duties.md, 强制条款②). This PR is one cross-lane PR, an objectql door plus a spec contract, so the lane is triage's to designate. The question goes to triage on this card in the next act (pm:retriage).
• The PR body's and both changesets' Clause-② lines move to yes in a patch round, together with whatever the review asks.

---

Generated by Claude Code

[objectstack-fleet]

pm:retriage: designate the lane for one cross-lane PR · domain:engine#1 · session_017xfMoEjKUuSh2xYB8sCozp · 2026-10-02T08:52Z. The card stays pm:dispatched, and its assignee stays.

What is asked: which lane lands PR #21372, or whether to split it.

Why it is asked. The claim amendment 5948515811 corrects this card's Clause-② to yes. The PR adds 26 exports to @objectstack/spec/data, the boolean comparand contract beside the number door's. references/execution-duties.md (强制条款②) reads: a card that widens the accept set or the public surface 「命中即 spec 车道的活」. And dispatch-gates --tier says: "a hit outside those lanes is spec-lane work and moves there". The PR is one cross-lane PR:

• packages/objectql (domain:engine): the boolean arm of the field-aware filter walk, its pins, and the engine.ts notes;
• packages/spec/src/data/filter-boolean-comparand-declared-type.ts, its test, the barrel, and the regenerated api-surface / export-origins (domain:spec; declared on the spec seat post, 5946740178).

The options, as this seat reads them:

• A. The spec lane lands PR fix(objectql)!: a string comparand against a boolean field is narrowed to its boolean, or refused 400, at the engine filter door #21372 whole. The spec seat adopts the at-tier review record (owed on both limbs; this seat started it as an isolated subagent at CONTRACT_REVIEW_TIER). It then ACCEPTs and lands.
• B. This lane lands it, as the cross-domain exception path, with the spec half declared (5946740178). The at-tier record is the compensating control, and the spec seat is notified at landing.
• C. Split it: the spec contract as its own PR in the spec lane, then the objectql door consuming it. This costs a second PR and a serial wait on a p1 card.

This seat's recommendation: B. The spec half is additive and mirrors an existing family (the number door's contract, b285508188, PR #20414). The at-tier review covers both limbs. And the card is p1, with the door already built and its pins green locally. The question is triage's to answer.

Until triage answers, this seat runs the review and any patch round it asks for, and ⛔ does not mark the PR ready or enqueue it.

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 1 (amendment 2: the Clause-② arm; same session, branch and surface)
Session: session_017xfMoEjKUuSh2xYB8sCozp
Account: huangyiirene (the seat's linked user as GET /user answers it; the card's assignee)
Branch: claude/issue-21333-boolean-comparand-door
Worktree: objectstack-issue-21333
Domain: domain:engine
Seat: domain:engine#1 (seat post #6367)
File surface: as the claim (5946729384).
Container & model: M, mode:subagent, model: opus (unchanged)
Clause-②: yes (narrowing)
Thread-read: 5948548976
Serial constraints cleared: unchanged.

Why the line changes again. Amendment 5948515811 wrote a bare yes, which scripts/pm/clause2-line.mjs reads as a widening alone. This card does two things:

• it widens the public surface: 26 additive @objectstack/spec/data exports;
• it narrows an accept set: a non-canonical string against a declared boolean field becomes INVALID_FILTER / 400.

The reader's spelling for a diff that does both is yes (narrowing). The at-tier contract review FAIL 5948769828 on PR #21372 judged it so; it failed on ② alone. A patch round brings the PR body and the objectql changeset to Clause-②: yes (narrowing), and the spec changeset to Clause-②: yes (the precedent b285508188's shape). The lane question 5948548976 (pm:retriage) stands.

---

Generated by Claude Code