Implement correctly
Build Text field without breaking its behavior
# Implement Text field in your agent ## Objective Implement Text field for this verified behavior: A labeled single-line control for entering or editing one textual value. ## Prerequisites - Inspect the repository, design system, and existing tests first. - Preserve unrelated changes and keep the file scope bounded. - Confirm that Text field matches the need before writing code. ## Required behavior - Typing edits a single value while selection, clipboard, and undo behaviors remain native. - A specific inline message identifies the invalid field and explains how to correct it. ## States to cover - Display name valid - Display name invalid ## Accessibility - ARIA role: input[type=text] - The primary control or named region for Text field has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names. - A visible focus indicator surrounds the field without hiding its value, label, or error. - Not applicable: the entered value remains until edited, reset, or intentionally submitted. - Label, input purpose, required state, helper relationship, invalid state, and specific error are exposed. - Tab focuses the field - Standard editing, selection, undo, and clipboard shortcuts remain native - Enter follows the surrounding form contract ## When not to use - The response needs line breaks - The primary intent is to submit a search query ## Acceptance criteria - A visible label remains outside the placeholder - Input purpose and autocomplete are correct - Help and error text are programmatically associated - Invalid submission preserves the user's value ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Web platform
- Requires · Access to the repository, design system, and tests
Why it works
- The need is tied to canonical behavior before any technical choice.
- States, accessibility, and non-goals prevent a merely visual implementation.
- Acceptance criteria and the output format make verification observable.
Try next
Verify Text field on a real journey
# Verify Text field after implementation ## Objective Audit the Text field implementation against its behavior, states, and accessibility requirements without changing it automatically. ## Checks - Replay the smallest representative journey. - Check keyboard behavior, focus, accessible name, and announcements. - Tie each gap to a specific acceptance criterion. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:2c0b00f0b3ebc6ae8d5055d516a154c9f2e6d8decac7f928b747c9ea5a67e282