Sentinel configuration and troubleshooting

Sentinel troubleshooting starts with authorization, source availability, scope, plan state, data provenance, and private-alpha limitations. Diagnose repository intake before scan behavior, then distinguish missing results from demo, fixture, empty, unsupported, or store-backed states. Remediation must remain defensive and repository-authorized; this guide does not provide live-target, credential-testing, exploit, destructive-testing, or external-disclosure instructions.

Configuration

The grounded configuration path uses an authorized local repository. Unavailable Git and archive paths reflect planned rather than active intake. Authorization diagnosis starts by confirming ownership or explicit permission, choosing the local source, narrowing scope, selecting an available scan profile, and reviewing preflight information.

Policy decisions can allow, deny, or require approval. Approval outcomes are none, human-required, or blocked. A declared action class does not prove the action is executable, and no configuration should override the authorized repository boundary.

Check the current source state and product posture. Sentinel is private alpha; a demo or fixture page is not equivalent to a configured production workspace.

Sentinel configuration begins with authorization, local source availability, scope, and private-alpha readiness. Local repository intake is the grounded private-alpha source, while Git-provider connection and archive upload are planned. Authorization must be confirmed before scope or scan activity. Policy outcomes can deny an action or require approval even when an action class exists in the type system.

Local repository intake is the grounded private-alpha source, while Git-provider connection and archive upload are planned; verify authorization and the selected local repository path. Plans may load from a store, while findings, queues, and history can use store or demo fallbacks; review the scan plan for denied, blocked, unsupported, or approval-required actions. Do not work around a denied action or broaden scope beyond the authorized repository.

Empty and unsupported states are different: empty can mean no records, while unsupported indicates the path is not available; verify authorization and the selected local repository path. Authorization must be confirmed before scope or scan activity; review the scan plan for denied, blocked, unsupported, or approval-required actions. Do not work around a denied action or broaden the scope beyond the authorized repository.

Repository errors

Repository troubleshooting begins with intake state, not scanner rules. Confirm that the source is the available local path, that the repository still exists, and that the operator remains authorized to assess it. Git-provider cards and archive upload are planned; failures on those paths should be documented as unavailable capability rather than repaired with invented token or upload instructions.

For a local path, distinguish an inaccessible directory from an empty repository, an incorrect root, and a scope that excludes all relevant files. These conditions can produce similar empty-state symptoms but require different corrections.

Repository problems commonly come from an unavailable source type, inaccessible local path, incorrect root, or uncertain authorization.

Do not broaden filesystem access or move to a remote target to bypass intake limitations.

Repository failures commonly arise from unavailable source types, inaccessible paths, or authorization problems. Plans may load from a store, while findings, queues, and history can use store or demo fallbacks. Patch proposals have no durable store and should remain labeled demo or fixture. Empty and unsupported states are different: empty can mean no records, while unsupported indicates the path is not available.

Policy outcomes can deny an action or require approval even when an action class exists in the type system; confirm the data-source label on the page that appears empty or inconsistent. Empty and unsupported states are different: empty can mean no records, while unsupported indicates the path is not available; check whether findings and history come from a store or demo fallback. When evidence is missing, preserve the repository, scan, finding, and source-state identifiers needed for an internal product investigation without exposing secrets.

Local repository intake is the grounded private-alpha source, while Git-provider connection and archive upload are planned; confirm the data-source label on the page that appears empty or inconsistent. Plans may load from a store, while findings, queues, and history can use store or demo fallbacks; check whether findings and history come from a store or demo fallback. If evidence is missing, preserve the repository, scan, finding, and source-state identifiers needed for an internal product investigation without exposing secrets.

Scan failures

A scan can fail before execution because scope is invalid, policy denies an action, approval is required, a scanner is unsupported, or the current data path cannot produce records.

Review the plan and preflight first. Distinguish deny from requires_approval, and distinguish a blocked action from an operational error. Do not retry a denied or blocked action.

If the scan starts but records do not appear, inspect source provenance and status. Empty means no records are available; unsupported means the path cannot provide them. Demo results do not prove the selected repository was analyzed.

Scan problems can originate in scope, plan, policy, unsupported action, or data-store state. Finding schema, severity rubric, collaboration persistence, exports, and retention remain review areas. Review the scan plan for denied, blocked, unsupported, or approval-required actions. Check whether findings and history come from a store or demo fallback.

Patch proposals have no durable store and should remain labeled demo or fixture; review the scan plan for denied, blocked, unsupported, or approval-required actions. Local repository intake is the grounded private-alpha source, while Git-provider connection and archive upload are planned; treat patch issues as proposal-display limitations rather than source-tree failures.

