Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Design] Unify destructive actions and error states

Abierto
  • ¿Algo no está bien?
#160 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
accessibility, design, frontend

Línea de trabajo

Start with the design audit at /design-audit#surfaces and inspect TerminalAlert consumers in apps/web, plus the document deletion and other destructive dialogs. Review the existing focus, recovery, and announcement behavior before mapping the required states. Done means approved audit specimens, accessibility evidence, migrated consumers, screenshots, and passing bun run types, bun run ci, bun run design-audit:test, and bun test.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

triage/human-response

Base branch: main
Branch: maggie/design-error-and-destructive-states
Depends on: None

Goal

Design a coherent system for destructive actions and inline, recoverable, and terminal errors across Chopin.

Context From Planning

  • The destructive dialog and all error specimens in /design-audit#surfaces currently feel visually crude and inconsistent.
  • Destructive buttons, warnings, validation errors, retryable failures, and terminal failures need related semantics without making every error equally loud.
  • This is a proper design pass requiring human review, not a CSS-only color adjustment.

Current Behavior

Errors are presented through a mix of plain destructive text, TerminalAlert, ad hoc banners, and dialog-local copy. Destructive actions use related colors but do not form a clear severity, placement, or recovery system.

Desired Behavior

Define reusable alert/status and destructive-action patterns with clear severity, readable hierarchy, consistent actions, accessible announcements, and calm visual weight appropriate to the consequence.

Acceptance Criteria

  • The design audit covers inline validation, recoverable error with retry, terminal error, destructive confirmation, destructive failure, and disabled/busy destructive action.
  • Each pattern defines icon, title/body hierarchy, action placement, color role, surface, spacing, and announcement semantics.
  • Errors remain understandable without color alone and meet contrast requirements.
  • Retry, cancel, and destructive confirmation keep their existing behavior and focus management.
  • A shared primitive replaces duplicate presentation while retaining consumer-specific copy and recovery behavior.
  • Maggie approves the audit specimens before production migration.

Verification Commands

  • bun run types
  • bun run ci
  • bun run design-audit:test
  • bun test

Primary Surfaces

  • /design-audit#surfaces
  • TerminalAlert consumers in apps/web
  • Document deletion and other destructive dialogs
  • Research, navigation, and composer failures

Expected PR Checks

  • Repo required checks

Report Requirements

  • State matrix and before/after screenshots
  • Accessibility behavior for alerts and dialogs
  • Production consumers migrated
  • Deferred edge cases

Implementation Notes

  • Preserve the distinction between validation, recoverable, and terminal failures.
  • Preserve persistence-before-publication and existing action semantics; presentation must not acknowledge work early.
  • Build on shared tokens/components rather than bespoke dialog and banner CSS.

Stop Conditions

  • Severity semantics or copy require a product decision.
  • A proposed shared component cannot preserve a consumer's focus or recovery contract.
Lenguaje dominante
TypeScript
Estrellas
392
Forks
22
Merge medio
1 d 7 min
PR fusionados (30 d)
203

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de githubnext/chopin

Todos los issues de githubnext/chopin

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.