Kanban Board

This Kanban board manages task states in four fixed lanes: "todo" (Not started), "in-progress" (In progress), "review" (Review), and "done" (Completed).

The screen draws tasks by extracting those from the entire task array (tasks) that match the identifier of each lane (lane.id) using a filter function.

It does not support setting WIP (Work In Progress) limits, manual sorting within the same lane, or adding/deleting lanes.

Each lane has a color set to distinguish between not started, in progress, review, and completed. During dragging, the candidate destination lane changes its border and background color to visually indicate the drop target.

When dropped, the card's status changes to the destination lane's value, and the item count display is recalculated from the current array.

This screen does not perform process management that stops movement when exceeding a WIP limit, nor does it perform role-based permission management.

The count in each lane is an indicator for grasping the situation, not a metric to automatically judge the appropriateness of the workload.

Because the usage is narrowed down to four states, it is a simple board focused on creating, editing, and changing the state of cards, rather than a highly flexible project management feature.

A task consists of eight items: ID, title, details, status, deadline, label name, label color, and creation date and time, and is held in a single array as React state.

In the creation and editing form, each input value is tied to an individual state, and upon saving, a new task is added or only the task with the corresponding ID is replaced.

Because status changes also rewrite only the corresponding element in the array, the contents of other tasks are not modified.

The identifier for a newly created task is generated from a timestamp string based on Date.now() combined with a deterministic numerical suffix (such as 1, 2, and so forth) appended only if an existing task in the current array collides with that exact timestamp ID, rather than using random suffix generation.

This identifier is strictly intended for local state reconciliation within the active browser session, rather than serving as a globally unique UUID across distributed databases or multi-client environments.

Task labels are constrained to a fixed taxonomy of seven categories in the Japanese interface, while the English interface preserves existing Japanese, English, or custom label values unless the user explicitly picks a different category during editing.

Any unrecognized custom attributes attached to existing tasks are safely preserved across edits rather than being dropped. Additionally, the initial default sample tasks have fixed creation dates set in UTC to June 23, 24, and 25, 2026, while user-generated timestamps remain completely untouched.

The interface does not support manual reordering or automated sorting within individual lanes, keeping the focus on advancing tasks through the four status stages.

Moving cards uses the browser's standard HTML Drag and Drop API. The card's draggable attribute and onDragStart hold the target ID, and the destination lane's onDragOver allows the drop.

Upon dropping, only the matching task's status is changed to the destination lane, and it is reflected on the screen and in localStorage through the same save process.

The lane being dragged over changes its border and background color, and onDragEnd clears the selection state.

While the HTML Drag and Drop API is easy to use with desktop mouse operations, operability varies depending on the touch device or browser.

Although there is a process to put the ID into dataTransfer, it does not guarantee that dragging is possible on all iOS and Android devices.

In environments where dragging is difficult, you can change the lane by opening the card and selecting the status from the edit screen.

By providing this alternative operation, the design does not limit the means of movement solely to dragging.

The application uses browser localStorage under the shared key agy-kanban-tasks on the current origin to persist task data across sessions.

Under the synchronous controller architecture, mounting the board does not trigger an automatic write, ensuring default demo values remain uncommitted in memory until an explicit change occurs.

When parsing stored data, the controller enforces strict schema validation, verifying required field types, unique non-empty identifiers, valid task statuses across the four lanes, actual existing calendar dates formatted as YYYY-MM-DD or empty strings, and finite timestamps within valid Date ranges, while preserving unknown task properties.

Top-level property access, getItem, and setItem calls are fully guarded by exception handling. If stored data is corrupted, malformed, or of an unsupported format, the controller leaves the stored value completely unmodified in localStorage and displays an empty board in memory rather than silently overwriting user data with sample tasks.

When a write fails, the latest in-tab edits across task creation, editing, status movement, and deletion are retained in React controller state via functional updates.

The sync status badge reflects only genuine load and write outcomes without artificial delay timers, clearly surfacing failures and ensuring subsequent retries operate directly on the latest in-memory edits.

LocalStorage operates within an isolated boundary determined by the browser profile and origin, meaning tasks are never synchronized across differing browsers, user accounts, or protocol and port configurations.

