Boards & Sections

Every project in Hypertask has a board — a visual workspace where tasks flow through customizable columns called sections. If you’ve used Kanban boards before, this will feel familiar. If you haven’t, think of it as a whiteboard with columns that represent stages of work.

Creating a board

From the web UI, click New board to create a blank board. You can also generate a board with AI-powered content:

From a board, use Ctrl+K and run “Create board with AI” to describe your board structure and sections. The AI generates sections and optionally pre-seeds tasks.

If you invoke AI board creation and the model doesn’t return a response after 45 seconds, the fetch cancels and an error is returned instead of leaving you in a stuck state. This prevents indefinite loading when the AI generation hangs.

Board titles in browser navigation

The browser title shows the board name and saved-view name when you navigate to a board. The server builds the title from board and saved-view metadata instead of replacing it with a generic title, so your browser tabs and history reflect your actual view.

Click-through prefixes for easier moving ([HTPR-5770])

Feature Each board’s ticket prefix is now deterministic based on the board title, making it easier to refer to tasks across similar boards. AI-generated task descriptions, quick toggles, and ticket lookups now use these stable prefixes instead of random identifiers.

• Identical titles across boards now produce one stable base prefix with predictable numeric suffixes (e.g., aexp-1 / aexp2-1 from longer titles, aexp-2 / aexp2-2, etc.).
• Short, clean titles are compressed to predictable 3–4 character labels (e.g., qa-2026-08-30-ui becomes QAUI). This improves readability in UI fields where space is limited.
• This deterministic behavior replaces the previous randomized prefix generator and simplifies workflows where multiple boards share similar naming patterns.

Use ticket prefixes in the browser’s address bar or AI prompts to reliably target tasks. The stable prefix—paired with a predictable numeric suffix—makes task references understandable and consistent.

App shell surface shortcuts

When the left icon rail (beta) is enabled on desktop, use a single number key to move between the main surfaces:

Key	Surface
1	Inbox
2	Board
3	Table
4	Calendar
5	Toggle AI chat

These shortcuts are ignored while you are typing, using a modal, or holding a modifier key. They are also listed in Settings → Shortcuts, the ? shortcut panel, and the Ctrl/Cmd+K command palette while the beta rail is active.

Adding and managing columns

Every board starts with a single default section. To add more:

1. From the view tab bar, use Ctrl+K, search for “Add column” (or “Add section”), and follow the dialog prompts.
2. Or use Ctrl+K > Create view > Add column.
3. In the CLI: hypertask view create --section "Section name" --project 15.

From the app:

1. Open any board.
2. Use Ctrl+K and choose “Add column” (or “Add section”).
3. Enter a name for the section and optional description.
4. Click Create or press Enter to confirm.

CLI:

hypertask view create --name "Doing" --project 15

Saved view options:

• Section: Tasks to include
• Priority: urgent, high, medium, low
• Assignee: me, unassigned, or a user ID
• Labels: Comma-separated label names or IDs

Sorting:

• Sort by: createdAt, updatedAt, or dueDate
• Sort order: asc (ascending) or desc (descending)

Column visibility

Behavior change A newly added column is visible in every view of the board immediately after creation. There is no need to manually include it in Saved Views or other board views.

This ensures that tasks moved into a new section appear in all view contexts (built-in splits, Saved Views, and per-browser preferences) without extra setup.

Built-in splits

Every board ships with four built-in views, on by default. A split’s tab appears in the view tab bar only while it contains at least one task, so an empty board shows none of them (HTPR-4996):

• My Tasks — tasks assigned to you. Each member sees their own slice of the board.
• Overdue — tasks whose due date has passed and are not in a done column.
• Blocked — tasks blocked by another task or waiting on a person.
• Agents — tasks assigned to an AI agent.

Built-in splits need no setup and cannot be edited or deleted; they don’t appear in Manage Views. They work in both kanban and table layout, and the usual view-cycling shortcut moves through them like any other view tab. Selecting one is a per-browser choice — it never changes the board’s saved default view.

For agents (CLI/MCP): these views are client-side filters over the board’s tasks; the API exposes no extra endpoint for them. Equivalent queries: tasks where assignees contains your user id (My Tasks), dueDate < now and status Normal (Overdue), waitingOnUserId set or a BlockedBy relation (Blocked), assignee rows with agentId set (Agents).

Midscene QA board coverage

Enhancement Midscene AI-driven testing now provides deeper coverage of board workflows, including five key board flows with stale-flow repairs and a nightly heartbeat watchdog for monitoring board health.

