fix(review): preserve invariant guardrails#3943
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
gittensory-ui | 8ebb6e4 | Commit Preview URL Branch Preview URL |
Jul 07 2026, 12:15 PM |
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
|
Warning 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ⏸️ Gittensory review result - manual review recommendedReview updated: 2026-07-07 12:22:46 UTC
⏸️ Suggested Action - Manual Review
Concerns raised — review before merging
Review context
Contributor next steps
Signal definitions
🟩 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.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3943 +/- ##
==========================================
- Coverage 93.58% 93.57% -0.01%
==========================================
Files 381 381
Lines 35483 35493 +10
Branches 13014 13014
==========================================
+ Hits 33206 33214 +8
Misses 1617 1617
- Partials 660 662 +2
🚀 New features to boost your workflow:
|
869ae1a to
c5c5ece
Compare
c5c5ece to
800aea3
Compare
…c/queue/** The unlinked-issue guardrail tests used src/queue/webhook-retry.ts as a generic example diff, which collides with ENGINE_DECISION_GUARDRAIL_GLOBS' src/queue/** built-in invariant (guardrail-config.ts) -- every scenario in this block now unconditionally holds regardless of the guardrail's own on/off setting. Switches to src/github/webhook.ts, which isn't covered by any built-in guardrail glob.
800aea3 to
8ebb6e4
Compare
…ims (#5240) Two config example files (.gittensory.yml.example, config/examples/gittensory.full.yml) still described legacy blockedPaths as enforceable ("yields a manifest_blocked_path finding... enforceable when gate.manifestPolicy: block") -- that mechanism was retired in #2974 in favor of settings.hardGuardrailGlobs as the single authoritative path-hold control, and manifest_blocked_path is no longer even a valid finding code. An operator copying either example would believe they had protection they don't have. Also fixes a second, related staleness: both example files and two docs pages (docs.self-hosting-configuration.tsx, docs.tuning.tsx) claimed an omitted/empty settings.hardGuardrailGlobs means "no path guardrails, never a hidden engine fallback" -- but #3943 (three days after the comment was written) added DEFAULT_HARD_GUARDRAIL_GLOBS, a fixed set of built-in invariant guardrails (config-as-code files, CI workflows/scripts, core engine-decision paths) that always apply regardless of repo settings. The docs never caught up.
…5708) hardGuardrailGlobs could previously only ADD to DEFAULT_HARD_GUARDRAIL_GLOBS (#3943), so no repo could narrow guardrail-triggered manual-review holds below the built-in invariant set. Add an explicit, opt-in hardGuardrailGlobsOverridesInvariants setting: when true, hardGuardrailGlobs fully replaces the built-in floor instead of adding to it (including an explicit [] to disable path guardrails entirely); default false preserves today's safe-by-default, add-only behavior for everyone who doesn't set it.
Motivation
.gittensory.ymlfrom removing built-in hard guardrails for config-as-code, workflows/runtime, and engine decision paths, which could otherwise allow contributor PRs to bypass manual-review holds.Description
CONFIG_AS_CODE_GUARDRAIL_GLOBS,WORKFLOW_AND_RUNTIME_GUARDRAIL_GLOBS,ENGINE_DECISION_GUARDRAIL_GLOBS) and consolidate them intoDEFAULT_HARD_GUARDRAIL_GLOBSinsrc/review/guardrail-config.ts.resolveHardGuardrailGlobsto return the union ofDEFAULT_HARD_GUARDRAIL_GLOBSand any repo-configuredsettings.hardGuardrailGlobs, deduplicating entries so repo settings can only add globs.packages/gittensory-engine/src/review/guardrail-config.tsso predicted-gate and miner flows use the same invariant behavior.hardGuardrailGlobsis omitted,null, empty, or provided (tests updated intest/unit/guardrail-config.test.tsandtest/unit/predicted-gate.test.ts).Testing
git diff --checkwhich passed.npx vitest run test/unit/guardrail-config.test.ts test/unit/predicted-gate.test.ts --reporter=dot, and those tests passed.npm run typecheckandnpm run build:miner, both of which completed successfully.npm run test:coverage, but the full suite hung in existingtest/unit/queue.test.tswith repeated stack-overflow output and was terminated; a scoped coverage run also failed during Vitest coverage remapping withTypeError: jsTokens is not a function(tooling/remapping issue unrelated to the guardrail logic changes).Codex Task