Live. SleekView queries the same _genesis_ and _open_graph_ meta keys The SEO Framework admin reads from. Filters apply at the SQL level, so a board scoped to one category reflects posts updated this week, not a snapshot from a previous quarterly audit that was exported to a shared planning spreadsheet for the team.

No. Drag-and-drop writes an editorial review flag in custom meta. The SEO title, description, canonical URL, and noindex flag continue to follow the values the editor entered in the TSF metabox. A move to Optimized never accidentally rewrites the title tag or hides the post from search engines.

Yes. Each row carries its post type. SleekView exposes type as a filter and a grouping field so a board can scope to posts only, pages only, or a specific custom post type, and group by type for a separate workflow per content surface the editorial team manages on the site daily.

Yes. Every move runs through current_user_can('edit_posts') before any update_post_meta call fires. A contributor account can drag for personal sorting but the change does not persist, with a toast notification explaining the missing capability and pointing to the SEO lead or the editor on call for that category.

Filters are applied at the database query level rather than in JavaScript. A typical board scopes to one category or to in-progress states only, so the rendered card count stays under a few thousand. Older optimized posts remain queryable in archive views without slowing the live editorial board down.

Yes. SleekView computes description length on the fly from the _genesis_description meta and reads the _genesis_noindex flag directly. Both appear on the card front, so an editor can see at a glance which posts are too short and which posts are silently hidden from search engines today.

Yes. The autodescription-site-settings option holds the global defaults. SleekView falls back to those defaults when a per-post override is missing, so the card description reflects what TSF actually outputs on the public front end and not an empty value that misleads the editor during the planning meeting.

Yes. Every drag writes a meta entry on the post naming the user, the source column, the destination column, and the timestamp. The entry uses standard update_post_meta calls so audits, exports, and downstream automations can read it without a separate event log table to maintain on the side.