The QA expansion uses live DOM inspection to verify critical board interactions end-to-end with automated regression coverage for recurrent issues like stale sections and orphaned tasks.

Saved views

Saved views are named filter/sort configurations stored on a project. They make it easy to quickly jump to a common view of specific tasks.

The views bar

Saved views appear as pills in a single row above the board, with the board’s own name as the first pill.

• The row scrolls sideways rather than wrapping. A board with many views no longer pushes the columns down the page.
• Edge arrows appear at either end once the pills overflow, and the active view is scrolled into position on load, so the current view is always visible.
• Drag a pill to reorder your views. The board’s own pill cannot be moved.

Create a saved view

From the app:

1. Open any board
2. Use Ctrl+K to open the command palette
3. Search for “Save view as…”
4. Enter a name for your view

Or use the CLI:

hypertask view create \
  --name "Epic checks" \
  --project 15 \
  --section "Doing" \
  --priority "high,urgent" \
  --sort-by "dueDate" \
  --sort-order "asc"

The view is saved once created. You cannot create a saved view without a name (HTPR-4960).

List saved views

hypertask view list --project 15

Output:

ID             NAME                  VISIBILITY
view_abc123    Dev Review & QA       shared
view_def456    My Open Tasks         shared
view_ghi789    High Priority        private

Switch to a saved view

hypertask view switch view_abc123

Or from the app: use Ctrl+K, search for the view name, and select it from the dropdown.

Board interactions and state

Board titles in browser navigation ([HTPR-5420])

The browser title reflects the board and saved-view name when you navigate to a board. The server builds the title from authorized board and saved-view metadata, so Next.js no longer replaces it with a generic title during navigation.

This change applies to:

• Board tabs in the browser
• History and back navigation
• Shared board links
• Default, named, malformed, and fallback routes

Full regression coverage includes these views to prevent unexpected title behavior.

Instant board painting from IndexedDB snapshot ([HTPR-5722])

Performance improvement Boards now paint instantly from a locally cached IndexedDB snapshot. When you open a board, it loads fast without waiting for a full fetch, and authentication revocation runs in the background. If authorization is denied, the board clears and navigates home softly instead of forcing a hard reload.

This Linear-style approach eliminates page flicker and server roundtrips. No reload paths are involved in typical board opening; only real authorization failures trigger a full clear and navigation.

Folder/collection-level board grouping (beta)

Beta feature Boards can now be grouped into collections (formerly called folders) to keep your workspace organized. Collections are rendered in a collapsible section of the board switcher.

No documented API is available for remote collections yet; they are managed from the web UI.

Board focus after saving a view ([HTPR-5201])

When you save a board view, the keyboard focus stays on your current card instead of jumping to the last card in the active column. This matches the behavior observed when other modals (command palette, board manager, column manager, search) close: the board restores focus to the card you were on, keeping your focus consistent across interactions.

Board reset-to-default

The Reset to default action for board views is now authenticated, access-scoped, transactional, and idempotent. This prevents 500 errors when resetting non-owned board views (HTPR-5362).

Faster boardTasks responses ([HTPR-5449])

The boardTasks endpoint no longer performs redundant authenticated-user lookups after the board access guard completes. This reduces unnecessary work and improves response times on desktop, with consistent behavior across views.

Board columns and in-flight agent turns ([HTPR-5545])

Behavior change An agent turn can no longer be canceled by a board column move. The worker now protects in-flight deliveries from cancellation caused by section changes or board hygiene moves.

Two independent guards enforce this behavior on the deployed worker:

• A delivery fingerprint that hashes only the title and description (section changes cannot generate a conflicting fingerprint).
• A watchdog that handles the revision fence and restores the origin section when a column move would otherwise invalidate an active turn.

With these guards in place, board moves by the Agent Manager or Board Maintainer no longer fail an in-flight agent turn.

Mobile board switcher ordering ([HTPR-5654])

When you open the board picker or switch boards on mobile:

• Search starts with focus, so you can begin typing immediately.
• Arrow keys and Enter navigate and select filtered results.
• Boards are ordered by latest activity with your current board pinned at the top:
  • The board you’re currently looking at appears first.
  • Followed by boards with the most recent task updates.
  • Ordering logic is preserved between opens without reshuffling the list.
• Empty boards sort alphabetically and appear at the end.

This behavior uses the same ordering logic as the desktop board switcher while maintaining a stable MRU order session-wide on mobile devices. (HTPR-5625).

Mobile board switcher search ([HTPR-5625])

