2.4.15 Design — Sprint field on the detail core-fields rail + 'Add to active sprint' in the ⋯ actions menu
Design prerequisite for code subtask 2.4.14 (MOTIR-1003) — Sprint inline-edit field on the work-item detail + 'Add to active sprint' ⋯-menu action. The design gate fires: both additions land on ALREADY-DESIGNED surfaces (detail.pen core-fields rail + delete-confirm.mock.html ⋯ menu) that do NOT currently include them, so they are undesigned elements — NOT mere grammar reuse. This mirrors how custom fields on the same rail (5.3.5 → 5.3.7) required their own design asset (custom-fields.mock.html) even though they reused FieldCard + Combobox verbatim.
Produce the THREE-file design asset set under design/work-items/ (a *.mock.html built from the real design system + a same-basename .png export + an update to design-notes.md), covering BOTH elements. DRAW THE ACCESS PATH for each — show the entry affordance in context (the field's place in the rail; the menu item open in the ⋯ menu), not just the destination.
What must be designed
1. Sprint FieldCard on the detail core-fields rail (CoreFieldsPanel)
The shipped rail built-ins are Status · Assignee · Reporter · Priority · Due · Estimate · Parent (detail.pen); there is NO Sprint field. Decide:
- Placement among the built-ins (Sprint is an agile-planning field — near Parent? after Estimate, before the custom-fields block? its own position). Built-ins never reorder, so fix where Sprint inserts.
- Value-line rendering — sprint NAME plain, or a Pill? How the no-sprint / Backlog state reads (the rail's muted-italic
Nonegrammar, or an explicit 'Backlog'?). Whether the sprint's lifecycle state (planned/active/complete) is indicated. - The inline picker — the shipped
Combobox(the AssigneePicker-shaped composition): the sentinel row. The filter'ssprint-selectputs a Backlog sentinel FIRST; the AssigneePicker puts None/Unset first. Pick one and state it. Searchable threshold (the ≥8-options Combobox rule).
2. 'Add to active sprint' in the ⋯ WorkItemActionsMenu
The shipped menu (Story 2.8/2.9, delete-confirm.mock.html) has a FIXED item set — Edit details · Copy link · — · Archive · Delete… — with no Sprint action, and is IDENTICAL across detail header / list rows / board cards. Decide:
- Placement / order / icon / label of the new row, and which group it joins (a new section above the Archive/Delete separator?).
- ⚠️ Grammar conflict to resolve: the card asks to 'grey it out / disable + tooltip when there is no active sprint', but the menu's established law is permission-gated rows are HIDDEN, never shown-disabled (
WorkItemActionsMenusource comment). A no-active-sprint state is a STATE gate, not a permission gate — decide whether disabled+tooltip is the right deviation here (and document why) or whether to hide it. Check the mirror (Jira/Linear 'Add to sprint' behaviour) at rung 1. - Whether this row appears on the list-row/board-card instances too (the menu is shared) or only on the detail header.
Acceptance criteria
design/work-items/<basename>.mock.html+<basename>.png+ adesign-notes.mdsection, covering both elements with every state (field populated / Backlog / editing; menu item enabled / disabled-or-hidden no-active-sprint).- The access path is DRAWN: Sprint field shown in its rail position; the menu item shown open in the ⋯ menu in context.
- The disabled-vs-hidden grammar decision is stated with its rationale (rung-1 mirror check cited).
- The sentinel + value-line + placement decisions are explicit, so 2.4.14 builds with zero improvisation.
Context refs
design/work-items/detail.pen(rail) ·design/work-items/delete-confirm.mock.html(the ⋯ menu) ·design/work-items/custom-fields.mock.html(the new-rail-field precedent) ·design/work-items/design-notes.mdapp/(authed)/issues/[key]/_components/CoreFieldsPanel.tsx+FieldCard.tsx(the rail) ·components/issues/actions/WorkItemActionsMenu.tsx(the menu, + its hide-never-disable comment) ·components/issues/AssigneePicker.tsx+components/ui/Combobox.tsx- Blocks 2.4.14 (MOTIR-1003).