Release v0 4 - AnnabiGihed/RaidManager GitHub Wiki
Generated from
docs/planning/releases/v0.4.md. Edit that file in the repository: changes made in the wiki are overwritten.
The planning record of release v0.4, Raid scheduling and readiness, kept as the Work Management and Delivery
Specification requires (§6, §14).
Draft awaiting owner approval. The owner asked the agent to split release 1 and set its dates (#339); the goal, criteria and scope below were drafted from Product scope and workflows and the epics. None of them is agreed until Gihed Annabi approves it.
| Field | Value |
|---|---|
| Version | v0.4 (repository milestone v0.4) |
| State | Draft: Planned once the owner approves it (§6) |
| Target date | 2027-01-22 (last day of Sprint 12, its stabilization sprint) |
| Actual delivery date | Not delivered |
| Approval | None yet |
Goal (draft)
Officers schedule raids and players sign up on the website or in Discord, with a reliable verdict on whether each character can join at the raid's start.
Acceptance criteria (draft)
- A player offers multiple specializations through either channel, saves a preset, and sees one consistent confirmed, tentative, late, or declined response on both channels (journey 2).
- A character saved today can join a raid after its reset, but can't be offered for a raid before that reset; an unknown save requests synchronization and never appears as confirmed available (journey 3).
- A changed raid time or fresh lockout snapshot triggers a new verdict and alerts the affected player and officer; the officer can record a reasoned exception for unknown data, but not for a confirmed active lockout (journey 5).
The repository's quality gates pass on the released version, and the stabilization sprint records its release checks below.
Scope (draft)
10 open outcome items, 60 Story Points estimated:
- #14 (user story) Link a community and enforce officer permissions: 8 points (moved from v0.3, #367)
- #20 (user story) Browse, create, and edit scheduled raids: 8 points
- #21 (user story) Generate weekly raids from reusable templates: 5 points
- #22 (user story) Respond on the website with multiple characters and presets: 8 points
- #23 (user story) Respond through Discord using the same signup: 8 points
- #24 (user story) Receive concise raid changes and reminders: 5 points
- #25 (user story) Capture complete and fresh raid-save evidence: 5 points
- #26 (user story) Assess lockouts at scheduled raid start: 5 points
- #27 (user story) Evaluate combined raids and block confirmed locks: 3 points
- #28 (user story) Re-evaluate changes and review unknown-data exceptions: 5 points
Their tasks share this milestone. Features and epics that also hold work of other releases carry no milestone (§15, A2).
Sprint sequence
| Sprint | Dates (Europe/Brussels) | Purpose |
|---|---|---|
| Sprint 9 | 2026-11-28 to 2026-12-12 (end exclusive) | Delivery |
| Sprint 10 | 2026-12-12 to 2026-12-26 (end exclusive) | Delivery |
| Sprint 11 | 2026-12-26 to 2027-01-09 (end exclusive) | Delivery |
| Sprint 12 | 2027-01-09 to 2027-01-23 (end exclusive) | Stabilization |
The dates assume 20 Story Points per two-week sprint, a conservative assumption until velocity exists (§9): 52 points fit in three delivery sprints, with time left for spikes, improvements and bugs.
Stabilization plan
Sprint 12: blocking defects, regressions, end-to-end validation of the acceptance criteria, documentation, release
notes, deployment and rollback preparation, planned as concrete items (work-stabilization-and-release-closure).
Scope decisions
| Date | Decision | Recorded on |
|---|---|---|
| 2026-10-02 | Release 1 split; the agent drafted this release's scope, sprints and target date at the owner's request. | #339 |
| 2026-10-02 | #14 and its task #291 join this release from v0.3: they need the raid commands of #20. | #367 |
Readiness evidence
None yet.