Context
packages/loopover-engine/src/review/content-lane/content-repo-spec.ts defines two field-name lists that are supposed to describe the same underlying concept — the set of manifest-entry keys that hold a source/provenance URL — but they've diverged:
urlFields (line 70-88), a Set, includes both camelCase AND snake_case aliases for every field: documentationUrl/docs_url, downloadUrl/download_url, githubUrl/github_url, packageUrl/package_url, repoUrl/repo_url, repositoryUrl/repository_url, sourceUrl/source_url, websiteUrl/website_url.sourceUrlFields (line 99-108), a readonly string[], includes ONLY the camelCase names — none of the eight snake_case aliases are present.
These two lists are consumed by different gates over the same manifest data:
duplicates.ts:270,554 reads spec.urlFields (the complete set, including snake_case).source-evidence.ts:229 reads spec.sourceUrlFields (the camelCase-only list).
Concretely: a manifest entry that legitimately uses source_url: (snake_case — a real, explicitly-listed alias in urlFields, and per the repo's own contribution conventions, source_url is in fact the canonical field name contributors are told to use — see the metagraphed sibling repo's contribution rules for the shared source_url convention this schema mirrors) is fully visible to duplicates.ts's duplicate-detection logic, but INVISIBLE to source-evidence.ts's source-evidence gate, which never even looks at that key. A legitimate source_url: entry can silently fail the source-evidence check not because the URL is actually missing or bad, but because the gate never reads the field it's stored under — a wrong-but-plausible "no source evidence" verdict for content that has valid evidence.
Requirements
sourceUrlFields must include the same snake_case aliases urlFields already has for the equivalent camelCase keys — specifically docs_url, download_url, github_url, package_url, repo_url, repository_url, source_url, website_url, matching urlFields's existing pairing exactly.- After the fix, every camelCase key in
sourceUrlFields must have its snake_case counterpart also present, and this pairing must match urlFields's pairing one-for-one (both lists describing the identical semantic field set, just different structural roles — ordered array vs. Set).
- Do not change what
duplicates.ts or source-evidence.ts themselves do with these lists — this is a data-fix to the spec constant only, not a behavior change to either consumer's logic.
Deliverables
Test Coverage Requirements
This repo's Codecov patch gate is 99%+ hard (branch-counted) on every changed line/branch in src/**/packages/**. The regression test must reproduce the exact snake_case-field-invisible-to-source-evidence gap described and assert it's fixed.
Expected Outcome
A manifest entry using the snake_case source_url (or any of its seven sibling snake_case field names) is now recognized consistently by both duplicates.ts and source-evidence.ts — no more silent false "missing source evidence" verdict for content stored under a snake_case key.
Links & Resources
packages/loopover-engine/src/review/content-lane/content-repo-spec.ts:70-88 (urlFields, the complete pairing), :99-108 (sourceUrlFields, the incomplete list). packages/loopover-engine/src/review/content-lane/source-evidence.ts:229 (the consumer that's blind to the missing aliases). packages/loopover-engine/src/review/content-lane/duplicates.ts:270,554 (the consumer that already sees the full set, for contrast).
Context
packages/loopover-engine/src/review/content-lane/content-repo-spec.tsdefines two field-name lists that are supposed to describe the same underlying concept — the set of manifest-entry keys that hold a source/provenance URL — but they've diverged:urlFields(line 70-88), aSet, includes both camelCase AND snake_case aliases for every field:documentationUrl/docs_url,downloadUrl/download_url,githubUrl/github_url,packageUrl/package_url,repoUrl/repo_url,repositoryUrl/repository_url,sourceUrl/source_url,websiteUrl/website_url.sourceUrlFields(line 99-108), areadonly string[], includes ONLY the camelCase names — none of the eight snake_case aliases are present.These two lists are consumed by different gates over the same manifest data:
duplicates.ts:270,554readsspec.urlFields(the complete set, including snake_case).source-evidence.ts:229readsspec.sourceUrlFields(the camelCase-only list).Concretely: a manifest entry that legitimately uses
source_url:(snake_case — a real, explicitly-listed alias inurlFields, and per the repo's own contribution conventions,source_urlis in fact the canonical field name contributors are told to use — see themetagraphedsibling repo's contribution rules for the sharedsource_urlconvention this schema mirrors) is fully visible toduplicates.ts's duplicate-detection logic, but INVISIBLE tosource-evidence.ts's source-evidence gate, which never even looks at that key. A legitimatesource_url:entry can silently fail the source-evidence check not because the URL is actually missing or bad, but because the gate never reads the field it's stored under — a wrong-but-plausible "no source evidence" verdict for content that has valid evidence.Requirements
sourceUrlFieldsmust include the same snake_case aliasesurlFieldsalready has for the equivalent camelCase keys — specificallydocs_url,download_url,github_url,package_url,repo_url,repository_url,source_url,website_url, matchingurlFields's existing pairing exactly.sourceUrlFieldsmust have its snake_case counterpart also present, and this pairing must matchurlFields's pairing one-for-one (both lists describing the identical semantic field set, just different structural roles — ordered array vs. Set).duplicates.tsorsource-evidence.tsthemselves do with these lists — this is a data-fix to the spec constant only, not a behavior change to either consumer's logic.Deliverables
sourceUrlFieldsinpackages/loopover-engine/src/review/content-lane/content-repo-spec.tsextended with the eight snake_case aliases already present inurlFieldssource_url:(snake_case) is recognized bysource-evidence.ts's gate the same way an equivalentsourceUrl:(camelCase) entry already is — i.e. the source-evidence check passes for a snake_case-keyed entry with a valid URL, matching howduplicates.tsalready treats itTest Coverage Requirements
This repo's Codecov patch gate is 99%+ hard (branch-counted) on every changed line/branch in
src/**/packages/**. The regression test must reproduce the exact snake_case-field-invisible-to-source-evidence gap described and assert it's fixed.Expected Outcome
A manifest entry using the snake_case
source_url(or any of its seven sibling snake_case field names) is now recognized consistently by bothduplicates.tsandsource-evidence.ts— no more silent false "missing source evidence" verdict for content stored under a snake_case key.Links & Resources
packages/loopover-engine/src/review/content-lane/content-repo-spec.ts:70-88(urlFields, the complete pairing),:99-108(sourceUrlFields, the incomplete list).packages/loopover-engine/src/review/content-lane/source-evidence.ts:229(the consumer that's blind to the missing aliases).packages/loopover-engine/src/review/content-lane/duplicates.ts:270,554(the consumer that already sees the full set, for contrast).