Files
adr-sml/README.md
T
Pouya LajevardiandClaude Opus 5 7514a49803 feat: upgrade to Astro 7; harden the content schema; wire a11y linting
Amends D1 to pin the major explicitly (v7.x) rather than inherit it. The
^5.0.0 pin was recalled rather than checked and was two majors stale the day
it was written, which meant shipping a framework carrying high-severity XSS
advisories. CLAUDE.md now requires every version pin to be verified against
the registry, and R11 requires re-checking at each build-order boundary.

npm audit now reports 0 vulnerabilities, down from 16. Every Astro advisory
is cleared; the residual 10 all traced to @lhci/cli, which is removed — it
was the sole source of 7 high-severity findings, 0.15.1 is latest so there
was no clean upgrade, and it cannot run without pages or a lighthouserc.
Re-added at build step 7 with a freshly verified pin.

Content collections migrated to the Content Layer API: src/content.config.ts,
loader: glob(), z from astro/zod.

Two review passes found seven defects in the fix itself, all now closed:

- z.coerce.date() read an unquoted 20260801 as epoch milliseconds and
  yielded 1970-01-01 silently; the first replacement then accepted
  2026-13-45 as an Invalid Date and rolled 2026-02-30 over to 2026-03-02.
  Dates are now anchored, date-only, parsed as UTC and round-tripped.
- The title bound applied the SEO spec's 50-60 to the headline rather than
  the rendered <title>, which guaranteed 68-78 on every article and rejected
  all five planned launch headlines. Articles are now the documented
  exception: the headline is the <title>, no suffix.
- An article could ship an image with no alt text, or whitespace-only alt.
- Two schema comments asserted controls nothing enforced; both are now real
  refinements, each tested with a failing and a passing case.
- PRACTICE_SLUGS and PRACTICE_AREAS could drift silently; a compile-time
  check now catches both directions.
- eslint.config.js imported globals and @eslint/js undeclared, resolving by
  hoisting accident.
- scripts/deploy-local.sh claimed parity with CI while skipping npm run
  check and two credential guards — on the only path this site can ship
  today.

Accessibility linting is on (36 jsx-a11y rules) before step 1 writes the
layout. An earlier claim in §7 that none was possible was wrong twice, and
is corrected in AGENTS.md entry (t) along with the reasoning.

Opens Q30 and Q31 for two unregistered claims in src/data/site.ts.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012XquaEq4BgWMCwUqLEyNkF
2026-08-26 14:10:09 -04:00

104 lines
4.9 KiB
Markdown

# adr.smlcompany.ca
The dispute resolution practice of Pouya Lajevardi — Toronto.
A static site built with [Astro](https://astro.build), built for deployment to
Amazon S3 behind CloudFront by Gitea Actions — see Deployment; the pipeline is
not yet proven.
## Quick start
```bash
nvm use # Node 22 LTS — the floor is in package.json engines
npm install
npm run dev # http://localhost:4321
```
## Scripts
| Command | Does |
|---|---|
| `npm run dev` | Development server with hot reload |
| `npm run build` | Static build to `./dist` |
| `npm run preview` | Serve the built site locally |
| `npm run check` | `astro check` — type and template errors |
| `npm run lint` | ESLint + Prettier check |
| `npm run format` | Prettier — rewrite files in place |
| `npm run deploy` | Build and deploy from this machine — see Deployment |
## Before you contribute
Read **`AGENTS.md`** first, and maintain it as you work — it is the living
record of what this project is, what was decided, and why. Then read
**`CLAUDE.md`** for the working rules, and the specs in `docs/`.
The single hardest rule: **no factual claim about Pouya, his credentials, his
experience, or his practice ships unless it appears in the verified register in
`AGENTS.md` §4.** This is a public marketing surface, and the site it replaces
contained fabricated credentials.
## How work is done here
Pouya decides; Claude Code implements and then adversarially reviews its own
work. Run **`/build <task>`** for any substantive change — it plans, implements,
runs two independent review agents on the diff (the claims audit wherever copy
changed), resolves the findings, verifies the build, and records the session in
`AGENTS.md`. `/review` runs the review pass alone; `/wrap` closes a session.
Full protocol and prompt guidance: `docs/08-execution-protocol.md`.
## Deployment
**Today, deploys run locally: `npm run deploy`** (`scripts/deploy-local.sh`).
It runs the same guard, the same three sync passes with the same cache headers,
and the same invalidation as the CI workflow — at this scale the pipeline
changes only *how* a deploy is triggered, not what it does. The script and
`.gitea/workflows/deploy.yml` are one artefact in two places: change one, change
both.
`.gitea/workflows/deploy.yml` is the CI pipeline — **Gitea Actions**, not GitHub
Actions. **It has never run**, for two reasons that are not oversights:
- The scoped IAM user does not exist. `aws iam get-user --user-name
adr-sml-deploy` returns `NoSuchEntity` (`AGENTS.md` Q22).
- Actions are not enabled and no runner is registered. The Gitea instance is
jointly administered, so both need its second administrator (Q23).
Its **first** step is a guard: the run aborts, naming what is missing, if any
required variable or either AWS secret is empty. Only emptiness is tested and no
value is echoed.
The GitHub Actions equivalent, which uses OIDC role assumption, is kept as
`docs/reference/github-actions-oidc.yml.example` in case the project ever moves
to a forge that supports it. It sits outside `.github/workflows/` on purpose:
Gitea falls back to that directory when `.gitea/workflows` is absent, so a
workflow file left there with a `push` trigger would be only conditionally
inert. As an `.example` under `docs/` it cannot be picked up at all.
**The pipeline is designed around a long-lived AWS credential, and it does not
exist yet.** Gitea is not an AWS OIDC provider, so there is no role to assume:
deploys are *to* authenticate as a scoped IAM user, `adr-sml-deploy`, with its
access key in the repository's Gitea Actions secrets. `aws iam get-user`
confirms that user has not been created (Q22). In the meantime the local script
**refuses to run as `user/pouya`**, the broadly-permissioned personal user —
see `AGENTS.md` §10. Two things are meant to bound the risk, and neither is in
place yet:
- **The policy must stay narrow.** Four actions: `s3:ListBucket` on one bucket,
`s3:PutObject` and `s3:DeleteObject` on that bucket's contents, and
`cloudfront:CreateInvalidation` on one distribution. No `Action: "*"`, no
`Resource: "*"`, nothing outside that one bucket and that one distribution.
The AWS account is shared with unrelated projects, including a bucket whose
name indicates another business's production database backups — that
narrowness is what keeps a compromised runner away from it, and it is
load-bearing rather than hygiene. See `AGENTS.md` §10. If a deploy step needs
a permission the policy lacks, question the step; do not widen the policy.
- **The key must be rotated quarterly, and nobody owns that yet.** Create a
second access key, update the Gitea secrets, confirm a deploy succeeds, then
delete the old one — rotation that leaves the old key active is not
rotation. OIDC would have removed the obligation entirely; it is
unavailable, so this is a standing calendar task still waiting on an owner.
Full procedure, IAM policy, runner setup, and cutover checklist:
`docs/06-deployment.md`.