Refresh README, docs, and Codex workflows

AGENTS.md

@@ -26,6 +26,11 @@
 - Preserve the current deployment model: main `/v1` behind the reviewed localhost/LAN/WireGuard/firewall boundary, private `/admin` behind its own private listener, and only read-only incident viewer paths behind HTTPS/reverse proxy when exposed.
 - Separate bind addresses are a deployment boundary, not a complete security model.
 - Treat Codex prompts as scoped change requests, not open-ended permission to expand the project.
+- Treat the website repository as the project-level source of truth for public
+  governance posture, political alignment, public-good framing, public voice,
+  README baseline style, and source-of-truth mapping. Server docs should link
+  to those website source documents instead of re-declaring project-wide
+  posture differently.
 - Do not implement newly discovered future work during an unrelated task; document it as an issue/backlog item instead.
 - For larger changes, start from a clean working tree or an explicit checkpoint commit.
 - Backlog scanning should create draft Markdown files first, not GitHub issues directly.
@@ -38,7 +43,12 @@
 - This repository is the Go server backend component only.
 - Current organisation: `open-proofline`.
 - Current server repository: `open-proofline/server`.
-- Planned future companion repositories: `open-proofline/web-client`, `open-proofline/ios-client`, `open-proofline/android-client`, and `open-proofline/protocol`.
+- Current companion repositories include `open-proofline/website` and
+  `open-proofline/web-client`.
+- Planned future companion repositories include `open-proofline/ios-client`,
+  `open-proofline/android-client`, and `open-proofline/protocol`.
+- Project-wide public governance posture and reusable README baseline guidance
+  live in `open-proofline/website`.
 - The Go module path is `github.com/open-proofline/server` at the repository root, release binaries use `proofline-server-*` names, and the published GHCR image is `ghcr.io/open-proofline/server`.
 - Current runtime protocol and default data-layout identifiers use Proofline names. Historical reports and archived prompts may still mention earlier `safety-recorder` identifiers.
 - SQLite metadata by default.
@@ -91,6 +101,9 @@ Before accepting Codex changes, check:
 - wrapped-key ciphertext, private deployment details, stored paths, object keys, and user safety data are not logged
 - ZIP downloads use safe headers and controlled paths
 - documentation still matches `README.md`
+- public-facing docs still link to the website governance/README-baseline
+  source documents when making project-wide public posture or public voice
+  claims
 - future web, iOS, Android, or protocol work was not accidentally added to this server repository
 - key custody/decryption changes are explicit and security-reviewed
 - no public-production readiness is implied unless deployment hardening has actually been implemented

SECURITY.md

@@ -1,6 +1,6 @@
 # Security Policy
 
-Proofline is a private encrypted incident-capture backend. It is not production-ready public infrastructure. The main `/v1` API uses local account sessions, optional browser cookie sessions for future web-client calls, email challenge, TOTP, disabled-by-default WebAuthn/FIDO2 second-factor setup for new account gating, private-admin assisted second-factor reset for lost-factor recovery, and app-level route-class rate limits. Broad public `/v1` exposure still needs route-by-route deployment review, TLS, edge abuse controls, browser credential review, logging review, proxy hardening, and operational testing. Private-admin `/admin/api/...` JSON routes and the private `/admin` web surface require admin authentication, completed admin second-factor setup, active-factor session verification when email challenge, TOTP, or WebAuthn is active, and must stay behind localhost, WireGuard, a firewall, or an equivalent private boundary. The private admin web display and validation boundary is documented in [docs/private-admin-web-scope.md](docs/private-admin-web-scope.md).
+Proofline is a private encrypted incident-capture backend. It is not production-ready public infrastructure. The main `/v1` API uses local account sessions, optional browser cookie sessions for future production web-client calls, email challenge, TOTP, disabled-by-default WebAuthn/FIDO2 second-factor setup for new account gating, private-admin assisted second-factor reset for lost-factor recovery, and app-level route-class rate limits. Broad public `/v1` exposure still needs route-by-route deployment review, TLS, edge abuse controls, browser credential review, logging review, proxy hardening, and operational testing. Private-admin `/admin/api/...` JSON routes and the private `/admin` web surface require admin authentication, completed admin second-factor setup, active-factor session verification when email challenge, TOTP, or WebAuthn is active, and must stay behind localhost, WireGuard, a firewall, or an equivalent private boundary. The private admin web display and validation boundary is documented in [docs/private-admin-web-scope.md](docs/private-admin-web-scope.md).
 
 The current implementation supports generic incident capture, optional
 incident-mode metadata fields, and token-scoped read-only incident review.
