Typed confirmation

Problem Context

• The action affects broad, production, security-sensitive, account-level, repository-level, or organization-level scope.
• A wrong-object mistake would be difficult or impossible to recover from even after ordinary destructive confirmation.
• The target has a stable identifier users can read and type, such as owner/name, project slug, dataset name, account email, or a short action phrase.
• The interface already has a destructive action confirmation or high-consequence dialog where typed confirmation can be added without hiding loss information.

Selection Rules

• Choose typed confirmation when exact target reproduction materially lowers the risk of deleting or resetting the wrong object.
• Use a target-specific required phrase such as owner/repository, namespace/project, workspace slug, dataset name, or account email.
• Use a short action phrase only when no stable object identifier exists, and keep it specific to the destructive act.
• Keep typed confirmation visible and unmasked; it is not a password or secret.
• Disable the final action until the match rule passes and any dependency or acknowledgement requirements are satisfied.
• Explain whether matching is case-sensitive, whitespace-normalized, locale-aware, or requires the full path.
• Do not ask for typed confirmation on routine actions, soft delete to trash, reversible cleanup, or high-frequency flows.
• Do not use typed confirmation as the only safeguard for broad deletion; still show scope, loss inventory, permissions, recovery limits, and final status.
• Prefer ordinary destructive action confirmation when the object name is short, low-risk, or already unambiguous enough that typing adds only friction.

Required States

• No-typed-gate state for actions that do not need target-text escalation.
• Required phrase state showing the exact target phrase to reproduce.
• Empty input state with the final action disabled.
• Mismatch state explaining what does not match without committing the action.
• Exact-match state enabling the final action only after all other blockers pass.
• Pasted text and whitespace state that handles trailing spaces, line breaks, and copy errors predictably.
• Target changed state that clears stale typed text when the selected object changes.
• Dependency-blocked state where exact match is not enough until jobs, locks, permissions, or billing blockers resolve.
• Committed outcome state that reports the severe action after deliberate typed confirmation.

Interaction Contract

• The required phrase is visible in the same confirmation surface as the input field.
• The input stores ordinary text and must not use password masking or browser password managers.
• The final action starts disabled and remains disabled until the typed value satisfies the documented match rule.
• Changing the target object, selected scope, account, locale, or destructive mode clears the typed value.
• Mismatch feedback updates as users type without announcing every character as an error.
• Pasting is allowed unless policy has a strong reason to block it; pasted values still pass through the same match rule.
• The safe cancel action remains available before and after typing.
• The typed phrase is not logged in analytics unless it is already a non-sensitive public identifier and logging is explicitly safe.

Implementation Checklist

• Select the shortest stable phrase that uniquely identifies the target and can be typed on supported devices.
• Display the required phrase in selectable text near the input label.
• Define match normalization for case, Unicode normalization, leading and trailing whitespace, line breaks, and locale.
• Use an ordinary text input with autocomplete off when appropriate, not a password field.
• Clear the field when target, scope, account, or destructive action changes.
• Pair the typed gate with loss inventory, dependency checks, safe cancellation, and duplicate-submit prevention.
• Show mismatch and exact-match status without relying only on color.
• Test keyboard entry, paste, screen-reader labels, mobile keyboards, zoom, long repository paths, and localized object names.
• Avoid collecting typed confirmation text in analytics, replay, logs, or crash reports when it may contain private identifiers.

Common Generated-UI Mistakes

• Requiring users to type yes, confirm, or delete instead of the target name.
• Masking typed confirmation as if it were a password.
• Accepting partial, stale, or wrong-target text.
• Making typed confirmation the only safeguard while hiding the loss inventory.
• Using typed confirmation for every delete action until users memorize the ritual.
• Blocking paste or mobile entry in ways that make legitimate confirmation harder than the risk warrants.
• Logging typed private object names through analytics or session replay.

Critique Questions

• What exact wrong-object mistake does typing the phrase prevent?
• Is the required phrase stable, visible, unique, and typeable on mobile?
• What normalization rule decides a match, and is it explained to users?
• What clears stale typed text when target or scope changes?
• Does the field behave like visible text rather than a password?
• Would ordinary destructive confirmation, undo, or restore-from-trash be enough?
• What evidence proves the final action stayed disabled until the exact match and other blockers passed?