Warns against copying the reference project's nginx Sentry tunnel

The backend already serves /sentry-tunnel itself with its own rate
limit, payload cap, and DSN-derived destination - exactly what that
nginx block exists to avoid needing. Proxying the same path at nginx
intercepts it first and silently drops all three protections.

aidlc-docs/features/gitea-deployment-workflow/audit.md

@@ -1399,3 +1399,13 @@ by Infrastructure Design. U5 carries REF-U3-01's Umami origin gate plus FR-21 an
 **Context**: OPERATIONS — Deployment Setup, reverse-proxy topology corrected across Operations and Construction docs
 
 ---
+## Deployment Setup — nginx Sentry Tunnel Block Shadows the Backend's Own Tunnel
+
+**Timestamp**: 2026-07-29T00:50:00Z
+
+**User Input**: Shared their actual proxy-Pi nginx config, which includes a `location /sentry-tunnel { proxy_pass https://o4511795618185216.ingest.de.sentry.io/...; }` block carried over from the reference project, and asked whether it's still needed.
+
+**AI Response**: "Confirmed this is a real conflict, not just redundancy: SentryTunnelExtensions.cs (U4) already serves /sentry-tunnel on the backend itself, with its own rate limiter, TunnelMaxPayloadBytes cap, and a destination derived dynamically from Observability__SentryDsn. The code's own comment says the reference project's nginx-tunnel approach is exactly what this backend feature was built to avoid. The user's nginx block intercepts the same path before it reaches pi-main, bypassing all three backend protections and hardcoding the Sentry org/project ID as a second place that must be kept in sync with the app config. Recommended removing the nginx block entirely and letting /sentry-tunnel fall through to pi-main like any other request. Added an explicit warning in deployment-instructions.md § 1.7 telling readers not to carry this nginx block over from the reference project."
+
+**Context**: OPERATIONS — Deployment Setup, real host config revealed the reference project's nginx Sentry-tunnel pattern was carried over unnecessarily and conflicts with this app's own built-in tunnel
+---

aidlc-docs/features/gitea-deployment-workflow/operations/deployment/deployment-instructions.md

@@ -232,6 +232,15 @@ domain through the proxy Pi to *any* backend (this deployment's domains included
 § 1.7.2 is what that procedure produced for `slpsoftware.nl` — the worked example, not a separate
 step.
 
+> **Do not add a `/sentry-tunnel` proxy block on the proxy Pi.** The reference project (a static
+> frontend with no backend of its own) had to tunnel through nginx directly to Sentry's ingest URL.
+> This application does not need that: `SentryTunnelExtensions.cs` (built in U4) serves
+> `/sentry-tunnel` itself, with its own rate limiter, a payload-size cap
+> (`Observability:TunnelMaxPayloadBytes`), and a destination derived from `Observability__SentryDsn`
+> rather than a hardcoded org/project ID. An nginx-level tunnel block at the same path intercepts
+> the request before it ever reaches pi-main, silently bypassing all three of those protections —
+> let `/sentry-tunnel` fall through the plain `location /` block like any other request instead.
+
 #### 1.7.1 Adding a New Domain From Scratch (on the proxy Pi)
 
 Starting from nothing — no existing server block, no certificate — for a new domain