Source preview guide · 0.1.0
Read and configure a project's scan gate
Separate completed analysis from its policy decision, then adjust the intended project's thresholds without changing source access or push protection.
Read coverage before the gate decision
A scan reports what happened during analysis. Its gate reports whether the applicable evidence meets the project’s policy. Read both in the Findings summary.
| What you see | What it means for your next step |
|---|---|
| Complete analysis and a passing gate | The scan meets the active policy for its recorded scope and evidence. Check that this is the source and scope you intended. |
| Complete analysis and a failing gate | Analysis finished, but one or more policy conditions failed. Review the stated reasons and relevant findings. |
| Partial, failed or cancelled analysis | Useful findings may remain, but missing analysis cannot become complete passing evidence. Resolve the coverage problem and scan again. |
| A gate that is not configured or is disabled | No active project policy establishes a pass. This cannot authorize a protected push. |
An empty finding list is insufficient to establish any of these outcomes. Filters may hide reports, a scanner may have failed, or the selected scan may cover only one file. The summary and gate reasons preserve those distinctions.
Scan completion, gate outcome and installed push protection are separate states. Inspect the findings to understand a failed gate.
Open the full imageConfigure only the intended project
Open Projects, choose the project and find Repository scan gate. Check its name before editing. The form offers four controls:
- Evaluate this project’s gate enables or disables policy evaluation for this project.
- Maximum critical findings sets the allowed number of counted critical reports.
- Maximum high findings sets the allowed number of counted high reports.
- Block secrets in this project adds the secret-report condition.
A maximum of 0 permits no counted findings at that severity. A maximum of 2 permits two and fails when the count exceeds two. -1 leaves that severity unbounded. The form accepts threshold values through 999.
Choose values that reflect the project’s review policy, then select Save project gate. The save recalculates existing scan gates for that project. It does not change another project’s policy, scan your source, authorize a directory, prepare scanner data or install a Git hook.
The secret condition operates on reports recognized by the gate’s scanner, rule and message matching. It is not a claim that every possible secret has been detected. Inspect the underlying reports when a secret condition fails.
Keep drafts and saved policy distinct
Reset draft restores the last loaded saved values in this form. Reload policy reads the current server policy and retains your unsaved edits so that you can compare and review them. Switching projects keeps the forms scoped to their respective projects.
If the save reports a conflict or the current policy cannot be read, reload and reconcile before saving again. A failed read must not be treated as an empty policy. If the outcome of a save is uncertain, inspect the current saved state before issuing another change.
Understand what counts
The gate counts active findings that have not been suppressed or exempted. Open and Needs review remain eligible to count under the policy. Non-blocking for gate and Accepted risk retain an active report with a gate exemption. Ignore, False positive and Fixed exclude the report from active gate counts.
These are reasoned review decisions, described in the finding lifecycle guide. Marking a finding Fixed does not verify a source repair. A new scan supplies the evidence about changed code.
Changing dispositions can make a completed scan meet its policy. It cannot repair missing scanner evidence in a partial or failed scan. The gate also does not treat Advisor’s model answer or confidence as a policy decision.
Connect the gate to push protection
A project gate by itself does not block Git. Push protection requires separate clone-specific approval and an explicit application of the local hook in VS Code.
For a push that sends source trees, protection checks current, complete, passing evidence for the exact outgoing history. A passing file scan, earlier workspace scan or different ref is not a substitute. Changes to policy, dispositions, scanner evidence or outgoing refs can require a new check.
A deletion-only or no-op outgoing plan has no source tree to scan, but repository approval and current policy still apply. The protection workflow explains this case separately from a source-bearing push.
Read the gate operations for project policy requests, configuration operations for their separate runtime controls, and scanning architecture for how evidence reaches the decision.