chore(cymbal): add shimforge to simplify tests

.agents/security.md

@@ -157,3 +157,43 @@ semgrep --test .semgrep/rules/security/
 # Or via Docker
 docker run --rm -v "${PWD}:/src" semgrep/semgrep semgrep --test /src/.semgrep/rules/security/
 ```
+
+## Content Security Policy
+
+`CSPMiddleware` in `posthog/middleware.py` attaches a policy to every HTML response.
+Treat it as enforced.
+A refused resource produces no user-visible error, so the feature simply does not work, and the only signal is a `$csp_violation` event in project 2.
+
+Three policies exist, and a change lands in whichever one covers the page:
+
+- **The app policy** governs every SPA page. It is enforced per user behind the `csp-enforce-app-policy` flag, and report-only otherwise.
+- **The admin policy** governs `/admin/`. It is enforced for every staff member, with no flag, so a mistake here breaks admin immediately.
+- **A view may set its own policy.** The canvas artifact and the workflow asset endpoint do this to sandbox untrusted HTML. `CSPMiddleware` returns a response that already carries the header unchanged, so do not expect the app policy on those documents.
+
+### What the app policy forbids
+
+| You want to                     | The policy says                                                                                                                                                       |
+| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Load a script from a new origin | Only `'self'`, our own CDNs, and a named list. Stripe, Turnstile and Unlayer are there because each vendor requires its own origin. Prefer serving the file yourself. |
+| Call `eval` or `new Function`   | Refused. `wasm-unsafe-eval` permits WebAssembly compilation only.                                                                                                     |
+| Start a worker                  | `'self'` and `blob:` only. Never `data:`: a `data:` worker body is code the policy cannot inspect.                                                                    |
+| Load a font from a CDN          | Self-host it instead. A CDN font already caused a regression when the origin was removed.                                                                             |
+| Submit a form                   | `'self'` plus the admin OAuth origin. The directive is checked on every hop of a redirect chain, so a same-origin action that redirects off-origin is refused.        |
+| Set `<base href>`               | Refused. Chromium judges the assignment even on a detached document.                                                                                                  |
+
+### Traps that have already cost us
+
+- **A dependency can carry the origin.** Grep `node_modules` for the literal host before you call an origin unused. A font CDN was removed on the belief nothing used it, and a transitive dependency defaulted to it.
+- **posthog-js wraps `fetch`, so an extension's request is reported with our bundle as the source file.** Never conclude a violation is ours from the source file alone. Corroborate with the blocked URL and the document.
+- **A CSP report names the original URL, not the hop that failed.** For `form-action` and any redirected navigation, the blocked URL can be same-origin while the refusal happened later in the chain.
+- **The Vite dev server cannot reproduce any of this.** It injects CSS as `<style>` blocks and emits absolute asset URLs, so paths that depend on a stylesheet's own href never run. Only the esbuild build matches production.
+
+### Checking a change
+
+Add the source to the policy that covers the document, which is not always `CSPMiddleware`.
+An app or admin page takes the matching list in `CSPMiddleware`.
+A canvas artifact takes `artifact_csp()` in `products/canvas/backend/contract.py`, and a workflow message asset takes the header its endpoint sets in `products/workflows/backend/api/hog_flow.py`.
+`CSPMiddleware` returns a view-set header untouched, so widening the app policy does nothing for those two.
+Say why the source is needed in a comment either way, then run `posthog/test/test_middleware.py::TestCSPMiddleware`.
+To see what the policy currently blocks, query `$csp_violation` events in project 2.
+Filter to the current policy text and exclude browser extensions on both the source file and the blocked URL, or the result is mostly noise.

.agents/skills/adding-inbound-webhooks/SKILL.md

@@ -45,6 +45,7 @@ Rules that decide whether this works:
 - The handler runs synchronously inside the request. Enqueue a task for real work, the way stamphog and conversations do.
 - A handler that reads the database wraps the read in `bounded_statement_timeout(ms, models=...)` from `posthog.ingress.dispatch.database`, passing only the models the read actually uses. Opening an alias is itself unbounded, so naming one the read never touches can stall the delivery on connection setup.
 - An import-linter contract (`webhook consumers must only import facade`) holds the module to its own product's `facade/`. Reach product internals through the facade.
+- A consumer whose resources are split across regions declares `ownership=`, pointing at a facade function that returns a `DeliveryOwnership`. Ingress forwards the signed request when the answer is `ELSEWHERE`, and dispatches locally either way. The lookup runs inside the request, so bound it with `bounded_statement_timeout(ms, models=...)`.
 
 Tests: extend the product's existing webhook test module rather than starting a parallel one.
 `products/stamphog/backend/tests/test_webhook_consumers.py` is the shape: drive the real view with a signed `RequestFactory` request and assert the enqueue, plus the event type the app does not register, the bad signature, the unparseable body, the non-POST, and the missing secret.
@@ -57,13 +58,16 @@ Copy `github/` for the full shape, or `vapi/` for a small one.
 `provider.py` holds three things:
 
 - `SPECS`, one `ProviderSpec` per app, naming the event types that app is subscribed to. The registry validates consumers against these.
-- A `WebhookProvider` subclass with `scheme()` (from `posthog/ingress/verify/`), `deliveries()` (how to read the event type, delivery id and context off the verified request), and any status codes the provider's protocol fixes. Defaults are 403 on a bad signature, 500 when unconfigured, 202 on success.
+- A `WebhookProvider` subclass with `scheme()` (from `posthog/ingress/verify/`), `deliveries(request, payload, facts)` (how to read the event type, delivery id and context off the verified request), and any status codes the provider's protocol fixes. Defaults are 403 on a bad signature, 500 when unconfigured, 202 on success.
+  - `verify(request)` answers a `Verification`: the outcome, plus `facts`, whatever the scheme proved on the way. A scheme that validates a signed token puts its verified claims there and `deliveries` cross-checks the body against them; an HMAC scheme leaves it empty and `deliveries` ignores it.
+  - `parse(request)` decodes the body, and defaults to JSON. Override it for a provider that posts a form, and raise `InvalidPayload` for a body it cannot read. Verification runs first and must, because reading `request.POST` consumes the request stream under ASGI.
+  - `throttle_class` names a DRF throttle from `posthog.rate_limit`, run in front of verification. Set one when the endpoint is public and its verification is expensive, such as a JWT signing-key lookup.
 - A `build_<provider>_provider(...)` function returning it. Secrets and verifiers a product owns are **passed into this builder**, never imported: nothing under `posthog/ingress/` may import a product.
 
 Then:
 
 1. Add the module path to `_INCARNATION_MODULES` in `posthog/ingress/providers.py`, or the registry never sees its specs or core consumers.
-2. Wire the URL with `build_webhook_view()`, for example `opt_slash_path("webhooks/<provider>", build_webhook_view(build_<provider>_provider()))`. GitHub and SES sit in `posthog/urls.py`; the others are declared by the owning product.
+2. Wire the URL with `build_webhook_view()` where the App registration lives. The owner of the third-party App owns the route: a product that registered the App declares `urlpatterns` in its own `products/<product>/backend/routes.py`, for example `opt_slash_path("webhooks/<product>/<provider>", build_webhook_view(build_<provider>_provider()))`. The path must start with `webhooks/<product>/` or `api/<product>/`, or the URL conf fails to load. Only an App several products consume stays in `posthog/urls.py`, which today is the customer-facing GitHub App alone. See [docs/internal/url-routing.md](../../../docs/internal/url-routing.md).
 3. Write `posthog/ingress/<provider>/README.md` with the fixed sections, in this order: headers, signature scheme, delivery id and event type, apps and secrets, quirks, consumers. `posthog/ingress/test/test_provider_readme_sections.py` fails on a provider folder without one, and on a README with different or reordered headings.
 4. Add the provider's signature header name to the `$HEADER` regex in `.semgrep/rules/devex/inbound-webhooks-go-through-ingress.yaml`, plus a fixture case in the `.py` beside it. The header names are spelled out rather than matched generically because a generic header pattern makes semgrep time out on a large module, which drops that file from the scan without failing it.
 5. Delete the migrated endpoint's line from `paths.exclude` in the same rule. That list is a ratchet of verifiers that predate ingress, and the migrating PR removes its own entry.

.agents/skills/adding-personhog-rpc/SKILL.md

@@ -130,14 +130,12 @@ The compiler guides you — once the proto is defined, `cargo build` errors tell
 
 ### 3c. Router wiring (personhog-router)
 
-1. **Add the method** to `rust/personhog-router/src/router/mod.rs`
-   - Use the `route_request` function (imported from `routing.rs`) with the correct `DataCategory` and `OperationType`
-   - Call the replica (or leader) backend
-   - Use the `call_backend!` macro for instrumentation
-2. **Add the service impl** to `rust/personhog-router/src/service/mod.rs`
-   - Invoke the `route_request!` macro (defined at the top of this file) to delegate to the router
-3. **Add to the backend trait** in `rust/personhog-router/src/backend/mod.rs` and implement in `replica.rs`
-4. **Add router tests** in `rust/personhog-router/tests/`
+The router forwards request bytes without decoding them, so a new RPC needs no handler there.
+
+1. **Add the method name** to `KNOWN_METHODS` in `rust/personhog-router/src/proxy.rs`, keeping the list sorted
+   - Methods that must reach the leader are matched by name in `proxy.rs`; everything else forwards to a replica
+   - `known_methods_is_sorted` and `known_methods_matches_service_proto` in the same file fail until the list matches `service.proto`
+2. **Add the method** to every `PersonHogService` mock that implements the generated trait, including the ones outside personhog (`rust/personhog-router/tests/common/mod.rs`, `rust/property-defs-rs/tests/`); tonic traits have no default methods
 
 Use `rstest` parameterized tests where multiple variations of the same behavior are being tested.
 

.agents/skills/establishing-code-ownership/SKILL.md

@@ -30,6 +30,7 @@ For a path, it walks from the repo root down to the path collecting ownership fi
 1. **`owners.yaml` — the canonical, distributed source.** Each directory can carry one. Fields (`owners`, `status`, `inherit`, per-path `rules`) fall through to the nearest ancestor unless overridden. `inherit: false` cuts the walk (Gerrit's `set noparent`) — nothing above it contributes. Within a file, `rules:` are last-match-wins. `owners: null` means **unowned by design** (exempt from the coverage check), distinct from a directory with no file at all (genuinely unowned).
 2. **`products/<name>/product.yaml` — an accepted alias.** When a product dir has no `owners.yaml`, its `product.yaml` `owners:` list is read as the ownership for `products/<name>/**` (every other `product.yaml` field is ignored). A dir with both files is a lint error; `owners.yaml` wins.
 3. **`.github/CODEOWNERS` — blocking approvals, never part of the walk.** It keeps GitHub-native semantics, stays hand-maintained (mostly infra, e.g. `team-security`), and is enforced by GitHub itself. The resolver does **not** read it — when you need to know whether a blocking approval is additionally required, consult the file directly. It never changes the resolved `owners`, and nothing here writes to it.
+   A tool that can only read CODEOWNERS gets a generated projection of the map instead, from `hogli owners:codeowners` (see [tools/owners/README.md](../../../tools/owners/README.md)); that projection covers test files and is never `.github/CODEOWNERS`.
 
 Owners are a mixed list of **team slugs** (`team-devex`, `conversations`, `logs` — the GitHub team handle minus `@PostHog/`) and **`@handles`** for individuals; the first entry is the primary owner.
 

.agents/skills/fixing-flaky-tests/SKILL.md

@@ -83,6 +83,14 @@ The `trunk` MCP server in `.mcp.json` queries it (tools are marked experimental
 
 Authenticate once via `/mcp` → `trunk` (browser OAuth); headless environments instead add an `Authorization: Bearer` header with a `TRUNK_API_TOKEN` org token to the server entry.
 
+Two limits worth knowing before you start here.
+AI investigations are not enabled for this repo, so `fix-flaky-test` returns history or nothing, never a root cause.
+And lookup only goes name to ID: a bare dashboard link identifies a test you cannot name, so ask for the test name rather than guessing at the ID.
+
+Trunk attributes each test to a team through CODEOWNERS, which cannot express the `owners.yaml` map.
+`.github/scripts/trunk-codeowners.sh` projects the map into a generated CODEOWNERS before each upload (`hogli owners:codeowners` builds the same file locally), so a test's owner in Trunk should match `hogli owners:who`.
+Where it does not, the projection dropped a spelling two teams would both claim.
+
 Like `ci:insights`, this is corroboration and history, not the classification authority — flaky-vs-deterministic and the rate still come from the run data above.
 
 ## 2. Extract the failure from CI