adr.smlcompany.ca

The dispute resolution practice of Pouya Lajevardi — Toronto.

A static site built with Astro, built for deployment to Amazon S3 behind CloudFront by Gitea Actions — see Deployment; the pipeline is not yet proven.

Quick start

nvm use            # Node 22
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 lighthouse	Lighthouse CI — not yet wired; nothing to measure until pages exist
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.