Pouya LajevardiandClaude Opus 5
02739adac9
Pouya's rulings of 2026-09-03, in five parts. 1. THE INTAKE FORM IS NOT BROKEN. (ar) was wrong. docs/09 §7.1 verbatim — POST /api/intake with an Origin header — returns 303 to /contact/could-not-send/ with access-control-allow-origin echoed; the same probe without Origin returns 403. A bare POST 403s BY DESIGN and §7.1 says so three lines below the probe it prescribes: "403 means the Origin header did not arrive". The earlier finding read a status code without reading the document that defines it. Second time in two days. CLAUDE.md's instrument list goes eight to nine. D20 findings 12 and 19 fall with it; §7.2 (that both emails arrive) is still owed. The correction is APPENDED as entry (as); (ar) stands unedited. 2. The privacy retention comment was stale, not a defect — superseded by his decision to publish and confirm after launch, reading from 2026-09-04. Reworded; the TODO(pouya) came off with the gate it enforced. The mechanism finding survives: it was a JSX comment, stripped by Astro, so no build or deploy path could see it. A publication gate that lives only in a stripped comment is not a gate. §9 Q60 corrected. 3. The gloss class is fixed — 15 of the 20 D20 findings, 14 distinct edits across 9 files, under the rule "the gloss may say no more than the extract says; no new claims, no new sources". Swept three unpublished insights drafts too, and corrected the wrong CAA attribution at its source in docs/reference/, which is where a fixed page re-seeds. /bio/ changed, so the committed PDF is regenerated (89,549 B, 1 page asserted). Three findings outstanding: 10 needs a ruling, 11 is ruled and owed via Q60, 13 needs him to have said it. R1 is not one of the twenty. 4. X-Robots-Tag cannot be done with S3 object metadata — --metadata writes user metadata, returned as x-amz-meta-x-robots-tag, which no crawler reads. Built as the CloudFront response-headers policy docs/06 has specified all along: configure.mjs section 4. It needs a --apply run, not a deploy. The policy is cloned from whatever is attached at run time and reconciled on every run, because a response-headers policy replaces rather than merges. 5. Headshot deferred as an open non-defect. The master and the srcset ladder are both fine; Astro passes no quality, so AVIF encodes at sharp's default 50 and is served first. Two review rounds, 29 findings, all resolved, none declined; stopped at two per D19. NINE of round 2's fourteen were defects in round 1's own repairs — including a fix that harmonised both /fees/ rows onto wording that was itself unregistered, publishing an unsourced fee term twice where it had been once. Gates, exit status read for each: check 0 (0 errors, 0 warnings, 0 hints), build 0 (23 pages), check:claims 0, check:intake 0, og:proof 0, lint 0, minifier grep exit 1, router.test.mjs 30/30. Lighthouse NOT run. Nothing deployed and nothing applied to the distribution. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Md3GndFqWPzK78xAoebsg5
adr.smlcompany.ca
The dispute resolution practice of Pouya Lajevardi — Toronto.
A static site built with Astro, built for deployment to Amazon S3 behind CloudFront by Gitea Actions — see Deployment; the pipeline is not yet proven.
Quick start
nvm use # Node 22 LTS — the floor is in package.json engines
npm install
npm run dev # http://localhost:4321
Scripts
| Command | Does |
|---|---|
npm run dev |
Development server with hot reload |
npm run build |
Static build to ./dist — 22 pages |
npm run preview |
Serve the built site locally |
npm run check |
astro check — type and template errors |
npm run check:claims |
AGENTS.md §4 Forbidden, enforced on dist/. Runs on every deploy |
npm run check:intake |
The intake form's field table against the Lambda's — two on purpose |
npm run og:proof |
Every og:image resolves; every card headline is its page's <h1> |
npm run lint |
ESLint + Prettier check |
npm run format |
Prettier — rewrite files in place |
npm run lighthouse |
The performance budget, all four categories. Local only |
npm run bio:pdf |
Re-renders the committed one-page PDF from /bio/. Local only |
npm run deploy |
Build and deploy from this machine — see Deployment |
Two of those cannot run in CI, and that is stated rather than left to be
discovered. lighthouse and bio:pdf drive an installed browser; the Gitea
runner has none. They are keyboard gates plus blocking items on docs/06's
cutover checklist, and they are deliberately not wired into npm run build
or either deploy path — a check described as running where it cannot is the
defect AGENTS.md Q22 turned out to be.
og:proof and check:intake exist because two facts here are deliberately
duplicated, and a duplicated fact needs a mechanism rather than a comment.
Text baked into an OG card cannot be grepped by check:claims, so og:proof
comparing each card's headline to its page's <h1> is the only thing keeping
card copy inside the claim register. And the Lambda validates against its own
field table, because a server that validates against a list the client shipped
it is not validating.
(npm run check:claims was missing from this table before 2026-08-31, along
with the four added that day. A table of the project's controls that omits a
control is the shape those controls exist to catch.)
Before you contribute
Read AGENTS.md first, and maintain it as you work — it is the living
record of what this project is, what was decided, and why. Then read
CLAUDE.md for the working rules, and the specs in docs/.
The single hardest rule: no factual claim about Pouya, his credentials, his
experience, or his practice ships unless it appears in the verified register in
AGENTS.md §4. This is a public marketing surface, and the site it replaces
contained fabricated credentials.
How work is done here
Pouya decides; Claude Code implements and then adversarially reviews its own
work. Run /build <task> for any substantive change — it plans, implements,
runs two independent review agents on the diff (the claims audit wherever copy
changed), resolves the findings, verifies the build, and records the session in
AGENTS.md. /review runs the review pass alone; /wrap closes a session.
Full protocol and prompt guidance: docs/08-execution-protocol.md.
Deployment
Today, deploys run locally: npm run deploy (scripts/deploy-local.sh).
It runs the same guard, the same three sync passes with the same cache headers,
and the same invalidation as the CI workflow — at this scale the pipeline
changes only how a deploy is triggered, not what it does. The script and
.gitea/workflows/deploy.yml are one artefact in two places: change one, change
both.
.gitea/workflows/deploy.yml is the CI pipeline — Gitea Actions, not GitHub
Actions. It has never run, for two reasons that are not oversights:
- Actions are not enabled and no runner is registered. The Gitea instance is jointly administered, so both need its second administrator (Q23).
(It previously listed a second reason — that the scoped IAM user did not exist.
It exists: adr-sml-deploy, created 2026-08-26, Q22 closed 2026-08-28. See
AGENTS.md §7 for the inventory and the least-privilege verification.)
Its first step is a guard: the run aborts, naming what is missing, if any required variable or either AWS secret is empty. Only emptiness is tested and no value is echoed.
The GitHub Actions equivalent, which uses OIDC role assumption, is kept as
docs/reference/github-actions-oidc.yml.example in case the project ever moves
to a forge that supports it. It sits outside .github/workflows/ on purpose:
Gitea falls back to that directory when .gitea/workflows is absent, so a
workflow file left there with a push trigger would be only conditionally
inert. As an .example under docs/ it cannot be picked up at all.
The pipeline is designed around a long-lived AWS credential, and that
credential now exists. Gitea is not an AWS OIDC provider, so there is no role
to assume: deploys authenticate as a scoped IAM user, adr-sml-deploy, with its
access key in the repository's Gitea Actions secrets. The user was created
2026-08-26 and verified least-privilege by execution — AGENTS.md §7, Q22 closed
2026-08-28. Its access key has never been used (LastUsed null), because
deploys still run locally. (This paragraph asserted the user "has not been
created" until 2026-08-28.) In the meantime the local script
refuses to run as user/pouya, the broadly-permissioned personal user —
see AGENTS.md §10. Two things are meant to bound the risk, and neither is in
place yet:
- The policy must stay narrow. Four actions:
s3:ListBucketon one bucket,s3:PutObjectands3:DeleteObjecton that bucket's contents, andcloudfront:CreateInvalidationon one distribution. NoAction: "*", noResource: "*", nothing outside that one bucket and that one distribution. The AWS account is shared with unrelated projects, including a bucket whose name indicates another business's production database backups — that narrowness is what keeps a compromised runner away from it, and it is load-bearing rather than hygiene. SeeAGENTS.md§10. If a deploy step needs a permission the policy lacks, question the step; do not widen the policy. - The key must be rotated quarterly. It now has an owner and a date: first
rotation due 2026-11-26 (key created 2026-08-26) —
AGENTS.md§12 R17. Create a second access key, update the Gitea secrets, confirm a deploy succeeds, then delete the old one — rotation that leaves the old key active is not rotation, and deleting before verifying leaves no way to authenticate the fix. OIDC would have removed the obligation entirely; it is unavailable, so this is a standing calendar task. (It read "nobody owns that yet" until 2026-08-28; R17 is the owner, and the date is the whole point of the row.)
Full procedure, IAM policy, runner setup, and cutover checklist:
docs/06-deployment.md.