fix(queue): correct maybeApplyManifestPolicyGate's "three"->"two" enforceable-findings comments

[hurryup52]

Summary

maybeApplyManifestPolicyGate's JSDoc and inline comment both said it pushes "three enforceable
policy findings", but its actual policyCodes set — and resolveConfiguredGateMode in
src/rules/advisory.ts — only has two (manifest_linked_issue_required,
manifest_missing_tests). manifest_blocked_path was retired by 329af5a9 (#5304), which removed
the dead code string but missed updating these two doc comments. Both are updated to "two
enforceable policy findings" so the docs match the code. policyCodes and all logic are unchanged.

Validation

• grep "three enforceable" src/queue/processors.ts returns zero occurrences after the fix.
• Comment-only change — no executable logic modified, so no test changes are needed (no behavior
  changed; no placeholder/stub test added, per the issue's own instruction).
• .gittensory.yml.example / config/examples/gittensory.full.yml untouched (already fixed by
  fix(config): stop documenting the retired blockedPaths key as a live feature #5304).
• npm run typecheck clean.
• test/unit/selfhost-pg-retention.test.ts — 2 pre-existing failures reproduce identically on a
  clean sync of upstream/main with only this 2-line comment diff applied (Postgres retention
  pruning row-count assertions, e.g. expected +0 to be 4). Confirmed unrelated to this change —
  this file/logic is untouched by the diff. A prior PR for this same issue (fix(queue): correct maybeApplyManifestPolicyGate's "three"->"two" enforceable-findings comments #9337) was
  auto-closed for this exact same unrelated CI failure.

Closes #9295

[codecov]

❌ 2 Tests Failed:

Tests completed	Failed	Passed	Skipped
3949	2	3947	11

View the top 2 failed test(s) by shortest run time

test/unit/selfhost-pg-retention.test.ts > runRetentionPrune + processJob on the Postgres backend (#977) > processJob prune-retention deletes eligible rows and records a success audit event on Postgres

Stack Traces | 0.00639s run time

AssertionError: expected 3 to be +0 // Object.is equality

- Expected
+ Received

- 0
+ 3

 ❯ test/unit/selfhost-pg-retention.test.ts:119:44

test/unit/selfhost-pg-retention.test.ts > pruneExpiredRecords on the Postgres backend (#977) > deletes across multiple bounded batches and stops at the per-table cap, same as the SQLite path

Stack Traces | 0.0228s run time

AssertionError: expected +0 to be 4 // Object.is equality

- Expected
+ Received

- 4
+ 0

 ❯ test/unit/selfhost-pg-retention.test.ts:76:33

To view more test analytics, go to the Test Analytics Dashboard
_{📋 Got 3 mins? Take this short survey to help us improve Test Analytics.}

[loopover-orb]

Caution

🛑 LoopOver review result - fixes required

_{Review updated: 2026-07-27 15:06:48 UTC}

1 file · 1 AI reviewer · no blockers · CI failing · unstable

🛑 Suggested Action - Fix Blockers

Review summary
This is a pure comment-only fix correcting stale JSDoc/inline comment text ("three" → "two" enforceable policy findings) in maybeApplyManifestPolicyGate to match the actual policyCodes set, which only has two entries after manifest_blocked_path was retired in #329af5a9 (#5304). The diff is exactly what it claims: two 1-line comment edits, no logic touched. No test changes are needed since no behavior changed, consistent with the PR's own stated rationale.

Nits — 3 non-blocking

• The PR description notes two pre-existing unrelated failures in test/unit/selfhost-pg-retention.test.ts reproduce on a clean sync of main, and the CI FAILED checks (validate-tests, validate) have no detail provided — worth confirming these are the same known-unrelated Postgres retention failures rather than something new before merge, especially since fix(queue): correct maybeApplyManifestPolicyGate's "three"->"two" enforceable-findings comments #9337 was previously auto-closed for this exact issue.
• Given the base branch is 1 commit behind current main, rebasing may clear the undetailed validate-tests/validate failures if they were fixed upstream since divergence.
• Code changes lack test evidence — Add focused regression tests or explain why existing coverage is sufficient.

CI checks failing

• validate
• validate-tests

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	#9295
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: 22 registered-repo PR(s), 6 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	hurryup52; Gittensor profile; 22 PR(s), 0 issue(s).
Improvement	ℹ️ None detected	risk: low · value: none · LLM: minor

Linked issue satisfaction

Addressed
The diff updates both the JSDoc and inline comment occurrences of "three enforceable policy findings" to "two," matching the actual two-entry policyCodes set, exactly as requested with no logic changes.

Review context

• Author: hurryup52
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: JavaScript, TypeScript, Dart, MDX, Rust
• Official Gittensor activity: 22 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 is closing this pull request on the maintainer's behalf (CI is failing (validate, validate-tests)). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.