chore: Enhance governance and security guidelines in documentation for GORM and token protection

.github/instructions/copilot-instructions.md

@@ -17,6 +17,23 @@ Every session should improve the codebase, not just add to it. Actively refactor
 - **READABLE**: Maintain comments and clear naming for complex logic. Favor clarity over cleverness.
 - **CONVENTIONAL COMMITS**: Write commit messages using `feat:`, `fix:`, `chore:`, `refactor:`, or `docs:` prefixes.
 
+## Governance & Precedence
+
+When policy statements conflict across documentation sources, resolve using this precedence hierarchy:
+
+1. **Highest Precedence**: `.github/instructions/**` files (canonical source of truth)
+2. **Agent Overrides**: `.github/agents/**` files (agent-specific customizations)
+3. **Operator Documentation**: `SECURITY.md`, `docs/security.md`,
+   `docs/features/notifications.md` (user-facing guidance)
+
+**Reconciliation Rule**: When conflicts arise, the stricter security requirement
+wins. Update downstream documentation to match canonical text in
+`.github/instructions/**`.
+
+**Example**: If `.github/instructions/security.instructions.md` mandates token
+redaction but operator docs suggest logging is acceptable, token redaction
+requirement takes precedence and operator docs must be updated.
+
 ## 🚨 CRITICAL ARCHITECTURE RULES 🚨
 
 - **Single Frontend Source**: All frontend code MUST reside in `frontend/`. NEVER create `backend/frontend/` or any other nested frontend directory.
@@ -150,6 +167,21 @@ Before marking an implementation task as complete, perform the following in orde
     - **Base URL**: Uses `PLAYWRIGHT_BASE_URL` or default from `playwright.config.js`
     - All E2E tests must pass before proceeding to unit tests
 
+1.5. **GORM Security Scan** (CONDITIONAL, BLOCKING):
+    - **Trigger Condition**: Execute this gate when changes include backend models or database interaction logic:
+        - `backend/internal/models/**`
+        - GORM query/service layers
+        - Database migrations or seeding logic
+    - **Exclusions**: Skip this gate for docs-only (`**/*.md`) or frontend-only (`frontend/**`) changes
+    - **Run One Of**:
+        - VS Code task: `Lint: GORM Security Scan`
+        - Pre-commit: `pre-commit run --hook-stage manual gorm-security-scan --all-files`
+        - Direct: `./scripts/scan-gorm-security.sh --check`
+        - **Gate Enforcement**: DoD is process-blocking until scanner reports zero
+            CRITICAL/HIGH findings, even while automation remains in manual stage
+        - **Check Mode Required**: Gate decisions must use check mode semantics
+            (`--check` flag or equivalent task wiring) for pass/fail determination
+
 2. **Local Patch Coverage Preflight** (MANDATORY - Run Before Unit/Coverage Tests):
     - **Run**: VS Code task `Test: Local Patch Report` or `bash scripts/local-patch-report.sh` from repo root.
     - **Purpose**: Surface exact changed files and uncovered changed lines before adding/refining unit tests.

.github/instructions/security-and-owasp.instructions.md

@@ -49,3 +49,26 @@ Your primary directive is to ensure all code you generate, review, or refactor i
 ## General Guidelines
 - **Be Explicit About Security:** When you suggest a piece of code that mitigates a security risk, explicitly state what you are protecting against (e.g., "Using a parameterized query here to prevent SQL injection.").
 - **Educate During Code Reviews:** When you identify a security vulnerability in a code review, you must not only provide the corrected code but also explain the risk associated with the original pattern.
