Pouya LajevardiandClaude Opus 5
6bf1167624
The re-audit of the deploy-guard change surfaced defects well outside the diff, including one that would have broken production mail. docs/05-backend-spec.md had the two SES DKIM sets exactly inverted, labelling the three records that resolve as "orphans" and the three NXDOMAIN records as "Live. Never delete". Entry (j) corrected this in AGENTS.md §7 and the correction never reached docs/05. Since SES has no custom MAIL FROM, DKIM is the only thing satisfying DMARC, so acting on that table would have silently broken intake mail authentication. Also in this change: - .gitea/workflows/deploy.yml gains a guard as steps[0] that fails the run, naming the variable, if AWS_REGION, S3_BUCKET or CLOUDFRONT_DISTRIBUTION_ID is empty — how a Gitea too old for the vars context manifests. Verified fail-closed under bash -e, sh -e and bash -euo pipefail. - AGENTS.md Current Truth: SPF and DMARC recorded as present (Q20), the matching §10 High risk row retired, three duplicate Q rows removed. - docs/reference/AWS-Hosting-Guide.md tracked and given a do-not-execute banner; it was an executable procedure for the architecture D1/D3 replace. - Copy decks: "a working litigator" and "an active litigation practice" replaced with the register's own wording; LegalService JSON-LD replaced with ProfessionalService; tribunal-secretary offers removed per D14; nine stale question blockers swept. - astro.config.mjs: prefetchAll disabled — it injected JS into every page against the zero-JS convention with no decision recorded. - src/data/site.ts: unregistered response-time commitment nulled (Q27); OBA section names downgraded to [assumed] (Q28). - s3:AbortMultipartUpload reasoning corrected to measure ./dist, not the repo. Opens Q27, Q28, Q29. AGENTS.md entry (q) records the full resolution, including the findings declined and why. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012XquaEq4BgWMCwUqLEyNkF
3.9 KiB
description, argument-hint
| description | argument-hint |
|---|---|
| The standing execution loop for this repo — plan, implement, adversarial review, resolve, verify, record. Use for every substantive change. | <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)
- Read
AGENTS.mdin full if you have not this session. Read §12 Standing Reminders and surface anything live to Pouya before you start. - Read the specs in
docs/that bear on this task. - Restate the task in your own words, and name:
- which locked decisions (D1–D18) it touches
- which specs govern it
- which facts it needs from the §4 Verified register
- 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.
- 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, simplicityclaims-auditor— every factual assertion traced toAGENTS.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
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 curlthe 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.
If the entry claims a change was applied across files, cite the command and paste its output. Write that claim only after reading the output. Recall is not evidence — three entries on this project asserted a completed sweep and instances survived all three.
Then report to Pouya: what shipped, what the review found, what you declined and why, and what remains open.