Docs · Deploy
Verification and hardening
This page records exactly what has been exercised and what has not been proven. Watchpost does not claim production readiness; the evidence below is the boundary of the current claim.
Evidence categories
Each category below was run against the current development candidate. The table pairs every category with the boundary of what it establishes, so a passing gate is never overstated.
| Evidence | What was exercised | What it does not prove |
|---|---|---|
| Formatting, build, vet, unit suites | gofmt, build, go vet, and the full unit suites for both Go repositories. | Correct behaviour under production load or on unexercised platforms. |
| Go race suites | Full go test -race suites for both repositories, including the concurrent state-update test. | The absence of every concurrency defect. Race detection only proves the runs that executed. |
| Focused security tests | Authentication, session, audit-atomicity, audit-failure, handler-level logout/revocation, and malformed-hash regressions. | Exhaustive security review or protection against unknown attack classes. |
| Agent hardening gate | The agent's local hardening gate: formatting, build, vet, unit, race, and the audit-ordering checks. | Remote-network or hostile-network behaviour beyond the documented controls. |
| Host-agent pairing journey | A scripted install-pair-approve-first-telemetry journey on a Linux loopback environment. | Ordinary-user usability, real-network latency, or multi-machine deployment. A scripted journey is not a usability study. |
| Backup, restore, corruption drill | Online backup, restore onto a separate directory, and recovery after injected corruption. | Every production disaster scenario or remote/retention-managed backup automation. |
| Release smoke | Artifact build, installer verification, upgrade, and rollback smoke from retained release artifacts. | A guaranteed upgrade contract. Smoke tests are regression evidence, not a support promise. |
| Bounded fuzzing | Ten-second ingestion observation-validation fuzzing. | Exhaustive fuzzing. A short bounded run is useful regression evidence, not a fuzzing campaign. |
| Cross-compilation | Linux, macOS, and Windows builds for amd64 and arm64. | Running or supporting the software on every target platform. Compiling is not operating. |
| Nift builds and site checks | Full rebuilds of the public website and operational pages, no leaked directives, link and status checks. | Nothing about runtime behaviour; it validates the documentation pipeline only. |
| Repository integrity | Clean worktrees, git fsck, and fast-forward ancestry in all repositories. | Nothing about runtime behaviour; it validates history hygiene only. |
Honest language
The following boundaries are deliberate:
- Cross-compilation is not the same as running the software on every target platform.
- A ten-second fuzz run is useful regression evidence, not exhaustive fuzzing.
- A scripted pairing journey is not ordinary-user usability validation.
- Release smoke tests are not a guaranteed upgrade contract.
- Local recovery drills are not proof of every production disaster scenario.
- Passing race tests does not prove the absence of every concurrency defect.
- The current agent support matrix is Linux-only for runtime support; macOS and Windows monitoring are not supported.
How to reproduce
The gates run from the application repositories: the full unit and race suites, the agent hardening gate, the operational SPA and public-site Nift rebuilds, and the release-smoke script are committed alongside the code. Run them in a clean checkout before relying on any claim made in this documentation. The exact invocation for a specific checkout is documented in the repository's plan and handover notes rather than repeated with machine-specific paths here.
What remains to be proven
Ordinary-user dogfooding, dense multi-post survey at scale, real-network remote agent administration, production TLS and proxy validation, assistive-technology auditing, long-duration soak, and external security review are open work items. They are tracked as proposed checkpoints in the project plan; none of them is claimed today.
See Security model for the implemented controls and their safe failures, and Current limitations for the non-claims.