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.
Service transaction evidence
watchpost service install is covered by a stateful layered fake-systemd transaction model rather than a live systemd instance. The model tracks persistent enablement, runtime enablement, persistent mask, runtime mask and active state separately, and is-enabled is derived from those layers. Evidence includes prior unit bytes preserved and restored on rollback; prior enablement and activity inspected before mutation with only exactly-recreatable states accepted (enabled, enabled-runtime, disabled × active, inactive); masked, static, linked, generated, transient, failed, reloading and other non-restorable states refused before any mutation; persistent/runtime enablement normalization so runtime-only enablement is restored without a persistent link; failure injection after each lifecycle step with exact unit and raw-state restoration assertions; fresh-install rollback that stops and disables the unit while it is still loaded, then removes it and reloads systemd; a genuine no-op for a byte-identical unit already enabled and active; and tests under umask 0022 and umask 0000, race tests for the changed service package, and the six-target compilation contract. In addition, a native systemd-lifecycle CI job exercises the real machine-service lifecycle on a live systemd system instance: install (creating the dedicated watchpost account and /var/lib/watchpost), idempotent reinstall, start/stop/restart, enable/disable, checksum-verified update, rollback, boot-enablement assertions (WantedBy=multi-user.target, no lingering), uninstall with data preservation, and deterministic failure-injection rollback (a fake systemctl failing activation, with and without a prior binary). The model-based evidence is still complemented by this live-systemd coverage; validation has not been proven through an actual host reboot or against every systemd release.
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.