Read a complete NotesWorkshop design with a selectable code and compare candidate text against the exact code/state contract. Expiration remains an operational field to resolve before production.
Put the action beside the full code
Use this review fixture:
| Field | Authored demonstration value |
|---|---|
| Application | NotesWorkshop |
| Request label | R1, fictional |
| Code string | 083417 |
| Intended action | Return to the sign-in screen you opened for NotesWorkshop and enter all characters. |
| Backend expiration policy | [TO CONFIRM] |
| Provider and configured flow | [TO CONFIRM] |
| Actual verification outcome |
The code is text, not a number. Its six characters include the first 0. The string 83417 fails this fixture even though a numerical conversion would treat both forms as the same value. Keep the full string through the native template, prepared HTML, and plain-text twin.
Make the code readable and selectable as text. An image of the code adds a dependency the task does not need. A verification input or Verify button belongs in the application's actual sign-in workflow, not in this email design.
The message should answer two immediate questions: “Which application is this for?” and “What should I do with it?” The fictional request label R1 belongs in the review record; do not turn it into a real support reference or claim that a request happened.
Use this complete demonstration message
Review subject: Your NotesWorkshop sign-in code — DEMONSTRATION ONLY
Heading: Your NotesWorkshop sign-in code
DEMONSTRATION ONLY — fictional design review
083417
Return to the sign-in screen you opened for NotesWorkshop and enter all characters, including the first 0.
Expiration policy: [TO CONFIRM — obtain the actual backend policy before release].
If you did not request a code, do not use or share this code. Return to the application through your usual route if you need help.
This review shows an issued challenge awaiting verification. It does not show a signed-in session.
The demonstration label, unconfirmed expiration, and review-state sentence make this a review copy. Resolve operational fields and review production wording before release. Do not send the fixture as a usable sign-in message.
For a prepared HTML design, preserve that content order: demonstration label, application heading, code text, entry instruction, expiration field, and unrequested-code guidance. Use a clear reading hierarchy and enough space around the code that its first character is easy to notice. No JavaScript, code-entry form, decorative “verified” badge, or nonfunctional button is needed.
Keep the plain-text twin in step
The plain-text twin must carry the same meaning:
Subject: Your NotesWorkshop sign-in code — DEMONSTRATION ONLY
DEMONSTRATION ONLY — fictional design review
Your NotesWorkshop sign-in code
Code: 083417
Return to the sign-in screen you opened for NotesWorkshop and enter
all characters, including the first 0.
Expiration policy: [TO CONFIRM — obtain the actual backend policy
before release].
If you did not request a code, do not use or share this code.
Return to the application through your usual route if you need help.
Compare the versions by field rather than appearance. Both must retain NotesWorkshop, 083417, the same entry destination, and the unconfirmed expiration. If one version omits the first zero or claims verification, it is a content mismatch.
A browser rendering cannot establish how an actual email client presents the message. Client layout, selection, wrapping, and plain-text delivery need later tests with an authorized synthetic challenge.
Bind the provider field deliberately
| Required confirmation | Value or observation |
|---|---|
| Provider and configured sign-in flow | [TO CONFIRM] |
| User-facing code field | [TO CONFIRM] |
| Code format and string-preserving handling | [TO CONFIRM] |
| Expiration policy and authoritative source | [TO CONFIRM] |
| Invalid-code, expired-code, and reuse behavior | [TO CONFIRM] |
| Resend and attempt policies | [TO CONFIRM] |
| Authorized synthetic test observations |
Match state wording to evidence
| Review case | Evidence needed | Appropriate wording |
|---|---|---|
| Prepared message | Template review only | Demonstration design; actual issuance unknown |
| Issued challenge | Actual provider issuance result | Code issued; verification pending |
| Expired challenge | Actual provider expiration result | Request a new challenge through the application |
| Verified session | Actual successful verification/session result | Signed-in state may be shown by the application |
Try the worked example
Compare the candidate 083417 with the visible message, then remove its first 0 to see a code mismatch. Try a “You are signed in” candidate to expose the unsupported state claim. The companion check does not verify a credential. An issued challenge is not a verified session.
Recreate this example
Build one complete self-contained HTML page for this task: prepare a complete fictional code email and review its text parity outside the email itself.
Use these exact original practice data and worked expectations: NotesWorkshop; fictional request R1; code 083417 as text. Return to opened NotesWorkshop sign-in screen and enter all characters. Expiration [TO CONFIRM]. Demonstration only; issuance/verification not connected.
Implement the following useful local interactions: Show a static email article containing no form or JavaScript-dependent action. Separately provide companion candidate-code and state-wording inputs with Check content parity. The exact text 083417 matches; 83417 fails; signed-in wording fails because no provider session was verified. Provide matching plain-text twin. Preserve the supplied source text and distinguish an uncomputed state, a successful local result, and an invalid or incomplete input. Update output only from the current input snapshot. An input edit must retire stale feedback until the reader runs the relevant action again. Do not silently invent missing values or replace a failing case with a success.
Design the page as a compact source-and-result developer workbench with readable code, labeled inputs, and a separate explanation area. Put a compact task heading, actual sample data, the main result, and usable controls early enough to be useful on a narrow screen. Use readable text of at least 16px, generous paragraph spacing, strong contrast, native labels, accessible buttons, and visible keyboard focus. Stack long records at 360px and wrap code without page-level horizontal overflow.
Use type=button and explicit querySelector-based click handlers rather than relying on form submission. If Enter is useful, handle it only on the relevant input and ignore isComposing. Keep effects within this open page; no remote dependencies, network calls, persistence, fake downloads, or automated sending. The code is fictional design data. No provider, real user, email delivery, code verification, or session is connected. Place worked explanations beside their data and identify teacher or synthetic examples clearly. Output only the complete HTML document, with inline styles and script and LF line endings.
Review the HTML and plain-text wording in NOS
Resolve provider fields and expiration from the actual backend before testing the production template in email clients. A fictional design copy in NOS can support wording review; eligible static entry instructions can be revised in visual editing mode.