Release quality.
Release confidence comes from reproducible checks and explicit limits, not a label saying “production-ready.”
What is checked
| Check | Evidence method | What it proves |
|---|---|---|
| Page and asset delivery | HTTPS HEAD and GET for approved public paths | Routes serve the expected HTTP response and MIME type |
| Catalog safety | Schema check, allowlisted internal URLs, unique paths | Directory cannot point to arbitrary external addresses |
| Public/private boundary | Negative route probes | Selected internal endpoints deny unauthenticated access |
| Browser behavior | Keyboard, search, filter, link and viewport checks | Usable experience under sampled conditions; requires manual browser verification |
| Backend disclosure | Public inference metadata | Backend identity is stated accurately at time of check |
| Release reversibility | Backup of the modified router and explicit undo procedure | The platform route can be disabled without moving existing apps |
What is not certified
A successful HTTP 200 does not prove every feature is working. There is no claim here of full penetration testing, formal accessibility conformance, load testing at production scale, paid provider integration, multi-region failover, or a security certification. Those require dedicated evidence.
Production acceptance gates
- All advertised public links respond; MIME types match; unexpected traversal, private files and admin URLs return denial.
- Local-model UI passes a real bounded prompt test within its allowance; external provider status remains unverified without signed receipts.
- Search/filter and navigation pass keyboard and mobile-browser checks at 320, 390, 768 and 1280 CSS pixels.
- Rate limiting, resource quotas and access logs are evaluated without leaking personal content or keys.
- Backup, restore, process health, automated restart and rollback are exercised on the deployed code.
- Performance, traffic, abuse resistance and uptime objectives are defined and load-tested before a commercial-service guarantee.
Maintainer procedure
Serve static assets from the dedicated /platform/ allowlist in the existing public router. Run python3 test_platform.py from the platform directory for the public release checks. Record execution date, results, build files and any exceptions. Do not change the root hub or private services as part of this isolated feature without their own release review.
Release facts and tests remain documented even when the chat history is deleted; they live on the VPS.