Kanban for WordPress takes a deliberately conservative path: every piece of plugin data sits in its own kanban_* table, separated from the WordPress posts table for security and data-hygiene reasons. Tasks, boards, comments, estimates, and status changes each get their own table with foreign-key links between them. The plugin's UI is the kanban board itself, which is great for visual flow and frustrating for any operation that needs sorting, filtering, or batch edits.

SleekView reads kanban_tasks, kanban_boards, and kanban_estimates as first-class data sources and joins kanban_status_changes for the real value-add: a time-in-status column computed from the latest status transition. Sort that column descending and the oldest stuck cards float to the top, which is exactly the cohort an engineering lead's Monday triage actually needs. Boards become a join column so 'in progress more than 5 days, across all boards' is a saved view rather than a manual board sweep.

Inline edits write back to kanban_tasks and append a row to kanban_status_changes when status flips, which preserves the audit trail the plugin's design intentionally keeps. The board UI continues to work alongside SleekView; the two surfaces share the same tables and stay consistent. The plugin handles visual flow; SleekView handles flat-list operations and reporting that the board view alone can't make easy.

Kanban boards are exceptional at showing flow and terrible at showing stagnation. A card that nobody touches for two weeks looks identical to a card that moved through three columns yesterday; both sit in a lane and wait. The plugin's design choice to store data in dedicated kanban_* tables, including a kanban_status_changes log of every transition, contains exactly the data needed to surface stagnation.

The default board UI doesn't expose it because boards are visual flow tools, not stuck-work dashboards. The result is that engineering leads run a manual sweep across boards each Monday, eyeballing which cards have been in 'in progress' too long, and triage suffers when boards multiply. SleekView reads kanban_status_changes directly and computes time-in-status as a sortable column, which makes 'in progress more than 5 days' a one-click cohort instead of a manual scan.

Cross-board filters reveal stuck work no matter which lane it lives in. Inline edits without dragging let triage happen at typing speed for the dozen-card sweeps that boards make slow. The board UI keeps doing what it does well; SleekView handles the queries the board UI can't.