docs: close Phase 5D security hardening

The documentation still described Phase 5D as in progress, Phase 6 as
blocked, and a disposable-runner isolation proof as a prerequisite for
opening the real pull request. All five passes and the independent
whole-repository re-audit have landed, so those statements no longer
match the accepted operating model.

The README's current status now records Phase 5D as complete under the
current trusted-contributor, not-yet-deployed threat model, with Phase 6
unblocked, and gains a pass 5 closure paragraph covering the re-audit,
the repository-local supply-chain and dependency fixes, the accepted
trusted-code-only CI boundary, and what remains required before
untrusted CI or a public launch. The pass 1-4 paragraphs keep their
technical content unchanged; only their tense changes, so each reads as
what was outstanding at the close of that pass rather than as a current
claim.

`platform-architecture.md` no longer stops at pass 1 or says passes 2-5
are unfinished; it summarizes all five passes and defers the remaining
operational limitations to the security document.

`security.md` states the trusted-code-only operating rule explicitly and
replaces "CI blockers before the real pull request is opened" with
"Requirements before executing untrusted contributions", framing the five
hardening items as prerequisites for relaxing that rule rather than as
Phase 6 blockers, and naming an isolated hosted-runner service as an
accepted alternative. The Gitea 1.24.2 warnings, the scope of
`persist-credentials: false`, and the unverified runner topology and
job-token authority are preserved verbatim; no external Gitea setting is
claimed. The launch checklist is marked as gating a public launch, not
development.

Both Doctor examples are corrected to the real three-migration output,
adding `core:0002_authorization_integrity · 634294731180`. The stale
sentence calling Core authorization the next architectural phase is
refreshed.

ADRs 0017-0020 are untouched: their statements that later passes were
outstanding are historical records made when each was accepted.

Documentation only — no production code, test, workflow, dependency,
migration, or schema change.

Co-Authored-By: Claude Opus 5 <[email protected]>

README.md

@@ -8,10 +8,14 @@ surfaces.
 
 Phase 3 is complete, and Phase 4A (Core identity foundation), Phase 4B (identity HTTP transport),
 Phase 4C (Core authorization), Phase 5A (module authorization integration), Phase 5B (module HTTP
-transport), and Phase 5C (module database access) have landed. Phase 5D (public request perimeter
-hardening against an independent security audit) is in progress; pass 1 of 5 has landed — see
-below. **Phase 5D is not complete, and Phase 6 (Surface work) remains blocked until every audit
-finding is resolved and a final re-audit passes.** The repository includes
+transport), and Phase 5C (module database access) have landed. **Phase 5D (security hardening
+against an independent security audit) is complete: all five passes have landed and the final
+independent whole-repository re-audit has closed, under the current trusted-contributor,
+not-yet-deployed threat model — and Phase 6 (Surface work) is unblocked.** The operational
+requirements that remain are prerequisites for two specific *future* activities — executing
+untrusted CI contributions, and a public production launch — and neither gates Phase 6; see the
+pass 5 closure below and
+[Security model and deployment trust boundaries](docs/development/security.md). The repository includes
 public module contracts, independently versioned capabilities, static module manifests,
 deterministic automatic discovery, compiled server loading, a staged capability registry,
 dependency-ordered lifecycle with rollback, module-owned Drizzle table contracts, deterministic