In addition to the ordering behavior above, the mobile board switcher supports focused search on launch:

• Search input automatically receives keyboard focus when the picker opens.
• Typing immediately begins filtering the visible board list.
• Drop-down results remain responsive to character input as you type.
• Board cards and the search result list offer keyboard navigation via arrow keys and selection via Enter.
• The current board stays pinned at the top during filter operations, ensuring a consistent positional reference.

Board sidebar behavior

The left sidebar organizes your boards into collapsible teams. When you group boards by team, they appear in the group’s accordion. Within a team’s group, the boards are sorted so that your most-used teams appear first.

• Boards are ranked by the most recently opened board inside a team.
• This ensures teams you actively use (for example, Inne or Hypertask) rise to the top of the list.
• The sorting is applied consistently across collapsed and expanded sections, keeping high-activity teams easily accessible.

Board switcher sort order ([HTPR-5476])

When you use Shift+M (board picker) or the board switcher, boards now appear based on their last activity rather than creation order:

1. The board you’re currently looking at is shown first.
2. Followed by boards with the most recent task updates.
3. Boards without recent tasks fall to the end and are sorted alphabetically.

This aligns with the agents page’s activity-based sorting and ensures your most active boards are always prioritized when navigating.

Mobile board switcher search and ordering ([HTPR-5625])

When you open the board picker or switch boards on mobile, search is focused on launch. Boards are ordered by latest activity with your current board pinned at the top, using the same desktop ordering logic as the board switcher:

• Search starts with focus, so you can begin typing immediately.
• Arrow keys and Enter navigate and select filtered results.
• The current board appears first, followed by the most recently updated boards.
• Ordering is preserved without reshuffling between opens, keeping active boards stable visually on mobile.

Guest boards

• Anonymously visit an empty guest board for the app.hypertask.ai host (hypertask.ai in production).
• Enter the guest board directly from the root URL logged out (no redirect hop) (HTPR-4845). The guest board is seeded once and persists until you log in or sign up.
• The cookie consent banner and “Log in” and “Sign up” buttons appear in the header for logged-out visitors (HTPR-4883).

Guest demo behavior

Guest demo boards provide a guided onboarding experience:

• Chat opens on load: When a guest loads a demo board, the AI chat opens automatically with an initial prompt to help them get started (e.g., create their first task or explore the board).
• Sticky chat: The chat remains visible for the duration of the guest session, acting as a persistent coach. The AI chat stays pinned to the sidebar during demo sessions so new users always see the AI assistant without hunting for it. A manual close no longer permanently suppresses the chat—all subsequent board reloads reopen it. This ensures new users always have guidance at hand as they discover boards and AI task creation.
• First board persisted: When a guest creates their first board, it persists until they log into a full account, providing continuity as they graduate from the demo

Boardless accounts

If you log in or sign up to Hypertask and don’t have any boards yet, you land on a project page that shows a real empty state instead of a blank screen. This provides clear guidance for new users and prevents the dead-end experience that previously occurred.

The empty state:

• Explains what boards are and how to create one
• Offers quick actions to create a board or invite a teammate
• Matches your theme and is consistent with other empty states in the app

Free tier limits

Free users (no active paid or team plan) are limited to a maximum of 3 owned boards. This limit applies across all board-creation surfaces:

• App web interface
• CLI (ht --create-board / ht board create)
• MCP tool (boards.create)
• Manifest-based board creation
• AI chat prompts that create boards

When a free user reaches the board limit, the creation surfaces block board generation and prompt them to upgrade to a paid or team plan. On the web UI, this appears as an in-app toast with upgrade options.

Example:

# This succeeds for free users with fewer than 3 boards
ht --create-board marketing-campaign-2026

# This fails when the limit has been reached
ht --create-board secret-project
# > Error: Board limit reached. Upgrade to add more boards.

Interactive onboarding modal toggle

During guest demo onboarding, interactive modals that ask users to confirm actions (accept invitations, archive views, etc.) use a boolean “toggle” state. The modal handler expects a simple boolean value to acknowledge or dismiss the prompt.

If a modal implementation incorrectly passes a non-boolean placeholder instead of a valid boolean toggle, the modal crashes with a this.props.toggle is not a function error when it attempts to invoke the toggle prop.

This occurred in four onboarding scenes before the fix was applied:

• Scene 8: Archive existing public view prompt
• Scene 11: Duplicate members confirmation
• Scene 17: Archive section prompt
• Scene 25: Onboarding completion confirmation

