perf(ci): give non-isolated product declarations a per-product lane

[gantoine]

Note

Stacked on #76481. Review that one first; this PR's diff is against it, not master.

Problem

products/<p>/package.json and products/<p>/turbo.json claim all 87 backend lanes for the 63 non-isolated products. A non-isolated product widens on any file the frontend rules don't claim, and neither of those is .tsx.

The 15 isolated products already get the narrow treatment for the same two files — their own lane plus the tach dependent cascade:

products/error_tracking/package.json  ->  8 lanes   (isolated)
products/endpoints/package.json       ->  3 lanes   (isolated)
products/actions/package.json         -> 89 lanes   (non-isolated)
products/desktop/package.json         -> 89 lanes   (non-isolated)

Nothing about the file justifies the difference. Isolation governs whether a product's backend code can be tested alone; these two files aren't backend code.

Changes

A non-isolated product's CONTRACT_DECLARATIONS (turbo.json, package.json) now claim py:product:<p> and seed the dependent cascade, instead of allPyProducts(). Everything else in a non-isolated product widens exactly as before.

Renamed changedIsolatedProducts to cascadeSeeds, since the set is no longer isolated-only.

Why these two files and nothing else. I checked what they actually contain before narrowing them. 69 of 78 products keep their backend test command right there:

"scripts": {
    "backend:test": "pytest -c ../../pytest.ini --rootdir ../.. backend/ -v --tb=short"
}

So they are not bare JS manifests, and this PR deliberately does not treat them as frontend-only — they keep a backend claim. What changes is the blast radius: the product's own lane plus every importer the tach cascade names, rather than every product in the repo. The cascade is the same mechanism the isolated products rely on, and tach check runs in CI so the graph can't drift.

Warning

This extends to non-isolated products a trust we previously reserved for isolated ones, for these two files. If the tach graph is unavailable the code still falls back to allPyProducts(), and there's a test for that, but the policy call is worth a reviewer's opinion rather than mine.

How did you test this code?

node --test .github/scripts/trunk-impacted-targets.test.js — 46 pass, 4 new.

The new cases cover the narrowing, the cascade seeding, that non-declaration files in the same product still widen, and that an unavailable tach graph widens a declaration change. I also updated one case from #76481 whose expectation this supersedes: it asserted the product root still reached py:core, and now asserts it still claims a backend lane (py:product:gamma) — the property it was actually guarding, which is that the workspace narrowing doesn't swallow the product root.

Whole-tree differential against #76481's head, all 20,555 tracked files under products/:

unchanged : 20488
NARROWED  :    67   (only basenames: package.json, turbo.json)
WIDENED   :     0

Every narrowed file is a product-root declaration, 89 lanes down to 2-13. Spot checks: products/desktop/package.json → ['fe:product:desktop', 'py:product:desktop']; products/actions/package.json → 13 lanes including its 11 tach dependents; products/actions/backend/api.py still → 88 lanes.

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

Docs update

Not applicable. The rationale lives in the script's own header comments.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Follow-up to #76481. I asked Claude (Claude Code) whether the same idea extended to every package.json in the repo outside the root; the answer was no, and finding out why is what produced this narrower change.

Two rejected approaches worth recording:

• Treating a nested package.json as a JS manifest and dropping its backend claim. Rejected on the backend:test evidence above. Repo-wide the case doesn't exist anyway: of 137 package.json files, 52 already claim no Python lane, 16 are the isolated products, and the only non-product ones that widen are common/hogql_parser, common/hogvm/typescript, and common/plugin_transpiler, which are genuinely Python-coupled.
• "No backend:* script means no Python effect." Only 9 products qualify, and the rule inverts on deletion: removing backend:test would classify as frontend-only precisely when the change is most backend-relevant.

/writing-tests invoked before adding the test cases.

[greptile-apps]

_{Reviews (1): Last reviewed commit: "perf(ci): give non-isolated product decl..." | Re-trigger Greptile}

[Copilot]

Pull request overview

Adjusts Trunk lane computation for non-isolated products so that changes to product-level contract declarations (products/<p>/package.json, products/<p>/turbo.json) no longer claim all backend lanes, but instead claim the product’s own backend lane and seed the existing tach-dependent cascade (matching the mechanism already used for isolated products’ contract surfaces).

Changes:

• Introduce isContractDeclaration() and use it to special-case non-isolated product declaration changes to claim py:product:<p> (instead of widening to all backend lanes).
• Rename changedIsolatedProducts → cascadeSeeds and expand seeding logic to include non-isolated declaration changes.
• Add/update unit tests covering narrowing behavior, cascade seeding, and tach-graph-unavailable fallback widening.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
.github/scripts/trunk-impacted-targets.js	Adds per-product backend lane claiming for non-isolated package.json/turbo.json and seeds dependent cascade accordingly.
.github/scripts/trunk-impacted-targets.test.js	Adds coverage for the new narrowing + cascade behavior and updates an expectation for product-root handling.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[trunk-io]

😎 Stack merged successfully - details.

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-08-03 16:39 UTC	Run
prod-us	✅ Deployed	2026-08-03 16:54 UTC	Run
prod-eu	✅ Deployed	2026-08-03 16:57 UTC	Run