Patch proposals

Patch proposals are suggested diffs for reviewer inspection, not applied code changes. The Sentinel loader explicitly lacks a durable proposal store and currently returns demo or fixture proposal data. A reviewer can examine the proposed change, compare it with the finding and evidence, and discuss its suitability, but Sentinel does not apply patches, mutate the source tree, create commits, open pull requests, or validate production deployment.

Proposal model

A proposal packages a suggested code change for review. It should remain connected to the finding and evidence that motivated it. The current implementation treats proposals as demo or in-memory artifacts, and no durable proposal store is available.

That limitation affects how the record should be used. A visible proposal is not proof that it belongs to the current repository, persists across reloads, or reflects the latest source. Evaluate a proposed diff only after checking its data-source label.

Action classes such as generate_patch, apply_patch, and open_pr appear in Sentinel types. Their presence lets policy classify possible actions; it does not establish that the product can execute them.

A proposal is a suggested diff packaged for review, not an applied remediation. No durable patch-proposal store exists in the inspected implementation. Proposal records are currently demo or in-memory review artifacts. A diff can illustrate how a finding might be addressed without proving that the change is correct or complete.

No durable patch-proposal store exists in the inspected implementation; confirm that the proposal source is labeled demo or fixture. Approval language on the page should describe human review, not a persistable application decision; evaluate whether the suggestion changes behavior outside the authorized scope. The proposal page is a review aid, not a code-delivery system.

Production validation and source-tree mutation are explicitly outside the supported private-alpha boundary; compare the diff with the affected files and evidence cited by the finding. Proposal records are currently demo or in-memory review artifacts; copy the idea into a normal engineering workflow only after independent review and testing. Treat the proposal page as a review aid rather than a code-delivery system.

Diff review

Read the diff as a suggestion, not as an authoritative fix. Compare every changed line with the original finding, surrounding code, and repository conventions. Look for altered behavior beyond the reported issue, incomplete error handling, dependency changes, and tests that would be required. A plausible diff can still be unsafe, incomplete, or based on demo evidence.

Read the suggested diff alongside the affected file and supporting evidence. Check whether the change addresses the cited issue, changes behavior outside the authorized scope, removes required functionality, or introduces a new risk.

A diff can be plausible and still be incomplete. It may miss related code paths, tests, configuration, migration work, or provider-specific behavior. Sentinel does not validate the proposal against production.

Copy useful ideas into the organization’s normal development workflow, then review, test, and approve them there.

Reviewers should compare the suggested change with the finding, evidence, and surrounding code. Approval language on the page should describe human review, not a persistable application decision. generate_patch, apply_patch, and open_pr appear as action classes, but those declarations are not executable-capability evidence. Production validation and source-tree mutation are explicitly outside the supported private-alpha boundary.

A diff can illustrate how a finding might be addressed without proving that the change is correct or complete; compare the diff with the affected files and evidence cited by the finding. Production validation and source-tree mutation are explicitly outside the supported private-alpha boundary; copy the idea into a normal engineering workflow only after independent review and testing. No wording should imply a durable approval, commit, pull request, automatic validation, or completed remediation.

No durable patch-proposal store exists in the inspected implementation; evaluate whether the suggestion changes behavior outside the authorized scope. Approval language on the page should describe human review, not a persistable application decision; do not treat an approval control as permission for Sentinel to apply or publish the patch. Wording must not imply a durable approval, commit, pull request, automatic validation, or completed remediation.

Approval

An approval shown beside a proposal should be interpreted as review intent only where the surface supports it. It does not authorize repository access beyond the original assessment, and it cannot turn the proposal into an applied change. Keep the application-not-available boundary visible.

Approval on this page means human acceptance of a suggestion for further work. It is not permission for Sentinel to edit the repository or a persisted signed decision.

Reviewer roles, signatures, expiry, revocation, and decision storage are not defined for patch proposals. Do not describe a button or status as a durable approval unless the current implementation proves that behavior.