The fix ensures that every interactive modal in the demo onboarding path receives a proper boolean toggle value instead of a non-callable placeholder. The correction eliminates crash crashes during the guided onboarding flow and provides a stable, incremental start to a user’s first Hypertask session.

Regression tests in this release verify modal toggle behavior across these four key onboarding scenes, ensuring future changes to the onboarding UI cannot reintroduce the same crash pattern.

Compact modal palette

Hypertask’s components now respect the compact visual scale by default, including modals. Core modals such as Task Detail, Priority, and board actions follow the theme’s typography tokens at 48px/16px (header) and 44px/14px (input), with 36px/13px row heights. Min-width is set to 560px to match sibling controls (e.g., the Command Palette). Legacy-sized modals are opt-in via an explicit legacySizing prop.

Default behavior (compact)

// flowsProps.tsx or shared-modal.jsx
// legacySizing omitted — uses compact tokens
<Modal title="Task Details" open={isModalOpen}>
  <div className="modal-content">
    <Input label="Title" />
    <Button variant="primary">Save</Button>
  </div>
</Modal>

Legacy sizing (sidebars)

// SharePoint summary modal
<Modal title="SharePoint" legacySizing={true}>...</Modal>

Layout notes:

• Users see a cohesive font-sizes: 16px body, 14px UI labels, 13px subtitles.
• Height is tightly calibrated: header 48px, input 44px, rows 36.
• No onboarding is required; modals respect the current theme and compact palette by default.

Includes the modal sizing changes that ship with the updated modal scale and palette alignment.

Cards and selection

On a board, when you select a card (click it or use navigation), its document / detail view remains open and its keyboard shortcuts become active even if the DOM focus falls back to the body.

This means you can use shortcuts like a (add), e (edit), c (comment), p (move), m (assign), t (move to inbox), and s (archive) on a card while staying on the board—after returning from its detail view, closing a detail modal, or clicking empty board space.

Before this change, selected (but not focused) cards would ignore these shortcuts because only the focused card had event listeners. Now, the document-level listener ensures all selected cards can receive these shortcuts.

This behavior matches the expectations you’re used to in similar Kanban tools and keeps shortcut use smooth during rapid navigation through tasks and modals.

Batch selection

On desktop boards, hover a card to reveal its selection checkbox. Press X while a card is active, click its checkbox, or hold Shift while clicking another card in the same column to select the inclusive range. Selected cards stay selected when focus moves to another card.

The bottom selection bar’s Open actions button opens the command palette for the selected cards. Ctrl or Cmd + E archives them. A opens batch assignment, T opens batch tags, and M opens batch move. Press Esc to clear the selection. If an operation fails for a card, that card stays selected so you can retry it.

Board staleness indicators

Once a task moves into a section, it ages in view over time. To avoid visual noise, aged cards show a faint line at the top while fresh cards keep the section context clear. Use Ctrl+K and search for “Show time on board” to toggle staleness hints on or off. Staleness is controlled per board and does not change how tasks flow or their accumulated time tracking.

In-app feedback routing

In-app user feedback forms now create their tickets directly on Board 15 (Project 15), section Bugs, labeled user-feedback, and priority Urgent—instead of using the retired Board 2101. Notifications to contributors are unchanged. This routing keeps feedback close to your entry point and ensures it lands on a board that supports user signal.

---

Board access for writes

Hypertask ensures all write paths gate the target board or task before mutations occur. This applies across surfaces:

• CLI task and comment mutations (e.g., task create, task update, comment add)
• MCP task/comment tools (board_update_task, board_add_comment, legacy_comment)
• REST API board_update_task, board_add_comment, and the legacy comment endpoint (/api/board/comment)

The shared command validator in the CLI normalizes ticket references. Accepted ticket formats obey the regular expression ^[A-Za-z0-9]+-\d+$ and, when parsed, are used to look up the target board and task. If the current identity lacks access, the write fails safely rather than silently creating or updating across a board boundary.

Legacy comment endpoints previously trusted the botUserId or userId from a client-supplied header. These are now verified against the target board’s membership and the editor’s access. Attempting to post a comment or task mutation without access results in an authorization error from the server.

This unified gating ensures that operations are isolated to their intended board/task and that sensitive actions (state updates, comments, descriptions) cannot bypass access checks introduced by your configuration or workflow patterns. Before this fix, some write path variations would not consistently gate the target board or task, and affected comment endpoints trusted an unverified client identifier, opening a window for cross-board access errors. All write surfaces are now protected consistently.