docs: record production readiness evidence

2026-07-29 20:06:14 +02:00
parent 347f7132b9
commit aa4895912a
3 changed files with 97 additions and 9 deletions
@@ -0,0 +1,80 @@
+# ForgeFlow 1.0 production-readiness evidence
+
+## 1. Scope and history
+
+The professionalization work started from `64ca267` on `main`. It preserves the
+0.10.0 compatibility baseline and deliberately creates no 1.0 tag or public
+release. The commits and their exact SHAs remain the authoritative audit trail.
+
+## 2. Deployment safety
+
+Server pull uses repository-scoped read-only deploy keys, exact commit SHAs,
+pinned SSH/Gitea host identities, Compose validation, health evidence and bounded
+rollback. Rotation is transactional and revocation requires reviewed impact and
+recovery evidence. Direct Copy and monitor-only remain explicit alternatives.
+
+## 3. Inventory and reconciliation
+
+Canonical deployment identity combines repository, branch, server, environment,
+Compose project/root, runtime labels, container, live SHA and profile. Duplicate,
+stale, ambiguous, orphan and historical evidence has persistent content-addressed
+review decisions. Discovery never deletes, stops or rewrites a workload.
+
+## 4. Architecture
+
+Renderer, IPC and Unraid responsibilities are split by domain. The generated
+architecture audit currently reports zero source files above 750 or 1,000 lines.
+Runtime schemas, bounded IPC capabilities, operation IDs and explicit error
+contracts protect the process boundary.
+
+## 5. Repository assurance
+
+Git Validator 2.0 covers security, reproducibility, governance, collaboration,
+performance/hygiene and release readiness. Minimal, Standard, Strict, Production
+and custom policies support accountable expiring suppressions, trend history and
+reviewable JSON/Markdown/HTML reports. Repairs always require preview and never
+commit or push automatically.
+
+## 6. Automated verification
+
+The Node suite includes real temporary Git remotes and an isolated production
+acceptance harness. Playwright adds 36 renderer cases across six viewport/theme/
+motion/scaling projects. Failure artifacts contain screenshots, traces, video,
+console events, DOM, fixture details and test identity.
+
+## 7. Coverage and dependencies
+
+Coverage increased from 69.74% statements/lines, 68.82% functions and 55.38%
+branches to at least 78.75%, 79.68% and 59.25%, respectively, before the last
+ConfigStore tests. The enforced gates are 75/75/75/60; the rationale and 65%
+follow-up are in `COVERAGE_POLICY.md`. Production dependencies have zero known
+audit vulnerabilities. Remaining development findings belong to current upstream
+ESLint/electron-builder toolchains and are assessed in `DEPENDENCY_AUDIT.md`.
+
+## 8. UX and accessibility
+
+Dark and light themes use the same semantic hierarchy, restrained project-signal
+motion and status text that never depends on color alone. Deployment cards expose
+container, repository, environment, commit parity and health distinctly. Dense
+inventories, long names, keyboard focus, dialogs, reduced motion and high scaling
+are part of the automated matrix.
+
+## 9. Packaging, updating and signing
+
+Windows installer and portable packaging use deterministic names; old `dist`
+versions are pruned after every successful build. Publication stays draft until
+installer, portable, checksums, provenance and CycloneDX SBOM are complete. Binary
+updates verify checksum, exact publisher and timestamp. A disposable local
+Authenticode fixture proves installer, portable, helper and uninstaller signing,
+RFC 3161 timestamping, publisher pinning and tamper rejection.
+
+## 10. Release decision
+
+No open P0 or P1 technical issue is known after the final quality, browser,
+acceptance, signing and packaging gates. The technically correct status is:
+
+`TECHNICALLY_COMPLETE_PENDING_EXTERNAL_REQUIREMENTS`
+
+The sole external production dependency is:
+
+`PENDING_HUMAN_INPUT: trusted production Authenticode certificate and exact legal publisher subject`