3.0 KiB
3.0 KiB
ForgeFlow current state
Baseline
- Baseline version: 0.10.0
- Baseline commit:
56efd1a00c2e76251a0b2e7a7a424d94200ae33c - Baseline branch:
main - Desktop runtime: Electron 43 with Node.js 22+ required by the source project
- Primary supported packaged updater: Windows installer and portable executable
The baseline was recorded before the 1.0 professionalization programme. It is the comparison point for functional, deployment and renderer regressions.
Known baseline evidence
npm run check: 155 tests, 152 passed, 3 environment-dependent Bash checks skipped, 0 failed.- OS-backed secure storage, encrypted Gitea token, Gitea API, repository and Actions access were available.
- Unraid exposed Docker, Compose, Git, tar and SHA-256 tooling.
- The server inventory contained active repository workloads plus a large number of historical or unrelated definitions that require backend classification.
- Windows release artifacts were checksum-protected but not Authenticode-signed.
No secret values, passwords, private keys or tokens are stored in this document.
Operation classes
| Class | Default | Examples |
|---|---|---|
| Read-only inspection | Allowed without confirmation | repository refresh, server inventory, deploy-key probe, preflight, audit export |
| Reconciliation | Preview required | adopt an exact workload, refresh a profile from server truth |
| Configuration mutation | Explicit action and audit record | save profile, rotate deploy key, change server settings |
| Deployment | Fresh preflight and confirmation | server pull, Direct Copy, Gitea Actions dispatch |
| Destructive maintenance | Recovery evidence and explicit confirmation | unlink, prune, key revocation, rollback |
Discovery and audit never belong to a mutating class. Ambiguous evidence cannot be promoted automatically.
Recovery model
ForgeFlow writes its configuration atomically. Explicit server reconciliation additionally creates a private recovery snapshot before changing profiles or deployment state. Encrypted user-created .ffbackup files remain the portable restore mechanism; recovery snapshots are local operational safeguards and can contain OS-encrypted credential material.
Issue priorities
- P0: active data loss, credential disclosure, arbitrary execution or uncontrolled production mutation.
- P1: release-blocking incorrect deployment, unsafe implicit mutation, broken recovery or material security gap.
- P2: important functional, accessibility, performance or maintainability defect with a safe workaround.
- P3: polish, documentation or low-risk improvement.
1.0 constraints
- No force-push or implicit repository history rewrite.
- No automatic deployment deletion.
- No desktop Gitea token on a server.
- Read-only repository-scoped deploy keys for server pull.
- SSH host-key changes fail closed.
- Live commit, remote commit and runtime health remain separate evidence.
- Packaged updates must fail closed on missing or mismatched release assets and SHA-256 evidence; paid code signing is optional.