The project board is where discovery turns into durable delivery work. It is SwarmCraft's Kanban-style view of the tasks required to create, check, review, and complete your project.
The delivery loop is simple: choose a task, open its working packet, implement the scoped change, record evidence, run the relevant checks, and move the task only when its state is true.
Read the board from left to right. Each task moves through implementation, technical checking, and human review before it is complete.
Read a task card
Each card is one task: a meaningful unit of project delivery work. A card shows:
- the task title and a short summary of the intended result
- its recommended order in the project
- completed checklist items compared with the total checklist
- when the task was last updated
- the option to open the task or drag it to another position or lane
Open a card to read or update its full details. The browser asks you to confirm before moving a task between lanes because the board should record a real change in the work, not just a visual rearrangement.
Workflow states
The normal board flow is:
- Todo means the task is defined and ready, but work has not started.
- Doing means implementation is actively changing the owned source code or other project output.
- Checking means the implementation is being technically validated and evidence is being recorded.
- Reviewing means a person is understanding the result, asking questions, and deciding whether to approve it.
- Done means the result has been reviewed, approved, and completed.
Each lane should represent a real change in delivery state, not just a cosmetic move.
Move work forward and back
The usual path is Todo → Doing → Checking → Reviewing → Done. Work can move back when it is not ready: a failed technical check returns to Doing, while review feedback can return the task to the earlier lane where the required change belongs. Record the reason in the task or working packet so the next pass starts with useful context.
SwarmCraft prefers lane changes from the VS Code extension because it keeps the board, working packet, and repository together. The extension moves linked tasks one adjacent lane at a time. Browser dragging is useful for an intentional correction, but confirm each move and keep it consistent with the repository work.
The final move to Done is a human action. When the VS Code auto-commit preference is enabled and the repository is in a safe state, the extension creates a local Git commit before completing the move. Moving a card in the browser does not provide the same packet-backed completion and commit assurance, so use the extension for linked implementation work.
Task, checklist, and working packet
A task is the unit that moves across the board. Checklist items are smaller expectations inside that task, grouped around implementation, checking, or review. Completing a checklist item records progress; it does not create another board task.
A working packet is the repository file linked to a task when you work through the VS Code extension or CLI. It carries the task goal, checklist, notes, agent update, and current lane alongside the source code. It supports the task; it is not a second name for it.
Packet-backed execution
Both delivery modes use the same server-owned board and repository packet contract:
- Choose interactive VS Code delivery when a person should guide one task through implementation, checking, and review.
- Choose the one-shot CLI when an experienced operator wants a bounded terminal run across selected tasks. Its default customer policy skips separate checking and reviewing lanes unless enabled.
Do not run both modes against the same active task. Refresh the board before changing mode so the packet revision and lane are current.
Prove the project builds
The board does not prescribe one build tool. Each task or project guide should name the repository's real install, build, lint, test, and run commands. Before moving a task from Checking, record the exact commands and results in the packet. A green board without reproducible repository evidence is not a successful build.
If a build fails, keep the task in or return it to Doing, record the failure, fix the smallest owning change, then rerun the relevant check. Do not move it forward to make the board look complete.
Keep movement honest
Keep tasks small enough that one person can understand the goal, complete the checklist, and prove the result without needing a second planning cycle. Move them when the work actually changes state. SwarmCraft is more useful when the board reflects reality instead of optimism.
Success means the board lane, packet checklist, repository state, and recorded evidence agree. Continue with one delivery mode above. When every first-release task is reviewed, deploy and operate the app.