diff --git a/AGENTS.md b/AGENTS.md index ac42509..727d35d 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -182,6 +182,8 @@ since May. | 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]` | +| **SML Company Ltd operates the practice and holds its systems** | `[verified 2026-09-02 — Pouya]`. **This row exists because a public page now names the corporation as the party that stores personal information.** The `/contact/` consent checkbox reads *"I consent to **SML Company Ltd** storing and using the information in this form…"* — his ruling of 2026-09-02, replacing *"Pouya Lajevardi"*. It is the one sentence a submitter actually agrees to and it is the PIPEDA basis, so the party named in it is a §4 claim and not a styling choice. ⚠️ **THE SHIPPED CONSENT SENTENCE IS NARROWER THAN THIS ROW'S HEADING, DELIBERATELY**: it asserts only that the corporation stores and uses what the form collects. ⚠️ **BUT TWO PAGES DO DESCRIBE THE RELATION, AND BOTH SAY *ALONGSIDE*, WHICH IS THE ROW ABOVE AND NOT THIS ONE.** `/about/`: *"I run SML Company Ltd alongside the practice."* `/practice/shareholder/`: *"SML Company Ltd. operates alongside the practice"* — **with a terminal period, which the incorporation row's own convention bars; pre-existing, not introduced here, and worth one character at the read-through.** A third surface states the narrow half only: `/legal/privacy/` §Why it is collected names *"SML Company Ltd, the company that holds this practice's systems"*, so a submitter can find the party the consent box names. **Nothing published says the corporation operates the practice, and nothing should until the *alongside*/*through* conflict above is settled** (`adversarial-reviewer`, round 2). ⚠️ **AND THE ROW ABOVE SAYS *alongside*, WHICH IS NOT WHAT THIS ATTESTATION SAYS.** Q49(b) was **declined** in 2026-08-28 on exactly that gap — the ruling then said *operates through*, §4 rowed *alongside*, and `worksFor` was kept out of the JSON-LD for it. This attestation is the *through* direction and it is Pouya's own words. **It is recorded rather than merged, and Q49(b) is NOT reopened by it**: nothing published turns on the relation, and reconciling two rows to unlock a graph field is the kind of tidying that put a struck permission back in this table (see the D16 precedent). **Name only, no terminal period, and never beside the licence-status row** — the incorporation row below carries that caution and it applies here unchanged | +| **A small number of people administer this practice's systems alongside Pouya** | `[verified 2026-09-02 — Pouya]`. His attestation, given twice on the day: *"two people is an exaggeration… a handful is accurate"*, and the ruling's own wording *"the small number of people who administer its systems with me"*. **`/legal/privacy/` §Who can see it's FIRST SENTENCE rests on this row for its human quantifier, and on §7's enumeration for the set it quantifies — they are two supports, not one.** The section's other three sentences rest elsewhere: §7's `info@smlcompany.ca` row, §7's Lambda-role measurement, and the handler's second `SendEmailCommand`. `docs/reference/intake-table-access-verification.md` maps all four, sentence by sentence. ⚠️ **IT IS AN ATTESTATION ABOUT PEOPLE, AND §7's ENUMERATION IS A MEASUREMENT ABOUT IDENTITIES — THEY ARE NOT THE SAME CLAIM AND NEITHER IMPLIES THE OTHER.** A simulation cannot see how many humans reach a credential, so the identity count is a **lower bound** on people; §9 Q63 exists because the page published one as the other. **No numeric human headcount ships.** ⚠️ **AND THIS ROW VERIFIES *administer the systems*, NOT *run the practice*.** The page said *"The people who run this practice can"* for one review round: nothing in §4 verifies that anyone else runs the practice, and on the natural reading it also swept in the administrative staff of the `info@smlcompany.ca` row — who read the mailbox and **cannot** read the intake table (§7). It now reads *"The record in the table: me, and the small number of people who administer the account it sits in with me"* — **scoped to the stored record**, because the section then names administrative staff who read the mailbox and cannot read the table, and **predicated on administering the ACCOUNT**, which is what §7 measures; *"this practice's systems"* was a third set, matching neither (`adversarial-reviewer`, round 2). **Do not widen the predicate back to running, founding, practising or acting** — that is the class of claim the fabricated founder on the old site belongs to, and it is what this register exists to stop. `adversarial-reviewer`, round 1, 2026-09-02 | | **SML Company Ltd — incorporated FEDERALLY, under the CBCA** | `[verified 2026-08-26 — Pouya, Q30]`. Two facts were being conflated and one of them was wrong: **jurisdiction of incorporation is federal (Canada)**; **place of business is Toronto, Ontario**. `src/data/site.ts` carried `'SML Company Ltd. · Ontario, Canada'`, which reads as a jurisdiction of incorporation and named the wrong one. **No corporation number** — none is held and the line does not need one. **Caution, and it is the point of this row:** "federally incorporated" says nothing about professional licensure, and nothing about where the practice may operate. It must not be read together with the **Licence status — NOT ESTABLISHED** row into an implication that neither row makes. **Not published:** on Pouya's direction the footer reads `© SML Company Ltd` and nothing further — the fact is verified and available, it is simply not on a page | | Memberships: **ADRIC**, **ADRIO**, **OBA — Construction & Infrastructure, ADR, and Civil Litigation sections**, and the **Canadian Tax Foundation** | **`[verified 2026-09-02 — Pouya]` — RE-CONFIRMED ON THE DAY OF CUTOVER, R10 FIRED AND SATISFIED.** Asked as a one-line question and answered 2026-09-02: **ADRIC, ADRIO, the three OBA sections and the CTF are all current.** The previous stamp was `[verified 2026-08-28 — Pouya]` and **it was not re-read to produce this one** — R10's whole content is that a stamp is not a renewal receipt. Both surfaces moved together: `CREDENTIALS.memberships` in `src/data/site.ts` (the visible list on `/about/`) and `memberOf` in `src/data/schema.ts`, which reads `MEMBERSHIP_ORGS`. **R10 does not close** — it fires on an event and events recur; the next fire is the next major republish. Original text follows. **RE-CONFIRMED, R10 DISCHARGED, AND NOW PUBLISHED ON `/about/`.** Q44 closed: *"All four are current as of today."* **Note on the stamp date, because it is a currency stamp and the date is the whole content:** Pouya's ruling said *"Stamp `[verified 2026-08-26 — Pouya]`"*, which is the date of the **original** confirmation. The stamp here reads **2026-08-28**, the date he actually re-confirmed — a stamp records when the assertion was made, and back-dating a re-confirmation by two days would understate the only thing the stamp is for. Flagged to him; one edit to change if he meant otherwise. **NO CURRENCY WARRANTY MAY BE PUBLISHED.** His words: *"List the memberships; promise nothing about their future state."* The struck sentence (*"Memberships are renewed annually and are listed as current"*) stays struck and nothing replaces it. **Renewal periods: the OBA sections and the CTF renew yearly. This record says NOTHING about ADRIC's or ADRIO's period** — an earlier form asserted "all four renew yearly" and that widened form propagated to four files. **He declined renewal-date tracking**, so R10 no longer fires on a date; it fires on an **event** — re-confirm before any cutover or major republish. **`memberOf` IS NOW EMITTED** on `/about/`'s Person node — Q53, ruled 2026-08-28; the withholding is dropped and this sentence said the opposite until the sweep that should have caught it was run. So the graph and the visible list assert the same four lines, and R10's event trigger covers both. `/`'s Person node omits it, because `/` shows no memberships. **CTF is a membership, not a practice area** — it is the one credential none of the six areas touch, and `docs/01-architecture.md` records why there is no seventh page at launch and when to revisit (R3) **Q51 CLOSED 2026-08-28 — the OBA sections STAY, and the distinction is structural.** Pouya: *"the Law Society is the regulator, so membership IS licensure; the OBA is a voluntary association."* That is why the `~~LSO~~` row below excludes one and this row publishes the other, and it holds **independently of eligibility details** — which is what made the question unanswerable inside this repo. Recorded so it is not re-litigated: a voluntary professional association admits members it does not license, so listing it carries no licensure implication; a regulator's membership roll *is* the licence. | | ~~OCNI~~ | **Not current. Do not publish** `[verified 2026-08-26 — Pouya]` | @@ -723,7 +725,7 @@ the audience it targets. Revisit at month 12–18. `[verified 2026-08-25 — dec | Intake API | `adr-intake-api`, HTTP API `4tl0m5igkj`, endpoint `https://4tl0m5igkj.execute-api.ca-central-1.amazonaws.com` `[verified 2026-08-26]`. **One route, `POST /submissions`** → integration `0ftgjgv` (`AWS_PROXY`, payload format **2.0**, which is the format `handler.mjs` reads). Stage `$default`, auto-deploy on, **no throttling**, no access log. CORS allows `POST` from the site origin `[verified 2026-09-01 — get-routes, get-api, get-stages, get-integrations]`. `DisableExecuteApiEndpoint` is **false** and must stay false: the CloudFront origin **is** that hostname. The form's route (`POST /api/intake`) does not exist yet — `docs/09` Part 6 | | Intake Lambda | `adr-intake-handler`, `nodejs24.x`, **arm64**, handler `index.handler`, timeout **10 s**, memory **128 MB**, role `adr-intake-lambda-role`, **no environment variables**, no DLQ, code **1,527 bytes**, last modified 2026-05-26 `[verified 2026-09-01 — get-function-configuration]`. **That is still the HAND-BUILT function, not `backend/intake/handler.mjs`** — nothing has been deployed (D11). Its resource policy has **one** statement, `apigateway.amazonaws.com` conditioned on `SourceArn` `…/4tl0m5igkj/*/*/submissions` — **the old route's path only**, so a new route needs its own permission or API Gateway is refused and answers 500 with nothing in the Lambda log. The execution role is **sufficient as it stands**: `dynamodb:PutItem` on the table (write-only — it cannot read it), `ses:SendEmail`/`SendRawEmail`, plus `AWSLambdaBasicExecutionRole`. Deployment commands: `docs/09-cutover-runbook.md` Part 5 | | Intake table | `adr-intake-submissions` (DynamoDB, ca-central-1) `[verified 2026-08-26]`. ⚠️ **KEY SCHEMA: PARTITION KEY `submissionId` (S), NO SORT KEY** ``[verified 2026-09-01 — `aws dynamodb describe-table`]``. **This contradicted `docs/05`, which specified `pk`/`sk`, and `backend/intake/handler.mjs` was written to the spec** — a `PutItem` missing the key attribute fails the whole write with `ValidationException`, the handler catches it and returns the failure page, so **every submission would have been lost while looking like a browser problem**. A DynamoDB key schema cannot be altered after creation; the handler was changed to the table on 2026-09-01 and `docs/05` §Storage carries the correction and the declined alternative. PITR **`ENABLED`**, 35-day window `[verified 2026-09-01 — describe-continuous-backups]`. Encryption at rest uses the **AWS-owned key — there is no customer-managed KMS key** `[verified 2026-09-01 — describe-table returns no SSEDescription]`, which `/legal/privacy/` does not claim, so nothing published depends on it. **4 items predate this repo**, written by the hand-built handler, which writes **no `ttl`** — so they never expire; `docs/06` carries that as Pouya's call. **TTL IS `ENABLED`, `AttributeName: ttl`** ``[verified 2026-08-31 — Pouya ran `describe-time-to-live` and read `TimeToLiveStatus: ENABLED`]``. The handler side matches: `backend/intake/handler.mjs` writes `ttl` as a Number in **epoch seconds** at **24 months** (`RETENTION_MONTHS = 24`, added to `getUTCMonth()`), which is `docs/05` §Retention and the `ttl` row of its item table `[verified 2026-08-31 — read from the handler, not recalled]`. ⚠️ **IT WAS `DISABLED` AT FIRST VERIFICATION EARLIER THE SAME DAY, AND THAT IS RECORDED RATHER THAN OVERWRITTEN.** Pouya ran `describe-time-to-live` on **2026-08-31** and it returned `DISABLED`; he enabled it on **2026-08-31** and re-read `ENABLED` the same day. `/legal/privacy/` has stated since build step 10 that a record is *"deleted automatically by the database rather than by someone remembering to do it"* after 24 months, so **that promise was unbacked from the day it was written until the day it was enabled** — the handler wrote the attribute and nothing on the table consumed it. This is the Q22 shape on a public privacy commitment rather than on a deploy control: a documented mechanism that did not exist. ⚠️ **`ENABLED` PROVES THE SETTING, NOT THE BEHAVIOUR, AND THE BEHAVIOUR IS STILL UNPROVEN — §9 Q60 STAYS OPEN.** No record has been written with a near-future `ttl` and watched to disappear. `docs/06`'s cutover checklist carries that test as a blocking item, it is not ticked by reading this row or the handler code, and §12 R19 keeps it surfacing until a deletion has actually been observed | -| **Intake table — who can read it** | 🛑 **TWO IAM IDENTITIES — AND THAT IS A COUNT OF IDENTITIES, NOT OF PEOPLE. `/legal/privacy/` NO LONGER PUBLISHES A HUMAN NUMBER (Q63, ruled 2026-09-02).** ⚠️ **THE DISTINCTION IS THE ROW'S MOST IMPORTANT CONTENT, because this register supplied the false one.** The enumeration below is exhaustive over identities and every read path terminates at `user/pouya` or `user/lars` — and the page then rendered that as *"Two people can"*. **Pouya's attestation, 2026-09-02: *"two people is an exaggeration… a handful is accurate"*.** A simulation cannot see how many humans reach a credential, so the identity count is a **lower** bound on people and was published as an exact one. The page now says *"the account's administrators — me, and the small number of people who administer it with me"*, and **no numeric human headcount may ship**. **ROOT: held by Pouya `[verified 2026-09-02 — Pouya, Q63(c)]`** — not an IAM principal, cannot be simulated, no policy constrains it; `AccountAccessKeysPresent: 0` and `AccountMFAEnabled: 1` `[verified 2026-09-02]`. The identity facts follow, and they are unchanged and still exhaustive. `user/pouya` and `user/lars`, both via group **`admins`** carrying `AdministratorAccess`. **Four roles can also read it** — two `cdk-hnb659fds-cfn-exec-role-*` (all seven actions; trust `cloudformation.amazonaws.com` only) and two `cdk-hnb659fds-lookup-role-*` (the four read actions; trust the account root, and `sts:AssumeRole` is **allowed only for those same two users**). **`adr-intake-lambda-role` holds `PutItem` ONLY** — implicitDeny on `GetItem`/`Query`/`Scan`/`BatchGetItem`/`UpdateItem`/`DeleteItem`. **`adr-sml-deploy` is implicitDeny on all seven.** The CDK/CloudFormation escalation path is implicitDeny for all three deploy users. No SAML, OIDC or Identity Center principal exists (0/0/0) — **and the account is not in an AWS Organization (`AWSOrganizationsNotInUseException`), which is what makes that Identity Center zero conclusive rather than merely local** `[verified 2026-09-02]`. **No resource-based policy on the table: `dynamodb get-resource-policy` returns `PolicyNotFoundException`** `[verified 2026-09-02]` — a command, not an inference; a resource policy is invisible to `describe-table` and grants from the opposite side to every simulation here, so nothing else in the enumeration could have seen one. Root holds **no access keys**, MFA on. ``[verified 2026-09-02 — `get-resource-policy` on the table, `organizations describe-organization`, 5 users x 7 actions, **all 33** roles x 7 actions — 26 non-service-linked and, added 2026-09-02, the 7 service-linked ones every earlier sweep had excluded by `grep -v '^AWSServiceRole'`, all implicitDeny, 4 trust policies, 5 users x 6 CDK-path actions, all in `docs/reference/intake-table-access-verification.md` with the counts asserted per call]``. ⚠️ **THE ORIGINAL 2026-09-01 VERIFICATION WAS NOT ENOUGH FOR THE SENTENCE IT BACKED**: it screened roles with `list-attached-role-policies` alone, so it never saw that **23 of 26 roles carry inline policies** and that the two `lookup` roles can read the table. Four roles can, not two. The conclusion held; the reasoning did not. **THE PAGE GOES FALSE IF THIS CHANGES AND NOTHING IN AWS WILL SAY SO — §12 R21 is the trigger.** | +| **Intake table — who can read it** | 🛑 **TWO IAM IDENTITIES — AND THAT IS A COUNT OF IDENTITIES, NOT OF PEOPLE. `/legal/privacy/` NO LONGER PUBLISHES A HUMAN NUMBER (Q63, ruled 2026-09-02).** ⚠️ **THE DISTINCTION IS THE ROW'S MOST IMPORTANT CONTENT, because this register supplied the false one.** The enumeration below is exhaustive over identities and every read path terminates at `user/pouya` or `user/lars` — and the page then rendered that as *"Two people can"*. **Pouya's attestation, 2026-09-02: *"two people is an exaggeration… a handful is accurate"*.** A simulation cannot see how many humans reach a credential, so the identity count is a **lower** bound on people and was published as an exact one. The page now says *"The record in the table: me, and the small number of people who administer the account it sits in with me"*, and **no numeric human headcount may ship**. ⚠️ **THAT SENTENCE HAS BEEN RE-QUOTED HERE THREE TIMES IN ONE DAY AND WAS WRONG TWICE — QUOTE IT FROM `dist/`, NEVER FROM A RULING OR FROM THIS ROW'S PREVIOUS VALUE.** ⚠️ **AND AS OF POUYA'S SECOND RULING THAT DAY, THIS ROW IS THE ONLY HOME FOR MOST OF WHAT FOLLOWS.** **Two facts below still ship** and must be kept true on the page as well as here: the Lambda role's **add-only** access (§Who can see it, paragraph 2) and the **shared account** (§Where it is stored). Everything else is this row's alone. *"The page stays generic. It over-explains technical mechanics that belong in the evidence file, not in front of an inquirer."* Deleted from `/legal/privacy/` §Who can see it: the measurement paragraph, the root-credential sentence, the single-sign-on and federated-login enumeration, the resource-policy clause, the *"company that runs a database"* aside, the deploy-credential sentence and the three-copies summary. ⚠️ **THE SHARED-ACCOUNT CLAUSE WAS CUT WITH THEM AND THEN RESTORED — to §Where it is stored, where it belongs.** It is a storage disclosure rather than mechanics, the ruling did not name it, and without it no page told a reader their intake sits in an account that also runs unrelated systems (`adversarial-reviewer`, round 1). **These lists must stay identical — there were four of them and they named four different sets.** **Everything below is unchanged, unretracted and still measured** — and all of it except the two facts named above has stopped appearing anywhere a reader can see it, which **raises** this row's stakes rather than lowering them: a register that nothing public contradicts is a register nobody re-reads. **Nothing here may be restored to the page**; the section comment in `src/pages/legal/privacy.astro` carries that bar. **ROOT: held by Pouya `[verified 2026-09-02 — Pouya, Q63(c)]` — RECORDED HERE, PUBLISHED NOWHERE.** The page stated it for part of 2026-09-02 and the sentence was deleted by the mechanics ruling; §9 **Q64** — *does anyone else hold it* — is closed as **MOOT rather than answered**, so ⚠️ *held by* is still not *held only by*, and **nothing about root custody may be published without asking him again** — not an IAM principal, cannot be simulated, no policy constrains it; `AccountAccessKeysPresent: 0` and `AccountMFAEnabled: 1` `[verified 2026-09-02]`. The identity facts follow, and they are unchanged and still exhaustive. `user/pouya` and `user/lars`, both via group **`admins`** carrying `AdministratorAccess`. **Four roles can also read it** — two `cdk-hnb659fds-cfn-exec-role-*` (all seven actions; trust `cloudformation.amazonaws.com` only) and two `cdk-hnb659fds-lookup-role-*` (the four read actions; trust the account root, and `sts:AssumeRole` is **allowed only for those same two users**). **`adr-intake-lambda-role` holds `PutItem` ONLY** — implicitDeny on `GetItem`/`Query`/`Scan`/`BatchGetItem`/`UpdateItem`/`DeleteItem`. **`adr-sml-deploy` is implicitDeny on all seven.** The CDK/CloudFormation escalation path is implicitDeny for all three deploy users. No SAML, OIDC or Identity Center principal exists (0/0/0) — **and the account is not in an AWS Organization (`AWSOrganizationsNotInUseException`), which is what makes that Identity Center zero conclusive rather than merely local** `[verified 2026-09-02]`. **No resource-based policy on the table: `dynamodb get-resource-policy` returns `PolicyNotFoundException`** `[verified 2026-09-02]` — a command, not an inference; a resource policy is invisible to `describe-table` and grants from the opposite side to every simulation here, so nothing else in the enumeration could have seen one. Root holds **no access keys**, MFA on. ``[verified 2026-09-02 — `get-resource-policy` on the table, `organizations describe-organization`, 5 users x 7 actions, **all 33** roles x 7 actions — 26 non-service-linked and, added 2026-09-02, the 7 service-linked ones every earlier sweep had excluded by `grep -v '^AWSServiceRole'`, all implicitDeny, 4 trust policies, 5 users x 6 CDK-path actions, all in `docs/reference/intake-table-access-verification.md` with the counts asserted per call]``. ⚠️ **THE ORIGINAL 2026-09-01 VERIFICATION WAS NOT ENOUGH FOR THE SENTENCE IT BACKED**: it screened roles with `list-attached-role-policies` alone, so it never saw that **23 of 26 roles carry inline policies** and that the two `lookup` roles can read the table. Four roles can, not two. The conclusion held; the reasoning did not. **THE PAGE GOES FALSE IF THIS CHANGES AND NOTHING IN AWS WILL SAY SO — §12 R21 is the trigger.** *(Less of the page than before: the mechanics cut of 2026-09-02 took four of R21's five claims off `/legal/privacy/`, leaving the administrators sentence and the mailbox. **The trigger did not weaken with them** — this row still asserts everything below, and `docs/06` still instructs an operator to re-run the verification before cutover.)* | | **`info@smlcompany.ca` — who reads it** | **A DELEGATED MAILBOX: Pouya AND administrative staff `[verified 2026-09-02 — Pouya, Q63(b)]`.** D18 sends the intake notification here, so this is the access list for the **second** copy of every submission — including the opposing parties and their counsel, which is the most sensitive thing the form collects. `/legal/privacy/` states it in terms (*"read by me and by administrative staff"*), having previously said *"anyone who can reach that mailbox"* — true either way, and a lower standard than the measured answer given one paragraph earlier for the table. ⚠️ **THIS IS AN ATTESTATION, NOT A MEASUREMENT, and it is the only fact behind a `/legal/privacy/` sentence that is.** Nothing in this repository or in AWS can check it: the mailbox is on Google Workspace (see the mail-hosting row) and this repo holds no Workspace credential. **It goes stale the way the AWS enumeration does and by the same mechanism — nobody is told when a delegation changes — so §12 R21's trigger covers it too.** | | 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 | @@ -775,9 +777,9 @@ Nothing below can be invented. Each needs an answer from Pouya. | # | Question | Blocks | |---|---|---| -| **Q64** | 🛑 **DOES ANYONE ELSE HOLD THE AWS ROOT PASSWORD OR ITS MFA DEVICE?** `/legal/privacy/` now publishes *"Its root credential — the one path no policy constrains — has no programmatic key, and I hold it"*, which are Pouya's own words from the Q63(c) ruling and are **true whether or not somebody else holds it too**. ⚠️ **The defect is what a reader takes from it.** The sentence sits one paragraph below *"the small number of people who administer it with me"*, so a reader takes *"I hold it"* as **sole** custody — and nothing establishes that. Root is not an IAM principal, cannot be simulated, and `get-account-summary` reports only `AccountAccessKeysPresent: 0` and `AccountMFAEnabled: 1` `[verified 2026-09-02]`; the attestation in §7 says *held by Pouya*, not *held only by Pouya*. **This is Q63's own lesson one paragraph lower and pointing the other way:** Q63 struck a sentence for reading identities as people, and this one invites a reader to read a possessive as an exclusion. §12 **R21** was written treating it as exclusive and has been corrected pending the answer. **If it is sole custody: say so, put it in §7, and R21 arms it. If it is not: the possessive comes out and the sentence keeps only the measured half.** Raised by `adversarial-reviewer`, round 1, 2026-09-02 | **`/legal/privacy/` going public, and therefore the cutover.** `src/pages/legal/privacy.astro` carries the `TODO(pouya)` beside the paragraph; `docs/06`'s checklist carries it as its own unticked item. It blocks no other page | -| ~~**Q63**~~ | ✅ **CLOSED 2026-09-02 — ALL THREE LIMBS ANSWERED BY RULING, and the answer to (c) changed the sentence (a) had just approved.** **(a) WORDING APPROVED WITH TWO TRIMS:** the editorial closing sentence (*"I would rather tell you that than give you the tidier answer"*) is struck, and the mailbox clause is rewritten per (b). **(b) `info@smlcompany.ca` IS A DELEGATED MAILBOX — Pouya and administrative staff read it.** The page said *"anyone who can reach that mailbox"*; it now says who. ⚠️ **That answer reached FOUR sentences, not the one the question named** — §Where it is stored twice (*"a notification to me"*, *"my own mail is on Google Workspace"*), §How long it is kept once (*"the notification sits in my mailbox"*) and §Who can see it once — because the mailbox had been written as a personal one throughout the page. **Fifth partial sweep of this page's who-can-see-it set; the section comment now names all NINE places, by opening phrase rather than by count** — it shipped "eight" for one round, having excluded a paragraph this very change set edited (`adversarial-reviewer`, round 1). **(c) ROOT IS HELD BY POUYA** `[verified 2026-09-02 — Pouya]`, and the page now states that it has no programmatic key and that he holds it. ⚠️ **THE CONSEQUENCE NOBODY ASKED FOR AND IT IS THE MOST IMPORTANT LINE IN THIS ROW: THE HUMAN HEADCOUNT CAME OFF THE PAGE.** Pouya's attestation: *"two people is an exaggeration… a handful is accurate — the simulation counts identities, not humans, and the two are not the same claim."* **The enumeration was exhaustive and the inference off it was not**: every read path terminates at two IAM identities, which is a **lower bound** on the number of people who can reach them, and `/legal/privacy/` published it as an exact count. It now reads *"the account's administrators — me, and the small number of people who administer it with me"*. **No numeric human headcount ships**, the identity count stays in §7 and in the reference extract, and the extract's own inference sentence (*"The count of people is two"*) is corrected at source, because a false inference left in the evidence file re-supplies itself to the next reader. ⚠️ **AND THE `33` WAS DELIBERATELY NOT PUBLISHED** — the ruling permits the identity count on the page *"if useful"*; a role total moves when AWS creates a service-linked role by itself, so publishing it would put a second R21-governed number on a legal page that can go stale with no human acting. *"Every user and every role in the account"* carries the exhaustiveness and survives the count moving. **One line to overrule.** Original question follows. 🛑 **TWO THINGS `/legal/privacy/` STILL NEEDED FROM POUYA, ANSWERED IN THE SAME READ-THROUGH.** **(a) APPROVE THE §Who can see it WORDING.** Q62 settled what it must say and he reserved the wording in terms: *"Draft it; Pouya gives final approval on wording during his page read-through."* The draft is shipped in `dist/` and quoted in `docs/reference/intake-table-access-verification.md`. **This is a gate that existed only inside records marked closed until 2026-09-02** — the `TODO(pouya)` had been deleted, Q62 struck, and `docs/06`'s blocker ticked, so when Q60's TTL test passes **nothing mechanical or visual would have stopped unapproved copy publishing.** `adversarial-reviewer`, round 1. **(b) WHO ELSE CAN READ `info@smlcompany.ca`?** Nothing in this repository establishes it — §7 records the mail host (Google Workspace) and the SES identities, **not the mailbox's access list**, and a Workspace super-admin can reach any mailbox in the tenancy. Given that this project's AWS account, its Gitea instance and §10 are all jointly administered, the plausible case is that it is not only him. The copy is now written to assert **no** access list (*"anyone who can reach that mailbox"*), so nothing false is published either way — but a privacy policy that answers the table half with a measured number and the mail half with a shrug is answering the same question on two standards, and the reader is entitled to the specific on both. **(c) WHO HOLDS THE ROOT CREDENTIAL FOR THE AWS ACCOUNT?** The page's headline answer is a **count of people**, and root is the one path no policy constrains and no simulation can reach — it is not an IAM principal and does not appear in `list-users`. Two facts bound it: `AccountAccessKeysPresent: 0`, so there is no programmatic root credential, and MFA is on, so console access needs the root password and its device `[verified 2026-09-02]`. **If those are held by anyone other than the two administrators, "Two people can" is short by one.** The second paragraph is scoped to *"every user and every role"* and to who has been **granted** access, so it is unaffected either way — this reaches the first sentence only. Raised by `adversarial-reviewer`, round 2, which is also where the honest form of the objection came from: the artefact says in terms that this is not established, and a page was resting a count on it. **If he answers: put the fact in §7, make the sentence specific like the table sentence above it, and arm it with §12 R21's trigger.** Raised by `claims-auditor` and `adversarial-reviewer`, D20 cutover pass round 1, 2026-09-02 | *(closed)* | -| ~~**Q62**~~ | ✅ **CLOSED 2026-09-02 — RULED *state the truth*, NOT *remove the access*. Pouya:** *"Rewrite the `/legal/privacy/` sentence to say exactly who can access the submissions table… the true number of people and their roles, stated specifically — not 'authorised administrators' or any other vacancy."* **Applied.** The page now opens §Who can see it with *"Two people can"*, states that the AWS account also runs systems unrelated to this practice and has two administrators, and says administrative access carries the ability to read the table. It then publishes the two facts the false sentence had been crowding out and which are **stronger** than what it claimed: the function that receives the form can only add a record and **cannot read the table back**, and the credential that publishes this website has **no access to the table at all**. ⚠️ **THE FIX TOUCHED THREE PLACES, NOT ONE, AND THE OTHER TWO ARE THE POINT.** A vocabulary sweep — `grep -rniE "no (team\|assistant\|outside\|external) [a-z]*\|nobody else\|no one else" src/` — found the same falsehood in different words **two sections up the same page**: §Where it is stored ended *"and no assistant or outside administrator"*, which the Q62 pattern could not see because it was anchored on the two sentences under the other heading. And the summary paragraph closed *"the honest answer to 'who can see this' is: me, and Google"* — which would have survived the correction directly above it and re-asserted the struck number. All three now change together and the page's own comment says so. **THE TRIPWIRE STAYS PERMANENTLY — his ruling in terms:** *"it bars the false-claim shape from returning, which is exactly what the freeze's breach exception exists for."* Extended from two alternatives to **five** — round 1 of the closing audit found a third published surface unbarred, and found the first extension had widened one alternative to four phrasings where one was published. Every alternative is now a single string that reached `dist/`, so nothing speculative entered a frozen script. **Proven both ways, on real published bytes and not on fixtures alone:** against the pre-correction page rebuilt from `bd282aa` it exits **1** with **5 matches** at `dist/legal/privacy/index.html:54, 67, 67, 68, 72` — 54 is the clause the first form missed and 72 the surface it could not see at all — and against the corrected page it exits **0**. ⚠️ **THE APPROVED-STRING AND FIXTURE COUNTS ARE NO LONGER RESTATED HERE, DELIBERATELY.** They said four/four/33/three, then 36/six, then were stale again within one review round when the Q63 rewrite changed the copy the fixtures quote — three times in two days, on a row whose own point is that the record of what a frozen script bars is its maintenance surface. **`npm run check:claims` prints both numbers on every run; read them there.** As at 2026-09-02 it prints **35 approved strings**, of which the first **seven** are live `/legal/privacy/` copy carrying a re-sync instruction (`adversarial-reviewer`, round 2). ⚠️ **The counts in this row said four/four/33/three until 2026-09-02**, describing the script as it stood before round 1's fix; on a frozen script the record of what it bars is the maintenance surface, so `adversarial-reviewer` round 2 was right to treat a stale count as a defect. ⚠️ **AND THE FIX AS FIRST WRITTEN INTRODUCED THREE DEFECTS OF ITS OWN, ALL FOUND BY THE D20 PASS ROUND 1 AND ALL NOW CORRECTED — see entry (an).** The replacement asserted *"No third party has access to it"* (an absolute negative that excludes a **disclosed processor**, which is the exact sentence struck from this page on 2026-08-31 as *"the most serious thing found in the step 7–10 review"*); it claimed *"every account and role in this infrastructure… that is checked rather than assumed"* over an artefact that had screened five users and **one** role; and it said *"the one other place a copy exists"* when the handler puts the whole submission into the confirmation it sends the inquirer, so a **third** copy sits with the reader's own provider — which this page already says two sections up. **Q62's own fix recreated Q62's shape twice.** **Two things are NOT resolved and are now Q63 rather than a footnote here** — the wording approval Pouya reserved, and the `info@smlcompany.ca` access list. The earlier form of this row called the mailbox point non-gating *"because the copy is true either way"*, which was **a guess about a fact nobody checked**; the copy is now written so it asserts no access list at all, and the question gates the page through Q63 with a `TODO(pouya)` beside it. Original finding follows. 🛑 **`/legal/privacy/` TELLS THE PUBLIC SOMETHING FALSE ABOUT WHO CAN READ THE INTAKE TABLE, AND IT IS A PRIVACY POLICY.** The page says: *"The table is reachable by the function that writes to it and by one administrative account, which is mine — nobody else has access to the table. There is no team, no assistant and no external administrator."* **The account has an IAM group `admins` carrying `AdministratorAccess` with TWO members**, and `iam simulate-principal-policy` returns **allowed** for `dynamodb:GetItem`, `dynamodb:Query` and `dynamodb:Scan` on the table for both of them — identical access, by the same route, the other user's own attachments being only `IAMUserChangePassword` `[verified 2026-09-01 — the five users, the group, and a five-row simulation, all commands in `docs/reference/intake-table-access-verification.md`]`. So **both halves of the sentence are wrong**: a second account has access, and it belongs to a second administrator of a shared account (§10). The three deploy users are `implicitDeny`; two CDK bootstrap roles carry `AdministratorAccess` but are assumable only by the same two administrators; the writing role holds **`PutItem` only and cannot read the table**, which is a stronger fact than the page currently claims and is the part of the sentence that is true. **THE QUESTION, AND IT IS ONE OF TWO THINGS.** (1) **Remove the access** — take that user out of `admins`, or deny DynamoDB on this table — after which the sentence becomes true as written. ⚠️ Note the likely collision: **Q23 records the Gitea instance as jointly administered and blocked on "its second administrator"**, so that access is probably not only for this account and removing it may cost something elsewhere. (2) **State the true number** — how many people hold administrative access, and that the function which writes cannot read. ⚠️ **DO NOT RESOLVE IT BY SOFTENING.** *"Access is limited to authorised administrators"* is the shape §4 exists to bar: defensible, uninformative, and it would replace a false specific with a true vacancy on the one page where a reader describing a live dispute is entitled to the specific. **Why this was invisible until now:** it is the only claim on the site whose subject lives entirely outside the repository, so R14 applies — *"unverifiable by construction"* — and there was no committed artefact to compare it against. There is now. Raised by `claims-auditor`, D20 cutover pass, finding 8 | *(closed)* | +| ~~**Q64**~~ | ✅ **CLOSED 2026-09-02 — MOOT. THE PARAGRAPH IT WAS ABOUT WAS DELETED, WHICH IS NOT THE SAME AS THE QUESTION BEING ANSWERED.** Pouya's second ruling of 2026-09-02 cut §Who can see it to four plain statements and struck the mechanics, the root sentence among them — *"the page stays generic. It over-explains technical mechanics that belong in the evidence file, not in front of an inquirer."* No page now says anything about root, so nothing turns on who holds it and the question gates nothing. The `TODO(pouya)` went with the paragraph. ⚠️ **THE UNDERLYING GAP IS EXACTLY AS OPEN AS IT WAS AND MUST NOT BE READ AS CLOSED.** §7 records root as *held by Pouya* `[verified 2026-09-02 — Pouya]`, which is not *held only by Pouya*; root is not an IAM principal, cannot be simulated, and `get-account-summary` reports only `AccountAccessKeysPresent: 0` and `AccountMFAEnabled: 1`. **Nothing about root custody may be published without asking him again**, and the question to ask is not *who holds root* — that is answered — but ***whether anyone else does***. §7's row, `docs/reference/intake-table-access-verification.md`'s addendum and the section comment in `src/pages/legal/privacy.astro` all carry that bar. **This is the third distinct way a question has left this list in one day — answered (Q63), struck (Q62), and now moot — and all three look identical in a count.** Original question follows. 🛑 **DOES ANYONE ELSE HOLD THE AWS ROOT PASSWORD OR ITS MFA DEVICE?** `/legal/privacy/` now publishes *"Its root credential — the one path no policy constrains — has no programmatic key, and I hold it"*, which are Pouya's own words from the Q63(c) ruling and are **true whether or not somebody else holds it too**. ⚠️ **The defect is what a reader takes from it.** The sentence sits one paragraph below *"the small number of people who administer it with me"*, so a reader takes *"I hold it"* as **sole** custody — and nothing establishes that. Root is not an IAM principal, cannot be simulated, and `get-account-summary` reports only `AccountAccessKeysPresent: 0` and `AccountMFAEnabled: 1` `[verified 2026-09-02]`; the attestation in §7 says *held by Pouya*, not *held only by Pouya*. **This is Q63's own lesson one paragraph lower and pointing the other way:** Q63 struck a sentence for reading identities as people, and this one invites a reader to read a possessive as an exclusion. §12 **R21** was written treating it as exclusive and has been corrected pending the answer. **If it is sole custody: say so, put it in §7, and R21 arms it. If it is not: the possessive comes out and the sentence keeps only the measured half.** Raised by `adversarial-reviewer`, round 1, 2026-09-02 | *(closed — moot)* | +| ~~**Q63**~~ | ✅ **CLOSED 2026-09-02 — ALL THREE LIMBS ANSWERED BY RULING, and the answer to (c) changed the sentence (a) had just approved.** **(a) WORDING APPROVED WITH TWO TRIMS:** the editorial closing sentence (*"I would rather tell you that than give you the tidier answer"*) is struck, and the mailbox clause is rewritten per (b). **(b) `info@smlcompany.ca` IS A DELEGATED MAILBOX — Pouya and administrative staff read it.** The page said *"anyone who can reach that mailbox"*; it now says who. ⚠️ **That answer reached FOUR sentences, not the one the question named** — §Where it is stored twice (*"a notification to me"*, *"my own mail is on Google Workspace"*), §How long it is kept once (*"the notification sits in my mailbox"*) and §Who can see it once — because the mailbox had been written as a personal one throughout the page. **Fifth partial sweep of this page's who-can-see-it set. The section comment names the places by opening phrase and gives NO COUNT** — it carried "eight" for one round after excluding a paragraph its own change set had edited, then "nine", and the set is now ten (`adversarial-reviewer`, rounds 1 and 2, on successive counts). **(c) ROOT IS HELD BY POUYA** `[verified 2026-09-02 — Pouya]`, and the page now states that it has no programmatic key and that he holds it. ⚠️ **THE CONSEQUENCE NOBODY ASKED FOR AND IT IS THE MOST IMPORTANT LINE IN THIS ROW: THE HUMAN HEADCOUNT CAME OFF THE PAGE.** Pouya's attestation: *"two people is an exaggeration… a handful is accurate — the simulation counts identities, not humans, and the two are not the same claim."* **The enumeration was exhaustive and the inference off it was not**: every read path terminates at two IAM identities, which is a **lower bound** on the number of people who can reach them, and `/legal/privacy/` published it as an exact count. It then read *"the account's administrators — me, and the small number of people who administer it with me"*. ⚠️ **THAT IS NOT THE SHIPPED SENTENCE EITHER, AND NOR WAS ITS REPLACEMENT.** Pouya ruled again the same day that the section states who and not how; the measurement paragraph, the root sentence and the summary were deleted outright, and the first sentence was then rewritten **twice more under review** — *"The people who run this practice can"* was struck for asserting an unregistered claim about who runs the practice, and *"administer this practice's systems"* for naming a set neither the measurement nor the attestation supports. **It ships as *"The record in the table: me, and the small number of people who administer the account it sits in with me"*, and §4 has the row it rests on.** Each limb of Q63 still stands; only the text it was applied to moved — **four times in one day, which is why nothing outside `dist/` is a safe source for this quote.** **No numeric human headcount ships**, the identity count stays in §7 and in the reference extract, and the extract's own inference sentence (*"The count of people is two"*) is corrected at source, because a false inference left in the evidence file re-supplies itself to the next reader. ⚠️ **AND THE `33` WAS DELIBERATELY NOT PUBLISHED** — the ruling permits the identity count on the page *"if useful"*; a role total moves when AWS creates a service-linked role by itself, so publishing it would put a second R21-governed number on a legal page that can go stale with no human acting. *"Every user and every role in the account"* carries the exhaustiveness and survives the count moving. **One line to overrule.** Original question follows. 🛑 **TWO THINGS `/legal/privacy/` STILL NEEDED FROM POUYA, ANSWERED IN THE SAME READ-THROUGH.** **(a) APPROVE THE §Who can see it WORDING.** Q62 settled what it must say and he reserved the wording in terms: *"Draft it; Pouya gives final approval on wording during his page read-through."* The draft is shipped in `dist/` and quoted in `docs/reference/intake-table-access-verification.md`. **This is a gate that existed only inside records marked closed until 2026-09-02** — the `TODO(pouya)` had been deleted, Q62 struck, and `docs/06`'s blocker ticked, so when Q60's TTL test passes **nothing mechanical or visual would have stopped unapproved copy publishing.** `adversarial-reviewer`, round 1. **(b) WHO ELSE CAN READ `info@smlcompany.ca`?** Nothing in this repository establishes it — §7 records the mail host (Google Workspace) and the SES identities, **not the mailbox's access list**, and a Workspace super-admin can reach any mailbox in the tenancy. Given that this project's AWS account, its Gitea instance and §10 are all jointly administered, the plausible case is that it is not only him. The copy is now written to assert **no** access list (*"anyone who can reach that mailbox"*), so nothing false is published either way — but a privacy policy that answers the table half with a measured number and the mail half with a shrug is answering the same question on two standards, and the reader is entitled to the specific on both. **(c) WHO HOLDS THE ROOT CREDENTIAL FOR THE AWS ACCOUNT?** The page's headline answer is a **count of people**, and root is the one path no policy constrains and no simulation can reach — it is not an IAM principal and does not appear in `list-users`. Two facts bound it: `AccountAccessKeysPresent: 0`, so there is no programmatic root credential, and MFA is on, so console access needs the root password and its device `[verified 2026-09-02]`. **If those are held by anyone other than the two administrators, "Two people can" is short by one.** The second paragraph is scoped to *"every user and every role"* and to who has been **granted** access, so it is unaffected either way — this reaches the first sentence only. Raised by `adversarial-reviewer`, round 2, which is also where the honest form of the objection came from: the artefact says in terms that this is not established, and a page was resting a count on it. **If he answers: put the fact in §7, make the sentence specific like the table sentence above it, and arm it with §12 R21's trigger.** Raised by `claims-auditor` and `adversarial-reviewer`, D20 cutover pass round 1, 2026-09-02 | *(closed)* | +| ~~**Q62**~~ | ✅ **CLOSED 2026-09-02 — RULED *state the truth*, NOT *remove the access*. Pouya:** *"Rewrite the `/legal/privacy/` sentence to say exactly who can access the submissions table… the true number of people and their roles, stated specifically — not 'authorised administrators' or any other vacancy."* **Applied.** The page now opens §Who can see it with *"Two people can"*, states that the AWS account also runs systems unrelated to this practice and has two administrators, and says administrative access carries the ability to read the table. It then published the two facts the false sentence had been crowding out and which are **stronger** than what it claimed: the function that receives the form can only add a record and **cannot read the table back**, and the credential that publishes this website has **no access to the table at all**. ⚠️ **OF THOSE TWO, ONLY THE FIRST STILL SHIPS** — the mechanics ruling of 2026-09-02 took the deploy-credential sentence off the page along with the rest of the method. It is unretracted and still measured; it lives in §7 and in `docs/reference/intake-table-access-verification.md`. ⚠️ **THE FIX TOUCHED THREE PLACES, NOT ONE, AND THE OTHER TWO ARE THE POINT.** A vocabulary sweep — `grep -rniE "no (team\|assistant\|outside\|external) [a-z]*\|nobody else\|no one else" src/` — found the same falsehood in different words **two sections up the same page**: §Where it is stored ended *"and no assistant or outside administrator"*, which the Q62 pattern could not see because it was anchored on the two sentences under the other heading. And the summary paragraph closed *"the honest answer to 'who can see this' is: me, and Google"* — which would have survived the correction directly above it and re-asserted the struck number. All three now change together and the page's own comment says so. **THE TRIPWIRE STAYS PERMANENTLY — his ruling in terms:** *"it bars the false-claim shape from returning, which is exactly what the freeze's breach exception exists for."* Extended from two alternatives to **five** — round 1 of the closing audit found a third published surface unbarred, and found the first extension had widened one alternative to four phrasings where one was published. Every alternative is now a single string that reached `dist/`, so nothing speculative entered a frozen script. **Proven both ways, on real published bytes and not on fixtures alone:** against the pre-correction page rebuilt from `bd282aa` it exits **1** with **5 matches** at `dist/legal/privacy/index.html:54, 67, 67, 68, 72` — 54 is the clause the first form missed and 72 the surface it could not see at all — and against the corrected page it exits **0**. ⚠️ **THE APPROVED-STRING AND FIXTURE COUNTS ARE NO LONGER RESTATED HERE, DELIBERATELY.** They said four/four/33/three, then 36/six, then were stale again within one review round when the Q63 rewrite changed the copy the fixtures quote — three times in two days, on a row whose own point is that the record of what a frozen script bars is its maintenance surface. **`npm run check:claims` prints both numbers on every run; read them there.** **Both numbers are deliberately not repeated here** — they moved again on 2026-09-02 when the mechanics cut retired six fixtures and added four, and a row that had just ruled the printed numbers authoritative was still carrying its own stale pair one sentence later (`adversarial-reviewer`, round 1). The script prints the pattern count, the approved-string count and which of them are live page copy; that is the record. ⚠️ **The counts in this row said four/four/33/three until 2026-09-02**, describing the script as it stood before round 1's fix; on a frozen script the record of what it bars is the maintenance surface, so `adversarial-reviewer` round 2 was right to treat a stale count as a defect. ⚠️ **AND THE FIX AS FIRST WRITTEN INTRODUCED THREE DEFECTS OF ITS OWN, ALL FOUND BY THE D20 PASS ROUND 1 AND ALL NOW CORRECTED — see entry (an).** The replacement asserted *"No third party has access to it"* (an absolute negative that excludes a **disclosed processor**, which is the exact sentence struck from this page on 2026-08-31 as *"the most serious thing found in the step 7–10 review"*); it claimed *"every account and role in this infrastructure… that is checked rather than assumed"* over an artefact that had screened five users and **one** role; and it said *"the one other place a copy exists"* when the handler puts the whole submission into the confirmation it sends the inquirer, so a **third** copy sits with the reader's own provider — which this page already says two sections up. **Q62's own fix recreated Q62's shape twice.** **Two things are NOT resolved and are now Q63 rather than a footnote here** — the wording approval Pouya reserved, and the `info@smlcompany.ca` access list. The earlier form of this row called the mailbox point non-gating *"because the copy is true either way"*, which was **a guess about a fact nobody checked**; the copy is now written so it asserts no access list at all, and the question gates the page through Q63 with a `TODO(pouya)` beside it. Original finding follows. 🛑 **`/legal/privacy/` TELLS THE PUBLIC SOMETHING FALSE ABOUT WHO CAN READ THE INTAKE TABLE, AND IT IS A PRIVACY POLICY.** The page says: *"The table is reachable by the function that writes to it and by one administrative account, which is mine — nobody else has access to the table. There is no team, no assistant and no external administrator."* **The account has an IAM group `admins` carrying `AdministratorAccess` with TWO members**, and `iam simulate-principal-policy` returns **allowed** for `dynamodb:GetItem`, `dynamodb:Query` and `dynamodb:Scan` on the table for both of them — identical access, by the same route, the other user's own attachments being only `IAMUserChangePassword` `[verified 2026-09-01 — the five users, the group, and a five-row simulation, all commands in `docs/reference/intake-table-access-verification.md`]`. So **both halves of the sentence are wrong**: a second account has access, and it belongs to a second administrator of a shared account (§10). The three deploy users are `implicitDeny`; two CDK bootstrap roles carry `AdministratorAccess` but are assumable only by the same two administrators; the writing role holds **`PutItem` only and cannot read the table**, which is a stronger fact than the page currently claims and is the part of the sentence that is true. **THE QUESTION, AND IT IS ONE OF TWO THINGS.** (1) **Remove the access** — take that user out of `admins`, or deny DynamoDB on this table — after which the sentence becomes true as written. ⚠️ Note the likely collision: **Q23 records the Gitea instance as jointly administered and blocked on "its second administrator"**, so that access is probably not only for this account and removing it may cost something elsewhere. (2) **State the true number** — how many people hold administrative access, and that the function which writes cannot read. ⚠️ **DO NOT RESOLVE IT BY SOFTENING.** *"Access is limited to authorised administrators"* is the shape §4 exists to bar: defensible, uninformative, and it would replace a false specific with a true vacancy on the one page where a reader describing a live dispute is entitled to the specific. **Why this was invisible until now:** it is the only claim on the site whose subject lives entirely outside the repository, so R14 applies — *"unverifiable by construction"* — and there was no committed artefact to compare it against. There is now. Raised by `claims-auditor`, D20 cutover pass, finding 8 | *(closed)* | | ~~**Q61**~~ | ✅ **CLOSED 2026-09-01 — RULED *fix now*, IMPLEMENTED AND MEASURED.** The minimum-font-size sticky header obscured keyboard focus: **290 entirely-hidden focus stops of 1,455** under `minimumFontSize=32`, a WCAG 2.2 **SC 2.4.11 (AA)** failure, created by the 2026-09-01 header fix. The fix is two declarations on `html` in the existing `@media (min-width: 66rem)` block — the plain `calc(var(--header-h) + var(--space-4))` first as a fallback, then `max(calc(var(--header-h) + var(--space-4)), calc(10lh - 83px))`. **`1lh`, not `rem`: the font-metric units read the *used* font size**, which is the mechanism the withdrawn ruling's premise denied existed. **Result, on the identical grid with the pre-fix tree rebuilt in a worktree as the control: 290 → 0, control still 290.** Default-settings rendering unchanged: **0 differences over 352 page-widths × 17 fields**, positive control detecting exactly 1 injected difference. `scroll-padding-top` 97 px at the default, 287 px under the setting against a 270.56 px header; `1lh` on `` is 18 / 37 px **with every `.woff2` blocked**, identical, because `` keeps the UA family. A wider grid than the ruling asked for — **777 cells over 37 settings — went from 63 failing to 12, with no cell worse.** The 12 are `minimumFontSize=16` and `=20`, they are **pre-existing and reduced**, and they were deliberately not fixed under Pouya's *"stop and report, do not widen"*: the setting floors sub-root type without moving the root, so `1lh` reads a quantity that did not change. `docs/06` carries it as its own item | *(closed)* | | **Q60** | ⚠️ **HAS A TEST RECORD BEEN OBSERVED TO DISAPPEAR FROM THE INTAKE TABLE?** **Half one closed 2026-08-31: TTL is `ENABLED` with `AttributeName: ttl`, verified by command — §7 holds that status and this row does not restate it.** The question is now the second half alone, and it was never the smaller half. `/legal/privacy/` does not merely publish a retention *period* — it asserts a **mechanism**: *"the record is deleted automatically by the database rather than by someone remembering to do it"*. **`ENABLED` proves the setting; only a record written with a near-future `ttl` and watched to vanish proves the behaviour.** Two things this may NOT be answered from: the handler code, which writes the attribute and nothing more (that side is verified and is not what is being asked); and the table setting, which is what was just confirmed. ⚠️ **AND THE FIRST HALF IS THE REASON TO TRUST THE SECOND LESS, NOT MORE:** `describe-time-to-live` returned **`DISABLED`** when Pouya first ran it on 2026-08-31, so the sentence above was published against a mechanism that was not running, and nothing in the repo, the build or AWS reported it. A setting that was off for as long as nobody looked is not evidence that the behaviour now works. `TODO(pouya)` sits on the retention section of `src/pages/legal/privacy.astro`; `docs/06`'s cutover checklist carries the test as blocking; §12 R19 keeps it surfacing. **Why this is a numbered question and not only a checklist line:** `CLAUDE.md` requires a `TODO(pouya)` plus a §9 row when a page needs a fact the repository does not have, and this page needs one — a cutover checklist fires once, at cutover, and §9 is what a person editing this page reads. Raised by `adversarial-reviewer` round 2, 2026-08-31 | **`/legal/privacy/` going public.** Nothing else — no other page states the mechanism, verified by sweeping `dist/` for the retention vocabulary and reading each hit in context | | ~~Q59~~ | ✅ **RULED AND CLOSED 2026-08-31 — Pouya. OVERTIME RUNS FROM THE SESSION CAP**: the fourth hour of a half day, the seventh of a full day. Not the billed envelope. `/fees/` shipped at build step 9 on this ruling and `docs/07` carries it in full. ⚠️ **THIS ROW NAMED A CONSTANT THAT NO LONGER EXISTS** — `FEES.mediation.overtimeStartsAfterSessionHours` was deleted the same day as dead data: nothing read it, so reversing it would have changed nothing and failed nothing, which is Q22's shape at constant scope. **Where the ruling actually lives:** the trigger is rendered on `/fees/` from `halfDay.hours` / `fullDay.hours`, and `FEES.mediation.reservation` carries the half that publishes as prose. Found by `adversarial-reviewer` round 2 — §9 is what a later implementer reads to find where a ruling is recorded, so pointing it at a deleted identifier is the same defect one layer up. ⚠️ **AND THE RULING CAME WITH A SECOND HALF THAT ANSWERS THE ARITHMETIC ANOMALY THIS ROW EXISTED TO ESCALATE, WHICH THE TRIGGER ALONE COULD NOT.** His words: *"a full day reserves the day; half-day overtime is subject to availability."* **The full-day fee buys the DAY, not six hours of it.** Read as a price comparison the table below says the full-day rate is never the cheaper choice; read knowing what each fee reserves, the $2,000-narrowing-to-$500 spread is the price of certainty rather than a defect. The sentence is `FEES.mediation.reservation` and it publishes **adjacent to the overtime row**, not as a footnote — the same structural rule as `PROCESS_FRAMING` beside the five timings under Q43, because a reader who takes the number and skips the framing has read a different offer. **THE ANOMALY IS NOT CLOSED AND STAYS ON §12 R5.** The gap is in D14's own figures — the half-to-full step is $2,000 against $1,500 for three hours of overtime — and the reservation point explains what it buys without removing it; the spread is largest at three to five hours, which is the band a half-day booking actually overruns into. `docs/07` §Recorded dissent carries the table for the 12-month review. **The original question, kept because the shape of it is the lesson.** *Where does the overtime hour start?* `docs/07`'s card carried *"Overtime, per hour — $500"* and had never said what it was overtime **to**. Q58's ruling settled the two allowances and did not reach this; Q15–Q17's answer records the rate with no trigger. The two candidates were the session cap (3 h / 6 h) and the billed envelope (5 h / 9 h), and this repository was barred from picking one — a fee term is a fact we do not have, and `CLAUDE.md`'s rule for that is a question, not an inference. **It cost two strikes to hold that line:** a first pass at `docs/07`'s Q58 note asserted the session cap as applied fact and `adversarial-reviewer` struck it in the change set that wrote it; a round-1 fix then published the $500 rate on `/for-parties/` beside an unambiguous *"up to 3 hours"*, which **defines the trigger by adjacency** — nothing else on the page is a quantity it can attach to — and round 2 struck that too. Both strikes were right, and the ruling supplied the value they were waiting for | ~~`/fees/`, `/for-parties/`~~ — both now unblocked and shipped | @@ -938,7 +940,7 @@ never being raised again. | R18 | ✅ **RE-CHECKED 2026-09-01 — the cutover fire. ALL SEVEN HOLD AND NO SHIPPED SENTENCE CHANGED.** Verified by Pouya (architect verification, Claude web) and recorded here with the sources, because the trigger is *"re-check before any cutover"* and this is that cutover. ⚠️ **THE STAMP IS TWO-TIER ON PURPOSE AND THE TIERS MUST NOT BE COLLAPSED: three limbs were re-verified against a source; four are held unchanged on a CADENCE JUDGEMENT rather than a fresh retrieval.** Writing all seven as "re-checked" would be the OCNI failure in miniature — a stamp that reads like a check and records a belief. ⚠️ **AND A CANDIDATE EIGHTH LIMB WAS FOUND WHILE STAMPING, FLAGGED RATHER THAN ADOPTED — (h)**: `/practice/construction/` publishes *"Ontario Power Generation … applied in March 2026 for a licence to operate it"*, a **pending application** that moves the way (a) moves. Not false today — the application was made, and a completed past act stays true — so it blocks nothing; but unlike (a) the sentence is **not time-anchored**, and a reader takes it as current status. **Pouya's call at the next re-check: adopt it as (h), or time-anchor the sentence and drop it.** **RE-VERIFIED AGAINST A SOURCE:** **(a) Bill C-36** — still at second reading in the House of Commons; latest completed stage **first reading, 2026-06-15**; no advance since `[re-checked 2026-09-01 — ]`. `/practice/technology/`'s *"was at second reading when this page was written"* stands. **This is the fastest mover of the seven and it needs no page edit while it sits, and one the day it moves.** **(d) the Tribunals Ontario annual report** — **no 2025-26 edition is published; FY2024-25 remains current** `[re-checked 2026-09-01 — ]`, so the figures `/practice/insurance/` publishes are still the latest. **This also closes an open item at the foot of `docs/reference/ontario-sabs-lat.md`** which had recorded *"NOT CONFIRMED either way… given today's date, one may well have been published"* — the honest gap is now answered. **(c) ERO 026-0853** — comment period to **2026-09-12** still open `[re-checked 2026-09-01]`. **HELD UNCHANGED ON A CADENCE JUDGEMENT, NOT RE-RETRIEVED — `[assumed 2026-09-01 — Pouya: unchanged by their nature at this cadence]`:** **(b)** the regulation under `Electricity Act` s. 28.1, **(e)** the SABS, **(f)** the ADRIC National Mediation Rules, **(g)** ADRIC's Code of Ethics. The quoted bytes in every extract are still the original retrieval and were not re-fetched; the digests in `adric-rules.md` were not recomputed, so that stamp says nothing about whether the page changed. ⚠️ **AND THE TRIGGER HAD NOWHERE TO FIRE, WHICH IS Q22'S SHAPE.** R18 names a cutover as its event and **`docs/06`'s cutover checklist carried no R18 item** — R10's was there, R18's was not, so a control documented here could not run where it was documented to run. **`docs/06` now carries one**, ticked for this cutover and re-armed for the next republish. Found 2026-09-02 while recording the re-stamp. ⚠️ **AND THE FIRST PASS STAMPED FIVE EXTRACTS OF SEVEN.** `ontario-construction-act.md` and `ontario-shareholder-remedies.md` carry the same standing "re-check before cutover" header and got no stamp, so a reader could not tell whether they were considered or missed — the same defect as this row having no checklist item, one notch smaller. Both are stamped now; `git grep -l "R18 re-check — cutover pass" -- docs/reference` returns **7**, and the set difference against `git grep -l "Re-check before cutover"` is **empty**. `adversarial-reviewer`, round 1. **THE ROW STAYS LIVE**: the trigger is an event and events recur. Original text follows. **THE SIX `docs/reference/` EXTRACTS BEHIND `/practice/*` ARE DATED 2026-08-29, AND SIX SHIPPED SENTENCES TURN ON FACTS THAT MOVE.** Build step 5 put statute, regulation, tribunal and bill status onto public pages — sourced, but **sourced as at one day**. The volatile ones, in order of how fast they move: **(a) federal Bill C-36** — `/practice/technology/` says it *"was introduced in June 2026 and was at second reading when this page was written"*; if it receives royal assent the page is wrong about the most load-bearing fact on it. **(b) the Ontario regulation under `Electricity Act` s. 28.1** — `/practice/energy/` says it *"had not been made as of August 2026"*. **(c) the ERO 026-0853 consultation**, comment period to **12 September 2026**. **(d) the Tribunals Ontario annual report** — `/practice/insurance/` publishes FY2024-25 figures and the extract records that a 2025-26 edition was never ruled out. **(e) the SABS**, amended with effect 1 July 2026. **(f) the ADRIC National Mediation Rules**, under review by ADRIC's own committee. **(g) ADRIC's Code of Ethics** — added 2026-08-30, build step 6. `/process/` §Confidentiality quotes it verbatim from `docs/reference/adr-institution-names.md` (retrieved 2026-08-29) **with a live link to ADRIC's page**, which is what makes it checkable and also what makes a stale quotation visible. It is the slowest-moving item here — a professional code, not a bill — so it does not change the cadence; it is listed because the trigger below says "all six" and there are now seven. **THE TRIGGER: re-check all seven extracts before any cutover, and before any republish that turns on one of them — the same event trigger R10 uses.** Then re-stamp the extract. **A page that was true when it was written and is false when it is read is still a false page**, and this is the first change set on the project to put that class of fact into public copy at volume | 2026-08-29 | Six sentences, six files, one retrieval date. Nothing here fires on its own; a fact with a shelf life and no owner is exactly what §12 exists for | | R19 | ⚠️ **DYNAMODB TTL BACKS A PUBLISHED PRIVACY PROMISE AND `/legal/privacy/` ASSERTS THE MECHANISM, NOT JUST THE PERIOD.** **§7 records the status and its stamp; this row deliberately does not restate it** — one place for a service status, or the copy that goes stale is the one nobody re-reads. **THE TRIGGER, and its two halves are not interchangeable: re-run `describe-time-to-live` and confirm `ENABLED`, THEN write a record with a near-future `ttl` and confirm it actually disappears.** `ENABLED` proves the setting; only the test record proves the behaviour. Writing the attribute proves neither — the handler's side is verified and is not what this row is about. Both halves are on `docs/06`'s cutover checklist and the question is §9 Q60. Re-stamp §7 the same day, **and when you do, sweep for the copies: this fact reached five files outside §7 in one change set and had to be pulled back.** Close this row only when the test record has been observed to vanish | 2026-08-31 | **This is R9's exact shape at higher stakes.** R9 exists because the SES alarms are configured and notify nobody until one subscription is confirmed — a control that reads as covered and is not. Here the control backs a **statement to the public on a privacy policy**, which is the one class of claim this project treats as unrecoverable, and the failure is silent in both directions: nothing in the repo, the build or AWS reports that records are accumulating forever. A cutover checklist fires once; §12 is read aloud every session | | R20 | ⚠️ **THE SEVENTH NAV ITEM ARMS TWO MEASURED HEADER DEFECTS, AND ITS TRIGGER IS A CONTENT EVENT RATHER THAN A DATE.** `SiteHeader` computes `showInsights` from the collection — Insights joins the masthead **automatically at two published articles** — so nothing in the build, the specs or a person's memory stands between publishing article #2 and arming both of these. With seven items **and fallback font metrics** (what a reader on `docs/04`'s Slow 4G profile sees during the `font-display: swap` window, at the DEFAULT text size, no reader setting involved) the header measures **141 px across a contiguous 1056–1091 px band** instead of 81 px: **(a)** it then collapses **60 px** when Geist swaps in, on all 22 pages, against the CLS < 0.05 budget; and **(b)** 141 px exceeds the 97 px `scroll-padding-top`, so "Skip to content" lands with **44 px of `#main` behind the sticky header** — and (b) is **new as of 2026-09-01**, the previous build's 86.97 px stayed under 97 px and covered 0. ⚠️ **HARDENED FROM A TRIGGER INTO A GATE — Pouya's ruling, 2026-09-01: NO SEVENTH NAV ITEM SHIPS UNTIL THE FALLBACK-METRICS DEFECT IS FIXED.** So fixing it is a **prerequisite of publishing the second Insights article**, not a follow-up to it, and *"font metric overrides on the fallback face or equivalent — to be designed then, not now"*. ⚠️ **AND THE GATE IS A BUILD FAILURE, NOT A CROSS-REFERENCE — corrected 2026-09-01 by `adversarial-reviewer`, round 2, in the same session that wrote the weaker version.** It was first implemented as three prose pointers, justified with the claim that the comment on `showInsights` in `SiteHeader.astro` is *"the only one of the three a person editing an article's front matter is likely to be reading"*. **That was backwards**: someone editing `src/content/insights/*.mdx` has no reason to open a header component. And it did not gate: with two articles flipped to `draft: false`, `npm run build` succeeded and `check`, `check:claims`, `og:proof`, `check:intake` and `lint` all exited 0 while both defects shipped. **`SiteHeader.astro` now THROWS when `published.length >= 2`**, with the measurements and the instruction in the message; it fires on both deploy paths, on the machine of whoever publishes. **Proven, not assumed:** two articles were temporarily published, `npm run build` exited **1** naming R20, and the files were restored and the restoration verified by `git diff --exit-code` plus an unchanged `dist` digest. The prose pointers remain — `docs/06`'s `/insights/` state item and its seventh-nav-item item under **Technical**, the latter deliberately unticked and marked NOT a cutover blocker — but they document the gate rather than being it. This project already knew the remedy: `content.config.ts` refuses `draft: false` without `reviewedByPouya: true` rather than trusting a comment, and `check:intake`/`og:proof` exist because a duplicated fact needs a mechanism. *Previous wording follows, and it was too weak: it asked for a re-measurement and a ruling at publication time, which leaves the defect shipping if the person publishing does not read this file.* **THE TRIGGER: before publishing the second Insights article, re-measure the masthead with seven items under blocked webfonts, and rule.** The two candidate fixes are raising the desktop breakpoint past 1091 px — which changes the normal-settings layout in that band — or giving Geist a metric-matched `size-adjust` fallback; both are outside the scope the header step was given, and both close (a) and (b) together. **Why this is a §12 row and not only a `docs/06` line:** a cutover checklist fires once, at cutover, and this arms itself later, on an editorial decision taken by someone who will not be reading the deployment spec. `docs/02` §Reflow carries the measurements | 2026-09-01 | It is latent today and invisible from inside the repo: six nav items never wrap, so every check passes, and the defect appears the day a second article ships. That is R13's shape — a temporary state that becomes permanent because nothing prompts anyone — with the added twist that the prompt would have to fire on a content event. Raised by `adversarial-reviewer`, round 2 | -| R21 | 🛑 **`/legal/privacy/` PUBLISHES FOUR CLAIMS ABOUT SYSTEMS OUTSIDE THIS REPOSITORY, AND NOTHING IN AWS, GOOGLE WORKSPACE, THE BUILD OR THIS REPO REPORTS WHEN ANY OF THEM CHANGES.** ⚠️ **RE-SCOPED 2026-09-02 BY THE Q63 RULING, AND THE HEADLINE CLAIM IT WAS WRITTEN FOR IS GONE:** the page no longer publishes a **count of people** — Pouya ruled that a simulation counts identities and not humans, so *"two people can"* came off and *"the account's administrators — me, and the small number of people who administer it with me"* went on. **That is a weaker claim and therefore a more durable one: adding an administrator no longer falsifies the page.** The four live claims: **(i)** that every user and every role was enumerated and only administrative identities can read the table; **(ii)** that the writing function cannot read it back and the deploy credential has no access at all; **(iii)** that the account's root credential has no programmatic key and Pouya holds it — ⚠️ **held, not held EXCLUSIVELY: nothing measured or attested rules out a second holder, and §9 Q64 is the one line that would settle it**; **(iv)** that `info@smlcompany.ca` is read by Pouya and administrative staff; **(v)** that the table carries no resource-based policy of its own and the account has no single sign-on or federated login. **(iv) is an ATTESTATION and nothing in this repo can check it** — the other three are re-runnable. **Attach a DynamoDB policy to any role, grant the deploy or Lambda role a read, **put a resource-based policy on the table itself** (invisible to `describe-table` and to every principal simulation — it grants from the other side, and it is claim (v) below), **join the account to an AWS Organization** (which would make the Identity Center zero local rather than conclusive), create a root access key, move root custody away from Pouya, delegate the mailbox more widely, or resolve Q23's Gitea dependency by changing `lars`'s access — and the privacy policy becomes false with every check still green.** Original text follows. **THE PAGE SAID "TWO", MEASURED (§7).** **Add a third administrator, remove `lars` from `admins`, attach a DynamoDB policy to any of the 33 roles, **hand the root credential to a third person**, or resolve Q23's Gitea dependency by changing his access — and the privacy policy becomes false with every check still green.** `check:claims`'s `sole-administrator-q62` pattern does **not** cover this: it bars the OLD false shape from returning and is blind to the world moving under the NEW sentence. That asymmetry is the whole reason this row exists. **THE TRIGGER, and it is the same event trigger R10 and R18 use: re-run the verification in `docs/reference/intake-table-access-verification.md` before any cutover, and before any republish that turns on it. Then re-stamp §7 the same day.** The counts are the assertion — seven decisions per role call, six per CDK-path call, two per-resource decisions per assume call — because a call that silently received one bogus action name answers `implicitDeny` and reads exactly like a clean row, which is how the first run of that sweep produced 22 uniformly clean rows and no measurement at all. **Removal is the live direction:** Q23 records the Gitea instance as jointly administered and blocked on its second administrator, so `lars`'s access is plausibly load-bearing elsewhere — and if it goes, `check-claims.mjs`'s `rule:` line carries the instruction (rewrite the page, then narrow the pattern deliberately). Raised by `adversarial-reviewer`, D20 cutover pass round 1, 2026-09-02: R9's and R19's shape at R19's stakes — a statement to the public on a privacy policy, backed by a fact with no owner. | 2026-09-02 | The 2026-09-01 verification is a photograph of a shared AWS account that two people administer and that runs four other projects. A stamp with no trigger behind it goes stale silently, and §4 already records OCNI as the precedent for exactly that | +| R21 | 🛑 **`/legal/privacy/` PUBLISHES CLAIMS ABOUT SYSTEMS OUTSIDE THIS REPOSITORY, AND NOTHING IN AWS, GOOGLE WORKSPACE, THE BUILD OR THIS REPO REPORTS WHEN ANY OF THEM CHANGES.** ⚠️ **RE-SCOPED AGAIN 2026-09-02 BY POUYA'S MECHANICS RULING — AND READ THE NEXT SENTENCE BEFORE TREATING THAT AS RELIEF. THE LIVE CLAIMS ARE NAMED, NOT COUNTED**: the headline of this row said FOUR over a list of five, then TWO over a list of three, in successive versions of the row whose whole subject is a fact going stale unnoticed (`adversarial-reviewer`, rounds 1 and 2). **What `/legal/privacy/` publishes now, in full:** (1) that the record in the table can be read by Pouya and the small number of people who administer the account it sits in with him; (2) that the receiving system can only add a record and cannot read the table back — **(ii)**'s first half; (3) that `info@smlcompany.ca` is read by Pouya and administrative staff — **(iv)**; and (4) that the table sits in an Amazon Web Services account that also runs systems unrelated to this practice, in §Where it is stored. **Deleted from the page and published nowhere now: (iii) root custody, (v) the single-sign-on and resource-policy findings, (ii)'s second half — the deploy credential's lack of access — and (i)'s recital of the method.** ⚠️ **THE FALSIFIERS BELOW ARE UNCHANGED AND SO IS THE TRIGGER.** Every deleted sentence is still asserted by **§7**, still cited by `docs/06`, and still what `docs/reference/intake-table-access-verification.md` exists to prove. **A claim moved off a public page into a register is still a claim — and it is one fewer reader likely to notice it going stale.** What genuinely improved: several falsifiers can now only make a *record* false rather than a public page. Original scoping follows, kept in full because §7 still asserts every one of these. ⚠️ **RE-SCOPED 2026-09-02 BY THE Q63 RULING, AND THE HEADLINE CLAIM IT WAS WRITTEN FOR IS GONE:** the page no longer publishes a **count of people** — Pouya ruled that a simulation counts identities and not humans, so *"two people can"* came off and *"the account's administrators — me, and the small number of people who administer it with me"* went on. **That is a weaker claim and therefore a more durable one: adding an administrator no longer falsifies the page.** The five claims as scoped before the mechanics cut: **(i)** that every user and every role was enumerated and only administrative identities can read the table; **(ii)** that the writing function cannot read it back and the deploy credential has no access at all; **(iii)** that the account's root credential has no programmatic key and Pouya holds it — ⚠️ **held, not held EXCLUSIVELY: nothing measured or attested rules out a second holder, and §9 Q64 is the one line that would settle it**; **(iv)** that `info@smlcompany.ca` is read by Pouya and administrative staff; **(v)** that the table carries no resource-based policy of its own and the account has no single sign-on or federated login. **(iv) is an ATTESTATION and nothing in this repo can check it** — the other three are re-runnable. **Attach a DynamoDB policy to any role, grant the deploy or Lambda role a read, **put a resource-based policy on the table itself** (invisible to `describe-table` and to every principal simulation — it grants from the other side, and it is claim (v) below), **join the account to an AWS Organization** (which would make the Identity Center zero local rather than conclusive), create a root access key, move root custody away from Pouya, delegate the mailbox more widely, or resolve Q23's Gitea dependency by changing `lars`'s access — and the privacy policy becomes false with every check still green.** Original text follows. **THE PAGE SAID "TWO", MEASURED (§7).** **Add a third administrator, remove `lars` from `admins`, attach a DynamoDB policy to any of the 33 roles, **hand the root credential to a third person**, or resolve Q23's Gitea dependency by changing his access — and the privacy policy becomes false with every check still green.** `check:claims`'s `sole-administrator-q62` pattern does **not** cover this: it bars the OLD false shape from returning and is blind to the world moving under the NEW sentence. That asymmetry is the whole reason this row exists. **THE TRIGGER, and it is the same event trigger R10 and R18 use: re-run the verification in `docs/reference/intake-table-access-verification.md` before any cutover, and before any republish that turns on it. Then re-stamp §7 the same day.** The counts are the assertion — seven decisions per role call, six per CDK-path call, two per-resource decisions per assume call — because a call that silently received one bogus action name answers `implicitDeny` and reads exactly like a clean row, which is how the first run of that sweep produced 22 uniformly clean rows and no measurement at all. **Removal is the live direction:** Q23 records the Gitea instance as jointly administered and blocked on its second administrator, so `lars`'s access is plausibly load-bearing elsewhere — and if it goes, `check-claims.mjs`'s `rule:` line carries the instruction (rewrite the page, then narrow the pattern deliberately). Raised by `adversarial-reviewer`, D20 cutover pass round 1, 2026-09-02: R9's and R19's shape at R19's stakes — a statement to the public on a privacy policy, backed by a fact with no owner. | 2026-09-02 | The 2026-09-01 verification is a photograph of a shared AWS account that two people administer and that runs four other projects. A stamp with no trigger behind it goes stale silently, and §4 already records OCNI as the precedent for exactly that | | ~~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 | — | @@ -946,6 +948,276 @@ never being raised again. # Change Log +## 2026-09-02 (ap) — `/legal/privacy/` §Who can see it is cut to four plain statements and the mechanics move to the evidence file; the consent checkbox names SML Company Ltd; Q64 closes MOOT rather than answered + +**Two rulings from Pouya, 2026-09-02.** **(1)** §Who can see it **stays +generic**: *"It over-explains technical mechanics that belong in the evidence +file, not in front of an inquirer."* **(2)** The `/contact/` consent string +**names the corporation**. And **(3)**, on process: the §Who can see it approval +closes **via the page read-through** — *"do not hold anything open waiting on a +separate wording approval; the read-through is the approval."* + +### 1. The section is four statements + +**Deleted from §Who can see it:** the measurement paragraph, the root-credential +sentence, the single-sign-on and federated-login enumeration, the resource-policy +clause, the *"company that runs a database"* aside, the deploy-credential +sentence and the three-copies summary. **That list is now identical in all four +records that carry it, asserted mechanically at 7/7 each** — see §5(b). The +shipped section, verbatim from `dist/legal/privacy/index.html`: + +> The record in the table: me, and the small number of people who administer the +> account it sits in with me. + +> The system that receives what you send **can only add a record — it cannot read +> back what is stored.** + +> The notification goes to the practice's mailbox, which is read by me and by +> administrative staff and is hosted on Google Workspace — so Google holds a copy +> of whatever you send me. + +> The confirmation that went to you sits with whoever runs your email. That copy +> is in your hands rather than mine. + +**Nothing was retracted.** Every deleted fact is unchanged, still measured and +still asserted — by **§7**'s two rows and by +`docs/reference/intake-table-access-verification.md`, whose shipped-sentence +block is re-synced and now maps each of the four sentences to what it rests on. + +⚠️ **AND THAT RAISES THE STAKES ON §7 RATHER THAN LOWERING THEM.** A claim moved +off a public page into a register is still a claim — and it is one fewer reader +likely to notice it going stale. §12 **R21** is re-scoped and **its falsifiers +and its trigger are unchanged**; what genuinely improved is that several of them +can now only falsify a record rather than a live page. **R21 now names its live +claims instead of counting them** — its headline said FOUR over a list of five, +then TWO over a list of three, in successive versions of the row whose whole +subject is a fact going stale unnoticed. + +### 2. Two sentences the ruling did not ask for, both added under review + +**(a) The shared-account disclosure came back, to §Where it is stored.** *"The +table sits in an Amazon Web Services account that also runs systems unrelated to +this practice."* It was cut with the mechanics; **the ruling never named it, and +it is a storage disclosure rather than a method.** With it gone, `grep -rl +unrelated dist/` returned nothing: no page told a reader that their intake — +opposing parties and counsel included — sits in an account shared with unrelated +production systems. `docs/05` §Privacy policy must state asks for exactly this. + +**(b) The policy now names the party the consent box names.** *"The wording you +agree to is on the form itself, and it names **SML Company Ltd**, the company +that holds this practice's systems."* Without it a submitter consented to a +company the linked policy never mentioned once — an accountability gap under +PIPEDA rather than a question of voice, and one this change set created. It says +**holds the systems** and stops: the site publishes the relation as *alongside* +on `/about/` and `/practice/shareholder/`, and *operates* would contradict both. + +### 3. Q64 closes MOOT — and moot is not answered + +**The paragraph it was about was deleted, so it gates nothing.** The underlying +gap is exactly as open as it was: §7 records root as *held by Pouya*, which is +not *held only by Pouya*, and root is not an IAM principal and cannot be +simulated. **Nothing about root custody may be published without asking again**, +and the question is not *who holds root* — that is answered — but ***whether +anyone else does***. Recorded in three places: §7's row, the evidence file's +addendum, and the section comment in `src/pages/legal/privacy.astro`. + +**Three distinct ways a question left §9 in one day — answered (Q63), struck +(Q62), moot (Q64) — and all three look identical in a count.** `docs/06`'s +callout says so where the count lives, and it no longer states how many times its +own number has moved: a tally of how often a tally changed is the same trap one +level up. + +### 4. The consent string, and the two §4 rows the copy rests on + +`src/data/intake.ts` and `docs/05` §Consent text both move and are proven +byte-identical by parsing both (a deliberate duplicate with no `check:` script +over it). Two new Verified rows, `[verified 2026-09-02 — Pouya]`: + +- **SML Company Ltd operates the practice and holds its systems.** ⚠️ The row + above says ***alongside*** and this one says ***through***; Q49(b) was + **declined** on 2026-08-28 for exactly that gap. **Recorded rather than merged, + and Q49(b) is not reopened** — nothing published turns on the relation, and + reconciling two rows to unlock a graph field is how a struck permission got + back into §4 once already (the D16 precedent). The row now also names the two + pages that *do* state the relation, both as *alongside*. +- **A small number of people administer this practice's systems alongside + Pouya.** ⚠️ **It verifies *administer the systems*, not *run the practice*.** + +### 5. Review — `adversarial-reviewer`, two rounds, per D19/D20 + +`claims-auditor` did **not** run: D20 puts it once, at cutover, over the whole +finished site. **14 findings, all 14 resolved, none declined.** ⚠️ **Nine of +round 2's ten were defects in round 1's own repairs**, which is the measurement +D19's cap is built on — and one of them is the single most useful finding in this +entry, so the second round earned itself again. + +**Round 1 — six findings, one blocking.** + +**(a) BLOCKING — the page claimed a group of people "run this practice", and §4 +verifies no such thing.** Sentence 1 shipped as *"The people who run this +practice can — me, and the small number of people who administer its systems with +me."* That subject is Pouya's own phrasing from the ruling, and **taking it +verbatim into copy was still wrong**, on the ruling's own constraint that +*nothing new may be asserted*: a §4 sweep for `staff|assistant|team|colleague| +employee` returns **zero**. Narrow, it says a co-administrator of an account §10 +records as running four unrelated production systems is a **principal of this +practice** — the fabricated-founder class. Broad, it sweeps in the administrative +staff named two paragraphs down, **who read the mailbox and cannot read the +table**. *Q63's own error in a new direction: Q63 struck "Two people can" for +reading IAM identities as humans, and this read them as principals.* + +**(b) The four records of what was deleted named four different sets** — and the +narrowest was the restoration bar in `privacy.astro`, the one an implementer +actually reads. + +**(c) `docs/05`'s definition-of-done item described copy that no longer exists** +— an `[x]` an operator ticks at cutover, carrying its own warning that this had +happened to it once already. The change set had edited that file for the consent +string and not swept it. **The same file, the same failure, three lines apart.** + +**(d) §9's Q62 row published `35 approved strings` / `first seven`** against a +script printing 33 / five — one sentence after the same row ruled the printed +numbers authoritative. Both numbers deleted rather than corrected. + +**(e) The consent named a company the policy never mentioned**, and its rationale +comment, in three copies, cited a page description this change set had deleted. + +**(f) Consider — comment volume exceeded the code in all three source files.** + +**Round 2 — eight findings, two blocking, and nine of the ten sub-parts were +mine from round 1.** + +**(g) BLOCKING — three records quoted the page as saying a sentence it does not +say, and it was the predicate §4 had just barred.** Round 1's fix reached +`docs/05` and the page and **missed §7, R21 and the evidence file** — including +the block captioned *"The shipped sentences … so this file can be compared +against the live page rather than against a struck one"*, which was quoting a +struck one, in the one artefact `docs/06`'s unticked human-pass blocker sends +Pouya to. **The correction then had to be made a second time**, because the +round-1 replacement was itself superseded by (i) below: sentence 1 moved **four +times in one day**, and §7 now says in terms that nothing outside `dist/` is a +safe source for that quote. + +**(h) BLOCKING — `docs/05` §DynamoDB still asserted the Q62 falsehood.** *"Table +access limited to the Lambda role and one named administrative principal"* — +false on both halves, in the spec `docs/01` says the privacy page must match, and +**`check:claims` carries that very sentence as a string that reached `dist/`.** +Pre-existing, and in scope because this change set's own checklist item claims the +`docs/` sweep was complete. Struck; the file now cites §7 rather than restating +it — the SES-DKIM rule, one more time. + +**(i) §Who can see it answered its own heading with a set narrower than the +truth.** Sentence 1 excluded the administrative staff sentence 3 names, because +the scoping clause that used to draw that distinction went out with the +mechanics — while §Where it is stored still promises the distinction is drawn +there. And *"this practice's systems"* was a **third** set, matching neither §7's +measurement nor Pouya's attestation. Fixed with one clause rather than a restored +paragraph: **"The record in the table: me, and the small number of people who +administer the account it sits in with me."** + +**(j) The new §4 row's own cautions were false about the shipped pages** — it +said the relation is described *"on any page"* by nothing, with two counter- +examples shipping, and that the section rests *"on this row and on nothing else"*, +where the evidence file maps four sentences to four sources. + +**(k) Three statements wrong by count or scope** — §7's *"that one sentence is +all the page says"* (false twice over), R21's headline count, and §9's *"names all +NINE places"* against a comment naming ten and giving no count. + +**(l) The evidence file's own edit broke twice** — a corrected seven-item list +**appended to** the four-item list it replaced, one sentence above *"these lists +must stay identical"*; and *"the second of those sentences"*, a pointer indexing +the quote block **by position** after the block changed length. + +**(m) Comment volume again.** Trimmed: §Who can see it 35 → **27** lines, +`CONSENT_TEXT` 19 → **17**, the fixture comment 14 → **12**. The restoration bar +grew rather than shrank, deliberately — finding (b) is what it exists to prevent. + +### 6. Two deviations from the ruling as dictated, both a one-line overrule + +**(a) The deploy-credential clause is gone, and it was not on the delete list.** +The ruling gave a *positive* specification — *"roughly four short statements"*, +enumerated (a)–(d) — and *"the credential that publishes this website has no +access to the table at all"* is in neither that list nor the delete list. It was +read as mechanics of the kind the ruling removed, and cut. It is true, favourable +and measured (`adr-sml-deploy` is `implicitDeny` on all seven actions); it is +kept in §7 and flagged in the evidence file as **NO LONGER ON THE PAGE**. + +**(b) The ruling's noun was changed.** Limb (b) reads *"the form that receives +your message can only add a record"*. The HTML form does not receive anything and +does not write records — the Lambda behind it does — so shipping that noun would +have put an inaccuracy in a legal document. It ships as **"The system that +receives what you send"**. Substance unchanged; one word deliberately not his. + +*(And sentence 1's subject is no longer his wording either — see §5(a) and (i). +That is not a third deviation but the same ruling applied to itself: it required +that nothing new be asserted, and his phrasing asserted something §4 does not +carry.)* + +### 7. Verification — every exit status read, nothing truncated, nothing suppressed + +`check` **0** (61 files, 0 errors / 0 warnings / 0 hints) · `build` **0** (23 +pages) · `check:claims` **0** (self-test: 12 patterns, **33** approved strings) · +`check:intake` **0** (12/12 fields) · `og:proof` **0** · `lint` **0** · +`lighthouse` **0**, worst of 23 **99 / 100 / 100 / 100**, CLS 0.000, +`/legal/privacy/` **100 / 100 / 100 / 69n**, `/contact/` **100 / 100 / 100 / +100**. Minifier grep for a folded `animation` shorthand: **exit 1, clean**. 23 +pages, **1039 internal references, 0 unresolved**; **0 `.js` in `dist`**. + +**The tripwire proven both ways, as the ruling required, and re-proven after each +review round.** **Exit 0** on the revised page. **Exit 1 with 5 matches** on the +pre-correction bytes rebuilt from `bd282aa` into a scratch tree — +`legal/privacy/index.html:54, 67, 67, 68, 72`, the same five at the same lines +each time. ⚠️ **One of those runs first returned exit 2, not 1** — `check-claims` +refusing a `dist/` older than `src/`, correct behaviour triggered by editing +source after building the scratch tree. The scratch build's content was therefore +proved **independently of its mtime**, by grepping both struck clauses in the +built HTML, before timestamps were cleared and the scanner re-run. **The regex +was not touched**; only negative fixtures moved, which the script's own comment +requires whenever that copy changes. + +**Sweeps, with the commands, because recall is not evidence.** + +- **Every variant of the first sentence, repo-wide**, five struck forms across + `src/`, `docs/`, `scripts/`, `backend/`, `AGENTS.md` and `CLAUDE.md`, each hit + printed with its file and line and classified live-record vs. Change Log + against the first `## ` heading. **In `dist/`: the shipped sentence + present, all five struck forms at 0.** In the repo, the survivors are §4's bar + and §9's closed rows, where they are quoted *as struck* — which is the point of + a register. ⚠️ **The first pass of this sweep found four more carriers after + the "fix" was already applied**, which is finding (g). +- **The change-together list asserted in both directions:** 10 phrases, **0 + missing** from the page; and every paragraph of §Where it is stored (5) and + §Who can see it (4) covered — **0 unlisted**. A list that is complete one way + and not the other is how the last five partial sweeps passed. +- **The canonical deletion list: 7/7 items present in each of the four records.** +- **Every who-stores-the-data claim in `dist/`**, by iterating match positions in + Python rather than `grep -o` with a context window — the enumeration failure + `CLAUDE.md` records. `'storing'`: **1**, the consent line. `'consent to Pouya + Lajevardi'`: **0**. +- **`CONSENT_TEXT` asserted string-equal to `docs/05`** by parsing both. +- **`TODO(pouya):` in `src/`: exactly one**, Q60's. **0 in `dist/`.** +- **`AGENTS.md` table integrity**, escaped `\|` handled: **1 malformed row, + pre-existing at `99889a3` and inside the Change Log. Delta 0.** + +⚠️ **AND ONE INSTRUMENT FAILED LOUDLY MID-SWEEP, WHICH IS THE SURVIVABLE HALF.** +A context-window `grep` returned nothing over four files; run without +`2>/dev/null` it was **exit 2, `ugrep: error: … exceeds complexity limits`** — +the pattern never compiled, and the empty result would have read as "no stale +quotes anywhere". Re-run in Python; three corrections came out of it. **A second +pass hit `UnicodeDecodeError` on a binary file and aborted mid-sweep after +printing two clean-looking rows** — the same shape from the other side, and the +reason the final sweep counts and reports the files it could not read (25). + +### 8. What is now open, and it is two things + +**Q60's TTL waiting period** — the only blocker that is a waiting period rather +than a task, so it starts first — and **Pouya's page read-through**, which +`docs/06`'s callout now carries as blocker 2 rather than leaving on the checklist, +because that is where the last reserved approval went missing. **Nothing else +code-side stands between this and a deploy.** `/legal/privacy/` carries one +`TODO(pouya)`, Q60's, and `docs/06` bars a shipped page with one. + ## 2026-09-02 (ao) — Q63 is answered in three limbs and the answer to (c) takes the human headcount off the page; R10 fires and is satisfied; `/med-arb/` is ratified; and a sentence added to back the correction turned out to have no command behind it **Pouya's rulings, 2026-09-02**, applied here: **Q63(a)** wording approved with diff --git a/docs/05-backend-spec.md b/docs/05-backend-spec.md index ddedc98..2c59c05 100644 --- a/docs/05-backend-spec.md +++ b/docs/05-backend-spec.md @@ -146,7 +146,7 @@ might reasonably treat as privileged. The intake call is for that. ### Consent text -> I consent to Pouya Lajevardi storing and using the information in this form to +> I consent to SML Company Ltd storing and using the information in this form to > respond to my inquiry and to run a conflicts check. I understand that > submitting this form does not create a retainer, does not appoint a neutral, > and does not itself establish a mediator–party relationship. @@ -216,8 +216,16 @@ against this row. | `ttl` | epoch seconds — **the input to automatic deletion; see §Retention for why writing it is not the mechanism** | **Encryption at rest** with a customer-managed KMS key. **Point-in-time recovery -on.** Table access limited to the Lambda role and one named administrative -principal. +on.** ⚠️ **THE THIRD LINE HERE WAS *"table access limited to the Lambda role and +one named administrative principal"*, AND IT WAS THE Q62 FALSEHOOD — struck +2026-09-02.** It is false on both halves: `adr-intake-lambda-role` holds +`PutItem` **only** and cannot read the table at all, and access is not one +principal. **`AGENTS.md` §7's `Intake table — who can read it` row is the answer +and this spec does not restate it** — a duplicated fact is one that goes wrong in +the copy nobody re-reads, which is what happened here: the Q62 sweep ran over +`src/` and never reached a spec, and `check:claims` carries this exact sentence +as a string that reached `dist/`. It survived the sweep this file's own +definition-of-done claims to have completed (`adversarial-reviewer`, round 2). ⚠️ **TWO OF THOSE THREE ARE THE STATE OF THE RUNNING TABLE AND ONE IS NOT.** PITR is **on** `[verified 2026-09-01 — describe-continuous-backups, @@ -446,7 +454,7 @@ Plausible or Fathom, cookieless, no consent banner. - [ ] **TTL set and verified by test record.** ⚠️ **THIS ONE BACKS A PUBLISHED PROMISE.** `/legal/privacy/` states that records are deleted automatically after 24 months, and it asserts the **mechanism**, not only the period. The handler writes the `ttl` attribute — epoch seconds, 24 months, confirmed against this spec `[verified 2026-08-31]` — and **writing the attribute is not the mechanism**: TTL must also be enabled on the table, which is a table setting the code cannot see. **`AGENTS.md` §7 holds that status and its stamp; this line does not restate it** — it restated it once, went stale within the day, and had to be pulled back (§12 R19). **The test record is what closes this item, not the status:** `ENABLED` proves the setting, a record written with a near-future `ttl` and observed to vanish proves the behaviour. Tracked as §9 Q60 - [x] **PITR enabled** — `ENABLED`, 35-day window `[verified 2026-09-01 — describe-continuous-backups]` - [ ] KMS customer-managed key. **Not on the table: encryption at rest is with the AWS-owned key** `[verified 2026-09-01 — describe-table returns no SSEDescription]`. **Not claimed on `/legal/privacy/`** — the page says "encrypted at rest", which is unconditionally true of every DynamoDB table and does not mention a customer-managed key, so nothing published depends on it. An improvement, not a blocker -- [x] ✅ **Table access matches what `/legal/privacy/` says about it — 2026-09-02.** **The access is unchanged; the page now states it.** Pouya ruled *state the truth* rather than *remove the access* (§9 Q62), so the page attributes read access to **the account's administrators of a shared account, with no human headcount** — the count came off later the same day under §9 Q63, because a simulation counts identities and the page was reading them as people — and adds the two stronger facts the false sentence had crowded out: the handler role holds `PutItem` **only**, and `adr-sml-deploy` is `implicitDeny` on all seven read **and** write actions. Evidence and commands: `docs/reference/intake-table-access-verification.md`, whose enumeration was **extended on 2026-09-02** — the original screened roles by `list-attached-role-policies` alone, missing that 23 of 26 non-service-linked roles carry inline policies and that the two CDK `lookup` roles can read the table. Four roles can, not two; every one of them is reachable only by those administrators. ⚠️ **Do not restate that as a count of PEOPLE** — this line said *"all four terminate at the same two people"* until 2026-09-02, which is the inference §9 Q63 struck. ⚠️ **THIS LINE SAID "IT DOES NOT" FOR A DAY AFTER THE PAGE WAS CORRECTED, AND IT IS A DEFINITION-OF-DONE LIST SOMEONE FOLLOWS AT CUTOVER** — the Q62 sweep was run over `src/` only, so it could not reach a spec. `adversarial-reviewer`, round 1. The sweep across `docs/` is in the Change Log entry +- [x] ✅ **Table access matches what `/legal/privacy/` says about it — 2026-09-02.** **The access is unchanged; the page now states it.** Pouya ruled *state the truth* rather than *remove the access* (§9 Q62), so the page states the truth about access rather than a false exclusivity. ⚠️ **WHAT IT STATES CHANGED TWICE MORE THAT DAY AND THIS LINE IS WRITTEN AGAINST THE SHIPPED BYTES, NOT AGAINST THE RULING.** §9 Q63 took the human headcount off (a simulation counts identities and the page was reading them as people), and a second ruling then cut §Who can see it to **four plain statements**. The page now says: *"The record in the table: me, and the small number of people who administer the account it sits in with me"*; that the receiving system *"can only add a record — it cannot read back what is stored"*; where the notification goes and who reads it; and that the confirmation sits with the reader's own provider. **§Where it is stored carries the shared-account disclosure** — *"an Amazon Web Services account that also runs systems unrelated to this practice"*. ⚠️ **`adr-sml-deploy` is `implicitDeny` on all seven read AND write actions — MEASURED, TRUE, AND NO LONGER ON THE PAGE**; it went with the mechanics cut and it is §7's claim now, not the policy's. Do not tick this item against a page that states it. Evidence and commands: `docs/reference/intake-table-access-verification.md`, whose enumeration was **extended on 2026-09-02** — the original screened roles by `list-attached-role-policies` alone, missing that 23 of 26 non-service-linked roles carry inline policies and that the two CDK `lookup` roles can read the table. Four roles can, not two; every one of them is reachable only by those administrators. ⚠️ **Do not restate that as a count of PEOPLE** — this line said *"all four terminate at the same two people"* until 2026-09-02, which is the inference §9 Q63 struck. ⚠️ **THIS LINE SAID "IT DOES NOT" FOR A DAY AFTER THE PAGE WAS CORRECTED, AND IT IS A DEFINITION-OF-DONE LIST SOMEONE FOLLOWS AT CUTOVER** — the Q62 sweep was run over `src/` only, so it could not reach a spec. `adversarial-reviewer`, round 1. The sweep across `docs/` is in the Change Log entry - [ ] Both emails send; SPF/DKIM/DMARC aligned; inbox-tested, not spam-tested - [ ] **CloudWatch alarms on Lambda `Errors` and API Gateway `5xx`** — replacing the DLQ item, which is struck: a DLQ on a **synchronously** invoked function never receives anything, so the alarm on its depth would have been permanently green. See §Notification. The handler writes to DynamoDB **before** sending mail, so the protection this item was pointing at is in the code rather than in a queue - [x] **Form usable by keyboard only.** Errors are announced by the browser's own validation, which with no script is the only thing that can announce them inline — `role="alert"` needs a live region and something to write into it diff --git a/docs/06-deployment.md b/docs/06-deployment.md index 2ef481f..3a86f6b 100644 --- a/docs/06-deployment.md +++ b/docs/06-deployment.md @@ -396,18 +396,23 @@ Then invalidate `/*`. > deployment takes. > 🛑 **TWO THINGS BLOCK THIS ENTIRE LIST AS AT 2026-09-02: ONE WAITING PERIOD -> AND ONE LINE FROM POUYA.** +> AND ONE READ-THROUGH.** > -> ⚠️ *(The count has moved twice in one day and the DIRECTION is what to read. -> It said ONE for part of 2026-09-02 and that was a **defect** — the wording -> approval Pouya reserved had been recorded only inside records marked closed, -> the `TODO(pouya)` deleted, Q62 struck, this callout ticked, so nothing would -> have stopped unapproved copy publishing (`adversarial-reviewer`, D20 pass -> round 1). Q63 was then **answered** in three limbs by ruling, which is a gate -> closed by an answer rather than by deletion. Answering it opened **Q64**, one -> paragraph lower on the same page. **A question that closes and a question that -> is deleted look identical in a count and nowhere else, which is why the count -> is never the record.**)* +> ⚠️ *(The count has moved repeatedly in one day and the DIRECTION is the only +> part worth reading — the number of moves is deliberately not stated, because a +> tally of how often a tally changed is the same trap one level up. It said ONE for part of 2026-09-02 and that was a +> **defect** — the wording approval Pouya reserved had been recorded only inside +> records marked closed, the `TODO(pouya)` deleted, Q62 struck, this callout +> ticked, so nothing would have stopped unapproved copy publishing +> (`adversarial-reviewer`, D20 pass round 1). Q63 was then **answered** in three +> limbs by ruling, which is a gate closed by an answer rather than by deletion — +> and answering it **opened Q64**, one paragraph lower on the same page. Q64 then +> left the list a **third** way: **the paragraph it was about was deleted**, so +> the question is moot rather than answered. **Closed, deleted, and moot look +> identical in a count and nowhere else, which is why the count is never the +> record.** The second slot is no longer a question at all — it is the human +> pass, promoted here from the checklist below because that is where the last +> reserved approval went missing.)* > > 1. **Q60 — the retention MECHANISM has still not been observed.** TTL is > `ENABLED` and no record has been watched to disappear, and @@ -416,15 +421,23 @@ Then invalidate `/*`. > record is written and it does not call failure before **7 days**, so > **start it before anything else on this page.** It is the one blocker > that is a waiting period rather than a task. -> 2. **Q64 — does anyone else hold the AWS root password or its MFA device?** -> `/legal/privacy/` publishes *"has no programmatic key, and I hold it"* — his -> own words from the Q63(c) ruling, **true whether or not someone else holds -> it too**, sitting one paragraph below *"the small number of people who -> administer it with me"*, where a reader takes it as **sole** custody. Root -> cannot be simulated, so nothing establishes that either way. **One line -> settles it:** sole custody → say so, record it in §7, arm §12 R21; not sole -> → the possessive comes out and the sentence keeps its measured half. See the -> unticked item under **Copy and claims** below. +> 2. **Pouya has not yet read every page against `AGENTS.md` §4.** The human +> pass — the other half of D20, and not delegable. **It is also where the +> §Who can see it approval now lands:** Pouya ruled on 2026-09-02 that the +> read-through *is* the approval and that nothing is to be held open waiting +> on a separate wording sign-off. The item under **Copy and claims** below +> carries what to read first and why. +> +> ✅ **CLOSED 2026-09-02 — Q64, MOOT.** It asked whether anyone else holds the +> AWS root password or its MFA device, because the page published *"has no +> programmatic key, and I hold it"* one paragraph below *"the small number of +> people who administer it with me"*, where a reader takes it as **sole** +> custody. **Pouya's second ruling that day deleted the sentence** — the section +> is now four plain statements and says nothing about root — so the question no +> longer gates anything. ⚠️ **The underlying fact is unchanged and unestablished: +> §7 records root as *held by Pouya*, which is not *held only by Pouya*, and +> nothing measured can settle it. Nothing may be published about root custody +> without asking again.** > > ✅ **CLOSED 2026-09-02 — Q63, all three limbs, by ruling.** **(a)** The §Who > can see it wording is **approved with two trims** — the editorial closing @@ -439,15 +452,54 @@ Then invalidate `/*`. > humans**. No numeric human headcount ships; the page attributes read access to > *"the account's administrators — me, and the small number of people who > administer it with me"*. §12 **R21** is re-scoped to match. +> ⚠️ *(Superseded the same day in its details, not in its rulings: the ruling +> below cut the section to four plain statements, so the sentence quoted above is +> no longer the shipped one and root is not mentioned at all. Each limb of Q63 +> still stands — no headcount, the mailbox named, root attested in §7.)* +> +> ✅ **CLOSED 2026-09-02 — THE SECTION IS GENERIC, by a second ruling the same +> day.** *"It over-explains technical mechanics that belong in the evidence file, +> not in front of an inquirer."* §Who can see it is now **four short statements** +> — who can read it, that the receiving system can only add a record, where the +> notification goes and who reads it, and that the confirmation sits with the +> reader's own provider. **Deleted from §Who can see it:** the measurement +> paragraph, the root-credential sentence, the single-sign-on and federated- +> login enumeration, the resource-policy clause, the *"company that runs a +> database"* aside, the deploy-credential sentence and the three-copies +> summary. ⚠️ **THE SHARED-ACCOUNT CLAUSE WAS CUT WITH THEM AND THEN RESTORED +> — to §Where it is stored, where it belongs.** It is a storage disclosure +> rather than mechanics, the ruling did not name it, and without it no page +> told a reader their intake sits in an account that also runs unrelated +> systems (`adversarial-reviewer`, round 1). **These lists must stay identical +> — there were four of them and they named four different sets.** **None of +> that verified +> material was lost** — all of it stays in `AGENTS.md` §7 and +> `docs/reference/intake-table-access-verification.md`, and the section comment in +> `src/pages/legal/privacy.astro` bars restoring it to the page. **The risk moved +> in the right direction:** every deleted sentence was a claim about a system +> outside this repository that nothing reports on, which is what §12 **R21** +> exists for — R21 is re-scoped from five live claims to two. +> +> ✅ **CLOSED 2026-09-02 — THE CONSENT STRING NAMES THE CORPORATION.** *"I +> consent to **SML Company Ltd** storing and using the information in this +> form…"*, per ruling, replacing the natural person. It is the one sentence a +> submitter actually agrees to and it is the PIPEDA basis, and the policy it +> links to describes a mailbox read by administrative staff — a corporation is +> the party that matches, and `/legal/privacy/` now names it in terms under §Why +> it is collected. **The NAME ONLY:** +> §4 verifies the federal incorporation, records it as *not published*, and +> cautions that it must never be read beside the licence-status row. `docs/05` +> §Consent text carries the string verbatim and moved with it. > > ✅ **CLOSED 2026-09-02 — Q62.** `/legal/privacy/` no longer states anything > false about who can read the intake table. Pouya's ruling was **state the > truth**, not remove the second administrator's access: the page attributes read -> access to the account's administrators, names their role, and adds the two -> stronger facts the false sentence had been crowding out — the writing function -> cannot read the table, and the deploy credential has no access to it at all. -> *(It said "two people can read it" until the Q63 ruling later the same day -> replaced the count; see the Q63 block above.)* The +> access to the account's administrators and names their role. *(It said "two +> people can read it" until the Q63 ruling later the same day replaced the count, +> and the ruling after that cut the section to four plain statements — of the two +> stronger facts this entry originally credited it with, the writing function's +> add-only access still ships and the deploy credential's lack of access does +> not. See the two blocks above.)* The > `sole-administrator-q62` tripwire in `check-claims.mjs` **stays permanently** > by the same ruling, extended from two alternatives to **five**: the clause the > first form could not see two sections up the same page, the summary that would @@ -554,52 +606,35 @@ the decision is re-readable rather than re-litigated. have flagged correct copy and demanded the struck form. It read §4 instead. That is the fifth stale claim found in that file and it is not the agent's to fix -- [x] ✅ **Q63(a) RULED 2026-09-02 — the wording is approved WITH TWO TRIMS.** - The editorial closing sentence (*"I would rather tell you that than give - you the tidier answer"*) is struck, and the mailbox clause is rewritten per - (b). Q62's ruling settled what the section must **say**; he reserved the - **wording**, and that reservation is discharged by the ruling. **This tick - records the RULING, not the current text** — see the next item. -- [ ] 🛑 **THE §Who can see it TEXT AS IT NOW STANDS HAS NOT BEEN READ BY POUYA, - AND IT IS NOT THE TEXT HE APPROVED.** The same ruling that approved the - wording also took the human headcount off the page, and the two review - rounds that followed rewrote both paragraph openings, the root sentence and - the mailbox clause. **The revised section is quoted verbatim in - `docs/reference/intake-table-access-verification.md`** for exactly this - reading. ⚠️ **This item is split from the one above because a single ticked - box over changed copy is the defect the item above was created to stop** — - a person working this list reads the tick, not the eleven lines under it - (`adversarial-reviewer`, round 2). It is narrower than the general - read-through below: this one is the wording approval Pouya reserved in - terms, over the sentences that actually ship. - ⚠️ **THIS ITEM EXISTS BECAUSE THE GATE HAD NO MECHANISM.** On 2026-09-02 - the `TODO(pouya)` was deleted from the source, Q62 was struck in §9 and the - blocker in the callout above was ticked — all correctly, and the net effect - was that the only surviving record of an **open** approval requirement was - prose inside three records marked ✅ CLOSED. When Q60's TTL test passes, - nothing mechanical or visual would have stopped copy Pouya has not read. - `adversarial-reviewer`, D20 pass round 1. ⚠️ **THAT SENTENCE READ "the - `TODO(pouya)` is reinstated beside the copy and §9 Q63 is open" AFTER BOTH - HAD BEEN CLOSED IN THE SAME CHANGE SET** — a ticked item describing a live - control that no longer existed, which is Q22's shape on the item written to - stop Q22's shape (`adversarial-reviewer`, round 1). **What actually carries - the text as it now stands:** the read-through item below, and §9 **Q64** - with its own `TODO(pouya)` and its own unticked item — because answering - Q63 opened Q64 rather than clearing the section -- [ ] 🛑 **DOES ANYONE ELSE HOLD THE AWS ROOT PASSWORD OR ITS MFA DEVICE — - §9 **Q64**.** `/legal/privacy/` publishes *"Its root credential — the one - path no policy constrains — has no programmatic key, and I hold it"*. - Those are Pouya's own words from the Q63(c) ruling and they are **true - whether or not a second person holds it**; the defect is what a reader - takes from them, one paragraph below *"the small number of people who - administer it with me"*. Root is not an IAM principal and cannot be - simulated, so no measurement settles it — `get-account-summary` gives only - `AccountAccessKeysPresent: 0` and `AccountMFAEnabled: 1`. **Sole custody → - say so on the page, record it in §7, arm §12 R21. Not sole → strike the - possessive and keep the measured half.** `src/pages/legal/privacy.astro` - carries the `TODO(pouya)`. **This is Q63's lesson pointing the other way**: - Q63 struck a sentence for reading identities as people; this one invites a - reader to read a possessive as an exclusion +- [x] ✅ **THE §Who can see it WORDING APPROVAL IS DISCHARGED — Pouya's ruling, + 2026-09-02: *"the read-through is the approval."*** Q62 settled what the + section must **say** and he reserved the **wording**; he then ruled twice on + it the same day — Q63(a) approving with two trims, and the second ruling + cutting the section to four plain statements — and directed in terms that + nothing be held open waiting on a separate sign-off. ⚠️ **THIS TICK IS NOT + "THE TEXT HAS BEEN READ".** It records that the reserved approval has + **moved**, to the read-through blocker in the callout above and the item + below. Two ticked boxes stood here for one round — one for the ruling, one + for the text — because a single tick over changed copy is how an approval + requirement went missing the first time (`adversarial-reviewer`, round 2). + They collapse into this one only because the ruling collapsed them, and + the gate did not disappear: **it is blocker 2 in the callout above**, which + is the most-read place on this page rather than the least. +- [x] ✅ **CLOSED 2026-09-02 — Q64 IS MOOT: THE PARAGRAPH WAS DELETED.** It asked + whether anyone else holds the AWS root password or its MFA device, because + `/legal/privacy/` published *"has no programmatic key, and I hold it"* one + paragraph below *"the small number of people who administer it with me"* — + where a reader takes it as **sole** custody, which nothing establishes. + Pouya's second ruling that day struck the sentence along with the rest of + the mechanics, so no page says anything about root and the question gates + nothing. The `TODO(pouya)` is gone from + `src/pages/legal/privacy.astro` with the paragraph that carried it. + ⚠️ **THE FACT IS STILL UNESTABLISHED AND THAT DID NOT CHANGE.** §7 records + root as *held by Pouya*, which is not *held only by Pouya*; root is not an + IAM principal and cannot be simulated. **Nothing about root custody may be + published without asking him again** — the section comment in the page + source carries that bar, because "we deleted it" and "we checked it" are + the same green tick from three weeks away. - [x] ✅ **Q63(b) ANSWERED 2026-09-02 — `info@smlcompany.ca` is a DELEGATED MAILBOX: Pouya and administrative staff read it.** The page said *"anyone who can reach that mailbox"*, which was true either way and answered the @@ -618,12 +653,17 @@ the decision is re-readable rather than re-litigated. - [ ] **Pouya has read every page against `AGENTS.md` §4.** The human pass. It is the other half of D20 and it is not delegable — his reading is what the per-step audit was traded for. - ⚠️ **START WITH `/legal/privacy/` §Who can see it.** Every sentence in it - changed on 2026-09-02, twice — once by Q62's ruling and again by Q63's — - and it is the only section on the site whose subject lives entirely outside - this repository. It is also where the approval he reserved lands: Q63(a) - approved the wording, and the wording then changed under the same ruling - when the headcount came out. + ⚠️ **START WITH `/legal/privacy/` §Who can see it. IT IS BLOCKER 2 IN THE + CALLOUT ABOVE, AND THIS READ *IS* THE APPROVAL** — Pouya ruled on + 2026-09-02 that nothing waits on a separate wording sign-off. Every + sentence in it changed three times that day — Q62's ruling, Q63's, then the + ruling that cut it to **four plain statements** — and it is the only + section on the site whose subject lives entirely outside this repository. + **It is now four sentences and should take a minute**; that is the point of + the cut. The verified material behind them is in + `docs/reference/intake-table-access-verification.md` and `AGENTS.md` §7 if + he wants to check any of it, and **the page deliberately no longer cites + it**. **Then read the two `/contact/` sentences against it, which is a judgement rather than a defect** — `/contact/received/` says *"email me directly at `info@smlcompany.ca` — that reaches me whether or not the receipt did"* and @@ -634,20 +674,23 @@ the decision is re-readable rather than re-litigated. the neutral may take more from the word than is true. A sweep of all 23 built pages found these two as the only other surfaces touching the point. Raised as **consider**, not blocking, by `adversarial-reviewer` round 1. - ⚠️ **AND A THIRD SURFACE THAT SWEEP COULD NOT REACH — the CONSENT string, - `src/data/intake.ts`, rendered on `/contact/`:** *"I consent to **Pouya - Lajevardi** storing and using the information in this form…"*. It names a - natural person as the party storing and using the data, while the policy it - links to now describes the practice's mailbox, administrative staff and a - shared AWS account. **Nothing here is false** — he is the accountable - individual and staff act for him — but it is the one sentence a submitter - actually agrees to, and it is the PIPEDA basis. **The sweep that missed it - was anchored on mailbox vocabulary** (*"email me directly"*, *"reaches - me"*), which is R8's sharpest edge: the right command, the wrong anchor. - **Decide it here rather than leaving it implicit** — either widen the - consent, or record that it names the responsible individual deliberately. - Either way the consent string joins the surfaces the mailbox question - governs, so the next answer reaches it. `adversarial-reviewer`, round 2. + ✅ **THE THIRD SURFACE IS DECIDED — the CONSENT string now names the + corporation.** *"I consent to **SML Company Ltd** storing and using the + information in this form…"*, Pouya's ruling 2026-09-02, replacing the + natural person. It is the one sentence a submitter actually agrees to and + it is the PIPEDA basis, and the policy it links to describes a mailbox read + by administrative staff — a corporation is the party that matches, and + `/legal/privacy/` now names it in terms under §Why it is collected. **The sweep that had missed it was anchored on + mailbox vocabulary** (*"email me directly"*, *"reaches me"*), which is R8's + sharpest edge: the right command, the wrong anchor. + ⚠️ **THE PAGE AROUND IT STILL SAYS "me" AND "I", AND THAT IS DELIBERATE, NOT + AN OVERSIGHT — read the two together and say if it reads wrong.** The + ruling changed the consent sentence and nothing else; `/legal/privacy/` is + written in the first person throughout (*"whatever you send me"*, *"in your + hands rather than mine"*), and `/contact/` is too. Nothing is false either + way — he is the accountable individual, the corporation holds the systems — + but the checkbox and the prose beside it now name different parties, and + **that is a judgement about voice which is his and not a reviewer's.** - [x] ✅ **MEMBERSHIPS RE-CONFIRMED 2026-09-02 — Pouya: ADRIC, ADRIO, the three OBA sections and the CTF are all current.** §4 and `src/data/site.ts` are re-stamped `[verified 2026-09-02 — Pouya]`. ⚠️ **THERE ARE TWO ARRAYS AND diff --git a/docs/reference/intake-table-access-verification.md b/docs/reference/intake-table-access-verification.md index 52350f9..54c7e9b 100644 --- a/docs/reference/intake-table-access-verification.md +++ b/docs/reference/intake-table-access-verification.md @@ -41,38 +41,63 @@ exact count. **No numeric human headcount may ship.** The identity counts in thi file are unaffected and stay exactly as measured — this is a correction to what may be *concluded* from them, not to any of them. +⚠️ **AND RULED A THIRD TIME, LATER THE SAME DAY: THE PAGE STATES WHO, AND THIS +FILE HOLDS THE METHOD.** Pouya, 2026-09-02: *"the page stays generic. It +over-explains technical mechanics that belong in the evidence file, not in front +of an inquirer."* §Who can see it is now **four short statements**. **Deleted from +the page:** the measurement paragraph, the root-credential sentence, the single-sign-on and federated-login enumeration, the resource-policy clause, the *"company that runs a database"* aside, the deploy-credential sentence and the three-copies summary. ⚠️ **THE SHARED-ACCOUNT CLAUSE WAS CUT WITH THEM AND THEN RESTORED — to §Where it is stored, where it belongs.** It is a storage disclosure rather than mechanics, the ruling did not name it, and without it no page told a reader their intake sits in an account that also runs unrelated systems (`adversarial-reviewer`, round 1). **These lists must stay identical — there were four of them and they named four different sets.** None of that was retracted and none of it is lost — it +is all still below, unchanged, and **that is now this file's job rather than a +supporting role.** ⚠️ **THE PAGE NO LONGER CITES THIS FILE'S CONTENT, SO THE +COMPARISON BELOW IS THE ONLY THING TYING THE TWO TOGETHER. Keep it in sync, and +do not restore a deleted sentence to the page on the strength of finding it +here** — the section comment in `src/pages/legal/privacy.astro` carries the same +bar. + **The shipped sentences as at 2026-09-02**, so this file can be compared against -the live page rather than against a struck one: +the live page rather than against a struck one. All four, in order, complete: -> The account's administrators can — me, and the small number of people who -> administer it with me. The table sits in an Amazon Web Services account that -> also runs systems unrelated to this practice, and administrative access to that -> account carries the ability to read the table. That is who can read the stored -> record; who reads the notification email is a separate question, answered in the -> last paragraph of this section. +> The record in the table: me, and the small number of people who administer the +> account it sits in with me. -> The access itself is measured rather than assumed: every user and every role in -> the account was simulated against this table, and every identity that comes back -> able to read it is reachable only by those administrators. The account has no -> single sign-on and no federated login configured, and the table carries no -> policy of its own granting access to anyone. The account's root credential — the -> one path no policy constrains — has no programmatic key, and I hold it. +> The system that receives what you send **can only add a record — it cannot read +> back what is stored.** -> The function that receives the form **can only add a record — it cannot read -> the table back.** And the credential that publishes this website has **no -> access to the table at all**, for reading or for writing. +> The notification goes to the practice's mailbox, which is read by me and by +> administrative staff and is hosted on Google Workspace — so Google holds a copy +> of whatever you send me. -**The wording was approved by Pouya on 2026-09-02 with two trims** (§9 Q63(a)) — -the editorial closing sentence struck, and the mailbox clause rewritten because -`info@smlcompany.ca` is **a delegated mailbox read by Pouya and administrative -staff**, not a personal one (Q63(b); the fact is in `AGENTS.md` §7). **`33` was -deliberately not published**: a role total moves when AWS creates a service-linked -role by itself, and *"every user and every role in the account"* carries the -exhaustiveness without putting a second self-staling number on a legal page. +> The confirmation that went to you sits with whoever runs your email. That copy +> is in your hands rather than mine. -⚠️ **AND THE ENUMERATION BELOW WAS NOT ENOUGH TO SUPPORT THE SECOND OF THOSE -SENTENCES. See the addendum at the foot of this file**, which is what the page -actually rests on. Read it before citing the five-row table. +**What each rests on, because that mapping is the reason this file exists.** +Sentence 1: the enumeration below, plus Pouya's *"a handful"* attestation for the +human quantifier — **the measurement gives administrators, the attestation gives +the number, and neither gives the other.** Sentence 2: `adr-intake-lambda-role` +holds `PutItem` only, implicitDeny on all six read and modify actions. +Sentence 3: **an attestation, not a measurement** — `AGENTS.md` §7's +`info@smlcompany.ca` row; nothing in this repository or in AWS can check it. +Sentence 4: the handler's second `SendEmailCommand`. + +**Three things the page deliberately does NOT say, and each was deleted by +ruling rather than being unsupported.** The **root credential** (§7 records it as +held by Pouya with no access key and MFA on — ⚠️ *held*, not *held only*, which +is why publishing it needed a question and why §9 Q64 is closed as **moot** and +not as answered). The **single-sign-on and resource-policy findings**. And the +**`33`** — deliberately withheld even while the paragraph stood, because a role +total moves when AWS creates a service-linked role by itself. + +**The wording approval Pouya reserved is discharged by the read-through** — his +ruling, 2026-09-02: *"do not hold anything open waiting on a separate wording +approval; the read-through is the approval."* Q63(a) had approved a version, and +the version changed twice after it. + +⚠️ **AND THE ENUMERATION BELOW WAS NOT ENOUGH TO SUPPORT THE COMPLETENESS CLAIM +— *"every user and every role in the account was simulated against this table"*, +which §7 still asserts and the page no longer carries. See the addendum at the +foot of this file**, which is what that claim actually rests on. Read it before +citing the five-row table. *(This pointer said "the second of those sentences" +until 2026-09-02: it indexed the quote block by POSITION, and the block changed +length under it. Name the claim, not its ordinal.)* --- @@ -211,10 +236,19 @@ a silently-skipped iteration is visible as a missing row, and suppresses nothing ## ⚠️ ADDENDUM 2026-09-02 — THE ENUMERATION ABOVE WAS INCOMPLETE IN THREE WAYS, AND ITS CONCLUSION SURVIVES ANYWAY -**Why this addendum exists.** `/legal/privacy/` publishes a completeness claim -about who can read this table — the second of the three sentences quoted at the -top of this file, under **The shipped sentences**. Written as it stood, this file -did not support it. +**Why this addendum exists.** `/legal/privacy/` published a completeness claim +about who can read this table — *"every user and every role in the account was +simulated against this table"* — and, written as it stood, this file did not +support it. ⚠️ **THAT SENTENCE IS NO LONGER ON THE PAGE**: Pouya ruled later the +same day that the section states who and not how, and the measurement paragraph +was deleted (see **The shipped sentences** at the top of this file, which is now +four statements and does not include it). **This addendum is not thereby +obsolete — it is now load-bearing in a different place.** `AGENTS.md` §7's +`Intake table — who can read it` row still asserts the completeness, `docs/06` +and §12 **R21** still instruct an operator to re-run it before cutover, and the +page's first sentence still rests on its conclusion even though it no longer +recites the method. **A claim moved off a public page into a register is still a +claim.** *(This paragraph quoted a different sentence until 2026-09-02 — round 1's **pre-fix** wording, *"every account and role in this infrastructure…"*, which @@ -234,7 +268,7 @@ construction even when it happens to be true. 2. **No role was ever simulated against the table.** Access was inferred from policy *names* (`AdministratorAccess`) rather than measured as a decision. 3. **The five users were simulated for reads only** — `GetItem`, `Query`, `Scan`. - So the page's *"the credential that publishes this website has no access to the + So the page's *(then-shipped; deleted by the mechanics ruling of 2026-09-02 and now §7's alone)* *"the credential that publishes this website has no access to the table at all"* covered three read actions and said "at all". **What the measurement found, and it changes the role count.** Simulating all 26 @@ -351,44 +385,50 @@ always read the table. Two facts bound it: `get-account-summary` reports and `AccountMFAEnabled: 1`. Root access therefore requires the root password and its MFA device. -⚠️ **THIS PASSAGE SAID *"The page does not mention root and should not"*, AND -THAT JUDGEMENT IS SUPERSEDED — §9 Q63(c), 2026-09-02.** It was reasoned from its -own last clause: *"Who holds the root credentials is not established in this -repository."* **Pouya established it on 2026-09-02: he holds it** -`[verified 2026-09-02 — Pouya]`. With the holder known, mentioning root -**strengthens** the paragraph rather than opening a hole in it — it closes the -one path a careful reader would ask about after being told every user and every -role was simulated. The page now states that the root credential has no -programmatic key and that he holds it; it does not state a headcount for it, and -`AGENTS.md` §7 carries the fact with §12 R21's trigger on it. ⚠️ **AND THE -ATTESTATION IS *held by Pouya*, NOT *held ONLY by Pouya* — §9 Q64 is open on -exactly that gap.** Nothing here excludes a second holder: root cannot be -simulated, and `get-account-summary` reports only that there is no access key and -that MFA is on. The shipped possessive sits one paragraph below *"the small -number of people who administer it with me"*, where a reader takes it as sole -custody. **This is the identity/human error of Q63 pointing the other way** — one -line from Pouya either arms it or strikes the possessive. The rest of the -original reasoning holds and is why the sentence is still scoped the way it is: -an account owner's own credential is inherent to every cloud account and is not a -third party who has been granted access, which is why the shipped sentence is -scoped to *"every user and every role"* and to who has been *granted* access -rather than to a bare "nobody else can". +⚠️ **THE PAGE SAYS NOTHING ABOUT ROOT, AND THIS PASSAGE HAS NOW BEEN THE REASON +FOR THAT TWICE ON OPPOSITE GROUNDS.** It first read *"The page does not mention +root and should not"*, reasoned from its own last clause — *"who holds the root +credentials is not established in this repository."* **Pouya then established it +(§9 Q63(c), 2026-09-02): he holds it** `[verified 2026-09-02 — Pouya]`, the page +published *"has no programmatic key, and I hold it"*, and the gap that opened +immediately was that *held by* is not *held only by* — a reader takes the +possessive as sole custody, which nothing measured or attested supports (§9 +**Q64**). **His second ruling that day deleted the sentence** along with the rest +of the mechanics, so **Q64 is closed as MOOT rather than answered and the +underlying fact is exactly as unestablished as it was.** -**Two page sentences are now supported that were not before.** +**The consequence to carry, because it is not "nothing happened":** root custody +is now recorded in `AGENTS.md` §7 and nowhere public. ⚠️ **Nothing about it may +be published without asking him again**, and the question to ask is not *who +holds root* — that is answered — but *whether anyone else does*. The original +reasoning still holds and is why the page's first sentence is scoped as it is: an +account owner's own credential is inherent to every cloud account and is not a +third party who has been *granted* access, which is why the measured claim was +always scoped to *"every user and every role"* rather than to a bare "nobody else +can". -- *"The function that receives the form can only add a record and cannot read the - table back"* — `adr-intake-lambda-role` returns `allowed` for `PutItem` and - `implicitDeny` for `GetItem`, `Query`, `Scan`, `BatchGetItem`, `UpdateItem` and - `DeleteItem`. Previously this rested on reading the policy document; it is now - the simulator's decision. -- *"the credential that publishes this website has no access to the table at - all"* — `adr-sml-deploy` is `implicitDeny` on all **seven**, so "at all" now - covers writes and deletes as well as reads. +**Two claims are supported that were not before. One of them still ships; the +other was deleted from the page by ruling on 2026-09-02 and is kept here because +it remains true and remains §7's.** + +- **SHIPS** — *"The system that receives what you send can only add a record — it + cannot read back what is stored"* — `adr-intake-lambda-role` returns `allowed` + for `PutItem` and `implicitDeny` for `GetItem`, `Query`, `Scan`, + `BatchGetItem`, `UpdateItem` and `DeleteItem`. Previously this rested on + reading the policy document; it is now the simulator's decision. +- **NO LONGER ON THE PAGE** — *"the credential that publishes this website has no + access to the table at all"* — `adr-sml-deploy` is `implicitDeny` on all + **seven**, so "at all" covers writes and deletes as well as reads. It went with + the mechanics cut, not because anything about it changed. **And it corroborates §10 from the IAM surface.** Of the 26 non-service-linked roles, **9 belong to CDK bootstrap** and **14 to four unrelated production -systems** in the same account — which is what `/legal/privacy/` now tells a -reader in as many words. *(Their role names were listed here until 2026-09-02 and +systems** in the same account. *(`/legal/privacy/` tells a reader this in as many words — +*"The table sits in an Amazon Web Services account that also runs systems +unrelated to this practice"* — in **§Where it is stored**, which is where the +sentence now lives: the mechanics cut removed it and it was restored there, as a +storage disclosure rather than a method. §10 is unaffected either way; it never +depended on the page saying so.)* *(Their role names were listed here until 2026-09-02 and are not any more: this is a committed file, they are another project's IAM surface, and the count carries the whole of the argument. `adversarial-reviewer`, round 2.)* diff --git a/scripts/check-claims.mjs b/scripts/check-claims.mjs index 4e603cd..7c31411 100644 --- a/scripts/check-claims.mjs +++ b/scripts/check-claims.mjs @@ -415,23 +415,22 @@ const FIXTURES = { the wording a correction is likely to reach for. Where a fixture is one of those, the comment beside it says so. */ mustNotMatch: [ - /* NEGATIVE FIXTURES FOR `sole-administrator-q62`. The first SEVEN are LIVE - PAGE COPY, verbatim from the corrected `/legal/privacy/` — - which is the fixture that matters, because Q62's ruling required this - pattern to be proven silent on the true sentence as well as loud on the - false one. THEY MUST BE RE-SYNCED WHENEVER THAT COPY CHANGES — this set - has now gone stale twice, once within the hour of being written and again - when Pouya's 2026-09-02 ruling took the human headcount off the page. The - rest are near misses on the same subject: the pattern is anchored on five - strings that reached `dist/`, not on the ideas in them, so a truthful - sentence about administrative access must pass. */ - "The account's administrators can — me, and the small number of people who administer it with me. The table sits in an Amazon Web Services account that also runs systems unrelated to this practice, and administrative access to that account carries the ability to read the table. That is who can read the stored record; who reads the notification email is a separate question, answered in the last paragraph of this section.", - 'The access itself is measured rather than assumed: every user and every role in the account was simulated against this table, and every identity that comes back able to read it is reachable only by those administrators.', - "The account's root credential — the one path no policy constrains — has no programmatic key, and I hold it.", - 'Two things in the system are narrower than I am, and they are worth stating because they are the part you cannot check for yourself.', - /* The replacement summary, which must not trip the third-surface alternative. */ - "There are therefore three copies of what you send. The record in the table, which the account's administrators can read.", - "The notification, which lands in the practice's mailbox — read by me and by administrative staff — on Google Workspace, so Google holds a copy of whatever you sent me.", + /* NEGATIVE FIXTURES FOR `sole-administrator-q62`. The first FIVE are LIVE + PAGE COPY, verbatim from the corrected `/legal/privacy/` — which is the + fixture that matters, because Q62's ruling required this pattern to be + proven silent on the true sentence as well as loud on the false one. + RE-SYNC THEM WHENEVER THAT COPY CHANGES. ⚠️ **A SENTENCE THAT LEAVES THE + PAGE LEAVES THIS LIST — it is not kept as a near miss.** Struck copy in a + list captioned "what this site legitimately publishes" is an invitation to + restore it. The rest below ARE near misses on the same subject: the + pattern is anchored on five strings that reached `dist/`, not on the ideas + in them, so a truthful sentence about administrative access must pass. + Rendered as text, without the `` wrappers — what is proven is that + the PATTERN is silent on the words. */ + 'The record in the table: me, and the small number of people who administer the account it sits in with me.', + 'The system that receives what you send can only add a record — it cannot read back what is stored.', + "The notification goes to the practice's mailbox, which is read by me and by administrative staff and is hosted on Google Workspace — so Google holds a copy of whatever you send me.", + 'The confirmation that went to you sits with whoever runs your email. That copy is in your hands rather than mine.', 'No one else is sent it. There is no CRM, no mailing list and no analytics on the submission.', 'The table is reachable by the function that writes to it.', 'Two accounts hold administrative access to the AWS account, and the function that writes to the table cannot read it.', diff --git a/src/data/intake.ts b/src/data/intake.ts index 6e2acfc..95afb6b 100644 --- a/src/data/intake.ts +++ b/src/data/intake.ts @@ -172,9 +172,17 @@ export const INTAKE_FIELDS: readonly IntakeField[] = [ * is the one the inquirer ticks; both ship on `/contact/`, which is deliberate: * `docs/01` requires the page to carry the notice, and `docs/05` requires the * checkbox to carry it too. + * + * ⚠️ **IT NAMES SML COMPANY LTD — Pouya's ruling, 2026-09-02 — AND THREE + * CONSTRAINTS RIDE ON THAT.** **Name only, no terminal period**, and never + * beside the licence-status row (`AGENTS.md` §4). **`docs/05` §Consent text is a + * byte-identical second copy with no `check:` script over it**, so it moves with + * this string. And **`/legal/privacy/` must keep naming the same party** — it + * does, under §Why it is collected; a consent naming a company the linked policy + * never mentions is an accountability gap, not a matter of voice. */ export const CONSENT_TEXT = - 'I consent to Pouya Lajevardi storing and using the information in this form ' + + 'I consent to SML Company Ltd storing and using the information in this form ' + 'to respond to my inquiry and to run a conflicts check. I understand that ' + 'submitting this form does not create a retainer, does not appoint a neutral, ' + 'and does not itself establish a mediator–party relationship.'; diff --git a/src/pages/legal/privacy.astro b/src/pages/legal/privacy.astro index 2aa754b..5a92519 100644 --- a/src/pages/legal/privacy.astro +++ b/src/pages/legal/privacy.astro @@ -171,7 +171,9 @@ const COLLECTED = INTAKE_FIELDS.map((field) => field.label);

