feat: execution protocol, review agents, DNS and SES findings
Build and deploy / build-and-deploy (push) Failing after 6s
Build and deploy / build-and-deploy (push) Failing after 6s
This commit is contained in:
@@ -0,0 +1,91 @@
|
||||
---
|
||||
description: The standing execution loop for this repo — plan, implement, adversarial review, resolve, verify, record. Use for every substantive change.
|
||||
argument-hint: <what to build, e.g. "the /med-arb/ page" or "step 4 of the build order">
|
||||
---
|
||||
|
||||
**ultrathink**
|
||||
|
||||
Task: $ARGUMENTS
|
||||
|
||||
Execute the six-phase loop below. Do not skip a phase because the task looks
|
||||
small — the loop is the quality mechanism, not ceremony. If a phase genuinely
|
||||
does not apply, say which and why before moving on.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 — Plan (think hard before writing anything)
|
||||
|
||||
1. Read `AGENTS.md` in full if you have not this session. Read **§12 Standing
|
||||
Reminders** and surface anything live to Pouya before you start.
|
||||
2. Read the specs in `docs/` that bear on this task.
|
||||
3. Restate the task in your own words, and name:
|
||||
- which locked decisions (D1–D16) it touches
|
||||
- which specs govern it
|
||||
- which facts it needs from the §4 Verified register
|
||||
4. **Stop and ask if you find a conflict** — between the task and a locked
|
||||
decision, between two specs, or between the task and a fact you do not have.
|
||||
A blocked build is a correct build. Never resolve a conflict by guessing, and
|
||||
never soften a claim to make it defensible.
|
||||
5. State your plan before implementing.
|
||||
|
||||
## Phase 2 — Implement
|
||||
|
||||
Follow `CLAUDE.md` conventions. Zero JavaScript by default. Tokens only, no raw
|
||||
hex, no magic numbers. Semantic HTML. Every page gets its metadata.
|
||||
|
||||
Where you need a fact you do not have: `TODO(pouya): <the exact question>` in the
|
||||
source **and** a new numbered question in `AGENTS.md` §9. Do not invent it.
|
||||
|
||||
## Phase 3 — Adversarial review (this is not optional)
|
||||
|
||||
Invoke **both** review agents on the change, in parallel:
|
||||
|
||||
- `adversarial-reviewer` — correctness, accessibility, crawlability,
|
||||
performance, security, simplicity
|
||||
- `claims-auditor` — every factual assertion traced to `AGENTS.md` §4
|
||||
|
||||
**Give them the diff and the specs. Do not give them your reasoning for why the
|
||||
work is correct.** Your rationale anchors the reviewer and produces agreement
|
||||
instead of review. They form their own view from the artefact; that independence
|
||||
is the whole point of the phase.
|
||||
|
||||
If the change touches no user-facing copy, `claims-auditor` may be skipped — say
|
||||
so explicitly.
|
||||
|
||||
## Phase 4 — Resolve
|
||||
|
||||
For every finding: **fix it, or decline it with a stated reason.** Silence is not
|
||||
a response. A declined finding is recorded in the Change Log with the reasoning,
|
||||
so a later reader can see the judgement was made rather than missed.
|
||||
|
||||
If you fix anything material, **re-run Phase 3 on the fix.** A patch written
|
||||
under review pressure is exactly where the second defect lives.
|
||||
|
||||
## Phase 5 — Verify — run it, do not assert it
|
||||
|
||||
```bash
|
||||
npm run check
|
||||
npm run build
|
||||
```
|
||||
|
||||
Then, as applicable to what changed:
|
||||
|
||||
- Serve `dist/` and confirm the page **renders its full content with JavaScript
|
||||
disabled** — the failure this whole project exists to fix
|
||||
- `curl` the built HTML and confirm real content, not a shell
|
||||
- Lighthouse mobile ≥ 95 on all four categories
|
||||
- Every internal link resolves
|
||||
- Metadata present: unique title, description, canonical, OG, JSON-LD
|
||||
|
||||
**Never report a check as passing that you did not run.** "Should pass" is not a
|
||||
result. If you could not run something, say which and why.
|
||||
|
||||
## Phase 6 — Record
|
||||
|
||||
Append a `AGENTS.md` Change Log entry, newest first: what changed, old → new,
|
||||
why, and any decision or plan — including declined findings and anything
|
||||
deferred. Update Current Truth in place where the change made a section stale.
|
||||
Re-stamp facts you re-checked with today's date.
|
||||
|
||||
Then report to Pouya: what shipped, what the review found, what you declined and
|
||||
why, and what remains open.
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
description: Run the adversarial review pass on demand — on the working tree, a commit range, or named files.
|
||||
argument-hint: [what to review — defaults to uncommitted changes]
|
||||
---
|
||||
|
||||
**ultrathink**
|
||||
|
||||
Scope: $ARGUMENTS
|
||||
|
||||
If no scope is given, review the uncommitted working tree (`git status`,
|
||||
`git diff`).
|
||||
|
||||
Invoke **both** agents in parallel on that scope:
|
||||
|
||||
- `adversarial-reviewer`
|
||||
- `claims-auditor` — unless nothing user-facing changed, in which case say so
|
||||
|
||||
Give them the diff and the relevant specs from `docs/`. **Do not brief them on
|
||||
why the code is correct** — that anchors the review and turns it into agreement.
|
||||
|
||||
Report findings grouped by severity, most severe first. For each: the defect, the
|
||||
concrete failure it produces, and the fix. Do not fix anything yet — Pouya
|
||||
decides what gets addressed. Then ask what he wants done.
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
description: End-of-session ritual — update AGENTS.md under its constitution and hand back a clean state.
|
||||
---
|
||||
|
||||
Close out this session properly. The working file is the deliverable that
|
||||
outlives the session; a session that ends without updating it has lost its
|
||||
reasoning.
|
||||
|
||||
1. **Re-read `AGENTS.md`** — the constitution at the top, then Current Truth.
|
||||
|
||||
2. **Update Current Truth in place** wherever this session made a section stale:
|
||||
environment, decisions, the §4 register, open questions, risks. Re-stamp any
|
||||
fact you re-verified with today's date. A stale date means it needs
|
||||
re-checking, so do not leave a date you did not earn.
|
||||
|
||||
3. **Append one Change Log entry**, newest first, covering:
|
||||
- what was discussed, decided, changed, or planned — **decisions and plans
|
||||
count even if no code was written**
|
||||
- old → new for every change, and why
|
||||
- findings you declined, with the reasoning
|
||||
- anything deferred, and where it is now tracked
|
||||
- questions closed and questions opened, by number
|
||||
|
||||
**Never edit a past entry.** If something earlier was wrong, correct it in
|
||||
today's entry and leave the original as written.
|
||||
|
||||
4. **Check §12 Standing Reminders.** Is anything now due? Should something new
|
||||
be added — a decision Pouya parked, or one you made on his behalf that he has
|
||||
not yet ratified?
|
||||
|
||||
5. **Leave the tree clean.** `git status` should show only intended changes. No
|
||||
stray build output, no `.env`, no credentials, no `aws-inventory.txt`.
|
||||
|
||||
6. Report: what changed in `AGENTS.md`, what is open, and the single most useful
|
||||
next action.
|
||||
Reference in New Issue
Block a user