Context
moderationGateMode's doc comment (src/types.ts:1099-1103) reads: "whether the whole layer runs on THIS repo." Read in isolation this implies "off" disables the anti-abuse system. It does not — the four enforcement mechanisms (contributor-cap close, contributor-blacklist close, review-nag cooldown, review-evasion close) each read only their own independent setting and never check moderationGateMode. resolveModerationGateEnabled has exactly one call site (agent-action-executor.ts:610, inside applyModerationEscalationForRule), which its own doc confirms runs only after enforcement already completed — it gates only the shared cross-repo violation tally + warning/banned label + auto-blacklist-at-threshold.
Note: moderation-rules.ts's own file header and .gittensory.yml.example:828-834 already describe this scope correctly — the drift is localized to the src/types.ts JSDoc for this one field, which is more ambiguous than the accurate .yml.example wording for the identical setting. No dashboard/OpenAPI surface duplicates the misleading text.
Requirements
- No functional code change required — comment fix only.
Deliverables
Expected Outcome
The types.ts JSDoc no longer implies moderationGateMode: off disables the anti-abuse system; it matches the already-accurate .gittensory.yml.example wording.
Links & Resources
- Evidence:
src/types.ts:1099-1103; src/services/agent-action-executor.ts:592-610; src/queue/processors.ts:2666-2703,8428-8431,11920
- Optional, bigger, separate follow-up: rename to
moderationEscalationMode (DB column, openapi, yml) — not in scope here.
Part of #5270 (roadmap epic).
Context
moderationGateMode's doc comment (src/types.ts:1099-1103) reads: "whether the whole layer runs on THIS repo." Read in isolation this implies "off" disables the anti-abuse system. It does not — the four enforcement mechanisms (contributor-cap close, contributor-blacklist close, review-nag cooldown, review-evasion close) each read only their own independent setting and never checkmoderationGateMode.resolveModerationGateEnabledhas exactly one call site (agent-action-executor.ts:610, insideapplyModerationEscalationForRule), which its own doc confirms runs only after enforcement already completed — it gates only the shared cross-repo violation tally + warning/banned label + auto-blacklist-at-threshold.Note:
moderation-rules.ts's own file header and.gittensory.yml.example:828-834already describe this scope correctly — the drift is localized to thesrc/types.tsJSDoc for this one field, which is more ambiguous than the accurate.yml.examplewording for the identical setting. No dashboard/OpenAPI surface duplicates the misleading text.Requirements
Deliverables
src/types.ts:1099-1103to match the already-correct.gittensory.yml.examplewording: clarify it gates only the shared cross-repo violation TALLY, not the four underlying mechanisms, each of which has its own independent setting (contributorOpenPrCap,contributorBlacklist,reviewNagPolicy,reviewEvasionProtection).Expected Outcome
The
types.tsJSDoc no longer impliesmoderationGateMode: offdisables the anti-abuse system; it matches the already-accurate.gittensory.yml.examplewording.Links & Resources
src/types.ts:1099-1103;src/services/agent-action-executor.ts:592-610;src/queue/processors.ts:2666-2703,8428-8431,11920moderationEscalationMode(DB column, openapi, yml) — not in scope here.Part of #5270 (roadmap epic).