Skip to content
← All starter build updates

Productivity starter

Drift

A lightweight project board for organizing ideas and keeping work moving.

Live on VuraUpdated

The List filter reacts immediately, edge moves are disabled and named, and lane orientation is clearer. The spatial planner preserves local state and its distinct lilac and peach identity.

Public sourceBUILD.mdOpen verified demo ↗In-app build guide
Drift: actual released desktop product view after the shared typography refinement.
Preview captured · Explore the product ↗

Build phase

  1. PlannedComplete
  2. BuildingComplete
  3. Local checks passedComplete
  4. In reviewComplete
  5. Live on VuraCurrent phase

This tracks the recorded release phase. The checks below include later findings and ongoing refinements.

Product scope and intended patterns

The following describes the intended reference. Features are not a verification claim; recorded check results below define what has actually been tested.

Client-rendered application served from explicit static route entries; browser-local state, not a shared server database.

Learning journal

How to read this starter

Drift is a project-board starter showing shared state across board, list, detail and activity routes.

Source map

Board store

src/state/board.js

Signals own cards, view mode, filters, activity and persistence status.

Routes

src/routes.js

The app includes board, detail, activity, build and fallback routes.

Browser tests

test/browser/drift.spec.js

The browser suite exercises board/list switching, details, export, storage denial and mobile rendering.

Live board/list reads

src/pages/Board.jsx

List cards derive through an accessor; bounded move buttons expose named destinations and mobile lanes retain scroll cues.

Responsive application stylesheet

src/styles.css

Balanced narrow navigation and readable detail/build typography retain board movement controls.

Code patterns worth copying

One card source feeds board and list views

src/state/board.js

The list and board do not duplicate filters. They read the same derived set in different layouts.

export const visibleCards = computed(() => cards()
  .filter((card) => assigneeFilter() === 'all' || card.assignee === assigneeFilter())
  .sort(byDueDate));

export const boardGroups = computed(() => columns.map((column) => ({
  ...column,
  cards: visibleCards().filter((card) => card.status === column.id),
})));

Read the filtered list after setup

src/pages/Board.jsx

The component runs once, but cards() is evaluated in reactive bindings when assignee changes. Capturing the resulting array once would freeze the open list.

const cards = () => boardGroups().flatMap((group) => group.cards.map((card) => ({ ...card, column: group.label })));

Use the shared stylesheet on application routes

src/styles.css

Balanced narrow navigation and readable detail/build typography retain board movement controls.

.brand { display: inline-flex; align-items: center; min-height: 44px; font-size: 24px; font-weight: 600; line-height: 1.2; text-decoration: none; }

Real issues and fixes

Storage restore must validate cards

Problem
Persisted cards can be stale, malformed or refer to a removed column.
Fix
safeLoad requires every stored card to pass validCard before restoring state.
Proof
Invalid stored data falls back to seed cards and reports that seed data loaded.
Takeaway
Shared route state is only useful if restoration cannot poison every route at startup.

An open list kept the old filter result

Problem
The list sampled boardGroups in run-once setup, so changing assignee updated the store without updating visible rows.
Fix
Keep the cards projection as an accessor; name move destinations and disable impossible edge moves. Give the mobile lane preview a focusable scroll region and visible cue.
Proof
Browser regressions change assignee while list view remains open, verify boundary move controls and inspect mobile lane scrolling.
Takeaway
Derived collections that change after mount belong in accessors, not setup snapshots.

Allow subpixel tolerance in browser target measurements

Problem
A 44px CSS target can report a fractional bounding rectangle just below 44px, making strict raw-float checks brittle across platforms.
Fix
Retain the 44px CSS minimum and allow a half-pixel tolerance in the style regression.
Proof
The modern-ui check requires control.height >= 43.5; CSS controls retain min-height: 44px, and the test verifies mobile navigation rows and home navigation.
Takeaway
Normalize measurement tolerances without reducing the authored target size.

What went smoothly

  • Route detail pages read from the same card signal as the board, so edits stay visible across views.
  • Keyboard step movement reuses the same moveCard path as select/drop interactions.
  • Board, list and detail still share one card store; bounded move controls reuse the existing movement and activity functions.
  • Mobile planner navigation forms two deliberate rows of two links; a 44px home wordmark and visible focus stay part of the board workflow.

Boundaries to preserve

  • Planner edits and export data are browser-local.
  • The board models workflow interactions, not team authorization or collaboration.

Verification record

Build journal

  1. · Live on Vura

    Shared typography release captured from production

    Published shared typography and responsive control refinements are tied to the exact live deployment and source revision. Actual released captures replace the previous gallery preview; existing product behavior and source-grounded lessons are retained.

  2. · Live on Vura

    Product-depth iteration released and exercised

    The List filter reacts immediately, edge moves are disabled and named, and lane orientation is clearer. The spatial planner preserves local state and its distinct lilac and peach identity.

  3. · Live on Vura

    Reviewed source ready for release verification

    Unique product identities and deeper workflows are implemented and independently reviewed. Existing releases remain accessible while new source is published and fresh deployments are exercised.

  4. · Live on Vura

    Product-depth iteration in progress

    Repairing stale assignee filtering in List view and disabled edge moves, with clearer lane orientation. The current source and deployment links still identify the previous verified release.

  5. · Live on Vura

    Live corrections verified after independent follow-up

    The board has compact headings, short dates and named movement controls with disabled edges. Live move actions update both the lane and activity record.

  6. · Live on Vura

    Design refinement released for live workflow review

    The board has compact headings, short dates and named movement controls with disabled edges. Live move actions update both the lane and activity record.

  7. · Live on Vura

    Independent live design review started

    The existing public app remains available while a new design review examines hierarchy, typography, navigation and workflow clarity. Actual findings and before/after repairs will be recorded as they are verified.

  8. · Live on Vura

    Hosted reference rechecked after documentation review

    Public source, green CI and the live app were checked together after the clean-machine documentation pass. Lessons and limitations now reflect the implemented code rather than pending pre-release work.

  9. · Live on Vura

    Final source and CI checkpoint verified

    The public source and build reference match the released learning journal, and the source workflow is green. The demo remains live at the same verified deployment; README and CI-only refinements did not change application code.

  10. · Live on Vura

    Clean-machine browser setup documented

    The README now installs the locked Chromium engine after npm ci and explains the Linux system-library prerequisite. The hosted application is unchanged; code examples, repair notes and boundaries remain source-backed.

  11. · Live on Vura

    Public template and Vura release

    The reviewed implementation is available from its independent repository and real hosted URL. Detailed code examples and actual repair notes are linked below.

  12. · In review

    Design review cleared; release verification underway

    The local implementation is complete and revised visual evidence has passed review. Source and demo links will appear only after publication and hosted verification.

  13. · Building

    Implementation started

    The standalone project files exist and the product build is active. No local verification or live release is claimed yet.

  14. · Planned

    Product scope recorded

    This is a planned starter, not a working release. Implementation, tests, public source and deployment evidence will be added as they are completed.

Implementation lessons

Known limitations

Remaining work and blockers

No release blockers are recorded for this snapshot.

Using this as an agent reference

Read the public README and BUILD.md, reproduce the recorded checks and inspect the source before adapting the starter. A live demo, where available, provides separate deployed evidence.

Agent workflowSignalsEffectsGlobal stateRouting