To reply to your inquiry and to run a conflicts check. The basis is your consent, which the form asks for explicitly with an unchecked box - you have to tick. The wording you agree to is on the form itself. + you have to tick. The wording you agree to is on the form itself, and + it names SML Company Ltd, the company that holds this + practice's systems.

It is not used for marketing. It is not sold, rented or shared with @@ -185,6 +187,10 @@ const COLLECTED = INTAKE_FIELDS.map((field) => field.label); the form — a notification to the practice and a confirmation to you — using Amazon Simple Email Service, also in the same Canadian region.

+

+ The table sits in an Amazon Web Services account that also runs + systems unrelated to this practice. +

{ /* ⚠️ TWO PROCESSORS, AND BOTH MUST BE NAMED. `AGENTS.md` §7 records mail hosting as **Google Workspace** and D18 sends the notification to @@ -245,85 +251,52 @@ const COLLECTED = INTAKE_FIELDS.map((field) => field.label);

Who can see it

{ - /* ⚠️ THESE NINE PARAGRAPHS ANSWER "WHO CAN SEE IT" AND THEY CHANGE - TOGETHER — by opening phrase, because every defect here has been a - partial sweep and a COUNT is what drifts. **This section:** "The - account's administrators can", "The access itself is measured", "Two - things in the system are narrower", "There are therefore three - copies". **§Where it is stored, all four:** "In a DynamoDB table", - "Two companies therefore process it", "The confirmation sent to you", - "No one else is sent it". **§How long it is kept:** "Emails are a - separate matter". - **NO HUMAN HEADCOUNT SHIPS** — Pouya, 2026-09-02: the simulation - counts identities, not people. Say "the account's administrators". - **TWO CLAIMS GO STALE ON THEIR OWN**, both about the present state of - systems outside this repo: the AWS enumeration and who reads - `info@smlcompany.ca`. Their durable homes are `AGENTS.md` §7's two - rows and §12 **R21** claims (i)–(v), which is the trigger for both; - `docs/reference/intake-table-access-verification.md` holds the - commands. **§9 Q63 is closed — the live gate is Q64.** - `check-claims.mjs`'s `sole-administrator-q62` pattern bars the OLD - false shape permanently and is blind to both. */ - } -

