feat: execution protocol, review agents, DNS and SES findings

.claude/commands/build.md

@@ -0,0 +1,91 @@
+---
+description: The standing execution loop for this repo — plan, implement, adversarial review, resolve, verify, record. Use for every substantive change.
+argument-hint: <what to build, e.g. "the /med-arb/ page" or "step 4 of the build order">
+---
+
+**ultrathink**
+
+Task: $ARGUMENTS
+
+Execute the six-phase loop below. Do not skip a phase because the task looks
+small — the loop is the quality mechanism, not ceremony. If a phase genuinely
+does not apply, say which and why before moving on.
+
+---
+
+## Phase 1 — Plan (think hard before writing anything)
+
+1. Read `AGENTS.md` in full if you have not this session. Read **§12 Standing
+   Reminders** and surface anything live to Pouya before you start.
+2. Read the specs in `docs/` that bear on this task.
+3. Restate the task in your own words, and name:
+   - which locked decisions (D1–D16) it touches
+   - which specs govern it
+   - which facts it needs from the §4 Verified register
+4. **Stop and ask if you find a conflict** — between the task and a locked
+   decision, between two specs, or between the task and a fact you do not have.
+   A blocked build is a correct build. Never resolve a conflict by guessing, and
+   never soften a claim to make it defensible.
+5. State your plan before implementing.
+
+## Phase 2 — Implement
+
+Follow `CLAUDE.md` conventions. Zero JavaScript by default. Tokens only, no raw
+hex, no magic numbers. Semantic HTML. Every page gets its metadata.
+
+Where you need a fact you do not have: `TODO(pouya): <the exact question>` in the
+source **and** a new numbered question in `AGENTS.md` §9. Do not invent it.
+
+## Phase 3 — Adversarial review (this is not optional)
+
+Invoke **both** review agents on the change, in parallel:
+
+- `adversarial-reviewer` — correctness, accessibility, crawlability,
+  performance, security, simplicity
+- `claims-auditor` — every factual assertion traced to `AGENTS.md` §4
+
+**Give them the diff and the specs. Do not give them your reasoning for why the
+work is correct.** Your rationale anchors the reviewer and produces agreement
+instead of review. They form their own view from the artefact; that independence
+is the whole point of the phase.
+
+If the change touches no user-facing copy, `claims-auditor` may be skipped — say
+so explicitly.
+
+## Phase 4 — Resolve
+
+For every finding: **fix it, or decline it with a stated reason.** Silence is not
+a response. A declined finding is recorded in the Change Log with the reasoning,
+so a later reader can see the judgement was made rather than missed.
+
+If you fix anything material, **re-run Phase 3 on the fix.** A patch written
+under review pressure is exactly where the second defect lives.
+
+## Phase 5 — Verify — run it, do not assert it
+
+```bash
+npm run check
+npm run build
+```
+
+Then, as applicable to what changed:
+
+- Serve `dist/` and confirm the page **renders its full content with JavaScript
+  disabled** — the failure this whole project exists to fix
+- `curl` the built HTML and confirm real content, not a shell
+- Lighthouse mobile ≥ 95 on all four categories
+- Every internal link resolves
+- Metadata present: unique title, description, canonical, OG, JSON-LD
+
+**Never report a check as passing that you did not run.** "Should pass" is not a
+result. If you could not run something, say which and why.
+
+## Phase 6 — Record
+
+Append a `AGENTS.md` Change Log entry, newest first: what changed, old → new,
+why, and any decision or plan — including declined findings and anything
+deferred. Update Current Truth in place where the change made a section stale.
+Re-stamp facts you re-checked with today's date.
+
+Then report to Pouya: what shipped, what the review found, what you declined and
+why, and what remains open.