54 lines
3.1 KiB
Markdown
54 lines
3.1 KiB
Markdown
# Vikunja
|
|
|
|
## Board
|
|
|
|
URL: http://vikunja.skynet.arpa/projects/19/77
|
|
Project ID: 19
|
|
Kanban view ID: 77
|
|
|
|
## Buckets
|
|
|
|
This board is normalized to the shared playbook lane model.
|
|
|
|
| Order | Bucket | ID | Playbook lane | Purpose |
|
|
|---:|---|---:|---|---|
|
|
| 1 | Backlog | 136 | Backlog | Ideas, rough tasks, and future work. |
|
|
| 2 | Ready for Dev | 137 | Ready | Refined and ready for implementation. |
|
|
| 3 | In Dev | 138 | In Progress | Active implementation work. |
|
|
| 4 | Ready for Test | 139 | Validate | Implementation complete and ready for validation. |
|
|
| 5 | Deploying to Dev | 140 | Validate | Dev deploy/verification in progress. |
|
|
| 6 | In QA | 141 | Validate | QA/live validation work. |
|
|
| 7 | Failed QA | 142 | Ready | Validation failed; return to the top of the fix queue with evidence. |
|
|
| 8 | Immediate Fix | 143 | Blocked | Urgent blocker requiring fast follow-up. |
|
|
| 9 | Ready for QA Promotion | 144 | Release | Ready for develop -> qa promotion sequencing. |
|
|
| 10 | Deploying to QA | 145 | Release | QA promotion/deploy in progress. |
|
|
| 11 | QA Deployed | 146 | Release | QA deploy complete and awaiting release decision. |
|
|
| 12 | Ready for Production | 147 | Release | Ready for production release batching. |
|
|
| 13 | Included in Next Release | 148 | Release | Queued for the next production release sweep. |
|
|
| 14 | Deploying to Production | 149 | Release | Production deployment in progress. |
|
|
| 15 | Production Deployed | 150 | Release | Production deploy complete and awaiting final closeout. |
|
|
| 16 | Done | 151 | Done | Fully complete. |
|
|
| 17 | Failed Deployment | 152 | Blocked | Deployment failure or broken promotion requiring intervention. |
|
|
| 18 | Blocked | 153 | Blocked | Cannot proceed without missing input/access/decision. |
|
|
|
|
## Labels
|
|
|
|
| Label | Purpose |
|
|
|---|---|
|
|
| [blocked] | Explicit blocker marker when work cannot continue. |
|
|
| [high risk] | Work that needs extra release/validation care. |
|
|
| [research] | Research is required before implementation. |
|
|
|
|
## Workflow Notes
|
|
|
|
- Planning docs are approved before build work.
|
|
- Phase 1 foundation work lands first.
|
|
- Feature work now lives on this board and should be tracked as separate tickets.
|
|
- Use the playbook lane names exactly when routing work.
|
|
- When a ticket finishes `In Dev`, Neo merges the feature branch back to `develop`, leaves a merge-complete comment, and hands the ticket forward for validation rather than marking it done.
|
|
- When Morpheus routes work, send Neo the handoff directly and leave the ticket comment as a concise record of the lane change and next action; do not rely on the bucket comment as the only delivery path.
|
|
- After the merge, move the ticket into `Ready for Test` and then `Deploying to Dev` while the dev build/deploy proves the change.
|
|
- Trinity handles validation once the dev environment is ready, and the ticket only moves forward after the live check passes.
|
|
- QA promotion is a separate step after dev validation, not part of the merge itself.
|
|
- When new functionality lands, update the Playwright suite at the same time so browser coverage keeps pace with the app and can gradually replace repetitive manual validation.
|