Document post-dev handoff flow

PROJECT.md

@@ -31,6 +31,7 @@ Phase 1 scaffold started from the approved planning docs, and the Vikunja board
 - Playwright browser test harness for dev and QA
 - Vikunja board normalized to the playbook lane model
 - The first build tickets are queued on the board, with later phase work staged behind them
+- Post-dev flow is documented so implementation tickets always merge to `develop`, then hand off into test/validation before QA promotion
 
 ## Next Build Step
 

README.md

@@ -8,6 +8,7 @@ Phase 1 scaffold has started. The repo now contains the Next.js app shell, Prism
 The browser test harness is now being added as a separate action that targets Dev and QA only.
 The project has been onboarded to Vikunja and the board now uses the playbook lane model.
 The next public work is queued as tickets, with `VIK-112` staged as the next active item after the current slice.
+Implementation tickets are expected to merge back to `develop` first, then hand off into `Ready for Test` / `Deploying to Dev` before Trinity validation and later QA promotion.
 
 ## Working Rule
 

VIKUNJA.md

@@ -45,3 +45,7 @@ This board is normalized to the shared playbook lane model.
 - 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.