# 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.
- 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.