fix(deps): the live-preview pin is load-bearing, and #222 widened it to a caret #223

Summary

@payloadcms/live-preview-react must be pinned exact, to SahajCloud's own payload version,
because it merges a live-preview message SahajCloud mints. That rule is written down in
sydevs/SahajAtlasWeb — docs/rules/data-layer.md:16-20 — and nowhere in this repo. So
#222 read the exact pin as unexplained and replaced it with ^3.92.1, which
is the one shape the rule forbids: a caret lets a fresh resolve carry the package ahead of the CMS.

That PR is marked ready for review, so this can merge. I introduced it — the PR's own reasoning
("exact-pinned with no stated reason") was wrong, and its sibling PR
sydevs/SahajAtlasWeb#361 had the same error caught by the adversarial review there, because that
repo carries the rule.

Approach

The package is in use, so the hazard is real, not theoretical:

• lib/live-preview/document.tsx:2 — import { useLivePreview } from '@payloadcms/live-preview-react'
• lib/live-preview/document.tsx:1 — CollectionPopulationRequestHandler from @payloadcms/live-preview

This repo's own Ed25519 token protocol (lib/live-preview/protocol, server/live-preview.ts) is a
separate layer and does not replace the merge. The merge is the part coupled to the producer.

Version state, read today:

Two pieces of work:

1. Restore the exact pin in package.json, at whichever version question 1 settles, and
   re-resolve the lockfile. @payloadcms/live-preview and @payloadcms/sdk move in the same bump,
   per the rule's last sentence — and the single-copy property WeMeditateWeb#222 won has to survive:
   live-preview-react@<v> depends on exactly live-preview@<v>, so both land on one version or
   the tree splits again.
2. Write the rule into this repo, so the next routine dependency run cannot make the same
   mistake. The natural home is a docs/rules/ file loaded on server/** and lib/**, or
   server/AGENTS.md, mirroring the paragraph in SahajAtlasWeb rather than paraphrasing it —
   docs/rules/code-comments.md already notes that nothing but prose enforces the couplings
   between these five repos.

Do not fix this by pushing to WeMeditateWeb#222 unless that PR is still open and unlocked when
this is picked up; it was marked ready by the dispatcher and may have merged.

Acceptance criteria

• package.json pins @payloadcms/live-preview-react exact, with no caret or tilde, at the version question 1 settles.
• pnpm-lock.yaml carries exactly one @payloadcms/live-preview entry, and it is the same version as live-preview-react.
• A rule in this repo states, in its own words, that this pin tracks SahajCloud's payload version and why a caret is wrong — reachable from a session editing package.json or lib/live-preview/**.
• The lean gate and pnpm build pass, and the live-preview specs in lib/live-preview/document.test.tsx and server/live-preview.test.ts pass.

Verification checklist

• node -e "const p=require('./package.json');const v=p.dependencies['@payloadcms/live-preview-react'];if(/[\^~]/.test(v))throw new Error(v)" exits 0.
• grep -c "'@payloadcms/live-preview@" pnpm-lock.yaml reports the same count as on a tree known to be single-copy, and the versions match live-preview-react's.
• .claude/skills/pr-prep/check.sh passes.
• pnpm build passes.
• ls .claude/rules/ or git ls-files '**/AGENTS.md' shows the new rule where a session editing package.json would load it.

Open questions

• 1. Which version does the pin track, given this repo is already ahead of SahajCloud?
  • A — Align to SahajCloud main, 3.90.2 (recommended): the rule says the pin is the producer's version, and this is the only value that makes that literally true. It is a downgrade of two minors from WeMeditateWeb#222's state and one from main, so the live-preview merge and the types:cms shape both want a check. Matches whatever chore(deps): routine minor and patch updates SahajAtlasWeb#361 settles on, which keeps the two consumers in step.
  • B — Hold at 3.91.0, this repo's pre-chore(deps): routine minor and patch updates #222 value: no downgrade from main, and the drift is pre-existing rather than introduced here. The cost is that the rule stays half-true and the next reader finds a pin that matches nothing.
  • C — Align both consumers and the producer at 3.92.1, by bumping SahajCloud first: the producer moves, then the consumers follow, which is the ordering format-ticket asks for anyway. Largest change, and it waits on SahajCloud's own Payload family bump — twelve exact pins plus the lexical trio.

Notes

The same error, in the same batch, on the sibling repo: sydevs/SahajAtlasWeb#361, where the review
caught it. Whichever version question 1 picks should be the same one that PR lands on.

Blocked by: nothing — but read sydevs/SahajCloud#1064 before picking a version, since it holds
SahajCloud's Payload family at 3.90.2 and says why.

🤖 Written by the sydevs autonomous loop — see what this is