diff --git a/docs/reuse-surface-on-railiance01.md b/docs/reuse-surface-on-railiance01.md
index 670492c..a30291a 100644
--- a/docs/reuse-surface-on-railiance01.md
+++ b/docs/reuse-surface-on-railiance01.md
@@ -104,8 +104,22 @@ reuse-surface hub list
 curl -fsS "$REUSE_SURFACE_URL/v1/federated" | jq '.capabilities | length'
 ```
 
-Deployed image tag: see `helm/reuse-surface-values.yaml` (currently `cb7a6e4`).
-Dogfood: `reuse-surface` repo registered; federated index returns 12 capabilities.
+Deployed image tag: see `helm/reuse-surface-values.yaml` (currently `e3ae22e`,
+deployed 2026-07-07 for REUSE-WP-0019-T01/T02).
+Dogfood: `reuse-surface` repo registered; federated index returns 61 capabilities.
+
+**Known issue (found 2026-07-07, not fixed):** the public ingress serves
+`GET /v1/*` correctly but 404s on the exact-path `/health` rule — Traefik
+appears to shadow it with the catch-all `/` rule routed to
+`reuse-surface-landing`. Confirmed NOT a pod/service problem: `/health`
+works correctly via direct port-forward to `svc/reuse-surface`, and the
+Deployment's own internal readiness/liveness probes (which hit `/health`
+directly, bypassing ingress) pass fine — the pod is `1/1 Ready`. Only
+public external monitoring against `https://reuse.coulomb.social/health`
+is affected; real API clients using `/v1/*` are unaffected. Needs an
+explicit Traefik router priority annotation (or a path-rule reorder) on
+`charts/reuse-surface/templates/ingress.yaml` — deliberately not changed
+here since it's a shared production ingress edit outside this task's scope.
 
 ## Operations