fix(review): honor ContentRepoSpec.urlFields in directory-index synthesis

[jsdevninja]

Summary

• contentSignalSourceFromDirectoryEntry now takes a ContentRepoSpec and emits URL frontmatter from spec.urlFields instead of a hardcoded field list.
• directoryIndexToSignals passes its spec through so synthesis and extractContentDuplicateSignals agree on URL keys.
• Regression tests cover a custom non-default urlFields set (corpus urls must contain the custom field) and unchanged default AWESOME_CLAUDE_CONTENT_SPEC camelCase behavior.

Scope

• Conventional Commit title
• Focused bug fix for fix(review): contentSignalSourceFromDirectoryEntry ignores ContentRepoSpec, breaking URL duplicate-detection for custom specs #5941
• Linked open issue

Validation

• npx vitest run test/unit/content-lane-duplicates.test.ts — 83 passed
• Coverage on src/review/content-lane/duplicates.ts — 100% stmts/branches/funcs/lines for this file under that suite

Safety

• No secrets / wallets / scoring surfaces
• No changelog / site edits

UI Evidence

N/A — review content-lane backend fix; no UI change.

Closes #5941

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.16%. Comparing base (3db64d8) to head (3793b2c).
⚠️ Report is 17 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6018   +/-   ##
=======================================
  Coverage   95.16%   95.16%           
=======================================
  Files         591      591           
  Lines       46934    46934           
  Branches    15000    15001    +1     
=======================================
  Hits        44664    44664           
  Misses       1512     1512           
  Partials      758      758           

Flag	Coverage Δ
shard-1	43.92% <100.00%> (-0.01%)	⬇️
shard-2	36.55% <0.00%> (+0.02%)	⬆️
shard-3	31.93% <0.00%> (-0.07%)	⬇️
shard-4	31.90% <0.00%> (-0.05%)	⬇️
shard-5	32.24% <0.00%> (-0.30%)	⬇️
shard-6	44.92% <0.00%> (+0.34%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/review/content-lane/duplicates.ts	100.00% <100.00%> (ø)

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-15 07:18:31 UTC}

2 files · 1 AI reviewer · no blockers · readiness 80/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This fix replaces a hardcoded URL-field list in `contentSignalSourceFromDirectoryEntry` with `spec.urlFields`, so `directoryIndexToSignals` and `extractContentDuplicateSignals` now agree on which frontmatter keys carry URLs for custom `ContentRepoSpec` configs. The default spec's `urlFields` set is a superset of the old hardcoded camelCase list (it adds snake_case variants), and since the loop only emits a line when `entry[field]` is truthy, iterating the larger default set is behaviorally equivalent for existing entries — the default-behavior regression test confirms this. The change is small, correctly traced to its root cause (the synthesis function, not the extraction filter), and is well covered by new tests exercising both custom and default `urlFields`.

Nits — 3 non-blocking

• src/review/content-lane/duplicates.ts: iterating `spec.urlFields` (a Set, now including snake_case keys) instead of the original 9-item array means the emitted frontmatter order for the default spec differs slightly from before if entry data had both camelCase and snake_case keys present, though this has no observed behavioral impact per the added test.
• test/unit/content-lane-duplicates.test.ts: the new regression tests are thorough but slightly redundant with the existing per-repo `ContentRepoSpec` override test just above them in the file — consider consolidating if reviewers flag file bloat.
• Consider exporting `contentSignalSourceFromDirectoryEntry`'s new spec parameter with a JSDoc note that `spec.urlFields` must stay in sync with any snake_case aliasing logic used elsewhere, to prevent future drift.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#5941
Related work	⚠️ 2 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 198 registered-repo PR(s), 126 merged, 39 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jsdevninja; Gittensor profile; 198 PR(s), 39 issue(s).
Gate result	✅ Passing	No configured blocker found.
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Review context

• Author: jsdevninja
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 198 PR(s), 39 issue(s).
• Related work: Items reference the same linked issue fix(review): contentSignalSourceFromDirectoryEntry ignores ContentRepoSpec, breaking URL duplicate-detection for custom specs #5941. (issue #5941)
• Related work: Open PR work references issue fix(review): contentSignalSourceFromDirectoryEntry ignores ContentRepoSpec, breaking URL duplicate-detection for custom specs #5941. (issue #5941)

Contributor next steps

• Start here: Review top overlaps.
• Then work through the remaining 2 steps in the Signals table above.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://gittensory.aethereal.dev/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[JSONbored]

Please, do not use draft - it messes with the bot, wastes resources, and generally slows down the pipeline/creates potential merge conflicts due to risks with out of order reviews/merges.

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.