Site: four-intent structure, interim Supporter signing, Participate and registers, temporary Review page

[artvana]

Rebuilds pdpp.dev around the four intents, adds the interim Supporter signing system behind a flag, ships the conformance registers, and adds a temporary Review page.

Branched off main at f1e8357d, after #267 merged. The design handoff is committed at design_handoff_pdpp_site/.

Routes

Route	What it is
/	Hero with the repo's scrolling data columns, the OAuth-versus-grant comparison, the six principles, the Supporters register, and the entry to Build.
/principles	Preamble and the six principles rendered from the repo-root PRINCIPLES.md, who can sign, the signing form, and the public register.
/specification	spec-core.md in the reader, with a contents rail of Core's nine sections, the informative documents, and Appendix A. GOVERNANCE.md renders inline at #governance, above it the four-stage diagram.
/build	The three role cards, running the reference implementation, and the community FAQs.
/participate	Three levels, four verification steps, the status table, both registers, and the contact channels.
/review	Temporary. What to read, how to comment, what happens to a comment. Behind reviewOpen in the nav and ticker; the page itself always resolves.
/privacy	Controller, purposes, what is stored, what is published, retention, confirmation and withdrawal, contact. All from config.
/governance	308s to /specification#governance. The standalone route is gone.

Nav is the four items with a Specification dropdown holding "The specification" and, behind reviewOpen, "Review, until 1 Oct". The full-width ticker under the header is one link wrapping a CSS marquee: two identical tracks translated by exactly -50% so the loop seam is invisible, ~55s, paused rather than hidden under prefers-reduced-motion.

Theme is the repo's existing PdppThemeSwitch and ThemeProvider, already keyed to pdpp-theme. The wordmark is the repo's existing WordmarkIcon; fonts are the repo's own loading, not the export's Google Fonts.

/review and the reader's version strip are the only places the review period is named, so retiring it is the flag plus one page.

Signing data flow

form on /principles
   |  POST /api/sign — rate limit, strict schema, organisation-domain rule
   v
pending store (KV, 48h TTL) ---- expires, leaving nothing ----> gone
   |  the signatory uses the single-use confirmation link
   v
PRIVATE repo: signatories/<yyyy>/<id>.json, committed by a bot
   |  scheduled publish, five fields only
   v
PUBLIC repo: apps/site/public/principles/supporters.json
   |
   v
/principles

Three properties hold it together:

• An unconfirmed submission leaves no residue. It lives only in a TTL store until the person who owns the address acts.
• One direction only. The site writes to the private repo; the private repo writes to the public one. The public site holds no credential that can read the private store.
• The publish script is an allowlist. It names the five public fields one at a time rather than deleting the private ones, so a record that grows a field cannot leak it.

Single use is enforced by GETDEL on the pending record, not by the token: an HMAC is stateless, so check-then-read-then-delete would leave a window where two clicks both write a signatory file. The withdraw link deliberately never expires — a signatory keeps the email and may act on it a year later.

Every seam fails closed with SigningUnavailableError rather than degrading. A degrading seam would accept a signature, tell the signatory it worked, and drop it.

None of the signing system has run. The KV store, the mail provider and the deploy key do not exist. Treat the request shapes as the intended contract, to be checked against each provider's documentation when provisioned.

The private store

Not created here, by agreement: it holds personal data and its settings need org-level rights I do not have. Staged at ~/Desktop/claude-projects/supporters-private-staging/, outside this repo, ready to push to PDP-Connect/supporters-private:

• README.md — what it holds, who may read it, handover and deletion.
• scripts/publish-supporters.mjs — the allowlist publisher.
• scripts/export-list-optins.mjs — prints opted-in addresses to stdout for a one-off manual subscribe. Sends nothing.
• .github/workflows/publish-supporters.yml — scheduled, not signature-triggered, so a confirmation cannot make the public commit timing a side channel about when someone signed.
• SETTINGS-CHECKLIST.md — private, collaborators, forking off, secret scanning, branch protection, deploy key, and every Vercel secret.

docs/registers.md in this repo documents all three stores, the flow, access, and the handover procedure.

Registers

/register/index.json ships []; /register/trust-registries.json holds the one recognised entry, the Data Transfer Initiative's Data Trust Registry. Both are PR-driven and hold no personal data, both render on /participate. Issue templates apply-source.md, apply-accessor.md and apply-operator.md list what to attach per GOVERNANCE.md Appendix A. The Operator button is inert with its date until operatorApplications.

Config still needing real values

Every one renders a visible bracketed placeholder until set, so nothing guessed ships as fact.

