# pocs/poc-01-blog/seeds/seed-blog.yaml
#
# Blog POC — Seed Manifest
#
# Standard seeder contract:
#   - admin user: password Admin123!, role admin, verified
#   - role-specific demo users: password Demo123!, verified
#   - predictable data with stable slugs/titles for deterministic tests
#   - idempotent: safe to run on every server start
#
# Execution order (four phases):
#   Phase 1 — Roles
#   Phase 2 — Users
#   Phase 3 — Assignments
#   Phase 4 — Domain data (posts and tags)
#
# Note on M2M tag linking and comments:
#   Post-to-tag links and comments cannot be seeded here because the
#   seeder dispatches create actions that return auto-generated UUIDs
#   that are not known at seed-file authoring time. Use TESTING.md
#   curl examples to wire up tag links and create comments via the API
#   after the server has started.

# ─── Phase 1: Roles ─────────────────────────────────────────────

roles:
  - name: admin
    description: "Full system access. Can manage users, roles, and all content."

  - name: editor
    description: "Can publish and archive posts. Can manage tags. Cannot delete."

  - name: author
    description: "Can create and edit own posts. Cannot publish or manage tags."

  - name: reader
    description: "Read-only access. Cannot create or modify any content."

# ─── Phase 2: Users ─────────────────────────────────────────────

users:
  - username: admin
    email: admin@blog.example.com
    password: "Admin123!"
    verified: true

  - username: alice
    email: alice@blog.example.com
    password: "Demo123!"
    verified: true

  - username: bob
    email: bob@blog.example.com
    password: "Demo123!"
    verified: true

  - username: carol
    email: carol@blog.example.com
    password: "Demo123!"
    verified: true

  - username: diana
    email: diana@blog.example.com
    password: "Demo123!"
    verified: true

# ─── Phase 3: Assignments ───────────────────────────────────────

assignments:
  - username: admin
    roles: [admin]

  - username: alice
    roles: [author]

  - username: bob
    roles: [author]

  - username: carol
    roles: [reader]

  - username: diana
    roles: [editor]

# ─── Phase 4: Domain data ───────────────────────────────────────
#
# Tags first (posts may reference tag names in TESTING.md workflows).
# Posts second.
#
# identity_field notes:
#   - For Tag: name is unique — safe identity field
#   - For Post: slug is unique — safe identity field
#   Duplicate runs skip records whose identity_field value already exists.

data:

  # ── Tags ─────────────────────────────────────────────────────

  - action: adl.blog.tag.create
    data:
      name: "tech"
      color: "#3b82f6"
      description: "Technology, software, and engineering topics"

  - action: adl.blog.tag.create
    data:
      name: "tutorial"
      color: "#8b5cf6"
      description: "Step-by-step instructional content"

  - action: adl.blog.tag.create
    data:
      name: "opinion"
      color: "#f59e0b"
      description: "Opinion pieces and editorial commentary"

  - action: adl.blog.tag.create
    data:
      name: "news"
      color: "#10b981"
      description: "Platform announcements and industry news"

  # ── Alice's posts (author role, 3 posts) ─────────────────────

  - action: adl.blog.post.create
    as: diana
    data:
      title: "Getting Started with Kalos"
      slug: "getting-started-with-kalos"
      excerpt: "A complete walkthrough of booting your first Kalos application from zero."
      body: |
        # Getting Started with Kalos

        Kalos is a C++ microkernel application server that generates complete
        backend APIs from a single YAML file. This post walks through getting
        your first application running in under ten minutes.

        ## Prerequisites

        - CMake 3.30+
        - MSVC 19.33 (Windows) or GCC 13+ (Linux)
        - SQLite3

        ## Your first domain

        Create a file called `hello.adl.yaml` with the following content...
      status: "published"
      authorId: "alice"
      authorName: "Alice"
      publishedAt: "2026-02-10T09:00:00Z"

  - action: adl.blog.post.create
    as: diana
    data:
      title: "Why Declarative APIs Are the Future"
      slug: "why-declarative-apis-are-the-future"
      excerpt: "Handwritten REST endpoints are technical debt. Here is why the industry is moving to declarative generation."
      body: |
        # Why Declarative APIs Are the Future

        Every developer has written the same CRUD handler a hundred times.
        List, get, create, update, delete. Validation. Permissions. Pagination.
        The logic is identical — only the field names change.

        ADL eliminates this class of boilerplate entirely...
      status: "published"
      authorId: "alice"
      authorName: "Alice"
      publishedAt: "2026-02-18T14:30:00Z"

  - action: adl.blog.post.create
    as: diana                          # editor — can write status field
    data:
      title: "Advanced ADL Patterns"
      slug: "advanced-adl-patterns"
      excerpt: "Composition with $merge, cross-domain relationships, and computed aggregations."
      body: |
        # Advanced ADL Patterns

        Once you have the basics down, ADL has a set of composition
        primitives that let you build large, well-structured domains
        without repetition. This post covers $merge, $ref, and $include.

        ## Shared objects with $merge

        The Timestamp object appears on every resource...
      status: "review"
      authorId: "alice"
      authorName: "Alice"

  # ── Bob's posts (author role, 2 posts) ───────────────────────
  # status omitted — defaults to "draft" per ADL domain definition.
  # Dispatching as bob is fine because no status field is being written.

  - action: adl.blog.post.create
    as: bob
    data:
      title: "My First Draft Post"
      slug: "my-first-draft-post"
      excerpt: "Just getting started. This is a work in progress."
      body: |
        # My First Draft Post

        I am still working on this. Check back later!

        TODO:
        - Add introduction
        - Add code examples
        - Add conclusion
      authorId: "bob"
      authorName: "Bob"

  - action: adl.blog.post.create
    as: bob
    data:
      title: "Things I Learned Building APIs"
      slug: "things-i-learned-building-apis"
      excerpt: "Five hard lessons from five years of building REST APIs."
      body: |
        # Things I Learned Building APIs

        After five years of building REST APIs, I have collected a
        list of mistakes I keep seeing — and making myself.

        ## 1. Pagination is not optional

        The endpoint that returns all records today returns 50,000
        records next year. Always paginate from day one...
      authorId: "bob"
      authorName: "Bob"
