chris.dumas/holiday-property-booking
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Document Playwright coverage expectations
All checks were successful
Deploy Holiday Property Booking / deploy (push) Successful in 1m31s
Details
Playwright Holiday Property Booking / playwright (push) Successful in 11m6s
Details
Test & Build Holiday Property Booking / test-build (push) Successful in 10m51s
Details

Browse Source
This commit is contained in:
Chris Dumas
2026-05-22 10:55:47 +00:00
parent bf51d51a7b
commit 85fc02fcfa
3 changed files with 3 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
PROJECT.md
View File

@@ -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 - Vikunja board normalized to the playbook lane model
- The first build tickets are queued on the board, with later phase work staged behind them - 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 - 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 ## Next Build Step

1
README.md
View File

@@ -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 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. 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. 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 ## Working Rule

1
VIKUNJA.md
View File

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