-
Notifications
You must be signed in to change notification settings - Fork 0
Launch Checklist
- Reviewed approval and a separate retryable setup step.
- Credential repair that preserves agency information and reports old-password cleanup failures.
- Source-based post/page creation, editing, UTC scheduling, trash, stale-edit checks, and uncertain-create protection.
- Bounded collection pagination and native table/form/save-status components.
- Redacted local support diagnostics.
- Automated credential lifecycle, real content round trips, two-window isolation, accessibility checks, deterministic packaging, and 10/20/30-site load fixtures.
- End-user README; setup, coverage limits, security, and operational detail in this wiki.
Engineering update: the four bug-hunt findings are fixed locally, with new regression coverage. Publishing review/recovery, saved content views, and custom-type discovery now need inclusion in the agency/hosting pilot. Local checks do not remove the release gates below. See Modern Core and publishing.
- Distribution: choose GitHub-only or WordPress.org, confirm the compatible OpenStation package is publicly obtainable, and test the exact downloadable pair. Do not instruct ordinary users to rely on an unspecified trunk build.
- Pilot: recruit at least three agencies on different hosts. Give them staging sites and ask them to connect without live assistance, manage two sites at once, repair a revoked connection, and disconnect. Record completion time, blockers, support contacts, and incorrect-site actions. Require zero credential leaks, unintended writes, or lost saved data.
- Hosting matrix: test HTTPS redirects, subdirectory installs, plain/pretty permalinks, security plugins, Authorization-header forwarding, read-only filesystems/FTP prompts, disabled cron, and supported PHP/WordPress versions. Local SQLite load results do not replace this.
- Recovery: back up the hub database/files and salts securely; prove restoration on an isolated clone. Revoke pilot credentials when tests end. Validate interrupted setup and uncertain creation; do not promise automatic rollback.
- Support/security: name the response owner, publish a private security-reporting channel, document response expectations, and review redacted reports before sharing. GitHub public issues are for non-sensitive bugs.
- Release gate: run all checks on the final ZIP, verify artifact checksum, deploy to clean staging, and retake screenshots if visible UI changed. Freeze the supported feature list and changelog. Obtain explicit approval before publishing.
A candidate passes only when all core workflows work on the chosen hosting matrix, agencies can onboard using the documentation, saves hit the correct remote site, and revocation/recovery work as documented. Record unresolved issues with severity and reproduction. A local green test suite is not a public-launch certification.
Keep the prior ZIP and a pre-upgrade hub backup. Disconnecting is a deliberate credential operation, not an uninstall side effect. If an update fails, stop new onboarding/writes, capture a redacted report, restore a known-compatible package pair on staging, and verify stored connection generations before reopening access. Restore database/salts only from a matched backup; copying stale records over repaired connections can resurrect obsolete state.
GitHub pre-release publication is tracked in the release record. Pilot recruitment, private support setup, and a general-availability claim still require their owners' evidence/approval.