@@ -113,9 +117,10 @@ transport-level failures are observed and logged in sanitized form. See
 [API](docs/development/api.md), [Module development](docs/module-development/README.md#http-routes),
 and [ADR 0017](docs/architecture/decisions/0017-public-request-perimeter-hardening.md). **This pass
 does not add distributed rate limiting, durable public-signup abuse control, or any deployment/TLS
-guarantee, and it does not complete Phase 5D** — passes 2–5 (identity/database transport hardening,
-authorization integrity, module/runtime/migration correctness, and deployment/supply-chain closure
-plus a final independent re-audit) remain outstanding before Phase 6 (Surface work) may begin.
+guarantee, and it did not by itself complete Phase 5D** — at the close of this pass, passes 2–5
+(identity/database transport hardening, authorization integrity, module/runtime/migration
+correctness, and deployment/supply-chain closure plus a final independent re-audit) were still
+outstanding, and Phase 6 (Surface work) was blocked until they landed.
 
 Phase 5D pass 2 of 5 corrects identity session resolution and enforces a database transport policy.
 A request carrying no cookies, or only unrelated cookies, now performs **no** identity database
@@ -135,9 +140,9 @@ which the pinned driver would otherwise let silently override the policy. See
 [ADR 0018](docs/architecture/decisions/0018-identity-session-resolution-and-database-transport.md).
 **This pass adds no secret store, no certificate rotation, no client-certificate authentication, and
 no distributed rate limiting; TLS protects the connection, not the exposure, so the network boundary
-remains the deployment's own responsibility. Phase 5D is still not complete** — passes 3–5
-(authorization integrity, module/runtime/migration correctness, and deployment/supply-chain closure
-plus a final independent re-audit) remain outstanding.
+remains the deployment's own responsibility. This pass did not by itself complete Phase 5D** — at
+its close, passes 3–5 (authorization integrity, module/runtime/migration correctness, and
+deployment/supply-chain closure plus a final independent re-audit) were still outstanding.
 
 Phase 5D pass 3 of 5 preserves authorization security history and makes explicit-grant management
 unambiguous and bounded. Authorization **audit history now survives user deletion**: the audit
@@ -159,9 +164,9 @@ unsigned position cursor. One forward Core migration (`0002_authorization_integr
 [ADR 0019](docs/architecture/decisions/0019-durable-authorization-history-and-grant-management.md).
 **This pass adds no roles, teams, tenants, service accounts, scope resolver, user-deletion endpoint,
 or owner-recovery workflow; audit append-only behavior remains an application convention, not a
-database or cryptographic guarantee. Phase 5D is still not complete** — passes 4 (module/runtime/
-migration correctness) and 5 (deployment/supply chain plus a final independent re-audit) remain
-outstanding, and Phase 6 remains blocked.
+database or cryptographic guarantee. This pass did not by itself complete Phase 5D** — at its close,
+passes 4 (module/runtime/migration correctness) and 5 (deployment/supply chain plus a final
+independent re-audit) were still outstanding, and Phase 6 was blocked until they landed.
 
 Phase 5D pass 4 of 5 hardens the module runtime and the migration commands. **Two routes of one
 module that could both match the same request path are now rejected at registration**
@@ -186,8 +191,32 @@ string literal, dollar-quoted body, quoted identifier, or comment. See
 **Deadlines bound how long the platform waits; they do not cancel or sandbox trusted in-process
 module code, and closing a socket does not prove a handler promise ended. No custom SQL parser
 exists. Modules remain trusted compiled backend code with no process, role, schema, or tenant
-isolation. Phase 5D is still not complete** — pass 5 (deployment/supply chain plus an independent
-whole-repository re-audit) remains outstanding, and Phase 6 remains blocked.
+isolation. This pass did not by itself complete Phase 5D** — at its close, pass 5
+(deployment/supply chain plus an independent whole-repository re-audit) was still outstanding, and
+Phase 6 was blocked until it landed.
+
+Phase 5D pass 5 of 5 closes the phase with an independent whole-repository re-audit and the
+repository-local half of deployment and supply-chain hardening. The re-audit swept every layer —
+Core, contracts, `apps/api`, scripts, the CI workflow, and documentation — and its repository-local
+findings are resolved here: every dependency advisory is remediated (both `pnpm audit` and
+`pnpm audit --prod` report no known vulnerabilities), every CI action reference is pinned to a full
+immutable commit SHA, installs run `--frozen-lockfile`, no workflow references a repository or
+instance secret, every checkout step sets `persist-credentials: false`, a checksum-verified secret
+scan found no committed credential in the history, and one canonical
+[security document](docs/development/security.md) now states the trusted-module model, the
+undeployed state, and the launch checklist in a single place. **CI is accepted as a
+trusted-code-only boundary**: the self-hosted Gitea runner executes only code controlled and
+reviewed by trusted repository collaborators, and unknown or untrusted pull requests must not
+execute on it automatically. What remains is operational and cannot be proven from this repository —
+upgrading Gitea past 1.24.2 (which *ignores* the workflow's `permissions`, `concurrency`, and
+`timeout-minutes` declarations), clamping job-token authority server-side, enforcing timeout and
+teardown in a trusted provisioner/reaper, and proving disposable runner isolation. Those are
+prerequisites for **executing untrusted contributions**, alongside the deployment checklist that
+gates a **public launch**; moving future public contribution workflows to a service with isolated
+hosted runners is an acceptable alternative. **Neither set of requirements blocks Phase 6** — Surface
+development proceeds under the current trusted-contributor, not-yet-deployed model. Runner topology
+and job-token authority remain unverified and are not described as isolated. See
+[Security model and deployment trust boundaries](docs/development/security.md).
 
 **Security model.** Installed modules are trusted compiled backend code that runs arbitrary
 JavaScript in the API process and shares its PostgreSQL role — table prefixes, manifests, permission
@@ -249,9 +278,10 @@ Data definitions
   ✓ Schemas validated
     0 modules · 0 tables
   ✓ Migrations validated
-    2 migrations · checksums valid
+    3 migrations · checksums valid
     core:0000_identity_core_tables · f8f2086ef06f
     core:0001_authorization_core_tables · 830e1fbc26d0
+    core:0002_authorization_integrity · 634294731180
 
 PostgreSQL
   ✓ Database TLS verified