Document Playwright coverage expectations

PROJECT.md

@@ -32,6 +32,7 @@ Phase 1 scaffold started from the approved planning docs, and the Vikunja board
 - 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
+- New functionality should extend the Playwright suite so browser regression coverage grows with the app
 
 ## Next Build Step
 

README.md

@@ -9,6 +9,7 @@ The browser test harness is now being added as a separate action that targets De
 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.
+Any new feature work should also update the Playwright suite so the browser tests become the main regression check as coverage expands.
 
 ## Working Rule
 

VIKUNJA.md

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