Repository navigation
Sprint 4
Generated from
docs/planning/sprints/sprint-04.md. Edit that file in the repository: changes made in the wiki are overwritten.
The planning record of Sprint 4, kept as the Work Management and Delivery Specification requires (§7, §14). Reconstructed on 2026-10-02 from the items' close dates (#339), when the owner split release 1. No sprint was planned in advance: the goal summarizes what was done, and no capacity was recorded at the time. These one-day sprints adapt past work to the specification; they don't change its rules.
| Field | Value |
|---|---|
| Sprint | Sprint 4 (Project iteration Sprint 4) |
| State | Ended |
| Start | 2026-10-02 00:00 Europe/Brussels, inclusive |
| End | 2026-10-03 00:00 Europe/Brussels, exclusive |
| Duration | One day (history, owner decision on #339) |
| Release |
v0.2, its final sprint by owner exception: it wasn't a stabilization sprint |
Adopt the Work Management and Delivery Specification and split release 1 into releases and sprints.
None recorded at the time. The sprint is reconstructed from completed work.
No sprint backlog was selected in advance (see above). The scope is every item whose Sprint is Sprint 4 on the Project:
11 outcome items and 26 tasks, all in release v0.2. #203 and #350 also have tasks finished in earlier sprints,
shown in brackets.
Reviewed on 2026-10-03, after the sprint ended at 00:00, from a read-back of the Project (#400, #401).
Achieved. The specification was adopted (#323, closed at 15:24) and release 1 was split into releases and sprints (#339, 16:20). The same day also planned Sprint 5 and approved release v0.3 (#360), and brought the OVH test deployment into v0.3 (#367, #378).
Every item and task in the sprint closed as completed before the sprint ended. The Story Points are the retrospective estimates of #346, set after the work; they aren't velocity (see Sprint 5).
User stories, 18 points:
| Item | Story Points | Closed (2 October) | Tasks in Sprint 4 (earlier) |
|---|---|---|---|
| #308 create RaidManager roles with chosen permissions | 5 | 10:27 | #310, #312, #313, #314 |
| #350 Link a community and enforce officer permissions (part delivered in v0.2) | 13 | 16:50 | #290, #296 (#286, #287, #288, #289, #294, #297, #300) |
Improvements, 38 points, counted separately from stories (specification §9):
| Item | Story Points | Closed (2 October) | Tasks in Sprint 4 (earlier) |
|---|---|---|---|
| #203 Re-theme the website to the design system | 8 | 06:20 | #305, #306 (#263, #265, #275) |
| #158 Enforce the Epic, Feature, Story and Task hierarchy | 3 | 15:06 | #318, #321 |
| #323 Adopt the Work Management and Delivery Specification | 13 | 15:24 | #324, #325, #326, #327, #328, #329, #330, #337 |
| #339 Split release 1 into releases and sprints | 3 | 16:20 | #340, #341 |
| #343 Show releases and sprints clearly on the Project | 2 | 16:46 | #344 |
| #346 Keep each sprint on one release and complete estimates and stages | 3 | 17:16 | #347, #348 |
| #360 Plan Sprint 5 and approve release v0.3 | 2 | 20:14 | #361 |
| #367 Apply the release decisions of 2 October and add the OVH test deployment to v0.3 | 3 | 22:44 | #368 |
| #378 Bring the OVH deployment spike into Sprint 5 | 1 | 23:31 | #379 |
No bugs, spikes or stabilization work were in the sprint.
None. No item in Sprint 4 is open or canceled.
None needed: nothing is carried over. Release v0.2, whose final sprint this was, stays open until the first
deployment (owner decision 3 on #367).
| Date | Change |
|---|---|
| 2026-10-02 | Created as Sprint 1 (2 to 16 October) for the adoption work (#323). |
| 2026-10-02 | Owner decision on #339: renumbered Sprint 4 and shortened to 2 October, keeping its items; the two-week sprint moved to start on 3 October as Sprint 5. |
| 2026-10-03 | Reviewed after its end (#401). The reconstruction of 2 October had listed #164, #168, #172 and #198 by their close date; their tasks finished in Sprint 2, where the Project places them, and the items closed later on 2 October are added. |
- Product scope
- Architecture
- Visual guide
- Diagram maintenance
- Review a pull request
- Design a screen
- Test the addon
- Set up Discord
- Provision the server
- Glossary
- API contracts
- Addon snapshot contract
- Project automation
- Work management specification
- Warmane lockout evidence
- Planning
-
Decisions
- Index
- Foundation and authentication
- Character synchronization
- Documentation publication
- Protected automatic squash merges
- Viewed files before approval
- Operator review before a peer
- Auto-merge when ready
- Merge with the workflow token
- Meaningful review comments
- Read queries from the write database
- Website session and API trust
- Interactive Server rendering with Radzen
- Scalar API reference
- GitHub Wiki mirror
- Coverage gate
- Work item hierarchy
- Penpot mockups
- Generated Penpot mockups
- Dark design system
- SonarCloud findings
- Addon roster import
- Discord role checks
- Discord servers at sign-in
- Community roles
- Work item classification
- Work management specification adoption
- OVH test environment
- Environment secrets
- PostgreSQL
- Companion pairing
- WoW addon in Lua
- Windows companion in Avalonia
- Companion in the Microsoft Store
- Workflows on a self-hosted runner