# Boardly — Website Relaunch board

Build the Kanban board view of **Boardly**, a fictional project-management
tool for small product teams. The board belongs to the workspace
**Harbor Studio** and tracks its **Website Relaunch** project.

## Product

- **Name:** Boardly.
- **Feel:** focused, calm, fast. A tool people keep open all day: dense
  enough to see the whole project, quiet enough not to tire the eyes.
- **You own the visual identity.** Design the Boardly wordmark/logo, color
  palette, type scale, label colors, member avatars, icons, and layout
  yourself; nothing is prescribed. Any graphics you need must be created in
  this workspace (inline SVG or CSS). There is no supplied photography.
- **Microcopy is part of the task.** Write all interface copy yourself:
  empty states, validation messages, confirmations, screen-reader
  announcements, and the explanation shown when a column limit blocks a move.

## Data

- `public/data/board.json`: workspace and board names, the fixed date
  `today`, labels, priorities, columns in order (with an optional
  `wip_limit`), each column's ordered `card_ids`, and all cards.
- `public/data/members.json`: the team members cards can be assigned to.

Use the supplied data as the initial board state. Do not add, remove, or
rename supplied cards, columns, members, or labels in the initial state.

**Dates:** treat `today` from `board.json` as the current date, not the
system clock. A card is **overdue** when its due date is before `today` and
it is not in the Done column. A card due on `today` is not overdue.

## Board view

One application screen with:

1. **App frame** — the Boardly wordmark you design, the workspace name, and
   the board name.
2. **Board** — all five columns in the supplied order, each showing its
   title, its card count, and its cards in the supplied order. Columns with a
   `wip_limit` show the limit next to the count.
3. **Cards** — each card shows its title, labels, assignee (or a clear
   unassigned state), due date, an overdue indication when overdue, and
   checklist progress (for example 2/4) when it has checklist items.
4. **Filter bar** — filter by assignee and by label, plus a text search over
   card titles and descriptions. Filters combine; column counts reflect the
   visible cards. Show an empty state when nothing matches, and offer a way
   to clear all filters.
5. **Fictional notice** — the note “Boardly is a fictional product created
   for UIBenchmark.” (verbatim, must be visible).

## Interactions

- **Drag and drop with a pointer.** Move cards between columns and reorder
  them within a column; the card lands where it was dropped. Show clear
  feedback while dragging (for example a placeholder at the drop position).
  No drag-and-drop library is installed and none may be added: build it with
  React and browser APIs.
- **Keyboard moves.** A focused card can be picked up, moved within its
  column or to an adjacent column with arrow keys, dropped, or cancelled with
  Escape, which restores its original position. Announce pick-up, each move,
  drop, and cancel through a live region.
- **Move without dragging.** Every card can also be moved to another column
  through a visible control (your choice of pattern). This must work at
  mobile width, where dragging is not required.
- **Column limit.** A move or new card that would exceed a column's
  `wip_limit` is blocked, whichever way it is attempted, and the interface
  explains why.
- **Card details.** Opening a card (pointer or Enter) shows a dialog with all
  of its fields. Title, description, assignee, and checklist items (done or
  not done) are editable there, and the board reflects the changes. An empty
  title is rejected with a visible message. The dialog keeps focus inside,
  closes with Escape, and returns focus to the card.
- **Create and delete.** Add a card to any column; the title is required.
  Delete a card only after a confirmation step.
- **Undo.** The most recent move, creation, or deletion can be undone
  through a visible control and with Ctrl+Z / Cmd+Z (outside text fields).
- **Persistence.** The board state survives a page reload using local
  storage. A “reset demo” action restores the supplied initial state.

## Constraints

- Responsive at 1440×900 (desktop) and 390×844 (mobile). At mobile width the
  document must not overflow horizontally; the board may scroll inside its
  own region, and every column must remain reachable.
- Respect reduced-motion preferences for any animation you add.
- No external network requests, fonts, or images. System font stack only.

See `BENCHMARK_RULES.md` for binding rules and `REQUIREMENTS.json` for the
behaviors that will be evaluated.

# Benchmark rules (shared, v3)

These rules are binding and identical for every Configuration.

## Allowed

- The supplied starter, images, data files, and installed dependencies.
- Additional graphics you create yourself inside this workspace (inline SVG,
  CSS art, or authored SVG files).
- Local development preview while working.
- Building, testing, and correcting your implementation before completion.

## Required

- Browser-compatible production output under `dist/` via the starter's build
  script, deployable at a hostname root.
- Implement required interactions as working behavior.
- Responsive behavior at 1440×900 and 390×844.
- Keep demo state in memory or origin-scoped local storage; no cookies.
- Required forms, if any, simulate behavior locally and never transmit data.
- All navigation stays within the demo.

## Prohibited

- Modifying `BENCHMARK_RULES.md`, `PROMPT.md`, `REQUIREMENTS.json`,
  `AGENTS.md`, `CLAUDE.md`, or the dependency lockfile.
- Delegating any part of the work to subagents, sub-sessions, or spawned
  agent tasks; complete the task in this single session.
- Adding, removing, or updating dependencies.
- External network resources of any kind: requests, fonts, images, embeds,
  analytics, service workers, or background requests.
- Researching on the web while you work: searching the web or fetching web
  pages or online documentation.
- Generating images with an image-generation tool or model.
- Backend services, databases, credentials, payments, or personal data.
- Deploying the result or accessing deployment credentials.

## Completion

Before declaring completion, run the production build. In your final response,
state whether it succeeded and identify any incomplete requirements.