Four rulings from Pouya, plus what implementing them turned up. Q58 — RULED, and he attributed the ambiguity to his own document: "3.5 was meant as the TOTAL time committed, of which 2 is preparation — leaving 1.5 hours in the room. Your arithmetic caught it: if prep sat inside, 3.5 and 7 wouldn't be exactly 2x, because preparation doesn't scale with session length." The card now reads: half day up to 3 hours of session, fee includes up to 2 hours of preparation, $2,000; full day up to 6 hours, up to 3 hours of preparation, $4,000. docs/07's own research table corroborates 3 and 6 — Patey and Zuber both publish those hours, and ADR Chambers' roster rate counts preparation separately from "up to three hours of mediation". One provenance note under R14: he recalled "all or part of 3 hours" as their wording; the committed extract carries the hours but not the phrase, so docs/07 cites the hours and attributes the phrase to nobody. Two things fell out of the ruling that the instruction did not name, and both were defects. docs/07 §All parameters confirmed was itself prescribing the flat "including 2 hours of preparation" — the sentence /for-parties/ was built against, so the spec was generating the defect. And the cap had to reach the copy: "including up to 2 hours". FEES.mediation.*.hours is corrected 3.5 -> 3 and 7 -> 6; it had no consumer in src/ while the question was open, which is the only reason no page was ever wrong. /fees/ is unblocked for step 9 on the question Q58 asked. Q57 — CLOSED with no seventh undertaking. "A reader assumes the outcome, and the obvious undertaking adds nothing a reader doesn't already infer." The TODO(pouya) is replaced by the ruling where the question was; src/ now carries zero live TODO(pouya) markers. §4's mediation row lists all six published areas. Q56's ruling had named five, which was four areas plus the word "commercial" — a scope descriptor, not a seventh area. The hedge is struck on his instruction; the clause saying the six are not the authorised subject-matter list is restored, because his ruling supplied a correct value and did not close Q35(c)'s class. Split-stamped. docs/03's compliance checklist now names what to look for on a page and which §4 row decides it, never the bar's own wording. 12 items before, 12 after — a structural fix, not a coverage change. Thirteen review findings across two rounds, all applied, none declined. Three were mine to own. The capped-form rule was written and then applied to one surface: /mediation/ shipped an uncapped form in words no barred-string grep could reach, site.ts quoted a docs/07 sentence Q58 had just deleted, and §9's Q15/Q16/Q17 row prescribed the flat form — which is what a later implementer building /fees/ reads. A derived fee term was asserted as applied fact in the document that is the authority on money: "overtime begins after 3 h and 6 h" is in no ruling. Struck, and opened as Q59. And round 2 caught the arithmetic in round 1's own fix. The full-day route is flat $4,000 until hour 6, so generalising it as 500n+1000 for all n>=3 was valid only from 6 h, and "cheaper by $500 at every length" was wrong across the whole 3-6 h band. The real spread is $2,000 at three hours narrowing to $500 from six on — up to four times larger, and largest exactly where a half-day booking overruns. Written into docs/07 §Recorded dissent and §12's R5 row, which is where the 12-month fee review will read it. Round 1's fix for the missing consequence also published the overtime rate on a page that now states an unambiguous cap, defining the trigger by adjacency with no other quantity for it to attach to; the rate came off the page. R11 at the step 6 -> 7 boundary: 13 of 14 pins current. §7's TypeScript hold named one gate and there are two — typescript-eslint requires <6.1.0, tighter than @astrojs/check, so the recorded removal trigger was unreachable. Both are now named. Verified: check 0 errors, lint 0, build 0 (14 pages), check:claims 0, npm audit 0, minifier tripwire clean, zero JS shipped, all copy present with JavaScript disabled. Lighthouse not run — tool unavailable until step 7. Co-Authored-By: Claude Opus 5 (1M context) <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 |
npm run preview |
Serve the built site locally |
npm run check |
astro check — type and template errors |
npm run lint |
ESLint + Prettier check |
npm run format |
Prettier — rewrite files in place |
npm run deploy |
Build and deploy from this machine — see Deployment |
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.