@@ -75,7 +75,7 @@ Reports are in scope when they affect the current backend, documentation, or dep
 
 The following are generally out of scope unless they demonstrate a concrete vulnerability in this repository:
 
-- missing features already documented as absent, such as public account workflows, OAuth, JWT, SMS, push notifications, trusted-contact accounts, Android/iOS clients, a web client, mode-driven escalation behavior, or a public admin dashboard
+- missing features already documented as absent, such as public account workflows, OAuth, JWT, SMS, push notifications, trusted-contact accounts, Android/iOS clients, web-client implementation in this server repository, mode-driven escalation behavior, or a public admin dashboard
 - lack of production hardening already documented as a known limitation, without a new exploit path
 - reports requiring unreviewed broad public exposure of main `/v1` route groups contrary to documented deployment guidance
 - denial-of-service reports based only on unrealistic local access or unbounded physical access

codex/README.md

@@ -1,9 +1,23 @@
 # Codex Prompts
 
-This directory records the Codex prompt workflow used for AI-assisted development.
+This directory records the Codex prompt workflow used for AI-assisted
+development in `open-proofline/server`.
 
 Codex output is treated as maintainer-reviewed work, not as endorsement, audit, certification, security review, or maintenance by OpenAI.
 
+The server repository owns server behavior, API, deployment, security, and
+release workflow facts. The website repository owns project-wide public
+governance posture, political alignment, public-good framing, public voice,
+reusable README baseline guidance, and source-of-truth mapping:
+
+- [`open-proofline/website/docs/governance-and-political-alignment.md`](https://github.com/open-proofline/website/blob/main/docs/governance-and-political-alignment.md)
+- [`open-proofline/website/docs/repository-readme-baseline.md`](https://github.com/open-proofline/website/blob/main/docs/repository-readme-baseline.md)
+
+Reusable server prompts that touch README structure, public-facing wording,
+project-wide governance, public-good framing, or source-of-truth mapping should
+inspect those website documents and link to them instead of re-declaring the
+project posture inside server docs.
+
 ## Directory Structure
 
 Keep the Codex workflow in this structure:
@@ -122,13 +136,18 @@ For any `v1 preview`, `v1.0.0`, or real-user evidence-upload readiness claim,
 run [docs/v1-preview-readiness-checklist.md](../docs/v1-preview-readiness-checklist.md)
 as part of the release workflow before using preview-ready language.
 
-## Current project constraints
+## Current Project Constraints
 
 Treat `README.md`, `AGENTS.md`, `SECURITY.md`, and the `docs/` directory as the current source of truth. For v1 preview terminology, repository roles, and current-versus-future product direction, read `docs/v1-preview-direction.md` before turning prototype gaps into backlog or implementation assumptions.
 For v1 preview release claims, also read
 `docs/v1-preview-readiness-checklist.md` and preserve its hard-blocker,
 non-goal, optional hosted-service, and issue-hygiene boundaries.
 
+For public governance posture, political alignment, public-good framing,
+public voice, README baseline style, and source-of-truth mapping, read the two
+website source documents above. Keep server-specific facts in this repository;
+link project-wide posture to the website source of truth.
+
 Product documentation now uses the name Proofline. The repository URL is `open-proofline/server`, the root Go module path is `github.com/open-proofline/server`, release binaries use `proofline-server-*` names, and the published GHCR image is `ghcr.io/open-proofline/server`. Current runtime protocol and default data-layout identifiers use Proofline names. Historical reports and archived prompts may still mention earlier `safety-recorder` identifiers.
 
 Core constraints:
@@ -166,6 +185,7 @@ When project scope, architecture, security posture, or workflow changes, update
 
 | Project change | Prompt/doc action |
 |---|---|
+| README baseline, public voice, governance posture, public-good framing, or source-of-truth mapping changes | Read the website governance and README baseline docs, update `README.md`, `AGENTS.md`, `docs/`, `codex/README.md`, and reusable prompts only where they consume that project-wide source of truth. |
 | Product rename or repository/artifact namespace migration | Update `README.md`, `AGENTS.md`, `SECURITY.md`, relevant `docs/`, `codex/README.md`, and reusable prompts that mention product or artifact names. Keep docs-only renames separate from repository/module/Docker/GHCR migrations. |
 | First-class incident modes, capture profiles, escalation policies, sharing state, safety checks, interaction records, or evidence notes | Update `docs/incident-modes.md`, `README.md`, API docs, security/threat docs, client prototype docs, and relevant review prompts. |
 | New API routes or listener exposure | Review `AGENTS.md`, `docs/api.md`, security/threat docs, and relevant review prompts. |

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

@@ -20,6 +20,11 @@ Before making changes, read current source-of-truth files as relevant:
 - `docs/README.md`
 - `docs/v1-preview-direction.md`
 - `docs/key-custody.md`, if present
+- `open-proofline/website/docs/governance-and-political-alignment.md`, when
+  public governance posture, political alignment, or public-good framing is in
+  scope
+- `open-proofline/website/docs/repository-readme-baseline.md`, when README
+  structure, public voice, or source-of-truth mapping is in scope
 - relevant files in `docs/`
 - relevant source files
 - relevant tests

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

@@ -20,6 +20,11 @@ Before making changes, read current source-of-truth files as relevant:
 - `SECURITY.md`
 - `docs/README.md`
 - `docs/v1-preview-direction.md`
+- `open-proofline/website/docs/governance-and-political-alignment.md`, when
+  public governance posture, political alignment, or public-good framing is in
+  scope
+- `open-proofline/website/docs/repository-readme-baseline.md`, when README
+  structure, public voice, or source-of-truth mapping is in scope
 - relevant files in `docs/`
 - relevant source files
 - relevant tests

codex/prompts/15-codex-structure-and-naming-maintenance.md

@@ -32,6 +32,11 @@ Read:
 - all files under `codex/`
 - `docs/codex-change-control.md`, if present
 - `docs/development.md`, if relevant
+- `open-proofline/website/docs/governance-and-political-alignment.md`, if
+  prompt workflow wording touches public governance or public-good framing
+- `open-proofline/website/docs/repository-readme-baseline.md`, if prompt
+  workflow wording touches README structure, public voice, or source-of-truth
+  mapping
 
 ## Standard directory structure
 
@@ -130,6 +135,9 @@ Check for:
 - historical prompts missing date prefixes
 - spaces, uppercase words, or inconsistent filenames
 - prompt files that reference stale project state
+- prompt files that miss the website source documents when their workflow
+  covers README structure, public voice, governance posture, or source-of-truth
+  mapping
 - prompt files that contradict `AGENTS.md`
 - prompt files that still say server-side key storage/decryption is permanently impossible
 - prompt files that do not distinguish current implementation from future key custody design

codex/prompts/40-documentation-update.md

@@ -15,6 +15,11 @@ Before making changes, read current source-of-truth files as relevant:
 - `SECURITY.md`
 - `docs/README.md`
 - `docs/v1-preview-direction.md`
+- `open-proofline/website/docs/governance-and-political-alignment.md`, when
+  public governance posture, political alignment, or public-good framing is in
+  scope
+- `open-proofline/website/docs/repository-readme-baseline.md`, when README
+  structure, public voice, or source-of-truth mapping is in scope
 - relevant files in `docs/`
 - relevant source files
 - relevant tests
@@ -94,6 +99,8 @@ Update only relevant files:
 - Codex change-control workflow
 - AI-assisted development disclosure
 - next steps / roadmap
+- links to website source documents for project-wide governance, public voice,
+  and reusable README baseline claims
 
 ## Constraints
 
@@ -102,6 +109,8 @@ Update only relevant files:
 - Do not claim the iOS client exists.
 - Do not claim production-readiness.
 - Do not describe future key custody/decryption as implemented unless it is implemented.
+- Do not duplicate project-wide governance or public-voice posture in server
+  docs when a link to the website source of truth is clearer.
 - Keep wording clear and concise.
 
 ## Validation

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

@@ -24,6 +24,8 @@ Start with current source-of-truth files:
 - `docs/README.md`
 - `docs/v1-preview-direction.md`
 - `docs/v1-preview-readiness-checklist.md`
+- `open-proofline/website/docs/governance-and-political-alignment.md`
+- `open-proofline/website/docs/repository-readme-baseline.md`
 - every current source-of-truth file under `docs/`
 - `codex/README.md`
 - every reusable prompt under `codex/prompts/`, including this prompt
@@ -51,6 +53,8 @@ Review:
 - all reusable Codex prompt files
 - all public-facing project claims
 - source-of-truth alignment
+- website governance, public-good framing, public voice, README baseline, and
+  source-of-truth mapping alignment
 - technical accuracy
 - linguistic coherence
 - readability and approachability
@@ -77,13 +81,18 @@ Preserve these server-specific boundaries:
   media exports.
 - Do not imply the backend is production-ready public emergency
   infrastructure.
+- Link project-wide governance posture and README baseline guidance to
+  `open-proofline/website` instead of rewriting that posture differently in
+  server docs.
 
 ## Review Checks
 
 Check source-of-truth consistency:
 
 - Do docs agree with current `README.md`, `AGENTS.md`, `SECURITY.md`, and
   `docs/`?
+- Do README, docs, and prompts point to the website governance and README
+  baseline docs where project-wide public posture or public voice is in scope?
 - Do Codex prompts agree with current repo rules?
 - Are public claims supported by implementation or source docs?
 
@@ -121,6 +130,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 current Proofline voice: serious
+  public-interest infrastructure, clear and humane, with dry humour only where
+  it clarifies values and never inside safety/security/key-custody claims?
 - Are acronyms and project-specific terms explained where needed?
 - Are there sections that sound like internal notes, legal fog, or startup
   hype?

codex/prompts/70-work-on-github-issue.md

@@ -86,6 +86,11 @@ Then read:
 - `CHANGELOG.md`
 - `SECURITY.md`
 - `docs/v1-preview-direction.md`
+- `open-proofline/website/docs/governance-and-political-alignment.md`, when
+  public governance posture, political alignment, or public-good framing is in
+  scope
+- `open-proofline/website/docs/repository-readme-baseline.md`, when README
+  structure, public voice, or source-of-truth mapping is in scope
 - relevant files in `docs/`
 - relevant source files
 - relevant tests

codex/prompts/75-create-draft-pr-from-current-branch.md

@@ -192,6 +192,9 @@ The PR body should include:
 - concise summary
 - validation commands run
 - docs updated, if any
+- website governance/README-baseline source documents inspected, when
+  README structure, public voice, public governance, or source-of-truth mapping
+  changed
 - follow-up work, if any
 - tests skipped and why, if any
 - whether the issue was generated from a different reviewed branch/ref and whether it was revalidated against this PR base

codex/prompts/76-request-codex-pr-review.md

@@ -56,6 +56,7 @@ Post this PR comment only after confirming the base branch is correct:
 @codex review
 
 Please review this PR for correctness, security, scope control, and consistency with README.md, AGENTS.md, SECURITY.md, docs/v1-preview-direction.md where product direction is relevant, and relevant docs.
+If the PR changes README structure, public voice, governance posture, or source-of-truth mapping, also check the website governance and README baseline source documents.
 
 Base branch: `<ACTUAL_BASE_BRANCH>`
 Head branch: `<ACTUAL_HEAD_BRANCH>`
@@ -104,9 +105,10 @@ Then review for:
 5. documentation accuracy
 6. consistency with README.md, AGENTS.md, and docs/v1-preview-direction.md where product direction is relevant
 7. whether it satisfies the linked issue acceptance criteria
-8. whether it should remain draft
-9. whether it changes key custody/decryption assumptions, and whether those changes are explicitly designed and documented
-10. whether branch-scoped issue/report findings were revalidated against the PR base branch
+8. consistency with the website governance and README baseline source documents if README structure, public voice, governance posture, or source-of-truth mapping changed
+9. whether it should remain draft
+10. whether it changes key custody/decryption assumptions, and whether those changes are explicitly designed and documented
+11. whether branch-scoped issue/report findings were revalidated against the PR base branch
 
 Do not modify files unless explicitly requested.
 

codex/prompts/80-backlog-scan-issue-drafts.md

@@ -60,6 +60,11 @@ Read current repository files where present:
 - `LICENSE`
 - `docs/README.md`
 - `docs/v1-preview-direction.md`
+- `open-proofline/website/docs/governance-and-political-alignment.md`, when
+  public governance posture, political alignment, or public-good framing is in
+  scope
+- `open-proofline/website/docs/repository-readme-baseline.md`, when README
+  structure, public voice, or source-of-truth mapping is in scope
 - `docs/api.md`
 - `docs/architecture.md`
 - `docs/configuration.md`
@@ -125,6 +130,7 @@ Look for future work in these categories:
 12. Codex workflow/process improvements
 13. Key custody / emergency access design
 14. Branch/release-candidate follow-up work
+15. README baseline, public voice, and source-of-truth mapping drift
 
 ## Candidate discovery guidance
 
@@ -151,6 +157,8 @@ Bad candidate signals:
 - vague “improve code”
 - duplicate of existing issue
 - feature that contradicts README/AGENTS scope
+- stale project-map wording that should be fixed in docs instead of becoming a
+  broad product issue
 - production claims beyond current maturity
 - public issue containing sensitive vulnerability details
 - anything requiring secrets, raw tokens, or private deployment details