MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-44

1.4.1 Mockup: issue detail view + tree view + create modal (data-only surface for 1.4 verification)

Done
Description

Estimate: 25m · Depends on: 1.0.5.2

Produce viewable mockups of the three surfaces Epic 2 will build on top of Story 1.4's data layer — the issue detail view, the issue tree view (parent → children), and the issue create modal — before Epic 2 starts. Per Principle #13 (design-before-code, within every Story), and per notes.html mistake #4: design Subtasks are flat peers, not deferred to feature Stories. Even though 1.4 itself ships no UI, the detail-view shape is the contract Epic 2's UI Subtasks read; landing it here keeps Epic 2 free to focus on routes + state, not also visual decisions.

Why now (vs. punting to Epic 2): Story 1.4's acceptance criteria commit to specific fields (priority, assignee, dueDate, estimateMinutes, descriptionMd, explanationMd, explanationSource). The detail-view mockup pressure-tests whether those fields hold up as user-visible shape — especially the description-vs-explanation split (do they read as obviously different concepts? does the AI-drafted badge clutter or clarify?) and the explanation-source state visuals. If the mockup reveals a missing field (e.g. labels being too painful to defer) or that explanation badging needs a separate dismissible-notice pattern, it lands in the schema NOW, not as a destructive Epic 5 migration later. Design discovery preceding schema commit is the same load-bearing pattern Story 1.1's 1.1.1 design Subtask used.

What you'll do: Open @pencil.dev/cli (per feedback_pencil_cli_for_design_subtasks — the desktop MCP has no save(); CLI does). Compose with the canonical primitives only — Button, Input, Textarea, Select, Card, Avatar, Badge from components/ui/. Lay out:

  • Detail view (/design/work-items/detail.pen): two-column layout, left = title + description (Markdown-rendered, section heading "Description — what to do") + explanation (Markdown-rendered, section heading "Explanation — why this matters", collapsed by default for technical users / expanded by default for non-technical users — design a subtle toggle) + activity placeholder (sized to host Epic 5's comments later), right = sidebar with status pill, priority pill, assignee Avatar+name + change button, reporter line, due date, estimate, parent breadcrumb, identifier (PROD-42) at the top, archive button at the bottom of the sidebar. Linear-style information density — every field visible without scrolling on a 1280px viewport. Explanation section affordances: (a) when explanationMd is NULL, show a "Draft explanation with AI" CTA button + a "Write manually" link as fallback; (b) when explanationSource = ai_draft, surface a subtle pill above the rendered Markdown ("AI-drafted — review me") + an "Edit" affordance that opens the editor (the act of editing transitions the source to user_edited per the service-layer state machine); (c) when user_edited or user_authored, no badge — looks like any user-written field; (d) a "Regenerate with AI" link is always available once content exists (overwrites the column, prior text retrievable from revision history).
  • Tree view (/design/work-items/tree.pen): indented list of work_items, each row showing kind icon (epic/story/task/bug/subtask) + identifier + title + assignee Avatar + status Badge. Twisty-arrow for collapse. Drag-handle indicator on hover (Epic 3's board work consumes this affordance). Empty state for new projects.
  • Create modal (/design/work-items/create.pen): Dialog with title input, kind Select (epic/story/task/bug — subtask creates via the "Add subtask" affordance on a parent's detail view, not the top-level create modal), parent Select (lazy-search, filtered by allowed-children rule — disabled-with-tooltip for illegal pairs), assignee Select, priority Select with medium pre-selected, description Markdown editor (with the editor's live-preview toggle in the corner — same component used by the detail view), Cancel / Create buttons. No explanation field in the create modal — explanation is drafted post-create on the detail page (either AI-assist or manual). Rationale: cluttering the create modal with an "explanation" textarea trains users to skip it; deferring to the detail-page CTA puts AI-assist front and center where it gets used.

Save .pen sources AND PNG exports for each surface. Update /docs/design-system.md if the mockups surface a new pattern (none expected — composition only).

Acceptance criteria

  • Three .pen files exist under /design/work-items/ with PNG exports alongside.
  • Detail view shows all v1.4 schema fields (identifier, title, descriptionMd, explanationMd, explanationSource state, status, priority, assigneeId, reporterId, dueDate, estimateMinutes, parentId, archivedAt-state).
  • Description and explanation sections are visually distinct on the detail view (clear "Description — what to do" / "Explanation — why this matters" labels; the explanation section's prose styling reads as long-form context vs. description's actionable spec). A non-technical reviewer looking at the mockup should be able to tell, without prompting, which field tells them WHAT and which tells them WHY.
  • Detail-view explanation section renders THREE states: (a) empty — "Draft explanation with AI" CTA + manual fallback link; (b) ai_draft — Markdown content with the "AI-drafted — review me" pill above it + Edit affordance; (c) user_authored / user_edited — Markdown content with no badge, just an Edit pencil and a subtle "Regenerate with AI" link. All three rendered in the .pen file.
  • Tree view shows kind icon + identifier + title + assignee Avatar + status Badge per row; supports indentation up to the depth-4 limit visually.
  • Create modal has description editor but NO explanation field (explanation drafted post-create on detail page).
  • Create modal's parent Select demonstrates the allowed-children rule (illegal parents are disabled with a tooltip explaining why).
  • All surfaces compose only existing primitives — no new design tokens or component shapes introduced.
  • The mockups reveal no missing v1 schema fields (or, if they do, the Subtask raises a finding in PRODECT_FINDINGS.md before merging — per notes.html mistake #27).
  • Mockups respect the brand-mark deferral principle — no wordmark / logomark anywhere on these surfaces (per MOTIR.md decision).

Context refs

  • /docs/design-system.md — canonical visual reference
  • /components/ui/Button.tsx, Input.tsx, Textarea.tsx, Select.tsx, Card.tsx, Avatar.tsx, Badge.tsx, Dialog.tsx — primitives to compose from
  • /design/workspaces/settings.pen from Subtask 1.2.1 — the visual grammar for two-column layouts with a sidebar (the detail view mirrors this shape)
  • /design/projects/*.pen from Subtask 1.3.3 — the tree-view affordances Story 1.3 established
  • MOTIR.md — brand-mark deferral principle, design-system tokens
  • This Story page (Story 1.4) — the schema fields the detail view must surface