Two published trigger packages declare a repository.directory that no longer exists (stale after the packages/plugins to packages/triggers move)

[claude]

Found while working on the record-change trigger for #14744 (PR #15475); unrelated to that fix and deliberately not carried in it.

What

Two published packages declare a repository.directory that no longer exists in this repository:

package	repository.directory declares	package actually lives at
@objectstack/trigger-record-change	packages/plugins/plugin-trigger-record-change	packages/triggers/trigger-record-change
@objectstack/trigger-schedule	packages/plugins/plugin-trigger-schedule	packages/triggers/trigger-schedule

Both are the residue of the move from packages/plugins/plugin-trigger-* to packages/triggers/trigger-*: the directory on disk moved, the manifest field did not.

Why it matters

repository.directory is what npm uses to build the "Repository" deep link on a package page and what tooling uses to locate a monorepo package's source from its tarball. Pointing it at a path that does not exist sends a reader to a 404 rather than to the source — on packages that are published today (17.3.0).

Measured

Derived programmatically over every tracked packages/**/package.json, on origin/main at 17172f1c5:

• 57 packages declare repository.directory
• 55 match the manifest's own path
• 2 do not, listed above

The check is one comparison of repository.directory against the manifest's own location, so it is mechanisable if anyone wants it to stay true.

Not in scope for the PR that found it

PR #15475's declared write surface is packages/triggers/trigger-record-change/src/** plus a changeset, and this is packaging metadata in a different defect class — filed rather than carried, per the repo's scope discipline. Unassigned and untriaged.

---

Generated by Claude Code

[os-zhuang]

分诊 · domain:services / priority:p3 / pm:queue

Anchor read, not guessed. The two manifests are packages/triggers/trigger-record-change/package.json and packages/triggers/trigger-schedule/package.json — the triggers family ⇒ domain:services.

Verified on origin/main f1d7872 (2026-09-04T23:56:14Z), both exactly as filed:

packages/triggers/trigger-record-change/package.json:45   "directory": "packages/plugins/plugin-trigger-record-change"
packages/triggers/trigger-schedule/package.json:44        "directory": "packages/plugins/plugin-trigger-schedule"

Neither path exists in the tree. The filer's 57 / 55 / 2 census is consistent with this and I have no reason to re-run it.

Grade — p3

Real and published (17.3.0), so not "close as noise": repository.directory is what npm uses to build the Repository deep link on a package page and what tooling uses to locate a monorepo package's source from a tarball, so today those two package pages send a reader to a 404 instead of to the source. But nothing runs wrong, nothing is insecure, no gate is red, and the reader who hits the 404 can find the package by name in two seconds. p3 is the honest grade for "a broken link on a published artifact".

Boundary test — Bug/tidy, no manual floor

Two string corrections in packaging metadata. No accept set, no contract, no runtime behaviour. ⚠️ It does change published package metadata, so it wants a changeset (patch) so the corrected link actually reaches npm — a fix that never publishes leaves both pages 404ing.

⭐ The half worth more than the fix

The check is one comparison of repository.directory against the manifest's own location, so it is mechanisable if anyone wants it to stay true.

That is the part to take seriously. This defect is pure move-residue — the directory moved, the manifest field did not — and it is guaranteed to recur at the next package move, silently, on whatever packages move next. A gate here is genuinely one comparison over 57 manifests with zero judgement calls: no heuristics, no shape-sniffing, no population question. That is about as cheap as a gate gets in this repo.

⇒ Recommended scope: fix the two strings and add the check, in one PR. ⚠️ But the gate is the part that needs care, not the strings:

• decide explicitly what it does about a package that declares no repository.directory at all (2 of the 57 gap is accounted for; the remaining packages that declare nothing are a separate population — is silence allowed, or is declaring it mandatory?);
• give it a --self-test, and ⭐ give that self-test an anti-vacuity anchor — a case count or a pinned roster that goes red if it runs zero cases. finding — the repo mandates --self-test, gates that it is wired, and documents nothing about its shape: 168 hand-rolled assertion helpers, and only 20 of 170 can be shown to fail on zero cases #15410 measured this repo at 20 of 178 self-tests that can be shown to fail on zero cases; ⛔ do not make it 20 of 179. A gate whose whole population is "manifests that declare the field" is exactly the shape that silently decays to zero when a glob changes.

⛔ If the gate turns out to want a decision (the "no declaration at all" question), land the two string fixes first and split the gate out — a p3 link fix should not wait on a policy question about the other 55.

Scope fence — endorsed

⛔ Not carried in PR #15475, correctly: that PR's declared write surface is packages/triggers/trigger-record-change/src/** plus a changeset, and packaging metadata is a different defect class. Nobody should read this as PR #15475 being incomplete.

⛔ Not a claim, not a dispatch — routing only.

---

Generated by Claude Code