How do you organize RLS policies and views in Supabase?

I start my projects with migration files that are pretty well organized:

xxxxxxx_enums.sql
xxxxxxx_tables.sql
xxxxxxx_rls.sql
xxxxxxx_view_name.sql
xxxxxxx_view_name2.sql
xxxxxxx_rpc_name.sql

As the project grows, the migration history becomes less consistent:

fix_view_name.sql
fix_view_again.sql
fix_rls.sql
fix_rls_again.sql
fix_rpc_name.sql
...

At that point, I find it much harder to audit the current state of the database because the definitions of views, RLS policies, and RPC functions are spread across many migrations.

I'm considering keeping schema changes in migrations but moving views, RLS policies, RPC functions, and triggers into repeatable SQL that gets applied after migrations:

supabase/
  migrations/
    create_tables.sql
    add_columns.sql

  repeatable/
    views.sql
    functions.sql
    triggers.sql
    rls.sql

supabase db reset
./scripts/apply-repeatable.sh

That would keep schema history immutable while giving each evolving object a single source of truth.

Has anyone adopted a similar workflow? Are there any downsides I'm overlooking?