[eli-r-ph]

Problem

The Library checks job can build the Next.js examples against the wrong SDK code. It restores .next/cache from any Linux-nextjs- entry, often one saved on another branch, and webpack reuses a node_modules package whose name@version is unchanged. A PR that changes @posthog/core or posthog-node without a version bump therefore builds against another branch's cached code: a false green, or a false red like 'V7Generator' is not exported from '@posthog/core' on #5508.

Changes

• Remove the "Restore Next.js build cache" and "Initialize Next.js build cache directories" steps, so both examples build from the packed tarballs every time. The cost is a few seconds per example build.
• CI only; no package changes.

Release info Sub-libraries affected

Libraries affected

• None (CI only).

Checklist

• All commits are signed (see Commit signing)
• Tests for new code (CI only)
• Accounted for backwards compatibility of any changes (no breaking changes!)

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

• Written with Claude Code (claude-opus-5-5). On chore: sync main into capture-v1 (posthog-node 5.58.0-5.61.1) #5508, a clean local build with no cache (pack, install from tarballs, next build) compiled, while CI failed after restoring a cache saved on main.

🤖 Generated with Claude Code

[github-actions]

📝 No Changeset Found

This PR doesn't include a changeset. A changeset is required to release a new version.

How to add a changeset

Run this command and follow the prompts:

pnpm changeset

Remember: Never use major version bumps for posthog-js as it's autoloaded by clients.

[github-actions]

Coherence

📄 0 spec file errors · ⛔ 0 broken rules · 🚪 2 unchecked inputs · 🐛 0 bugs that came back

What is Coherence?

Coherence compares the code with its spec files (*.spec.md). A spec file lists the rules for one part of the code.

This check read 44 parts of the code and 7 rules.

Note

These findings do not make this check fail.

None of these findings are in files that this pull request changes. You do not need to fix them in this pull request.

🚪 Unchecked inputs (2)

• public api in packages/web/Web.spec.md. The input comes from: host-app.
• webpack plugin in packages/webpack-plugin/Webpack-plugin.spec.md. The input comes from: build.

What this means and how to fix it

Input from outside this code comes in at these places. The spec does not say what checks that input. 10 more places were already like this when Coherence was added. This list does not show them.

To close one of these, find the place by its name in the ## entrances section of its spec file. Add one line under it:

• If all of the input goes through one function that a rule in the spec protects, add guard: <function>.
• If a rule in the spec already checks input from the same source, add the place's name to the entrances: line of that rule.
• If the input needs no check, add control: none - <reason>.

To get the line to add, run npx --no -- coherence scaffold control "<name>".