Changelog

Organizations and workspaces

• Organizations. A Stride site admin creates an Organization from the new /admin/organizations screens and appoints its first org-admin by email. An address with no account gets a new one and an email with instructions to set a password. A person belongs to at most one Organization.
• The Organization console. Org-admins open /org from Organization in the side navigation. It shows the Organization's details and members, and lets org-admins create, rename and archive workspaces and remove members.
• Workspaces. Every account has a hidden personal workspace, and existing boards were moved into their owners' personal workspaces. An Organization can have several workspaces. Its people get a workspace switcher in the side navigation and a Workspace settings page, with Members and Boards for everyone, and Invitations, Tokens and Export for org-admins.
• Invitations. Org-admins invite people to a workspace by email, as a Member or a Guest, optionally with access to one board. Links work once and expire after 7 days. On a free board, the owner can invite someone to that one board from its members screen.
• Moving a board into a workspace. An org-admin moves a board they own into an Organization workspace from Move a board here. Everyone on the board must already belong to the Organization, and the move cannot be undone. Once moved, the board is a paid board.
• Workspace tokens. One API token for every AI Optimized board in a workspace, instead of one per board. Each request names its board. Tokens expire after 90 days and stop working when revoked or when the org-admin who created them leaves.
• Workspace export. Org-admins download a workspace as a zip of JSON files, built in the background and kept for 7 days. A self-hosted instance restores one with mix kanban.import_workspace (or Kanban.Release.import_workspace/3 in a release). The archive never contains passwords, tokens or webhook secrets.
• The Organization audit log at /org/audit lists the Organization's security events, 50 to a page, filtered by action and date, with CSV and JSON export.

Organizations and Workspaces (docs/organizations.md) covers all of this, and the Resources section has new guides for org-admins.

Single sign-on, SCIM and security policies

• Single sign-on with OpenID Connect or SAML 2.0, one identity provider per Organization. Org-admins verify their email domains with a DNS TXT record, and people on those domains use Sign in with SSO. Their first sign-in creates their account and makes them a member. Verified domains are re-checked daily, and a domain whose record is missing three days in a row stops being verified. See Single Sign-On (docs/single-sign-on.md).
• SCIM 2.0 provisioning at /scim/v2. An identity provider creates, updates and deprovisions members and keeps workspace membership in step with its groups, using Organization-scoped tokens created on /org/scim. See SCIM Provisioning (docs/scim-provisioning.md).
• Security policies on /org/security: require two-factor authentication for every member, with a grace period of 1 to 30 days (7 by default) that each person gets once, and set how long the Organization's audit events are kept (90 to 3,650 days, or forever). See Organization Security Policies (docs/organization-security-policies.md).

The Free and Organization plans

When plans are enforced:

• A free board holds at most 3 people. AI agents never count. A board already over the limit keeps everyone, but nobody new can be added until there is room. Public read-only boards can still be read by any signed-in user; readers do not count.
• Notifications, bulk actions, integrations, the task telemetry fields and MCP access are Organization-only. On a free board each shows its name with "Available to organizations" and links to the pricing page. Webhook, Slack and Discord endpoints are paused rather than deleted, and send again once the board moves into an Organization. MCP requests for a free board get a JSON-RPC -32001 error. The REST API and client-side hooks stay available on free boards; the REST API accepts the telemetry fields but does not store them, and says so in a warnings list.
• People without paid access stop getting notification emails. Tasks waiting for them are still listed in the Review queue and My Work.

Operators get a read-only report of boards over the member limit (mix kanban.over_cap_boards, or Kanban.Release.report_over_cap_boards/0), a release function that creates Stride's own internal Organization, and a one-time launch announcement email.

Account deletion

• Anyone with a password can delete their own account from Delete account in account settings. Deletion is refused while they own a board other people use, or while they are the last org-admin of an Organization that has other members. Their claimed tasks go back to Ready, and their tasks and comments are kept without their name.
• A site admin can delete an account that an Organization's identity provider deprovisioned, on its owner's request.
• Every account deletion, and every refused one, from /admin/users is recorded in the audit log.

Public pages

• /pricing, /terms and /privacy are rewritten for the Free plan and the sales-led Organization plan.
• /product and /workflows are redesigned around Stride's features, with current screenshots, and /workflows shows how Stride plugs into your coding agent.
• Stride is published under the MIT license that the pricing page and terms refer to.

Documentation

• Every doc under docs/ and the README was checked against the code and corrected, and docs/README.md indexes every doc by audience. A test keeps the index complete.
• The in-app Resources guides were refreshed against the current app, with new screenshots and new guides for account settings, board settings, labels, search and filters, bulk actions, the archive, task details, comments and mentions, the Agents page, My Work, Targets, notifications, integrations, MCP, free and paid boards, workspaces, invitations, and the org-admin pages. Guides are now grouped into Getting started, For developers, For non-developers and Best practices.
• The onboarding endpoint and the skills and setup templates it serves to agents were corrected to match the payloads the server accepts.

Webhooks and Slack notifications

Board owners have a new Integrations tab next to Settings. Each endpoint receives the task events ticked when it was added: created, updated, moved, claimed, unclaimed, completed, moved to review, reviewed and deleted.

• A generic webhook receives a signed JSON POST. Its signing secret is shown once, when the endpoint is added or its secret is rotated. Copy says whether the secret reached the clipboard, and asks you to copy it by hand if it did not.
• A Slack endpoint posts a short message to a channel through a Slack incoming webhook.
• A Discord endpoint posts a short message to a channel through a Discord channel webhook.
• Each endpoint has Send test, an on/off switch and a log of its 20 most recent deliveries.
• Edit changes which events an endpoint gets or where they go. Leave the URL blank to keep the current one; a new URL gets the same checks as a new endpoint. The kind cannot be changed. The endpoint keeps its delivery log, and a webhook keeps its signing secret, so use Rotate secret if the new address belongs to a different receiver. Deliveries already waiting to be retried go to the new address.
• Failed deliveries are retried for about an hour, up to 8 attempts. A 4xx other than 408 or 429 is not retried.
• Stride never sends to a private or internal network address.

Webhooks and Slack (docs/webhooks.md) explains how to set up each kind, what a delivery contains and how to verify its signature.

Monitoring events across the app

Stride now sends a monitoring event for:

• board settings, members and columns, including the API tokens revoked when a member is removed or made read only;
• task edits, moves, deletes, claims, released and expired claims, review decisions and comments, whether they come from the board, the API or MCP;
• goals: the last task finished, tasks unblocked, Backlog tasks promoted, after_goal hooks succeeding or failing, and goal reassignments and reprioritizations;
• sign-out, password and email changes, account confirmation, display names and user administration;
• notifications, notification email (sent, skipped or failed), weekly digests, delivery targets and broadcast messages;
• downloads, rate limiting, MCP messages, API requests with no token and GitHub issue reports.

Events carry ids, counts, types and the names of changed fields. They never carry email or IP addresses, names, titles, descriptions, comment or message text, tokens or hook output.

Stored metrics retention

A daily job removes stored metrics older than 90 days. The period is set with retention_days under Kanban.Metrics.RetentionWorker; an invalid value removes nothing. The admin users page counts activity within the same period. The audit log is not affected.

Telemetry reference

Telemetry Events (docs/telemetry.md) lists every event with its measurements, labels and meaning, and explains how to receive the events, what they never contain and how long stored metrics are kept. A test fails whenever the list and the app disagree.

Board search and filters

A filter bar above the columns searches a board by text and filters it by type, priority, assignee and label.

• Search matches a task's title or identifier, ignoring case.
• The assignee filter offers every board member, plus Unassigned.
• Filters combine, and Clear filters removes them all.
• A goal stays on the board when one of its child tasks that is not archived matches, so a matching task is never shown without its goal.
• Drag reordering is off while a filter is active, and the bar says so.

The filters are part of the page address (?q=, ?type=, ?priority=, ?assignee=, ?label=), so a filtered view can be bookmarked or shared. Opening a link with a value the board does not recognise shows the board without that filter instead of failing. If the label or member a filter names is deleted or removed while the board is open, the filter is dropped and the address updated. Read-only members can search and filter like everyone else.

Board labels

Owners and members with modify access manage a board's labels in the new Labels section of the board settings. They can add, rename, recolour and delete labels, and each change saves straight away.

• Each label has a name of up to 40 characters and one of nine colours. Names are unique on a board, ignoring case.
• Deleting a label removes it from its tasks; the tasks themselves are kept.
• Read-only members see the board's labels but cannot change them.

The task form has a label picker. Task cards show up to three label chips, then a +N count for the rest; goal cards show none. When a label is created, renamed, recoloured or deleted, every open copy of the board updates its cards and its label filter without a reload. A member added to or removed from the board appears in, or leaves, the assignee filter the same way.

My Work

A new My Work page (/my-work), linked from the sidebar, lists every open task assigned to you across the boards you belong to. Tasks are grouped by board and ordered by priority within each board, and each one links to the task on its board.

Archived and completed tasks are left out, and so are tasks sitting in a board's Done column. Tasks on a board you have been removed from are no longer listed.

Bulk actions

Select in the board header turns on selection mode for owners and members with modify access. Each card gets a checkbox, and each column gets a Select all button. A bar that stays at the top of the board shows how many tasks are selected and acts on all of them at once:

• Move them to another column;
• Assign them to a board member, or unassign them;
• Add or Remove a label;
• Archive them, after a confirmation.

Each action succeeds or fails as a whole. A move that would take a column past its WIP limit changes nothing. Move, assign and archive skip goals, because doing any of them to a goal also affects its child tasks; the board says how many goals were skipped. Labels can be added to and removed from goals.

A card that is filtered out, deleted, archived or moved off the board leaves the selection. So does a card that moves to another column, for example when someone else drags it, so a bulk action cannot quietly undo that move; the board says when this happens. Clear selection, Done selecting or Escape clears the selection.

Keyboard shortcuts

On a board, / puts the cursor in the search box and ? opens a list of the shortcuts. Escape closes the list, or clears the selected tasks. The shortcuts are ignored while typing in a field or while another dialog is open. Closing the list puts focus back where it was. On wider screens, a / ? hint in the filter bar opens the list too.

Labels in the API and MCP server

Agents work with labels by name. The API never exposes label ids and never creates labels.

• POST /api/tasks and POST /api/tasks/batch attach existing labels with a labels list of names. PATCH /api/tasks/:id replaces a task's labels, and "labels": [] removes them all.
• Names are matched against the token's board, ignoring case and surrounding spaces. An unknown name returns 422 naming every unknown label, and nothing is written.
• Task responses include labels as {name, color} objects.
• GET /api/tasks takes ?label=<name>, which filters the same way as the board's label filter. The MCP server's stride_list_tasks tool takes the same label argument.

Move a Backlog task to Ready from its card

Task cards in the Backlog column have a Move to Ready arrow, shown on hover or keyboard focus (and always on touch screens). It moves the task to the bottom of the Ready column. It appears for owners and members with modify access on boards that have a Ready column, and never on goal cards.

Two-factor authentication

A new Two-factor tab under Settings turns on two-factor authentication. Stride shows a QR code and the same key as text; two-factor is on only once a code from the authenticator app is accepted with Verify and turn on. Stride then shows ten recovery codes, once. Leaving or cancelling before the code is accepted leaves two-factor off. Like the rest of Settings, the tab needs a recent sign-in.

From the same tab, New recovery codes replaces all ten codes after a current code from the app, and Turn off two-factor accepts a current code or an unused recovery code, which is then used up. Turning it off deletes the stored key and recovery codes. Recovery codes ignore spaces, dashes and capital letters when typed.

A code is accepted for its own 30-second window and one window either side, to allow for a phone clock that is slightly off, and each code works only once. API tokens are not affected: agents keep authenticating with their bearer token.

A second step at sign-in

With two-factor on, a correct email and password no longer signs a person in by itself. Stride sends them to a new Two-factor authentication page (/users/two-factor) for the code from their app, or a recovery code through Use a recovery code instead. The session token is issued only once a code is accepted. Until then the session holds only a pending-sign-in marker, which expires after five minutes.

• Keep me signed in on this device is honoured once the code is accepted, and someone sent to sign in from another page is returned to it.
• Signing in with a recovery code uses it up, and Stride suggests creating new codes.
• If the account is disabled or two-factor is turned off while a sign-in is pending, the code is refused and the person starts again.
• Re-authenticating to reach Settings asks for the second factor too. Changing the password from Settings, which already needed a recent sign-in, does not ask again.

A reminder for people without two-factor

When someone without two-factor signs in with their password, the page they land on shows a card above its content. That includes a page they were sent back to after signing in. The card links to Settings → Two-factor and to the setup guide. Not now hides it straight away and snoozes it for 10 days. The snooze is stored on the account, so it holds on every device, and once 10 days have passed the next sign-in shows it again.

The card belongs to that sign-in: it goes away when the person moves to another page or reloads, and it never shows once two-factor is on. Starting set-up without finishing it does not count as on. Re-entering the password to open Settings counts as a sign-in for someone without two-factor, so the card can appear on the Settings page then. Pages outside the signed-in app (the Resources pages, About and Changelog) do not show it.

A guide to setting up two-factor

Resources → Setting Up Two-Factor Authentication covers:

• turning two-factor on and saving the recovery codes;
• signing in, including with a recovery code;
• getting new codes and moving to a new phone;
• what to do if the authenticator is lost or a code is refused.

docs/TWO-FACTOR-AUTHENTICATION.md is the technical reference behind it.

Two-factor audit events

Each change is recorded in the audit log against the user:

• two_factor_enabled
• recovery_codes_regenerated
• two_factor_disabled
• login_succeeded_two_factor
• two_factor_recovery_code_used
• two_factor_challenge_failed

No code, key or recovery code is written to the audit log.

Comment authorship, editing and deleting

Every comment now records who wrote it and, when it came through the API or MCP, the agent that wrote it. The thread shows the author's avatar and name, or the agent's name with the person whose token it ran under ("via Ada Lovelace"). Comments written before this release have no recorded author and show as "Unknown", rather than having one invented. Deleting a user keeps their comments and drops only the attribution.

Authors can edit their own comments, and an edited comment is marked as edited with the time of the edit on hover. Authors can delete their own comments, and board owners can delete any comment on their board. An owner deleting someone else's comment is recorded in the audit log as comment_deleted_by_owner. Any board member can comment, read-only members included, because commenting is discussion rather than a change to the task. These rights are checked live, so someone removed from a board loses them at once. The board UI, the REST API and the MCP tool share one permission check, so they cannot drift apart.

One live comment thread

The task view and the edit form now share one comment thread, in light and dark mode. New, edited and deleted comments appear for everyone viewing the task without a reload. Posting a comment scrolls it into view inside the thread; comments arriving from other people do not move your place. Posting a comment from the edit form keeps any unsaved changes to the task.

@mentions with suggestions as you type

Typing @ in a comment suggests board members, matched by name or email. The list works with the arrow keys, Enter or Tab to pick and Escape to close, and is announced to screen readers as a combobox. A mention is stored as an @[Name](user:ID) token and shown as a chip with the member's current name. Mentions are checked on the server: only current members of the task's board whose accounts are not disabled count, at most 20 per comment, and anything else stays plain text.

Each newly mentioned member gets a Mentioned notification in the app and, by default, by email. The author is never notified of their own mention, and editing a comment notifies only the people the edit newly mentions. The notification links to the task's edit form and scrolls to the comment, which is outlined so it is easy to find. It never copies the comment's text, so someone who later leaves the board keeps no copy. When an agent wrote the comment, the notification names the agent and the person whose token it ran under, for example "Claude (Ada Lovelace)", and never shows an email address. Mention emails can be turned off under Settings like any other notification.

Task comments in the API and MCP

• GET /api/tasks/:id/comments lists a task's comments oldest first. limit (1 to 200, default 50) returns the most recent comments, and meta.has_more says whether there are older ones.
• POST /api/tasks/:id/comments adds a comment as the token's user. content is 1 to 10,000 characters and may carry mentions. The agent name shown on the comment is resolved in the same order as a created task's created_by_agent: the token's agent model, then the agent_name sent, then the agent name the token last sent.
• GET /api/tasks/:id and the MCP stride_get_task tool now include a comment_count, so an agent can tell when a thread is worth fetching.
• The MCP stride_add_comment tool now accepts agent_name, runs the same action as the REST endpoint and returns the comment in the REST shape, so a comment is attributed the same way over both.

Both endpoints are documented in docs/api/, described in the OpenAPI specification, and listed in the agent onboarding response.

An MCP server at /api/mcp

Stride now serves a Model Context Protocol server at POST /api/mcp, so MCP clients such as Claude Code can use Stride through schema-checked tools instead of hand-built curl commands. It offers six tools: stride_next_task, stride_claim_task, stride_complete_task, stride_get_task, stride_list_tasks and stride_add_comment. Each tool's arguments match the REST API's OpenAPI specification. Claims and completions run through the same code as the REST endpoints, so hook results, reviewer_result and the completion gate are checked exactly as before. Hooks still run on the agent's machine; the server never runs one. stride_list_tasks always returns one page of slim summaries unless asked for whole tasks, so a large board cannot flood an agent's context.

The server speaks JSON-RPC 2.0 over Streamable HTTP and answers with JSON only. It opens no event stream and keeps no session, so GET and DELETE /api/mcp return 405. It supports MCP protocol versions 2024-11-05 through 2025-11-25. It uses the same API token as the REST API, acts as the token's user on the token's board, and counts failed authentication attempts toward the same rate limit. A request whose Origin header names any other site is refused with 403, so a web page cannot drive the endpoint through a visitor's browser. A REST refusal comes back as a tool error carrying the same body plus error_code and http_status. docs/MCP.md covers setup in Claude Code and the full tool reference, and the API docs and OpenAPI specification now list the endpoint. REST responses are unchanged.

A persisted, append-only audit trail

Every security audit event is now also stored as a row in a new audit_events table, alongside the structured log line and telemetry event it already produced, so events can be queried, exported and kept. Each row records the action, the acting user, the IP address and the event's metadata. Values that look like credentials (passwords, raw tokens, secrets) are dropped before anything is logged or stored, and long values are cut to 2,000 characters.

The table is append-only. A database trigger rejects every change to a stored row, every TRUNCATE, and every delete outside the retention purge. The one exception: deleting a user clears the actor link on their events but keeps the events, and the user's id stays in the metadata.

Storing an event can never break the action being audited. If the insert fails, the failure is logged by action and error type only, never the values, and the caller carries on. Inside a transaction the insert runs under a savepoint, so a failed audit insert cannot roll back the caller's work. An event whose user no longer exists is stored without the actor link rather than lost.

An audit log viewer and export for site admins

Site admins have a new /admin/audit-log page, linked from the admin menu on desktop and mobile. It lists events newest first, 50 to a page, and filters by action, actor email, and a from and to date (whole UTC days, both inclusive). The filters live in the URL, so a filtered view can be bookmarked or shared with another admin. Filter values are checked strictly, and an invalid one is ignored rather than causing an error.

The same filters drive a download as CSV or JSON from /admin/audit-log/export. Large exports stream from the database in batches instead of loading at once. CSV cells are guarded against spreadsheet formula injection, using the same encoder as the board archive export. Every export is itself recorded as an audit_log_exported event, with its format and filters, before the first byte is sent, so even an aborted download leaves a record. Only site admins can reach the page or the export.

A separate owner role for the audit table

The audit_events table, its id sequence, its append-only trigger function and their schema can now belong to kanban_audit_owner, a role that cannot log in and that the application can never assume. The application keeps only the right to insert and read events. Until now the application's own role owned the table, so it could disable or drop the trigger that protects it. A migration hardens the table when it runs as a superuser and otherwise logs why and carries on, so a deploy never fails for lack of privilege. docs/audit-log-hardening.md describes the statements and every reason a database can be reported as degraded.

An owner-owned retention purge

Old events are now removed only through the audit_events_purge database function. It refuses any cutoff newer than 90 days in the function body itself, so even a compromised application cannot erase recent history. In a hardened database it runs with the owner's rights and is the only way the application can delete a row; the old session flag that let a delete through is ignored there.

Cursor pagination and filters for GET /api/tasks

GET /api/tasks now accepts limit (1 to 200, default 50) and an opaque cursor. It also accepts filters on status, type, priority, assigned_to_id, parent (a goal identifier such as G12) and updated_since (an ISO 8601 timestamp), and they combine with the existing column_id. Archived tasks are left out. Each page is ordered by task id and carries a meta block with next_cursor and limit. Pass next_cursor back as cursor to get the next page, and stop when it is null. Following the pages with updated_since gives an incremental sync.

Pagination is opt-in. A request with none of the new parameters gets the same unpaginated response as before, byte for byte, so existing clients are unaffected. Once any new parameter is present, a blank or malformed value returns a 400 with the reason, never a silent fall back to the full list. Every doc that describes the endpoint, and the onboarding api_reference, now cover the new parameters.

An OpenAPI 3.1 specification at /api/openapi.json

The API is now described by a hand-written OpenAPI 3.1 specification, served without authentication at GET /api/openapi.json with a one-hour cache. It defines the bearer-token security scheme and shared Task, TaskSummary, Error and PageMeta schemas. The agent onboarding response links to it as api_reference.openapi_url, and docs/api/get_openapi_json.md documents it.

A contract test keeps the specification honest. It fails when a route exists in the router but not in the spec, or in the spec but not in the router, when an operation's authentication does not match its pipeline, or when the Task schema's keys and enum values drift from what the API actually renders.

An inbox and a notification bell

Every page in the app shell now has a bell with a live unread count, linking to a new /notifications inbox. The inbox lists your notifications newest first, filters to unread, marks one or all as read, and opens a notification's page when you click it. New notifications and read-state changes arrive live, without a reload. A notification tied to a board is hidden once you leave that board; account-level notices, such as being removed from a board, stay visible.

Notification wording is rendered when it is shown, not when it is stored, so each person reads it in their own language. Agent free text that does reach a notification (review notes, an unclaim reason) is trimmed, capped at 500 characters and always shown escaped.

What you are notified about

• Review requested: when an agent completes a task that needs review, every board member with owner or edit access is told, with a link to the review queue.
• Review results: approving a task or requesting changes tells the person whose agent did the work, with the reviewer's notes on a change request, unless they reviewed it themselves.
• Task assigned: assigning a task to someone else tells them. Assigning one to yourself does not.
• Task unclaimed: an agent releasing a task back to Ready tells the user it was working for and the task's creator, with the reason when one was given.
• Claim expired: an agent claim that lapses before the task is finished tells the assigned user once. A sweeper checks every five minutes.
• Goal completed: a goal reaching Done tells its creator and assignee once per completion.
• After-goal hook failed: a failing after_goal hook tells the goal's creator and assignee once per run of failures, with the exit code and duration but never the hook's output.
• Board access changed: being added to a board, having your access changed or being removed tells you what changed. When the change revoked your API tokens for that board, it says how many, so failing agents are no longer a mystery.
• Delivery target at risk or missed: an hourly check tells a target's owner when the target becomes at risk of missing its date or misses it. The status matches the badge on the boards strip, and a target that recovers and slips again notifies again.

Email delivery with one-click unsubscribe

Notifications can also arrive by email. Emails are sent in the background, never on the request that caused them, so a slow mail server never slows the app down and a failed email never undoes the action that triggered it. Every kind of notification emails by default except completed goals.

Every notification email carries a signed unsubscribe link, plus the List-Unsubscribe and List-Unsubscribe-Post headers mail providers use for one-click unsubscribe. A link turns off that one kind of email without logging in, expires after 90 days, and shows the same response for any invalid link, so it never reveals whether an account exists.

Notification preferences

A new /users/notifications page lets each person turn in-app and email delivery on or off for every kind of notification, and turn the weekly digest on or off.

A weekly digest

On Mondays at 13:00 UTC, everyone who has opted in, confirmed their email and still has an active account gets a digest of the previous week. It covers what was finished on their boards, completed goals and what is waiting in their review queue. It only mentions boards they belong to, and quiet weeks send nothing.

Completion notes are persisted and shown on the Review queue

completion_notes had been documented as the place an agent records findings a human needs to read — exploratory-testing results, a refused behaviour-matrix row — but it was never a field on the task. The completion endpoint accepted it, the changeset silently discarded it, and the agent got a success response with no signal that its report had vanished. It is now a real column, cast on the completion path, returned by the API, and rendered on the Review queue beside the completion summary. It stays optional: omitting it leaves any stored value untouched.

Because the field is agent-authored free text now shown to humans, the completion path also scans it for credential shapes — token formats, key blocks, opaque secret assignments — and raises a security audit event without ever logging the matched text. The scan deliberately detects rather than blocks or rewrites: a legitimate refusal narrative is about credentials, so rejecting on that vocabulary would break the workflow the field exists to serve.

A target warns you when its own estimate slips past its date

A delivery target now derives at_risk from its estimated completion date rather than waiting for the target date to pass. When the estimate — projected from median lead time across the target's member goals — lands after the target date, the badge reads at risk, and the reason is surfaced wherever the status is explained rather than left as an unexplained colour change.

Matrix row text is confirmed escaped, and the rule that says so is now true

Behaviour-matrix row text is attacker-controlled at the API boundary — anyone posting directly to the API never sees the authoring guidance. Every render surface was read and confirmed to interpolate row values through auto-escaped templates with no raw-HTML helper anywhere on the path, and the seven category strings and four row statuses were confirmed to be hard-rejected server-side rather than merely documented as such. Escaping tests were added for the surfaces that lacked them, including attribute context and an unrecognized category. The agent-facing guidance was reworded to cite the real render-side control instead of implying the "don't type raw HTML" convention was the defense.

The matrix secret rule no longer contradicts itself

The implementation-driver guidance mandated recording a row's status advance by PATCHing the matrix, and in the same breath forbade letting a credential reach the PATCH body. On a task whose matrix carried a credential-bearing row those were unsatisfiable together: the PATCH replaces the whole array, and a partial matrix is rejected for not covering every category, so advancing any row re-sends them all. The guidance now states that re-sending already-stored row text back onto its own record is not a new copy, and names one correct action — scoped narrowly enough that it is not a general licence to put credential material in a request body.

Behaviour/test matrix on tasks

A task can now carry a behaviour/test matrix: a list of rows pairing a behaviour the change must satisfy with the real test that covers it, or an explicit reason the row is waived. Each row carries a category drawn from seven fixed values (happy path, boundary, error/exception, null/empty, concurrency, lifecycle/wiring, contract/serialization), a status (planned, passing, failing, not applicable), and an optional test name and type.

The field is optional, but a non-empty matrix must cover all seven categories — a partial matrix is rejected naming the ones missing. It is editable from the task create/edit form, accepted and serialized through the JSON API, rendered on the task detail view, and echoed by the reviewer into a verdict shown on the Review queue.

A workspace navigation spine

The boards index gained a header showing aggregated workspace stats and an avatar stack of active agents, plus a nav strip linking the Agents page, Review queue, and Metrics from every page — so the workspace-level views are reachable without going through a board first.

Per-consideration security mitigation breakdown

When a task lists security considerations, the Review queue now shows an always-visible per-consideration breakdown of whether each one was actually mitigated, rather than a single rolled-up verdict.

Admin pages became tabbed, with an agent view

The admin user administration page was converted into an in-page tabbed view, and gained an Agents tab showing completed-task counts per agent. A "hide users with zero boards" filter was added to the user list.

The dark-mode contrast checker had blind spots

The contrast tooling missed the pairs that hid a status-chip delineation defect, so a real visual problem passed the automated gate. The checked pair set was widened to close those gaps.

Export workspace metrics to PDF and Excel

The workspace metrics page gained an export dropdown that carries the page's active filters and the viewer's timezone into the generated file. Both a PDF report and an Excel workbook are produced, fully translated across all locales, behind a scope-authorized route. The existing board-level metrics export was translated to match.

Lead time charting and an exclude-weekends filter

A daily median (p50) lead-time series was added and rendered as its own chart below the cycle-time chart. Both charts gained a trend line and an auto-fitting rounded y-axis that picks readable tick values instead of arbitrary ones. A filter to exclude weekends was added, and the KPI strip's lead-time figure moved from p75 to p50 so it agrees with the chart.

Targets show an estimated completion date

A delivery target's pill now shows an estimated completion date derived from the median lead time of its member goals, so the target communicates a projection rather than only a deadline.

Plugin install picker during onboarding

The confirmation onboarding page gained a tabbed picker for installing the agent plugin matching the user's coding agent, backed by a registry of the supported runtimes.

Workspace metrics load once, and read far less

The metrics pages were reading more than they rendered. Reads were consolidated into a single narrow fetch of completed tasks, the cumulative-flow view's full-table load was replaced with a bounded projection, the Agents page fetch was projected down to the fields it derives from and reused across both time windows, and a composite index was added for the board-scoped fetch. Metrics now load once per visit on the connected mount rather than on every mount.

Wait Time metrics reported zero for every summary value

The Wait Time page's summary figures were all zero regardless of data. They now reflect real measurements.

A goal's column no longer goes stale when its children change

Adding an existing task to a goal, or creating a child under a goal already in Done, left the parent goal in the wrong column. The parent's column is now recalculated in both cases.

Auth pages showed a stale top nav

The registration, login, and confirmation pages rendered the old root-layout navigation instead of the homepage nav.

Reassign and reprioritize a goal without leaving the Agents page

The Agents page gained in-page interventions: Reassign moves an unstarted goal to a different agent, and Reprioritize changes its priority, each behind a confirmation dialog and an undo window. Both operations are concurrency-safe and only apply to unstarted work, and both are gated on being the target owner or the board owner. Agent claim order was verified and regression-tested to respect priority, so a reprioritization actually changes what gets picked up next.

User administration

A new admin-only User Administration page lists every user with per-user actions: disable, enable, resend confirmation, and delete. Disabled accounts are blocked from logging in and have their existing sessions invalidated. The page shows per-user activity metrics and a Created column, and the older LiveDashboard user-activity report was removed in favour of it.

Archive a delivery target

Delivery targets can now be archived once complete, with a dedicated Archived Targets page and an Unarchive action, both owner-gated.

Authentication surfaces are rate limited and audited

Rate limiting was added to the authentication surfaces, and security audit logging now records authentication and authorization events. A systematic authorization sweep went through every LiveView event handler, and a host allow-list was added for task diff URLs. A scheduled dependency-audit CI run was added.

A large security-remediation wave

Roughly two dozen findings from the security review were remediated. The most significant: sudo re-authentication was restored on account settings and password/email change — it had been defined but silently dropped from the router by an unrelated earlier change, so a borrowed session or stolen remember-me cookie could change a password or email with no re-auth. Beyond that: authentication emails are delivered asynchronously to close a timing-based user-enumeration channel; active LiveView sessions are disconnected on password reset; the session cookie is marked Secure in production; the audit-log sensitive-key filter became substring-based so credential-shaped keys it never anticipated are redacted; the numeric API task lookup is board-scoped, closing a 403-vs-404 existence oracle; and API token authentication returns a uniform error rather than distinct state strings. Dependency bumps cleared three CVEs in mint, including an HTTP response-smuggling issue.

Review diffs showed the wrong task's files

A hook-uploaded changed_files payload could surface another task's diffs in review. Alongside that fix, a review-bound task completing with an empty changed_files is now detected and flagged, the review UI renders an explicit diff-unavailable state with a re-fetch action instead of a blank panel, and a supported backfill path with alerting was added.

Confirmation emails never arrived

New users were not receiving the confirmation email after registration. The delivery failure is now surfaced rather than swallowed, and SMTP TLS hostname verification was corrected.

Delivery Targets

A delivery target is a named, dated commitment owned by a user, to which goals are assigned. Targets are board-scoped with full CRUD, a strip on the boards page showing each target's status at a glance, a create/edit page for managing goal assignment, and a detail page with a progress hero — aggregate percentage, segmented progress bar, status badge — above a table of member goals showing per-goal progress, count, priority, and owner. On-track status is derived from the member goals rather than entered by hand.

The Agents page was restructured around delivery

The Agents page was reframed delivery-first: a delivery-health band at the top, an explainer for why a target is at risk, and a roster annotated with the targets each agent is working toward and ordered risk-first. A delivery rollup derives the agent-to-target bridge that makes this possible.

A second security-remediation wave

API tokens gained expiration — a nullable expiry with a 90-day default on new tokens, enforced at authentication, with existing tokens unaffected. Password-reset tokens were shortened to a dedicated one-day window. The email-confirmation gate is now enforced in admin and sudo authorization paths. Live board-write authorization was added to the API unclaim, create, update, and after-goal endpoints, and modify-access is enforced on the task create/edit save path. Path traversal in changed_files paths is rejected, the content-security policy was tightened with base-uri, form-action, and object-src, production database connections are guarded against cleartext to a public host, and the development secret-key placeholder now fails closed for a running server.

The Agents page was slow, reloaded continuously, and could crash

The Agents page suffered an unbounded fetch, a global refresh, and an N+1 — together producing slow loads, continuous re-loading, and a crash loop in production, plus a SQL error in the delivery rollup's task fetch. It also attributed tasks to the wrong goal for agents working across several goals. All were fixed.

Target status disagreed with itself

The boards page and the Agents delivery band reported different statuses for the same target, archived goals were not counted as complete in the progress view, and target goal rows showed unassigned instead of the agent who worked the goal.

Flash messages were unreadable

Flash messages rendered with a near-transparent, low-contrast background.

A returning-user resend journey

An unconfirmed account attempting to log in is now redirected to a confirmation-pending page where the confirmation email can be resent, with an email-entry fallback and a link from the login page, so a user whose confirmation email went missing has a way back in.

Ten-part security review

The application was reviewed end to end against a documented scope inventory: authentication and session management, API token authentication and capability authorization, IDOR and cross-board access scoping, injection and data-access safety, cross-site scripting and output encoding, input validation and file-path handling, secrets and deployment configuration, dependencies and supply-chain risk, and server-side request forgery in the hook and file transports. Findings were triaged and prioritized; remediation ran through the following releases.

The first remediation batch landed here: live board-access enforcement on agent claim and complete, a scheme allow-list on review diff URLs, metric-parameter validation in the PDF and Excel exports, changed_files write authorization scoped to the assignee or reviewer, an owner gate on board member search, a hardcoded audit credential moved to environment variables, and mass-assignment blocks on the column and message changesets. Base images in the Dockerfiles were digest-pinned and the Chrome install hardened.

Responsive layout audit across every page

Every surface was audited for responsive layout at the project's breakpoints — global navigation and the sidebar drawer, authentication pages, the boards index and board form, the kanban board view and its column scrolling, board modals, the task form and detail view, goal detail, the metrics landing and chart pages, agents and the review queue, and the archive, resources, issue, and admin pages — followed by a cross-page regression sweep.

Internal: large modules split along their seams

Several oversized modules were broken up: metrics queries moved out of LiveViews into a Kanban.Metrics.TaskQueries context and workspace functions into Kanban.Metrics.Workspace; the API TaskController shed its changed-files transport decoding, param filtering, and batch goal creation; Kanban.Tasks.Task's validation helpers were split into focused modules; BoardLive.Show shed task-card presentation, goals-strip computation, and API token management; and ReviewLive's inline render moved to a co-located template with its acceptance-criteria and verdict helpers extracted. credo --strict was added to the precommit alias.

Elixir 1.20 and Erlang 28.5

The project was upgraded to Elixir 1.20 on Erlang 28.5, with the compiler warnings the new version surfaced fixed.

Over-length field values crashed instead of returning a validation error

A value exceeding a length-bounded column raised a Postgrex error rather than a validation failure. Over-length values are now translated into a 422 at the task API boundary, and a regression guard ensures every length-bounded column has a matching changeset validator.

Agents throughput cards followed the wrong control

The Agents page throughput cards were driven by the page time-range selector when they should not have been. Board and time-range filter placement was also standardized across the Agents and Metrics views.

Filter the archive by assignee, date range, and name

The archive filter row gained three working filters that compose with each other and with the existing reason filter. An Assignee chip opens a dropdown of the board's archived assignees — each with an avatar and name, plus an "Unassigned" option and an "All assignees" reset — and narrows the list to the chosen person. A Date range chip opens a popover with From/To date inputs and Apply/Clear buttons that limit the list to tasks archived within an inclusive range. And a live name search box filters by task title as you type (debounced), with a clear (×) affordance and a search-aware empty state that names the term you searched. All four dimensions — reason, assignee, date range, and search — apply together and survive live updates.

Export the archive to CSV

The footer's "Export CSV" button was a "coming soon" placeholder; it now downloads a real CSV of the board's archived tasks (Identifier, Title, Type, Goal, Assignee, Archive Reason, Archived At, Archived By). The export is an authenticated, board-scoped download that mirrors the existing metrics-export pattern, and the generated file is RFC-4180 quoted/escaped and neutralized against spreadsheet formula injection.

Expand or collapse every goal group at once

A control in the archive header collapses every goal group — including the "Tasks Without Goals" group — so you can scan the list of goals, or expands them all to see every archived task. It reuses the per-group chevron state, so it composes with collapsing or expanding individual groups, and hides itself when there are no collapsible groups.

Archived tasks are grouped and collapsible by goal

The archive was reorganized around goals. Archived rows are grouped by their goal, the goal's own archived row carries a collapsible chevron (no more duplicated header line), and the "Tasks Without Goals" group sits at the top. Goal rows are tinted with the same soft violet as the board's goal cards for visual continuity. The earlier month-section grouping was removed in favor of this flat, goal-grouped list.

The filter row now shows only filters that work

The archive previously offered Cancelled, Won't do, Duplicate, and Deferred reason filters that nothing in the UI could ever populate, so they sat permanently empty; those were removed, leaving All and Completed. The decorative Goal placeholder chip was removed, and the Date range placeholder became the real filter described above. Tasks archived with any of the removed reasons still appear under "All" — no data is hidden.

Internal: the archive filter pipeline moved into its own module

As the filtering grew to four composed dimensions, the reason/assignee/date-range/search filters and their input coercion were extracted from the LiveView into a dedicated KanbanWeb.ArchiveLive.Filters module, keeping the LiveView under the size cap and making the pure filter logic unit-testable on its own.

The footer no longer claims a read-only rule the system doesn't enforce

The archive footer stated that items become "read-only after 180 days," but no such rule exists — archived tasks remain restorable and deletable by anyone with edit access regardless of age. The copy was corrected to describe the actual behavior.

The Agents page is now a fleet console

/agents was redesigned around actually operating a fleet rather than glancing at a list. The roster now attributes each agent to its human owner (derived from the task's created_by/completed_by), so two agents that share a model name are no longer indistinguishable, and it is sorted by most recent activity instead of alphabetically. Roster cards are clickable with a selected state, and selecting an agent filters the activity feed; the kind filter and the per-agent filter compose, and a clear/deselect affordance resets either dimension.

A fleet-health rollup summarizes the fleet at a glance — working, idle, and stuck counts, with stuck surfaced as an explicit overlay — and a collapsible Dormant agents group classifies agents that have gone quiet, with their last-active time. The Delivery-trends band at the top was rebuilt to remove dead whitespace: a taller bar chart, enlarged stat values and labels, a prior-period trend indicator on the Completed-throughput figures, and the duplicated "Cycle time · avg" stat removed.

Selecting an agent opens a per-agent detail panel with collapsible category sections, a daily-activity sparkline, and a success-rate donut. The activity feed shows each row's avatar and owner, renders times in the user's timezone, and groups rows by date. The page is now mobile-friendly with a corrected scroll and a responsive layout.

The Workspace Metrics dashboard gained working controls and readable charts

/metrics picked up the controls its toolbar had only mocked. A session-only board selector scopes the workspace view to chosen boards (backed by a new board_ids filter on Kanban.Metrics.scoped_board_ids/1), and the "Last 14 days" button is now a real time-range selector driven by a configurable :window_days option threaded through the workspace metrics reads. The non-functional Filter placeholder button was removed.

The charts became legible: the Throughput chart now plots per-day values with x-axis date labels and a y-axis scale, the Cumulative flow chart gained a y-axis scale, and the workspace cycle-time chart was simplified to a single cycle-time series.

Agents and Metrics compute every date on the viewer's local clock

Both pages previously bucketed by UTC / SQL DATE(completed_at), so "today" and the day columns could be off by a day for anyone west or east of UTC. The browser timezone is now captured and threaded through the Agents and Metrics LiveViews and their context reads, and day-bucketing — throughput buckets, the dashboard's day grouping, the metrics window boundaries, and completion grouping — was converted to local time. The shared local-timezone helpers were extracted from /agents into reusable modules so both pages share one implementation. On /agents, the two "Completed today" figures that could disagree were reconciled to a single local-timezone computation, and the header today-counters were made timezone-aware (with cycle time scoped to today). A cross-timezone regression suite was added and every metrics calculation audited for correctness.

Internal: Agents and Metrics contexts refactored

Kanban.Agents was split into focused modules — Roster, Events, Detail, and Metrics — as the page's derivations grew. The per-metric LiveViews were deduplicated behind a shared load_data flow and a shared legend_swatch component, a shared board-scope query helper was extracted across the agents, archives, and reviews contexts, and the minutes-to-duration formatters were consolidated behind one shared helper with per-site variants.

Email confirmation is now required to sign in

Registration no longer logs the user in. Creating an account sends a confirmation email and lands the browser on a new public confirmation-pending page that shows the destination address, explains that the account has no access until the emailed link is clicked, and offers a resend button — throttled against abuse and deliberately neutral about whether an address has an account, so the endpoint cannot be used to enumerate emails or bomb arbitrary inboxes. The gate is enforced at every entry point: signing in with correct credentials is denied while the account is unconfirmed (with an explanatory message, and without issuing a session or remember-me cookie), and a pre-existing session for an unconfirmed account is turned away from authenticated pages by both the router plug and the LiveView mount hook, so neither full-page requests nor live navigation can slip past. The denial message appears only after the password has verified, keeping the login form enumeration-safe.

Accounts created before the gate shipped never needed to confirm, so a data migration grandfathers them in as confirmed — existing users sign in exactly as before, while every account registered after the deploy goes through the email step. An end-to-end integration test locks the whole journey together (register, pending page, blocked login, confirmation link, onboarding, successful sign-in), and docs/AUTHENTICATION.md now documents the flow.

The post-confirmation page is a getting-started onboarding experience

Clicking a valid confirmation link no longer dead-ends on a bare "account confirmed" message. The page now walks a new user through getting productive as ordered steps: a copy-paste prompt for their coding agent that points at the /api/agent/onboarding endpoint to scaffold the .stride_auth.md and .stride.md configuration files (with a one-click Copy button), signing in, creating a first board, generating an API token — with navigation copy matching the real UI (the Tokens tab on an AI-optimized board) and a reminder that the token value is shown only once — and inviting team members. The board-creation, API-authentication, and team-member steps each link to their resources guide, opening in a new tab so the user keeps their place. Invalid and already-used confirmation links still redirect to the login page with their existing messages, and the single-use confirmation token never appears in the page or its URLs.

Auth pages now display their status messages

The sign-in, registration, forgot/reset-password, confirmation, and confirmation-pending pages render inside a custom auth frame that never displayed flash messages — even the long-standing "Invalid email or password" denial was invisible, leaving every failed attempt looking like a silent bounce back to a blank form. The frame now renders error and info banners using the theme's contrast-checked status tokens, so denial reasons, confirmation notices, and resend feedback are actually visible in both light and dark mode.

All new user-facing copy across these flows is translated in the six non-English locales (de, es, fr, ja, pt, zh).

Terms of Service and Acceptable Use Policy pages

The registration form's consent checkbox ("I agree to the Terms of Service and Acceptable Use Policy — including the agent-action attribution clause") previously pointed both policy links at the Privacy Policy page, and the clause it names was not written down anywhere. Two new public pages now back that checkbox: /terms and /acceptable-use, both rendered under the marketing layout alongside /privacy and covered by controller tests.

The Terms of Service carries the standard sections — the service, accounts, content ownership (with an explicit commitment that workspace content is never used to train AI models), acceptable use (incorporating the AUP by reference), fees, termination, disclaimers, and limitation of liability — plus the binding definition of the agent-action attribution clause: every action an AI agent takes with an API token issued from an account (claiming a task, completing work, running a hook, posting a comment) is attributed to that account, and the holder accepts responsibility for it as if they had performed it themselves. The Acceptable Use Policy enumerates prohibited uses (illegal activity, security compromise, harming others, spam and malware, IP infringement, impersonation) and restates the attribution rule from the enforcement side — an agent acting outside the policy is a violation by the token-issuing account, even when the behavior was unintended — alongside API fair-use limits and the enforcement and reporting process.

Both registration checkbox links now navigate to the real pages, and all visible copy on both pages is fully translated in the six non-English locales (de, es, fr, ja, pt, zh).

Review queue: server-enforced review reports, richer detail pane, and reliable diffs

A series of changes since 2.3.0 hardened the review queue end to end. The "fully populated review report" guarantee moved off the agent plugins and onto the server: the completion endpoint now rejects a dispatched review whose structured report is incomplete or inconsistent with the task it describes — including project checks that don't cover the full CODE-REVIEW.md checklist — and the queue renders explicit warnings for any remaining gap. This closed the recurring defects where project checks arrived truncated and security considerations came back "not assessed" on tasks that had supplied them.

The detail pane became richer and more truthful: new Security considerations and Review checks sections render alongside acceptance criteria, the code-review panel shows every project-check row, review status is derived from the reviewer's structured verdict instead of inferred from legacy issue counts, approved reviews no longer repeat their summary and report body, and raw JSON payloads are no longer rendered.

Per-file diffs are now delivered reliably and read cleanly: an optional base64 transport envelope on the changed-files endpoint lets code-bearing diffs through the production edge filter that was silently rejecting them, and the diff panel's highlighting and line spacing were tightened so patches read like blocks of source.

Strict completion validation is now the production default

The /complete endpoint's hard gate on explorer_result and reviewer_result — the API-level enforcement that rejects completions lacking evidence that exploration and review happened — now runs in strict mode by default in production. Through the grace-period soak the :strict_completion_validation flag defaulted to false, so validation failures were logged but the request still proceeded; with the soak complete, config/runtime.exs now defaults the flag to true whenever the app boots in the :prod environment. Development and test environments are unaffected and continue to run in grace mode.

The STRIDE_STRICT_COMPLETION_VALIDATION environment variable remains an explicit override in both directions: setting it to false is the emergency rollback (production drops back to grace mode on restart, with no schema migration to reverse), and setting it to true forces strict mode in any environment. The rollout record and rollback plan are documented in docs/stride-plugin-enforcement-recommendations.md, where "API-Level Enforcement" has moved from Remaining Recommendations to the Implemented section.

Stride plugin code-review results now display on the review queue

When the stride plugin's task-reviewer agent reviews a task before completion, the verdict it produces — submitted as the reviewer_result field on PATCH /api/tasks/:id/complete — is now rendered in the app instead of living only inside the API payload. A new shared component surfaces it on the Review Queue for the selected task, and the same panel is embedded in the task-detail review section and the agent-handoff completion view, so a reviewer sees the same report wherever a task is inspected.

The panel chooses one of three render branches from the task's review fields:

• Structured — when reviewer_result carries a structured payload, it renders the reviewer's findings grouped by severity (Critical / Important / Minor), each issue showing its category (correctness, security, testing, …) and description, so a human can scan what the automated review flagged at a glance.
• Fallback — when only the legacy review_report markdown is present, it renders that report as formatted HTML (via Earmark).
• Empty — when a task has neither field, the panel renders nothing, so callers can embed it unconditionally.

after_goal hook gates goal completion on agent confirmation

Stride goals now stay out of the Done column until the agent that completed the goal's last child task reports back that its after_goal hook ran successfully. When a child completion (via PATCH /api/tasks/:id/complete or PATCH /api/tasks/:id/mark_reviewed) is detected as the goal's last open child, the parent goal flips into a new :pending after_goal state inside the same transaction as the child update — the goal is no longer auto-promoted to Done the instant its last child closes. The completion response includes an after_goal hook envelope so the agent knows to execute the project's after_goal script (e.g. release notes, deploy, post-goal cleanup) and POST the result back. A successful report (exit_code: 0) promotes the goal to Done and records the agent-reported result; a failure leaves the goal pending so a human can intervene.

Concurrent sibling completions are serialized by a row-level lock on the parent goal in Kanban.Tasks.GoalCompletion, so exactly one sibling sees :last_child even when many close simultaneously — duplicate after_goal envelopes are not possible.

For backwards compatibility with agent plugins that don't yet speak the after_goal protocol, an Oban-scheduled grace worker (Kanban.AfterGoal.GraceWorker, configurable via :after_goal_grace_window_seconds, default 5 minutes) promotes any still-pending goal to Done with a synthetic success result. This is a back-compat fallback, not the happy path — the latest agent plugin (stride-marketplace ≥ 1.7.0) is required to participate in the hook proper and avoid the grace-window delay on goal closure.

The workspace metrics dashboard gains two tiles for tracking the rollout: after_goal adoption over the trailing 7 days (distinct boards with at least one non-grace-worker report) and goal-to-Done latency percentiles (p50 / p95) over 14 days. Both queries structurally exclude the grace-worker synthetic attempt so adoption isn't inflated by the fallback path. A new [:kanban, :api, :after_goal_delivered] telemetry event fires from the single chokepoint reached by both completion endpoints; the grace worker bypasses it.

Database: new after_goal_* tracking columns on tasks (added by 20260522015833_add_after_goal_tracking_to_tasks) and the standard Oban jobs table (20260522015418_add_oban_jobs_table).

Review queue diff panel now renders patch content

The per-file diff area on /review (KanbanWeb.ReviewDiffPanel.diff_content) now renders unified-patch text with terminal-style row spacing (line-height: 1.1) and theme-aware add/del highlighting. Added rows render against the existing green --st-done-soft token; deleted rows continue to use --st-blocked-soft. Both classes consume CSS custom properties (--stride-diff-add-bg, --stride-diff-del-bg) so the highlight reads strongly in light mode and switches to a higher-chroma overlay (oklch(30% 0.09 155 / 0.55) / oklch(32% 0.10 25 / 0.55)) under [data-theme="dark"] where the previous soft tokens were too desaturated to read against the dark sunken surface.

Diff-header lines (---, +++) now classify as del and add instead of a separate file class, so the file-pair header band itself shows the same red/green tinting as its hunk body — the eye picks up which side of the diff each line belongs to at a glance.

Blocked indicator on task cards

Task cards in any column now show a small red 🚫 icon next to the priority dot in the top row when Task.status is :blocked. The other Task.status values (:open, :in_progress, :completed) render nothing. The icon uses the existing --st-blocked accent token so it shares the visual language of WIP-limit-exceeded and changes-requested cues, sized to 10×10px so the top row stays compact. A "Blocked" tooltip and matching aria-label provide hover and screen-reader context.

No new fields or context calls — :status already rides on the card via Map.from_struct(task) in task_card_data/4. Three new tests cover the rendering (positive case, :in_progress negative, status-absent negative).

Goal show page groups children by column instead of status

The per-section grouping on /boards/:id/goals/:goal_id now buckets each child by the workflow column it currently lives in (Backlog / Ready / Doing / Review / Done) rather than by Task.status. The dedicated "Blocked" section introduced in 2.0.1 is gone — blocked children now appear inside whichever column section they sit in (Backlog, Doing, etc.) with the new per-card "Blocked" pill flagging their state. This collapses two related but separate axes (workflow stage vs. blocked-ness) into the single visual layout the rest of the app already uses.

Implementation: Tasks.Queries.list_children_for_goal/2 now preloads :column alongside :assigned_to and :parent. KanbanWeb.GoalLive.Show replaced group_by_status/1's Task.status reducer with a new bucket_for/1 helper that maps task.column.name to the section atom. The :blocked plumbing added to @status_order, status_label/1, status_dot/1, and flow_key/1 in 2.0.1 has been reverted since blocked tasks no longer need a separate bucket. build_flow/1 simplified back to Map.new/2 (the multi-status-to-one-key collision the 2.0.1 reduce guarded against can't happen with the column-keyed groups).

Goal show page hid blocked child tasks

Children of a goal whose Task.status was :blocked never rendered on /boards/:id/goals/:goal_id. The page's @status_order enumeration in KanbanWeb.GoalLive.Show included [:backlog, :ready, :in_progress, :review, :completed] but omitted :blocked — status_sections/1 only emits a section for statuses in the order list, so any blocked child fell off the page silently even though the underlying Tasks.list_children_for_goal/2 query returned it correctly.

:blocked is now in @status_order and renders as its own "Blocked" section using the existing --st-blocked accent token. flow_key(:blocked) rolls blocked work into the :backlog segment of the progress bar so the existing GoalProgressHeader flow-key contract (backlog / ready / doing / review / done) is preserved. build_flow/1 was rewritten with Enum.reduce + Map.update so multiple statuses mapping to the same flow key now sum their counts instead of clobbering each other — without this, routing :blocked to :backlog would have silently overwritten the real backlog count.

No data, API, or storage changes — the database always had blocked children, the goal page just wasn't rendering them.

New Agents view at /agents

Workspace-level page that surfaces every AI agent active across the user's workspace in one place. Composes three new presentational components — KanbanWeb.AgentsHeader, KanbanWeb.AgentRosterCard, and KanbanWeb.AgentActivityFeed — into a two-column layout: the agent roster on the left (status, current task, recent throughput, capabilities) and a chronological activity feed on the right (claims, completions, hook results) windowed to the last 24 hours.

KanbanWeb.AgentsLive is a thin LiveView binding the Kanban.Agents context output to the components — no Ecto queries in the LiveView module per the project's separation rule. Real-time updates flow over the "agents" PubSub topic; a debounced refresh (@refresh_debounce_ms = 250ms) coalesces bursts of {:agent_event, _} broadcasts so a flurry of completions does not redrive the agent queries on every message. KanbanWeb.AgentsPresence powers a "live · N connected" indicator showing how many agent sessions are currently online.

The page supports filter tabs (:all, :online, plus per-capability filters) routed through handle_event/3 and persisted in the URL via push_patch. Auth lives in the :require_authenticated_user live_session — workspace data is never served to anonymous visitors.

New Review queue at /review

Workspace-level review queue replacing the per-board "tasks in Review" scrolling list. A two-pane layout: the queue list on the left (one KanbanWeb.ReviewQueueItem per pending task with a stats strip showing acceptance-criteria coverage, issue count, and reviewer dispatch state), the selected task's full detail on the right (KanbanWeb.ReviewDetailHeader, KanbanWeb.ReviewStatsStrip, KanbanWeb.ReviewDiffPanel, the existing KanbanWeb.AcceptanceChecklist).

KanbanWeb.ReviewLive is a thin binding layer — all reads route through Kanban.Reviews.list_pending_reviews/1 and Kanban.Reviews.queue_stats/1; approve and request-changes mutations route through Kanban.Reviews.approve_review/3 and Kanban.Reviews.request_changes_review/3. No Ecto queries live in the LiveView module.

The Review page renders structured reviewer_result payloads (see the structured review-report contract below) when present, falling back to the legacy markdown review_report regex extraction for tasks completed before the rollout. Tasks completed via the no-subagent skip-form render via the existing summary-and-skip-reason layout. The render branch is detected via if reviewer_result["issues"] is a list → structured; elsif review_report is non-empty → markdown fallback; else → empty so old archived tasks keep displaying acceptably indefinitely.

Approve and request-changes are both single-click; request-changes opens an inline form (no modal navigation) that posts back into the same LiveView.

Marketing and auth surface refresh

Six marketing-site pages — landing, about, resources index, resources show, product, workflows, security, privacy — rebuilt against a shared editorial design language. New KanbanWeb.AuthFrame component standardizes the four auth surfaces (sign in, sign up, forgot password, reset password) on the same card-based layout. KanbanWeb.UserLive.Settings redesigned to use the same auth-card pattern. Every screen now passes dark-mode contrast verification: light text (oklch ~0.97) on dark backgrounds (oklch ~0.30) in dark mode, dark text (oklch ~0.21) on light backgrounds (oklch ~0.98) in light mode. The dark-mode color map (theme-aware daisyUI tokens — text-base-content, bg-base-100, border-base-300) replaces hard-coded greys across every converted template.

The login screen is now fully responsive (mobile-first layout, breakpoint-aware spacing). Avatars across the board view display the owner's name on hover. Drag-and-drop on the board has been substantially improved — fewer jitter cases on column boundary crossing, smoother re-flow of remaining cards.

Structured review-report contract (G143 server-side)

Kanban.Tasks.CompletionValidation now optionally accepts a structured reviewer_result payload alongside the legacy summary + integer-counts shape. New fields: schema_version (semver string), status, issue_counts, issues[] (with severity ∈ critical|important|minor and category ∈ acceptance_criteria|pitfall|pattern|testing|code_quality), acceptance_criteria[] (with status ∈ met|not_met — underscore form), and three section verdicts testing_strategy / patterns / pitfalls (each {status, notes?} with status ∈ passed|failed|not_assessed). All fields are optional — legacy payloads continue to validate unchanged. Unknown fields per entry are tolerated for forward compatibility. The reviewer_result jsonb column persists the full payload verbatim; KanbanWeb.API.TaskJSON round-trips it without filtering or allowlisting.

Full schema documented in docs/api/patch_tasks_id_complete.md and via GET /api/agent/onboarding → api_schema.reviewer_result_format. Plugin variants are tracked under G144 — the server accepts payloads from any client emitting the new shape, and the UI degrades to the markdown fallback for tasks completed by older clients.

Goal-Driven Assignment Workflow (G88, G89, G90)

Three coordinated changes that make a goal's assigned_to_id a meaningful boundary across the goal's full lifecycle. Previously, assigning a goal to a person was a no-op for the children — they stayed unassigned, were claimable by any agent, and a freshly added child created a new assignment hole. With this release, "the goal owner owns the goal's work" is a real invariant maintained automatically.

Cascading goal assignment to existing children (G88)

When a goal's assigned_to_id is changed via the UI or API, the new assignment cascades atomically to every non-completed child task whose assigned_to_id differs from the new value. The cascade is performed inside an Ecto.Multi: goal update, all child updates, and per-task assignment_history rows commit together or roll back together. Each affected child broadcasts a task_updated event over PubSub so connected board LiveViews refresh in real time. Completed children are intentionally not touched. Unassigning a goal (setting assigned_to_id to nil) also propagates nil to children — the goal-mirrors-children model holds in both directions.

The form_component LiveView now shows a flash after a goal save indicating how many children were also re-assigned: "Task updated successfully. 3 child tasks were also updated." Translated via ngettext for all 7 supported locales. Suppressed when zero children were affected.

Restricting task claiming to the assigned user (G89)

Tasks with a non-nil assigned_to_id are now visible and claimable ONLY by the named user. GET /api/tasks/next automatically filters out assigned-to-others tasks for each agent. POST /api/tasks/claim against an explicit identifier assigned to another user returns 403 Forbidden with {"error": "This task is assigned to a different user"}. The gate is enforced atomically inside the SQL update_query of perform_claim/4, so two concurrent agents cannot race past it. Unassigned tasks (assigned_to_id IS NULL) remain claimable by anyone — fully backwards compatible.

A new error variant :assigned_to_other_user is documented in the agent onboarding catalog (agent_json.ex common_mistakes_agents_make) with a corresponding ErrorDocs clause linking to the AI workflow guide. Recommended remediation: skip the task and call GET /api/tasks/next again — the queue endpoint automatically excludes assigned-to-others tasks.

Inheriting goal's assignment when a new child is added (G90)

When Tasks.create_task/2 is called with a parent_id referencing an assigned goal AND attrs do NOT explicitly set assigned_to_id, the new task inherits the goal's assigned_to_id at creation time. The same rule applies to children created inside Tasks.create_goal_with_tasks/3. Explicit assigned_to_id values in attrs always win — including explicit nil — so the inheritance only fills the gap when the caller did not specify an assignee. Defensive against missing parent rows and non-goal parents: both are silent no-ops.

Prevent Agents from Bypassing Workflow via Column Reassignment

Agents were able to move tasks from Backlog directly to Ready by sending PATCH /api/tasks/:id with a new column_id, then claiming the task — bypassing the human review gate that gates which tasks are available for AI work. Two production incidents of this behavior were observed.

The API update endpoint now rejects any request that attempts to change a task's column_id, returning 403 Forbidden with a message directing callers to the proper workflow endpoints (claim, complete, mark_reviewed, mark_done). Echoed matching values are silently stripped so honest round-trip clients are unaffected. A new [:kanban, :api, :task_update_column_change_forbidden] telemetry event fires on every rejected attempt for monitoring.

Column transitions for agents are now strictly limited to:

• POST /tasks/claim — Ready → Doing (still verifies the task is in Ready)
• PATCH /tasks/:id/complete — Doing → Review
• PATCH /tasks/:id/mark_reviewed — review approval
• PATCH /tasks/:id/mark_done — → Done

Human users dragging tasks in the LiveView UI are unaffected — that flow uses a separate code path and is not subject to the restriction.

Stride Workflow Orchestrator and Enforcement Gates (All Plugins)

• New stride-workflow orchestrator skill — A single skill that replaces the pattern of remembering to invoke 6+ separate skills at specific moments. Agents invoke it once and follow the complete lifecycle: claim → explore → implement → review → hooks → complete → loop. Includes a decision matrix for when to explore, plan, and review based on task complexity and key_files count. Platform-adaptive with dual paths for Claude Code (subagent dispatch) and other environments (manual exploration/review).
• Claiming gate — All claiming skills now include a non-negotiable "YOUR NEXT STEP" section demanding stride-workflow invocation after claiming. Catches agents that skip the orchestrator.
• Completion verification checklist — All completing skills now include a 4-item checklist before the completion endpoint: (1) Did you activate stride-workflow? (2) Did you explore the codebase? (3) Did you review changes against acceptance criteria? (4) Are you ready for the after_doing hook?
• Reframed automation notices — All AUTOMATION NOTICE sections rewritten from "work continuously without stopping" to "the workflow IS the automation — every step exists because skipping it caused failures."

Three layers of defense-in-depth: orchestrator guides every step → claiming gate catches orchestrator skippers → completion checklist catches everyone else.

Plugin Releases

Generic Skills for File-Based Platforms (Cursor, Windsurf, Continue.dev, Kimi Code)

Cursor, Windsurf, Continue.dev, and Kimi Code do not support dedicated plugin repos — they use file-based skill discovery. Previously, these platforms were told to install 4 generic Claude Code skills with no stride-workflow, no enforcement gates, and no enriching/subagent-workflow skills.

• 7 generic SKILL.md files hosted at docs/multi-agent-instructions/skills/ — tool-agnostic versions of all Stride skills adapted from the v1.7.0 plugin, including stride-workflow orchestrator with all enforcement enhancements. Each file has compatibility: cursor, windsurf, continue, kimi frontmatter and dual-path design (Claude Code subagent dispatch vs. manual exploration/review).
• Onboarding endpoint enhanced — The GET /api/agent/onboarding response now provides platform-specific download instructions:
  • Cursor: skills_provided with all 7 skills, curl download commands for .cursor/skills/, PowerShell Windows commands
  • Windsurf: Same pattern with .windsurf/skills/ paths
  • Continue.dev: Same pattern with .continue/skills/ paths (Continue.dev added SKILL.md support in Jan 2026), existing config.json preserved as supplemental
  • Kimi Code: Enhanced AGENTS.md with condensed orchestrator steps, 4-item verification checklist, and process-over-speed messaging
• claude_code_skills.skills_included updated from 4 to 7 skills. All usage_notes and memory_strategy entries updated. All "4 skills" references replaced throughout.

Stride OpenCode Plugin (stride-opencode)

Full Stride plugin for OpenCode, providing 6 skills, 4 agents, and a native TypeScript plugin for automatic hook execution. Published at cheezy/stride-opencode.

• TypeScript plugin — Native hook execution engine using OpenCode's tool.execute.before and tool.execute.after events. Automatically detects Stride API calls, routes to the correct .stride.md section, and executes commands sequentially. Blocks completion on after_doing failure.
• .stride.md parser — Dedicated parser module handling CRLF/LF line endings, empty code blocks, comments, adjacent sections, and files without trailing newlines.
• Environment variable caching — Automatically extracts task metadata from claim API responses and makes them available in subsequent hooks within the same session.
• 6 OpenCode-adapted skills — All Stride workflow skills ported with OpenCode frontmatter, tool names, and tool.execute.before/tool.execute.after hook event references.
• 4 custom agents — Task explorer, reviewer, decomposer, and hook diagnostician with OpenCode agent frontmatter.
• npm distribution — Installable via opencode.json plugin array or locally via install script.
• 49 passing tests — Comprehensive test suite using bun:test covering parser, hook routing, command filtering, and environment extraction.

Stride Codex CLI Plugin (stride-codex)

Full Stride plugin for OpenAI Codex CLI, providing 6 skills and 4 subagents with manual hook execution. Published at cheezy/stride-codex.

• 6 Codex-adapted skills — All automatic hook sections removed — manual hook execution is the only path. Skills instruct the agent to read .stride.md and execute each command directly via shell.
• 4 subagents — Task explorer, reviewer, decomposer, and hook diagnostician with Codex agent frontmatter.
• Install script — One-liner installation supporting global (~/.agents/) and project-local (.agents/) modes.
• AGENTS.md — Codex configuration bridge with skill activation rules, tool name mapping, and manual hook execution instructions.

Stride Copilot Plugin Updates (stride-copilot v2.0.0 → v2.1.0)

Restructured the Copilot plugin for copilot plugin install support and added automatic hook execution.

• Automatic hook execution — Added hooks/hooks.json and hooks/stride-hook.sh that intercept Stride API calls and execute .stride.md sections automatically.
• PowerShell support — Added hooks/stride-hook.ps1 companion script for native Windows. Platform detection auto-delegates from bash to PowerShell.
• Test suites — test-stride-hook.sh (67 tests) and test-stride-hook.ps1 (70 assertions) covering JSON extraction, parsing, integration, and edge cases.
• Repository restructured — Skills and agents moved from .github/ to root-level directories for copilot plugin install support.

Stride Gemini Extension Updates (stride-gemini v1.1.0)

Added automatic hook execution to the Gemini CLI extension.

• Automatic hook execution — Added hooks/hooks.json registering BeforeTool/AfterTool hooks on run_shell_command. All non-JSON output goes to stderr (Gemini requires JSON-only stdout).
• PowerShell support — Added hooks/stride-hook.ps1 for Windows compatibility with PowerShell 5.1+ and 7+.
• Test suites — test-stride-hook.sh (67 tests) and test-stride-hook.ps1 (70 assertions).
• GEMINI.md updated — Hook execution section now documents automatic hooks vs manual fallback.

Automatic Stride Hook Execution via Claude Code Hooks (Stride Plugin v1.5.0)

Stride .stride.md hooks now execute automatically through Claude Code's hook system, eliminating all permission prompts. Previously, every hook command (git pull, mix test, mix credo, git commit, etc.) triggered a CLI permission dialog because commands ran through Claude's Bash tool. The new system runs hooks as shell processes on the harness, bypassing the tool permission layer entirely.

• hooks/stride-hook.sh — Generic bridge script that parses any user's .stride.md file, detects Stride API calls in Bash tool commands, routes to the correct hook section, and executes each uncommented command sequentially. Exits 2 on failure to block tool calls in PreToolUse context.
• hooks/hooks.json — Plugin hook configuration that activates automatically when the Stride plugin is enabled. No user settings changes needed.
• Environment variable caching — Task metadata ($TASK_IDENTIFIER, $TASK_TITLE, $TASK_ID, etc.) is extracted from the claim API response and cached for use by all subsequent hooks in the lifecycle. Cache is cleaned up after the after_review hook.
• Structured JSON diagnostics — On both success and failure, the hook script emits structured JSON with hook name, command sequence, exit codes, and stdout/stderr. On failure, includes commands_completed, commands_remaining, and the specific failed_command for precise diagnosis.
• Hook-diagnostician update — The stride:hook-diagnostician agent now accepts both structured JSON from Claude Code hooks and raw text from the legacy agent-executed flow, with command sequence context (PASSED/FAILED/SKIPPED) in its fix plans.

Stride Copilot Extension (GitHub Copilot)

Stride skills have been ported to GitHub Copilot's agent mode, distributed as a .github/copilot-instructions.md configuration with prompt files. This enables Copilot-powered agents to follow the full Stride workflow (claim → implement → complete) with proper hook execution and API field formats.

• 6 Prompt Files — All six Stride workflow skills adapted for Copilot's prompt file system: stride-claiming-tasks, stride-completing-tasks, stride-creating-tasks, stride-creating-goals, stride-enriching-tasks, and stride-subagent-workflow.
• Copilot instructions file — .github/copilot-instructions.md bridge file with mandatory skill activation rules, workflow sequence, API authorization, and hook execution guidelines.

Stride Gemini Extension (Google Gemini CLI)

Stride skills and custom agents have been ported to Google Gemini CLI's extension format, distributed as a standalone repository installable via gemini extensions install. This brings full Stride workflow support — including custom agents for codebase exploration, code review, goal decomposition, and hook failure diagnosis — to Gemini CLI users.

• 6 Skills — All six Stride workflow skills adapted for Gemini CLI conventions: stride-claiming-tasks, stride-completing-tasks, stride-creating-tasks, stride-creating-goals, stride-enriching-tasks, and stride-subagent-workflow.
• 4 Custom Agents — Specialized Gemini CLI agents for task lifecycle support: task-explorer, task-reviewer, task-decomposer, and hook-diagnostician.
• GEMINI.md bridge file — Always-on context with skill activation rules, custom agent references, workflow sequence, API authorization, and tool name mapping table.
• Extension repository — Published at cheezy/stride-gemini with README, LICENSE (MIT), and CHANGELOG.

Review Report Field for Task-Reviewer Agent Traceability

• Review Report database field - Added review_report text column to the tasks table via Ecto migration, enabling structured review findings from the task-reviewer agent to be persisted on task records.
• Task schema and changeset - Added field :review_report, :string to the Task schema near existing review fields (review_notes, review_status). Included in both the general changeset cast list in task.ex and the complete_task cast list in agent_workflow.ex as an optional field (not in validate_required).
• API JSON serializer - Added review_report to the task JSON response in task_json.ex, placed between review_notes and reviewed_at for consistent grouping with other review fields. The field is returned in all task API responses (GET /api/tasks, GET /api/tasks/:id, GET /api/tasks/next, PATCH /api/tasks/:id/complete, etc.).
• Complete endpoint accepts review_report - The PATCH /api/tasks/:id/complete endpoint now accepts an optional review_report parameter, allowing agents to submit structured review findings at task completion time. Backward compatible — existing completions without review_report continue to work.
• Task detail UI display - Added a conditional review report section to the task detail ViewComponent, rendered between the Review Status and Completion sections.

Human Task Field

• Human Task database field - Added human_task boolean column to the tasks table (default: false), allowing tasks to be explicitly marked as requiring human workers rather than AI agents.
• Agent query filtering - AI agent task discovery (GET /api/tasks/next) now automatically excludes tasks marked as human_task: true, ensuring agents only claim work appropriate for automated processing. Both get_next_task and get_specific_task_for_claim queries enforce this filter.

Stride Plugin (Claude Code Marketplace)

Stride's Claude Code skills have been extracted from the project's .claude/skills/ directory into a standalone plugin distributed via the Claude Code marketplace (cheezy/stride-marketplace). This enables any project using Stride to install the skills with two commands instead of manually copying files.

• 6 Skills — The plugin ships with six mandatory workflow skills:
  • stride-claiming-tasks — Task discovery and claiming with before_doing hook execution and before_doing_result capture
  • stride-completing-tasks — Dual-hook completion workflow (after_doing + before_review) with all required API fields
  • stride-creating-tasks — Comprehensive task creation with validated field formats (verification_steps as objects, key_files as objects, testing_strategy with arrays)
  • stride-creating-goals — Goal and batch creation with correct "goals" root key and dependency management
  • stride-enriching-tasks — 4-phase codebase exploration that transforms minimal task specs into full implementation-ready specifications
  • stride-subagent-workflow — Decision matrix for dispatching exploration, planning, review, and decomposition agents based on task complexity
• 4 Custom Agents (Claude Code only) — Specialized subagents that handle focused tasks autonomously:
  • stride:task-explorer — Reads key_files, finds related tests, searches for patterns, returns structured codebase context before implementation
  • stride:task-reviewer — Reviews git diff against acceptance criteria, pitfalls, and patterns; categorizes issues as Critical/Important/Minor
  • stride:task-decomposer — Breaks goals and large tasks into dependency-ordered child tasks with full specifications
  • stride:hook-diagnostician — Parses hook failure output across 6 failure categories and returns a prioritized fix plan
• Mandatory skill chain — Skills enforce a strict invocation order: claiming → subagent-workflow → [implementation] → completing. Each skill documents the exact API fields and hook results required at that lifecycle point. Skipping a skill results in API rejections or hours of rework.
• Skills version tracking — All claim and complete API requests now include a skills_version field. The API returns skills_update_required when the agent's skills are outdated, prompting automatic plugin updates.
• All hooks now blocking — before_review and after_review hooks are now blocking (previously non-blocking). All four hooks must succeed before their associated API calls proceed.

Lean Metrics Dashboard System

• Comprehensive Metrics Dashboard - AI-optimized boards now feature a complete lean metrics tracking system for measuring and optimizing workflow performance:
  • Metrics Dashboard (/boards/:id/metrics) - Centralized overview displaying all key performance indicators with real-time data
  • Summary Cards - Four metric categories with at-a-glance statistics (average, median, P90)
  • Quick Navigation - Jump to detailed views for each metric category
  • Board Navigation - Easy return to kanban board from metrics views
• Throughput Metrics - Track task completion velocity over time:
  • Daily Completion Count - Number of tasks completed each day
  • Completion Trend Visualization - Line chart showing throughput patterns
  • Day-by-Day Breakdown - Expandable list of completed tasks grouped by date
  • Task Details - View identifier, title, complexity, agent, and completion time
  • Statistics - Average, median, and 90th percentile throughput calculations
  • Empty State Handling - Informative message when no completions exist
• Cycle Time Metrics - Measure time from work start to completion:
  • Doing → Done Duration - Track how long tasks spend in active development
  • Distribution Analysis - Understand typical cycle time patterns
  • Task-Level Details - View claimed time, completed time, and total duration
  • Agent Attribution - See which agent worked on each task
  • Statistics - Average, median, and P90 cycle time in hours/days
  • Grouped Display - Tasks organized by completion date
• Lead Time Metrics - Track total time from creation to completion:
  • Created → Done Duration - Full lifecycle tracking from backlog to done
  • End-to-End Visibility - Understand complete workflow efficiency
  • Task Timeline - View creation time, completion time, and total duration
  • Agent Tracking - Identify which agent completed each task
  • Statistics - Average, median, and P90 lead time calculations
  • Date Grouping - Tasks organized by completion date
• Wait Time Metrics - Identify human bottlenecks in the workflow:
  • Review Wait Time - Time tasks spend waiting for human review after completion
  • Backlog Wait Time - Time tasks spend in backlog before being claimed
  • Bottleneck Identification - Pinpoint where tasks wait for human intervention
  • Dual Wait Type Tracking - Separate views for review delays vs backlog delays
  • Task Details - View timestamps, durations, and responsible agents
  • Statistics - Average, median, and P90 wait times for each category
• Advanced Filtering System - Flexible data analysis across all metrics:
  • Time Range Filter - Today, last 7 days, last 30 days, last 90 days, or all time
  • Agent Filter - Filter metrics by specific AI agent (e.g., "Claude Sonnet 4.5")
  • Weekend Exclusion - Toggle to exclude weekends from calculations
  • Persistent Filters - Filter selections maintained across metric views
  • Agent Dropdown - Auto-populated with agents who have completed or created tasks

PDF Export for Metrics

• Print-Optimized PDF Export - Export all metrics to professionally formatted PDF documents:
  • Data Tables - Structured tables with all task details and metrics
  • Statistics Summary - Summary statistics prominently displayed in reports
  • Filter Preservation - Applied filters reflected in exported data
  • One-Click Export - Simple export button on each metrics page

GitHub Copilot, Cursor, Windsurf, Gemini, OpenCode, and Kimi Code CLI AI Assistant Support

Multi-Agent Integration Expansion - Added comprehensive support for GitHub Copilot agent skills, Cursor agent skills, Windsurf agent skills, Gemini Code Assist skills, OpenCode, and Kimi Code CLI (k2.5):

GitHub Copilot (Claude Code Skills Compatible):

• Uses Claude Code Skills: GitHub Copilot now automatically discovers skills in .claude/skills/ directories, eliminating the need for separate Copilot-specific content
• 4 Stride Skills: Reuses the same skills as Claude Code (stride-claiming-tasks, stride-completing-tasks, stride-creating-tasks, stride-creating-goals)
• On-Demand Loading: Skills are loaded when invoked, reducing token usage compared to always-active instructions
• Automatic Discovery: GitHub Copilot discovers skills in .claude/skills/ directories
• Zero Duplication: One set of skills works for Claude Code, GitHub Copilot, Cursor, Windsurf, Gemini, and OpenCode users
• Agent Skills Feature: Leverages GitHub Copilot's new agent skills capability announced December 2024

Cursor (Claude Code Skills Compatible):

• Uses Claude Code Skills: Cursor now automatically discovers skills in .claude/skills/ directories, eliminating the need for separate Cursor-specific content
• 4 Stride Skills: Reuses the same skills as Claude Code (stride-claiming-tasks, stride-completing-tasks, stride-creating-tasks, stride-creating-goals)
• On-Demand Loading: Skills are loaded when invoked, reducing token usage compared to always-active instructions
• Automatic Discovery: Cursor discovers skills in .claude/skills/ (and .cursor/skills/ or .codex/skills/) directories
• Zero Duplication: One set of skills works for Claude Code, GitHub Copilot, Cursor, Windsurf, Gemini, and OpenCode users
• Agent Skills Feature: Leverages Cursor's agent skills capability

Windsurf (Claude Code Skills Compatible):

• Uses Claude Code Skills: Windsurf now automatically discovers skills in .windsurf/skills/ directories, eliminating the need for separate Windsurf-specific content
• 4 Stride Skills: Reuses the same skills as Claude Code (stride-claiming-tasks, stride-completing-tasks, stride-creating-tasks, stride-creating-goals)
• On-Demand Loading: Skills are loaded when invoked, reducing token usage compared to always-active instructions
• Automatic Discovery: Windsurf discovers skills in .windsurf/skills/ directories
• Zero Duplication: One set of skills works for Claude Code, GitHub Copilot, Cursor, Windsurf, Gemini, and OpenCode users
• Agent Skills Feature: Leverages Windsurf's agent skills capability

Gemini Code Assist (Claude Code Skills Compatible):

• Uses Claude Code Skills: Gemini Code Assist now automatically discovers skills in .gemini/skills/ directories, eliminating the need for separate Gemini-specific content
• 4 Stride Skills: Reuses the same skills as Claude Code (stride-claiming-tasks, stride-completing-tasks, stride-creating-tasks, stride-creating-goals)
• On-Demand Loading: Skills are loaded when invoked, reducing token usage compared to always-active instructions
• Automatic Discovery: Gemini discovers skills in .gemini/skills/ directories with three-tier discovery (workspace, user, extension)
• Zero Duplication: One set of skills works for Claude Code, GitHub Copilot, Cursor, Windsurf, Gemini, and OpenCode users
• Agent Skills Feature: Leverages Gemini's agent skills capability following the Agent Skills standard

OpenCode (Claude Code Skills Compatible):

• Uses Claude Code Skills: OpenCode automatically discovers skills in .claude/skills/ directories, eliminating the need for separate OpenCode-specific content
• 4 Stride Skills: Reuses the same skills as Claude Code (stride-claiming-tasks, stride-completing-tasks, stride-creating-tasks, stride-creating-goals)
• On-Demand Loading: Skills are loaded when invoked, reducing token usage compared to always-active instructions
• Automatic Discovery: OpenCode searches .claude/skills/, .opencode/skills/, and ~/.config/opencode/skills/ directories
• Zero Duplication: One set of skills works for Claude Code, GitHub Copilot, Cursor, Windsurf, Gemini, and OpenCode users

Kimi Code CLI (k2.5):

• AGENTS.md Instruction File: Uses existing AGENTS.md file (~15KB, ~400 lines) with complete Stride integration guidelines
• Always-Active Loading: Instructions are loaded automatically when Kimi starts
• Append-Mode Installation: Can append Stride instructions to existing AGENTS.md content
• Project-Local: Installed in project root ./AGENTS.md

Onboarding Endpoint Integration: Updated GitHub Copilot, Cursor, and Windsurf formats, and added OpenCode and Kimi formats to /api/agent/onboarding multi_agent_instructions section with appropriate installation commands

Supported AI Assistants (8 Total):

1. Claude Code (Skills - claude_code_skills section)
2. GitHub Copilot (.claude/skills/<skill-name>/SKILL.md - uses Claude Code skills)
3. Cursor (.claude/skills/<skill-name>/SKILL.md - uses Claude Code skills)
4. Windsurf (.windsurf/skills/<skill-name>/SKILL.md - uses Claude Code skills)
5. Gemini Code Assist (.gemini/skills/<skill-name>/SKILL.md - uses Claude Code skills)
6. OpenCode (.claude/skills/<skill-name>/SKILL.md - uses Claude Code skills)
7. Continue.dev (.continue/config.json)
8. Kimi Code CLI (k2.5) (AGENTS.md)

Note: Claude Code has its own dedicated claude_code_skills section in the onboarding endpoint. The multi_agent_instructions section provides 7 formats for the other assistants. Claude Code, GitHub Copilot, Cursor, Windsurf, Gemini, and OpenCode share the same skill-based system with on-demand loading. Continue.dev and Kimi use traditional always-active instruction files.

Automatic Task Status Synchronization

Task Status Now Syncs Automatically When Moving Between Columns - Fixed data inconsistency issue where task status could be out of sync with column position:

• Ready/Backlog Columns: Automatically sets status: :open and clears completed_at
• Doing/Review Columns: Automatically sets status: :in_progress and clears completed_at
• Done Column: Automatically sets status: :completed and sets completed_at timestamp
• Preserves Timestamps: When task already has completed_at set, preserves the original timestamp
• Impact: Eliminates the inconsistency where agents sometimes failed to update status when completing tasks, ensuring column position and status always match

Read-Only Board Sharing

Public Board Sharing - Board owners can now share boards publicly for read-only access:

• Read-Only Checkbox: Added "Make board publicly readable" checkbox to board edit form
• Public Access: Any signed-in user can view boards marked as read-only

Google Gemini Code Assist Support

Multi-Agent Integration Expansion - Added comprehensive support for Google Gemini Code Assist as the fifth supported AI coding assistant:

• GEMINI.md Instruction File: Created Markdown-formatted instruction file with complete Stride integration guidelines
• Hierarchical Context Support: Supports project-scoped, global (~/.gemini/GEMINI.md), and component-level context files
• Impact: Gemini Code Assist users can now leverage Stride's workflow enforcement with agent/chat mode context files

Supported AI Assistants (Now 5 Total):

1. Claude Code (Skills-based, contextual)
2. GitHub Copilot (.github/copilot-instructions.md)
3. Cursor (.cursorrules)
4. Windsurf Cascade (.windsurfrules)
5. Continue.dev (.continue/config.json)
6. Google Gemini Code Assist (GEMINI.md or AGENT.md)

Task Priority Selection in /api/tasks/next Endpoint

Corrected Priority Sorting for Task Claiming - Fixed critical bug where the /api/tasks/next endpoint was selecting lower-priority tasks instead of higher-priority tasks:

• Impact: Tasks are now correctly selected in priority order: critical → high → medium → low
• Secondary Sort: Position (ascending) is used as tiebreaker when priorities are equal, ensuring tasks higher in the Ready column (lower position number) are selected first

Review Queue Section Visibility in Task Forms

Fixed Review Fields Not Appearing for Tasks in Review - Resolved issue where review status and review notes fields were hidden when tasks with needs_review=true entered the Review column:

• Root Cause: Visibility condition only checked if review_status field had a value, but newly moved tasks to Review column had nil review_status
• Impact: Users can now properly review and approve/reject tasks that enter the Review column

AI Agent Onboarding Documentation

Enhanced Getting Started Guide - Improved clarity in docs/GETTING-STARTED-WITH-AI.md for AI agent onboarding:

• Updated Instructions: Rephrased onboarding instructions to be more acceptable to Claude Code's security policies
• Multi-Agent Support: Added explicit mention of agent configuration setup and reference to Multi-Agent Instructions guide

Claude Code Skills for Automatic Hook Execution

Updated Hook Execution Instructions - Modified all four Claude Code Skills (stride-claiming-tasks, stride-completing-tasks, stride-creating-tasks, stride-creating-goals) in the onboarding endpoint:

• Automatic Execution: Added explicit instructions to execute hooks automatically without prompting the user
• Impact: Eliminates unnecessary user prompts during task claiming and completion, streamlining the agent workflow

Resources & How-To Guides Section

New Resources Landing Page - Comprehensive help center for learning Stride:

• Search Functionality - Real-time search across all guide titles and descriptions
• Tag-Based Filtering - Filter guides by category tags (getting-started, developer, non-developer, best-practices, etc.)
• Sorting Options - Sort by relevance, newest, or alphabetically (A-Z)

How-To Guide Detail Pages - Step-by-step instruction views:

• Hero Section - Gradient background with title, description, content type badge, and reading time
• Step-by-Step Content - Numbered steps with markdown support (bold, code blocks, lists)

13 How-To Guides - Comprehensive documentation covering:

• Getting Started (4 guides): Creating boards, understanding columns, adding tasks, inviting team members
• Developer Guides (4 guides): Workflow hooks, API authentication, task dependencies, troubleshooting
• Non-Developer Guides (3 guides): Writing tasks for AI, monitoring progress, reviewing completed work
• Best Practices (2 guides): Organizing with dependencies, using complexity and priority effectively

Agent Capabilities Input Field

UI Input for Agent Capabilities - Added agent capabilities input field to API token creation form:

Dark Mode Enhancements

Improved Task Card Styling - Enhanced dark mode appearance for task cards:

Agent Capabilities Management

Token Creation Workflow - Capabilities now entered during token creation instead of configuration file:

Claude Code Skills Enhancement

Automatic Workflow Progression - Skills updated to enable continuous agent operation:

Multi-Agent Instructions for Non-Claude Code AI Assistants

Four AI Assistant Formats - Always-active code completion guidance distributed as downloadable files:

• GitHub Copilot (.github/copilot-instructions.md) - Repository-scoped instructions optimized for 4000 token limit
• Cursor (.cursorrules) - Project-scoped rules with expanded examples for 8000 token limit
• Windsurf Cascade (.windsurfrules) - Hierarchical rules that cascade from parent directories
• Continue.dev (.continue/config.json) - JSON configuration with custom context providers and slash commands

Onboarding Endpoint Enhancement - GET /api/agent/onboarding now includes multi_agent_instructions section:

• Download URLs for all four instruction formats
• Platform-specific installation commands (Unix/Linux/macOS and Windows)
• Token limit information for each format
• Usage notes explaining complementary relationship with Claude Code Skills
• Safe installation guidance (backup, append, manual merge options)

Documentation Directory - All instruction files stored in docs/multi-agent-instructions/:

• copilot-instructions.md (9KB) - Markdown format with code examples
• cursorrules.txt (15KB) - Plain text with detailed patterns
• windsurfrules.txt (15KB) - Plain text with cascading rules
• continue-config.json (4KB) - JSON with custom commands and context providers

Core Content Coverage - All formats include essential Stride integration guidance:

• Hook execution mandate (all four hooks and their requirements)
• Top 5 critical mistakes agents make
• Essential task field requirements
• Code patterns for claiming, completing, and creating tasks
• Batch creation examples
• Documentation links

Onboarding Endpoint Optimization

Multi-Agent Instructions Architecture - Complementary approach to Claude Code Skills:

• Claude Code Skills: Contextual workflow enforcement (1000+ lines per skill, embedded content)
• Multi-Agent Instructions: Always-active code completion (200-400 lines, downloadable files)

Claude Code Skills for AI Agent Workflow Enforcement

Four Workflow Enforcement Skills - Complete set of Claude Code skills distributed via the onboarding endpoint to enforce Stride workflow discipline:

• stride-claiming-tasks - Enforces proper task claiming workflow with hook execution before claiming
• stride-completing-tasks - Ensures both after_doing and before_review hooks are executed before marking tasks complete
• stride-creating-tasks - Requires comprehensive task specifications to prevent 3+ hour exploration failures
• stride-creating-goals - Enforces proper goal structure with nested tasks and correct batch format

Onboarding Endpoint Distribution - Skills automatically provided through GET /api/agent/onboarding:

• Complete skill content embedded in JSON response
• Step-by-step installation instructions with exact commands
• Usage guidance explaining when to invoke each skill
• Automatic discovery by Claude Code when installed

Task Archive System

Archive Functionality - Tasks can now be archived and later restored or permanently deleted:

• Archive Tasks - Archive button added to task card menus on board view
• Archived Tasks Page - Dedicated page (/boards/:id/archive) to view all archived tasks for a board
• Unarchive Tasks - Restore archived tasks back to their original column
• Permanent Delete - Delete archived tasks permanently from the database
• Archive Navigation - "Archived Tasks" link added to board header for easy access
• Empty State - Friendly empty state when no archived tasks exist

⚠️ BREAKING CHANGE: All Four Hooks Now Blocking with Mandatory API Validation

All hooks (before_doing, after_doing, before_review, after_review) are now blocking and require mandatory validation at the API level. Agents must execute hooks before calling endpoints and include execution results in their requests.

1. Execute before_doing hook (blocking, 60s) → Capture result
2. POST /api/tasks/claim WITH before_doing_result
3. [Do work]
4. Execute after_doing hook (blocking, 120s) → Capture result
5. Execute before_review hook (blocking, 60s) → Capture result
6. PATCH /api/tasks/:id/complete WITH after_doing_result AND before_review_result
7. IF needs_review=true: Wait for human approval
8. Execute after_review hook (blocking, 60s) → Capture result
9. PATCH /api/tasks/:id/mark_reviewed WITH after_review_result

WIP Limit Calculation - Goals Exclusion

• Goals No Longer Count Toward WIP Limits - Work In Progress (WIP) limits now correctly exclude goal tasks and only count work and defect tasks

Goal Positioning During Drag Operations

• Fixed Goal Display Order in LiveView - Goals now consistently appear above their child tasks during live drag-and-drop operations

Dependency Blocking Status in Bulk Upload

• Dependencies Now Properly Block Tasks in Bulk Upload - Tasks with dependencies are now correctly marked as blocked when created via bulk upload API endpoint (POST /api/tasks/batch)

API Enhancements - Agent Onboarding Endpoint

• Comprehensive Agent Memory System - The /api/agent/onboarding endpoint has been significantly enhanced to help AI agents remember how to work with Stride across sessions and platforms:
  • memory_strategy section - Platform-agnostic and platform-specific instructions for maintaining context across sessions
  • session_initialization section - Step-by-step checklist for starting new sessions
  • first_session_vs_returning section - Different workflows for experience levels
  • common_mistakes_agents_make section - Learning from collective experience
  • quick_reference_card section - Ultra-condensed essentials for experienced agents
• Enhanced Documentation:
  • docs/AGENT-MEMORY-SOLUTION.md - Detailed explanation of the multi-layered memory strategy

Why This Matters

This release solves the "agent memory problem" - where AI agents would forget how to work with Stride between sessions. The enhanced onboarding endpoint provides a universal, platform-agnostic solution that works for any AI coding agent (Claude Code, Cursor, Windsurf, Aider, Cline, etc.) in any project using Stride.

Goal Movement Behavior Enhancement

• Improved Goal Auto-Positioning - When a task triggers its parent goal to move to a new column, the goal now positions itself directly above the task that caused the movement (instead of above the earliest child in the target column)

UI Improvements - Conditional Field Visibility

• Conditional Visibility for Status & Agent Tracking Section - The "Status & Agent Tracking" section in task forms now intelligently shows/hides based on agent interaction:
  • Status - Task status (Open, In Progress, Completed, Blocked)
  • Created By Agent - Name of AI agent that created the task
  • Completed By Agent - Name of AI agent that completed the task
  • Completion Summary - Summary provided by agent upon completion
• Conditional Visibility for Review Queue Section - The "Review Queue" section in task forms now only appears when a task has a review status:
  • Review Status - Pending, Approved, Changes Requested, or Rejected
  • Review Notes - Notes from the reviewer about the task
• Conditional Visibility for Actual Metrics Section - The "Actual Metrics" section in task forms now only appears when actual metrics data exists:
  • Actual Complexity - Actual complexity level (Small, Medium, Large)
  • Actual Files Changed - Number of files actually modified
  • Time Spent (minutes) - Actual time spent on the task

Documentation

• TASK-FORM-FIELD-VISIBILITY.md - New comprehensive guide explaining task form field visibility
  • Board-level field visibility settings and configurable fields
  • Always-visible fields vs. conditionally visible fields
  • Detailed explanation of conditional visibility for Status & Agent Tracking, Review Queue, and Actual Metrics
  • API behavior vs. UI form behavior
  • Best practices for board owners, AI agents, and human users
  • Examples and scenarios demonstrating visibility logic

Drag and Drop Improvements

• Smoother Animation - Enhanced drag and drop feel with improved visual feedback
• More Precise Positioning - Improved accuracy when dropping tasks
• Better Scroll Behavior - Enhanced dragging near column edges
• Prevented Premature DOM Updates - Fixed jarring updates during drag operations
• Enhanced Touch Support - Better mobile drag experience
• Position Index Bug Fix - Resolved issue where tasks would return to wrong position

Enhanced New User Experience

• Automatic Login After Registration - New users are now automatically logged in after creating their account
  • Eliminates the redundant step of requiring users to log in immediately after registration
  • Improved onboarding flow reduces friction for new users

• AI Optimized Board Quick Start - Added prominent call-to-action for new users without boards
  • Displays helpful message: "You don't have any boards yet. Create your first board to get started!"
  • Large, centered "Create AI Optimized Board" button with orange gradient styling

UI/UX Improvements

• Enhanced Task Review Checkbox Visibility - Made the \"Needs Review\" checkbox more obvious in task forms
  • Changed from subtle gray label to prominent blue gradient styling
  • Added blue checkmark icon when enabled for better visual feedback
  • Increased text size and weight for better readability
  • Improved accessibility with clearer visual distinction

Agent Onboarding Endpoint

• GET /api/agent/onboarding - Comprehensive onboarding endpoint for AI agents starting work with Stride
  • Critical first steps - Immediate guidance on creating .stride_auth.md and .stride.md configuration files
  • File templates - Complete templates for both configuration files included in response
  • Workflow overview - Clear explanation of the Ready → Doing → Review → Done workflow
  • Hook execution guide - Complete documentation of all four hook points with environment variables
  • API reference - Full endpoint listing with categorization (discovery, management, creation)
  • Documentation links - Direct URLs to all agent-facing documentation guides
  • Quick start guide - Step-by-step instructions for getting started immediately
  • Returns all information needed for an agent to begin working without external documentation lookup

• Comprehensive Agent Documentation - Created complete documentation set for AI agents
  • AUTHENTICATION.md - Bearer token authentication with .stride_auth.md format
  • AGENT-CAPABILITIES.md - Capability matching system with 12 standard capabilities
  • AGENT-HOOK-EXECUTION-GUIDE.md - Client-side hook execution with complete examples
  • TASK-WRITING-GUIDE.md - Task creation guide with structured JSON format rationale
  • REVIEW-WORKFLOW.md - Review workflow patterns and continuous work loop
  • ESTIMATION-FEEDBACK.md - Providing estimation feedback on task completion
  • UNCLAIM-TASKS.md - When and how to release tasks agents can't complete
  • AI-WORKFLOW.md - Complete agent workflow from authentication to task completion

Homepage Redesign

• Human-AI Collaboration Focus - Completely redesigned the homepage to showcase Stride as a Human-AI collaboration platform
  • Hero section - Updated badge to "Human-AI Collaboration Platform" and headline to emphasize AI agents working alongside humans
  • Value proposition - Rewritten to highlight workflow hooks, task delegation to AI, and human review control
  • Feature cards - Replaced generic kanban features with collaboration-focused features
    • AI Agent Integration - REST API with capability matching and workflow hooks
    • Automated Task Claiming - Atomic claiming with optimistic locking and dependency handling
    • Human Review Workflow - Optional human review and approval process
    • Client-Side Workflow Hooks - Custom code execution at four key workflow moments

About Page Enhancement

• Human-AI Collaboration Platform Section - Added new section explaining Stride's collaborative features
  • Overview - Describes how AI agents and humans work together through REST API and review workflows
  • Five key features - Capability matching, atomic task claiming, client-side hooks, human review, and API documentation
  • Use case description - Explains how teams delegate repetitive tasks to AI while humans focus on architecture and review

Workflow Hooks System for AI Agent Integration

Bulk Task Creation with Nested Goals

Automatic Goal Deletion

Goal → Task Hierarchy System

Hierarchical Task Tree API Endpoint

Intelligent Review Workflow with mark_reviewed Endpoint

AI Agent Metadata Tracking

Task Dependencies and Blocking Logic

Review Status Update

Fixed issue preventing review status updates on tasks:

• Added automatic population of reviewed_at and reviewed_by_id when review status changes
• Added missing handle_info handler for :task_reviewed PubSub events
• Form component now properly receives user context for review metadata

Task Completion API Endpoint

Task Mark Done API Endpoint

Task Claiming API Endpoints

Task CRU API Endpoints

API Token Authentication for AI Agents

AI Context Fields for Enhanced Task Intelligence

• Three New Task Fields - Added specialized fields to capture AI-relevant context for task execution:

AI Optimized Boards

• New Board Type - Introduced AI Optimized Boards with predefined, immutable structure:

• Automatically creates 5 standard columns: Backlog, Ready, Doing, Review, Done
• Columns are locked and cannot be added, edited, deleted, or reordered
• Designed for AI-driven workflows with consistent, predictable structure
• Board owners retain full control over tasks, but column structure is fixed
• Clear visual distinction from regular boards throughout the interface

Rich Task Metadata System

• Extended Task Schema - Added 18+ new fields to support AI-optimized task management:

• Planning & Context: complexity (small/medium/large), estimated_files, why, what, where_context
• Implementation Guidance: patterns_to_follow, database_changes, validation_rules, required_capabilities
• Observability: telemetry_event, metrics_to_track, logging_requirements
• Error Handling: error_user_message, error_on_failure
• Collections: key_files (JSONB), verification_steps (JSONB), technology_requirements (JSONB), pitfalls (JSONB), out_of_scope (JSONB)
• Metadata Tracking: created_by, creator_name, completed_at, completed_by, completer_name, completion_summary
• Assignment Tracking: claimed_at, claimed_by, claimer_name
• Review System: needs_review (boolean), review_status (pending/approved/changes_requested), review_notes
• Dependencies: dependencies (JSONB array) to track task relationships

Board-Level Field Visibility System

• Field Visibility Toggles - Board owners can control which task fields are visible to all users:

• 12 toggleable fields: acceptance_criteria, complexity, context, key_files, verification_steps, technical_notes, observability, error_handling, technology_requirements, pitfalls, out_of_scope, required_capabilities
• Stored in boards table as JSONB (field_visibility column)
• Real-time PubSub broadcasts synchronize visibility changes across all connected clients
• Owner-only access control - only board owners can modify field visibility settings
• Default visibility: acceptance_criteria shown, all others hidden
• Settings persist in database and apply to all users viewing the board

Enhanced Task Forms

• Comprehensive Task Creation/Edit Form - Support for all rich task fields with dynamic sections:

• Dynamic key files editor with add/remove functionality
• Dynamic verification steps editor with add/remove functionality
• Embedded schema support for structured JSONB data
• Validation for all new fields with proper error handling
• Field visibility awareness - form fields show/hide based on board settings
• Reduced code complexity (Credo compliant) through helper function extraction

Task Detail View Enhancements

• Rich Task Display - All 18 TASK.md categories displayed in organized, scannable format:

• Planning context (Why/What/Where)
• Implementation guidance section
• Key files to read (with file paths and descriptions)
• Verification steps checklist
• Observability requirements
• Error handling guidelines
• Technology requirements
• Known pitfalls
• Out of scope clarifications
• Dependencies visualization
• Review status indicators
• Assignment and completion tracking

Real-Time Collaboration

• PubSub broadcasts for field visibility changes
• Instant synchronization of board settings across all connected clients

AI-Optimized Task Structure

Tasks now contain comprehensive information for AI agents to:

• Understand context and rationale (why/what/where)
• Follow project patterns and conventions
• Locate relevant code files
• Verify implementation success
• Handle errors appropriately
• Track dependencies and review status

Flexible Board Configuration

Teams can customize their workflow by:

• Showing only relevant fields for their process
• Reducing information overload on task cards
• Maintaining consistent views across all team members
• Adjusting visibility as workflow needs evolve

User Authentication & Management

• User registration with email and password
• Secure user login and logout with session management
• Password hashing and security using bcrypt
• Protected routes requiring authentication
• User profiles with customizable display names
• Multi-language support with language switcher (English and French)

Board Management

• Create, view, edit, and delete kanban boards
• Each board has a name and description
• Board-level access control with three permission levels:

• Owner: Full control over board, columns, and tasks
• Modify: Can edit and move tasks, but cannot modify board structure
• Read-only: Can only view the board

• Share boards with other users with granular permissions
• Beautiful board cards with responsive design
• Board listing with quick access to all user boards

Column Management

• Create, edit, and delete columns within boards
• Drag-and-drop column reordering
• Configurable Work-In-Progress (WIP) limits per column:

• Set to 0 for unlimited tasks
• Set to positive integer to enforce maximum tasks
• Visual indicators when approaching or exceeding WIP limits
• Prevents task creation/movement when limit is reached

• Visual task count display (e.g., \"3/5\" when limit is 5)
• Column deletion with cascade (removes all tasks in column)

Task Management

• Create, edit, and delete tasks within columns
• Rich task properties:

• Title: Required task name
• Description: Optional detailed description
• Acceptance Criteria: Optional criteria for task completion
• Type: Work or Defect
• Priority: Low, Medium, High, or Critical
• Assigned To: Assign tasks to specific users
• Identifier: Auto-generated unique identifier (e.g., W1, W2, D1)

• Drag-and-drop task movement:

• Move tasks within the same column (reorder)
• Move tasks between columns
• Respects WIP limits when moving
• Visual feedback during drag operations

• Task comments:

• Add comments to tasks for collaboration
• Timestamp and display for all comments
• View comment history

• Task history tracking:

• Automatic tracking of task lifecycle events
• Track creation, moves between columns, priority changes, and assignments
• Display full history with timestamps
• Visual icons for different event types

Real-Time Collaboration

• Phoenix PubSub integration for real-time updates
• Live synchronization across all connected browsers:

• Task creation, updates, and deletion
• Task movement between columns
• Automatic board refresh when changes occur

• Multiple users can view and interact with the same board simultaneously

User Experience

• Modern, responsive design using TailwindCSS
• Smooth animations and transitions
• Drag-and-drop interfaces for intuitive task management
• Loading states for asynchronous operations
• Flash messages for user feedback
• Confirmation dialogs for destructive actions
• Empty states with helpful guidance
• Accessibility improvements throughout the application
• Mobile-responsive layout

Error Tracking & Monitoring

• Built-in error tracking with ErrorTracker
• Error dashboard for administrators
• Automatic error capture and reporting
• Stack trace and context information for debugging

Internationalization

• Full Gettext integration
• English translations (default)
• French translations
• Spanish translations
• German translations
• Portugese translations
• Japanese translations
• Mandarin Chinese translations
• Easy addition of new languages
• Context-aware translations