Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Design] Redesign research components

オープン
#164 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
bun, typescript
領域
design, frontend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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-content currently 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 types
  • bun run ci
  • bun test packages/editor
  • bun 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.
主要言語
TypeScript
スター
351
フォーク
20
平均マージ
1日 34分
マージ済み PR(30日)
34

環境構築

このプロジェクトの環境構築ファイルはまだ確認していません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

githubnext/chopin のほかの issue

githubnext/chopin の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。