Filed by the domain:ui execution seat (session session_01EMrWaQw3XS5DxTHxp4yRyC), unassigned and unlabelled beyond finding — ⛔ domain:* and grading are triage's. First reported by the #6939-group-3 implementer, which measured one row of it and could not file (/search/issues 403); this seat ran the duplicate check and re-measured the whole paragraph, which changed what the card is: it is not one stale row, it is a list with a scheduled falsifier.
The claim surface
examples/schema-catalog/test/safe-validate-corpus-6318.test.ts, closing paragraph of the module docblock:
⛔ This file deliberately does NOT pin the size of the remaining bucket. The 28 entries still in it are open findings on the Zod union (tooltip and context-menu demand a children their renderers never read; tree-view demands data where the renderer reads nodes first; kanban declares columns[].items where the board reads columns[].cards; and so on), and a number pinned here would turn red on the card that repairs any one of them.
The paragraph correctly refuses to pin the count, and gives a good reason. Then it enumerates the contents by name — and nothing pins those either.
Measured on origin/main 045d20ba8
| the header's claim |
reading |
"tooltip and context-menu demand a children their renderers never read" |
❌ FALSE. Neither schema declares children at all. Both were repaired by #6939, and each says so in its own docblock: packages/types/src/zod/overlay.zod.ts:105 — "⚠️ This member used to REQUIRE children"; :213 — the same sentence for context-menu. |
"tree-view demands data where the renderer reads nodes first" |
❌ FALSE. packages/types/src/zod/data-display.zod.ts:316 is z.array(TreeNodeSchema).optional(). Repaired by #6939 (landed 777e5c6f4), and its .describe() now reads "OPTIONAL since objectui#6939". |
"kanban declares columns[].items where the board reads columns[].cards" |
✅ TRUE today — packages/types/src/zod/complex.zod.ts:55, items: z.array(KanbanCardSchema), required. ⚠️ But this is exactly what PR #7541 (#6939 group 3) repairs, and that PR is ready with auto-merge armed. |
| "The 28 entries still in it" |
NOT RECOUNTED. Recounting needs node packages/cli/dist/cli.js check, which needs a full workspace build; I did not run it, and I am not repeating an unverified number as though I had. Nothing asserts it either way. |
⇒ Of the four named examples, two are already false, and the third is one merge away. The paragraph will be entirely false about tooltip, context-menu, tree-view and kanban while still presenting itself as the reader's map of what is open.
⭐ Why this is not "a stale comment, correct it"
#6939 is a multi-group repair card, and each group falsifies one of these rows. The rows are not an accidental snapshot — they are a list of the exact work items an open card is executing, in an open card's own file. Three of #6939's groups have landed and falsified three rows; the remaining groups will take the rest. Correcting the text once puts it right until the next group lands, which on the current cadence is hours.
That makes this a different defect from the ordinary stale docblock: the falsifier is scheduled and known by name. The header is a hand-maintained index of another card's open work, kept in a third file, with no link between them. Nothing in #6939's flow says "and update that paragraph", and nothing goes red when a group lands.
⚠️ The sibling instance is #7433 (the zod-mirror-parity.test.ts population count), which is the same class — hand-maintained prose about the repo's state, in a file whose subject is measurement, with no pin. That card has now measured its own remedy failing twice: #6141 corrected the number by hand and it rotted in ten days, and the number the correction wrote was already wrong by 3 on the day it was written. Filing this separately rather than as a comment there because the remedies genuinely differ — #7433's fork is "derive the count vs. pin it"; this one's is "should the paragraph enumerate at all".
Not claimed
⛔ Nothing here says the file's pins are wrong. They are not: the seven repaired entries are pinned by the KEY that moved rather than by .success, with a counter-probe against a mirror that accepts everything, and that construction is sound and unaffected. ⛔ Nothing here asks for the bucket size to be pinned — the header's reason for refusing that is correct and this card does not reopen it. The defect is only in the named enumeration, and only in that it has no gate.
Directions, ⛔ none chosen — this needs a ruling
I would not pick C for that reason, but the choice between A and B is a real fork about where the authority for "what is still open" should live, and it is the maintainer's, not this seat's.
Duplicate check
search_issues, repo-scoped, semantic. 62 on-topic results, including the parent #6318, the live repair card #6939, the sibling-class #7433, and the adjacent stale-prose family (#7302, #6973, #7151, #6810, #7115). A non-empty, genuinely on-topic hit set ⇒ the absence of a card for this paragraph is a reading, not a broken query. ⚠️ This matters here: search_issues was rate-limited for roughly thirty minutes earlier in this session, and a zero returned during that window would have been an instrument failure rather than a measurement.
Refs: #6318 (the parent) · #6939 (the repair card whose groups falsify the rows) · #7433 (the sibling instance, same class, different remedy) · PR #7541 (#6939 group 3 — falsifies the kanban row on landing).
Filed by the
domain:uiexecution seat (sessionsession_01EMrWaQw3XS5DxTHxp4yRyC), unassigned and unlabelled beyondfinding— ⛔domain:*and grading are triage's. First reported by the #6939-group-3 implementer, which measured one row of it and could not file (/search/issues403); this seat ran the duplicate check and re-measured the whole paragraph, which changed what the card is: it is not one stale row, it is a list with a scheduled falsifier.The claim surface
examples/schema-catalog/test/safe-validate-corpus-6318.test.ts, closing paragraph of the module docblock:The paragraph correctly refuses to pin the count, and gives a good reason. Then it enumerates the contents by name — and nothing pins those either.
Measured on
origin/main045d20ba8tooltipandcontext-menudemand achildrentheir renderers never read"childrenat all. Both were repaired by #6939, and each says so in its own docblock:packages/types/src/zod/overlay.zod.ts:105— "children";:213— the same sentence forcontext-menu.tree-viewdemandsdatawhere the renderer readsnodesfirst"packages/types/src/zod/data-display.zod.ts:316isz.array(TreeNodeSchema).optional(). Repaired by #6939 (landed777e5c6f4), and its.describe()now reads "OPTIONAL since objectui#6939".kanbandeclarescolumns[].itemswhere the board readscolumns[].cards"packages/types/src/zod/complex.zod.ts:55,items: z.array(KanbanCardSchema), required.node packages/cli/dist/cli.js check, which needs a full workspace build; I did not run it, and I am not repeating an unverified number as though I had. Nothing asserts it either way.⇒ Of the four named examples, two are already false, and the third is one merge away. The paragraph will be entirely false about
tooltip,context-menu,tree-viewandkanbanwhile still presenting itself as the reader's map of what is open.⭐ Why this is not "a stale comment, correct it"
#6939 is a multi-group repair card, and each group falsifies one of these rows. The rows are not an accidental snapshot — they are a list of the exact work items an open card is executing, in an open card's own file. Three of #6939's groups have landed and falsified three rows; the remaining groups will take the rest. Correcting the text once puts it right until the next group lands, which on the current cadence is hours.
That makes this a different defect from the ordinary stale docblock: the falsifier is scheduled and known by name. The header is a hand-maintained index of another card's open work, kept in a third file, with no link between them. Nothing in #6939's flow says "and update that paragraph", and nothing goes red when a group lands.
zod-mirror-parity.test.tspopulation count), which is the same class — hand-maintained prose about the repo's state, in a file whose subject is measurement, with no pin. That card has now measured its own remedy failing twice: #6141 corrected the number by hand and it rotted in ten days, and the number the correction wrote was already wrong by 3 on the day it was written. Filing this separately rather than as a comment there because the remedies genuinely differ — #7433's fork is "derive the count vs. pin it"; this one's is "should the paragraph enumerate at all".Not claimed
⛔ Nothing here says the file's pins are wrong. They are not: the seven repaired entries are pinned by the KEY that moved rather than by
.success, with a counter-probe against a mirror that accepts everything, and that construction is sound and unaffected. ⛔ Nothing here asks for the bucket size to be pinned — the header's reason for refusing that is correct and this card does not reopen it. The defect is only in the named enumeration, and only in that it has no gate.Directions, ⛔ none chosen — this needs a ruling
safeValidateSchemabecause the Zod mirror names a key its renderer never reads (8 components) #6939 (and 53 in-repo schema files carry a registered ObjectUI type but failsafeValidateSchema#6318), so the authority for "what is still open" lives on the cards that are actually maintained. Cost: a reader of the test file has to follow a link to learn why the bucket is non-empty.objectui checkat run time and print it, asserting nothing about its size or contents. Cost: the file grows a dependency on the CLI's output format, and printing is not pinning — it informs, it does not hold.safeValidateSchemabecause the Zod mirror names a key its renderer never reads (8 components) #6939's per-group checklist, so each group's landing updates the paragraph. Cost: paid by every future group, and it is the same "a human remembers to restate it" mechanism that finding(types): zod-mirror-parity's population count rotted AGAIN — #6141 predicted this in writing, the cheap route was taken, and it recurred within ten days #7433 has now measured failing twice in the sibling file — including once at the moment of restatement.I would not pick C for that reason, but the choice between A and B is a real fork about where the authority for "what is still open" should live, and it is the maintainer's, not this seat's.
Duplicate check
search_issues, repo-scoped, semantic. 62 on-topic results, including the parent #6318, the live repair card #6939, the sibling-class #7433, and the adjacent stale-prose family (#7302, #6973, #7151, #6810, #7115). A non-empty, genuinely on-topic hit set ⇒ the absence of a card for this paragraph is a reading, not a broken query.search_issueswas rate-limited for roughly thirty minutes earlier in this session, and a zero returned during that window would have been an instrument failure rather than a measurement.Refs: #6318 (the parent) · #6939 (the repair card whose groups falsify the rows) · #7433 (the sibling instance, same class, different remedy) · PR #7541 (#6939 group 3 — falsifies the
kanbanrow on landing).