- The account's administrators can — me, and the small number of people - who administer it with me. The table sits in an Amazon Web Services - account that also runs systems unrelated to this practice, and - administrative access to that account carries the ability to read the - table. That is who can read the stored record; who reads the - notification email is a separate question, answered in the last - paragraph of this section. -

-

- The access itself is measured rather than assumed: every user and - every role in the account was simulated against this table, and every - identity that comes back able to read it is reachable only by those - administrators. The account has no single sign-on and no federated - login configured, and the table carries no policy of its own granting - access to anyone. The account's root credential — the one path no - policy constrains — has no programmatic key, and I hold it. Amazon Web - Services operates the table, as Where it is stored above says: - a company that runs a database is not someone who has been given access - to it, and both of those are true at once. -

- { - /* TODO(pouya): DOES ANYONE ELSE HOLD THE ROOT PASSWORD OR ITS MFA - DEVICE? `AGENTS.md` §9 **Q64**. You attested that you hold it - (Q63(c)) and the paragraph above ships your words — *"has no - programmatic key, and I hold it"* — which is true whether or not - somebody else holds it too. ⚠️ **But it sits one paragraph below "the - small number of people who administer it with me", and a reader takes - it as SOLE custody.** Nothing measured establishes that: root is not - an IAM principal, cannot be simulated, and `get-account-summary` - reports only that there is no access key and that MFA is on. If it is - sole custody, say so and §12 R21 arms it; if it is not, the possessive - comes out. One line either way. `adversarial-reviewer`, round 1. */ - } -