The agy-kanban-tasks key is deliberately shared between the Japanese and English interfaces on the same origin, which is an intentional architectural design rather than a defect; task titles and labels previously saved in one language remain intact without automatic translation when switching views.

To guard against data loss, the board provides manual export utilities allowing users to download the current task array as a JSON file and download the raw saved storage snapshot as a separate file, even when the underlying record is malformed, rather than copying raw storage contents to the clipboard.

However, no import, file restore, or automated migration interfaces are provided. Reloading stored data is an explicit user-initiated action that is advised after performing an export but is not technically gated on export completion, and it requires explicit confirmation regarding the loss of unsaved drafts.

Furthermore, corrupted or invalid stored data cannot be loaded into the board simply by refreshing; the user must export the raw saved copy and manually recover the malformed records before reloading.

The tool listens for storage events and executes raw string comparisons immediately before writing to detect external modifications from other tabs, halting subsequent automatic writes without discarding the active in-memory draft if external changes or key clearing occur.

Because non-transactional race conditions and ABA discrepancies can still emerge between concurrently open tabs, multi-tab collaboration is not guaranteed, and editing should remain restricted to a single tab.

Default deadlines for newly created tasks are computed directly from the local calendar date using local year, month, and day components via setDate, rather than formatting tomorrow as a UTC string that can skew dates across time zone offsets.

Existing deadlines stored as YYYY-MM-DD strings are strictly validated against genuine calendar dates, rejecting impossible dates such as February 30 or invalid leap days.

To evaluate due dates reliably, the system derives numeric UTC calendar day indices directly from the stored date components and compares them against the local device current calendar day components, completely avoiding standard Date string constructor parsing and 24-hour elapsed millisecond math to remain immune to daylight saving time shifts.

The deadline indicator is recalculated dynamically during component rendering without relying on midnight timers or background alert intervals.

Tasks situated in the done lane always display a Completed badge regardless of their deadline. For uncompleted tasks in other lanes, overdue items with a negative calendar difference show Expired, tasks due on the current day show Due today, tasks due within the following two days display the remaining day count, and dates further out display the formatted calendar date.

If the operating system date or regional settings are misconfigured, these display badges will reflect those local values accordingly.

This deadline feature is a visual marker at the time the page is displayed. It does not guarantee deadline judgment accuracy, nor does it perform email, push notification, calendar integration, or background reminders.

Since notifications will not arrive even if a deadline approaches while the page is closed, please use it in conjunction with a calendar or notification-supported management service for tasks requiring reliable schedule management.

This Kanban board is suited for organizing short-term individual tasks handled on the same device and browser. With 4 lanes and fixed labels, its intended use is to summarize the day's work, a small progress chart for a few days, or a checklist during prototyping.

Because there are no accounts, collaborative editing, cloud synchronization, comments, assignees, notifications, or change histories, it is not suitable for formal recording of multi-person project management or long-term roadmaps.

Task creation, lane transitions, and persistence routines run entirely within client-side browser memory and local storage. Stored task records are kept as unencrypted plain text JSON without cloud replication, automated version history, or scheduled backup rotations.

While an advisory beforeunload handler prompts users when unsaved drafts exist in the controller state, this prompt cannot guarantee data preservation during abrupt mobile browser shutdowns, forced tab closures, or Next.js client-side route navigations.

When exporting data, users can download the current in-memory task array as a UTF-8 JSON file alongside raw stored JSON snapshots as downloadable files, with Blob object URL cleanup reliably executed in a finally block even if a download click triggers an error; however, browser completion of file downloads cannot be guaranteed by the application.

The kanban board does not implement a clipboard copy button or a useTextCopy hook; instead, data inspection and offline archiving rely on file downloads, while a visual saved badge accurately conveys whether changes are currently persisted or waiting as unsaved in-tab drafts.

In-place task deletions and resets require explicit user confirmation to prevent accidental loss, but the system does not guarantee complete security or elimination of all concurrency anomalies.

Triggering an explicit reload prompts for confirmation of unsaved draft loss, but it does not provide file import or automated restoration capabilities.

Users should avoid entering confidential credentials or mission-critical records, and should maintain external records or dedicated task management systems whenever durable long-term storage is required.