Skip to content
ScrinCloudScrinCloud Docs

Remediation review

Remediation review is separate from diagnosis. A diagnosis can identify a possible cause; a review presents a bounded proposed code change with evidence, checks, findings, limitations, and rollback context.

Typical time
15–30 minutes plus Git review
You need
An authorized project remediation link
Outcome
A human decision continued in protected Git
Section titled “Step 1: Open the authorized review link”

Open remediation review from the owning project workflow. The link must contain both the project and remediation-run context. If either is missing, the page shows Review link is incomplete and does not search across projects.

Remediation review 1 of 4 · Screenshot placeholder

Future capture briefHide URL query values, tenant/project/run IDs, user identity, repository details, access tokens, and browser history.

Only organization owners, project owners, or authorized remediation reviewers should receive review data. A scope mismatch is blocked rather than showing a different project’s proposal.

Step 2: Review incident, cause, and approval state

Section titled “Step 2: Review incident, cause, and approval state”

Read:

  • Approval state: Pending, Approved, or Changes requested;
  • Incident summary;
  • Root cause summary; and
  • the notice that the page cannot approve or merge.

Approval state is informational readback. Git branch protection, required checks, eligible reviewers, and merge policy remain authoritative.

Step 3: Inspect the Proposed diff

Section titled “Step 3: Inspect the Proposed diff”

Review the changed-path count, additions, deletions, shortened patch digest, path list, and already secret-scanned preview. Confirm every path is expected and within the approved repository boundary.

Remediation review 2 of 4 · Screenshot placeholder

Inspect the bounded proposed diff

Show a synthetic path list, small change summary, shortened digest, and harmless secret-free preview.

Future capture briefUse fictional code and paths. Hide repository and branch names, source commit, full digest, secrets, credentials, customer code, and internal URLs.

The displayed diff is a proposal, not an applied change. Protected paths, unsupported extensions, excessive size, stale evidence, unavailable Git, or missing human/specialist approval must fail closed.

Step 4: Review checks, findings, and evidence

Section titled “Step 4: Review checks, findings, and evidence”

In Tests and release checks, confirm each check category, status, required flag, and duration. A mandatory failed, skipped, or timed-out check requires attention.

Then review Security and IaC findings and Evidence status. Expired or unavailable evidence weakens the review and must not be silently treated as available.

Remediation review 3 of 4 · Screenshot placeholder

Review required checks and findings

Show synthetic passed and failed mandatory checks, security/IaC findings, and available or expired evidence.

Future capture briefHide check result bodies, workflow URLs, full digests, evidence IDs, security-sensitive findings, actors, and repository metadata.

Step 5: Read limitations and Rollback

Section titled “Step 5: Read limitations and Rollback”

Read every Known limitation and the Rollback summary. A rollback note is review context; it is not proof that rollback was tested or that a deployment can be safely reversed in the target environment.

Step 6: Continue in Git

Section titled “Step 6: Continue in Git”

Choose Open pull request in Git only after the review snapshot matches the intended incident, repository, source commit, and patch. Complete review, approval, required checks, and merge in the Git provider.

Remediation review 4 of 4 · Screenshot placeholder

Continue through protected Git

Show the synthetic Open pull request in Git action and an authority boundary separating this read-only page from Git approval and merge.

Future capture briefHide repository URL, pull-request ID, reviewers, comments, branches, commit SHA, tokens, check links, and customer organization details.

Check your result

Section titled “Check your result”

You can trace the immutable proposal to its incident, source commit, policy, bundle, evidence, checks, limitations, rollback notes, and external Git review without claiming it was approved, merged, applied, or deployed here.

Common blockers

Section titled “Common blockers”
  • Review link is incomplete: reopen it from the owning project flow.
  • Reviewer access denied: request an authorized project review role.
  • Review not found: confirm the exact project and remediation run.
  • Review is being refreshed: wait and retry; do not use an older snapshot.
  • Mandatory check failed: fix the proposal and create reviewed evidence.
  • Git action unavailable: the server did not authorize a safe HTTPS review link.

The review UI and immutable contract do not prove a proposal API is deployed, a pull request exists, or a merge occurred. Record those only from authorized runtime and Git evidence.