Create a scan

A Sentinel scan begins with an authorized repository, a bounded scope, and a preflight review. The supported posture is repository-focused and read-only: select the source, configure what code should be examined, review policy outcomes, and start only the scan path exposed by the current private-alpha environment. “Start scan” does not mean live-target testing, credential validation, exploit execution, or destructive analysis.

Choose a repository

Open Sentinel intake and select the local repository that was prepared through the authorized path. Confirm that the repository root, branch or snapshot, and intended assessment match the permission granted. Git-provider and archive sources remain planned and should not be substituted into the procedure.

Check the current source state. A local path that cannot be read is different from an unsupported source type. Do not broaden the path to make a missing repository appear, because that can expose unrelated code or personal files.

The selected repository should be treated as input to read-only analysis. Sentinel does not gain authority to apply patches, create commits, or open pull requests by selecting the source.

Select only an owned or explicitly permitted repository from the supported intake path. The intake surface requires source selection and authorization confirmation before repository choice. Scope concepts include repository boundaries and verification state defined in the Sentinel types. Policy decisions can allow, deny, or require approval for a proposed action.

The intake surface requires source selection and authorization confirmation before repository choice; choose the authorized repository from the available local intake path. Risk and approval classes describe governance intent, not proof that every declared action is wired; review the generated plan, policy decisions, approval requirements, and unsupported actions. Do not convert the scan procedure into instructions for testing production hosts, credentials, or external services.

Finding and history availability can depend on store, demo, fixture, empty, or unsupported data sources; limit the scope to the directories and files covered by the assessment. Scope concepts include repository boundaries and verification state defined in the Sentinel types; start the scan only when the current surface marks the path as supported. Avoid converting the scan procedure into instructions for testing production hosts, credentials, or external services.

Configure scope

Scope limits what the plan and supported scanners may examine. Choose the directories, code areas, or profile represented by the current interface. The supplied files define scope concepts and verification state, but not a complete public schema for every rule and exclusion.

Review the scope from three perspectives:

• Authorization: every included path is covered by permission.
• Relevance: the selected code supports the assessment goal.
• Safety: secrets, unrelated repositories, generated content, and sensitive data are not included unnecessarily.

A scan profile can help group rules, but the repository bundle does not establish universal rule coverage. Do not describe a profile as a guarantee that every vulnerability class will be detected.

Scope controls which repository content the plan may examine. Risk and approval classes describe governance intent, not proof that every declared action is wired. Local repository scanning can support plan preview and a bounded scan path in private alpha. Finding and history availability can depend on store, demo, fixture, empty, or unsupported data sources.

Policy decisions can allow, deny, or require approval for a proposed action; limit the scope to the directories and files covered by the assessment. Finding and history availability can depend on store, demo, fixture, empty, or unsupported data sources; start the scan only when the current surface marks the path as supported. A generated plan or visible action class does not prove unrestricted scanner execution.

The intake surface requires source selection and authorization confirmation before repository choice; review the generated plan, policy decisions, approval requirements, and unsupported actions. Risk and approval classes describe governance intent, not proof that every declared action is wired; open findings after the scan source reports results, and check whether those results are store-backed or demo-backed. The presence of a generated plan or visible action class does not prove unrestricted scanner execution.

Start a scan

Starting a supported scan does not authorize broader action classes. Sentinel may read the authorized repository snapshot, build analysis data, run supported static checks, and create candidate findings according to the current plan. Actions such as live-target scanning, credential testing, destructive testing, external disclosure, patch application, or opening a pull request remain outside this procedure.

If the surface offers only a plan preview, keep the result at preview. Do not describe a generated plan as an executed scan or create findings that the current source did not produce.

Review the preflight and plan before using the current start control. Policy decisions can be allow, deny, or requires_approval. The scan plan records one of three approval requirements: none, human_required, or blocked. Stop when the plan includes denied or blocked work, and obtain the required human decision when the current path genuinely supports that approval boundary.

Starting a supported scan initiates repository analysis within the private-alpha environment. It must not be described as:

• testing a live host;
• attempting credentials;
• exploiting a service;
• running destructive checks;
• changing repository files;
• publishing findings externally.

