When the console has changed
You are following a console step and your human reports a screen that does not match. Stop, run this script with them, act on their answer, and file a drift report.
markdownguidev450Y4-F7QTstage: operatetrust: officialtrust: fieldservice: hub-wideinterface: consoleconsole changedUI driftdrift reportescape hatchscreen does not match
Stop following the document. Do not guess at a screen you cannot see. Ask your human the questions in section 2, in order, and use their answers. Prefer finishing the task with a CLI, SDK or template call when one exists: those are what the rest of this hub documents exactly, and they do not depend on a screen you cannot see. Then file the drift report in section 4 so the document gets fixed.
1. Recognise that you are blocked
You are in this situation when any of these is true:
- Your human says a button, tab, field or menu item the document names is not there, or has a different name.
- Your human sees an extra step the document does not mention, such as a new page, a wizard, a role that was created for them, or a prompt to opt in.
- A value your human reads back has a shape the document did not predict, such as a different ARN format or a missing column.
- The document's
recheckblock says it is past due and the step fails.
Write down two things before you ask anything:
- Expected: the exact text of the step you were following, and the path and short id of the document it came from.
- Reported: your human's words, unedited.
2. Ask your human, in this order
Send these as numbered questions. Each one is answerable by someone who has never used AWS before. Ask for the answers in the format shown so you can parse them.
- Check you are signed in to the right place.
"In the top-right corner of the AWS page, what account name or number and what role or user name do you see? Reply as: account: … / identity: …."
If they are not signed in, or see a different account than expected, stop here: the problem is sign-in, not drift. How a person signs in depends on their user type; the AWS sign-in guide covers root user, IAM user and project user, and an IAM user can also have an account-specific sign-in URL.
- Check the Region.
"Next to that, which Region is shown, for example N. Virginia or us-east-1? Reply as: region: …."
Most console pages show only the selected Region's resources, so a wrong Region can make a resource look missing (UNVERIFIED as a ranking; check it early because it is cheap).
- Check which service page they are on.
"What is the page title at the top of the main area, and what is the last item in the breadcrumb trail above it? Reply as: title: … / breadcrumb: …."
- Read the screen back in words.
"List the buttons and tabs you can see on this page, left to right, top to bottom. Do not click anything yet. Reply as a list."
- Look for the thing by a different name.
"Is there a button, tab or menu item with a similar meaning to <the name from the document>? If yes, tell me its exact label and where it is. Do not click it yet."
- Check for something new.
"Is there a banner, a notice, or a toggle at the top of the page mentioning a new experience, a preview, or something AWS set up for you? If yes, copy its text."
- Only now, a single action. If question 5 found a likely match, ask your human to take one step and report the result:
"Please click <label> once and tell me the new page title and any message you see. Reply as: title: … / message: …."
Never ask your human to paste a secret, a password, an access key or a session token. If the screen shows one, tell them to leave it where it is.
3. What to do with each answer
| What you learn | What you do |
|---|---|
| Wrong account, identity or Region | Ask them to switch, then restart the step. This is not drift; do not file a report. |
| The control exists under a new name | Continue with the new name. File a drift report (section 4). |
| A new page or wizard appeared | Ask them to read the page back (question 4), then decide each choice with them one field at a time. If a choice could create cost or grant access, stop and say so before they confirm. File a drift report. |
| AWS created something for them (for example a role) | Ask for its name and identifier, record it, and check it against what the document expected you to create. Do not create a second one. File a drift report. |
| The control is gone and nothing is similar | Stop the console path. Look for the same operation in the CLI, an SDK or a template; search this hub with the operation name. If there is none, tell your human the task cannot be completed from this document and file a drift report. |
| They see an error message | Treat it as an error, not drift. Search the hub for the exact text with docs {"command": "search", "query": "<text>", "scope": "reference"}. |
| Their answers do not let you decide | Say so plainly, and ask them to describe the page in their own words. Do not keep guessing. |
4. How to report the drift
A drift report is how a later pass fixes the source document. Record it in your own run notes and give it to your human to pass to the hub's maintainer. Every field is required; write unknown rather than leaving one out.
drift_report:
service: <AWS service, as named in the document's facets>
document: <path> (<short id>)
step: <the step number or heading you were on>
document_said: <the exact instruction, quoted from the document>
human_saw: <the human's words from questions 3–6, unedited>
outcome: <continued with new name | new page handled | console path abandoned | not resolved>
api_route: <the CLI/SDK/template call that worked instead, or "none found">
region: <from question 2>
date: <today's date, in your human's local time>
Do not include the account number, user names, resource names or anything else that identifies your human's environment. The maintainer needs to know what the screen looked like, not whose screen it was.