80 lines
3.6 KiB
Markdown
80 lines
3.6 KiB
Markdown
# 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 81.48%, 82.07% and 65.59%, respectively. The enforced gates are now
|
|
75/75/75/65 and are documented 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`
|