ScrinOps workflow

ScrinOps brings provider-neutral incident summaries and advisory diagnosis into the project workspace. It does not replace your cloud provider, monitoring system, incident owner, Git controls, Terraform approvals, or audit record.

Typical time

20–45 minutes plus runner time

You need

An enabled environment and existing project scope

Outcome

A reviewed advisory diagnosis

The guarded journey

Stage	Product area	What it proves
Select scope	Setup	Which existing project, workspace, and cloud connection you intend to inspect
Check access	Check health	Whether the read-only connection check returned healthy, degraded, or revoked
Discover	Discover sources	Which monitoring sources are readable now
Preview	Run dry preview	What a future binding would create and preserve, with zero mutations
Triage	Incidents	A redacted provider-neutral summary, timeline, evidence manifest, and audit history
Diagnose	Start read-only diagnosis	A server-authorized advisory run was accepted for ready evidence
Monitor	Runs	Authoritative lifecycle, sanitized activity, evidence metadata, diagnosis, and usage
Review change	Remediation review	An immutable proposal snapshot that must continue through protected Git controls

Workflow 1 of 3 · Screenshot placeholder

Understand the ScrinOps operating sequence

Show a synthetic flow from Setup through Incidents, read-only diagnosis, run evidence, and Git review.

Future capture briefUse documentation-only labels. Hide tenant, project, workspace, provider, incident, run, evidence, repository, and reviewer identifiers.

Step 1: Confirm availability

ScrinOps appears in the workspace navigation only when the product capability is enabled for that deployed environment. If the navigation item is absent, do not construct a URL or assume the backend is available. Ask an organization administrator to confirm rollout and plan access.

Step 2: Use Setup as a preview

The current Setup area offers Check health, Discover sources, and Run dry preview. These actions are read-only. There is no enable, activate, or save-binding action on this page, and a dry preview does not start incident ingestion.

Step 3: Review an incident

Choose the exact project and workspace in Incidents, filter the provider- neutral history, and open View details. Read Overview, Timeline, Evidence, and Audit before considering diagnosis.

Step 4: Start advisory diagnosis

Start from an incident with at least one ready, unexpired evidence manifest. The browser cannot choose prompts, tools, model policy, runner profile, timeout, or placement. ScrinOps cannot apply Terraform, merge code, or change cloud resources.

Workflow 2 of 3 · Screenshot placeholder

Confirm the read-only diagnosis boundary

Show synthetic incident evidence entering an advisory runner, with cloud mutation and Git merge outside the boundary.

Future capture briefDo not show raw logs, prompts, provider payloads, credentials, repository content, model settings, or internal runner infrastructure.

Step 5: Monitor authoritative status

Use the active runner dock and Runs history. A queued or running record is not a completed diagnosis. Wait for a terminal status and inspect the structured activity, evidence availability, cited hypotheses, risks, uncertainty, and usage.

Step 6: Keep remediation governed

A remediation review can show a proposed diff, test results, findings, evidence, limitations, rollback notes, and Git approval state. It cannot approve or merge. Continue in the protected Git pull request, where branch protection and required checks remain authoritative.

Workflow 3 of 3 · Screenshot placeholder

Separate diagnosis, proposal, approval, and execution

Show four distinct synthetic states: advisory diagnosis, remediation proposal, Git approval, and separately governed delivery.

Future capture briefHide source code, diff bodies, repository URLs, reviewers, approval evidence, deployment details, and customer infrastructure.

Check your result

You can identify the exact scope, evidence freshness, diagnosis status, advisory findings, and next human-owned decision without claiming that ScrinOps mutated infrastructure.

Common blockers

• ScrinOps is absent: the deployed environment or plan has not enabled it.
• Setup checks fail: the existing cloud connection or runtime contract is unavailable; no setup mutation occurred.
• No incidents: confirm the selected scope and deployed incident ingestion.
• Diagnosis disabled: ready, unexpired evidence is required.
• Remediation unavailable: a diagnosis does not automatically create a proposal or Git pull request.

Source code, CI, API routes, and Terraform wiring describe intended controls. Only an authorized runtime journey proves that a particular environment ingested an incident, ran diagnosis, retained evidence, or created a remediation review.