Merge branch 'master' into codex/fix-replay-vision-slack-workspace

Author: Indira-kumar

.agents/skills/debugging-mcp-analytics/references/event-vocabulary.md

@@ -92,7 +92,13 @@ Per-event additions: `$mcp_error_status` (upstream HTTP status), `$mcp_error_cod
 which keys the caller actually sent), and exec-mode calls carry `$mcp_exec_verb` (which dispatcher
 verb ran) and `$mcp_exec_target_tool` (the tool that `info`/`schema`/`call` named). Those four are
 stamped in `tool-executor.ts` but are **not registered in `posthog/taxonomy/taxonomy.py`**, so they
-have no descriptions in the property picker — they still query fine. `execute-sql` calls additionally emit a separate `$ai_generation` event
+have no descriptions in the property picker — they still query fine.
+A `learn` call also carries `exec_learn_kind` (`search`, `load`, `list` for `learn skills` and a bare `learn`, `describe`, `guide`),
+stamped before the availability check so a rejected skill command still records its form, plus
+the raw `exec_search_query` for `search` (and for a `load` that searches inside the skill with `-s`) and `exec_learn_target` (the qualified skill) for `load`.
+A successful call carries `mcp_result_empty: true` when the handler returned zero rows, and
+`mcp_discovery_hint` (`empty_state` or `related_capability`) when the response builder appended a
+hint footer (`services/mcp/src/lib/discovery-hints.ts`). `execute-sql` calls additionally emit a separate `$ai_generation` event
 carrying `$ai_trace_id`, `$ai_input`, `$ai_output_choices`, and `$ai_latency`.
 
 ## Exec-mode properties

.agents/skills/depot-ci/references/posthog-check-run-semantics.md

@@ -73,10 +73,24 @@ In the following cancelled runs, an unstarted job received a `cancelled` check w
 
 ## Finding one event's Depot run
 
-Check times and `pull_requests` did not pick out the Depot run in these cases, so the event goes into a check name. The Depot wait job's name ends with `(PR <number>, event <pull_request.updated_at>)`, and Depot renders expressions in job names into the check name. `.github/scripts/ci_backend_relay.py` builds the same name from the GitHub run's payload, reads that check, takes the Depot workflow id from its `details_url`, and reads the gate or migration check of that workflow only. Measured 2026-09-24 on PR 105886: Depot posted check `107656013423` named `… (PR 105886, event 2026-09-24T13:33:14Z)`, and GitHub relay job `107655803961` used `EVENT_AT: 2026-09-24T13:33:14Z` and relayed a successful gate.
+Check times and `pull_requests` did not pick out the Depot run in these cases, so the event goes into a check name. The Depot wait job's name ends with `(PR <number>, event <pull_request.updated_at>)`, and Depot renders expressions in job names into the check name. `.github/scripts/ci_backend_relay.py` builds the same name from the GitHub run's payload, reads that check, takes the Depot workflow id from its `details_url`, and reads the gate check of that workflow only. Measured 2026-09-24 on PR 105886: Depot posted check `107656013423` named `… (PR 105886, event 2026-09-24T13:33:14Z)`, and GitHub relay job `107655803961` used `EVENT_AT: 2026-09-24T13:33:14Z` and relayed a successful gate.
+
+### Racing events
+
+Two events of one commit that arrive within a second or two race the concurrency cancel on both engines, and neither engine reliably keeps the newer event. A stack push shows it: it force-pushes a pull request's head and its base about one second apart, and each push starts a pull request event. Measured 2026-09-25 on a stack push at 15:17Z:
+
+- PR 106429: GitHub Actions cancelled the run of the newer event (15:17:40Z) and kept the older one (15:17:39Z). Depot kept 15:17:40Z and cancelled Depot run `rtl932mrbc` with "Cancelled due to the workflow concurrency policy".
+- PR 106435: GitHub Actions kept the newer event (15:17:41Z). Depot kept the older one (15:17:40Z) and cancelled `nzb661zql2`.
+- Neither cancelled Depot run posted a wait check, so each surviving GitHub relay found no run for its event and failed after the grace period, although Depot's run for the other event passed on the same commit.
+
+GitHub Actions alone does the same. Among the 946 `ci-backend.yml` pull request runs created on 2026-09-25 between 11:30Z and 16:00Z, 56 same-commit pairs were created within 30 seconds of each other, 52 of them 0 to 2 seconds apart. GitHub kept the older run in 6 pairs, all 0 to 1 second apart. So after its grace period, the relay follows the Depot run of an event of the same pull request up to 2 seconds away (`RACING_EVENT_SECONDS`), newest first.
 
 The newest check per name tells you the verdict. It does not tell you whether the PR can merge. A cancelled run on the same head keeps its checks, and when one of them is a required check, GitHub's merge box and Trunk keep the PR blocked until that run is rerun. `/merging-prs` has the recipe.
 
+## pull_request_target checks
+
+Depot can post a `pull_request_target` job's check on another pull request's head commit. A `pull_request_target` run's `github.sha` is the base branch head, so pull requests opened against the same master commit share it, and every misplaced check measured sat on a commit whose own run shared that base commit. Measured 2026-09-25 on a migration report workflow that ran on `pull_request_target`: 35 of its 42 checks sat on the wrong commit. For example, check `108123656729` on PR 106758's head `0295b92b41` links Depot workflow `ljv421dmlt`, whose run `vpg4b1kvh7` tested PR 106767's head `fb236b6c26`, and both runs had base `7af9307723`. The jobs' own writes, a check posted with an explicit `head_sha` and a comment on an explicit PR number, reached the right pull request. Post pull-request-facing results from a `pull_request` workflow, whose checks land on the right head.
+
 ## Depot CI CLI recipes
 
 The CLI needs ids that the GitHub API does not carry. Start from a check run's `details_url`, which encodes the workflow id and job id.

.agents/skills/implementing-warehouse-sources/SKILL.md

@@ -643,9 +643,9 @@ Requirements and behavior:
 
 - **The parent must be a selectable schema of the same source** — it has to produce its own Delta table.
 - **Soft dependency — the child falls back to the parent API.** Declare the parents by overriding `get_required_parent_schemas` on the source (wire it to `required_parents_from_endpoint_configs(ENDPOINTS, schema_name)`; add explicit entries for custom-iterator endpoints). That override is the only declaration: nothing surfaces the relationship through the API, so don't add a schema-payload field for it while the feature is unvalidated.
-  Nothing in the API constrains the selection either: a child can be enabled without its parent, and a parent can be disabled or deleted while children sync. `_warehouse_parent_reuse_available` in `import_data_activity_sync` decides per run — a parent that is missing, disabled, not yet initially synced, or on any sync type other than merge or full refresh sends that run down the legacy parent-API path, so enabling the flag can never break a schema that syncs today. A parent that is merely mid-sync does not force the fallback, because `resolve_parent_table_ref` pins the read to the parent's last completed snapshot via Delta time travel.
+  Nothing in the API constrains the selection either: a child can be enabled without its parent, and a parent can be disabled or deleted while children sync. `_warehouse_parent_reuse_available` in `import_data_activity_sync` decides per run — a parent that is missing, disabled, not yet initially synced, or on any sync type other than merge or full refresh sends that run down the legacy parent-API path, so opting a child in can never break a schema that syncs today. A parent that is merely mid-sync does not force the fallback, because `resolve_parent_table_ref` pins the read to the parent's last completed snapshot via Delta time travel.
   Never enable a parent as a side effect of enabling a child: parent syncs count toward the customer's billed rows.
-- **Feature-flagged.** The whole path is gated by the `warehouse-fanout-parent-reuse` flag (`is_fanout_warehouse_reuse_enabled`); with the flag off, opted-in endpoints silently keep the legacy parent-API path, so rollback is a flag flip.
+- **Small parents stay on the API.** A parent under `MIN_WAREHOUSE_PARENT_ROWS` (1,000 rows) is not worth opening: the Delta read has a fixed cost of a few seconds, more than paging a small listing, and that cohort measured slower when converted. The gate reads the parent table's `row_count`, so it applies per run without configuration. There is no feature flag any more; rollback is a revert.
 - **Strictly streaming — never materialize the parent table.** The reader scans one projected batch at a time with column projection pushed down to the parquet read. Do not add `to_table`, global sorts, or seen-set dedupe to it — parents can be arbitrarily large, and the whole pipeline exists to avoid full-dataset memory. If a caller's semantics depend on parent order (the API returned sorted rows), rework them into per-row filters over the unordered stream (see Sentry's `issue_tag_values` cutoff handling) instead of sorting.
 - **The usable sync types are an allow-list, not a deny-list.** Only merge and full refresh hold one row per key; append accumulates a row per sync and CDC keeps change history, so streaming either would fan the child out once per duplicate, and dedupe would need unbounded state. A new sync type has to opt in deliberately in `_parent_unusable_reason`.
 - **Values carry Delta physical types, not the API's JSON types.** A timestamp comes back as a datetime rather than an ISO string, a nested object as a dict. Because the API fallback engages per run, projecting such a field through `include_from_parent` makes the child's column type flip between runs and trips the merge's type-drift guards. Only project fields whose physical type matches what the API returned (an id string is safe), or normalize in the caller.

.agents/skills/run-posthog/SKILL.md

@@ -112,7 +112,7 @@ The frontend uses kea-router. The mapping rule:
 | Edited path                              | Scene URL (under `/project/{team_id}/`)                 |
 | ---------------------------------------- | ------------------------------------------------------- |
 | `frontend/src/scenes/<name>/**`          | usually `/<name>` (e.g. `insights/` → `/insights`)      |
-| `frontend/src/scenes/activity/**`        | `/activity/explore` (and other `ActivityTab`s)          |
+| `frontend/src/scenes/activity/**`        | `/activity/events` (and other `ActivityTab`s)           |
 | `frontend/src/scenes/data-management/**` | `/data-management/<sub>`                                |
 | `frontend/src/scenes/settings/**`        | `/settings/<section>`                                   |
 | `frontend/src/scenes/authentication/**`  | `/login`, `/signup`, `/preflight` (un-scoped)           |

.agents/skills/stacking-prs/SKILL.md

@@ -82,6 +82,8 @@ gh stack sync --prune    # also delete local branches for merged PRs
 - `gh stack view --short` shows status (`--json` for scripting); a `⚠` means that layer needs a rebase, which blocks merging. `gh stack checkout <stack-number|PR|URL>` pulls down and tracks a stack you don't have locally, including a teammate's.
 - `gh stack modify` interactively reorders, folds, drops, or renames layers. `gh stack unstack` removes the stack on GitHub (`--local` to only drop local tracking).
 - Batch work before syncing. Each sync force-pushes and re-runs a full CI matrix for every rebased layer, so sync when you need the rebase, not to track master.
+- A push that moves a layer and its base in one go sends that layer two `synchronize` events, one per moved ref (the same behavior [git-spice#966](https://github.com/abhinav/git-spice/issues/966) reports). Every workflow then starts twice, and a workflow with a concurrency group cancels the older run, so a `cancelled` row next to a passing one is this duplicate, not a test failure. To avoid it, push the layers one at a time, bottom first, about a minute apart: each layer then gets the extra run on its old head, and its own push supersedes that run cleanly.
+- A cancelled duplicate still blocks the merge, because GitHub keeps its checks next to the newer green ones. Rerun it with the "Cancelled runs on the head" recipe in `/merging-prs` instead of pushing again. When `Django Tests Pass` fails because Depot cancelled its run for the event, its log lists the retry steps: retry the Depot run, then `gh run rerun <run id> --failed` relays the new result.
 - Layer branches move without you: ReviewHog and other bots push fix commits straight onto PR branches. `gh stack sync` fetches first and pushes with `--force-with-lease`, so it refuses when a branch moved; treat that refusal as "someone committed here, go read it", not "retry". Before any manual `git push` or rebase of a layer, `git fetch origin` and fast-forward onto the remote head. Never plain force-push a layer branch.
 - The `ci:preflight` pre-push hook runs on these pushes like any other; never bypass it.
 

.agents/skills/styling-sidebar-products/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: styling-sidebar-products
+description: >
+  How products and pages appear in the PostHog sidebar: which category they sit in, which icon and color they
+  get, and which groups share a color gradient. Use when adding a product or data management page to the
+  sidebar (treeItemsProducts or treeItemsMetadata in a products/*/manifest.tsx), giving an entry a new icon or
+  color, moving an entry between sidebar categories, adding a category, or when a sidebar icon renders the
+  wrong color, the wrong glyph, or differently once starred. Trigger terms: sidebar, nav, All products,
+  Popular, category, iconType, iconColor, product icon, product color, gradient, starred icon.
+---
+
+# Styling sidebar products
+
+The sidebar reads every entry from the product manifests.
+An entry needs three things to look right: a category, an icon type that only it uses in the sidebar, and a color.
+Some categories share a gradient, so a new entry in one of them changes its neighbors' colors too.
+
+## Where things live
+
+| What                                                                           | File                                                                                  |
+| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------- |
+| Entry definition (`path`, `category`, `iconType`, `iconColor`, `href`, `flag`) | `products/<product>/manifest.tsx`, under `treeItemsProducts` or `treeItemsMetadata`   |
+| Icon glyph and default color per icon type                                     | `iconTypes` in `frontend/src/layout/panel-layout/ProjectTree/defaultTree.tsx`         |
+| The icon type union                                                            | `FileSystemIconType` in `frontend/src/queries/schema/schema-general.ts`               |
+| Color values                                                                   | `--color-product-<name>-light` and `-dark` in `frontend/src/styles/base.scss`         |
+| Category names                                                                 | `ProductItemCategory` in `schema-general.ts`                                          |
+| Category order in the sidebar                                                  | `CATEGORY_ORDER` in `frontend/src/layout/panel-layout/navbar/tabs/productsCatalog.ts` |
+| Sidebar-only groupings (Popular, hidden tab pages, pinned rows)                | `navProductsTabLogic.ts` and `productsCatalog.ts` in the same folder                  |
+| Custom icons that are components, like the Support badge                       | `ProjectTree/customIconRegistry.tsx`                                                  |
+
+## Rules
+
+**One icon per entry.** No two sidebar entries share a glyph.
+If the icon type you want is also used outside the sidebar, for example `event_definition` or `data_pipeline_metadata`, add a new icon type instead of changing the shared one.
+A new icon type goes into the `FileSystemIconType` union and the `iconTypes` map, and then `hogli build:schema` regenerates the Python enums.
+
+**One color, set in both places.** Put the same color variable pair on the `iconTypes` entry and on the manifest entry's `iconColor`.
+The sidebar row uses the manifest color. Scene titles, search and other surfaces use the map color.
+When the two disagree, the product shows two colors across the app.
+Always give both a light and a dark variable, because a single value is reused for dark mode and reads poorly there.
+
+**Starred entries follow the product.** A star stores only `iconType || type` and `href`.
+The file tree looks up the product by `href` (`getProductIcon` in `defaultTree.tsx`) and uses its icon and color, and it wraps custom icons in `ProductIconWrapper`.
+Do not add a per-surface icon override. Fix the manifest and the map, and the star follows.
+
+**Pinned rows stay neutral.** Home, Self-driving and Activity and people have no color on purpose.
+
+## Color families
+
+Four categories use one gradient each. The steps follow the order the sidebar shows, which is alphabetical by label.
+
+| Category       | Gradient                      | Light end points                       |
+| -------------- | ----------------------------- | -------------------------------------- |
+| AI engineering | indigo to magenta             | `rgb(99 102 241)` to `rgb(196 60 218)` |
+| CDP            | golden yellow to burnt orange | `rgb(234 179 8)` to `rgb(194 65 12)`   |
+| Schema         | teal to deep blue             | `rgb(20 184 166)` to `rgb(29 78 216)`  |
+| Tools          | red to magenta pink           | `rgb(239 68 68)` to `rgb(217 40 160)`  |
+
+When you add, remove or rename an entry in one of these categories, regenerate the whole category, since every step moves:
+
+```sh
+python3 .agents/skills/styling-sidebar-products/scripts/sidebar_gradient.py schema \
+    actions annotations event-definitions mcp-servers sql-variables
+```
+
+Pass the color variable names in sidebar order, and include entries behind a feature flag.
+Paste the output over the matching lines in `base.scss`.
+If an entry shared a variable with a product outside the group, give it its own variable first. `warehouse-destinations` is an example: it used to share with Data ops.
+The end points, including dark mode, live in the script. Change them there, not by hand in `base.scss`.
+
+The other categories (Popular, Data, Monitoring, Product engineering, Messaging, Unreleased) use each product's own brand color.
+Pick a hue that differs from the entries right next to it in the same category.
+Avoid the gradient families above, so a product does not look like it belongs to AI engineering, CDP, Schema or Tools.
+
+## Categories
+
+Categories are values of `ProductItemCategory`, and the backend reads them through `products.json`.
+After renaming or adding one, update `CATEGORY_ORDER` in `productsCatalog.ts`, update the old nav's `CATEGORY_ORDER` in `ProjectTree/utils.tsx`, and update `test_get_products_by_category_has_expected_categories` in `posthog/test/test_products.py`.
+Then run `hogli build:schema` and `pnpm --filter=@posthog/frontend build:products`.
+
+Popular is sidebar-only. It lives in `POPULAR_PRODUCT_PATHS` and does not change a product's real category.
+Pages that are tabs of another page, like the definitions tabs, stay in their manifest but are hidden in `navProductsTabLogic.ts`.
+
+## Check it
+
+- `hogli test frontend/src/layout/panel-layout` runs the sidebar logic tests. It also checks that every starred product renders the same icon and color as its row, in `ProjectTree/utils.test.ts`.
+- Render the `Layout/Products and files` story in light and dark (`Dark` story), and look at the whole category, not only the new entry. A gradient reads wrong when one step is off.
+- Storybook does not hot-reload `base.scss`. Restart it after changing a color, or it keeps rendering the old values.
+- Neighboring steps need visible contrast. When steps look alike, widen the end points in hue and lightness rather than adding more steps.