distill: best practices from 2026-04-19 cross-project run

Adds 3 new topic files (ai-parallel-agents, api-integration,
python-patterns) and extends 21 existing topic files with new gotchas
and patterns surfaced from memory across tracked projects. Index
updated accordingly.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

security-architecture.md

@@ -77,3 +77,37 @@ Some scenarios genuinely require client-side credentials (e.g., direct S3 upload
 **Wrong:** CMS authenticates directly with Gitea via OAuth popup. Gitea token lands in browser localStorage. CMS makes API calls directly to Gitea with the token.
 
 **Right:** CMS sits behind Authelia (MFA). A proxy service intercepts the OAuth flow, issues a proxy session token (containing only the user's identity), and forwards all API calls to Gitea using a per-user server-side Gitea token. The Gitea token never leaves the server.
+
+## Multi-Tenant Isolation Guard on Outbound Writes
+
+When a service writes into per-tenant destinations — customer Slack channels, per-customer boards, per-org webhooks, tenant-scoped buckets — route every outbound write through a single **IsolationGuard** module.
+
+### What the guard validates
+
+For every outbound write, the guard checks:
+
+1. **Destination ownership** — the target channel/board/webhook belongs to the tenant the write is scoped to
+2. **Payload cross-references** — the payload does not reference other tenants by name or ID (string match against the known tenant list)
+3. **Cross-tenant field stripping** — fields known to carry cross-tenant context (internal descriptions, linked-issue titles, audit trails) are removed or redacted before leaving the service
+
+### Why centralise it
+
+Per-tenant isolation is only testable if there is one place to exercise. If each call site inlines its own "scope this write" logic, cross-tenant leak tests must cover every call site and every future one. A single guard module:
+
+- Gives tests one surface to fuzz with adversarial payloads
+- Makes it impossible to ship a new outbound path that forgets the check (the guard is the only API)
+- Centralises logging for any blocked write — leaks become observable, not silent
+
+### Pattern
+
+```
+CallSite ──→ IsolationGuard.send(tenant_id, destination, payload)
+                  │
+                  ├── Validate destination ∈ tenant_id's destinations
+                  ├── Scan payload for other tenants' names/IDs
+                  ├── Strip cross-tenant fields per schema
+                  ├── Log (tenant_id, destination, redacted fields)
+                  └── Dispatch to underlying transport
+```
+
+No call site should import the underlying transport directly. Lint or grep for direct imports as a CI check.