chore(app): TS app skeleton, docker compose and verify commands

[Fluory]

Goal

Make the empty system runnable and provable: docker compose up starts PostgreSQL, SeaweedFS, web and a no-op worker; the three verify levels exist and CI runs them.

Acceptance criteria

• docker compose up starts postgres:17, SeaweedFS, web (Next.js, Node 24) and worker; GET /api/health returns 200 with database and storage status
• pnpm verify:changed, pnpm verify, pnpm verify:full exist; verify runs lint, typecheck, Vitest, dependency-cruiser, build and pnpm audit --audit-level high
• Module skeletons src/features/<module>/index.ts match the architecture map; dependency-cruiser rejects deep imports across modules
• Drizzle with migrations in src/db/migrations; the first migration creates the roles app_owner and app_rw (NOBYPASSRLS)
• .env.example documents every variable; no secret committed; the foundation note in AGENTS.md is removed
• New dependencies are justified in the PR (Next.js, Drizzle, pg-boss, Vitest, dependency-cruiser, S3 SDK)

Not part of this task

• Auth, RLS policies, AI service, UI beyond a placeholder page

Affected areas

• package.json
• compose.yaml
• Dockerfile
• src/app/
• src/db/
• src/features/*/index.ts
• .github/workflows/ci.yml

Test plan

Criterion	Check
health endpoint	integration test against Postgres + SeaweedFS
module boundaries	dependency-cruiser rule test with a deliberate deep import
compose start	manual smoke: docker compose up → /api/health

Security/Privacy affected?

Database roles and env-only secrets. No data processed yet.

Epic: #2 · Architecture: docs/decisions/ADR-0001-pilot-architecture.md

[Fluory]

Claimed by @Fluory on branch claude/chore-app-skeleton-3 – stacked on #20 (foundation) per orchestrator decision 2026-09-22. Draft PR follows.

[Fluory]

decision-needed – DB roles: the acceptance criterion says "the first migration creates the roles app_owner and app_rw". PR #21 creates them in docker/postgres/init/01-roles.sh (passwords from env) instead, and the first migration only verifies them (no superuser, no BYPASSRLS, no inherited owner/bypass role, runs as app_owner) and aborts otherwise.

Why: a migration that creates login roles needs either passwords in the repo or superuser rights for the migration role – both contradict D7/the secrets rule. Most reversible option taken; outside Docker an operator creates the two roles once (documented in docs/technical/operations.md).

Please confirm, or say if you prefer a migration that creates NOLOGIN roles (passwords set by the operator afterwards).

---

Generated by Claude Code