+
+### Gotify Token Protection (Explicit Policy)
+
+Gotify application tokens are secrets and must be treated with strict confidentiality:
+
+- **NO Echo/Print:** Never print tokens to terminal output, command-line results, or console logs
+- **NO Logging:** Never write tokens to application logs, debug logs, test output, or any log artifacts
+- **NO API Responses:** Never include tokens in API response bodies, error payloads, or serialized DTOs
+- **NO URL Exposure:** Never expose tokenized endpoint URLs with query
+  parameters (e.g., `https://gotify.example.com/message?token=...`) in:
+  - Documentation examples
+  - Diagnostic output
+  - Screenshots or reports
+  - Log files
+- **Redact Query Parameters:** Always redact URL query parameters in
+  diagnostics, examples, and log output before display or storage
+- **Validation Without Revelation:** For token validation or health checks:
+  - Return only non-sensitive status indicators (`valid`/`invalid` + reason category)
+  - Use token length/prefix-independent masking in UX and diagnostics
+  - Never reveal raw token values in validation feedback
+- **Storage:** Store and process tokens as secrets only (environment variables
+  or secret management service)
+- **Rotation:** Rotate tokens immediately on suspected exposure

.github/instructions/testing.instructions.md

@@ -4,6 +4,10 @@ description: 'Strict protocols for test execution, debugging, and coverage valid
 ---
 # Testing Protocols
 
+**Governance Note**: This file is subject to the precedence hierarchy defined in
+`.github/instructions/copilot-instructions.md`. When conflicts arise, canonical
+instruction files take precedence over agent files and operator documentation.
+
 ## 0. E2E Verification First (Playwright)
 
 **MANDATORY**: Before running unit tests, verify the application UI/UX functions correctly end-to-end.
@@ -170,16 +174,39 @@ Before pushing code, verify E2E coverage:
 * **Threshold Compliance:** You must compare the final coverage percentage against the project's threshold (Default: 85% unless specified otherwise). If coverage drops, you must identify the "uncovered lines" and add targeted tests.
 * **Patch Coverage (Suggestion):** Codecov reports patch coverage as an indicator. While developers should aim for 100% coverage of modified lines, patch coverage is **not a hard requirement** and will not block PR approval. If patch coverage is low, consider adding targeted tests to improve the metric.
 * **Review Patch Coverage:** When reviewing patch coverage reports, assess whether missing lines represent genuine gaps or are acceptable (e.g., error handling branches, deprecated code paths). Use the report to inform testing decisions, not as an absolute gate.
+
 ## 4. GORM Security Validation (Manual Stage)
 
-**Requirement:** All backend changes involving GORM models or database interactions must pass the GORM Security Scanner.
+**Requirement:** For any change that touches backend models or
+database-related logic, the GORM Security Scanner is a mandatory local DoD gate
+and must pass with zero CRITICAL/HIGH findings.
 
-### When to Run
+**Policy vs. Automation Reconciliation:** "Manual stage" describes execution
+mechanism only (not automated pre-commit hook); policy enforcement remains
+process-blocking for DoD. Gate decisions must use check semantics
+(`./scripts/scan-gorm-security.sh --check` or equivalent task wiring).
 
-* **Before Committing:** When modifying GORM models (files in `backend/internal/models/`)
-* **Before Opening PR:** Verify no security issues introduced
-* **After Code Review:** If model-related changes were requested
-* **Definition of Done:** Scanner must pass with zero CRITICAL/HIGH issues
+### When to Run (Conditional Trigger Matrix)
+
+**Mandatory Trigger Paths (Include):**
+- `backend/internal/models/**` — GORM model definitions
+- Backend services/repositories with GORM query logic
+- Database migrations or seeding logic affecting model persistence behavior
+
+**Explicit Exclusions:**
+- Docs-only changes (`**/*.md`, governance documentation)
+- Frontend-only changes (`frontend/**`)
+
+**Gate Decision Rule:** IF any Include path matches, THEN scanner execution in
+check mode is mandatory DoD gate. IF only Exclude paths match, THEN GORM gate
+is not required for that change set.
+
+### Definition of Done
+- **Before Committing:** When modifying trigger paths listed above
+- **Before Opening PR:** Verify no security issues introduced
+- **After Code Review:** If model-related changes were requested
+- **Blocking Gate:** Scanner must pass with zero CRITICAL/HIGH issues before
+   task completion
 
 ### Running the Scanner