docs: restore push trigger to branches: [master] and document PR-trigger investigation

Co-authored-by: Junie <junie@jetbrains.com>

aidlc-docs/features/react-frontend/audit.md

@@ -408,3 +408,27 @@
 **Context**: Post-workflow follow-up (feature already marked Complete); corrects the previous follow-up which stopped short of fully centralizing the deploy destination and artifact naming. Changes not yet committed/pushed.
 
 ---
+
+## Post-Completion Follow-up: `push` Trigger No Longer Filtered to `master`
+
+**Timestamp**: 2026-07-24T16:27:00Z
+
+**User Input**: "maar ik wil dat de workflow ook draait als ik een pull request update of aanmaak zoals je in de andere triggers kan zien. Moet ik die branch check niet gewoon weghalen? Hij staat namelijk ook al als losse check in de deploy stap" — followed by: "De nee-optie klopt niet. ik zie namelijk de PR niet getriggerd worden nu. Dus ik zou zeggen haal voor nu weg."
+
+**AI Response**: "Removed the `branches: [master]` filter from the `push` trigger in `continuous_integration.yaml` (now `push: {}`), so `prepare`/`build`/`test` also run on pushes to any branch, not just `master`. The `pull_request` trigger itself was already unfiltered (`types: [opened, synchronize, reopened]`, no `branches` key) and was not the cause of PRs not triggering; the user reported PRs weren't triggering regardless, and explicitly asked to remove the redundant branch check since `deploy-test` already has its own `if`-guard restricting deploy to `master`/`workflow_dispatch`. Updated `deployment-instructions.md` and `deployment-plan.md` to reflect that build/test now runs on every push/PR, while deploy stays gated to `master`."
+
+**Context**: Post-workflow follow-up (feature already marked Complete); simplifies trigger config per user request. Note: if PRs still don't trigger after this change, the root cause may lie elsewhere (e.g. Gitea repository Actions settings/permissions), which is outside this workflow file and should be checked separately.
+
+---
+
+## Post-Completion Follow-up: `push` Trigger Restored to `branches: [master]`
+
+**Timestamp**: 2026-07-24T16:31:00Z
+
+**User Input**: "kan die hele push trigger dan niet gewoon weg ipv Push: {} te laten staan? Nu zal het aanmaken van een PR niks doen" — followed by clarification that removing the push trigger entirely would break automatic `deploy-test` after merging to master, and the reply: "dan zou dus de push trigger met master gewoon terug kunnen. Waarom triggert de Workflow dan nu niet op de huidige PR? Kloppen de pull_request triggers dan misschien niet? Zoek uit, verander en commit de changes".
+
+**AI Response**: "Restored `push: branches: [master]` in `continuous_integration.yaml` (reverting the previous `push: {}` change), since removing the push trigger entirely would have stopped automatic `deploy-test` after merging a PR to master, while keeping it unfiltered was unnecessary (the `pull_request` trigger already runs on every PR regardless of branch). Investigated why the PR itself wasn't triggering: confirmed (per Gitea/GitHub Actions behavior) that for `pull_request` events, the workflow definition used is the one from the PR's HEAD branch, not the base branch, so the feature branch's own (correct) `pull_request` trigger should apply. Found that `origin/master`'s copy of `continuous_integration.yaml` is still an old, stale version (`push: branches: [main]`), confirming that none of this session's workflow fixes have been merged into `master` yet — this by itself should not block PR triggering (per the HEAD-branch behavior above) but does mean `master` runs an outdated pipeline for direct pushes/merges until a PR from this feature branch is merged. Could not access the Gitea instance itself (no direct access from this session) to inspect Actions run history/settings, so could not conclusively diagnose why the PR isn't triggering — advised the user to check the PR's Actions/Checks tab in Gitea for a skipped/error state, confirm Actions is enabled for the repository, and confirm a runner is online and picking up jobs."
+
+**Context**: Post-workflow follow-up (feature already marked Complete); reverts the previous change and documents remaining open questions about the PR triggering issue that require checking the Gitea instance directly. Committed on `feature/updates_gitea_workflow`.
+
+---

aidlc-docs/features/react-frontend/operations/deployment/deployment-instructions.md

@@ -8,7 +8,7 @@ Deployment gebeurt via Gitea Actions, opgesplitst in twee bestanden:
 Sinds deze stap wordt er automatisch gedeployed naar een **testomgeving**: een Raspberry Pi die de site serveert via nginx, bereikbaar achter een tweede Raspberry Pi met een nginx reverse proxy.
 
 ## Pipeline Files
-- `continuous_integration.yaml` — getriggerd door `pull_request` (build/test/lint-gate), `push` naar `master`, en handmatig via `workflow_dispatch`.
+- `continuous_integration.yaml` — getriggerd door `pull_request` (build/test/lint-gate, ongeacht branch), `push` naar `master` (build/test/lint-gate + `deploy-test`), en handmatig via `workflow_dispatch`.
   - Heeft bovenaan een `env:`-blok met alle aanpasbare waarden op één plek: `NODE_VERSION`, `PNPM_VERSION`, `ARTIFACT_NAME` (`dist`), `ARTIFACT_PATH` (`dist/`), `DEPLOY_ENVIRONMENT` (`test`) en `DEPLOY_PATH` (`/html/test/slpsoftware`).
   - `prepare` → `build` (uploadt de artifact, naam/pad uit `env.ARTIFACT_NAME`/`env.ARTIFACT_PATH`) → `test` (lint + unit tests)
   - Een losse `config`-job zet deze `env`-waarden om in job-outputs (zie hieronder waarom dat nodig is).

aidlc-docs/features/react-frontend/operations/deployment/deployment-plan.md

@@ -2,7 +2,7 @@
 
 ## Chosen Method
 **Gitea Actions**, opgesplitst in twee workflow-bestanden:
-- `.gitea/workflows/continuous_integration.yaml` — draait de build/test/lint-gate, automatisch bij elke pull request en bij elke push/merge naar `master`, of handmatig via `workflow_dispatch`.
+- `.gitea/workflows/continuous_integration.yaml` — draait de build/test/lint-gate, automatisch bij elke pull request (ongeacht branch) en bij elke push/merge naar `master`, of handmatig via `workflow_dispatch`. De `deploy-test`-job zelf blijft daarnaast ook beperkt tot `master`/`workflow_dispatch` via een eigen `if`-check.
 - `.gitea/workflows/deploy.yaml` — een herbruikbare (`workflow_call`) job die de `dist/` build via SCP (over SSH) uploadt naar de webroot van een omgeving.
 
 Sinds deze stap is er een echte, geautomatiseerde upload naar een **testomgeving**: een Raspberry Pi die de statische site serveert via nginx, achter een tweede Raspberry Pi die als nginx reverse proxy fungeert.