[Design] Redesign research components
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
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- bun, typescript
Línea de trabajo
Start at /design-audit#authored-content and inspect the research composer and SidecarCard-based lifecycle cards in packages/editor. Use the stated lifecycle stages and acceptance criteria to create the lifecycle state matrix, then verify with bun run types, bun run ci, bun test packages/editor, and bun run e2e. Done includes Maggie-approved specimens, screenshots at normal and narrow widths, reduced-motion and keyboard evidence, and confirmation that identity and publication semantics are unchanged.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Base branch: main
Branch: maggie/redesign-research-components
Depends on: None
Goal
Redesign the complete research request family so entry, progress, failure, cancellation, and ready states feel like one polished workflow.
Context From Planning
- Every research component in
/design-audit#authored-contentcurrently feels underdesigned and needs a dedicated pass. - Research requests are inline durable cards, not standalone channels. Their identity survives failure, cancellation, and retry.
- This is a human-reviewed design task; lifecycle semantics are already established and must be preserved.
Current Behavior
The research composer and SidecarCard-based lifecycle cards expose the necessary data and actions but have weak hierarchy, inconsistent action placement, and little visual continuity between queued, searching, analyzing, writing, publishing, failed, cancelled, and ready states.
Desired Behavior
Create a cohesive research composer and lifecycle-card family with clear progress, source/report metadata, calm loading states, legible recovery actions, and strong continuity from request to child document.
Acceptance Criteria
- The audit covers composer empty/drafted/submitting/blocked/error states and every durable request stage: queued, searching, analyzing, writing, publishing, failed, cancelled, and ready.
- State changes retain a stable card identity and do not visually imply a new request on retry.
- Cancel, retry, remove, and open-child actions have consistent placement and hierarchy appropriate to each stage.
- Ready state clearly presents title, summary, source count, Planner provenance, and navigation to the ordinary child document.
- Loading/progress treatment respects reduced motion and does not rely on animation alone.
- Existing persistence-before-publication, observational-read, retry, cancellation, and child-publication behavior remains unchanged.
- Maggie approves the audit specimens before production migration.
Verification Commands
bun run typesbun run cibun test packages/editorbun run e2e
Primary Surfaces
/design-audit#authored-content- Research composer and lifecycle cards in
packages/editor - Parent document research request and child-document navigation
Expected PR Checks
- Repo required checks
Report Requirements
- Complete lifecycle state matrix
- Before/after screenshots at normal and narrow widths
- Reduced-motion and keyboard evidence
- Confirmation that request identity and publication semantics are unchanged
Implementation Notes
- A pending request remains an inline card with no URL, sidebar row, Conversation, or Decisions.
- Failure, cancellation, and retry preserve request identity; reads must not restart terminal work.
- Publication remains idempotent and persistent before the ready card or navigation row appears.
Stop Conditions
- The design implies a new product workflow such as standalone research workspaces or grandchildren.
- A visual change requires altering durable lifecycle or publication ordering.
- 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
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de githubnext/chopin
-
documentation triage/human-response
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
githubnext/chopin#149 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
enhancement triage/human-response
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
githubnext/chopin#203 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
[Design] Style Mermaid diagramsAbiertoenhancement triage/human-response
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
githubnext/chopin#165 ·
Los mantenedores suelen responder en 1 día
-
triage/human-response
Dificultad 5/5 Más de una semana Aptitud para principiantes 38/100
githubnext/chopin#163 ·
Los mantenedores suelen responder en 1 día
-
triage/human-response
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
githubnext/chopin#162 ·
Los mantenedores suelen responder en 1 día
Todos los issues de githubnext/chopin
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
cameri/nostream#811 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug p3 triaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
bug javascript P2-medium python release:v3.1
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
adrirubio/claude-deck#546 ·
Los mantenedores suelen responder en 1 día
-
area: desktop area: website priority: P2 type: feature
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
appandflow/stim#3411 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
rjsf-team/react-jsonschema-form#5485 ·
Los mantenedores suelen responder en 2 días