Define manifest schema v1

[jordanpartridge]

What

Define the JSON manifest schema that drives everything Foundry does.

Schema

{
  "name": "billing-service",
  "description": "...",
  "stack": {
    "framework": "laravel",
    "type": "microservice",
    "php": "8.2",
    "auth": "github-socialite",
    "queue": "redis",
    "db": "sqlite"
  },
  "models": [
    {
      "name": "Plan",
      "attributes": ["name", "price_cents", "interval", "is_active"],
      "relationships": [{ "type": "hasMany", "model": "Subscription" }]
    }
  ],
  "bifrost": {
    "source": "billing-service",
    "events": ["subscription.created", "subscription.cancelled"]
  },
  "quality": { "runner": true, "coverage": 100, "pint": true, "phpstan": true },
  "deploy": { "host": "odin", "quadlet": true }
}

Acceptance Criteria

• Schema documented in docs/manifest.md
• ManifestData DTO validates and hydrates from JSON
• Unknown keys ignored (forward compatible)
• All fields except name optional with sensible defaults

[jordanpartridge]

Done — ManifestData schema implemented

What was done

Package rename: the-shit/agent-skeleton → conduit-ui/foundry

Deps cleaned up:

• Removed: hirethunk/verbs, laravel/ai, prism-php/prism, spatie/laravel-activitylog
• Added: laravel/socialite for GitHub OAuth (repo creation automation)
• PHPStan bumped to level 8

New DTOs (all in app/Data/, using spatie/laravel-data):

• ManifestData — top-level manifest
• StackData — framework, type, php, auth, queue, db
• ModelData — name, attributes[], relationships (DataCollection)
• RelationshipData — type, model
• BifrostData — source, events[]
• QualityData — runner, coverage, pint, phpstan
• DeployData — host, quadlet

Tests: 16 Pest BDD tests, 49 assertions, 100% coverage on all 7 classes.

Gate status: Pint clean, coverage 100%, composer audit clean.

Open questions

1. stack.auth — currently a free string ("github-socialite", "none"). Should this become an enum? Possible values aren't fully enumerated yet.
2. stack.db — same question, enum vs string ("sqlite", "mysql", "pgsql").
3. models[].attributes — currently string[] (just names). Will CodeGeneratorJob need type info (e.g., name:string, price:integer) or will Blueprint infer from conventions?
4. quality.coverage — typed as int. If we want to support fractional thresholds (e.g., 99.5) this would need to be float.
5. deploy.host — free string for now. Will there be a hosts registry, or is "odin" always the only valid value for v1?

Ready for issue #2 (RepoGeneratorJob).

[jordanpartridge]

Schema open questions resolved

All 5 open questions from the initial issue are now closed. Changes landed in commit 629ccc6.

What changed

Auth driver — StackData::$auth is now typed as AuthDriver (backed enum). Valid values: github-socialite, google-socialite, login-link, none. String input is cast automatically by Spatie Data.

Database driver — StackData::$db is now typed as DatabaseDriver (backed enum). Valid values: sqlite, mysql, pgsql. Same casting behaviour.

Typed attributes — ModelData::$attributes remains string[] but the convention is now documented: values follow Blueprint type syntax (name:string, price_cents:integer, is_active:boolean). Plain names without :type default to :string.

Float coverage — QualityData::$coverage changed from int to float. Supports thresholds like 80.5. Integer values in manifests cast cleanly.

Arch test — App\Data\Enums namespace excluded from the "data objects extend Spatie Data" arch rule, since enums cannot extend classes.

Files added

• app/Data/Enums/AuthDriver.php
• app/Data/Enums/DatabaseDriver.php

Files modified

• app/Data/StackData.php
• app/Data/ModelData.php
• app/Data/QualityData.php
• tests/ArchTest.php
• tests/Unit/Data/StackDataTest.php
• tests/Unit/Data/QualityDataTest.php
• tests/Unit/Data/ModelDataTest.php
• tests/Unit/Data/ManifestDataTest.php

All gates pass: 100% coverage, Pint clean, audit clean.