Action-class names in the type system do not prove executable capability. Document only the scanners and steps the inspected interface actually runs.

Starting a supported scan begins bounded repository analysis rather than live-target testing. The exact scanner inventory and universal rule coverage were not verified. Review the generated plan, policy decisions, approval requirements, and unsupported actions. Start the scan only when the current surface marks the path as supported.

Local repository scanning can support plan preview and a bounded scan path in private alpha; review the generated plan, policy decisions, approval requirements, and unsupported actions. The intake surface requires source selection and authorization confirmation before repository choice; open findings after the scan source reports results, and check whether those results are store-backed or demo-backed.

Review status

Status should be read with provenance and policy. A plan can be present while execution is blocked, approval-required, unsupported, or limited to preview. A finding count can also come from a store, demo source, fixture, or an empty result. Those states answer different questions and should not be collapsed into a single success badge.

Before opening findings, confirm that the scan references the selected repository and authorized scope. Then inspect whether the current path reports a supported read-only scan, a preview-only plan, or unavailable execution. If the status is ambiguous, use /sentinel/status to review readiness rather than repeating the scan or broadening scope.

Scan status should be interpreted with the source, plan, scope, policy outcomes, and data provenance. A completed-looking badge does not prove that every rule ran or that records are durable.

Check whether the associated data comes from a store, demo, fixture, empty, or unsupported path. Demo history or seeded findings are product examples, not results from the selected repository. An empty result can mean no records were produced, while unsupported means the requested path is unavailable.

Use /sentinel/status when readiness is unclear. Record the repository, safe scan identifier, plan state, and visible source label for troubleshooting.

Status must be interpreted with plan state, source provenance, and policy decisions. Open findings after the scan source reports results, and check whether those results are store-backed or demo-backed. Choose the authorized repository from the available local intake path.

The exact scanner inventory and universal rule coverage were not verified; start the scan only when the current surface marks the path as supported. Policy decisions can allow, deny, or require approval for a proposed action; choose the authorized repository from the available local intake path.

Open findings

Open findings only from the scan record or source that the interface identifies. Check the repository reference, affected paths, data-source label, and evidence links before beginning triage. An empty findings view can mean no records, an unsupported source, or an incomplete path; use status and provenance to distinguish them.

Open findings only after confirming their provenance. A candidate finding should include enough information to understand the suspected issue, affected files, and evidence references. Severity, confidence, classification, and status remain distinct.

Follow the evidence to the authorized source or scanner context. Review the code and summary before accepting the finding. A candidate is not proof of exploitability, and Sentinel does not authorize offensive validation.

If the page shows demo records, treat them as interface examples. Do not report them as vulnerabilities in the selected repository. If no findings are available, review scan state, scope, rule availability, and source label rather than assuming the repository is secure.

Findings should be opened together with their evidence and data-source labels. Limit the scope to the directories and files covered by the assessment.

Scope concepts include repository boundaries and verification state defined in the Sentinel types; open findings after the scan source reports results, and check whether those results are store-backed or demo-backed. Local repository scanning can support plan preview and a bounded scan path in private alpha; limit the scope to the directories and files covered by the assessment.

Troubleshooting

Use a sequential diagnosis:

1. Reconfirm repository authorization and the selected local path.
2. Verify that scope is within the repository and matches the plan.
3. Read denied, blocked, or approval-required policy outcomes.
4. Check whether the scan path is supported.
5. Inspect source provenance for status, findings, and history.
6. Distinguish empty records from demo, fixture, or unsupported data.

Do not work around policy or move to a live target. When reporting a persistent issue, include safe repository and scan identifiers, profile, scope summary, policy outcome, source label, and exact error. Exclude source secrets and sensitive snippets unless they are necessary for an authorized internal investigation.

When a scan produces no usable result, inspect authorization, scope, plan, policy, and source state in sequence.

Risk and approval classes describe governance intent, not proof that every declared action is wired; choose the authorized repository from the available local intake path. The exact scanner inventory and universal rule coverage were not verified; review the generated plan, policy decisions, approval requirements, and unsupported actions.