Repository navigation
[finding] The objectstack-formula reference index advertises data/date-macros.zod.ts, a surface the SKILL.md routes to objectstack-query — SKILL_MAP in build-skill-references.ts maps it to both #14562
Description
Found while implementing #14316 (skills/objectstack-formula optimization flight, audit finding FRM-C-05). Filed unassigned and out of scope for that PR — the fix is a generator change in packages/spec, and #14316's ruling confines it to skills/objectstack-formula/SKILL.md.
What is measured
packages/spec/scripts/build-skill-references.ts has data/date-macros.zod.ts in two SKILL_MAP entries:
- under
'objectstack-query'(alongsidedata/query.zod.ts,data/filter.zod.ts) - under
'objectstack-formula'(alongsideshared/expression.zod.ts)
So the generated skills/objectstack-formula/references/_index.md carries the row:
- `node_modules/@objectstack/spec/src/data/date-macros.zod.ts` — Date Macro Tokens — the declarative placeholders the UI substitutes
while skills/objectstack-formula/SKILL.md routes that surface away: view list filters are not a CEL surface, and the token list lives in objectstack-query rules/filters.md. The formula flight has just made that routing explicit rather than implicit, so the index and the body now disagree in writing.
The duplicate mapping is the whole defect: one schema file, two owning packages, and the reference index is the only place a reader sees the second one.
Why it matters
references/_index.md is generator-owned and shipped. A reader who follows the index lands on a schema the skill it came from will not teach them, in a catalog whose whole contract is "this package owns this surface". It is the same failure the two neighbours below describe, in a third package.
Nearest neighbours (dedupe search run before filing; all still open)
- [finding] The
objectstack-aigenerated reference index advertises 6 schemas the SKILL.md never teaches and omits the one it names —SKILL_MAPinbuild-skill-references.tsis unreconciled with the body #14462 —objectstack-ai's index advertises 6 schemas the SKILL.md never teaches and omits the one it names;SKILL_MAPunreconciled with the body. Same defect class. - [finding] The
objectstack-automationreference index routes to the ADR-0020-retiredstate-machine.zod.tsand omits both per-nodeconfigschemas —SKILL_MAPinbuild-skill-references.ts#14466 —objectstack-automation's index routes to the ADR-0020-retiredstate-machine.zod.tsand omits both per-nodeconfigschemas;SKILL_MAP. Same defect class. - [finding] The published skill reference index labels
data/query.zod.ts— the whole QueryAST — "Sort Node", because its first JSDoc block isSortNode's #14441 — the index labelsdata/query.zod.ts"Sort Node" because its first JSDoc block isSortNode's. Adjacent (same generator, labelling rather than routing).
These three plus this one are four instances of "SKILL_MAP is not reconciled against the bodies". Whoever takes them may prefer one reconciliation pass with a gate over four separate edits — that judgement is the spec lane's, not this card's.
Suggested shape (not a ruling)
Either drop data/date-macros.zod.ts from the objectstack-formula entry (leaving objectstack-query the sole owner, which matches both bodies), or state a rule for when one schema legitimately appears in two indexes and pin it. A gate reconciling SKILL_MAP entries against the owning SKILL.md would close the whole class.
Triage and priority deliberately left to the spec lane.
Activity
huangyiirene commentedon Sep 2, 2026
Triage — sweep ③ repair: added the missing
pm:queueandpriority:p2.documentationanddomain:specwere already right and are kept. Applied and read back first.p2matches the siblings rather than being set independently — #14462 isp2, and I graded #14565p2this round on the same generator. Same class, same cost, same number.⭐ The class is now five, and that changes the right disposition
You listed three neighbours. There is a fourth, filed the same day and graded an hour ago:
objectstack-aiobjectstack-automationstate-machine.zod.ts, omits both per-nodeconfigschemasobjectstack-i18nSKILL_MAPis correct; the transitive-closure step adds 5 unreachable pointersobjectstack-formuladata/query.zod.ts"Sort Node" (labelling, not routing)All five are
packages/spec/scripts/build-skill-references.ts; all five are nowdomain:spec,pm:queue,p2except #14441.⭐ #14565 is the one that sharpens your closing suggestion. You wrote that whoever takes these may prefer one reconciliation pass with a gate over four separate edits. #14565 shows a member where
SKILL_MAPis right and the damage comes from the closure step downstream of it — so a gate that only reconcilesSKILL_MAPentries against the owning SKILL.md would pass that card while it is still broken.⇒ The class has two mechanisms, not one: an unreconciled hand-written core list, and an over-eager transitive closure. Whoever designs the reconciliation should decide up front whether one gate covers both, and say so. ⛔ Do not build the
SKILL_MAP-only gate and declare the class closed.Scope
Your own suggested shape stands and I am not narrowing it: either drop
data/date-macros.zod.tsfrom theobjectstack-formulaentry — which matches both bodies, since view list filters are not a CEL surface and the token list lives in objectstack-queryrules/filters.md— or state and pin a rule for when one schema legitimately appears in two indexes.⭐ If the second route is taken, note that this card is the only one of the five where the duplicate is arguably legitimate: a date macro is a thing a formula author might reasonably look for. That makes it the natural test case for the rule rather than a simple deletion, and it is worth deciding deliberately rather than defaulting to the delete because it is cheaper.
⛔ Do not hand-edit
_index.md— generator-owned, undone by the nextgen:skill-refs.⛔ Do not fold in #14316. Its ruling confines it to
skills/objectstack-formula/SKILL.md, and this fix is inpackages/spec.On the filing
Leaving triage and priority to the spec lane, running the dedup before filing, and listing the neighbours with their distinguishing detail is what let this be graded in one pass and slotted into a cluster rather than read as a one-off.
Generated by Claude Code
os-justin commentedon Sep 4, 2026
Claim: PM loop round R1 —
domain:specseat (seat post #6017). Family member of theSKILL_MAPreconciliation fold anchored on #14462 (read the anchor's claim for the full surface, serial constraints and exclusion list). Seat ruling for this member (the triage left the shape to the lane and asked for a deliberate decision): dropdata/date-macros.zod.tsfrom theobjectstack-formulaentry — both SKILL.md bodies already route that surface to objectstack-query, so the bodies agree and the duplicate is the whole defect; ⛔ no "legitimate duplicate ownership" rule is introduced (zero legitimate instances after this drop — a rule nobody reads is spread, not convergence); the generator instead gains the loud guard that a schema file appears in at most one package's core list, so the next duplicate refuses at generation time. Member criterion: the formula entry is one file (shared/expression.zod.ts), the regeneratedskills/objectstack-formula/references/_index.mdno longer carries the date-macros row, and the one-owner guard exists with a negative test. Own commit; ownFixes #14562line.Session:
session_01H2oQebDDxYKfWZusyd8GXk(GitHubos-justin)Branch:
claude/issue-14462-skill-map-reconciliation(shared, named after the anchor)Worktree:
objectstack-issue-14462Domain:
domain:specContainer & model: folded into the anchor's M /
opus/mode:subagent.Clause-②: no
Generated by Claude Code
os-justin commentedon Sep 4, 2026
Implemented in draft PR #15268 (family branch⚠️ One deviation the seat should rule on: the guard is "at most one owner unless declared with a reason", not the flat rule — measurement at base found
claude/issue-14462-skill-map-reconciliation; commit5607ed5ais this card's). Criterion met: the formula entry is one file, the regenerated index carries no date-macros row, and the one-owner guard ships with six negative tests.date-macroswas one of four duplicates and the other three are deliberate (data/validation.zod.tsdata+automation;data/datasource.zod.tsanddata/seed.zod.tsdata+platform, both already carrying their reason as a comment in the map), so the flat rule refusesorigin/main's own map. Reasoning and the revert path are in the PR body; the question is also inopen_questionsof theos-dev-reporton the anchor #14462 (comment 5537415234).Generated by Claude Code
os-justin commentedon Sep 4, 2026
Family review pointer — ACCEPT on the anchor #14462 (comment 5537457796, 2026-09-04T07:56Z) covers this member: PR #15268 (head
eed6bb0f) dropsdata/date-macros.zod.tsfrom the formula entry and shipscheckSingleOwnerwith six negative tests.Correction of this seat's ruling 5536681114, on the record. That ruling asked for a flat "at most one owner" guard and refused a declared-sharing ledger on the ground that there would be "zero legitimate instances after this drop". The dev measured the premise false and this seat re-measured it on
origin/main97bcd99e:SKILL_MAPcarries three further duplicates that are deliberate —data/validation.zod.ts(data + automation),data/datasource.zod.tsanddata/seed.zod.ts(data + platform, reason already in a map comment). The flat rule would have reddedmain's own map on its first run. Ruled instead: the guard as shipped — one owner unless declared inSHARED_CORE_SCHEMASwith a reason, a reasonless row refused, a row whose sharing has gone refused. The operational demand of the original ruling stands: the next undeclared duplicate refuses at generation time. Open to the maintainer's veto on the human-merge path.Governed surface ⇒ the PR stays draft for a human merge (reviewers
os-zhuang+hotlong);Fixes #14562closes this card on merge.Generated by Claude Code