feat: rule Q62 by stating the truth; strike the /med-arb/ gloss; re-stamp R18
Pouya's four rulings of 2026-09-01, applied 2026-09-02.
Q62 — RULED "state the truth", not "remove the access". /legal/privacy/
now says two people can read the intake table, names their role, 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. Wording is subject to Pouya's read-through —
Q63(a), with a TODO(pouya) beside the copy.
The ruling named one sentence; a vocabulary sweep found the falsehood in
three places, and the audit then found two more. Five paragraphs now
answer "who can see it" and change together.
The tripwire stays permanently, per ruling, and grew from two
alternatives to five. Every alternative is one string that reached dist/.
Proven both ways against the pre-correction page rebuilt from bd282aa:
exit 1 with 5 matches at dist/legal/privacy/index.html:54,67,67,68,72;
exit 0 on the corrected page, self-test 12 patterns / 36 approved
strings.
/med-arb/ — the gloss is struck with no replacement, per ruling. The
strike left "the section above" pointing at the ADRIC rule set and "the
agreement" with no antecedent; both fixed. The bare designations line
sitting under ADRIC's quoted competence requirement is also struck, which
goes beyond the ruling and is flagged for Pouya.
R18 — re-stamped, two-tier: (a)(c)(d) re-verified against a source,
(b)(e)(f)(g) held on a cadence judgement. All seven hold, no shipped
sentence changed. R18's trigger had NO cutover checklist item and had
stamped five extracts of seven; both fixed. Candidate limb (h) flagged.
R10 — fired and unsatisfied; left open on instruction.
The evidence behind the new privacy sentence was weaker than the
sentence. Re-measured: 33 of 33 roles simulated (23 of 26 carried inline
policies nobody had read; the two CDK lookup roles can read the table),
four trust policies, the CloudFormation escalation path for all five
users, 0 federated providers, root recorded. Every read path terminates
at the same two people.
Two review rounds, 36 findings. 35 fixed, 1 declined. Five of round 2's
were defects in round 1's own fixes; stopped at two per D19.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Md3GndFqWPzK78xAoebsg5
This commit is contained in:
Pouya Lajevardi
co-authored by
Claude Opus 5
Claude Opus 5
parent
bd282aa47d
commit
6aaf089b05
@@ -13,6 +13,18 @@ cite it. Do not paraphrase a fact into a page that is not stated here.
|
||||
> date and effective date below is as at the retrieval date and nothing more.
|
||||
> Re-check before cutover, and before any republish that turns on one of them.
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> The trigger fired. `AGENTS.md` §12 R18 holds the per-limb findings and
|
||||
> the sources; this stamp does not restate them. **The quoted bytes below
|
||||
> are still the original retrieval and were not re-fetched** — what was
|
||||
> re-checked is whether the *facts* they support have moved.
|
||||
>
|
||||
> - **(g) ADRIC's Code of Ethics, quoted verbatim on `/process/` — NOT
|
||||
> RE-RETRIEVED.** Held unchanged on a cadence judgement `[assumed
|
||||
> 2026-09-01 — Pouya]`. It is the slowest-moving of the seven; the live link
|
||||
> on `/process/` is what makes a stale quotation visible to a reader.
|
||||
|
||||
**Topic as researched:** The Canadian ADR institutions this practice names, and the exact form of their names — ADRIC / ADRIO rule sets, designations, codes; ADR Chambers; early neutral evaluation and dispute-system design
|
||||
|
||||
---
|
||||
|
||||
@@ -10,6 +10,19 @@ construction. This is the same fetch-before-writing that caught
|
||||
|
||||
**It caught one immediately. See Finding 1.**
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> The trigger fired. `AGENTS.md` §12 R18 holds the per-limb findings and
|
||||
> the sources; this stamp does not restate them. **The quoted bytes below
|
||||
> are still the original retrieval and were not re-fetched** — what was
|
||||
> re-checked is whether the *facts* they support have moved.
|
||||
>
|
||||
> - **(f) the ADRIC National Mediation Rules, under review by ADRIC's own
|
||||
> committee — NOT RE-RETRIEVED.** Held unchanged on a cadence judgement
|
||||
> rather than a fresh fetch `[assumed 2026-09-01 — Pouya]`. The digests in
|
||||
> the Provenance table below are the 2026-08-28 bytes and were not
|
||||
> recomputed, so this stamp says nothing about whether the page changed.
|
||||
|
||||
## Provenance
|
||||
|
||||
| | |
|
||||
|
||||
@@ -21,6 +21,19 @@ not published.
|
||||
> at second reading on the retrieval date and could be law, or dead, by the time
|
||||
> anyone reads this. **Re-check before cutover.**
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> The trigger fired. `AGENTS.md` §12 R18 holds the per-limb findings and
|
||||
> the sources; this stamp does not restate them. **The quoted bytes below
|
||||
> are still the original retrieval and were not re-fetched** — what was
|
||||
> re-checked is whether the *facts* they support have moved.
|
||||
>
|
||||
> - **(a) Bill C-36 — RE-VERIFIED UNMOVED** `[re-checked 2026-09-01 — Pouya,
|
||||
> <https://www.parl.ca/legisinfo/en/bill/45-1/c-36>]`. Still at second
|
||||
> reading in the House of Commons; latest completed stage is first reading,
|
||||
> 2026-06-15; no advance since. `/practice/technology/`'s sentence stands as
|
||||
> written.
|
||||
|
||||
**Topic as researched:** Canadian technology / data / AI dispute context — privacy legislation status as at 2026-08-29, Ontario public-sector and health privacy statutes, data residency law, and Canadian arbitral-institution rules for technology/AI disputes
|
||||
|
||||
---
|
||||
|
||||
@@ -10,16 +10,56 @@ one claim on the site whose subject was entirely outside the repo.
|
||||
|
||||
Raised by `claims-auditor` in the D20 cutover audit, 2026-09-01, finding 8.
|
||||
|
||||
**Provenance.** Every figure below was read from AWS on **2026-09-01** with the
|
||||
commands listed at the end, run read-only as `arn:aws:iam::327082975128:user/pouya`.
|
||||
**Provenance.** Figures in the ORIGINAL sections were read from AWS on
|
||||
**2026-09-01**; everything in the **2026-09-02 addendum** at the foot of this file
|
||||
was read on 2026-09-02, and it supersedes the original role screen. Both were run
|
||||
read-only as `arn:aws:iam::327082975128:user/pouya` with the commands listed at
|
||||
the end.
|
||||
No command in this file creates or changes anything. Re-run them rather than
|
||||
trusting this file; it is dated for that reason.
|
||||
|
||||
---
|
||||
|
||||
## The claim being checked
|
||||
## ✅ RULED AND APPLIED — 2026-09-02
|
||||
|
||||
`src/pages/legal/privacy.astro`, §Who can see it:
|
||||
**Pouya ruled `state the truth`, not `remove the access`** (§9 Q62, ruled
|
||||
2026-09-01, applied 2026-09-02). Option 2 below is the one taken; option 1 was
|
||||
declined. `lars`'s membership of `admins` is **unchanged**.
|
||||
|
||||
**The shipped sentences**, so this file can be compared against the live page
|
||||
rather than against a struck one:
|
||||
|
||||
> Two people can. The table sits in an Amazon Web Services account that also
|
||||
> runs systems unrelated to this practice, and that account has two
|
||||
> administrators — me, and one other person who administers it with me.
|
||||
> Administrative access to the account carries the ability to read the table, so
|
||||
> both of us can read what you send.
|
||||
|
||||
> No one outside those two people has been granted access to the table, and that
|
||||
> is measured rather than assumed: every user and every role in the account was
|
||||
> simulated against this table, and the only ones that come back able to read it
|
||||
> lead to those same two people.
|
||||
|
||||
> 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.
|
||||
|
||||
**Wording is subject to Pouya's read-through approval** — §9 **Q63**, with a
|
||||
`TODO(pouya)` beside the copy. The measurement is settled; the phrasing is not.
|
||||
|
||||
⚠️ **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.
|
||||
|
||||
---
|
||||
|
||||
## The claim being checked — ⚠️ STRUCK 2026-09-01, QUOTED HERE AS THE DEFECT
|
||||
|
||||
This is **no longer on the page.** It is kept because it is the string
|
||||
`check-claims.mjs`'s `sole-administrator-q62` pattern permanently bars, and a
|
||||
tripwire whose target is not recorded anywhere becomes unmaintainable.
|
||||
|
||||
`src/pages/legal/privacy.astro`, §Who can see it, **as it stood at `bd282aa`**:
|
||||
|
||||
> 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.
|
||||
@@ -75,9 +115,13 @@ access, and it belongs to a second administrator of a shared account.
|
||||
`meshkini*`/`gitea*` users are evidence of that on the IAM surface, not just
|
||||
in the S3 bucket listing §10 describes.
|
||||
|
||||
## What has to happen before `/legal/privacy/` goes public
|
||||
## What had to happen before `/legal/privacy/` went public — ✅ RESOLVED BY OPTION 2
|
||||
|
||||
Tracked as `AGENTS.md` §9 **Q62**. It is one of two things and both are Pouya's:
|
||||
Tracked as `AGENTS.md` §9 **Q62**, **closed 2026-09-02 on option 2.** Kept
|
||||
unstruck because the reasoning is what makes the ruling re-readable, and because
|
||||
option 1 remains live in one direction: if that access is ever actually removed,
|
||||
the page and the tripwire both have to change, and `check-claims.mjs`'s `rule:`
|
||||
line carries that instruction.
|
||||
|
||||
1. **Remove the access** — take `lars` out of `admins`, or replace that
|
||||
membership with a policy that denies DynamoDB on this table — and then this
|
||||
@@ -139,3 +183,218 @@ parameter-expansion bug (`$ACCT:user/` parses `:u` as a history modifier). The
|
||||
loop above brace-quotes `${U}` for that reason, prints one line per principal so
|
||||
a silently-skipped iteration is visible as a missing row, and suppresses nothing.
|
||||
**Five rows, or the run did not happen.**
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 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.
|
||||
|
||||
*(This paragraph quoted a different sentence until 2026-09-02 — round 1's
|
||||
**pre-fix** wording, *"every account and role in this infrastructure…"*, which
|
||||
the audit then struck. So this file briefly quoted two different sentences as the
|
||||
live one, in the two halves of the same document, which defeats the comparison
|
||||
R14 exists for. Fixed by pointing at the block above rather than re-quoting it:
|
||||
one copy of a fact, in one place. `adversarial-reviewer`, round 2.)* Under R14 the artefact is what a reviewer compares the
|
||||
claim against, so a claim stronger than its artefact is unverifiable by
|
||||
construction even when it happens to be true.
|
||||
|
||||
**What was missing.**
|
||||
|
||||
1. **`aws iam list-role-policies` was never run.** The command block above lists
|
||||
only `list-attached-role-policies`, which returns *managed* policies. **23 of
|
||||
the 26 non-service-linked roles carry inline policies**, and none of them had
|
||||
been read. The screen for "broad policies" could not have seen an inline grant.
|
||||
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
|
||||
table at all"* covered three read actions and said "at all".
|
||||
|
||||
**What the measurement found, and it changes the role count.** Simulating all 26
|
||||
non-service-linked roles across **seven** actions — `GetItem`, `Query`, `Scan`,
|
||||
`BatchGetItem`, `PutItem`, `UpdateItem`, `DeleteItem`:
|
||||
|
||||
| role | decision on the table | trust |
|
||||
|---|---|---|
|
||||
| `cdk-hnb659fds-cfn-exec-role-…-ca-central-1` | **allowed on all 7** | `cloudformation.amazonaws.com` only |
|
||||
| `cdk-hnb659fds-cfn-exec-role-…-us-east-1` | **allowed on all 7** | `cloudformation.amazonaws.com` only |
|
||||
| `cdk-hnb659fds-lookup-role-…-ca-central-1` | **allowed on the 4 READS**, denied on writes | `arn:aws:iam::327082975128:root` |
|
||||
| `cdk-hnb659fds-lookup-role-…-us-east-1` | **allowed on the 4 READS**, denied on writes | `arn:aws:iam::327082975128:root` |
|
||||
| `adr-intake-lambda-role` | `PutItem` **only**; implicitDeny on the other six | `lambda.amazonaws.com` |
|
||||
| the other 21 | implicitDeny on all 7 | — |
|
||||
|
||||
**So FOUR roles can read the table, not the two this file recorded.** The two
|
||||
`lookup` roles were missed by exactly the gap above: their grant is the inline
|
||||
`LookupRolePolicy`, and `list-attached-role-policies` returns nothing for them.
|
||||
|
||||
**Why the published sentence is nevertheless correct.** The question is not how
|
||||
many roles exist but which *people* they lead back to.
|
||||
|
||||
- The two **cfn-exec** roles trust `cloudformation.amazonaws.com` and nothing
|
||||
else. No human can assume them; they are reachable only by deploying a
|
||||
CloudFormation/CDK stack, which requires a principal who can deploy one.
|
||||
- The two **lookup** roles trust the account root, which delegates the decision
|
||||
to the caller's own identity policy. Simulated for `sts:AssumeRole` against
|
||||
both role ARNs, for all five users, reading `ResourceSpecificResults` (ten
|
||||
per-resource decisions, not five — `EvaluationResults` is one entry per
|
||||
**action**, and an earlier pass here asserted the wrong count):
|
||||
|
||||
| principal | assume `lookup-…-ca-central-1` | assume `lookup-…-us-east-1` |
|
||||
|---|---|---|
|
||||
| `user/pouya` | **allowed** | **allowed** |
|
||||
| `user/lars` | **allowed** | **allowed** |
|
||||
| `user/adr-sml-deploy` | implicitDeny | implicitDeny |
|
||||
| `user/gitea-deploy-meshkinilaw` | implicitDeny | implicitDeny |
|
||||
| `user/meshkini-backend-deploy` | implicitDeny | implicitDeny |
|
||||
|
||||
- The **CloudFormation escalation path this file named and left untested** —
|
||||
*"a real path to the table for anyone who can deploy a CDK stack"* — is now
|
||||
measured. Simulated for `cloudformation:CreateStack`, `UpdateStack`,
|
||||
`CreateChangeSet`, `ExecuteChangeSet`, `iam:PassRole` and `sts:AssumeRole`,
|
||||
five users × six actions = **30 decisions**, count asserted:
|
||||
|
||||
| principal | the CDK / CloudFormation path |
|
||||
|---|---|
|
||||
| `user/pouya` | **allowed** on all six |
|
||||
| `user/lars` | **allowed** on all six |
|
||||
| `user/adr-sml-deploy` | implicitDeny on all six |
|
||||
| `user/gitea-deploy-meshkinilaw` | implicitDeny on all six |
|
||||
| `user/meshkini-backend-deploy` | implicitDeny on all six |
|
||||
|
||||
This is the finding that mattered most, because `meshkini-backend-deploy` is by
|
||||
its name another project's backend-deploy credential and
|
||||
`gitea-deploy-meshkinilaw` is held on a **jointly administered** Gitea instance
|
||||
(Q23). Either one, had it been able to drive CloudFormation, would have read
|
||||
the table without appearing in the five-row table above — and *"Two people
|
||||
can"* would have been wrong. Neither can.
|
||||
|
||||
- **And the seven roles every sweep here had excluded BY CONSTRUCTION are now
|
||||
measured too.** Every role loop in this file filters `grep -v
|
||||
'^AWSServiceRole'`, and the assertion was written as *"twenty-six role rows"* —
|
||||
so a service-linked role was outside the claim rather than inside it, which
|
||||
matters because a service-linked role for a backup or migration service can
|
||||
read table contents. All **7** (`APIGateway`, `CloudFrontLogger`,
|
||||
`InternetMonitor`, `RDS`, `ResourceExplorer`, `Support`, `TrustedAdvisor`) are
|
||||
**implicitDeny on all seven actions** — 49 decisions, count asserted
|
||||
`[verified 2026-09-02]`. **So the enumeration is 33 of 33 roles, not 26 of
|
||||
33**, and the page's *"every user and every role in the account"* is now
|
||||
literally true. Raised by `adversarial-reviewer`, round 2.
|
||||
|
||||
- **There is no federated identity surface at all**: `list-saml-providers` **0**,
|
||||
`list-open-id-connect-providers` **0**, `sso-admin list-instances` **0**
|
||||
`[verified 2026-09-02]`. So "every user and every role" is not leaving out a
|
||||
federated principal, because there is none to leave out.
|
||||
|
||||
Every read path therefore terminates at `pouya` or `lars`. **The count of people
|
||||
is two, and it is now the result of an enumeration rather than of a policy name.**
|
||||
|
||||
**The account root user, recorded because an enumeration that quietly omits it is
|
||||
not an enumeration.** Root is not an IAM user and does not appear in
|
||||
`list-users`, so it cannot be simulated and no policy constrains it — root can
|
||||
always read the table. Two facts bound it: `get-account-summary` reports
|
||||
`AccountAccessKeysPresent: 0`, so **there is no programmatic root credential**,
|
||||
and `AccountMFAEnabled: 1`. Root access therefore requires the root password and
|
||||
its MFA device. **The page does not mention root and should not**: 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". Who holds the root credentials is not
|
||||
established in this repository; it is not a page-blocking fact, and it is noted
|
||||
here rather than guessed at.
|
||||
|
||||
**Two page sentences are now supported that were not before.**
|
||||
|
||||
- *"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.
|
||||
|
||||
**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
|
||||
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.)*
|
||||
|
||||
⚠️ **THE INSTRUMENT FAILED FIRST, UNIFORMLY, AND IN THE DIRECTION THAT READS AS
|
||||
CLEAN.** The role sweep was first run as `--action-names $ACTS` with the seven
|
||||
actions in a shell variable. **zsh does not word-split parameter expansions**, so
|
||||
`simulate-principal-policy` received **one** action name — the whole string — and
|
||||
answered it: `implicitDeny` for 22 roles, and `allowed` for the four with a `*`
|
||||
grant, because `*` matches a bogus action too. Twenty-two clean rows and a
|
||||
plausible four. The tell was the shape of the output, not the verdict: one
|
||||
decision per role where there should have been seven. **The fix is the assertion,
|
||||
not the memory** — the loop now counts `EvaluationResults` per call and refuses a
|
||||
row that does not carry exactly seven, and the users' assume check counts
|
||||
`ResourceSpecificResults` and refuses a row that does not carry exactly two.
|
||||
`CLAUDE.md` records this class five times over; this is the sixth, and it is the
|
||||
"uniformly good" half.
|
||||
|
||||
### Commands — the ones this addendum rests on
|
||||
|
||||
Read-only, run as `user/pouya` in `ca-central-1`. No stderr suppressed, exit
|
||||
status read on every call, and note the **literal** action lists: they are not in
|
||||
a variable, which is the whole point above.
|
||||
|
||||
```bash
|
||||
# 1. Inline policies — the command the original block never ran.
|
||||
aws iam list-roles --query 'Roles[].RoleName' --output text \
|
||||
| tr '\t' '\n' | grep -v '^AWSServiceRole' \
|
||||
| while IFS= read -r R; do
|
||||
aws iam list-role-policies --role-name "$R" --query 'PolicyNames' --output text
|
||||
done
|
||||
|
||||
# 2. Every non-service-linked role, seven actions, decision asserted per row.
|
||||
# The count check is what makes a broken call loud instead of clean.
|
||||
aws iam simulate-principal-policy \
|
||||
--policy-source-arn "arn:aws:iam::327082975128:role/<ROLE>" \
|
||||
--action-names dynamodb:GetItem dynamodb:Query dynamodb:Scan \
|
||||
dynamodb:BatchGetItem dynamodb:PutItem dynamodb:UpdateItem \
|
||||
dynamodb:DeleteItem \
|
||||
--resource-arns "arn:aws:dynamodb:ca-central-1:327082975128:table/adr-intake-submissions" \
|
||||
--query 'length(EvaluationResults)' --output text # must print 7
|
||||
|
||||
# 3. Trust policies of the four roles that can read.
|
||||
aws iam get-role --role-name <ROLE> --query 'Role.AssumeRolePolicyDocument'
|
||||
|
||||
# 4. Who can assume the two lookup roles — per RESOURCE, not per action.
|
||||
aws iam simulate-principal-policy \
|
||||
--policy-source-arn "arn:aws:iam::327082975128:user/<USER>" \
|
||||
--action-names sts:AssumeRole \
|
||||
--resource-arns "arn:aws:iam::327082975128:role/cdk-hnb659fds-lookup-role-327082975128-ca-central-1" \
|
||||
"arn:aws:iam::327082975128:role/cdk-hnb659fds-lookup-role-327082975128-us-east-1" \
|
||||
--query 'EvaluationResults[].ResourceSpecificResults[].{R:EvalResourceName,D:EvalResourceDecision}' \
|
||||
--output text # must print 2 rows
|
||||
```
|
||||
|
||||
```bash
|
||||
# 5. The CloudFormation / CDK escalation path, per user. Six actions, literal.
|
||||
aws iam simulate-principal-policy \
|
||||
--policy-source-arn "arn:aws:iam::327082975128:user/<USER>" \
|
||||
--action-names cloudformation:CreateStack cloudformation:UpdateStack \
|
||||
cloudformation:CreateChangeSet cloudformation:ExecuteChangeSet \
|
||||
iam:PassRole sts:AssumeRole \
|
||||
--query 'EvaluationResults[].{A:EvalActionName,D:EvalDecision}' --output text
|
||||
|
||||
# 6. Federated identity surfaces, and root.
|
||||
aws iam list-saml-providers --query 'length(SAMLProviderList)'
|
||||
aws iam list-open-id-connect-providers --query 'length(OpenIDConnectProviderList)'
|
||||
aws sso-admin list-instances --query 'length(Instances)'
|
||||
aws iam get-account-summary \
|
||||
--query 'SummaryMap.{AccessKeysPresentRoot:AccountAccessKeysPresent,MFA:AccountMFAEnabled}'
|
||||
```
|
||||
|
||||
**Five user rows and twenty-six role rows, or the run did not happen.** And for
|
||||
every simulation: **seven decisions per role call, six per CDK-path call, two
|
||||
per-resource decisions per assume call** — the counts are the assertion, because
|
||||
a call that silently received one bogus action name answers `implicitDeny` and
|
||||
reads exactly like a clean row.
|
||||
|
||||
@@ -13,6 +13,31 @@ cite it. Do not paraphrase a fact into a page that is not stated here.
|
||||
> date and effective date below is as at the retrieval date and nothing more.
|
||||
> Re-check before cutover, and before any republish that turns on one of them.
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> ⚠️ **THIS FILE CARRIES THE STANDING RE-CHECK INSTRUCTION ABOVE AND WAS
|
||||
> NOT ONE OF R18's SEVEN LIMBS, AND IT WENT UNSTAMPED IN THE FIRST PASS.**
|
||||
> Five of seven extracts were stamped and two were not, so a reader could
|
||||
> not tell whether this one was considered and found non-volatile or simply
|
||||
> missed. Found by `adversarial-reviewer`, 2026-09-02 — the same
|
||||
> control-fires-over-part-of-its-scope defect as R18 having no checklist
|
||||
> item, one notch smaller. **Nothing here was re-retrieved.**
|
||||
>
|
||||
> - **No R18 limb, but ONE CANDIDATE LIMB, and it is flagged rather than
|
||||
> silently adopted.** `/practice/construction/` publishes: *"Ontario Power
|
||||
> Generation … applied in March 2026 for a licence to operate it."* That is a
|
||||
> **pending application**, so it moves the way limb (a) moves. It is not
|
||||
> false today — the application was made, and a completed past act stays
|
||||
> true — which is why this is a note and not a blocker. But a reader takes it
|
||||
> as current status, and unlike limb (a) the sentence is **not time-anchored**
|
||||
> ("when this page was written"). **For Pouya at the next re-check: adopt it
|
||||
> as R18 limb (h), or time-anchor the sentence and drop it.**
|
||||
> - The rest is stable: Part II.1 in force since 2019-10-01, and ODACC's own
|
||||
> statement that it is the Authorized Nominating Authority. The ODACC 2025
|
||||
> Annual Report is cited for institutional facts rather than for figures, so
|
||||
> it does not carry limb (d)'s exposure `[verified 2026-09-02 — swept
|
||||
> `dist/practice/construction/index.html`]`.
|
||||
|
||||
**Topic as researched:** Ontario construction dispute resolution — the statutory machinery (Construction Act, R.S.O. 1990, c. C.30); plus verification of the OPG Darlington New Nuclear Project and Bruce Power's Bruce C Project
|
||||
|
||||
---
|
||||
|
||||
@@ -13,6 +13,20 @@ cite it. Do not paraphrase a fact into a page that is not stated here.
|
||||
> date and effective date below is as at the retrieval date and nothing more.
|
||||
> Re-check before cutover, and before any republish that turns on one of them.
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> The trigger fired. `AGENTS.md` §12 R18 holds the per-limb findings and
|
||||
> the sources; this stamp does not restate them. **The quoted bytes below
|
||||
> are still the original retrieval and were not re-fetched** — what was
|
||||
> re-checked is whether the *facts* they support have moved.
|
||||
>
|
||||
> - **(c) ERO 026-0853 — RE-VERIFIED UNMOVED** `[re-checked 2026-09-01 —
|
||||
> Pouya]`. The comment period to 2026-09-12 is still open.
|
||||
> - **(b) the regulation under `Electricity Act` s. 28.1 — NOT RE-RETRIEVED.**
|
||||
> Held unchanged on a cadence judgement rather than a fresh retrieval
|
||||
> `[assumed 2026-09-01 — Pouya: unchanged by its nature at this cadence]`.
|
||||
> That is a weaker stamp than (c) and is written weaker on purpose.
|
||||
|
||||
**Topic as researched:** Ontario electricity/energy regulatory processes that generate disputes: OEB leave to construct (OEB Act, 1998 ss. 90/92/95/96), the IESO and market participation, the IESO connection assessment process (SIA/CIA), large-load and data-centre grid connection (Electricity Act, 1998 s. 28.1), and Ontario Bill 40
|
||||
|
||||
---
|
||||
|
||||
@@ -13,6 +13,22 @@ cite it. Do not paraphrase a fact into a page that is not stated here.
|
||||
> date and effective date below is as at the retrieval date and nothing more.
|
||||
> Re-check before cutover, and before any republish that turns on one of them.
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> The trigger fired. `AGENTS.md` §12 R18 holds the per-limb findings and
|
||||
> the sources; this stamp does not restate them. **The quoted bytes below
|
||||
> are still the original retrieval and were not re-fetched** — what was
|
||||
> re-checked is whether the *facts* they support have moved.
|
||||
>
|
||||
> - **(d) the Tribunals Ontario annual report — RE-VERIFIED UNMOVED**
|
||||
> `[re-checked 2026-09-01 — Pouya,
|
||||
> <https://tribunalsontario.ca/en/about/governance-and-accountability/>]`.
|
||||
> **No 2025-26 report is published; FY2024-25 remains current**, so the
|
||||
> figures `/practice/insurance/` publishes are still the latest. This closes
|
||||
> the open item at the foot of this file, which asked exactly that question.
|
||||
> - **(e) the SABS, amended with effect 2026-07-01 — NOT RE-RETRIEVED.** Held
|
||||
> unchanged on a cadence judgement `[assumed 2026-09-01 — Pouya]`.
|
||||
|
||||
**Topic as researched:** Ontario accident benefits (SABS) disputes — regulation, Minor Injury Guideline, the LAT-AABS dispute route, tribunal caseload volume, mediation references in tribunal materials, and FSRA's role
|
||||
|
||||
---
|
||||
@@ -341,6 +357,7 @@ honest, and on this project it is the half that has twice been skipped.
|
||||
- **Whether a more recent annual report than 2024-25 exists (i.e. a 2025-26 report covering the year ending March 31, 2026).**
|
||||
- *Searched:* WebSearch for Tribunals Ontario annual report LAT AABS caseload; retrieved the 2024-25 report, which is dated June 30, 2025 and is the most recent surfaced.
|
||||
- *Outcome:* NOT CONFIRMED either way. The 2024-25 report (fiscal year ending March 31, 2025) is the latest located as of 2026-08-29, but no search was run specifically to rule out a 2025-26 edition. Given today's date, one may well have been published. Re-check before publishing any 'most recent' or 'latest available' framing around these figures.
|
||||
- *Outcome, R18 re-check:* **CONFIRMED — no 2025-26 edition is published, and FY2024-25 remains current** `[re-checked 2026-09-01 — Pouya, <https://tribunalsontario.ca/en/about/governance-and-accountability/>]`. This closes the item as originally posed. The caution in the line above is retained rather than struck, because it is about a FRAMING and not about this fact: nothing on `/practice/insurance/` calls these figures the most recent or the latest available, and nothing should start to — a 2025-26 edition will appear eventually and a bare year label goes stale gracefully where a superlative does not.
|
||||
- **What the SABS amendments effective July 1, 2026 actually changed.**
|
||||
- *Searched:* Noted the consolidation banner on the e-Laws SABS page ('From July 1, 2026') and the tribunal's warning that 'Changes to the Statutory Accident Benefits Schedule effective July 1, 2026 may impact your insurance benefits'. Did not fetch O. Reg. 383/24 or the amending instruments.
|
||||
- *Outcome:* NOT ESTABLISHED. Search-result snippets suggested that certain benefits became optional, but no primary amending regulation was fetched, so nothing about the substance of the July 2026 changes is asserted here. The s. 3(1) definitions and the s. 18(1) $3,500 limit quoted above ARE from the post-July-2026 consolidation and are current as retrieved.
|
||||
|
||||
@@ -13,6 +13,22 @@ cite it. Do not paraphrase a fact into a page that is not stated here.
|
||||
> date and effective date below is as at the retrieval date and nothing more.
|
||||
> Re-check before cutover, and before any republish that turns on one of them.
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> ⚠️ **THIS FILE CARRIES THE STANDING RE-CHECK INSTRUCTION ABOVE AND WAS
|
||||
> NOT ONE OF R18's SEVEN LIMBS, AND IT WENT UNSTAMPED IN THE FIRST PASS.**
|
||||
> Five of seven extracts were stamped and two were not, so a reader could
|
||||
> not tell whether this one was considered and found non-volatile or simply
|
||||
> missed. Found by `adversarial-reviewer`, 2026-09-02 — the same
|
||||
> control-fires-over-part-of-its-scope defect as R18 having no checklist
|
||||
> item, one notch smaller. **Nothing here was re-retrieved.**
|
||||
>
|
||||
> - **No volatile limb at this cutover.** The facts this file supports on
|
||||
> `/practice/shareholder/` are OBCA sections and case law, which do not move
|
||||
> at this cadence, and a sweep of the built page for dates, statuses and
|
||||
> "as of" framings returned nothing time-anchored `[verified 2026-09-02 —
|
||||
> swept `dist/practice/shareholder/index.html`]`.
|
||||
|
||||
**Topic as researched:** Ontario/Canada shareholder, partnership and closely-held business disputes — statutory remedies (oppression, dissent/appraisal, winding up), the Partnerships Act, arbitration references in the corporations statutes; plus an independent re-check of Ontario family arbitration training requirements.
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user