Refresh README, docs, and Codex workflows

AGENTS.md

@@ -5,6 +5,8 @@
 - This repository is `open-proofline/web-client`.
 - This is the Proofline web client only. The current backend source of truth is
   `open-proofline/server`.
+- The project-level public governance, political alignment, public voice, and
+  reusable README baseline source of truth is `open-proofline/website`.
 - Do not implement backend features here.
 - Do not add browser decryption unless explicitly scoped and threat-modeled.
 - Do not add recording or capture behavior here.
@@ -38,6 +40,17 @@
 
 ## Commands
 
+For documentation or reusable-prompt-only changes:
+
+```bash
+npx prettier --check \
+  README.md AGENTS.md SECURITY.md CHANGELOG.md \
+  docs/*.md codex/*.md codex/prompts/*.md
+git diff --check
+```
+
+For frontend source, route, browser-flow, auth, API-client, or behavior changes:
+
 ```bash
 npm run typecheck
 npm run lint
@@ -56,3 +69,10 @@ Check that changes remain frontend-only, do not overpromise production status,
 do not introduce browser decryption or key unwrapping, keep token persistence
 explicit and reviewable, preserve accessible loading/error/empty states, and
 keep server facts tied back to `open-proofline/server`.
+
+When changes touch README structure, public voice, governance,
+cooperative/public-good framing, political alignment, funding posture, or
+source-of-truth mapping, check the current `open-proofline/website` README,
+`docs/governance-and-political-alignment.md`, and
+`docs/repository-readme-baseline.md` instead of rewriting those project-level
+claims here.

CHANGELOG.md

@@ -2,6 +2,11 @@
 
 ## Unreleased
 
+- Refreshed README, documentation, and reusable Codex workflow guidance to
+  consume the website repository's governance, public voice, source-of-truth
+  map, and README baseline while preserving web-client-specific boundaries.
+- Clarified that server-supported account second-factor routes remain outside
+  the current web-client UI and API-client method surface.
 - Documented end-user web-client product design direction for user-facing
   language, trusted-contact invite/accept flows, viewer-link UX, future viewer
   map/location behavior, future browser capture framing, and product-design

SECURITY.md

@@ -2,17 +2,27 @@
 
 Proofline Web Client is experimental and not production-ready.
 
+Do not report security vulnerabilities through public GitHub issues. Use GitHub
+private vulnerability reporting where available, and keep sensitive details out
+of public issues, PRs, docs, prompts, screenshots, logs, and examples.
+
 Do not report real secrets, raw session tokens, browser session cookies, CSRF
 tokens, raw viewer tokens, token-bearing viewer links, Authorization headers,
-request bodies, plaintext, raw keys, wrapped-key ciphertext, verification
-credentials, private deployment details, or user safety data in public issues.
+request bodies, uploaded bytes, plaintext, raw keys, raw media keys, contact
+private keys, wrapped-key ciphertext, verification credentials, stored paths,
+object keys, private deployment details, exploit details, or user safety data in
+public issues.
 
 Backend security issues may belong in
 [`open-proofline/server`](https://github.com/open-proofline/server). Web-client
 issues involving XSS, dependency risk, browser token handling, local storage,
 browser-cookie auth, CSRF handling, credentialed CORS, or UI disclosure should
 be handled carefully and without public sensitive details.
 
+Project-wide governance, public-good posture, and public voice belong in
+[`open-proofline/website`](https://github.com/open-proofline/website). They are
+not a substitute for component-specific security review.
+
 This repo does not implement recording, browser decryption, backend decryption,
 trusted-contact decryption, key escrow, playable media export, emergency
 dispatch, or production safety workflows.

codex/README.md

@@ -6,6 +6,16 @@ The web-client repository is frontend-only. `open-proofline/server` remains the
 source of truth for current backend behavior, routes, security model, and
 deployment constraints.
 
+`open-proofline/website` is the project-level source for Proofline public
+governance posture, political alignment, cooperative/public-good framing,
+public voice, reusable README structure, and source-of-truth mapping. When a
+task touches those areas, inspect the current website README,
+`docs/governance-and-political-alignment.md`, and
+`docs/repository-readme-baseline.md` before editing this repo.
+
+Codex output is maintainer-reviewed work. It is not an audit, certification,
+security review, legal review, or endorsement by OpenAI.
+
 ## Prompts
 
 - `00-project-context-check.md`: read repo context before changes
@@ -29,6 +39,17 @@ deployment constraints.
 
 ## Standard Validation
 
+For documentation or reusable-prompt-only changes:
+
+```bash
+npx prettier --check \
+  README.md AGENTS.md SECURITY.md CHANGELOG.md \
+  docs/*.md codex/*.md codex/prompts/*.md
+git diff --check
+```
+
+For frontend source, route, browser-flow, auth, API-client, or behavior changes:
+
 ```bash
 npm run typecheck
 npm run lint

codex/prompts/00-project-context-check.md

@@ -14,19 +14,29 @@ Read relevant local files first:
 - `CHANGELOG.md`
 - `docs/README.md`
 - relevant `docs/` files
+- `codex/README.md`
+- relevant `codex/prompts/` files
+- `package.json`
 - relevant source, route, API, auth, and test files
 - relevant issue or PR
 
 For backend facts, treat `open-proofline/server` as the external source of
 truth. Do not turn server planning docs into web-client implementation claims.
 
+For governance, political alignment, public-good framing, public voice,
+repository README structure, and source-of-truth mapping, treat
+`open-proofline/website` as the external source of truth. Inspect its current
+README, `docs/governance-and-political-alignment.md`, and
+`docs/repository-readme-baseline.md` when those topics are involved.
+
 ## Output
 
 Return:
 
 1. current web-client scope
 2. current frontend surfaces
-3. backend assumptions that need server-doc confirmation
+3. source-of-truth inputs checked, including backend or website docs when
+   relevant
 4. security boundaries and non-goals
 5. likely affected files
 6. files or areas that must not change

codex/prompts/05-codex-change-control.md

@@ -14,16 +14,31 @@ Do **not** change code or docs unless explicitly asked.
   OAuth, JWT, push/SMS/Messenger notifications, public admin dashboards, mobile
   client code, or protocol repository behavior unless explicitly scoped.
 - Do not log raw tokens, Authorization headers, request bodies, plaintext, raw
-  keys, raw media keys, wrapped-key ciphertext, private deployment details, or
-  user safety data.
+  keys, raw media keys, wrapped-key ciphertext, verification credentials,
+  stored paths, object keys, private deployment details, or user safety data.
 - Preserve Tailwind Catalyst licensing boundaries.
 - Treat `open-proofline/server` as backend source of truth.
+- Treat `open-proofline/website` as source of truth for public governance,
+  political alignment, cooperative/public-good posture, public voice, reusable
+  README structure, and source-of-truth mapping.
 
 ## Check
 
 Assess whether the task has a clear goal, affected files, validation commands,
 out-of-scope items, and a clean enough working tree.
 
+For documentation or reusable-prompt-only tasks, prefer:
+
+```bash
+npx prettier --check \
+  README.md AGENTS.md SECURITY.md CHANGELOG.md \
+  docs/*.md codex/*.md codex/prompts/*.md
+git diff --check
+```
+
+For frontend behavior, route, auth, API-client, or browser-flow changes, use
+the full web-client validation stack.
+
 Return one of:
 
 - `Ready`

codex/prompts/10-frontend-readability-maintenance.md

@@ -12,7 +12,10 @@ Improve frontend readability without changing product scope.
 - accessible form labels, validation, and disabled states
 - explicit loading, error, and empty states
 - no clever abstractions before they are needed
-- no secret logging
+- no secret logging, including raw tokens, browser session cookies, CSRF tokens,
+  Authorization headers, request bodies, verification credentials, paths,
+  object keys, plaintext, raw keys, wrapped-key ciphertext, private deployment
+  details, or user safety data
 - no browser decryption, key unwrapping, or key-handling changes
 - no production-readiness claims
 
@@ -33,6 +36,7 @@ npm run typecheck
 npm run lint
 npm run test
 npm run build
+git diff --check
 ```
 
 Run Playwright only when route/browser flows change:

codex/prompts/20-code-review.md

@@ -13,8 +13,10 @@ Do **not** add features unless needed to fix a bug.
 - auth/session token handling
 - local-storage use and warnings
 - accessible forms and states
-- no raw token, Authorization header, request body, plaintext, key, wrapped-key
-  ciphertext, private deployment detail, or user safety data logging
+- no raw token, browser session cookie, CSRF token, Authorization header,
+  request body, uploaded byte, plaintext, raw key, raw media key, contact
+  private key, wrapped-key ciphertext, verification credential, stored path,
+  object key, private deployment detail, or user safety data logging
 - no browser decryption or key unwrapping
 - no recording/capture behavior
 - no production-readiness claims
@@ -34,4 +36,5 @@ npm run lint
 npm run test
 npm run build
 npm run test:e2e
+git diff --check
 ```

codex/prompts/30-security-review.md

@@ -15,9 +15,11 @@ public docs or issue drafts.
 - CSP and security-header deployment expectations
 - route assumptions that might expose private `/v1` or admin routes
 - public UI wording around emergency reliance
-- no logging of raw tokens, Authorization headers, request bodies, plaintext,
-  raw keys, wrapped-key ciphertext, private deployment details, or user safety
-  data
+- no logging of raw tokens, browser session cookies, CSRF tokens,
+  Authorization headers, request bodies, uploaded bytes, plaintext, raw keys,
+  raw media keys, contact private keys, wrapped-key ciphertext, verification
+  credentials, stored paths, object keys, private deployment details, or user
+  safety data
 - no browser decryption, key unwrapping, key escrow, recording, playable export,
   or emergency dispatch added incidentally
 - Catalyst licensing and redistribution boundaries
@@ -34,6 +36,7 @@ npm run typecheck
 npm run lint
 npm run test
 npm run build
+git diff --check
 ```
 
 Run `npm run test:e2e` when browser flows changed.

codex/prompts/40-documentation-update.md

@@ -12,17 +12,25 @@ production readiness.
 - `SECURITY.md`
 - `CHANGELOG.md`
 - `docs/README.md`
+- `docs/end-user-web-client-design.md`
+- `docs/browser-security-headers.md`
+- `docs/viewer-token-ui-design.md`
 - `docs/architecture.md`
 - `docs/api-client.md`
 - `docs/security-model.md`
 - `docs/threat-model.md`
 - `docs/development.md`
 - `codex/README.md`
 - `codex/prompts/*.md`
+- current `open-proofline/website` README and source docs when public voice,
+  governance, source-of-truth mapping, or README baseline is involved
 
 ## Constraints
 
 - Keep `open-proofline/server` as backend source of truth.
+- Keep `open-proofline/website` as the source for public governance,
+  political alignment, cooperative/public-good posture, public voice, reusable
+  README structure, and source-of-truth mapping.
 - Do not describe unimplemented backend routes as confirmed.
 - Do not imply recording, browser decryption, trusted-contact decryption, key
   escrow, playable export, emergency dispatch, OAuth, JWT, or production safety
@@ -36,8 +44,11 @@ production readiness.
 If only Markdown changed:
 
 ```bash
-git diff --stat
-git diff -- README.md AGENTS.md SECURITY.md CHANGELOG.md docs codex
+npx prettier --check \
+  README.md AGENTS.md SECURITY.md CHANGELOG.md \
+  docs/*.md codex/*.md codex/prompts/*.md
+git diff --check
 ```
 
-Run frontend validation only if code changed.
+Run frontend validation only if source, route, browser-flow, auth, API-client,
+or behavior changed.

codex/prompts/45-documentation-and-prompt-review.md

@@ -40,6 +40,14 @@ Start with current source-of-truth files:
 - Catalyst/Tailwind Plus license and provenance files:
   - `src/components/catalyst/README.md`
   - `src/components/catalyst/LICENSE.md`
+- current project-level source documents from `open-proofline/website`, when
+  governance, political alignment, public-good framing, public voice, funding
+  posture, source mapping, or README structure is involved:
+  - `README.md`
+  - `docs/governance-and-political-alignment.md`
+  - `docs/repository-readme-baseline.md`
+  - `codex/README.md`
+  - relevant `codex/prompts/`
 
 Use source and test files to verify UI, API-client, route, auth/session, and
 documentation claims:
@@ -59,6 +67,11 @@ For backend behavior, routes, deployment, and server security claims, inspect
 the current `open-proofline/server` source documents instead of relying on
 web-client assumptions.
 
+For governance, political alignment, public-good framing, public voice,
+repository README structure, and source-of-truth mapping, inspect the current
+`open-proofline/website` source documents instead of duplicating project-level
+claims here.
+
 Do not rely on stale assumptions from this prompt when current docs or source
 code disagree.
 
@@ -72,6 +85,7 @@ Review:
 - all reusable Codex prompt files
 - all public-facing project claims
 - source-of-truth alignment
+- public voice and reusable README baseline alignment
 - technical accuracy
 - linguistic coherence
 - readability and approachability
@@ -109,6 +123,8 @@ Check source-of-truth consistency:
 - Do docs agree with current `README.md`, `AGENTS.md`, `SECURITY.md`, and
   source docs?
 - Do backend claims match the current `open-proofline/server` docs?
+- Do public-governance, political-alignment, public-good, public-voice, and
+  README-baseline claims match the current `open-proofline/website` docs?
 - Do Codex prompts agree with current repo rules?
 - Are public claims supported by implementation or source docs?
 
@@ -146,6 +162,9 @@ Check readability and approachability:
 - Are public-facing docs understandable without internal context?
 - Are technical docs precise without being needlessly dense?
 - Is wording direct, humane, and clear?
+- Does public-facing wording follow the website public voice without putting
+  jokes in emergency, security, implementation-status, encryption, decryption,
+  key-custody, or vulnerability-reporting sections?
 - Are acronyms and project-specific terms explained where needed?
 - Are there sections that sound like internal notes, legal fog, or startup
   hype?
@@ -227,11 +246,16 @@ In edit mode:
 For docs-only edits, run:
 
 ```bash
+npx prettier --check \
+  README.md AGENTS.md SECURITY.md CHANGELOG.md \
+  docs/*.md codex/*.md codex/prompts/*.md
 git diff --check
-npm run format:check
 ```
 
-Run `npm run format:check` only if it is available and applicable.
+Use the docs/prompt Prettier command above for docs-only review work so
+unrelated source formatting drift does not block the docs report. Run
+`npm run format:check` only when a repo-wide formatting check is explicitly
+requested or applicable.
 
 If code changed because the maintainer explicitly scoped that work, run:
 

codex/prompts/50-web-security-header-review.md

@@ -27,6 +27,15 @@ Document deployment expectations rather than claiming production hardening.
 
 ## Validation
 
+For documentation-only header guidance changes:
+
+```bash
+npx prettier --check \
+  README.md AGENTS.md SECURITY.md CHANGELOG.md \
+  docs/*.md codex/*.md codex/prompts/*.md
+git diff --check
+```
+
 Run frontend validation if config or browser behavior changes:
 
 ```bash