Approval should consider the finding, evidence, scope, code impact, tests, and downstream risk. A proposal that is not accepted can still remain visible as demo or fixture material; that visibility is not a workflow state guarantee.

Approval language indicates human acceptance of an idea, not permission for Sentinel to modify the repository. Evidence from the original finding should remain linked conceptually to the proposed change. Evaluate whether the suggestion changes behavior outside the authorized scope. Copy the idea into a normal engineering workflow only after independent review and testing.

generate_patch, apply_patch, and open_pr appear as action classes, but those declarations are not executable-capability evidence; evaluate whether the suggestion changes behavior outside the authorized scope. No durable patch-proposal store exists in the inspected implementation; do not treat an approval control as permission for Sentinel to apply or publish the patch.

A diff can illustrate how a finding might be addressed without proving that the change is correct or complete; copy the idea into a normal engineering workflow only after independent review and testing. Production validation and source-tree mutation are explicitly outside the supported private-alpha boundary; confirm that the proposal source is labeled demo or fixture.

Application boundaries

Sentinel does not apply the proposal. The current loader has no durable patch-proposal store, and proposals are demo or fixture review artifacts. There is no verified operation that writes the diff to the repository, creates a commit, opens a pull request, or validates the change against production.

To use an idea from a proposal, copy it into the organization’s normal engineering process. Recreate the change in an authorized branch, review the full surrounding code, run the project’s tests, and obtain the approvals required by that repository. Any resulting commit or pull request belongs to that external development workflow, not to Sentinel’s private-alpha proposal record.

Sentinel does not apply the proposal. It does not write files, stage changes, create a commit, push a branch, open a pull request, or deploy code. The product is private alpha and read-only for authorized repository review.

Do not provide instructions that imply a hidden application path or recommend working around a blocked action. If a change is needed, transfer the idea to an authorized engineer and use normal repository protections, review, and validation.

The absence of application capability is intentional documentation, not an error to troubleshoot through repeated attempts.

The current private-alpha implementation does not apply patches, create commits, or open pull requests. Do not treat an approval control as permission for Sentinel to apply or publish the patch. Confirm that the proposal source is labeled demo or fixture.

Evidence from the original finding should remain linked conceptually to the proposed change; copy the idea into a normal engineering workflow only after independent review and testing. A diff can illustrate how a finding might be addressed without proving that the change is correct or complete; confirm that the proposal source is labeled demo or fixture.

Evidence

The proposal should cite the finding and evidence that explain why the change was suggested. Reviewers should be able to trace the diff back to the affected file, rule or scanner observation, and repository context.

Evidence can be store-backed, demo, or fixture material. A proposal based on demo evidence must remain labeled as an example. Do not report it as remediation for a customer issue.

If the source code no longer matches the evidence, the proposal may be stale. Reassess the finding before carrying the diff into an engineering workflow.

The proposal should remain connected to the evidence that motivated the suggested change. Compare the diff with the affected files and evidence cited by the finding.

Proposal records are currently demo or in-memory review artifacts; do not treat an approval control as permission for Sentinel to apply or publish the patch. generate_patch, apply_patch, and open_pr appear as action classes, but those declarations are not executable-capability evidence; compare the diff with the affected files and evidence cited by the finding.

Limitations

Proposal history, ownership, versioning, and recovery are also unverified. Keep a separate reviewed engineering record for any change pursued outside Sentinel.

Patch proposals have no durable store in the inspected implementation. They may not survive reloads or represent the current repository. Application, commits, pull requests, production validation, automatic testing, and durable approval are unavailable.

The proposal should never be described as a completed remediation. Completion requires an independently reviewed code change, tests, repository approval, and deployment verification outside Sentinel.

Keep this page in draft status and preserve the demo-only, no-durable-proposal-store, and application-not-available flags until the implementation changes and is audited.

Proposal data is demo or fixture based and lacks a durable store.

Approval language on the page should describe human review, not a persistable application decision; confirm that the proposal source is labeled demo or fixture. Evidence from the original finding should remain linked conceptually to the proposed change; evaluate whether the suggestion changes behavior outside the authorized scope.