fix(content-lane): add snake_case aliases to protectedFrontmatterFields

[tryeverything24]

Closes #7445

Summary

protectedFrontmatterFields (packages/loopover-engine/src/review/content-lane/content-repo-spec.ts)
listed every protected field in camelCase only, so an entry that wrote a protected field in the
legitimately-accepted snake_case convention (e.g. download_url: instead of downloadUrl:) was
invisible to protectedFrontmatterChanges (src/review/content-lane/duplicates.ts:154) — the gate
compares before["downloadUrl"]/after["downloadUrl"] by literal parsed key, both undefined, sees
no change, and the protected-close never fires even though the underlying value actually changed. A
real bypass of the identity/provenance/monetization protected-edit gate, based purely on which naming
convention a submission happens to use.

This is the same divergence class as #7250 (urlFields vs sourceUrlFields), already fixed in this
exact file via #7269. This PR mirrors that fix's shape exactly: adds the 19 snake_case aliases for
every multi-word camelCase member of protectedFrontmatterFields (author, category, disclosure,
slug are single all-lowercase words — byte-identical in both conventions, so no separate alias is
needed). Pure data addition to the Set; protectedFrontmatterChanges's comparison logic and every
other field list in content-repo-spec.ts are untouched.

Scope

• Conventional Commit title; focused (one spec constant + its tests); no site//CNAME/lovable; no new dependency.
• Linked a currently open issue (Closes #7445).

Validation

• git diff --check — clean
• npm run typecheck (root) — clean
• npm run engine-parity:drift-check — ok
• npm run build --workspace @loopover/engine — clean
• Targeted coverage (vitest run --coverage, scoped to the two changed files): 100%
  statements/branches/functions/lines (193/193, 211/211, 42/42, 175/175)
• Full test/unit/content-lane-*.test.ts suite (11 files, 549 tests) — all pass
• Two new regression tests in test/unit/content-lane-duplicates.test.ts: (1) an end-to-end
  before/after download_url: frontmatter change through parseSimpleFrontmatter is now
  reported by protectedFrontmatterChanges, matching what the equivalent camelCase-keyed edit
  already produced; (2) a pairing assertion that every multi-word camelCase member of
  protectedFrontmatterFields has its snake_case counterpart also present in the set, mirroring
  content-repo-spec's sourceUrlFields omits the snake_case aliases its sibling urlFields already has #7250's sourceUrlFields/urlFields pairing-assertion test.

If any required check was skipped, explain why:

• Change confined to packages/loopover-engine/src/review/content-lane/content-repo-spec.ts (one
  constant) + its test file; src/review/content-lane/content-repo-spec.ts is the export *
  re-export shim documented in its own header comment and picks up the change automatically — not
  duplicated there, per the issue's explicit requirement.

Safety

• No secrets, wallets, hotkeys, coldkeys, PATs, trust scores, or private data exposed.
• Public GitHub text stays sanitized and low-noise.
• No auth/CORS/session/API/OpenAPI/MCP surface change — a spec-constant data fix; it only makes
  the protected-close gate recognize the same fields duplicate-detection (urlFields) already did.
• No UI change — no UI Evidence needed.

[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 91.36%. Comparing base (14db2b8) to head (2e57ab7).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7478      +/-   ##
==========================================
- Coverage   91.36%   91.36%   -0.01%     
==========================================
  Files         717      717              
  Lines       73022    73022              
  Branches    21632    21632              
==========================================
- Hits        66719    66715       -4     
  Misses       5265     5265              
- Partials     1038     1042       +4     

Flag	Coverage Δ
shard-1	34.16% <ø> (ø)
shard-2	39.27% <ø> (-0.05%)	⬇️
shard-3	32.61% <ø> (+0.01%)	⬆️
shard-4	39.53% <ø> (-0.01%)	⬇️
shard-5	36.58% <ø> (ø)
shard-6	34.32% <ø> (ø)

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

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

... and 1 file with indirect coverage changes

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-20 12:10:28 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This is a pure data addition mirroring the exact pattern already established by #7269 for urlFields/sourceUrlFields: it adds 19 snake_case aliases to protectedFrontmatterFields so protectedFrontmatterChanges (duplicates.ts:154) catches protected-field edits regardless of naming convention, since the comparison is a literal keyed lookup. The single-lowercase-word fields (author, category, disclosure, slug) are correctly excluded since they're byte-identical in both conventions. Tests include both a direct regression test for download_url and a completeness assertion that programmatically verifies every multi-word camelCase member has its snake_case pair, which is a solid safeguard against future drift.

Nits — 4 non-blocking

• The completeness test's toSnakeCase regex-based conversion in test/unit/content-lane-duplicates.test.ts duplicates logic that could silently diverge from the actual field list if a future field has unusual casing (e.g. an acronym); worth a comment noting this is intentionally simple.
• The large inline comment block in content-repo-spec.ts (5 lines) is somewhat verbose for a Set literal; could be trimmed to reference fix(content-lane): protectedFrontmatterFields omits snake_case aliases, letting a protected-field edit bypass the close gate #7445 without restating the full mechanism, since the same explanation already exists in the analogous urlFields comment.
• Consider extracting the snake_case pairing invariant (multi-word camelCase -> alias exists) into a small shared assertion helper if this pattern is repeated a third time for another field list, per DRY.
• No functional changes needed; the diff is narrow, tested, and matches the established convention exactly.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#7445
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low 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: 57 registered-repo PR(s), 22 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	tryeverything24; Gittensor profile; 57 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff adds all 19 required snake_case aliases to protectedFrontmatterFields in the correct file, leaves protectedFrontmatterChanges and other lists untouched, and includes both required regression tests (an end-to-end snake_case protected-change detection test and a pairing-assertion test mirroring #7250's fix).

Review context

• Author: tryeverything24
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: JavaScript, TypeScript, Python, HTML, C++, Java, PHP, C#
• Official Gittensor activity: 57 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Triage stale or unlinked PRs.

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://loopover.ai/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

[loopover-orb]

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