Add PolicySeeder

[tarrow]

Creates a new Seeder for easily creating Policy locally. This is not automatically run with php artisan db:seed since I intend to follow up with separating out Seeders into those we may wish to run only in test or dev and those we may wish to run in Prod

Bug: T430090

[outdooracorn]

It might be good for the PR description / commit message to include:

• how you can run this seeder (php artisan db:seed --class=PolicySeeder), as well as why it won't be run with php artisan db:seed.
• that you might need to run composer dump-autoload in order for the db:seed command to know that the PolicySeeder class exists.

[outdooracorn]

I believe this will create a new policy, or fail if the policy already exists. If multiple seeders are run in the future, I think a failed Seeder will prevent subsequent seeders from running, which is likely not what we want.

From my quick searching, it's often recommended to create seeders in an idempotent way (i.e. running the seeder multiple times will result in the same database state).

https://oneuptime.com/blog/post/2026-02-03-laravel-database-seeding/view recommends using firstOrCreate() or updateOrCreate() methods on the model to make seeders idempotent.

Alternatively/additionally, you could use the Policy::truncate(); method to clear the table and reset the index (I haven't thought much about how best to handle existing constraints, though).

[outdooracorn]

Creating a CarbonImmutable instance here works, but makes it trickier to use firstOrCreate() or updateOrCreate() methods (see other comment as to why you would want to use those methods). This is because (emphasis mine):

Create a Carbon instance from just a date. The time portion is set to now.

And explained using tinker:

$ dc exec -it api php artisan tinker
> use Carbon\CarbonImmutable;

> $a = CarbonImmutable::createFromDate(2026, 06, 01);
= Carbon\CarbonImmutable @1780325575 {#8373
    date: 2026-06-01 14:52:55.291326 UTC (+00:00),
  }

> $b = CarbonImmutable::createFromDate(2026, 06, 01);
= Carbon\CarbonImmutable @1780325594 {#8399
    date: 2026-06-01 14:53:14.547747 UTC (+00:00),
  }

> $a === $b
= false

> $a == $b
= false

> $a->equalTo($b)
= false

To address this you could either:

• use a date string (e.g. 'active_from' => '2026-06-01',)
• use the CarbonImmutable::createMidnightDate() method

> $a = CarbonImmutable::createMidnightDate(2026, 06, 01);
= Carbon\CarbonImmutable @1780272000 {#8474
    date: 2026-06-01 00:00:00.0 UTC (+00:00),
  }

> $b = CarbonImmutable::createMidnightDate(2026, 06, 01);
= Carbon\CarbonImmutable @1780272000 {#8451
    date: 2026-06-01 00:00:00.0 UTC (+00:00),
  }

> $a === $b
= false

> $a == $b
= true

> $a->equalTo($b)
= true

[outdooracorn]

I did some more testing of creating CarbonImmutable objects while writing a test for another PR and thought I would paste the findings here as well.

echo CarbonImmutable::create(2026, 06, 01);              // 2026-06-01 00:00:00
echo CarbonImmutable::createFromDate(2026, 06, 01);      // 2026-06-01 16:01:49
echo CarbonImmutable::createMidnightDate(2026, 06, 01);  // 2026-06-01 00:00:00
echo CarbonImmutable::create(2026, 06, 01, 12);          // 2026-06-01 12:00:00

[outdooracorn]

For testing purposes, would it be useful to have more than one current policy? Maybe also a superseded policy? I'm also happy if we add these at a later stage, though.

The base branch was changed.