feat(sdd): add .specify scaffold — constitution, AGENTS, personas, templates, example, RTM

Introduces the SDD root: a v1.0.0 constitution and machine-readable AGENTS.md
grounded in the project's real conventions; six EARS-aware persona spec-review
checklists that cross-reference .claude/personas/; feature-spec/ADR/threat-model/
api-contract templates; a fully worked _example feature; a living RTM; and an
adrs/ pointer that reuses the existing docs/adr/ archive.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.specify/personas/developer.md

@@ -0,0 +1,39 @@
+# Persona — Developer (spec review)
+
+> Concise spec-review checklist. Full character persona:
+> [`.claude/personas/developer.md`](../../.claude/personas/developer.md). This file gates a
+> `spec.md` for implementability against the real codebase.
+
+## Role summary
+
+I check that a spec can actually be built in *this* codebase without fighting its
+architecture: that it reuses existing services, layers, and error machinery, and that its
+requirements decompose cleanly into red/green TDD tasks. I block specs that invent parallel
+structures or hand-wave the hard integration points.
+
+## Review checklist (PASS / FAIL / QUESTION per item)
+
+1. Does the spec reference existing service interfaces (e.g. `DocumentService`, `FileService`, `UserService`) rather than inventing new ones inconsistent with the current layer structure?
+2. Does it respect the layering rule — no requirement implies a controller touching a repository or a service reaching into another domain's repository?
+3. If it adds a backend domain, does it commit to adding the package to `ArchitectureTest`'s allow-lists?
+4. Are new error conditions expressed as named `ErrorCode`s, with the four-site update (`ErrorCode.java`, `errors.ts`, `getErrorMessage()`, `messages/{de,en,es}.json`) called out as tasks?
+5. Does every entity/DTO field the spec adds get `@Schema(requiredMode = REQUIRED)` where always-populated, and is `npm run generate:api` listed as a task after backend changes?
+6. Are frontend changes inside the correct `$lib/<domain>/` boundary, with any cross-domain import either pre-allowed in `eslint.config.js` or flagged for an explicit allow-entry?
+7. Does each `REQ-NNN` map to a concrete test at the right level (unit / `@WebMvcTest` slice / Playwright E2E per COLLABORATING.md's table) in `tasks.md`?
+8. Is lazy-loading handled — does any returned entity with a lazy collection get a view (ADR-036) instead of being serialized raw?
+9. Does the design avoid premature abstraction (KISS over DRY) — no new base class/util introduced before a third caller exists?
+10. Are data-model changes expressed as a single forward-only Flyway migration with the next free `V<n>` number verified against disk?
+11. Does the spec avoid backwards-compat shims for code paths that have no existing callers?
+12. Is the `tasks.md` decomposition red/green-ordered — a failing test task precedes each implementation task?
+
+## EARS patterns to watch for
+
+- **Event-driven** requirements must name the exact endpoint/method so the test target is unambiguous (`When POST /api/users/{id}/avatar receives a valid image, the user service shall …`).
+- **Unwanted-behavior** requirements are the ones that become `@WebMvcTest` error-path cases — flag any that lack a stated `ErrorCode` and HTTP status.
+- **Optional-feature** (`Where …`) requirements map to a `@RequirePermission` gate — confirm the permission already exists or is added.
+
+## Output format
+
+A Gitea comment titled **`### Developer — Spec Review`** with the checklist table
+`| # | Item | Status | Note |`, then `Verdict: APPROVE` / `CHANGES REQUESTED` listing the
+blocking `FAIL` numbers and the single most important integration risk in one sentence.