decisions_log:
  - question: >
      `notes` here only cover Settings; no entities/columns have been sketched yet for
      Users, Roles, Permissions, Pages, Posts, Media, Comments, or Content Versions
      (History). Should the core schema be drafted in this section before
      MILESTONES.yaml is written, given how many features depend on it?
    decision: >
      Yes — the core schema has been drafted above (`Database Tables`), covering
      Settings, Users, Roles, Permissions, Role_Permission, User_Role, Pages,
      Page_Versions, Posts, Post_Versions, Media, and Comments.
    rationale: >
      Gives MILESTONES.yaml concrete table/column definitions to build migrations
      from, instead of inferring the schema from feature descriptions alone.
  - question: >
      Should a cross-cutting convention for audit/timestamp columns (`created_at`/
      `updated_at`, and who created/last edited a record) be documented once entities
      are sketched out, so every migration follows the same pattern?
    decision: >
      Partially applied so far: Pages, Page_Versions, Posts, Post_Versions, and
      Comments already follow a `created_at`/`created_by`/`updated_at`/`updated_by`
      pattern. Users, Roles, Permissions, Role_Permission, User_Role, and Media do
      not yet have any `created_at`/`updated_at` columns (see the new suggestion
      below flagging this gap).
    rationale: >
      Records the convention actually in use today, rather than assuming it was
      applied uniformly across every table.
  - question: >
      Should the suggested `created_at`/`created_by`/`updated_at`/`updated_by`
      columns be added to Users, Roles, Permissions, Role_Permission, User_Role, and
      Media (see `suggestions` below)?
    decision: >
      Yes, accepted and applied — Users, Roles, Permissions, Role_Permission, and
      User_Role already carried the columns above; Media has now also been given the
      same `created_at`/`created_by`/`updated_at`/`updated_by` columns, so every
      table in the schema now follows the convention. `User_Totp`, `User_password_reset`,
      and `User_email_verification` are purposely missing the `created_by` and `updated_by`
      fields, as these are system generated and not tied to specific users.
    rationale: >
      Closes the last gap (Media) so audit/timestamp tracking is consistent across
      every table, matching the convention already used on Pages/Page_Versions/
      Posts/Post_Versions/Comments.
  - question: What database engine will be used?
    decision: >
      Support for MySQL/MariaDB through PDO connections.
    rationale: >
      Supporting multiple engines provides flexibility for different deployment
      scenarios while maintaining a consistent interface through PDO.
  - question: How will data migrations be handled?
    decision: >
      Data migrations will be implemented using Laravel Eloquent migrations, with each plugin having
      its own migration files.
    rationale: >
      This approach allows plugins to manage their own database schema changes
      while providing a centralized migration management system.