SITE v3.2: a FEEDBACK tab, signature only, no gas, and the weekly loop that turns it into builds. WHY: the operator cannot navigate the site without an AI at their side; the people it is for will not have one. We want the users to tell us what is wrong and what to build, be told up front what cannot change, and have the IMD oracle panel pick what gets built each week.

1. THE TAB. A fifth composer tab 'Feedback' on the home screen (after Launched tokens). Fields: kind (Site · Mechanics · Idea), text up to 600 UTF-8 bytes, optional X handle. Posting = the connected wallet signs an EIP-191 personal_sign over the exact JSON {site:'marginalia.chat', week:<unix/604800>, kind, text, handle} and the page POSTs {message, signature, address} to the same-origin route /api/feedback. No gas, no approval, no token movement; say so in one line above the form. Rate: one entry per wallet per hour, 10 per wallet per week, enforced by the route.
2. WHAT IS FIXED, SAID FIRST. Above the form, a short list titled 'Cannot change (immutable contracts)': noted MARG sells pay 1% + 0.1 IMD stamp, quiet sells 3%; every note costs 0.1 IMD stamp + 0.25 IMD of MARG the author keeps + a 0.25–10 IMD bond; accruals split 70% weekly thesis pool / 30% daily writer refunds; a thesis needs its author's child call within 7 days; theses are ranked by the IMD oracle panel; a call's baseline is the venue's 1–6 hour price window (the checkpoint) and every venue needs one; the Annex venue rule; Pages (when live) is a capped curve 0.05 IMD × n to 10 IMD at page 200, 10 per wallet, 80/10/10, buy gate whitelist OR 10,000 MARG OR a posted note; one token, no second MARG ever; nothing is advice. Then 'Open to change': the site, its copy and flows, agents.md/llms.txt, the keeper, new modules alongside the existing contracts. Ideas that ask for price action, rewards, promotion or a new token are accepted but will rank zero.
3. THE WEEK'S BOARD. Under the form: this week's entries newest first (kind, text, short address or handle, a 'posted a note' badge when the address has a NotePosted on the hook or Annex, read from chain), a 'Picked this week' card listing the panel's ranked entries when the week's pick exists, and 'Adopted' = the append-only ledger of shipped builds (week, the entry ids it implemented and each one's share, synthesis yes/no, attestation request id, PR commit). Read all of it from public JSON at /api/feedback/.json (entries) and /api/feedback/adopted.json; no third-party scripts.
4. THE INTAKE ROUTE, delivered as code we deploy: web/worker/feedback.js, a Cloudflare Worker module (fetch handler; KV binding FEEDBACK) that we mount on the worker already serving the site. POST /api/feedback: verify the EIP-191 signature recovers address (use viem or @noble, no network call), check week == current, text ≤ 600 bytes, rate limits via KV, derive id = keccak256(address, week, text), store the entry, return {id}. GET /api/feedback/.json and /api/feedback/adopted.json: public, CORS same-origin, cache 60s. GET /api/feedback/today.json = the current week's document with fields {site, week, brief:{audience, scope, immutable:[...], open:[...]}, adopted:[ids], entries:[{id, address, handle, kind, text, ts, noted:bool}]} — this exact shape is what the oracle question will name. Also write web/worker/README.md: how to bind KV and mount the route next to the existing asset handler, and the one-line adopted.json append we will do by hand after each build. Tests for signature recovery, id derivation, rate limits and the document shape.
5. THE LOOP, documented for us and for agents in docs/loop.md and a section in agents.md: every Sunday 00:00 UTC the operator asks the IMD oracle one ranking question (answerType bytes32[], head 3, evidence panel, guards.allow = the week's entry ids, definitions.document = the public today.json) worded: rank the entries that would most improve the product for its audience, judged by concrete and implementable in one iteration, consistent with the immutable list, specific about the user problem, not a duplicate of an adopted entry; ignore length, author and popularity; entries asking for price action, rewards, promotion or a token score zero. All ranked entries go verbatim, with their ids and authors, into the next site continuation under a fixed header (read docs/loop.md first; implement the ranked entries, as one pick or as a SYNTHESIS that brings several together when they fit, and say which; never regress an adopted item; no token, mint, fee or payment path; append the adopted ledger). The build must declare a credits file, docs/credits/.json = {week, attestationRequestId, implemented:[{id, author, share}], notImplemented:[{id, why}], synthesis:bool}, that matches what the diff actually implements; the review step fails the delivery when it does not. Credit comes from that file, never from us. Write that fixed header into docs/loop.md so every future brief copies it. Review steps on every future continuation must fail a delivery that regresses an adopted item or adds token code.
6. MEMORY FOR FUTURE JOBS: create docs/CHANGELOG.md (one dated line per delivered job so far, from the project's job history: hook launch, site v1, v2, v3, v3.1, this one; what shipped, what was fixed, commit) and docs/STATUS.md (what is live and where: contracts with addresses and verification, site version and CID, the Annex, Pages pending its address; what is open from docs/FEEDBACK.md-style items; what cannot change). Every future continuation reads docs/loop.md, docs/STATUS.md and docs/CHANGELOG.md first and appends to both before delivering; put that sentence into the fixed header in docs/loop.md and into agents.md.
7. EVERYTHING ELSE UNCHANGED: stack, manifest, caveat, approvals, copy rules (no buy, no price, no chart links). Also: suppress the 'venue is not stored on chain' notice after a THESIS post (a thesis has no venue); keep it for priced calls. Deliver into this project's repository as before.