- Two things in the system are narrower than I am, and they are worth - stating because they are the part you cannot check for yourself. The - function that receives the form - can only add a record — it cannot read the table back. And the credential that publishes this website has - no access to the table at all, for reading or for - writing. -

- { - /* ⚠️ THREE COPIES, NOT TWO, AND THE THIRD IS THE READER'S OWN: the + /* ⚠️ THIS SECTION AND THE SENTENCES BELOW ANSWER THE SAME QUESTION + AND CHANGE TOGETHER — by OPENING PHRASE, never by count. **Here:** + "The record in the table", "The system that receives", "The + notification goes to", "The confirmation that went to you". + **§Where it is stored:** "In a DynamoDB table", "The table sits in an + Amazon Web Services account", "Two companies therefore process it", + "The confirmation sent to you", "No one else is sent it". **§How long + it is kept:** "Emails are a separate matter". + ⚠️ **THIS SECTION STATES WHO, NOT HOW — Pouya's ruling, 2026-09-02. + NOT TO BE RESTORED HERE:** the measurement paragraph, the + root-credential sentence, the single-sign-on and federated-login + enumeration, the resource-policy clause, the "company that runs a + database" aside, the deploy-credential sentence and the three-copies + summary. All true, all still in `AGENTS.md` §7 and + `docs/reference/intake-table-access-verification.md`. **No human + headcount** — a simulation counts identities, not people. + ⚠️ **SENTENCE 1 IS SCOPED TO THE STORED RECORD** (paragraph 3 names + administrative staff, who read the mailbox and **cannot** read the + table) **AND PREDICATED ON ADMINISTERING THE ACCOUNT** (what §7 + measures). §4 carries the row and the bar: **never widen it to + running, founding, practising or acting.** + **TWO CLAIMS GO STALE ON THEIR OWN** — who administers the account, + and who reads `info@smlcompany.ca`. §7 holds both; §12 **R21** is the + trigger. + ⚠️ **THERE ARE THREE COPIES AND THE THIRD IS THE READER'S OWN** — the handler puts the whole submission into the confirmation it sends the - inquirer, under "What you sent:" (the second `SendEmailCommand` in - `backend/intake/handler.mjs`). Do not write "the one other place a - copy exists" — an absolute enumeration standing one section from the - page's own counter-example is what Q62 was. */ + inquirer. Never write "the one other place a copy exists". */ }

- There are therefore three copies of what you send. The record in the - table, which the account's administrators can read. The notification, - which lands in the practice's mailbox — read by me and by - administrative staff — on Google Workspace, so Google holds a copy of - whatever you sent me. And the confirmation that went to you, which - sits with whoever runs your email; that copy is in your hands rather - than mine. + The record in the table: me, and the small number of people who + administer the account it sits in with me. +

+

+ The system that receives what you send + can only add a record — it cannot read back what is stored. +

+

+ The notification goes to the practice's mailbox, which is read by me + and by administrative staff and is hosted on Google Workspace — so + Google holds a copy of whatever you send me. +

+

+ The confirmation that went to you sits with whoever runs your email. + That copy is in your hands rather than mine.

Cookies and analytics