Release, Archiving, and Iteration

Release process

• After finishing a change: openspec archive <change-id> and openspec validate --specs to confirm the truth source is updated.
• Release notes must reference evidence (meeting/email) and test results (PHPStan profile, PHPUnit, click-test report).
• New requests after go-live always start from another meeting or email → intake → change proposal → sprint.

---

Checklists

Evidence & specification

• [ ] Every requirement has source linking to meeting timestamp or email message-id.
• [ ] Transcript is stored and linked in openspec.
• [ ] openspec validate --strict passed for the change/spec.
• [ ] Manual review by architect/PM confirmed.

Build quality

• [ ] PHPStan ran with the config for the target EspoCRM version (state the file).
• [ ] PHPUnit tests (if present) ran.
• [ ] Frontend lint (Autocrm/FE) ran.
• [ ] CI jobs are green.

Testing

• [ ] Unit/integration covered critical logic.
• [ ] Click-test scenarios executed; report and checklist updated.
• [ ] Cleanup done (no leftover data).

Release / iteration

• [ ] openspec archive executed for completed changes.
• [ ] Release notes include links to evidence and tests.
• [ ] New change requests go back through intake (meeting/email).

---

➡️ Continue to Iterative development for the ongoing change workflow.