• NEXT_PUBLIC_PDPP_CONTROLLER_NAME — decided: the Vana Foundation, holding the register until LFDT hosting is confirmed. Shipped as a default, still env-overridable.
• NEXT_PUBLIC_PDPP_GENERAL_CONTACT — decided: support@vanafoundation.org. The footer's General contact, never the reports address.
• NEXT_PUBLIC_PDPP_PRIVACY_CONTACT — defaults to the general address. Split it by setting this when a dedicated mailbox exists.
• NEXT_PUBLIC_PDPP_FORM_ENDPOINT — where the form posts
• NEXT_PUBLIC_PDPP_EMAIL_PROVIDER — named in config; the route currently targets Resend's API
• NEXT_PUBLIC_PDPP_DISCORD_URL
• NEXT_PUBLIC_PDPP_MAILING_LIST_URL
• Flags: NEXT_PUBLIC_PDPP_REVIEW_OPEN, NEXT_PUBLIC_PDPP_SIGNING_LIVE, NEXT_PUBLIC_PDPP_OPERATOR_APPLICATIONS — all default off
• Server secrets: PDPP_SIGNING_TOKEN_SECRET, PDPP_KV_REST_API_URL, PDPP_KV_REST_API_TOKEN, PDPP_MAIL_API_KEY, PDPP_MAIL_FROM, PDPP_PRIVATE_REPO_OWNER, PDPP_PRIVATE_REPO_NAME, PDPP_PRIVATE_REPO_TOKEN
• In the private repo: PDPP_PUBLIC_REPO_TOKEN

Where the two sources disagreed

• Hero. The prototype puts a grant card right of the hero text; the design export and the brief's own addition put the scrolling data columns there. Columns used, which also stops the grant card appearing twice, since it carries the comparison below.
• Section citations. /build's prototype copy is built on § citations, and the brief removes section citations from site copy outside the reader and /review. Links kept as wayfinding but named ("Source declaration" rather than "Core §5"); they land on the same anchors. A grep of the built site finds zero § on /, /principles, /build, /participate and /privacy.
• Supporters table. The prototype shows six example rows and "[ 247 ] signatories", labelled layout-only. An empty state ships instead: supporters.json is [], and a page showing invented signatories has published a false register.
• Governance lede. The prototype's governance section says "Both are open for comment until 1 October: how to comment". That names the review period outside /review, so the clause is dropped.

Copy deltas 1 to 5 are all applied.

Verification

pnpm spec:check passes. pnpm --dir apps/site types:check, test (202 passed, 0 failed), check and build all pass, 68 pages generated.

Served the production build: all seven routes 200, /governance 308s to /specification#governance, the rail renders the three groups, and the governance document renders inline.

Grep of the built site finds one email address, the reports mailbox, plus user@example.com inside spec-collection-profile.md's own JSON example, which is pre-existing spec text on a reserved example domain. bot@pdpp.dev appears in source as the git committer identity the GitHub contents API requires; it is not a mailbox. No private-store content is tracked in this repo.

Five sandbox files are reformatted by the repo's own formatter. They are unrelated to this change and were already failing pnpm check on main (20 errors there); fixing them is what makes this branch green.

Assisted-by: AI

🤖 Generated with Claude Code

https://claude.ai/code/session_01NECjjZbYWNTzq3bu7nuiDP

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
pdpp	Ready	Preview	Sep 3, 2026 1:54pm UTC

[artvana]

@tnunamak @annakaz — review context for all three open PRs, and the order to take them, is in one comment on #279: #279 (comment)

This one is independent on the branch graph but coupled in content: /specification renders the repo-root GOVERNANCE.md, so #279's text lands on the site the moment it merges. Until then that section still shows Official Source and Steward.

[artvana]

Pushed 4d2c3269: every surface that would put personal data in the private repository is now held in a waiting state, pending Kat F. on the right approach.

The gate is "would this collect someone's details", not "is it a list". Three places claimed signing was open and no longer do:

• The signing section keeps its place on /principles and carries a waiting panel: not taking signatures yet, why, and a link to the specification instead, so someone who came to support the work can still comment on it this week.
• /participate Level 2 said "Open now"; it now says signing opens once the register has a confirmed home, and links to the Principles document rather than to a form that is not there.
• The Pre stage in the governance diagram said "you can sign now".

Discord and the mailing list no longer render an unset config value as a live link (href="[mailing list URL not set]"); they show "Link to follow" until the destination is real. The mailing list opt-in needed no change, since it lives inside the form and the form is absent while signingLive is off.

Nothing here changes the conformance register, which is PR-driven and holds no personal data.

Verified on the served build: no page claims signing is open, and no placeholder href renders.