# 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`