Skip to content

Fix gate.enabled/gate.checkMode ambiguity at the code level (root cause of the Orb Review Agent check-run incident) #5355

Description

@JSONbored

Context

Follow-up to the closed drift-audit roadmap (#5270). That audit found and fixed 22 config-drift issues, but missed the actual original incident: the "Gittensory Orb Review Agent" check-run was republishing as a required-looking CI check on all 3 self-hosted repos (gittensory, metagraphed, awesome-claude) because each repo's private VPS config has gate.enabled: true (restored 2026-07-09 for an unrelated token-spend/gate-restoration reason) with no explicit gate.checkMode, so it falls back to reviewCheckMode: "required" (applyGateConfigOverrides, src/signals/focus-manifest.ts:465-466).

This is the second incident this exact field has caused (the first: gate.enabled: false was believed to be a full AI-spend kill switch — it wasn't, see feedback-gate-enabled-false-does-not-stop-ai-spend history). The maintainer's explicit ask: fix this properly in the codebase, not just the config, so it cannot recur — including eliminating any duplicated/legacy code found along the way.

Requirements

  1. Immediate VPS fix (config-only, zero code risk): gate.checkMode: disabled on all 4 private config layers (global + 3 repos) on the dedicated server.
  2. Code-level permanent fix: a parse-time warning when gate.enabled is set without an explicit gate.checkMode, mirroring this codebase's own established precedent for exactly this class of problem (gate.firstTimeContributorGrace's fix(review): gate.firstTimeContributorGrace is documented as softening blockers but is dead/inert #2266 warning in packages/gittensory-engine/src/focus-manifest.ts).
  3. Warning must actually reach a human for the private-config case (verified: the public PR comment's manifestWarnings deliberately excludes private-config warnings by design — src/queue/processors.ts:9656-9660, loadPublicRepoFocusManifest never consults the private VPS config reader). Correct delivery path: src/signals/registration-readiness.ts's buildRegistrationReadiness/buildGithubAppBehavior, which already uses the private-config-aware loadRepoFocusManifest and is the real maintainer-facing readiness surface (GET /v1/repos/:owner/:repo/registration-readiness).
  4. Companion doc-comment fixes: enabled field in FocusManifestGateConfig has no doc comment (unlike its sibling checkMode); docs.tuning.tsx calls gate.enabled/reviewCheckMode "the master switch" (misleading, it's check-run-publication-only); docs.self-hosting-configuration.tsx's example doesn't pair enabled+checkMode like the other 3 templates already do.
  5. Add a clarifying comment on GITTENSORY_LEGACY_GATE_CHECK_NAME/finalizeLegacyPendingCheckRuns (src/github/app.ts) confirming it's a genuine upgrade-migration safety net for third-party self-hosters, not dead code — so a future cleanup pass doesn't delete it incorrectly.

Deliverables

  • VPS: gate.checkMode: disabled applied to global + 3 repo configs, backed up first.
  • packages/gittensory-engine/src/focus-manifest.ts: new warning in parseGateConfig().
  • src/signals/registration-readiness.ts: surface manifest parse warnings in the readiness report.
  • Doc-comment fixes (3 files above).
  • Legacy check-run-name comment.
  • Regression tests: warning emission (5 cases incl. the paired enabled+checkMode silent case), warning reaches the registration-readiness report.
  • Full local gate green before push.

Expected Outcome

The check-run is gone from all 3 repos immediately. Going forward, any operator (including future maintainers of a hosted/cloud version) who sets gate.enabled without gate.checkMode gets a real, actually-visible warning on the maintainer dashboard instead of a silent, surprising side effect discovered only after the fact.

Links & Resources

Metadata

Metadata

Assignees

Labels

maintainer-onlyOwner-only work — yields no Gittensor points.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions