Changelog

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: Anyone with the direct link 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