You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Immediate VPS fix (config-only, zero code risk): gate.checkMode: disabled on all 4 private config layers (global + 3 repos) on the dedicated server.
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).
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.
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
Prior incident (same field, different symptom): feedback-gate-enabled-false-does-not-stop-ai-spend (project memory)
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 explicitgate.checkMode, so it falls back toreviewCheckMode: "required"(applyGateConfigOverrides,src/signals/focus-manifest.ts:465-466).This is the second incident this exact field has caused (the first:
gate.enabled: falsewas believed to be a full AI-spend kill switch — it wasn't, seefeedback-gate-enabled-false-does-not-stop-ai-spendhistory). 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
gate.checkMode: disabledon all 4 private config layers (global + 3 repos) on the dedicated server.gate.enabledis set without an explicitgate.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 inpackages/gittensory-engine/src/focus-manifest.ts).manifestWarningsdeliberately excludes private-config warnings by design —src/queue/processors.ts:9656-9660,loadPublicRepoFocusManifestnever consults the private VPS config reader). Correct delivery path:src/signals/registration-readiness.ts'sbuildRegistrationReadiness/buildGithubAppBehavior, which already uses the private-config-awareloadRepoFocusManifestand is the real maintainer-facing readiness surface (GET /v1/repos/:owner/:repo/registration-readiness).enabledfield inFocusManifestGateConfighas no doc comment (unlike its siblingcheckMode);docs.tuning.tsxcallsgate.enabled/reviewCheckMode"the master switch" (misleading, it's check-run-publication-only);docs.self-hosting-configuration.tsx's example doesn't pairenabled+checkModelike the other 3 templates already do.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
gate.checkMode: disabledapplied to global + 3 repo configs, backed up first.packages/gittensory-engine/src/focus-manifest.ts: new warning inparseGateConfig().src/signals/registration-readiness.ts: surface manifest parse warnings in the readiness report.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.enabledwithoutgate.checkModegets a real, actually-visible warning on the maintainer dashboard instead of a silent, surprising side effect discovered only after the fact.Links & Resources
feedback-gate-enabled-false-does-not-stop-ai-spend(project memory)packages/gittensory-engine/src/focus-manifest.tsgate.firstTimeContributorGracehandling (~line 1361-1367)