Policy outcomes can deny an action or require approval even when an action class exists in the type system; review the scan plan for denied, blocked, unsupported, or approval-required actions. Empty and unsupported states are different: empty can mean no records, while unsupported indicates the path is not available; treat patch issues as proposal-display limitations rather than source-tree failures.

Finding issues

When a finding looks incomplete, verify its data source, repository reference, affected files, evidence references, severity, classification, and creation time. A demo record can be internally consistent while still being unrelated to the selected repository. Missing evidence should be treated as a review gap, not repaired by guessing the scanner result.

Status and classification problems require separate diagnosis. The complete mutation contract is not verified, so a control that changes the screen may not prove durable persistence. Refresh the source and check history before relying on the change.

Unexpected findings require a provenance and evidence review. Confirm whether the record is store-backed or demo-backed, verify the affected files, and follow the source or scanner references.

Severity, confidence, classification, and status are separate. Do not change one field to compensate for missing evidence. The complete severity rubric and persistent status workflow remain under review.

If no findings appear, do not conclude that the repository is secure. Check scan scope, plan state, scanner availability, source type, and data loader behavior.

Missing or unexpected findings require a source-provenance check before severity or scanner conclusions. Treat patch issues as proposal-display limitations rather than source-tree failures. Use /sentinel/status to review readiness before repeating a scan attempt.

Finding schema, severity rubric, collaboration persistence, exports, and retention remain review areas; check whether findings and history come from a store or demo fallback. Policy outcomes can deny an action or require approval even when an action class exists in the type system; use /sentinel/status to review readiness before repeating a scan attempt.

Patch proposals have no durable store and should remain labeled demo or fixture; check whether findings and history come from a store or demo fallback. Local repository intake is the grounded private-alpha source, while Git-provider connection and archive upload are planned; use /sentinel/status to review readiness before repeating a scan attempt.

Patch issues

A missing or stale proposal should be diagnosed against the demo or fixture source. Do not interpret it as a failed repository write, because Sentinel has no verified application path.

Patch proposals are demo or fixture review artifacts with no durable store. They cannot be applied, committed, pushed, or turned into pull requests by Sentinel.

A proposal that disappears after reload can reflect the current non-durable implementation. A disabled application control is not a permission or setup error. Transfer a useful suggestion into the normal development workflow and review it independently.

Do not attempt to work around the read-only boundary or treat action-class names such as apply_patch and open_pr as hidden capabilities.

Patch problems usually reflect demo-only proposal behavior rather than source mutation failure. Verify authorization and the selected local repository path. For an empty or inconsistent page, inspect its data-source label first.

Authorization must be confirmed before scope or scan activity; treat patch issues as proposal-display limitations rather than source-tree failures. Patch proposals have no durable store and should remain labeled demo or fixture; verify authorization and the selected local repository path.

Finding schema, severity rubric, collaboration persistence, exports, and retention remain review areas; treat patch issues as proposal-display limitations rather than source-tree failures. Policy outcomes can deny an action or require approval even when an action class exists in the type system; verify authorization and the selected local repository path.

Debugging checklist

Use the product’s source and policy labels to narrow the failure before retrying:

1. Confirm ownership or explicit authorization for the repository.
2. Verify that the selected intake path is currently supported; Git-provider connection and archive upload remain planned.
3. Check the local repository path and intended scope.
4. Read the plan for denied, blocked, unsupported, or approval-required actions.
5. Identify whether plans, findings, queues, and history are store-backed, demo, fixture, empty, or unsupported.
6. Compare a finding with its evidence references before changing classification.
7. Treat proposal problems as review-artifact limitations because no durable proposal store or apply path exists.

Record only safe repository identifiers, source labels, plan or finding IDs, and the visible error. Do not include credentials, complete sensitive files, or exploit instructions in troubleshooting notes.

Use this order to avoid changing unrelated parts of the workflow:

1. Confirm repository ownership or explicit authorization.
2. Verify that the local source path is accessible and correctly bounded.
3. Review scope, profile, plan, policy decision, and approval class.
4. Check whether the scan path is supported.
5. Identify store, demo, fixture, empty, or unsupported provenance.
6. Inspect safe scan and finding identifiers with the status route.
7. Treat proposal limitations as product boundaries, not source-tree failures.

For product support, include the current route, build context, source type, safe repository and scan identifiers, scope summary, policy outcome, and exact error. Remove credentials, secrets, and unnecessary source snippets. Never use troubleshooting as a reason to scan a live target or repository outside the authorized scope.

A bounded diagnostic sequence prevents unsafe workarounds and preserves the authorized repository boundary.

Plans may load from a store, while findings, queues, and history can use store or demo fallbacks; use /sentinel/status to review readiness before repeating a scan attempt. Finding schema, severity rubric, collaboration persistence, exports, and retention remain review areas; confirm the data-source label on the page that appears empty or inconsistent.