# Website Change & Incident Handoff Worksheet

Use this as a local planning sheet. Do not paste secrets, private customer data, production logs containing personal data, API keys, cookies, tokens, passwords, or browser-profile material into an AI tool.

## 1. Work identity

- Change / incident ID:
- Site, environment, and owner:
- Date and review window:
- Business purpose in one sentence:
- What a visitor will notice if this succeeds:
- What could be harmed if it fails:

## 2. Evidence inventory

- Current URL(s) or component name:
- Current baseline (screenshot, response code, release tag, test result, or analytics note):
- Request source and authority to act:
- Exact input files or approved references:
- Sensitive data present? `No / Yes — stop and use an approved restricted process`

## 3. Classify before AI work

| Class | Use it when | AI may do | Human must do |
|---|---|---|---|
| Prepare-only | No production or external change is requested | Draft ticket, checklist, test cases, summary | Verify facts and decide whether work proceeds |
| Review-required | A reversible proposed site/content/config change needs evidence | Compare approved inputs, draft release and rollback notes | Approve scope; execute or authorize execution; check evidence |
| Blocked / escalate | Credentials, secrets, production access, DNS, permissions, money, legal notices, deletion, incident severity, or customer impact is involved | Create a redacted handoff only | Authorized owner/security/operations lead decides and acts |

Selected class:

## 4. One-change packet

- Change statement: “Change ___ from ___ to ___ so that ___.”
- What will not change:
- Affected URLs, templates, integrations, or users:
- Preconditions / maintenance window:
- Named implementation owner:
- Named reviewer / approver:
- Rollback trigger:
- Rollback method and owner:
- External communication required? `No / Yes — approval required`

## 5. AI preparation prompt (safe by default)

```text
You are preparing a review packet, not changing a website.
Use only the approved, non-sensitive inputs below. Do not invent facts,
credentials, configuration values, URLs, or test results. Produce:
1) a concise change summary; 2) assumptions and missing information;
3) a test checklist; 4) rollback questions; 5) a human approval gate.
If the request involves secrets, production access, permissions, DNS, payments,
legal notices, deleting data, or external messaging, stop and return an escalation note.

Approved inputs:
[paste redacted inputs]
```

## 6. Verification evidence

- [ ] Correct environment confirmed.
- [ ] Scope and owner confirmed.
- [ ] Changed route/component loads as expected.
- [ ] Keyboard path and visible focus reviewed.
- [ ] Mobile-width check completed (including no unintended horizontal overflow).
- [ ] Relevant links/forms/error states tested.
- [ ] Accessibility concerns recorded for a qualified follow-up where needed.
- [ ] Security/permission impact reviewed by the authorized owner.
- [ ] Rollback information is usable and has an owner.
- [ ] Evidence links or filenames recorded without secrets.

Evidence record:

## 7. Release or incident decision

- Decision: `approve / reject / hold / escalate`
- Reason:
- Accountable human:
- Time and timezone:
- Next check:

## 8. Incident handoff (facts only)

- What was observed:
- First known time:
- Affected service / visitor impact:
- What evidence is preserved and where:
- What has already been tried:
- What must not be attempted without authority:
- Next accountable owner and escalation path:

