Files

T

Pouya LajevardiandClaude Opus 5 2b6176e4d7 feat: SES production access and monitoring; §7 as single source of operational truth

Q19 is closed — SES production access granted in ca-central-1, confirmed in
writing. Nothing now blocks /contact/.

The structural change is the important one. Specs in docs/ carried their own
copies of resource IDs, regions, DNS records and service state. AGENTS.md §7
is now the single source of truth for operational facts and docs/ cite it
rather than restating it, with the rule recorded in CLAUDE.md under
Conventions.

The reason is the previous commit's DKIM inversion, generalised: the same
fact lived in §7 and docs/05, a correction reached one of them, and the stale
copy told an operator to delete the records that authenticate outbound mail.
A duplicated fact is one that will eventually be wrong in one place, and the
copy that goes stale is the one nobody re-reads. Verified by grep over
docs/*.md — no operational identifier remains.

Also in this change:

- §7 records the SES monitoring: SNS topic ses-alerts, alarms
  SES-BounceRate-High (>= 0.03) and SES-ComplaintRate-High (>= 0.001), and
  the deliberate choice of email feedback forwarding over an SNS feedback
  topic at this volume. The ses-alerts email subscription is stamped PENDING
  CONFIRMATION — the alarms currently notify nobody, now tracked as R9 and on
  the cutover checklist.
- docs/05 records why those alarms are a real control: SES suspends above
  roughly a 5% bounce rate, and under 100 messages a month five bounces
  crosses it.
- Q29: the deploy guard now covers AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
  (emptiness only, never echoed) and INTAKE_ENDPOINT, promoted to job-level
  env. An empty intake endpoint ships a live form posting to nothing, which
  is worse than a failed build. Executed under sh -e across four input
  states; fails closed, leaks nothing.
- docs/06: account ID removed from the backup-bucket callout, pointing at §10
  instead, as README already does.
- astro.config.mjs: prefetch removed entirely. Any setting ships Astro's
  prefetch script to every page against the zero-JS convention. Recorded as a
  decision; revisit against real Lighthouse numbers.

AGENTS.md entry (r) records the full reasoning.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012XquaEq4BgWMCwUqLEyNkF

2026-08-26 11:47:17 -04:00

114 KiB

Raw Blame History

Agent Working File

This file is a living document and a full history tree for this project — not a snapshot. Any agent or person working here (Claude in chat, Claude Code, Claude Cowork, or a human) maintains it by the rules below. Everything else in this file varies by project; these rules do not.

How to maintain this file

Document everything. On every change, record what was discussed, decided, changed, or planned — decisions and plans included, not just executed work.
Never overwrite or delete history. When something changes, update the relevant Current Truth section in place and append a dated Change Log entry capturing old → new and why.
Two parts, kept separate: Current Truth is updated in place and always reflects the present state; the Change Log is append-only, newest entry first, and is never edited retroactively.
Stamp facts as [verified YYYY-MM-DD] or [assumed]. When you re-check a fact, re-stamp it with today's date; a stale date means it needs re-verifying.
Never prune the Change Log. If the file gets unwieldy, ask before archiving old entries to AGENTS-history.md. History is not destroyed.

Current Truth

1. What this project is

A ground-up rebuild of adr.smlcompany.ca, the personal-brand website of the alternative dispute resolution practice of Pouya Lajevardi. [verified 2026-08-25]

The brand's centre of gravity is the practitioner, not the firm and not SML Company Ltd. Legal background, firm affiliation, and the operating company are credibility signals referenced in support; they are not the subject. [verified 2026-08-25 — source: PL_ADR_Personal_Branding_Strategy_Brief.docx]

Positioning in one sentence: a credentialed neutral who is also close to live litigation and a practising machine-learning / infrastructure engineer — a combination that is close to absent from Canadian ADR rosters, and which is the practice's economic moat. [verified 2026-08-25 — source: strategy brief §I, §V] (Wording corrected 2026-08-26: "a working litigator" asserted conduct of litigation, which §4 bars — see entry (q).)

Time horizon: the strategy brief plans a 24-month compounding arc. The site is built to be added to continuously, not shipped once. [verified 2026-08-25]

2. State of the thing being replaced

The site live at adr.smlcompany.ca as of this entry: [verified 2026-08-25]

It is a single 2.2 MB HTML file containing an entire React application, compiled in the browser at runtime by Babel Standalone loaded from unpkg.
React and ReactDOM are loaded as development builds from a public CDN.
Crawlers see almost nothing. A server-side fetch of the URL returns only SML Company, DISPUTE RESOLUTION, and the loading string Unpacking.... Every word of real content is assembled client-side after three CDN round trips. [verified 2026-08-25 — direct fetch]
The deployed <head> has no <meta name="viewport">, no meta description, no Open Graph or Twitter card tags, no canonical URL, and no favicon. [verified 2026-08-25]
robots.txt returns 403. There is no sitemap. [verified 2026-08-25]
The two logo PNGs are ~1 MB combined and are base64-inlined into the HTML, so they cannot be cached separately from the page. [verified 2026-08-25]
<title> is still SML Company · Dispute Resolution — the pre-rebrand placeholder title. [verified 2026-08-25]
There is no version control, no build step, and no test suite. The publishing mechanism is a Python script (rebuild-standalone.py) that inlines the JSX components into the single file. [verified 2026-08-25]
The May 2026 content brief was partially applied — the JSX components under components-standalone/ contain the corrected Pouya-branded copy, but the document <head> and some structural defaults still carry placeholder content. [verified 2026-08-25]

Consequence, stated plainly: for a site whose entire purpose is to be found by counsel, general counsel, and appointing bodies searching for a neutral, the current architecture is close to a worst case. This rebuild is justified on architecture alone, independent of any content or design opinion. [verified 2026-08-25]

3. Locked decisions

Decided with Pouya on 2026-08-25. Each of these is settled; do not re-open one without an explicit instruction and a Change Log entry. [verified 2026-08-25]

#	Decision	Chosen	Rejected alternatives
D1	Framework	Astro, static output	Next.js; patching the single-file build; hand-written HTML
D2	Content scope	Full re-architecture — new IA, new pages, all copy rewritten	Copy rewrite on existing structure; audit only; technical layer only
D3	Hosting & CI/CD	Git repo + Gitea Actions → existing S3 + CloudFront. Amended 2026-08-26: self-hosted Gitea, repo `adr-sml`. Gitea Actions uses GitHub Actions syntax, so the workflow ports nearly as is — but Gitea is not an AWS OIDC provider, so deploys authenticate with a scoped IAM user, rotated quarterly	GitHub Actions + OIDC; Terraform/CDK IaC; Amplify; manual deploys
D4	Languages	English only	Full EN/FA bilingual; EN + one Farsi page; EN with FA scaffolding
D5	Page structure	Full multi-page, ~20 URLs	Lean six-page; rich home + a few deep pages
D6	Primary audience	All four tiers, served by different surfaces (see §5)	Single-audience focus
D7	Visual design	Keep palette and infinity mark; modernize the execution	Faithful port; strip motion only; fresh design direction
D8	Fees	Full rate card published on a `/fees/` page	Ranges only; on request; gated PDF
D9	Insights	Build it and launch with 3–5 drafted pieces, every word reviewed by Pouya before publication	Launch empty; no Insights section
D10	Intake	Rebuilt intake form + calendar booking for the confidential intake call	Structured questionnaire; form only; email/phone only
D11	Rollout	Build everything, one clean cutover. The current site stays live untouched until replaced	Patch live site first; staging subdomain; take site down
D12	Agent working file	This file, maintained under the constitution above	Ad hoc notes
D13	Licensure claims	The site asserts the JD only. No claim of licensure, call to the bar, or entitlement to practise law. The approved phrasing for the boutique role is "active litigation exposure" or "involvement in litigation and ADR matters" — never "practice" in that context. "Practice" describing Pouya's own ADR practice — "the dispute resolution practice of Pouya Lajevardi" — is correct and stays. Pouya's direction, 2026-08-26. Explicitly interim — see Standing Reminders §12	Stating LSO licence status; the word "practice"
D14	Fee structure	Single published rate card, all mediation matters at one rate. Confirmed by Pouya 2026-08-26; figures in `docs/07-fees.md`. No tribunal-secretary line	Two-tier card (recommended by Claude, declined); ranges; fees on request
D15	Analytics	Privacy-first and cookieless (Plausible or Fathom). No cookie banner, nothing to consent to, one line in the privacy policy	GA4; no analytics at all
D18	Intake email	Two emails per submission — notification to `info@smlcompany.ca`, and a confirmation receipt to the inquirer. Pouya, 2026-08-26. The receipt is what requires SES production access (Q19)	Notification only; no email; no form at all
D17	Working method	Pouya architects; Claude Code implements and then adversarially reviews its own work. Six-phase loop encoded in `.claude/commands/build.md`; two independent review agents in `.claude/agents/`; extended thinking on by default. Standing agreement — not restated per prompt	Implement-and-report; single generic reviewer; review only on request
D16	Naming the boutique	Never named. Referred to throughout as a Toronto litigation and ADR boutique. Pouya's decision, 2026-08-26	Naming the firm

4. Credential and claim register

This is the most important section in this file. The previous version of this site carried a fictitious founder, invented matter values, fabricated office locations, and a testimonial attributed to a person who does not exist. Whatever regulatory regime does or does not apply, publishing false credentials on a professional's marketing site is the thing this register exists to prevent. That reason is sufficient on its own, and it does not rest on a fact this file has never established.

Note on this paragraph's own history, kept as a caution. It previously read "Pouya is a licensed legal professional", then "a legal professional", then asserted that LSO marketing rules apply — three progressively weaker forms of the same unverified claim, each surviving a sweep meant to remove it. The register was asserting what it could not vouch for, in the section written to stop exactly that.

Governing rule

No claim reaches a public page unless it appears in the Verified column below. If a page needs a fact that is not here, stop and ask Pouya. Do not infer it, do not soften it into something defensible, and do not carry it over from the old site.

Verified — may be published

Sourced from Pouya's own strategy brief of 2026-05-26. Self-reported by the subject, which makes them reliable as to substance, but currency is not confirmed — several are on a moving credentialing track and may have advanced since May.

Claim	Status
Pouya Lajevardi, JD, Bond University	`[verified 2026-08-25 — strategy brief §I]`
Licence status — NOT ESTABLISHED	`[unestablished 2026-08-26]`. This record does not know whether Pouya is licensed. He instructed that licensure be left out of the site (D13) — an instruction about the site, not a statement of fact either way. Do not assert it, do not deny it, do not infer it from anything else here, and do not treat any regulatory regime as established. R1 tracks the reopening
~~Lawyer; Law Society of Ontario member~~	DO NOT PUBLISH. Pouya directed on 2026-08-26 that licensure is left out of the site entirely; the JD is asserted, nothing further. See D13 and the Forbidden table below `[verified 2026-08-26]`
Director of Firm Operations, Toronto litigation and ADR boutique	`[verified 2026-08-25 — strategy brief §I]`
Active litigation exposure: personal injury, construction, regulatory (POA), insurance (SABS)	`[verified 2026-08-26]`. Wording corrected — this row previously read "practice", the exact word D13 bars in exactly the context it bars it. The register was quoting the strategy brief verbatim and contradicting its own rule. The underlying fact is unchanged
Q.Med designation through ADRIC / ADRIO	`[verified 2026-08-25 — strategy brief §I]`
Has completed multiple sole mediations	`[verified 2026-08-25 — strategy brief §I]` — count deliberately not published, see below
Q.Arb credentialing pathway — commenced August 2026	`[verified 2026-08-26 — Pouya]`. Describe as newly commenced, never as held or nearing completion
C.Med-Arb stated as long-term designation goal	`[verified 2026-08-25 — strategy brief §I, §IV]`
Kompass Arbitration Certificate Program — completed	`[verified 2026-08-25 — strategy brief §I]`
Stitt Feld Handy negotiation and ADR workshop sequence — completed	`[verified 2026-08-25 — strategy brief §I]`
Practising machine-learning and DevOps / infrastructure engineer	`[verified 2026-08-25 — strategy brief §I, §V]`
Bilingual English and Farsi	`[verified 2026-08-25 — strategy brief §I]`
Iranian-Canadian; cross-cultural fluency with diaspora business communities	`[verified 2026-08-25 — strategy brief §I]`
Operator of SML Company Ltd. alongside the practice	`[verified 2026-08-25 — strategy brief §I]`
Memberships: ADRIC, ADRIO, OBA sections	`[verified 2026-08-26 — Pouya]`. Which OBA sections is still `[assumed]` — the brief names Construction & Infrastructure, ADR, and Civil Litigation
~~OCNI~~	Not current. Do not publish `[verified 2026-08-26 — Pouya]`
~~LSO~~	Do not publish. Listing the Law Society among memberships implies licensure, which D13 bars. Excluded deliberately, not by oversight `[verified 2026-08-26]`
Toronto, Ontario; by appointment	`[verified 2026-08-26]`
Contact: `info@smlcompany.ca`; no public phone number; consultations by scheduled call	`[verified 2026-08-26 — Pouya]`
LinkedIn: `https://www.linkedin.com/in/pouyalajevardi/`	`[verified 2026-08-26 — Pouya]`
~~The boutique may be named on the site~~	STRUCK 2026-08-26 (Q25). Superseded by D16 — never named. Pouya said it could be named, then reversed; the permission survived the reversal and sat in the Verified table authorising exactly what D16 bars. Refer to it only as a Toronto litigation and ADR boutique

Forbidden — must not appear on the site

Scope, clarified 2026-08-26. This table governs published pages — anything a visitor to adr.smlcompany.ca can read, JSON-LD included. It is not a word filter over the repository's own documentation.

Internal docs are bound by a related rule: they must not assert as fact anything this register has not verified. Reasoning built on an unverified premise propagates into copy. Licensure is the live example — the Verified table above does not establish licence status either way; its two licensure rows are verified directives not to publish, not a verified status. So no file in this repo may call Pouya "licensed", or soften it to "a legal professional", internal or not. State the reason for a rule rather than a credential the register cannot vouch for.

Never publish	Why
Any count of matters closed, hours mediated, or years in ADR practice	Practice is new. Small true numbers do not persuade a sophisticated GC and invite scrutiny. Save for one-to-one appointment proposals where context travels with the figure. `[verified 2026-08-25 — content brief, "Rule of thumb on numbers"]`
Settlement rates, resolution percentages, median time to award	No underlying data exists
Aggregate value resolved; any dollar figure attached to past matters	No underlying data exists
Named or describable past matters	Confidentiality, and none are publishable
Testimonials, endorsements, quotes from counterparties	None exist. The prior site's testimonial was fabricated
"Since 2009", "sixteen years", London / New York offices, Co. № 07452218	Artefacts of the placeholder template. All false
The name "S. M. Lawrence"	Fictitious founder from the template
Guarantees of outcome, or superlatives ("best", "leading", "top-rated")	LSO marketing rules
The word "lawyer" used of Pouya; "called to the bar"; "licensed"; "my law practice"; "my litigation practice"; any post-nominal implying a licence	D13. The site asserts the JD and nothing further
Any phrasing that implies entitlement to practise law without saying so — "acts for clients", "represents parties", "my clients", "legal advice"	Same rule. Implication is the risk, not just the word. Describe the role factually instead: Director of Firm Operations at a Toronto litigation and ADR boutique, and the matter types worked on
Q.Arb described as held, imminent, or "nearly complete"	It commenced August 2026

The substitution principle

Wherever the design wants a "how much / how many" statistic, substitute a longer-arc credential — something already substantial and true at launch that does not grow by closing files. The approved stat set is Q.Med / JD + ML / EN · FA, with Q.Arb as a fourth slot where one exists. [verified 2026-08-25 — content brief]

5. Audience model

All four tiers matter, but they are served by different surfaces rather than by diluting every page into a compromise. [verified 2026-08-25 — decision D6]

Tier	Reads	Wants	Primary surface
In-house / general counsel	Home, practice pages	Credentials, subject-matter fluency, procedure, predictable cost	Home + `/practice/*`
Referring lawyers and litigation boutiques	Practice pages, fees, process	Availability, rules familiarity, rate card, confidence you won't embarrass them	`/fees/`, `/process/`, `/mediation/`
Appointing bodies and ADR institutions	About, credentials	A verifiable credential record and evidence of depth	`/about/`
Self-represented parties and SMEs	Plain-language layer	What mediation actually is, what it costs, what happens	`/for-parties/`

Realistically, referring counsel are the largest source of early appointments. Where two audiences conflict on a page, resolve toward counsel. [assumed]

6. Architecture

Full sitemap, URL map, and per-page content outline: docs/01-architecture.md.

Summary: ~20 static pages. Home; About; three process pages (Mediation, Arbitration, Med-Arb); six practice-area pages; Process; Fees; For Parties; Insights index and articles; Contact; Privacy; Terms.

Deliberate omission: there is no Indigenous engagement / IBA practice page at launch, though the strategy brief rates that niche as strategically the most valuable. Publishing a practice page for it before the multi-year relationship work described in brief §III.4 has been done would read as overreach to exactly the audience it targets. Revisit at month 12–18. [verified 2026-08-25 — decision recorded here, not yet discussed with Pouya]

7. Environment and stack

Thing	Value
Framework	Astro, `output: 'static'` `[verified 2026-08-25 — D1]`
Node	22 LTS, pinned in `.nvmrc`; `package.json` `engines.node` `>=22` `[verified 2026-08-26 — .nvmrc, package.json]`
Styling	Plain CSS with custom properties. No Tailwind, no CSS-in-JS `[verified 2026-08-25]`
Client JS	Astro islands only, where genuinely needed. Target: most pages ship zero JS `[verified 2026-08-25]`
Content	Astro content collections, MDX for Insights `[verified 2026-08-25]`
Fonts	Instrument Serif + Geist + Geist Mono, self-hosted, `font-display: swap` `[verified 2026-08-25]`
AWS account	`327082975128` `[verified 2026-08-26 — inventory]`
Region	`ca-central-1` throughout — hosting, Lambda, DynamoDB `[verified 2026-08-26]`
S3 bucket	`adr-smlcompany-site` — versioning Enabled, so rollback works `[verified 2026-08-26]`
CloudFront	`E1OK7G98KNKUTA`, alias `adr.smlcompany.ca`, origin `adr-smlcompany-site.s3.ca-central-1.amazonaws.com`, Deployed `[verified 2026-08-26]`
ACM certificate	`arn:aws:acm:us-east-1:327082975128:certificate/2b6d5bdf-6790-430c-9b82-c00ab66e6d87` — ISSUED `[verified 2026-08-26]`
Intake API	`adr-intake-api`, HTTP API `4tl0m5igkj`, endpoint `https://4tl0m5igkj.execute-api.ca-central-1.amazonaws.com` `[verified 2026-08-26]`
Intake Lambda	`adr-intake-handler`, `nodejs24.x` `[verified 2026-08-26]`
Intake table	`adr-intake-submissions` (DynamoDB, ca-central-1) `[verified 2026-08-26]`
SES identities	Domain `smlcompany.ca` verified for sending `[verified 2026-08-26]`; addresses `info@`, `intake@`, `adr@`
SES account	Production access GRANTED — out of the sandbox in `ca-central-1`, confirmed by AWS in writing and effective immediately `[verified 2026-08-26 — Q19 closed]`. Mail now reaches unverified recipients, so the inquirer confirmation in D18 works
Mail hosting	Google Workspace — MX `1 smtp.google.com`; `google._domainkey` present, so Google DKIM is configured `[verified 2026-08-26 — DNS query]`
SPF	PRESENT. `v=spf1 include:_spf.google.com include:amazonses.com ~all` on `@`, added by Pouya and independently verified `[verified 2026-08-26 — DNS query, Q20]`
DMARC	PRESENT. `v=DMARC1; p=none; rua=mailto:info@smlcompany.ca; fo=1` on `_dmarc`, added by Pouya and independently verified `[verified 2026-08-26 — DNS query, Q20]`. Still at `p=none`; tighten to `quarantine` only after reports come back clean
Required DNS (Namecheap)	TXT `@` → `v=spf1 include:_spf.google.com include:amazonses.com ~all` · TXT `_dmarc` → `v=DMARC1; p=none; rua=mailto:info@smlcompany.ca; fo=1` `[assumed]` — start at `p=none`, tighten after monitoring
SES DKIM — the set that actually resolves	`f5puwearz5ek47aiuoskk57ya6ir66ju`, `jdue2r22cxrk27laxlgnjcpby2fq4vxu`, `kznn3cklvwh4gs342rtf5euqymlger53` — all three answer NOERROR at `<token>._domainkey.smlcompany.ca` `[verified 2026-08-26 — DNS]`
SES DKIM — the set that is BROKEN	`3zsnvsjg3ddi6hjyndjy6jgjoitvhydl`, `jejgp7na3wdpprsanamct4uxxgw2tyqw`, `xpiwyftpodmgpnzfof3ee7t7fzmlmhnh` — listed in the SES console, present in Namecheap, but NXDOMAIN. They were entered with the full name in Namecheap's Host field, so the zone doubled the domain: `<token>._domainkey.smlcompany.ca.smlcompany.ca` resolves, the correct name does not `[verified 2026-08-26 — DNS]`
SES identity — `ca-central-1` (the one that matters)	`Verified: true`, `DkimStatus: SUCCESS`, tokens `kznn…` / `jdue…` / `f5pu…` — the set that resolves. Healthy. Change nothing `[verified 2026-08-26]`
SES identity — `us-east-1` (unused)	`Verified: false`, `DkimStatus: PENDING`, tokens `3zsn…` / `jejgp…` / `xpiwy…` — the doubled-domain set. A stray identity in a region this project does not use `[verified 2026-08-26]`
⚠️ SES sandbox is per-region	Recorded as a standing caution, not an open task — production access was granted in `ca-central-1` (Q19). The trap: the AWS console defaults to `us-east-1`, and granting access there leaves `ca-central-1` in the sandbox with the intake email still failing. Applies again to any future SES request `[verified 2026-08-26]`
SES custom MAIL FROM	Not configured — SES reports "No MAIL FROM records found". This is why SES's SPF is unaligned and DMARC rests on DKIM. Optional future improvement, not required `[verified 2026-08-26]`
SES monitoring — SNS topic	`ses-alerts`, `ca-central-1`. Email subscription to `info@smlcompany.ca` is PENDING CONFIRMATION, not confirmed `[verified 2026-08-26]`. Until the subscription is confirmed the alarms below fire into nothing — confirm the link in the subscription email
SES monitoring — alarms	`SES-BounceRate-High` (bounce rate ≥ `0.03`) and `SES-ComplaintRate-High` (complaint rate ≥ `0.001`), both `ca-central-1`, `treat-missing-data: notBreaching` `[verified 2026-08-26]`
SES bounce/complaint handling	Email feedback forwarding — SES's default, on unless disabled. Deliberately not an SNS feedback topic: at under 100 messages a month there is nothing to consume a programmatic feed. Revisit when code needs to act on a bounce `[verified 2026-08-26]`
DMARC alignment	SES satisfies DMARC via DKIM, not SPF — without a custom MAIL FROM domain its envelope sender is at `amazonses.com` and is unaligned. The SPF record's real job is authenticating Google Workspace mail `[verified 2026-08-26]`
Do not delete	Two ACM validation CNAMEs → `jkddzztszm.acm-validations.aws`. They renew the `adr.smlcompany.ca` certificate; deleting them breaks HTTPS silently at the next renewal `[verified 2026-08-26]`
Root domain	`@` carries a Namecheap URL Redirect Record to `sml-coming-soon.ca`. TXT records coexist with it — adding SPF does not disturb it `[verified 2026-08-26]`
DNS confirmed	`adr.smlcompany.ca` CNAME → `d26v23dhgsp2ta.cloudfront.net` `[verified 2026-08-26]`
TLS	ACM certificate `[verified 2026-08-25 — AWS-Hosting-Guide.md]`
DNS	Namecheap, not Route 53 `[verified 2026-08-25 — AWS-Hosting-Guide.md]`
Intake backend	API Gateway (HTTP API) → Lambda → DynamoDB, notifications via SES `[verified 2026-08-25 — AWS-Hosting-Guide.md]`
Repository	`adr-sml`, self-hosted Gitea. Local clone at `/Users/pouya/Dev/Websites/adr-sml` `[verified 2026-08-26]`
CI/CD	Gitea Actions, `.gitea/workflows/deploy.yml`. The GitHub OIDC workflow is kept as `docs/reference/github-actions-oidc.yml.example` — moved out of `.github/workflows/` on 2026-08-26 so Gitea cannot fall back to it. Credentials: scoped IAM user in Gitea secrets — no OIDC available. Whether that IAM user has actually been created is Q22 `[verified 2026-08-26 — D3 as amended]`
Analytics	Plausible or Fathom — cookieless, no personal data, no consent banner, EU-hosted `[verified 2026-08-26 — D15]`

8. Design system

Full token set, type scale, motion rules, and contrast results: docs/02-design-system.md.

Palette and infinity mark carry over unchanged. Execution is modernized: fluid type scale, self-hosted fonts, an 8 px spacing scale, motion gated behind prefers-reduced-motion, and one hard accessibility constraint discovered by measurement:

Gold #c9a876 on cream #faf7f2 measures 2.10:1 contrast. That fails WCAG AA for body text (4.5:1) and for large text (3:1). Gold is a decorative and on-dark colour only. On maroon it measures 5.84:1 and on ink 8.00:1, both of which pass. [verified 2026-08-25 — computed]

9. Open questions — blocking

Nothing below can be invented. Each needs an answer from Pouya.

#	Question	Blocks
Q1	ANSWERED 2026-08-26. Licensure is left out entirely; the site asserts the JD only. See D13	—
Q2	ANSWERED 2026-08-26. Q.Arb commenced August 2026	—
Q3	ANSWERED 2026-08-26. Email `info@smlcompany.ca`. No public phone — "By scheduled call". Location: Toronto · Ontario · By appointment	—
~~Q4 / Q14~~	ANSWERED 2026-08-26. Rate card confirmed by Pouya — see D14 and `docs/07-fees.md`	—
~~Q13~~	ANSWERED 2026-08-26. Self-hosted Gitea with Gitea Actions	—
~~Q15 / Q16 / Q17~~	ANSWERED 2026-08-26. Non-mediation hourly $500. Prep bundled: 2 h in the half day, 3 h in the full day, stated on the page. Overtime $500/h	—
~~Q25~~	ANSWERED 2026-08-26. Struck. The §4 row permitting the boutique to be named is removed; D16 governs alone	—
~~Q26~~	ANSWERED 2026-08-26. §4 now carries an explicit Licence status — NOT ESTABLISHED row, and its opening no longer asserts that LSO rules apply. The register's rationale stands on the fabricated-credentials history alone	—
~~Q24~~	ANSWERED 2026-08-26. `AWS-Hosting-Guide.md` copied into `docs/reference/` — it is the only record of how the hand-built infrastructure was created. Scanned for credentials before copying: no access keys, no secrets, no account ID	—
Q22	Has the deploy credential actually been provisioned? `docs/06-deployment.md` instructs creating IAM user `adr-sml-deploy`, issuing an access key, and setting `AWS_ACCESS_KEY_ID` / `AWS_SECRET_ACCESS_KEY` in the repository's Gitea Actions secrets. It is written imperatively — a procedure to perform, not a record of one performed — and nothing in this file records any of it as done; the inventory behind Q10 captured no such principal. Check with `aws iam get-user --user-name adr-sml-deploy`. Until it is confirmed, no file may describe the credential as existing, only as designed. The §10 rotation obligation has no subject until this is answered	CI/CD, the first deploy, and the accuracy of every credential claim in the docs
Q5	Booking tool — parked 2026-08-26 at Pouya's request. Build `/contact/` with the form only and a clean slot for the embed. Now tracked as standing reminder R6	`/contact/` — non-blocking
Q6	ANSWERED 2026-08-26. Supplied and committed: `src/assets/pouya-lajevardi.jpg` (1600×1600 master) and `src/assets/og-portrait.jpg` (1200×630 link-preview crop)	—
Q7	ANSWERED 2026-08-26. Pouya reverted to generic. The boutique is never named; refer to it as a Toronto litigation and ADR boutique throughout	—
Q8	ANSWERED 2026-08-26. ADRIC, ADRIO, OBA sections. Not OCNI. Not LSO (see §4)	—
Q9	ANSWERED 2026-08-26. Gitea, repo `adr-sml`, clone at `/Users/pouya/Dev/Websites/adr-sml`	—
~~Q10~~	ANSWERED 2026-08-26. Full inventory captured; values in §7	—
~~Q18~~	ANSWERED 2026-08-26. `smlcompany.ca` is verified for sending — `true`. The `None` in the earlier listing was a query artefact, not a fault	—
~~Q19~~	ANSWERED 2026-08-26. Production access granted in `ca-central-1`, confirmed by AWS in writing, effective immediately. The per-region trap was real and was avoided — it was requested in `ca-central-1`, not the console's default `us-east-1`. Nothing now blocks `/contact/`	—
~~Q20~~	ANSWERED 2026-08-26. Both records added by Pouya and independently verified: SPF `v=spf1 include:_spf.google.com include:amazonses.com ~all` on `@`, DMARC `v=DMARC1; p=none; rua=mailto:info@smlcompany.ca; fo=1` on `_dmarc`. Both existing `@` TXT records, Google DKIM, MX, and the `adr` CNAME all confirmed intact	—
~~Q21~~	ANSWERED 2026-08-26. `ca-central-1` is healthy (`SUCCESS`) on the resolving token set. The broken records belong to a stray `us-east-1` identity this project does not use. Nothing to fix. The three dead CNAMEs are inert; leaving them is the low-risk choice	—
~~Q11~~	ANSWERED 2026-08-26. Privacy-first, cookieless — Plausible or Fathom. No GA4, no consent banner	—
~~Q12~~	ANSWERED 2026-08-26. `https://www.linkedin.com/in/pouyalajevardi/`	—
Q27	Is a one-business-day response time a commitment you want published? `src/data/site.ts` carried `responseTime: 'Inquiries are answered within one business day.'` — a service level a reader can hold you to, and not in the §4 register. Set to `null` with a `TODO(pouya)` until confirmed. Raised by `claims-auditor`, 2026-08-26	The `/contact/` page copy
Q28	Which OBA sections? §4 verifies OBA membership but marks the section list `[assumed]` — the brief names Construction & Infrastructure, ADR, and Civil Litigation. `src/data/site.ts` was publishing all three under a blanket `[verified]` stamp; now marked and flagged. Raised by `claims-auditor`, 2026-08-26	The `/about/` credentials list
~~Q29~~	ANSWERED 2026-08-26 by implementation. Guard widened on both counts: the two secrets are checked (emptiness only, never echoed), and `INTAKE_ENDPOINT` is promoted to job-level `env:` and guarded. Every `vars.` and `secrets.` the workflow consumes is now covered except `BOOKING_URL`, empty by decision (R6)	—
Q23	Is a Gitea `act_runner` registered to this repository or its organisation? Without one the workflow queues silently and never runs — indistinguishable from a broken pipeline (`docs/06-deployment.md`). The Gitea-version half of this question is closed: rather than record a version fact that goes stale, `.gitea/workflows/deploy.yml` now runs a guard as its first step that fails the run if `AWS_REGION`, `S3_BUCKET`, or `CLOUDFRONT_DISTRIBUTION_ID` is empty — which is how a pre-1.21 instance manifests. Pouya's decision, 2026-08-26. Runner registration is not something a guard can cover	The first deploy

10. Risks

Risk	Severity	Mitigation
A fabricated or unverifiable claim reaches a public page	High — professional-conduct exposure	§4 register; every claim traced to a source before it ships
Copy silently carried over from the placeholder template	High	Nothing is ported verbatim. All copy written fresh against `docs/03-content-spec.md`
Insights section launches and then goes stale	Medium	D9 commits to 3–5 pieces at launch and a monthly cadence. A dead blog is worse than no blog
Personal data in the intake pipeline without a retention policy	Medium — PIPEDA	`docs/05-backend-spec.md` sets retention, and `/legal/privacy/` states it
Cutover breaks the live site (D11 is a single-shot deploy)	Medium	Full pre-cutover checklist in `docs/06-deployment.md`; CloudFront can be rolled back to the prior origin path
Twenty pages of thin copy rank worse than six good ones	Medium	Each page must justify itself with substantive content. Ship fewer pages rather than padded ones
Deploy-credential blast radius. AWS account `327082975128` is not a single-project account. It also holds `meshkinilaw.ca` and its preview site, `demesne.media`, `orynenergy.ca`, `lajirugs.ca`, and `mlp-clientdb-prod-backups-327082975128` (recorded in an earlier entry with the account suffix; the short form `mlp-clientdb-prod-backups` is used elsewhere in the docs) — which by its name holds production client-database backups. Only the name was ever observed; the contents were not inspected and the owner is not established	High	A static deploy key for a personal website must never be able to reach a client database. The scoped IAM policy in `docs/06-deployment.md` grants four actions on one bucket and one distribution and nothing else — that narrowness is now load-bearing, not hygiene. Never widen it. Never reuse the `user/pouya` credentials in CI `[verified 2026-08-26 — inventory]`
~~SES is in the sandbox~~	~~High~~ → RESOLVED 2026-08-26	Q19 closed: production access granted in `ca-central-1`, confirmed in writing. Residual, tracked in §7: the `ses-alerts` SNS email subscription is pending confirmation, so the bounce and complaint alarms currently notify nobody `[verified 2026-08-26]`
~~No SPF and no DMARC on `smlcompany.ca`~~	~~High~~ → RESOLVED 2026-08-26	Both records added by Pouya and independently verified (Q20). SPF authenticates Google Workspace mail; SES satisfies DMARC through DKIM alignment on the three resolving CNAMEs. DMARC sits at `p=none` — the residual task is to review reports and tighten to `quarantine`, which is monitoring, not a risk `[verified 2026-08-26 — DNS query]`

11. Glossary

Term	Meaning
ADR	Alternative dispute resolution
ADRIC	ADR Institute of Canada — national credentialing body
ADRIO	ADR Institute of Ontario — provincial affiliate
Q.Med	Qualified Mediator — ADRIC/ADRIO designation
Q.Arb	Qualified Arbitrator — ADRIC/ADRIO designation
C.Med-Arb	Chartered Mediator-Arbitrator — senior hybrid designation; the long-term goal
Med-Arb	Hybrid process: mediation that converts to binding arbitration if unresolved
SABS	Statutory Accident Benefits Schedule — Ontario auto insurance benefits
LAT	Licence Appeal Tribunal — hears Ontario SABS disputes
POA	Provincial Offences Act
ENE	Early neutral evaluation
LSO	Law Society of Ontario
OBA	Ontario Bar Association
IESO	Independent Electricity System Operator
OEB	Ontario Energy Board
SMR	Small modular reactor
PIPEDA	Personal Information Protection and Electronic Documents Act

12. Standing reminders

Surface these to Pouya at the start of any substantial session. They are open questions he has deliberately parked, not settled matters. The point of this section is that a parked decision does not quietly become permanent by never being raised again.

#	Reminder	Raised	Why it must keep coming back
R1	Licensure. No site exists yet — `src/pages/` is empty. As specified, the copy will assert the JD only and describe the boutique role as active litigation exposure, never practice. Pouya flagged that as an interim position and asked to be reminded to change it. §4 now records licence status as `[unestablished]`, which is the honest state, not a resolution	2026-08-26	If he is licensed and in good standing, it is the first credential appointing bodies and opposing counsel look for, and its absence from a detailed credentials page is conspicuous. If licensure is in progress, the copy should be rewritten the moment it completes. Either way this is a temporary framing that will otherwise ossify
R2	Matter counts stay off the site until they are independently credible. Revisit once there is a number a sophisticated GC would find persuasive on its own	2026-08-26	§4 forbids them now. That rule has an expiry date nobody has set
R3	Indigenous engagement practice page. Deliberately omitted at launch (§6). Revisit at month 12–18	2026-08-26	The strategy brief rates it the most valuable single niche. Omission is a timing call, not a permanent one
R4	Insights cadence. D9 commits to monthly. A blog that stops is worse than one that never started	2026-08-26	The section's whole value is compounding
R5	Fee review at 12 months. Published rates are sticky; the right moment to move them is deliberate, not reactive	2026-08-26	D14 is priced for where the practice is going, not where it is
R6	Booking tool. Parked by Pouya on 2026-08-26; `/contact/` ships with the intake form and a reserved slot for an embed	2026-08-26	He asked to be reminded. D10 committed to booking because it removes the back-and-forth that loses appointments — the form alone is a partial answer
R9	The SES alarms notify nobody until the `ses-alerts` email subscription is confirmed. `SES-BounceRate-High` and `SES-ComplaintRate-High` are configured and live; the SNS email subscription to `info@smlcompany.ca` is pending confirmation, and an unconfirmed subscription drops every message	2026-08-26	A monitoring control that exists but does not deliver is worse than none, because it reads as covered. At this volume five bounces can cross the ~5% suspension threshold. Tracked in §7 and on the cutover checklist, but a one-click task nobody owns is exactly what §12 is for
R7	RATIFIED / SUPERSEDED 2026-08-26. (a) Cache-policy table matching the pipeline — accepted; documenting what the pipeline does beats documenting an intention. (b) `s3:AbortMultipartUpload` omitted — accepted, reasoning corrected: the lifecycle rule does not exist and is therefore not the cover; the actual cover is that `aws s3 sync` only goes multipart above 8 MB and the largest asset is a 357 KB portrait. Recorded in `docs/06-deployment.md` with a revisit trigger. (c) The `aws s3 ls` pre-flight — superseded by the variable guard now running as the workflow's first step	2026-08-26	—
R8	PROMOTED TO A RULE 2026-08-26. A reminder was too weak for a pattern that survived three entries. A sweep is a command, not a claim now sits in `CLAUDE.md` under Conventions, in `/build` Phase 6, and in `/wrap` step 3: any claim that a change was applied across files must cite the command and be written only after reading its output	2026-08-26	—

Change Log

2026-08-26 (r) — Q19 closed; SES monitoring recorded; §7 made the single source of operational truth

Who: Pouya closed Q19, supplied the monitoring configuration, ruled on Q29, and made the structural call below. Claude Code implemented.

Q19 — CLOSED. Nothing now blocks `/contact/`

Production access granted in ca-central-1, confirmed by AWS in writing, effective immediately. §7's SES account row and §9's Q19 both record it; §10's High risk row for the sandbox is struck as resolved.

The per-region trap is kept in §7 as a standing caution rather than an open task — it was avoided, and it applies again to any future SES request. Deleting the row would delete the lesson.

Monitoring exists, and one part of it does not work yet

Recorded in §7 (the facts) and docs/05-backend-spec.md (why it matters):

SNS topic ses-alerts, ca-central-1. The email subscription to info@smlcompany.ca is PENDING CONFIRMATION, stamped that way deliberately. An unconfirmed SNS subscription drops every message, so as things stand the alarms below fire into nothing. That is now a cutover checklist item in its own right, checked with sns list-subscriptions-by-topic rather than assumed.
SES-BounceRate-High (≥ 0.03) and SES-ComplaintRate-High (≥ 0.001), both ca-central-1, treat-missing-data: notBreaching.
Bounce and complaint handling is SES email feedback forwarding — the default — not an SNS feedback topic, deliberately. Under 100 messages a month there is nothing to consume a programmatic feed, and an unused topic is one more thing to keep correct. Revisit when code needs to act on a bounce: suppression lists, retry logic, marking a record undeliverable.

docs/05 records why these are a real control rather than a formality: SES suspends sending above roughly a 5% bounce rate, and at this volume five bounces crosses it. An intake form is exactly where mistyped addresses arrive. The alarms sit well below that line so there is room to react.

The structural fix — §7 is the single source of truth for operational facts

Old → new. Specs in docs/ carried their own copies of resource IDs, regions, DNS records, and service state. They now cite §7 instead.

The reasoning is entry (q)'s DKIM inversion, generalised: the same operational fact lived in §7 and in docs/05, a correction reached one of them, and the stale copy ended up instructing an operator to delete the three records that authenticate outbound mail — under the heading "Never delete". Same class as the D3 amendment surviving three sweeps. A duplicated fact is a fact that will eventually be wrong in one place, and the copy that goes stale is the one nobody re-reads.

The rule is now in CLAUDE.md under Conventions, with that incident as its stated reason so it is not softened later by someone who does not know the cost.

Swept. docs/05 no longer restates the DKIM token sets, the DNS records, the MX, the region, or the table name — it cites §7 and keeps only the two facts it depends on, stated as dependencies. docs/06 no longer restates the region, bucket, distribution ID, intake endpoint, or account ID; its variable table now points at §7 rows, and the IAM substitutions say explicitly that they are not repeated and why. Verified by command:

grep -rn "ca-central-1\|adr-smlcompany-site\|E1OK7G98KNKUTA\|4tl0m5igkj\|327082975128\|adr-intake-submissions\|d26v23dhgsp2ta\|jkddzztszm" docs/*.md

Output read: no matches. Every operational identifier in docs/ is now a reference.

Q29 — the guard is widened on both counts

Both gaps adversarial-reviewer found are closed:

AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are guarded. By Q22 nobody has confirmed the IAM user or its key exists, so an unset key is the single likeliest first-run failure — excluding it defeated the guard's stated purpose. Only emptiness is tested and no value is ever echoed, so nothing can leak into a run log.
INTAKE_ENDPOINT promoted to job-level env: and guarded. An empty one does not fail a build; it ships a live contact form posting to nothing. A silent production defect is worse than a failed build.

The build step still reads ${{ vars.INTAKE_ENDPOINT }} rather than the env context — depending on Gitea's expression-context support is the exact thing the guard exists not to do. Coverage checked against every vars.* and secrets.* the workflow consumes: all guarded except BOOKING_URL, which is empty by decision (R6).

Also done

docs/06: the account ID is out of the backup-bucket callout, pointing at §10 instead — the same removal entry (m) made in README.md. Operational usefulness does not outweigh pairing a live account number with a statement about what the account holds, in a file that gets pasted around. The billing check now derives the account from sts get-caller-identity rather than hard-coding it.

astro.config.mjs: prefetch removed entirely — recorded here as a decision, not a silent deletion. Any prefetch setting ships Astro's prefetch script to every page, against CLAUDE.md's "default to zero JS", for a marginal gain on a small static site already served from CloudFront. Revisit only against real Lighthouse numbers, once pages exist to measure. Entry (q) had set it to hover; that was still JS on every page.

Gitea version stays [assumed] at Pouya's direction — he is running the check. The guard is designed not to need the answer.

Verification

The widened guard's run: block was executed under sh -e across four input states — all set, all empty, secret empty, intake empty. Exit 0 only when everything is present; exit 1 naming exactly the missing items otherwise; no value printed in any case. node --check astro.config.mjs passes. The duplication sweep was run as the grep above and its output read — no matches.

npm run lint, check and build still cannot run: node_modules is absent and npm ci needs a lockfile. Installing dependencies is the first concrete task of build step 1.

Closed: Q19 (and with it the last blocker on /contact/). Still open: Q22 (deploy credential), Q23 (runner registration), Q27, Q28, R6 (parked). Q29 closed by implementation.

2026-08-26 (q) — Guard built; and the audit found an inverted DKIM table that would have broken production mail

Who: Pouya ruled on entry (o)'s escalations, ratified R7, promoted R8, and reversed his own F5. Claude Code implemented, ran claims-auditor and adversarial-reviewer in parallel, and resolved 31 + 17 findings.

The six rulings, implemented

Q23 hardened, not checked. .gitea/workflows/deploy.yml now runs a guard as steps[0] — before checkout, before npm ci, before any AWS call — that fails the run naming any of AWS_REGION, S3_BUCKET, CLOUDFRONT_DISTRIBUTION_ID that is empty. It tests the env names (AWS_DEFAULT_REGION) and reports the Gitea variable names, which is the mapping most likely to be got wrong. adversarial-reviewer executed the extracted block under bash -e, sh -e, and bash -euo pipefail across all-unset / all-set / one-empty / whitespace-only and confirmed it fails closed and is POSIX-clean.
R7(3) dropped — the aws s3 ls pre-flight is out; the guard supersedes it.
R7(1) ratified — the cache table stays matched to the pipeline.
R7(2) reasoning corrected. Old → new: "the intended cover is an S3 lifecycle rule" → no lifecycle rule exists and is not the cover; the cover is that aws s3 sync only goes multipart above 8 MB. Corrected once more after audit: the figure now measures what is uploaded, with src/assets/pouya-lajevardi.jpg at 357,627 bytes [verified — stat] as the largest source asset and an instruction to re-measure ./dist after the first build. The old wording measured the repository, which is not what syncs.
R8 promoted to a rule in CLAUDE.md, /build Phase 6, /wrap step 3.
R1 put in the conditional — there is no site; src/pages/ is empty.

The finding that mattered most was nowhere near the diff

docs/05-backend-spec.md had the two SES DKIM sets exactly inverted. It labelled 3zsn… / jejgp… / xpiwy… "Live. Matches SES exactly. Never delete", and f5pu… / jdue… / kznn… "Orphans from an earlier verification. Inert." §7 records the opposite, [verified 2026-08-26 — DNS]: the f5pu set is the one that resolves and backs the healthy ca-central-1 identity; the 3zsn set is NXDOMAIN and belongs to a stray us-east-1 identity.

Entry (j) corrected this. The correction reached §7 and never reached docs/05. An operator tidying DNS from that table deletes the three CNAMEs that make SES DKIM work — and since SES has no custom MAIL FROM, DKIM is the only thing satisfying DMARC. Outcome: intake mail from ca-central-1 starts failing authentication, silently, and the table said "Never delete" over the wrong three records. Both rows rewritten from §7. The "six CNAMEs" claim below them now says three, which is how many answer.

Current Truth was stale in three more places

§7 SPF and DMARC still read "ABSENT" [verified 2026-08-26], and §10 still carried a live High risk row for it — while Q20, in the same file, records both records added and independently verified the same day. Rule 2 requires Current Truth updated in place; it was not. Both §7 rows now record the live values; the §10 risk row is struck as RESOLVED, with the residual p=none → quarantine tightening described as monitoring rather than risk. docs/05 opened with "it is not in place" and a table headed "Add both of these" for records that already exist — rewritten, with the superseded state kept visible as a caution.

§9 carried Q24, Q25 and Q26 twice each, struck and open, with opposite verdicts. The live Q25 still asserted §4's boutique-naming permission stands — against D16 — after entry (p) had struck it. This is the duplicate-question defect entry (o) fixed for Q22, reintroduced three times in one session: entry (p) added struck rows rather than striking the existing ones. The three superseded open rows are deleted.

The guide added in entry (p) was a live procedure for the architecture being replaced

docs/reference/AWS-Hosting-Guide.md was added untracked — so Q24's answer ("copied into docs/reference/") was true of one working tree and false of the repository — with no reference-only marker, in fully executable imperative voice. Following it creates an IAM user with AdministratorAccess in account 327082975128, rebuilds the site through the standalone-HTML pipeline D1 and D3 replace, and wires SES to adr@ / intake@smlcompany.ca against D18's info@. It is now git added and carries a do-not-execute banner tabulating seven contradictions with Current Truth, each resolved in Current Truth's favour.

It also called Pouya a lawyer — "Audience: You (a lawyer, not a sysadmin)" — and proposed public copy reading "does not create a lawyer-client relationship", which is what NO_RETAINER_NOTICE in src/data/site.ts was written to avoid. Both corrected.

The R8 sweep command recorded in entry (o) could not have caught either. grep -rn -i "licensed\|legal professional" does not match "lawyer". The rule promoted this session is right; the pattern it was demonstrated with was incomplete. The corrected sweep is:

grep -rn -iE "\blawyer\b|licensed|legal professional|litigator" \
  --include="*.md" --include="*.ts" --include="*.astro" .

Run, output read. Every surviving hit is rule text, Change Log history, or "lawyer" referring to the reader or a third party (docs/03:20, docs/03:161, docs/01:291, docs/08:111) — none describes Pouya.

Copy defects one step from shipped pages

"a working litigator" — AGENTS.md §1's positioning sentence and docs/03-content-spec.md:71, the line designated for the hero, the About page and the PDF bio. Not in §4; in Ontario it asserts conducting litigation, which §4 Forbidden bars. §1's own line asserted "each element is verified"; it was not. Both now read "close to live litigation". §1's correction is annotated in place rather than silently rewritten.
"an active litigation practice" — docs/03:118, docs/01:211, docs/01:246. §4's Verified row was itself corrected from "practice" to "exposure" in entry (l); the copy decks kept the barred word. Fixed to the register's own substitute.
LegalService JSON-LD — docs/04-seo-spec.md specified it for the home page. schema.org defines LegalService as a business providing legal advice and representation: it asserts in machine-readable form precisely what D13 bars. Changed to ProfessionalService, with the reason recorded so it is not changed back. worksFor on the Person node had no register-safe value — populating it either names the boutique (D16) or misstates the employer — so it is dropped in favour of jobTitle.
Tribunal-secretary work — docs/01:173,180 and docs/03:32 instructed offering it; docs/07-fees.md:116 records Pouya removing the rate and barring the offer. Three files against one; the one was right.
§4's Forbidden table and docs/03:52 justified the superlative ban with "LSO marketing rules" — the fourth surviving form of the licensure claim, two rows below the NOT ESTABLISHED row. Restated on grounds that do not depend on licence status. (The §4 instance is the architect's to apply.)
docs/07-fees.md opened with "pending Pouya's sign-off — Q14" and "Nothing in this document publishes until Pouya confirms the figures", then contradicted itself 85 lines later with "This is the card. Build /fees/ from it." An implementer reading top-to-bottom blocks the page. Header rewritten to D14 as confirmed.
Nine stale Q blockers across five spec files — Q4, Q10, Q11, Q12, Q14, Q20, Q5 — all answered or re-tracked, three of them gating /fees/, whose figures are confirmed. Swept.

Code defects

src/data/site.ts published responseTime: 'Inquiries are answered within one business day.' — a service level a reader can hold him to, not in §4. Set null with a TODO(pouya); Q27.
The memberships block carried a blanket [verified] stamp over the OBA section names, which §4 marks [assumed]. Downgraded, flagged; Q28.
src/content/config.ts — /** Drafts are excluded from the build, the index, and the sitemap. */ describes three controls, none implemented; the sitemap filter covers /legal/ only. Same defect class as Q22. Restated as intent with a deadline. Its title/description bounds also contradicted docs/04 (max 70 / min 70 against 50-60 / 140-160); tightened to the spec.
astro.config.mjs set prefetch: { prefetchAll: true, defaultStrategy: 'viewport' }, injecting Astro's prefetch script and an IntersectionObserver into every page and speculatively fetching every link that scrolls into view — against CLAUDE.md's "default to zero JS" and §7's "most pages ship zero JS", with no Change Log entry. Set to prefetchAll: false / defaultStrategy: 'hover', the setting the written conventions imply. If prefetch-all is wanted, it needs a decision entry.
src/styles/tokens.css attached the ink contrast figure (11.09:1) to both ink and maroon; on maroon --gold-l measures 8.11:1. Both pass AA, so no accessibility consequence — but the token file is what developers read.

Also corrected

docs/06 cited a billing alarm verified by cloudwatch describe-alarms; the guide set up an AWS Budget, which that command never returns — and nothing records either as created. Now names budgets describe-budgets and says confirm, do not assume. The booking cutover check is marked conditional on R6, since BOOKING_URL is empty by decision. scripts/aws-discover.sh and docs/06 claimed "every call is a list or describe" — four are not (sts get-caller-identity, apigatewayv2 get-apis, s3api get-bucket-versioning, configure get); all are genuinely read-only, so the substance held and the wording did not. Four stale AWS-Hosting-Guide.md paths repointed at docs/reference/. The reference workflow still said "Two passes" above three sync steps — the one file entry (o)'s three-pass sweep missed, and a twelve-character grep would have caught it. The IAM procedure had 22 lines of multipart prose between "attach this policy" and "create an access key", which also broke the ordered list in CommonMark; moved below step 3.

Declined, with reasons

The guard was not widened. adversarial-reviewer showed it does not cover the secrets — and by Q22, an unset key is the most likely first-run failure, so the stated benefit ("one second instead of a full build") does not apply to the likeliest case — nor vars.INTAKE_ENDPOINT, whose absence would ship a live form posting to an empty endpoint. Both are real. Neither was done: the ruling named three variables, and INTAKE_ENDPOINT additionally needs promoting to job-level env:. What was fixed instead is the guard's comment, which claimed it converted the problem "on every Gitea version" into a clean failure — broader than what it implements. It now states its scope and points at Q29.

The Gitea 1.21 claim is stamped [assumed], not verified. The version could be confirmed with one command on the instance. It was not run here; the guard is designed to work without knowing the answer, so the stamp is the honest record.

docs/06 still pairs the account ID with the backup-bucket callout — the pairing entry (m) removed from README.md as an inference vector. docs/06 is an operational document where the account ID is load-bearing, unlike the README. Flagged rather than changed; if you want it out, it moves to aws-inventory.txt, which is gitignored.

Verification

The guard's run: block was extracted from parsed YAML and executed by adversarial-reviewer under three shells and four input states — fail-closed confirmed. Both workflow YAMLs parse. The barred-word sweep was run as the grep -iE above and its output read. stat gave 357,627 bytes. npm run lint, check and build were not run: node_modules is absent and npm ci cannot install without a lockfile, so the astro.config.mjs, site.ts and config.ts edits are unverified by any type-checker — they are small and syntactically simple, and that is the whole of the assurance.

Opened: Q27, Q28, Q29. Still open: Q22, Q19 (blocking), Q23 (runner half), Q5/R6 (parked). Closed by entry (p), confirmed here: Q24, Q25, Q26.

Lesson. Entry (o) said the sweep must be a command whose output is read. This entry adds what that costs when the command is wrong: the pattern licensed|legal professional cannot match "lawyer", so a compliant sweep still missed a file added in the same session. And the largest finding of the session was in a file nothing had asked either reviewer to look at. Both reviewers were pointed at a diff; the destructive defect was three files away, left by a correction that reached one file and stopped. Scope the audit to the decision that changed, not the lines that changed.

2026-08-26 (p) — Q24, Q25, Q26 answered; R7 ratified; R8 promoted to a rule

Who: Pouya relaying Claude Code's session close. Claude (architect) deciding.

Q25 — struck. This was the dangerous one and it was mine. §4's Verified table carried "The boutique may be named on the site", authorising precisely what D16 — never named forbids. Sequence: Pouya said it could be named, then reversed; D16 recorded the reversal; the permission was never removed. A locked decision and the table copy is written from disagreed, and the table was the more permissive of the two. Struck.

The general defect: reversing a decision requires removing the permission it granted, not only recording the new position. Same shape as the D3 amendment that went unswept three times.

Q26 — answered, and the third form of the same claim is gone. §4's opening asserted "Every public claim on this site is subject to Law Society of Ontario marketing rules" — which asserts regulatory status by implication, since those rules bind licensees. Claude Code was right that this is the same half-measure as the "legal professional" reversal, one level further down.

Old → new: the register's rationale no longer rests on licensure at all. It rests on the fabricated-credentials history, which is documented, sufficient, and true regardless of licence status. The paragraph's own history is kept in place as a caution — three progressively weaker forms of one unverified claim, each surviving a sweep.

§4 now carries a Licence status — NOT ESTABLISHED row. Stamped [unestablished], a new stamp for this case. It records the honest position: this file does not know, Pouya's instruction was about the site and not a statement of fact either way, and nothing may assert, deny, or infer it. Claude Code was also right that the two licensure rows were stamped [verified] as directives, which is a different thing from a verified fact — this row separates the two.

Q24 — closed. AWS-Hosting-Guide.md copied to docs/reference/. It is the only record of how the hand-built infrastructure was created, so it belongs in the repo rather than in a Drive folder the repo cites but cannot reach. Scanned before copying: no access keys, no secrets, no account ID.

Q23 — answered by hardening rather than by version-checking. The risk is real — on Gitea below ~1.21, ${{ vars.* }} interpolates empty and the sync target becomes s3://. But a version check is a fact that goes stale. Ruling: add a pre-flight guard step to .gitea/workflows/deploy.yml that fails the run if any required variable is empty, before any AWS call. That converts a silent destructive misfire into a clean failure on every Gitea version, and it subsumes R7's third item.

R7 ratified, with one amendment.

Cache-policy table amended to match the pipeline — accepted. Documenting what the pipeline does beats documenting an intention. robots.txt and sitemap*.xml at max-age=0, must-revalidate is immaterial at this size.
s3:AbortMultipartUpload omitted, lifecycle rule as intended cover — accepted, with the reasoning corrected. The lifecycle rule does not exist, so it is not the cover. The actual cover is that aws s3 sync only goes multipart above 8 MB and the largest asset in the repo is a 357 KB portrait. Record that, and add a note to revisit if any asset ever approaches 8 MB. Do not document a control that does not exist — that is Q22's defect again.
aws s3 ls pre-flight documented but not implemented — superseded by the guard step above, which covers more.

R8 promoted from a reminder to a rule. "A sweep is a command whose output is read, not a claim." Entries (l), (m) and (n) each asserted a completed sweep; instances survived all three — one of them inside claims-auditor.md, the definition of the agent whose job is to catch it. A reminder is the wrong instrument for something this reliable. It belongs in /build Phase 6 and /wrap: any claim that a change was applied across files must cite the command and be made only after reading its output.

R1's wording corrected: it says "the site currently asserts the JD only". There is no site — src/pages/ is empty. Restated in the conditional.

Closed: Q23, Q24, Q25, Q26. Still blocking the build: nothing. Still blocking /contact/: Q19. Still open: Q22, Q5 (parked).

2026-08-26 (o) — Five rulings implemented; both reviewers run; the D3 sweep finally completed

Who: Pouya ruled on entry (m)'s escalations and reversed his own F5 ruling. Claude Code implemented, ran claims-auditor and adversarial-reviewer in parallel on the diff, and resolved 27 + 17 findings.

The five rulings, implemented

§4 and §10 "licensed" — the architect's, done in entry (n).
Reversal on "a legal professional's" — cut from README.md:35 and CLAUDE.md (twice). The sentences now assert nothing about professional status and state the reason instead.
s3:PutObjectAcl dropped from the policy in docs/06-deployment.md. §10's "four actions" is now accurate without §10 being touched, and every file that states a count agrees with the policy: README.md:77, docs/06:82, .gitea/workflows/deploy.yml:13, AGENTS.md §10.
.github/workflows/deploy.yml → docs/reference/github-actions-oidc.yml.example via git mv; .github/ removed entirely. It held exactly one file — no CODEOWNERS, no dependabot, no templates — and nothing referenced the path. References updated in README.md, CLAUDE.md, docs/06, .gitea, and §7.
Q22 left open with the designed-not-confirmed phrasing intact.

The reviewers found that the D3 sweep had never actually reached `docs/06`

Both agreed on the same blocking defect, independently. docs/06-deployment.md is the file README.md points to as "Full procedure, IAM policy, runner setup" — and it still opened with:

Authority: AGENTS.md §3 D3 (git + GitHub Actions → ...) — D3 as amended says Gitea;
a topology diagram, the first content block in the file, reading GitHub push to main → GitHub Actions → assume AWS role via OIDC (no stored keys). That is the exact sentence entry (l) called "the serious one", six lines above the section that contradicts it;
an entire 19-line section, ## Why OIDC and not access keys, in the imperative — "IAM → Identity providers → add OIDC provider..." — with no marker that it does not apply, naming a third principal adr-site-deploy that conflicts with adr-sml-deploy, and citing Q9, which is answered.

adversarial-reviewer named the concrete failure: an operator working the document top-to-bottom adds a GitHub federation trust to account 327082975128 — the account §10 rates High blast-radius — that nothing will ever use, and plausibly never creates adr-sml-deploy at all. Two mutually exclusive credential procedures in one file with no signpost saying which is live.

Fixed. Authority line cites D3 as amended. Topology rewritten to Gitea + static key. The OIDC section is retitled Why OIDC would have been better — and why it is unavailable, opens with a do not execute block, and its executable steps are gone.

The "licensed" sweep had missed three more files, including the auditor's own persona

Entry (n) scoped the reversal to "README.md, CLAUDE.md (twice), and this file." Five instances survived in three files it did not name:

.claude/agents/claims-auditor.md:8 — "You audit public copy for a licensed legal professional's marketing site." This is the system prompt of the agent that enforces the rule. Its opening sentence asserted the exact claim its own §"Licensure (D13)" instructs it to flag.
.claude/agents/adversarial-reviewer.md:9 — "a legal professional's dispute resolution practice", the precise phrase entry (n) reverses.
docs/08-execution-protocol.md:63 — "a licensed professional's public marketing page". This file was edited in that same diff, eleven lines above the surviving phrase.

Entry (n) said "twice in two entries that a claim about a sweep was made without the sweep being verified. The pattern, not the instances, is the finding." This was the third. It is now swept by command, not by recall:

grep -rn -i "licensed\|legal professional" --include="*.md" --include="*.yml" .

Every surviving hit is either rule text stating the prohibition, or Change Log history, which rule 3 forbids editing.

Also fixed

Register and rule accuracy. §4's internal-docs rule cited a [assumed] stamp on licensure that does not exist — the two licensure rows are stamped [verified] as directives not to publish, which is a different thing. A reader following the pointer found nothing there, in the sentence stating the rule. Reworded here and in CLAUDE.md:30 to say what is true: the Verified table does not establish licence status either way. Duplicate Q22 — two rows, two scopes, one number, one of them mine; merged into the fuller statement, keeping the architect's aws iam get-user check command. §7 Node re-stamped [verified] — it was [assumed] for something directly checkable.

Claims that overstated what exists. CLAUDE.md:164 still said "deploys use OIDC role assumption" — verbatim the F1 claim, in a file both prior sweeps touched; it and CLAUDE.md:119 are corrected. .gitea/workflows/deploy.yml and CLAUDE.md asserted the deploy credential in the present tense; both now cite Q22. docs/06 asserted five blocking PR checks — the workflow has no pull_request trigger and neither lint nor lighthouse is wired, so nothing gates a merge today; retitled planned, not implemented. README.md:5 and docs/06's "every push deploys" both hedged against the never-run-green fact the same files establish elsewhere.

The moved reference file carried the defect the move was meant to contain. Its line 16 still read "OIDC role assumption — no long-lived AWS credentials in this repository": present tense, about this repository, and false. It also carried a live TODO(pouya): AGENTS.md Q9, Q10 against two struck rows — which CLAUDE.md's definition of done treats as a build failure — for a variable that will never be set. Both fixed, along with its claim that the file is usable on GitLab (different CI schema entirely; it is the design there, not the implementation).

Two security-posture claims narrowed. docs/06 said the workflow's aws sts get-caller-identity pre-flight means "a credential problem fails loudly and early rather than halfway through a sync." sts:GetCallerIdentity requires no IAM permission — it succeeds for any valid key regardless of policy. It catches a missing or revoked key and misses an under-scoped one, which is exactly the risk this diff introduced by removing an action. Narrowed, with the one-line aws s3 ls check that would make it load-bearing. And README.md had re-dropped §10's "which by its name is" hedge on mlp-clientdb-prod-backups — the defect entry (m) F2 records as fixed — as had docs/06:113, escalated in entry (n) and not done. Both restored.

Documentation matching implementation. The cache section described two sync passes; the workflow runs three, and two ordering dependencies are load-bearing and undocumented — pass 3 re-walks the tree and preserves pass 2's image headers only because sync skips just-uploaded objects, and pass 3's excludes also exclude those prefixes from --delete, which is why hashed assets from old deploys are kept deliberately. Both now stated. The robots.txt / sitemap*.xml row claimed max-age=3600; nothing implements it, so the table now records what the pipeline does. Two conflicting variable tables for the same five names — one under Secrets with real values, one under Variables with placeholders — merged; entering those as secrets would have masked them in the logs the doc says to read them from. Duplicate booking references (Q5 vs R6) resolved to R6. README.md said "no src/pages/"; the directory exists and is empty, which is not what a reader would find.

docs/08-execution-protocol.md — entry (n)'s inserted block landed between "claims-auditor reads the copy..." and its follow-up "It is a separate agent on purpose", leaving "It" twelve lines from its antecedent and reading as though the frontmatter were a separate agent. Block moved below.

Declined, with reasons

s3:AbortMultipartUpload not added. adversarial-reviewer traced every AWS call in the workflow against the policy and found the happy path fully covered, with this one gap: objects over 8 MB upload multipart, and an interrupted transfer cannot clean up its own parts. It recommended against adding the permission — an S3 lifecycle rule aborting incomplete uploads after 7 days solves it without widening the policy. Agreed, and left as an operational item below rather than a policy change.

The aws s3 ls pre-flight is documented, not implemented. Adding it changes the deploy pipeline, which was not in scope. It is written into docs/06 as the fix for the narrowed claim.

§4's tables untouched. Two findings land in the register itself; both are escalated below rather than edited. §4 is the architect's instrument.

Escalated — for the architect

(All four now tracked: 1 and 2 as Q25 and Q26 in §9; 3 folded into Q26; 4 left in R1, which already owns the licensure framing.)

§4's Verified table authorises what D16 forbids. AGENTS.md:153 reads "The Toronto litigation and ADR boutique may be named on the site ... the name itself is pending, see Q7." D16 says "Never named." Q7 is answered: "Pouya reverted to generic. The boutique is never named." A Verified row currently permits publication of the exact thing a locked decision bars — the same shape as the F5 defect in entry (l), in the same table, and the register is where copy is written from.
§4's opening asserts regulatory status by implication. "Every public claim on this site is subject to Law Society of Ontario marketing rules" — LSO marketing rules bind licensees. Stating flatly that they govern this site asserts the licensure §4 declines to verify, in the sentence that replaced "Pouya is a licensed legal professional". A half-measure of the same shape as the "legal professional" reversal.
Consider an explicit §4 row — "LSO licence status | UNKNOWN / not verified either way" — which would make the internal-docs rule's pointer land somewhere real instead of being reworded around.
R1 (§12) describes "the site currently asserts the JD only". There is no site; src/pages/ is empty. R1 is the reminder that must not ossify, so it should be accurate about what it describes.
Operational: add an S3 lifecycle rule aborting incomplete multipart uploads after 7 days; and once Q22 is answered, run aws s3 sync ./dist s3://adr-smlcompany-site --dryrun under the new key to confirm no s3:GetBucketLocation call is needed.
Minor: .yml.example is not a Prettier-recognised extension, so the moved reference file has silently dropped out of prettier --check coverage. Frozen reference material, so near-harmless — but nothing validates it as YAML now.

Q23–Q26 opened, none blocking the build. Q23: is an act_runner registered, and is the Gitea instance ≥ 1.21 for the vars context the workflow depends on throughout? On an older instance vars.S3_BUCKET interpolates empty and the sync target becomes s3://. Q24: AWS-Hosting-Guide.md is cited by docs/06 as the source for existing infrastructure and two cutover checks, and does not exist in the repository; the two dependent checks have been restated self-containedly, so nothing is blocked. Q25 and Q26 carry the two §4 escalations above.

R7 and R8 added to §12. R7 records three spec decisions made on Pouya's behalf and not ratified — the amended cache-policy row, the omitted s3:AbortMultipartUpload, and the documented-not-implemented aws s3 ls pre-flight. R8 records the sweep-verification lesson as a standing discipline rather than a lesson buried in one entry, which is what let it recur three times.

Verification

npm run lint, npm run check, and npm run build were not run — node_modules is absent, and npm ci cannot install without a lockfile. No JavaScript, TypeScript, or Astro source was touched. The .gitea workflow and the .yml.example were not YAML-parsed either: PyYAML is unavailable in this environment and the project has no YAML tooling installed. Both were changed only in comment blocks, and the indentation of every edited comment was checked by eye. The "licensed" sweep was executed as the grep above and its output read, not asserted. Every prose line added to README.md and CLAUDE.md is ≤ 80 columns.

Lesson. Entry (m) recorded that a correction is a change and gets reviewed like one. This pass adds the sharper version: the sweep must be a command, and its output must be read. Three consecutive entries claimed a completed sweep; three times instances survived, and the third time one of them was inside the definition of the agent whose job is to catch it. The /wrap step should require pasting the grep, not describing it.

2026-08-26 (n) — Register corrected; a declined finding reversed on appeal

Who: Pouya relaying Claude Code's re-audit. Claude (architect) recording.

Correction to entry (l), which was false. It claimed all three files had been rewritten off "licensed". Two were. This file still said it twice — §4's own opening sentence ("Pouya is a licensed legal professional") and §10's risk row ("professional-conduct exposure for a licensed practitioner"). The register was asserting as established fact the very thing it marks [assumed], in the section that exists to prevent exactly that. Entry (l) stands as written per rule 3; this is the correction. Both lines are now fixed.

That is twice in two entries that a claim about a sweep was made without the sweep being verified. The pattern, not the instances, is the finding.

Reversal — "a legal professional's" is out too. claims-auditor wanted the phrase cut entirely, arguing that in Ontario it reads as an LSO licensee and so trips the same bar as "licensed". Claude Code declined it, correctly, because it was my explicit ruling — and recorded the reasoning rather than silently keeping it, which is what let it be revisited.

On appeal the auditor is right and I was wrong. "Legal professional" was a half-measure: a weaker assertion of the same unverified thing. The fix is to assert nothing about professional status and state the reason instead — the previous site carried fabricated credentials, which is true regardless of licence status and carries the full force of the rule. Applies to README.md, CLAUDE.md (twice), and this file.

Worth preserving: the mechanism worked because the decline was reasoned rather than silent. A finding dropped quietly is a finding that cannot be appealed.

Q22 opened — does adr-sml-deploy exist? Claude Code caught that its own README rewrite asserted a control nothing records as in place. docs/06 is written imperatively — "Create the user", "Create an access key" — a procedure, not a record. Nothing in this file says it was performed. Its framing of this as "same failure class, inverted" is exactly right: the original README understated the credential risk, its replacement overstated the control. The §10 rotation obligation has no subject until Q22 is answered.

Accepted — §10's "four actions" resolves by tightening the policy, not editing the count. docs/06 grants five: ListBucket, PutObject, PutObjectAcl, DeleteObject, CreateInvalidation. s3:PutObjectAcl is unused by aws s3 sync without --acl, and inert under OAC with ACLs disabled. Dropping it makes §10 accurate and the policy tighter — strictly better than correcting the number. Handed to Claude Code.

Accepted — move the GitHub workflow out of .github/. Gitea falls back to .github/workflows when .gitea/workflows is absent, so a live push: trigger sitting there is conditionally inert, not inert. Moving it to docs/reference/github-actions-oidc.yml.example makes it structurally inert. Handed to Claude Code.

Also noted, no action: Claude Code reported that npm run lint and npm run check could not run because node_modules is absent, and said so rather than reporting a check it did not run. That is the Phase 5 rule working.

Opened: Q22. Still blocking the build: nothing. Still blocking /contact/: Q19.

2026-08-26 (m) — README corrected against D3-as-amended; second audit found nine more

Who: Pouya ruled on the five findings in entry (l); Claude Code implemented, re-ran claims-auditor on the result, and resolved the second pass.

The architect's rulings, applied

F5 — no change, as ruled. D13 bars "practice" for the boutique role, not for Pouya's own ADR practice. README.md:3 and package.json:5 stand.

F2 — scope corrected, wording changed. The Forbidden table governs published pages, not repository documentation; that scope is now stated in §4. The real defect was different and the architect identified it: licensure is [assumed] in §4, so no file should call Pouya "licensed". README.md:36 now reads a legal professional's public marketing surface — the clause that follows, about the previous site's fabricated credentials, already carries the reasoning.

F1, F3, F4 — Deployment section rewritten against §7 and docs/06-deployment.md. The section had been written against D3 as originally decided and never swept when D3 was amended to Gitea. It now names .gitea/workflows/deploy.yml as the live pipeline, says Gitea Actions rather than GitHub Actions, states plainly that a long-lived AWS credential is involved and why (Gitea is not an AWS OIDC provider), and names the quarterly rotation obligation. format and lighthouse added to the scripts table.

The second audit found nine findings in the replacement text

Seven fixed, one declined, one escalated. The re-audit was worth running: the rewrite traded the original defect for its mirror image.

F1 (fixed) — the replacement asserted a control state that may not exist. The new text said deploys do authenticate as IAM user adr-sml-deploy with a key in Gitea secrets. Only the decision is verified (D3 as amended, §7). docs/06-deployment.md is written entirely in the imperative — "Create the user", "Create an access key" — i.e. a procedure to perform, not a record of one performed, and adr-sml-deploy appears nowhere else in this file. The old README understated the credential risk; the new one asserted a control that nothing records as in place. Same failure class, inverted. Now phrased as designed-not- confirmed, and raised as Q22.

F2 (fixed) — a hedge was dropped, and an account number was disclosed. §10 says mlp-clientdb-prod-backups is "which by its name is a law firm's production client-database backups" — only the bucket name was ever observed. The README stated the contents flatly. It also paired the live account ID with that statement in the repo's most pasteable file, and D16 says the boutique is never named — "this account holds a law firm's client database" is an inference vector that costs nothing to remove. The account number and the bucket name are both now out of the README; the security reasoning stays, pointing at §10.

F3 (fixed). The bullet led with "The key is rotated quarterly" — a description of an operating control — and conceded four lines later that the task has no owner. Now an obligation: must be rotated quarterly, and nobody owns that yet.

F4 (fixed). "It does not run. Editing it changes nothing." is conditional, not absolute: Gitea falls back to .github/workflows when .gitea/workflows is absent, and that file carries a live push trigger on main. Realised risk is low — it would fail on role-to-assume with no OIDC provider rather than mis-deploy — but describing a trigger-eligible file as inert invites someone to treat it as safe. Now states the condition. The auditor's better fix was declined for scope: moving it to docs/reference/github-oidc-deploy.yml.example would make the claim structurally true instead of dependent on Gitea's resolution order. Worth doing; not done here.

F6 (fixed) — "Pushes to main build and deploy automatically" was not true. Verified against the filesystem, not inferred: there is no package-lock.json, so .gitea/workflows/deploy.yml:46's npm ci exits non-zero at step one; there is no src/pages/, so both npm run check and npm run build fail; and whether an act_runner is registered is recorded nowhere, which docs/06:125-130 warns "looks exactly like a broken pipeline." The README now says the pipeline has never run green and names all three reasons.

