fix(identity): which-was-first canonical for confirmed dupes + createdAt in starmap - #22
Conversation
…t score a byte-identical copy can outscore the original it was lifted from; naming the copy canonical rewards the theft. identity clusters now resolve by the earliest-created rule (mode issue, 24h near-tie window) in both the cluster bestPick and the starmap canonical. fuzzy clusters keep the state/CI/score rule.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6fb5a21c19
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ...ref(it), | ||
| title: sanitizeTitle(it.title), | ||
| author: it.author, | ||
| createdAt: it.createdAt, |
There was a problem hiding this comment.
The existing star-map importer rejects unknown fields (as this commit's CHANGELOG notes), so every newly generated --starmap payload will fail to load in that consumer while still advertising schema version 1. Ship the importer change in lockstep, defer this field, or version the contract before emitting it.
Useful? React with 👍 / 👎.
1 participant
two changes promised to the star-map side, landing together before the next dataset rerun.
starmap items now carry
createdAtalongsideupdatedAt. the value has been in the db all along; every output renderedupdatedAtonly, so consumers had no which-was-first signal without re-fetching from github. additive field, schema stays v1. star-map's importer rejects unknown fields by design, so datasets carrying this wait for the coordinated importer patch on that side.confirmed (identity) duplicate clusters now pick canonical by earliest-created instead of quality score. byte-identical duplicates are a which-was-first question: a copied PR can outscore the original it was lifted from, and naming the copy canonical rewards the theft. the earliest-created rule (24h near-tie window) now applies in both the cluster bestPick and the starmap canonical, so the two selectors cannot disagree. fuzzy clusters keep the state/CI-veto/score rule, pinned by a guard test.
validation: 435 tests green (was 432), adversarially verified in a throwaway worktree. reverting either half independently fails exactly its pinned tests while the fuzzy guard stays green.