current_user&.org_admin?(organization) issues a DB query (organization_memberships.admin.exists?) per organization, which can create an N+1 on the editor page when a user belongs to many orgs. Consider precomputing the admin org IDs once (e.g., from current_user.organization_memberships.admin.pluck(:organization_id)) and using that set inside the serialization loop, or otherwise eager-loading/caching the admin membership check.

allowed_to_manage_org_co_authors? checks org-admin status against effective_organization_id, which switches to the requested organization_id whenever organization_id is present in params. This prevents clearing/updating co_author_ids_list during an org change (including switching to personal organization_id: ""), even though the editor clears co-authors on org switch; the result is that org changes can fail validation (co-authors no longer belong to the new org) with no way to clear them in the same request unless the user is admin of the target org. Consider authorizing co-author updates against the article’s current org when changing/removing org, or explicitly allowing co_author_ids_list to be cleared when organization_id is changing and the user is permitted to change org.

There’s no request spec covering the org-switch scenario with existing co-authors (e.g., changing organization_id while co_author_ids_list is cleared), which is a key regression risk given the new effective_organization_id/permission logic and the new org-membership validation. Adding coverage for updating an org article with co-authors while switching to a different org (admin and non-admin target org cases) would help prevent breaking org changes in the editor.

The orgOptions logic uses strict equality (organizationId === organization.id) to set the selected <option>, but the onChange handler typically supplies e.target.value as a string while organization.id is a number. After a change, this can prevent the correct option from being marked selected on re-render. Consider coercing both sides to the same type (e.g., String(...)) or making the <select> controlled via a value={...} prop instead of setting selected on individual options.

This seeds loop performs multiple queries per organization (organization.users.count and organization.users.pluck(:id)), which can get slow with many orgs/users. Consider using already-loaded IDs (e.g., organization.user_ids) and avoiding repeated association queries inside the loop (or batching via preloading) to keep seeding fast.

In this spec setup, create(:organization_membership, user: co_author, organization_id: admin_org_id) will still build the factory's organization association and then overwrite organization_id, creating an extra unused Organization record. Prefer passing organization: Organization.find(admin_org_id) (or the already-created org object) to avoid unnecessary records and keep the setup accurate.

sign_in_as disables CSRF verification (skip_before_action :verify_authenticity_token). Since the UI uses button_to, Rails will include an authenticity token automatically, so this skip is unnecessary and weakens protection (even in development, a cross-site POST could change the session in an unexpected way). Consider removing the CSRF skip (or at least restricting the action to same-origin/local requests).

@users is loaded without preloading roles, but the view calls user.roles.map(...) for each row. This will issue an extra query per user (up to 100). Consider eager-loading roles in the controller (e.g., User.includes(:roles)), or otherwise avoiding per-row role lookups.

sign_in_as allows any request in development to assume any user's identity (no authentication/authorization check beyond Rails.env.development?). If a dev server is ever reachable by others (shared LAN/tunnel), this becomes a serious escalation vector. Consider additionally restricting to request.local? and/or requiring an authenticated admin user before allowing impersonation.

co_author_ids_list= does not handle blank/nil input. When the editor submits an empty string (common default/cleared state), split produces [""], causing co_author_ids to be non-blank and triggering invalid_coauthor validation errors. Treat blank input as an empty array and filter out blank IDs (and ideally cast to integers) before assigning to co_author_ids.

co_authors_data uses User.where(id: co_author_ids) without enforcing ordering, so the returned array can come back in an arbitrary order (which can cause UI flicker or mismatched ordering vs co_author_ids_list). Consider ordering with in_order_of(:id, co_author_ids) (or equivalent) so the serialized data matches the stored co-author order.

ArticleForm stores organizations, authorId, and coAuthorsData in component state, and submitArticle currently sends almost the entire state back to the server (see processPayload in app/javascript/article-form/actions.js). With the new org fields (including fetch_users_url) and coAuthorsData objects, this can significantly bloat editor save requests and introduce unpermitted-param noise. Consider excluding UI-only fields (at least organizations, authorId, and coAuthorsData) from the submitted payload.

The new dev_tools endpoints are currently mounted for every non-production environment (unless Rails.env.production?). Even though the controller returns 403 outside development, having a privileged identity-assumption endpoint routable in staging/QA increases accidental exposure and attack surface. Consider scoping these routes to development only (e.g. if Rails.env.development?) or otherwise removing them from non-dev deployments entirely.