docs(signing): record test-signing proof

docs/CODE_SIGNING_POLICY.md

@@ -22,7 +22,12 @@ artifact is not Authenticode-signed. Detached checksums and Pulse release
 signatures remain mandatory and are not a substitute for Authenticode. The
 `test-signing` policy may be used to validate the integration, but its test
 certificate is untrusted and its output must never be published as a
-production release.
+production release. The manual
+[`SignPath Test Signing Proof`](../.github/workflows/signpath-test-signing.yml)
+workflow is the only test-signing entrypoint: it is restricted to `main`,
+hard-codes the test policy, verifies the exact returned file set, and uploads
+only a non-production JSON evidence record after verification. It never uploads
+the test-signed binaries as a GitHub artifact or assembles a release candidate.
 
 The canonical CI integration uses SignPath's GitHub trusted-build-system
 action. GitHub Actions uploads the three unsigned Windows agent executables as
@@ -50,7 +55,8 @@ Normal stable publication and stable dry runs select `signpath` directly.
   be submitted to the SignPath Foundation project.
 - Third-party or private binaries must never be signed with the community
   project certificate.
-- Every signing request requires approval by an authorised project approver.
+- Every production signing request requires approval by an authorised project
+  approver.
 - Test-signed output must never enter a release candidate or publication path.
 - Production signing must fail closed while the release certificate or signing
   policy is invalid.

docs/release-control/v6/internal/records/signpath-windows-authenticode-integration-packet-2026-07-21.md

@@ -29,8 +29,7 @@ Production signing is not ready. `Release certificate 2026` remains
 Foundation's certificate authority issues and installs the certificate. The
 remaining proof sequence is:
 
-1. Submit a non-publishing request through `test-signing` to validate the CI
+1. The isolated, non-publishing `test-signing` integration proof is complete.
-   credentials, origin, artifact configuration, approval, and download path.
 2. Wait for the production release certificate to become active.
 3. Run the exact-SHA, non-publishing `release-signing` proof described below.
 
@@ -38,6 +37,41 @@ Test-signed files use an untrusted certificate. Do not publish them, include
 them in a production candidate, or mark production Windows signing ready on the
 basis of a test request.
 
