fix(gate): downgrade readiness gate mode block to advisory

[JSONbored]

What

gate.readiness.mode in .gittensory.yml (and the equivalent dashboard/API qualityGateMode field) is documented and parsed as the shared off | advisory | block tri-state used by every other gate dimension. In practice it can never block anything.

Fix

buildQualityGateWarning (src/rules/advisory.ts) always produces a warning-severity finding, and isConfiguredGateBlocker has no branch for the readiness/quality dimension at all — this is a deliberate, pre-existing design (readiness is intentionally informational-only). But the config parser silently accepted mode: block anyway, so a maintainer who set it believed a real quality floor was enforced, when the effective behavior was silently advisory-only.

Added normalizeReadinessGateMode in src/signals/focus-manifest.ts, wired into parseGateConfig for the gate.readiness.mode field only. It downgrades block → advisory at parse time and pushes a clear deprecation warning pointing at gate.mergeReadiness or gate.manifestPolicy for an enforceable quality floor. The shared normalizeOptionalGateMode helper itself is untouched, since it's reused by other gate fields (linkedIssue, duplicates, aiReview, etc.) that legitimately support block.

Updated .gittensory.yml.example's readiness.mode doc comment to state only off | advisory are accepted, with a note on the downgrade-with-warning behavior.

Deliberately out of scope: src/api/routes.ts (repositorySettingsSchema/maintainerSettingsSchema) and src/openapi/schemas.ts (RepositorySettingsSchema/RepoSettingsPreviewSchema) still accept "block" for qualityGateMode in their Zod enums. These are read/response schemas as well as write-validation — narrowing them risks breaking API responses for any repo that already has quality_gate_mode = 'block' stored in the DB (deserialization would fail). Since the runtime already treats "block" as fully inert regardless of what's stored, leaving those schemas as-is is a safe, intentional deferral rather than an oversight.

Tests

• New test: parseFocusManifest downgrades gate.readiness.mode: block → advisory with a deprecation warning matching /gate\.readiness\.mode.*no longer accepts "block"/; an invalid mode still produces the normal "must be one of" warning and not the block-specific one.
• Updated two existing focus-manifest.test.ts tests that previously used mode: "block" as incidental input for unrelated assertions — switched to "advisory" to preserve their original intent.
• Updated gate-check-policy.test.ts's "overlays the friendly gate alias over DB settings" test: kept readiness: { mode: "block", minScore: 70 } as input (now a deliberate higher-level check) and asserted eff.qualityGateMode resolves to "advisory", confirming the downgrade propagates through resolveEffectiveSettings.
• npx tsc --noEmit clean.
• Scoped: focus-manifest.test.ts + gate-check-policy.test.ts — 222 passed.
• Regression sweep: all 14 files importing src/signals/focus-manifest.ts — 278 passed.
• Diff-range coverage-gap check on src/signals/focus-manifest.ts: fully covered.
• Full unsharded npm run test:coverage: 5601 passed, 4 skipped (pre-existing/unrelated), 0 failed.
• npm audit --audit-level=moderate: 0 vulnerabilities.

Advances #1936. Closes #2267.

[loopover-orb]

Tip

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

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-01 19:17:40 UTC}

4 files · 1 AI reviewer · no blockers · readiness 75/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
The change correctly downgrades the typed `gate.readiness.mode` alias from `block` to `advisory` and preserves the invalid-value warning path. The tests cover the alias-level downgrade and its overlay through `resolveEffectiveSettings`. The notable remaining problem is that the equivalent `qualityGateMode` setting path is still left able to carry the same inert hard-block value, so the fix only closes one configuration entry point.

Blockers

• src/signals/focus-manifest.ts:436 only normalizes `gate.readiness.mode`, so `qualityGateMode: "block"` supplied through the generic settings/dashboard/API path still survives as an inert hard-block setting and preserves the false-enforcement state this PR is meant to remove.

Nits — 4 non-blocking

• src/signals/focus-manifest.ts:360 has a long cross-module behavior comment that would be easier to maintain if it were shortened to the local invariant and left the detailed behavior proof in tests or nearby gate documentation.
• Add the same `block` to `advisory` normalization at the `qualityGateMode` settings normalization or effective-settings boundary, while keeping response schemas backward-compatible with existing stored values.
• Add a regression test for `settings.qualityGateMode: "block"` or an existing stored `qualityGateMode: "block"` resolving to `advisory`, matching the new `gate.readiness.mode` behavior.
• PR author also opened the linked issue — Link an issue that was opened by a different contributor, or provide a rationale for why this self-authored issue represents genuine discovery work.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#2267
Related work	⚠️ 3 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope	❌ 8/20	High review scope from cached public metadata (size label size:S; 1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 67 registered-repo PR(s), 57 merged, 589 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 67 PR(s), 589 issue(s).
Gate result	✅ Passing	No configured blocker found.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 67 PR(s), 589 issue(s).
• Related work: Items reference the same linked issue fix(review): gate.readiness.mode "block" is accepted and documented but the quality gate can never hard-block #2267. (issue #2267)
• Related work: Open PR work references issue fix(review): gate.readiness.mode "block" is accepted and documented but the quality gate can never hard-block #2267. (issue #2267)
• Related work: Items reference the same linked issue fix(queue): draft-dodge close bypasses the standard actuation pipeline guards #2134. (issue #2134, PR #2391)
• Additional title-only matches omitted; title-only overlap does not block.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Review top overlaps.
• Add a concise scope and risk note.
• Triage stale or unlinked PRs.
• No action.
• Check active issues and PRs before submitting.

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.

_{🟩 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 Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.84%. Comparing base (6cef302) to head (2193bde).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2384   +/-   ##
=======================================
  Coverage   95.84%   95.84%           
=======================================
  Files         224      224           
  Lines       25042    25048    +6     
  Branches     9103     9106    +3     
=======================================
+ Hits        24001    24007    +6     
  Misses        427      427           
  Partials      614      614           

Files with missing lines	Coverage Δ
src/api/routes.ts	94.66% <100.00%> (+<0.01%)	⬆️
src/signals/focus-manifest.ts	99.18% <100.00%> (+<0.01%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.