mirror of
https://github.com/rennf93/roboco.git
synced 2026-08-03 07:23:24 +02:00
[3dfc43a1] Task detail overhaul: markdown, navigation, collapsible sections, timestamps (#410)
* [35a27c3d] UX/UI: design task-detail overhaul (#404) * [39ea1900] docs(ux_ui): add content-readability spec for markdown, collapsible sections, timestamps (#388) Co-authored-by: UX/UI Developer 1 <ux-dev-1@roboco.tech> * [71f9aec6] docs(ux_ui): add task navigation/structure design spec (#400) Adds docs/ux_ui/design/task-navigation-structure.md covering the breadcrumb trail, prev/next sibling navigation, and a distinct visual treatment for the read-only constraints section, grounded in the real task-detail components and existing amber/Lock read-only tokens. Co-authored-by: UX/UI Developer 2 <ux-dev-2@roboco.tech> --------- Co-authored-by: UX/UI Developer 1 <ux-dev-1@roboco.tech> Co-authored-by: UX/UI Developer 2 <ux-dev-2@roboco.tech> * [9baa1c34] Frontend: implement task-detail overhaul (#408) * [13b6c723] Task detail: inline timestamps + breadcrumb + prev/next navigation (#390) * [13b6c723] feat(panel): add inline absolute timestamps, task breadcrumb, and prev/next list nav to task detail Adds a shared formatAbsoluteTimestamp helper used inline (with tooltip) next to relative time on progress updates and checkpoints in tab-progress.tsx, progress-timeline.tsx, and checkpoint-card.tsx. Adds TaskBreadcrumb (renders only when task.parent_task_id is set) and TaskListNav, which reads a new taskListNav context in the scroll-restoration zustand store — populated by the Tasks list page from TaskTable's live filtered/sorted order — to move to the adjacent task. When no list context exists for the session or the current task isn't part of the captured order, both nav buttons render disabled with an explanatory tooltip (the documented fallback). * [13b6c723] docs(guide): task detail navigation, timestamps, breadcrumb, and prev/next behavior --------- Co-authored-by: Frontend Developer 2 <fe-dev-2@roboco.tech> Co-authored-by: Frontend Documenter <fe-doc@roboco.tech> * [40acdd31] Task detail: collapsible markdown sections + distinct Constraints styling (#407) * [40acdd31] feat(panel): collapsible task-detail sections + distinct Constraints styling Wrap the Description, per-field Notes, and Plan cards in a new CollapsibleSection (Radix Collapsible + tw-animate-css fade/slide, so collapse/expand only animates opacity/transform) so a long task no longer forces continuous scrolling. Restyle the read-only Constraints card with an amber accent border, background tint, and ShieldAlert icon so it reads as distinct from authored content. Existing edit/preview toggles are force-open while active and otherwise unchanged. Adds a global prefers-reduced-motion override in globals.css. * [40acdd31] docs(panel): CollapsibleSection component API and usage guide Documents the new CollapsibleSection wrapper component used for independent collapse/expand of task-detail sections (Description, Constraints, Notes, Plan). Covers component API, controlled vs. uncontrolled state patterns, animation behavior (fade+slide, transform/opacity only), prefers-reduced-motion handling, and usage examples across task-description.tsx / tab-notes.tsx / tab-plan.tsx. --------- Co-authored-by: Frontend Developer 1 <fe-dev-1@roboco.tech> Co-authored-by: Frontend Documenter <fe-doc@roboco.tech> * [73f8311f] fix(task-table): remove exhaustive-deps suppression on visible-order effect (#409) Co-authored-by: Frontend Developer 1 <fe-dev-1@roboco.tech> --------- Co-authored-by: Frontend Developer 2 <fe-dev-2@roboco.tech> Co-authored-by: Frontend Documenter <fe-doc@roboco.tech> Co-authored-by: Frontend Developer 1 <fe-dev-1@roboco.tech> * [eb417ef1] Fix: apply auto-collapse thresholds to Progress and Acceptance Criteria surfaces (#429) * [4e855d24] Apply content-readability-spec collapse thresholds to Progress and Acceptance Criteria surfaces (#416) * [4e855d24] feat(task-detail): auto-collapse long progress/checkpoint/AC content per readability spec * [4e855d24] refactor(task-detail): remove inline JSX section-marker comments per no-inline-comments convention * [4e855d24] docs(task-detail): document content-readability-spec collapse thresholds for CollapsibleSection --------- Co-authored-by: Frontend Developer 1 <fe-dev-1@roboco.tech> Co-authored-by: Frontend Developer 2 <fe-dev-2@roboco.tech> Co-authored-by: Frontend Documenter <fe-doc@roboco.tech> * [3c90ef34] Wire content-readability thresholds into CollapsibleSection, tab-progress, acceptance-criteria (#430) * [3c90ef34] test(task-detail): add AC4 combined readability test — 30+ progress entries + long acceptance-criteria list * [3c90ef34] docs: enhance content-readability thresholds documentation and code comments - Enhance panel/src/lib/content-readability.ts with usage examples and clarified intent - Enhance CollapsibleSection with auto-collapse logic explanation and precedence rules - Enhance TabProgress's RECENT_OPEN_COUNT logic with dual-threshold explanation - Add comprehensive architecture guide: panel/docs/CONTENT_READABILITY_THRESHOLDS.md covering thresholds, components, testing, and implementation notes The readability feature prevents long-history tasks (30+ updates, 20+ criteria) from rendering fully expanded, keeping pages navigable. Tests confirm 32 progress updates default to 2 open, and long criteria lists collapse while short ones stay expanded. --------- Co-authored-by: Frontend Developer 2 <fe-dev-2@roboco.tech> Co-authored-by: Frontend Documenter <fe-doc@roboco.tech> --------- Co-authored-by: Frontend Developer 1 <fe-dev-1@roboco.tech> Co-authored-by: Frontend Developer 2 <fe-dev-2@roboco.tech> Co-authored-by: Frontend Documenter <fe-doc@roboco.tech> * [fc04d84a] Round-3 revision: fix 4 named gaps on task-detail overhaul, one dev leaf per fix (#455) * [cac9b603] fix(panel): fall back to task.created_at for missing written_at stamp in tab-notes.tsx (#446) Co-authored-by: Frontend Developer 2 <fe-dev-2@roboco.tech> * [31dd4f99] Remove ArrowLeft back button from task-header.tsx (#441) * [31dd4f99] Remove ArrowLeft back button and Link wrapper from task-header.tsx, drop now-unused imports * [31dd4f99] docs(task-navigation): mark spec as implemented, clarify ArrowLeft button removal Update task-navigation-structure.md to reflect v0.21.0+ implementation: - Status changed from "proposed" to "implemented" - Clarified that ArrowLeft back button was removed from task-header.tsx - Noted that breadcrumb and prev/next navigation now provide all navigation - Constraints section styling with amber tint and ShieldAlert icon is complete - Referenced related guide documentation for task-detail-navigation features --------- Co-authored-by: Frontend Developer 2 <fe-dev-2@roboco.tech> Co-authored-by: Frontend Documenter <fe-doc@roboco.tech> * [75fd7444] Wire content prop into EditableNoteCard's CollapsibleSection (#449) * [75fd7444] feat(panel): wire content prop into EditableNoteCard's CollapsibleSection Pass the note field's current value into CollapsibleSection's content prop and derive EditableNoteCard's initial sectionOpen state from exceedsReadabilityThreshold, so long notes default collapsed with an expand affordance while short notes render fully expanded. * [75fd7444] docs(panel): document EditableNoteCard's content-driven collapse pattern in collapsible-section.md Updated docs/frontend/components/collapsible-section.md to reflect how EditableNoteCard in tab-notes.tsx uses both controlled mode (force-open while editing) and content-driven initialization (seed sectionOpen from content length). Added a new "Combined: controlled + content-driven initialization" example showing this pattern for future developers extending editable-content sections. Pattern: long notes default collapsed with expand affordance, short notes default expanded, edit forms always visible during editing. --------- Co-authored-by: Frontend Developer 1 <fe-dev-1@roboco.tech> Co-authored-by: Frontend Documenter <fe-doc@roboco.tech> * [18ada610] docs(ux-ui): reconcile prev/next nav design spec with shipped list-order behavior (#453) Co-authored-by: Frontend Developer 2 <fe-dev-2@roboco.tech> --------- Co-authored-by: Frontend Developer 2 <fe-dev-2@roboco.tech> Co-authored-by: Frontend Documenter <fe-doc@roboco.tech> Co-authored-by: Frontend Developer 1 <fe-dev-1@roboco.tech> * [3dfc43a1] round-3 fixes: reconcile nav spec, Alt+Arrow shortcuts, CHANGELOG The breadcrumb section of task-navigation-structure.md now describes the shipped single-ancestor design (and drops the stale DropdownMenu claims); Alt+ArrowLeft/Right on TaskListNav mirror the visible prev/next buttons, suppressed while an editable element has focus, with tests; the user-facing CHANGELOG entry lands under Unreleased. Also reflows the round-1 content-readability-spec so the prose gate is green branch-wide. * [3dfc43a1] blank line between Unreleased and 0.22.0 sections --------- Co-authored-by: UX/UI Developer 1 <ux-dev-1@roboco.tech> Co-authored-by: UX/UI Developer 2 <ux-dev-2@roboco.tech> Co-authored-by: Frontend Developer 2 <fe-dev-2@roboco.tech> Co-authored-by: Frontend Documenter <fe-doc@roboco.tech> Co-authored-by: Frontend Developer 1 <fe-dev-1@roboco.tech> Co-authored-by: Renn F <rennf93@users.noreply.github.com>
This commit is contained in:
Renzo F
co-authored by
UX/UI Developer 1
UX/UI Developer 2
Frontend Developer 2
Frontend Documenter
Frontend Developer 1
Renn F
UX/UI Developer 1
UX/UI Developer 2
Frontend Developer 2
Frontend Documenter
Frontend Developer 1
Renn F
parent
f0f09b2204
commit
eefaca1d3b
@@ -0,0 +1,80 @@
|
||||
# Content-readability spec: markdown, collapsible sections, timestamps
|
||||
|
||||
Status: proposed Owner: ux-dev-1 Surface: task detail panel (`panel/src/components/tasks/task-detail/`) and any other view that renders task-authored markdown or an activity/notes feed (journals, A2A transcript).
|
||||
|
||||
## Dial read
|
||||
|
||||
Per the team design bar, this is dense product UI (task detail / admin panel), not a marketing surface:
|
||||
|
||||
- **DESIGN_VARIANCE:** 2 — predictable, symmetric card layout. Collapsing content changes height, not position; no asymmetric grid.
|
||||
- **MOTION_INTENSITY:** 2 — a single `transform`/`opacity`/`grid-template-rows` expand-collapse transition on the section body, nothing else animates.
|
||||
- **VISUAL_DENSITY:** 8 — tight padding, no added chrome beyond what already exists in `Card`, tabular timestamps in list contexts.
|
||||
|
||||
## Problem
|
||||
|
||||
Long task bodies (descriptions, dev/QA/PR-reviewer notes, journal entries) render in full with no way to collapse them, so a task with a large plan or a long QA note pushes the rest of the tab below the fold — this is the "scrolling fatigue" the acceptance criteria name. Separately, the panel currently renders timestamps three different ways depending on which component you're looking at:
|
||||
|
||||
| Component | Format | Example |
|
||||
|---|---|---|
|
||||
| `progress-timeline.tsx` `formatTime()` | relative bucket, falls back to short absolute past 7 days | `"3h ago"` / `"Jul 3, 02:14 PM"` |
|
||||
| `tab-notes.tsx` `writtenAt()` | always absolute, no time-of-day granularity beyond minutes | `"Jul 10, 04:41 AM"` |
|
||||
| `a2a-transcript.tsx` | `date-fns` `formatDistanceToNow`, always relative, no absolute fallback | `"3 hours ago"` |
|
||||
|
||||
Three renderers means three different date-math implementations to keep correct and three different reading experiences in the same activity feed. This spec fixes both problems without introducing a new dependency — `date-fns` is already installed and used by `a2a-transcript.tsx`.
|
||||
|
||||
## 1. Collapsible-section pattern
|
||||
|
||||
Use the existing Radix wrapper (`panel/src/components/ui/collapsible.tsx`, `Collapsible`/`CollapsibleTrigger`/`CollapsibleContent`) — do not add a new library or hand-roll a `useState` show/hide toggle for this; the primitive already handles the `data-state`/animation attributes lint components key off.
|
||||
|
||||
**Trigger condition.** A markdown body collapses when its rendered content would exceed **~10 lines or ~640 characters of source markdown**, whichever comes first — measured on the raw markdown string before render, not the rendered DOM height, so the decision is synchronous and doesn't require a layout pass. Content under that threshold renders inline with no trigger/affordance at all (a collapse control on a 2-line note is chrome for its own sake).
|
||||
|
||||
**Default state by field, not a single global rule** — a reader's expectation of "do I need this right now" differs per field:
|
||||
|
||||
| Field / feed | Default state | Rationale |
|
||||
|---|---|---|
|
||||
| Task `description` | **open** | The task's own brief — the reason the reader opened the task. |
|
||||
| `dev_notes` / `qa_notes` / `pr_reviewer_notes` / `auditor_notes` / `doc_notes` | **collapsed** if over threshold | Historical record; opened on demand while triaging or auditing, not on first load. |
|
||||
| `quick_context` (resumption) | **open** | Explicitly the field a resuming agent/PM needs first. |
|
||||
| Progress-timeline / journal entries (list items) | **collapsed**, most recent 2 entries **open** | Matches "activity feed" convention — recent items visible, older ones summarized. |
|
||||
| Task `constraints` | **collapsed** | Read-only, project-wide, rarely the thing a reader is here for. |
|
||||
|
||||
**Affordance.** The `CollapsibleTrigger` wraps a text button reading `Show more (N lines)` / `Show less`, right-aligned in the existing `CardHeader` row those components already use (see `tab-notes.tsx`'s header `flex items-center justify-between`) — no new header layout. Use a `ChevronDown` (`lucide-react`, already a dependency) that rotates 180° on open via `data-[state=open]:rotate-180 transition-transform`, matching the `MOTION_INTENSITY: 2` budget (transform only, no scroll listener).
|
||||
|
||||
**Persistence.** Collapse state is component-local (`useState`), not persisted to the task record or localStorage — a reader re-opening the tab should see the field-default state again, not their last session's toggle. This keeps the change purely presentational with zero backend/schema touch.
|
||||
|
||||
**Accessibility.** `CollapsibleTrigger` already renders `aria-expanded` via the Radix primitive; keep the visible label text in sync with that state (`"Show more"` / `"Show less"`, not just an icon) so screen readers get the same information sighted users do.
|
||||
|
||||
## 2. Markdown rendering treatment
|
||||
|
||||
The existing `Markdown` component (`panel/src/components/ui/markdown.tsx`) already defines the full token set — this spec does not introduce a second markdown renderer or a competing prose scale. It formalizes which of its two existing modes (`compact` vs. default) each surface should use, since that choice is currently made ad hoc per call site:
|
||||
|
||||
- **Default mode** (`prose-headings:font-bold`, `h1` 2xl / `h2` xl with a bottom border / `h3` lg / `h4` base, `prose-pre:bg-muted prose-pre:border prose-pre:rounded-lg`) is for content the reader is reading top-to-bottom as a document: task `description`, `dev_notes`/`qa_notes`/etc. bodies, journal entries, constraints.
|
||||
- **`compact` mode** (uniform `text-xs` headings, hidden `pre` blocks, tight list/paragraph spacing) is for anything rendered inside a list row or card summary where markdown is secondary to the surrounding metadata — e.g. a one-line progress-update message or an A2A transcript bubble. Do not disable `compact`'s `prose-pre:hidden` for these contexts: a code block inside a chat bubble already breaks density, and this spec's threshold-based collapse (§1) is the mechanism for anyone who needs the full content, not an inline fenced-block render.
|
||||
- **Code blocks** (default mode only, since `compact` hides them): rely on the existing `prose-pre:bg-muted prose-pre:border prose-pre:rounded-lg` plus inline-code's `prose-code:bg-muted prose-code:rounded prose-code:font-mono` — this already matches the panel's card/muted tokens, so no new color is introduced. No syntax highlighting — out of scope; a highlighter is a new dependency this spec's content doesn't justify (ponytail: revisit only if a future task specifically needs highlighted diffs/code review inline).
|
||||
- **Lists**: GFM task-list checkboxes already render via the `Checkbox` component when `onCheckboxChange` is supplied (editable contexts: description, notes) and as a plain styled `input[type=checkbox]` otherwise (read-only contexts: journals, PR bodies) — keep that split; do not force every consumer to wire up `onCheckboxChange`.
|
||||
|
||||
No changes to `markdown.tsx`'s Tailwind token classes are proposed — they already satisfy this criterion. What was missing was a documented rule for *which mode a new call site should pick*, captured above.
|
||||
|
||||
## 3. Timestamp presentation format
|
||||
|
||||
**One format, applied everywhere a note or progress/journal entry shows a timestamp:** a relative bucket for anything within the last 7 days, an absolute short date+time beyond that — this is `progress-timeline.tsx`'s existing `formatTime()` behavior, and it becomes the canonical implementation the other two call sites adopt instead of maintaining their own date math:
|
||||
|
||||
```
|
||||
< 1 min "Just now"
|
||||
< 60 min "{n}m ago"
|
||||
< 24 h "{n}h ago"
|
||||
< 7 d "{n}d ago"
|
||||
>= 7 d "Jul 3, 2:14 PM" (Intl "MMM d, h:mm a", locale en-US)
|
||||
```
|
||||
|
||||
**Always-visible absolute timestamp on hover/focus.** Every timestamp element carries a `title` attribute with the full ISO-derived absolute stamp (`"Jul 3, 2026, 2:14:32 PM"`), so a relative bucket never fully hides the precise time — this is a one-line addition to each call site, no new component required beyond the shared formatter.
|
||||
|
||||
**Consolidation, not three rules.** Extract `progress-timeline.tsx`'s `formatTime()` into a shared helper (e.g. `panel/src/lib/format-timestamp.ts`, matching where other date/agent-name helpers already live like `lib/agent-utils.ts`) and have `tab-notes.tsx`'s `writtenAt()` and `a2a-transcript.tsx`'s `formatDistanceToNow(...)` call replaced with it. This removes two of the three divergent implementations rather than adding a fourth. `date-fns` stays a dependency (already used elsewhere in the panel) but this specific formatter does not need it — the bucket math is short enough to stay plain `Date` arithmetic, consistent with `formatTime()`'s current implementation, so `format-timestamp.ts` has no new dependency to justify.
|
||||
|
||||
**Where this applies:** progress updates, journal/note entries in every task-detail tab (`quick_context`/`dev_notes`/`qa_notes`/`pr_reviewer_notes`/ `auditor_notes`/`doc_notes` "written at" stamps), and the A2A transcript. Any future feed showing a note/progress entry should reuse the same helper rather than writing a fourth formatter.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- No new component library or animation dependency — everything above composes `Collapsible`, `Markdown`, and `date-fns`/plain `Date`, all already in the panel's dependency tree.
|
||||
- No change to how markdown is stored or how notes are written (backend, `notes_structured`, gateway verbs) — this is purely a rendering-layer spec.
|
||||
- Syntax highlighting, persisted collapse-state, and a global "collapse all" control are explicitly out of scope for this pass.
|
||||
@@ -0,0 +1,90 @@
|
||||
# Navigation/structure spec: breadcrumb, prev/next, constraints distinction
|
||||
|
||||
Status: implemented (v0.21.0+) Owner: ux-dev-2 Surface: task detail page (`panel/src/app/(dashboard)/tasks/[taskId]/page.tsx`) and its header (`panel/src/components/tasks/task-detail/task-header.tsx`) and description tab (`panel/src/components/tasks/task-detail/task-description.tsx`).
|
||||
|
||||
## Dial read
|
||||
|
||||
Per the team design bar, this is dense product UI (task detail / admin panel):
|
||||
|
||||
- **DESIGN_VARIANCE:** 2 — the breadcrumb and prev/next controls are a predictable single row above the existing header; no new grid or layout shape.
|
||||
- **MOTION_INTENSITY:** 1 — hover/focus states only (existing `Button` / `Link` hover treatment), no transition is introduced.
|
||||
- **VISUAL_DENSITY:** 8 — compact 28px-tall controls that add one row of chrome, nothing more; the constraints card stays a `Card`, not a heavier modal or full-width banner.
|
||||
|
||||
## Problem
|
||||
|
||||
The task detail page currently has no sense of *where this task sits*: the header's only navigation is a single `ArrowLeft` icon button that always goes to `/tasks` (`task-header.tsx` lines 474-479), regardless of whether the task has a parent. A reader drilling into a subtask of a subtask loses the parent chain the moment they land on the page, and moving between sibling tasks (e.g. checking each dev subtask of the same parent while triaging) requires going back to the list and re-finding the next one every time.
|
||||
|
||||
Separately, `task.constraints` (the auto-attached project-wide architectural standard, read-only) renders in `task-description.tsx` as a `Card` with only `border-dashed` and a muted title (lines 181-196) — visually one dash away from the free-form, user-authored `description` card right above it. A reader skimming the page has no fast visual cue that one box is "the project's rule" and the other is "this task's own words."
|
||||
|
||||
This spec is a pure design/markup change: no new dependency, no new backend field (`parent_task_id`, `sequence`, and `project_id` already exist on `Task`; `useTask` and `useSubtasks` already exist in `@/hooks/use-tasks`).
|
||||
|
||||
## 1. Breadcrumb trail
|
||||
|
||||
**Implementation status:** ✓ Complete (v0.21.0+). This diverged from the rich multi-crumb trail originally proposed for this section — see "What shipped" below for the design that actually rendered.
|
||||
|
||||
**Component:** `TaskBreadcrumb` at `panel/src/components/tasks/task-detail/task-breadcrumb.tsx`, rendered in the task detail page (`[taskId]/page.tsx`) above the `TaskHeader` component, replacing the standalone `ArrowLeft` button that was removed from `task-header.tsx`.
|
||||
|
||||
**What shipped.** A single ancestor level, not the multi-crumb trail below: `{Parent title} > {Current title}`. It renders only when `task.parent_task_id` is set — `null` for a root task, so the row is simply absent rather than showing an empty or placeholder crumb. The parent is fetched with one `useTask(parentId)` call (a `Skeleton` covers the loading gap); the parent title is a `Link` to `/tasks/{parent.id}`, truncated with a `title=` tooltip; the current task's own title renders last, non-interactive, in `text-foreground/70`. Separator: `ChevronRight` (`lucide-react`). Deeper ancestry is reached by following the chain up one hop at a time — clicking into the parent shows its own parent, and so on — rather than being flattened into one row.
|
||||
|
||||
**Why not the rich trail.** The proposed `Tasks` crumb existed to carry the back-to-list affordance the standalone `ArrowLeft` button used to own; that's redundant with the persistent sidebar's own "Tasks" nav link (`components/layout/sidebar.tsx`), so dropping it doesn't remove a control, it removes a duplicate. The `{Project name}` crumb and the multi-ancestor walk (a `useTask(parentId)` fetch per generation, collapsing behind a `DropdownMenu` past 3 entries) added fetches and layout branching for a case — chains long enough to need collapsing — that's rare given hierarchies cap at 3 levels per `CLAUDE.md`'s MegaTask section; the one-hop-at-a-time model covers it with a fifth of the markup. Full writeup: `docs/guide/task-detail-navigation.md`.
|
||||
|
||||
**Accessibility.** The row carries `aria-label="Parent task"`; the current-task span is plain non-interactive text, not a focusable element.
|
||||
|
||||
## 2. Prev/next list navigation
|
||||
|
||||
**Implementation status:** ✓ Complete (v0.21.0+). List-context-aware navigation, documented separately in `docs/guide/task-detail-navigation.md`.
|
||||
|
||||
**Component:** `TaskListNav` at `panel/src/components/tasks/task-detail/task-list-nav.tsx`, rendered in the task detail page (`[taskId]/page.tsx`) alongside the breadcrumb — two chevron icon buttons that move to adjacent tasks within the current Tasks list filter/sort context, or disabled when viewed outside the list context.
|
||||
|
||||
**Data & ordering.** This diverged from the original sibling-order proposal during implementation (see `docs/guide/task-detail-navigation.md` for the full writeup) — "adjacent" means the previous/next row in the **Tasks list's last-visited filter/sort order**, not a `parent_task_id` sibling. The Tasks list page (`tasks/page.tsx`) reports its currently visible, filtered/sorted task order to `useScrollRestorationStore.setTaskListNav({ items, queryString })` whenever it changes; `TaskListNav` reads that `taskListNav` context, finds `task.id`'s index in `items`, and derives the prev/next item from `index - 1` / `index + 1`. The context is session-scoped (`sessionStorage` via the existing Zustand `persist` middleware), so it survives navigation within a session but doesn't persist across sessions. `useSubtasks` / `parent_task_id` / `sequence` are not part of this feature — sibling-order navigation, as originally proposed below, was not what shipped.
|
||||
|
||||
**Controls.** Two `Button variant="outline" size="icon"` using `ChevronLeft` / `ChevronRight` (`lucide-react`), each wrapped in a `Tooltip`:
|
||||
|
||||
- **Prev** links (`Link href="/tasks/{id}{queryString}"`) to `items[index - 1]`; **disabled** (not hidden — a disabled control at the boundary communicates "this is the first one," an absent control reads as "there is no prev/next feature here") when the current task is first in the captured list order, or when no list context exists for this session, or when the current task isn't part of the captured order (opened via a direct link, search, or notification instead of from the list).
|
||||
- **Next** mirrors this at `index + 1`, disabled when current is last (or the same no-context/not-in-list cases as Prev).
|
||||
- Each button's tooltip shows the target item's `title` when enabled, or the fixed explanation "Open this task from the Tasks list to enable prev/next navigation within that list's filter/sort order." when disabled — so hovering a disabled button still explains why, rather than looking broken.
|
||||
- The href carries the captured `queryString` (the Tasks list's filters/sort at the time it was visited), so navigating there preserves that view.
|
||||
|
||||
**Keyboard.** ✓ Implemented. `Alt+ArrowLeft` / `Alt+ArrowRight` navigate prev/next exactly as the visible buttons do (same disabled-at-boundary and no-context behavior — the shortcut is a no-op when the corresponding button would be disabled). A `window` `keydown` listener in `TaskListNav` is suppressed whenever the focused element is an `input`, `textarea`, or `contenteditable` node, so it doesn't fight text-field cursor movement.
|
||||
|
||||
**Empty state.** When no list context has been captured this session, or the current task isn't found in the captured `items`, both buttons render disabled with the fallback tooltip above rather than being omitted — consistent with the boundary-disabled treatment, so the control's presence is predictable regardless of which task the reader is on.
|
||||
|
||||
## 3. Constraints visual distinction
|
||||
|
||||
**Implementation status:** ✓ Complete (v0.21.0+). Constraints now render with distinctive amber styling and a ShieldAlert icon.
|
||||
|
||||
**File:** `panel/src/components/tasks/task-detail/task-description.tsx` (lines 181-199).
|
||||
|
||||
**Treatment — amber "read-only architectural" tint, matching the existing convention already used for the *same* concept elsewhere in the panel:** the per-project Conventions tab uses `border-amber-500/40` for its "this is a committed, canonical rule" card (`conventions-tab.tsx` line 412), and `edit-project-dialog.tsx` uses `text-amber-600 dark:text-amber-400` plus a `KeyRound` icon (line 214-215) for the same "system-controlled, read-only" semantic on the git-token field. `task.constraints` is generated from that same `.roboco/conventions.yml` map (per `CLAUDE.md`'s Architectural Conventions Standard section), so reusing that exact token pairing — instead of introducing a new color — makes the same underlying concept look the same everywhere it appears, rather than inventing a fourth "read-only" treatment.
|
||||
|
||||
```tsx
|
||||
<Card className="border-amber-500/40 bg-amber-500/5">
|
||||
<CardHeader className="pb-3">
|
||||
<CardTitle className="text-base flex items-center gap-2 text-amber-700 dark:text-amber-400">
|
||||
<Lock className="h-4 w-4" />
|
||||
Constraints
|
||||
</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent>
|
||||
<p className="text-xs text-muted-foreground mb-3">
|
||||
Architectural standard derived from the project conventions —
|
||||
read-only. Applies to every task in this project.
|
||||
</p>
|
||||
<Markdown>{task.constraints}</Markdown>
|
||||
</CardContent>
|
||||
</Card>
|
||||
```
|
||||
|
||||
- `Lock` (`lucide-react`, already a project dependency — no new icon package) replaces no icon at all today, signaling "not editable" at a glance before the reader even reads the label — the `description` card above it has an `Edit3` pencil in its header for the opposite reason (it IS editable), so the two icons now read as a matched pair of opposite affordances.
|
||||
- `bg-amber-500/5` is a barely-there tint (5% opacity) — enough to differentiate the card body from the plain-white `description` card above without competing with it or reading as a warning/error state (which would call for `destructive`/red, wrong semantic here — this is informational, not an alert).
|
||||
- The header text and icon both take `text-amber-700 dark:text-amber-400` (matching `edit-project-dialog.tsx`'s exact light/dark pair) instead of the current plain `text-muted-foreground`, so the section title itself carries the distinction, not just the border.
|
||||
- The explanatory caption paragraph (already present, unchanged) stays `text-muted-foreground` — only the card chrome and heading change color; body copy stays neutral for readability.
|
||||
|
||||
**Placement.** Unchanged — still renders directly below the `description` `Card` in the Overview tab, so the reading order (task's own words, then the project-wide rule) is preserved; only the visual weight changes.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- No new shadcn/ui primitive (no `breadcrumb.tsx` added to `components/ui`) — the breadcrumb composes existing `Link`, `Skeleton`, and `lucide-react` icons already in the tree, per the "fewest files" bar.
|
||||
- No change to how ancestors are fetched server-side — the breadcrumb reuses `useTask` exactly as it exists today; no new endpoint, no new query param. Prev/next reuses the Tasks list's already-fetched page data instead of a dedicated sibling endpoint.
|
||||
- No persisted "last visited sibling" or breadcrumb history — this is a point-in-time structural view of the current task's position, not a session/browsing-history feature.
|
||||
- No persisted keyboard-shortcut preference (e.g. a toggle to disable `Alt+Arrow`) — the shortcut always mirrors whatever the visible buttons currently allow.
|
||||
Reference in New Issue
Block a user