+## Test-Signing Integration Proof (2026-08-06)
+
+The canonical non-production integration proof is GitHub Actions run
+[`31114440080`](https://github.com/rcourtman/Pulse/actions/runs/31114440080),
+executed from `main` at
+`0dd9c92cb84548c4f602f9e647150d2ce6de4f14` for version `6.2.0-rc.8`.
+The manually dispatched workflow hard-coded `test-signing`, submitted only the
+three contract executables through artifact configuration `initial`, verified
+the exact returned file set and Authenticode signatures, and retained no signed
+output. Repository policy retains the JSON proof artifact for seven days and
+the unsigned input artifact for one day. The test-signed executables were
+neither uploaded as a GitHub artifact nor published or assembled into a release
+candidate. This record preserves the accepted evidence fields after the
+ephemeral artifacts expire.
+
+SignPath request
+[`88badc79-817f-4a8d-80e9-5ccdbe6d69a1`](https://app.signpath.io/Web/1ecb3261-e389-49c2-a071-e03ff177cc5d/SigningRequests/88badc79-817f-4a8d-80e9-5ccdbe6d69a1)
+used the self-signed test certificate
+`CN=Test certificate for 'Pulse [OSS]'`, thumbprint
+`D24B66B8F6C5F59362DE85C0965F1E4303ADE344`. The accepted signed-file hashes
+are:
+
+- `pulse-agent-windows-386.exe`:
+  `b69ab0ed070e64e459edfe9150f2ad1b9a23bdb22b601bbf7ce480d2ed1dd6eb`
+- `pulse-agent-windows-amd64.exe`:
+  `75d08c411ccd3a98fa406674836e67e824a12a0dac7437fe1fa7ad552791ed6c`
+- `pulse-agent-windows-arm64.exe`:
+  `03ac32e86bc5456ccc23cfd85f3c7df2c23eafe84c74ac77f1e2fb0caa230d8d`
+
+The four diagnostic runs `31110733308`, `31111803643`, `31112661094`, and
+`31113777871` were cancelled or failed without publication while isolating the
+Windows user-certificate-store hangs. The replacement uses bounded,
+non-interactive `certutil` operations against the documented ephemeral machine
+stores and bounds every SignTool verification to 90 seconds.
+
 ## SignPath Project Contract
 
 The approved project must continue to satisfy this contract:

frontend-modern/public/docs/CODE_SIGNING_POLICY.md

@@ -9,14 +9,25 @@ community signing project.
 
 ## Signing service
 
-Pulse is applying to the SignPath Foundation open-source programme. Once the
+Pulse was accepted into the SignPath Foundation open-source programme on
-application is approved, Windows community release artifacts will use free code
+2026-08-06. The SignPath organization `Pulse [OSS]` and project `Pulse` are
-signing provided by [SignPath.io](https://signpath.io/), with the certificate
+connected only to the public repository through SignPath's GitHub App and
-issued by the [SignPath Foundation](https://signpath.org/).
+trusted build system. The production release certificate is still awaiting
+issuance (`CSR PENDING`), so the `release-signing` policy is not yet available
+for production releases.
 
-Until approval and production integration are complete, release notes must say
+Until the production certificate is active and the exact-commit,
-when a Windows artifact is not Authenticode-signed. Detached checksums and Pulse
+non-publishing proof run has passed, release notes must say when a Windows
-release signatures remain mandatory and are not a substitute for Authenticode.
+artifact is not Authenticode-signed. Detached checksums and Pulse release
+signatures remain mandatory and are not a substitute for Authenticode. The
+`test-signing` policy may be used to validate the integration, but its test
+certificate is untrusted and its output must never be published as a
+production release. The manual
+[`SignPath Test Signing Proof`](https://github.com/rcourtman/Pulse/blob/main/.github/workflows/signpath-test-signing.yml)
+workflow is the only test-signing entrypoint: it is restricted to `main`,
+hard-codes the test policy, verifies the exact returned file set, and uploads
+only a non-production JSON evidence record after verification. It never uploads
+the test-signed binaries as a GitHub artifact or assembles a release candidate.
 
 The canonical CI integration uses SignPath's GitHub trusted-build-system
 action. GitHub Actions uploads the three unsigned Windows agent executables as
@@ -25,20 +36,30 @@ completion, downloads the signed result, and verifies every file before
 candidate assembly. A non-secret evidence artifact records the SignPath request
 URL, source SHA, signer identity, and signed-file SHA-256 values.
 
+The artifact configuration accepts exactly these ZIP-root files and no others:
+
+- `pulse-agent-windows-amd64.exe`
+- `pulse-agent-windows-arm64.exe`
+- `pulse-agent-windows-386.exe`
+
 The repository-secret PFX path is an explicitly selected break-glass fallback.
 Normal stable publication and stable dry runs select `signpath` directly.
 
 ## Build and release controls
 
 - Release artifacts are built by GitHub Actions from an exact commit on the
-  protected `main` branch.
+  `main` branch.
 - The release workflow records artifact digests and promotes the same immutable
   candidate without rebuilding it.
 - Only binaries built from the public repository's source and build scripts may
   be submitted to the SignPath Foundation project.
 - Third-party or private binaries must never be signed with the community
   project certificate.
-- Every signing request requires approval by an authorised project approver.
+- Every production signing request requires approval by an authorised project
+  approver.
+- Test-signed output must never enter a release candidate or publication path.
+- Production signing must fail closed while the release certificate or signing
+  policy is invalid.
 - Release checksums and detached signatures are published alongside artifacts
   and verified independently after publication.
 

frontend-modern/public/docs/INSTALL.md

@@ -13,13 +13,14 @@ Pulse offers flexible installation options from Docker to enterprise-ready Kuber
 
 ## Windows code-signing status
 
-Pulse is applying to the SignPath Foundation open-source programme. Once
+Pulse was accepted into the SignPath Foundation open-source programme on
-approved, Windows community release artifacts will use free code signing
+2026-08-06, and the public repository is connected to its SignPath project. The
-provided by [SignPath.io](https://signpath.io/), with the certificate issued by
+production release certificate is still awaiting issuance (`CSR PENDING`), so
-the [SignPath Foundation](https://signpath.org/). Until that integration is
+Windows community release artifacts remain unsigned until the certificate is
-complete, release notes identify Windows artifacts that are not
+active and the non-publishing production proof run has passed. Release notes
-Authenticode-signed; published checksums and detached Pulse signatures remain
+identify Windows artifacts that are not Authenticode-signed; published
-mandatory.
+checksums and detached Pulse signatures remain mandatory. Test-signed artifacts
+use an untrusted certificate and are never published as production releases.
 
 See the [Code Signing Policy](CODE_SIGNING_POLICY.md) for build provenance,
 approval roles, signing scope, and reporting requirements. Release downloads