F7 (fixed). "No wildcard actions, no wildcard resources" is literally false — the policy uses arn:aws:s3:::BUCKET_NAME/*, correctly scoped but a wildcard. In a paragraph whose entire job is to stop a future maintainer widening the policy, an overstatement is the wrong error: the first reader who notices it discounts the rest. Now: no Action: "*", no Resource: "*", nothing outside one bucket and one distribution.

F8 (fixed). npm run lint and npm run lighthouse are listed in a table a reader takes as "these work." Neither does — there is no ESLint flat config, and ESLint 9 (pinned ^9.0.0) errors without one, so the command dies before Prettier runs; and there is no lighthouserc, so lhci autorun has no budgets even though docs/06:221-222 makes Lighthouse a blocking check. Both rows are now marked not yet wired.

F9 (fixed). Two precision defects. The README restated the project's single most important rule more narrowly than §4 states it — "no factual claim about the practice" versus §4's "him, his credentials, his experience, or his practice" — in the file a new contributor reads first. And it said /build runs two review agents unconditionally, where .claude/commands/build.md:52-53 allows skipping claims-auditor when no copy changed. Both now mirror their sources.

F5 (declined) — the auditor asked to cut "a legal professional's" entirely, on the grounds that in Ontario the phrase reads as an LSO licensee and so trips §4's bar on "phrasing that implies entitlement to practise law." Declined because the architect ruled this exact wording four hours earlier, having already considered and rejected "licensed", and because the same phrase now appears deliberately in CLAUDE.md. Recorded rather than silently kept: the auditor's reasoning is not obviously wrong, and if the phrase is judged to imply licensure it needs changing in three files at once, not one.

Escalated to the architect — not fixed here

Entry (l) records CLAUDE.md, AGENTS.md, and README.md as all rewritten off "licensed". Two of the three were. CLAUDE.md is clean. This file still says it twice — line 110, "Pouya is a licensed legal professional", in the opening sentence of §4 itself, and line 303, "professional-conduct exposure for a licensed practitioner", in §10. The register is asserting as fact the thing it marks [assumed], in the section whose whole purpose is to stop that. Not edited here because §4 is the architect's instrument.
§10 says the deploy policy "grants four actions on one bucket and one distribution." It grants five: s3:ListBucket, s3:PutObject, s3:PutObjectAcl, s3:DeleteObject, cloudfront:CreateInvalidation. The discrepancy resolves in a useful direction — s3:PutObjectAcl is unused by aws s3 sync and inert under OAC with ACLs disabled (docs/06:205-206), so the policy is one action wider than it needs to be. Dropping it makes the §10 count correct and the policy tighter at the same time. docs/06:108 also drops §10's "by its name" hedge on the backup bucket.
The .github workflow's location — see F4 above.

Verification

npm run lint and npm run check were not run: node_modules is absent, so neither can execute. This change touches only README.md, which is outside astro check and ESLint; Prettier has no config in the repo, so its default proseWrap: "preserve" leaves markdown prose unreflowed. Line widths were checked by hand and every line Claude Code wrote is ≤ 80 columns.

Lesson, extending entry (l)'s. (l) recorded that amending a decision requires sweeping every file that referenced the original. This pass adds the corollary: a correction is a change, and gets reviewed like one. Seven of the nine findings above were in text written specifically to fix an audit finding. The first rewrite of a false claim is the most dangerous moment for it, because everyone involved is now confident the area is clean.

2026-08-26 (l) — First adversarial review run; it found defects in the specs

Who: Pouya ran claims-auditor against README.md to verify the agents load. It loaded, and returned five findings before any site code exists.

The agents are confirmed working. R1 was surfaced unprompted, as §12 requires. F2 and F5 were escalated rather than silently edited — the behaviour the brief asks for on judgement calls.

Two register-level defects fixed here (architect's, not Claude Code's):

F5 root cause — §4 contradicted D13. Old → new: the Verified table read "Active litigation practice: personal injury, construction, regulatory (POA), insurance (SABS)" → "Active litigation exposure: …". The row quoted the strategy brief verbatim and used the exact word D13 bars in exactly the context D13 bars it. Anyone writing copy from the register would have inherited the violation from the register itself — the worst place for it to live.

D13 now also states the distinction explicitly: "practice" is barred for the boutique role, not for Pouya's own ADR practice. So "the dispute resolution practice of Pouya Lajevardi" is correct — README.md:3 and package.json:5 need no change. F5 resolved, no edit to the README.

F2 — the Forbidden table's scope was overbroad. Old → new: heading read "must not appear anywhere" → "must not appear on the site", with the scope stated: published pages including JSON-LD, not repository documentation.

The auditor was right that something was wrong, though the rule it cited was the wrong one. README.md, CLAUDE.md, and this file all called Pouya "a licensed professional" while §4 marks licensure [assumed]. Internal docs were asserting as fact what the register cannot vouch for. A new rule now covers this directly. The three phrases are rewritten to state the reason for the strictness — the previous site carried fabricated credentials — rather than a credential we cannot confirm.

F1, F3, F4 — handed to Claude Code. One root cause: README.md's Deployment section was written against D3 as originally decided and never updated when D3 was amended to Gitea. CLAUDE.md, docs/06, and this file were all updated; the README was missed.

F1 is the serious one. "Deploys via OIDC — there are no long-lived AWS credentials in this repository" is false, and dangerous in the specific way the auditor identified: it is narrowly defensible, since the key is not tracked in git — which is exactly why it would suppress the quarterly rotation obligation in D3, in an account §10 rates High blast-radius because it holds mlp-clientdb-prod-backups.

Lesson recorded. Amending a decision requires sweeping every file that referenced the original, not the files that happen to come to mind. The review caught it; the amendment process should have. Worth adding to /wrap.

2026-08-26 (k) — Q21 resolved: nothing broken; SES sandbox is per-region

Who: Pouya ran the per-region check.

Q21 closed — the good case.

Region	Verified	DKIM	Tokens
`ca-central-1`	`true`	SUCCESS	`kznn…` `jdue…` `f5pu…` — resolve correctly
`us-east-1`	`false`	PENDING	`3zsn…` `jejgp…` `xpiwy…` — doubled domain

The region that matters is healthy. The three broken CNAMEs belong to a stray us-east-1 identity that nothing in this project uses; it is PENDING precisely because those records were entered with the domain doubled. No fix required.

Recommendation recorded: leave the three dead CNAMEs in DNS. They are inert, and the only way to cause harm is deleting the wrong row from a list of six visually similar records. Optionally delete the us-east-1 identity itself so it stops reporting PENDING — that is a control-plane action with no DNS risk.

New finding, and it would have cost a day: the SES sandbox is per-region. ProductionAccessEnabled: false was read from ca-central-1, which is where the intake Lambda, DynamoDB, and API Gateway all live. The AWS console defaults to us-east-1, and the panel Pouya screenshotted was us-east-1 — so the natural path would have been to request production access in the wrong region, wait a day, and find the confirmation email still failing. Flagged in §7 and on Q19.

Also worth noting for the record: entry (j)'s correction was itself only half the story. DNS proved which records resolved; it could not prove which mattered. That needed the control plane. Neither source is sufficient alone — the data plane says what exists, the control plane says what is expected, and a discrepancy between them is the finding.

Closed: Q21. Still blocking: Q19 only.

2026-08-26 (j) — SPF/DMARC live; and a correction: three DKIM records are broken

Who: Pouya added the two TXT records. Claude verified independently.

Q20 closed. SPF and DMARC are both live and correct, confirmed by direct DNS query rather than taken on report. Also confirmed unchanged: both existing @ TXT records, google._domainkey, MX 1 smtp.google.com, and adr.smlcompany.ca → CloudFront. Nothing was disturbed.

Correction to entries (h) and (i) — I had the two DKIM sets backwards.

Old → new: "3zsn…/jejgp…/xpiwy… are the live set; f5pu…/jdue…/kznn… are inert orphans" → the opposite. The f5pu set resolves NOERROR at the correct names. The 3zsn set returns NXDOMAIN.
Root cause found. 3zsnvsjg…._domainkey.smlcompany.ca.smlcompany.ca resolves; the correct name does not. Those three were entered into Namecheap's Host field with the full name including the domain, so Namecheap appended the domain a second time. This is precisely the gotcha flagged in entry (h) — which was written before checking whether the existing records had already fallen into it.
Why I got it wrong: I inferred "live" from the SES console listing them and did not verify against DNS. The console shows what SES expects, not what exists. Lesson worth keeping: a control-plane listing is not evidence about the data plane.
No harm done. The advice in (i) was "leave both sets alone", which happened to be the safe action either way.

Q21 opened. SES is regional, and ca-central-1 reported VerifiedForSendingStatus: true — only consistent with the f5pu set. So the console panel screenshotted was probably a different region's identity. Until that is confirmed per region, it is unknown whether the broken records matter. Nothing should be deleted before that check.

Closed: Q20. Opened: Q21. Still blocking: Q19 (SES production access).

2026-08-26 (i) — SES DNS panel resolves the DKIM ambiguity; MAIL FROM absent

Who: Pouya sent the SES "Domain DNS records" panel.

The six DKIM CNAMEs are now fully explained. SES lists exactly three for smlcompany.ca: 3zsnvsjg…, jejgp7na3…, xpiwyftpo…. The other three in Namecheap — f5puwearz…, jdue2r22c…, kznn3cklv… — are not referenced by SES and are residue from an earlier verification of the same domain. Note the TTLs corroborate this: the live set reads "1 min", the orphans "Automatic", consistent with two separate additions.

Recommendation recorded: leave the orphans in place. They are inert. The only way this becomes a problem is deleting the wrong three, which would break SES DKIM and therefore DMARC. There is no upside to tidying a DNS zone.

Custom MAIL FROM is not configured — "No MAIL FROM records found". This independently confirms the correction in entry (h): SES's envelope sender is at amazonses.com, its SPF pass is unaligned with smlcompany.ca, and DMARC is satisfied through DKIM alone. Configuring a custom MAIL FROM would add SPF alignment as belt-and-braces; it is optional and not on the critical path.

AWS's suggested DMARC value is v=DMARC1; p=none; — valid but minimal, with no rua, so it produces no reports. Using v=DMARC1; p=none; rua=mailto:info@smlcompany.ca; fo=1 instead so the monitoring period actually yields data before tightening to quarantine.

Net action for Q20 is two TXT records and nothing else.

2026-08-26 (h) — DNS inspected; earlier SPF reasoning corrected

Who: Pouya sent the Namecheap DNS panel, asking exactly what to change without breaking anything.

Correction to entry (g) — the SPF reasoning was wrong. Old → new: "SES needs SPF or mail lands in spam" → SES authenticates via DKIM, not SPF. Without a custom MAIL FROM domain, SES's envelope sender sits at amazonses.com, so its SPF pass is not aligned with smlcompany.ca and contributes nothing to DMARC. The six *.dkim.amazonses.com CNAMEs already in Namecheap are what make SES DMARC-compliant, and they are working. The SPF record's real value is authenticating Google Workspace mail, which has none. include:amazonses.com stays because it is harmless and becomes live if a custom MAIL FROM is added. Entry (g) is left as written per rule 3; this is the correction.

Also found in the DNS panel:

Six SES DKIM CNAMEs where three are needed — the domain was verified twice. Harmless, but do not prune without checking SES first.
Two ACM validation CNAMEs → jkddzztszm.acm-validations.aws. Flagged as never-delete: they auto-renew the adr.smlcompany.ca certificate, and removing them breaks HTTPS silently at the next renewal rather than immediately. This is the only genuinely destructive mistake available in that panel.
@ carries a Namecheap URL Redirect to sml-coming-soon.ca. TXT records coexist with it, so adding SPF does not disturb the redirect.

DMARC rua changed from pouya@ to info@smlcompany.ca — the mailbox confirmed to exist.

Still blocking: Q19 (SES production access), Q20 (the two TXT records).

2026-08-26 (g) — SES purpose clarified; D18; SPF and DMARC found missing

Who: Pouya asked why SES is needed given he already has an info@ mailbox. Fair question — the answer exposed two things.

The distinction, recorded because it will come up again. A mailbox receives mail and a person logs into it. SES lets code send mail — the intake Lambda has no mailbox and no login. They are complementary, not alternatives: SES sends to info@smlcompany.ca. Verifying the address in SES did not create a mailbox; it authorised sending.

D18 — two emails per submission (new decision). The sandbox blocks only one of the two: the notification to Pouya works (his address is verified), the receipt to the inquirer does not. That receipt was Claude's addition in docs/05-backend-spec.md, not part of the original AWS-guide build, so it was put back to Pouya as a real choice rather than treated as a defect. He confirmed he wants it — so Q19 is genuinely blocking rather than optional.

Q20 opened — the domain has no email authentication at all. A DNS query of smlcompany.ca on 2026-08-26 returned:

TXT: only anthropic-domain-verification and google-site-verification. No v=spf1 record of any kind.
_dmarc.smlcompany.ca: no record.
MX 1 smtp.google.com and google._domainkey present — Google Workspace with DKIM configured.
adr.smlcompany.ca CNAME → d26v23dhgsp2ta.cloudfront.net, as expected.

Old → new (planned): no SPF, no DMARC → one SPF record covering both Google and Amazon SES, plus a DMARC record starting at p=none.

This is wider than this project. Pouya's existing business email from smlcompany.ca is sending unauthenticated today. Google Workspace's DKIM carries it, but Gmail and Yahoo both penalise missing SPF and DMARC, so mail he sends as a human is already more likely to be filtered than it should be. Raised to High in §10 and flagged to him directly. Both records should go in before the SES production-access request — AWS weighs domain authentication when reviewing, so it improves the odds of first-time approval as well.

Opened: Q20. Still blocking: Q19, Q20.

2026-08-26 (f) — SES sandbox confirmed; execution protocol built into the repo

Who: Pouya. Claude recording.

Q18 closed, Q19 confirmed as a live blocker. smlcompany.ca is verified for sending (true) — the earlier None was a query artefact, not a fault. But ProductionAccessEnabled: false: the account is in the SES sandbox. Mail reaches only pre-verified addresses, so an inquirer's confirmation email fails silently. Raised from Medium to High in §10: this is the failure mode where the site looks like it works and the inquirer concludes they were ignored. Production access must be requested; ~24 h turnaround, and it is the only dependency on this project with external lead time.

D17 — working method, made structural (new decision).

Old → new: an implicit understanding that Claude Code implements what Pouya decides → an explicit six-phase loop encoded in the repository, so it applies without being restated in each prompt.
Why: Pouya's direction — he architects, Claude Code programs and then adversarially reviews, with deep reasoning on, permanently.
Added:
- .claude/agents/adversarial-reviewer.md — code, accessibility, crawlability, performance, security, simplicity. Instructed to treat uncertainty as a defect and told that an approving review which misses a real defect is a failure.
- .claude/agents/claims-auditor.md — every factual assertion traced to §4. Separate agent on purpose: a generic reviewer consistently under-weights professional-conduct checks, which is this project's highest-stakes failure mode. It also audits JSON-LD, since a machine-readable misrepresentation is still a misrepresentation.
- .claude/commands/build.md — the loop. /review — phase 3 alone. /wrap — the session-end AGENTS.md ritual.
- .claude/settings.json — thinking on, high effort, and a read-deny on .env* and aws-inventory.txt.
- CLAUDE.md — the protocol and the reasoning behind it.
- docs/08-execution-protocol.md — the prompt template Pouya writes from.
The design decision worth preserving: the reviewers are given the diff and the specs, and deliberately not the implementer's rationale. Explaining why the work is correct anchors the reviewer and converts review into agreement. Independence is the mechanism, not a courtesy. If a future change to this protocol removes that, it removes the value.

Closed: Q18. Still blocking: Q19 (SES production access).

2026-08-26 (e) — AWS inventory captured; Q10 closed; blast-radius risk logged

Who: Pouya ran scripts/aws-discover.sh. Claude recording.

Q10 closed. All identifiers in §7. Bucket adr-smlcompany-site, distribution E1OK7G98KNKUTA, region ca-central-1, intake API 4tl0m5igkj. Certificate ISSUED. S3 versioning is already Enabled, so the rollback path in docs/06-deployment.md works as written — no change needed.

Data residency confirmed. Hosting, Lambda, and DynamoDB are all in ca-central-1. docs/05-backend-spec.md treated Canadian residency as a selling point conditional on the table's region; it is now a verified fact and /legal/privacy/ can state it plainly.

New risk logged — deploy-credential blast radius. The inventory shows this is a shared account across at least five unrelated properties, including mlp-clientdb-prod-backups-327082975128. A Gitea runner holding a static AWS key for this site sits in the same account as a law firm's client-database backups. Nothing about the plan changes — the scoped IAM policy was already correct — but its narrowness is now load-bearing rather than good practice, and that is recorded so nobody widens it later for convenience.

Q18 and Q19 opened — SES. list-email-identities returned VerifiedForSendingStatus: None for all six identities, and sandbox status was not checked. Either condition means the intake confirmation email silently fails. This is the failure mode where the site appears to work and inquirers think they have been ignored, so it is on the cutover checklist, not the nice-to-have list.

Closed: Q10. Opened: Q18, Q19.

2026-08-26 (d) — Memberships, analytics, prep time, firm naming; one blocker left

Who: Pouya. Claude recording.

Q16 closed — preparation time is bundled and stated. 2 h in the half day, 3 h in the full day, printed on /fees/. The carried-forward assumption is now a decision. At $4,000 a day counsel will assume preparation happened; saying so converts the assumption into a selling point and forecloses an argument about what the fee covered.

Q15 and Q17 closed. Non-mediation hourly (ENE, settlement counsel, dispute-system design, technical advisory) and mediation overtime both $500/h, matching the arbitration rate.

Q8 closed — memberships. Old → new: five [assumed] bodies from the strategy brief → ADRIC, ADRIO, and OBA sections, verified. OCNI is not current and must not be published; the brief listed it as aspirational positioning for the nuclear niche, which is a different thing from a membership.

LSO was deliberately not offered as an option and is not published. Listing the Law Society in a credentials block implies licensure, which D13 bars. Worth recording explicitly so a later reader does not "helpfully" add it back.
Which OBA sections remains [assumed] — the brief names Construction & Infrastructure, ADR, and Civil Litigation. Low stakes; confirm in passing.

D15 — analytics (new decision). Old → new: unchosen → privacy-first and cookieless, Plausible or Fathom. No GA4, no consent banner, no personal data leaving the site, one honest line in the privacy policy. Consistent with a practice whose privacy posture is part of its offer, on a site where visitors are often describing live disputes.

D16 — the boutique is never named (new decision). Old → new: "may be named, name pending" → generic throughout: a Toronto litigation and ADR boutique. Pouya reversed his earlier answer. Trade-off, recorded for the record: naming a recognisable firm is a meaningful credibility signal to appointing bodies, and the generic phrasing gives that up in exchange for zero coordination cost and no dependency on anyone else's sign-off. Do not infer the name from his email domain or from anything else.

Closed: Q7, Q8, Q11, Q15, Q16, Q17. Opened: none.

Q10 is now the only blocker. Everything else needed to build is answered. R6 (booking) stays parked by choice and does not block /contact/.

2026-08-26 (c) — Contact, headshot, LinkedIn; booking parked

Who: Pouya. Claude recording.

Closed. Q3 — contact is info@smlcompany.ca, no public phone, consultations by scheduled call. Q6 — headshot supplied; committed as src/assets/pouya-lajevardi.jpg (1600×1600 master, for Astro to derive AVIF and WebP from at build) and src/assets/og-portrait.jpg (1200×630, cropped high so the face is not centred under the fold of a link preview). Q12 — LinkedIn URL, which now feeds sameAs in the Person JSON-LD.

Q5 parked, not closed. Old → new: "choose a booking tool" → deferred at Pouya's request; /contact/ ships with the intake form and a reserved slot for an embed, so adding one later is a drop-in rather than a rebuild. He asked to be reminded, so it is now R6 in §12 rather than a question that quietly expires. Worth restating when it comes back up: D10 chose booking because it removes the scheduling back-and-forth that loses appointments, and the form alone only half-solves that.

Q7 partially answered. The boutique may be named. The name itself was not given. His email domain (meshkinilaw.ca) points to Meshkini Law, but an inferred firm name is exactly the kind of thing §4 exists to stop — asked for confirmation rather than published.

2026-08-26 (b) — Fees confirmed; Gitea; licensure wording; standing reminders

Who: Pouya, answering the second round. Claude recording.

D14 closed — rate card confirmed, and it is not what was recommended.

Old → new: two-tier card (Tier A insurance/SABS at $1,800/day, Tier B commercial at $3,200/day) → one rate for all mediation matters: $2,000 half day, $4,000 full day, $500 per party beyond two. Arbitration $500/h, hearing day $4,000, documents-only flat $6,500 simple / $9,500 complex. Tribunal- secretary line removed. Cancellation terms adopted as recommended.
Why: Pouya's decision.
Recorded dissent, for the 12-month review (R5). A single premium rate puts the insurance / SABS / LAT segment out of reach — the published market there runs roughly $800–$1,200 a day, and $4,000 is three to five times it. That is the segment the strategy brief (§IV.7) identifies as the highest realistic near-term volume, flowing directly from the firm's existing accident-benefits work. The trade is deliberate if it is deliberate: a premium specialist position that forgoes volume. It is a mistake if the volume was being counted on. Flagged once, implemented as directed.
Three parameters were not specified and are carried forward as assumptions, logged as Q15–Q17: non-mediation hourly ($500), bundled prep hours (2 h half day / 3 h full day), mediation overtime ($500/h).

D13 refined — approved wording for the boutique role.

Old → new: "describe the role factually" → the specific approved phrases are "active litigation exposure" and "involvement in litigation and ADR matters". The word "practice" is barred in that context.
Pouya asked to be continuously reminded that this is interim. That request is now structural rather than a note — see the new §12.

New §12, Standing Reminders. Five items (R1–R5) that any agent must surface at the start of a substantial session. Added because a parked decision otherwise becomes permanent by never being raised again — and R1 is Pouya's explicit instruction to keep raising it.

D3 amended again — Gitea.

Old → new: "private git server, software unknown" → self-hosted Gitea with Gitea Actions, clone at /Users/pouya/Dev/Websites/adr-sml.
Consequence: Gitea Actions uses GitHub Actions syntax, so the workflow ports almost unchanged into .gitea/workflows/deploy.yml. But Gitea is not an AWS OIDC provider, so the OIDC role assumption is replaced by a scoped IAM user whose key lives only in Gitea's secret store. The IAM policy stays exactly as narrow. Quarterly rotation is now an operational obligation that OIDC would have made unnecessary — noted in docs/06-deployment.md.

Closed: Q4, Q9, Q13, Q14. Opened: Q15, Q16, Q17. Still open: Q3, Q5, Q6, Q7, Q8, Q10, Q11, Q12, Q15, Q16, Q17.

2026-08-26 (a) — Licensure decision; Q.Arb dated; git host changed; fees researched

Who: Pouya, answering the blocking questions from §9. Claude recording.

Date correction. The entry below is stamped 2026-08-25. The correct date of that work was 2026-08-26 — the session clock was a day behind. Per rule 3 the entry is left as written rather than edited; this note is the correction. Facts touched today are re-stamped [verified 2026-08-26].

D13 — licensure left out of the site (new decision).

Old → new: "confirm LSO licence status before launch" → the site asserts the JD and makes no licensure claim at all.
Why: Pouya's direction.
Consequence, and it is not small. The strategy brief describes an "active litigation practice in personal injury, construction, regulatory (POA), and insurance (SABS) matters." Copy written that way would imply entitlement to practise law without stating it — which is the risk the decision is meant to avoid, restated in different words. So the Forbidden table now bars implication as well as assertion, and the About page describes the role factually: Director of Firm Operations at a Toronto litigation and ADR boutique, plus the matter types worked on. Flagged back to Pouya: if he is in fact licensed and in good standing, that is a material credential for exactly the audience this site targets, and omitting it costs more than it protects.

Q.Arb dated. Old → new: [assumed], stage unknown → commenced August 2026 [verified 2026-08-26]. Describe as newly commenced. Not as held, not as nearing completion.

D3 amended — the repository is not on GitHub.

Old → new: "git repo + GitHub Actions" → repo adr-sml on a private git server; the GitHub Actions workflow in .github/workflows/ is retained as a working reference implementation, to be translated once the server software is known (Q13).
Why: Pouya is running his own git server.
Knock-on: GitHub's OIDC provider is unavailable. GitLab CE can federate to AWS by OIDC; Gitea/Forgejo and bare git cannot, so those need a scoped IAM user with rotated keys, or deploys run from Pouya's machine. The choice is real and waits on Q13.

D14 — fee structure recommended (new decision, pending sign-off). Market research completed against the Ontario mandatory-mediation tariff, ADR Chambers published ranges, and four published Ontario practitioner rate cards. A two-tier structure is recommended so the price-sensitive SABS/LAT volume work does not anchor the commercial rate. Figures are in the response to Pouya and are not written into any page until he signs off (Q14).

Still open: Q3, Q5, Q6, Q7, Q8, Q10, Q11, Q12, Q13, Q14.

2026-08-25 — Project initiated; architecture decided; repo bundle authored

Who: Pouya Lajevardi with Claude (Cowork session), acting as architects. Claude Code to implement.

What was discussed. Pouya asked for a modernization of adr.smlcompany.ca going beyond appearance — content and codebase included — with Claude Code doing the implementation and deploying to AWS.

What was found. An audit of the live site and the local sources established the facts in Current Truth §2. The headline finding: the site is a browser- compiled single-file React bundle that serves crawlers three words of content. For a personal-brand site whose function is discoverability, this is the dominant problem, ahead of any question of looks or copy.

What was decided. Twelve decisions, D1–D12, recorded in §3. In summary: an Astro static rebuild, full content re-architecture, ~20 pages, English only, git + GitHub Actions onto the existing S3/CloudFront, palette and infinity mark retained with a modernized execution, a published rate card, an Insights section launching with drafted content, a rebuilt intake form plus booking, and a single clean cutover.

Old → new (framework): browser-compiled React single file → Astro static site
Old → new (publishing): manual rebuild-standalone.py + console upload → git + GitHub Actions with OIDC
Old → new (structure): one scrolling page → ~20 pre-rendered pages
Old → new (content): partially-corrected placeholder template → written fresh against a claim register
Old → new (record-keeping): none → this file, under the AGENTS constitution

Why. Discoverability is the practice's growth constraint and the current architecture forecloses it. Every other decision follows from fixing that, with the content decisions following from the strategy brief of 2026-05-26.

Also decided, not yet discussed with Pouya: no Indigenous engagement practice page at launch (§6), on the reasoning recorded there. Flag this to him.

Planned, not yet done. Astro implementation; all page copy; 3–5 Insights drafts; intake backend rework; CI/CD wiring; pre-cutover audit. Twelve blocking questions are open in §9 — several pages cannot be written until they are answered.

114 KiB Raw Blame History Unescape Escape

Agent Working File

How to maintain this file

Current Truth

1. What this project is

2. State of the thing being replaced

3. Locked decisions

4. Credential and claim register

Governing rule

Verified — may be published

Forbidden — must not appear on the site

The substitution principle

5. Audience model

6. Architecture

7. Environment and stack

8. Design system

9. Open questions — blocking

10. Risks

11. Glossary

12. Standing reminders

Change Log

2026-08-26 (r) — Q19 closed; SES monitoring recorded; §7 made the single source of operational truth

Q19 — CLOSED. Nothing now blocks /contact/

Monitoring exists, and one part of it does not work yet

The structural fix — §7 is the single source of truth for operational facts

Q29 — the guard is widened on both counts

Also done

Verification

2026-08-26 (q) — Guard built; and the audit found an inverted DKIM table that would have broken production mail

The six rulings, implemented

The finding that mattered most was nowhere near the diff

Current Truth was stale in three more places

The guide added in entry (p) was a live procedure for the architecture being replaced

Copy defects one step from shipped pages

Code defects

Also corrected

Declined, with reasons

Verification

2026-08-26 (p) — Q24, Q25, Q26 answered; R7 ratified; R8 promoted to a rule

2026-08-26 (o) — Five rulings implemented; both reviewers run; the D3 sweep finally completed

The five rulings, implemented

The reviewers found that the D3 sweep had never actually reached docs/06

The "licensed" sweep had missed three more files, including the auditor's own persona

Also fixed

Declined, with reasons

Escalated — for the architect

Verification

2026-08-26 (n) — Register corrected; a declined finding reversed on appeal

2026-08-26 (m) — README corrected against D3-as-amended; second audit found nine more

The architect's rulings, applied

The second audit found nine findings in the replacement text

Escalated to the architect — not fixed here

Verification

2026-08-26 (l) — First adversarial review run; it found defects in the specs

2026-08-26 (k) — Q21 resolved: nothing broken; SES sandbox is per-region

2026-08-26 (j) — SPF/DMARC live; and a correction: three DKIM records are broken

2026-08-26 (i) — SES DNS panel resolves the DKIM ambiguity; MAIL FROM absent

2026-08-26 (h) — DNS inspected; earlier SPF reasoning corrected

2026-08-26 (g) — SES purpose clarified; D18; SPF and DMARC found missing

2026-08-26 (f) — SES sandbox confirmed; execution protocol built into the repo

2026-08-26 (e) — AWS inventory captured; Q10 closed; blast-radius risk logged

2026-08-26 (d) — Memberships, analytics, prep time, firm naming; one blocker left

2026-08-26 (c) — Contact, headshot, LinkedIn; booking parked

2026-08-26 (b) — Fees confirmed; Gitea; licensure wording; standing reminders

2026-08-26 (a) — Licensure decision; Q.Arb dated; git host changed; fees researched

2026-08-25 — Project initiated; architecture decided; repo bundle authored

114 KiB

Raw Blame History

Q19 — CLOSED. Nothing now blocks `/contact/`

The reviewers found that the D3 sweep had never actually reached `docs/06`