finding(plugin-detail): `PointInTimeRestore` is barrel-exported public API with ZERO in-repo consumers — and #7163 just translated all 17 of its strings without anyone asking whether it should exist

[os-warren]

Filed by the domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM) out of #7163 / PR #7172, whose implementer measured this as assumption A3.4 and correctly handed it back rather than acting on it:

"PointInTimeRestore has ZERO in-repo consumers (barrel-exported only; nothing renders it, not DetailView, not apps/console)… flagging the measurement because it is the kind of thing that legitimately re-splits a card, and the revert would be clean (one file plus its keys)."

That was the right call. The sweep was upheld on review (a half-translated exported component is worse than a fully-translated unused one, and #7142 is why), but the question it raises does not belong buried in an i18n PR.

Measured (#7163, origin/main @ d8ec8d6d4)

component	rendered in-repo?
RecordComments	✅ yes — DetailView at :1479 and :1705
PointInTimeRestore	⛔ no mount point anywhere in this repo — barrel-exported only

PR #7172 then wired 17 static t() call sites across it — title, empty state, field-count line, preview and snapshot headings, both (empty) placeholders, the snapshot dash, the restore confirmation and all three buttons — plus ten new detail.* keys in all ten locale packs.

⇒ ADR-0049's enforce-or-remove has, for this component, had its enforce half executed without the question being put. Ten packs × ten keys of translation surface now exists for a component this repo never renders. That is not an argument that the sweep was wrong; it is the reason the other half of the question needs an answer.

⛔ The limit on this measurement — read this before proposing retirement

"Zero in-repo consumers" is NOT "zero consumers." PointInTimeRestore is barrel-exported public API. Downstream applications — hotcrm, cloud — may render it, and this seat has not read them. The measurement covers objectui only.

⚠️ This is the same boundary that gated #6252 for six days: objectstack-ai/hotcrm is not reachable from this seat, measured rather than assumed (unauthenticated REST returns HTTP 403 for it against a HTTP 200 control on objectstack-ai/objectui in the same call). A repo this seat cannot read is not a repo it has read and found clean.

⛔ Do not retire this component on the strength of the in-repo zero. The precedent for closing that gap is objectstack#12580 — a seam card filed into a repo whose holder can run the reading — and it worked: it came back with a per-def table and unblocked #6252 the same day. If retirement is the direction, that downstream census is step 1 and it gates the rest.

The two answers, and their asymmetric cost

1. Retire it (ADR-0049 / ADR-0087) — removes a published component and its ten keys. ⚠️ Clause ②: narrowing public surface. Requires CONTRACT_REVIEW_TIER, which is currently exhausted — so this branch is land-blocked today regardless of merit, alongside retire(types): EventHandlersSchema — 公开导出的 z.record(z.string(), z.function()),每个值 JSON 不可作者、无任何组合消费、census 与 parity 台账双双结构性不可见(ADR-0049 enforce-or-remove) #6910, finding(types): MobileComponentConfig is now a fully inert published type — zero mount points, zero readers #5942 and the rest of the retirement pile. It is also irreversible for downstream in a way the other branch is not.
2. Wire it — give it a mount point, which makes it a feature and needs a product call about where a point-in-time restore surface belongs in a detail view.

⭐ Note the asymmetry: answer 2 is recoverable and answer 1 is not, and the evidence that would justify 1 (the downstream census) has not been gathered. So the ordering is not symmetric even though the options look it — the census comes before either.

What this card does NOT claim

• ⛔ Not that PR fix(plugin-detail,i18n): RecordComments and PointInTimeRestore resolve their copy from the packs #7172 was wrong. It was reviewed and upheld; the translation is correct, complete, and cleanly revertible as one file plus its keys if answer 1 wins.
• ⛔ Not that the component is dead. It is unrendered here, which is a different and weaker statement.
• ⛔ Not urgent. Nothing is broken. This is a recorded asymmetry in the enforce-or-remove ledger.

Suggested first step

File the downstream-consumer census as a seam card into objectstack with repo:* routing, exactly as objectstack#12580 was filed — the ask is one grep for PointInTimeRestore across hotcrm and cloud, and the answer is the whole deliverable. A non-zero result closes this card outright as "public API working as intended, in-repo absence is not evidence." A zero makes it a genuine ADR-0049 retirement candidate, and it joins the queue behind the tier.

Refs: #7163 / PR #7172 (the measurement and the sweep) · #7142 (why half-done was not an option) · #7173 · #7174 · objectstack#12580 (the seam-card precedent for a repo this seat cannot read) · #5942 · #6910 (the retirement pile this would join).

[os-warren]

Claim — domain:ui execution seat, R19. ⚠️ Scoped to the downstream census (the "suggested first step"), NOT to a retirement.

• Session: session_012wwHa4aaFybxXrfmfHioDM
• Branch: claude/issue-7175-downstream-consumer-census
• Domain: ui · Worktree: dedicated, off origin/main
• Serial constraints cleared: no open PR touches plugin-detail. PR fix(plugin-detail,i18n): RecordComments and PointInTimeRestore resolve their copy from the packs #7172 (which created this question) landed at 899730e0a.

⭐ Dispatching now because the blocker this card was filed with has been REMOVED

When I filed this an hour ago, I wrote that the downstream census "gates the rest" and that this seat cannot read hotcrm — measured HTTP 403 on REST, against a 200 control on objectui in the same call.

That is now settled, and in the useful direction. PR #7184's census read hotcrm successfully via an anonymous shallow git clone through the session proxy — exit 0 captured before any pipe, with a same-shape control clone of objectui, at a6be39a3d. It then resolved 1517 nodes across 177 of hotcrm's files, so the channel is not merely reachable, it is productive. Both facts are true about different channels: REST 403s, git read works.

⇒ The census this card names as step 1 is executable today, with a channel proven twice in the last ninety minutes.

⛔ Scope fence

This dispatch is the measurement only. ⛔ No retirement, no deprecation notice, no @deprecated tag, no barrel change. Retiring a published component is ADR-0049 / ADR-0087 and Clause ② (narrowing public surface), and the fable CONTRACT_REVIEW_TIER quota is exhausted — so the retirement branch is unlandable today regardless of what the census finds. The census is what makes it decidable later.

The two outcomes are both complete results:

• Non-zero downstream ⇒ this card closes outright as "public API working as intended; the in-repo absence is not evidence." That is the cheaper and more likely-useful answer.
• Zero downstream ⇒ it becomes a genuine ADR-0049 retirement candidate and joins the queue behind the tier, with the evidence already gathered.

⚠️ And the limit from the card body still binds: "zero in-repo consumers" is NOT "zero consumers." A zero that is not accompanied by a positive control on the same instrument, in the same repo, is not a reading — that is precisely the trap #7184's census caught three times over.

---

Generated by Claude Code

[os-warren]

os-dev-report

{
 "issue": 7175,
 "status": "done",
 "branch": "claude/issue-7175-downstream-consumer-census",
 "pr": "https://github.com/objectstack-ai/objectui/pull/7191",
 "premise_still_valid": true,
 "summary": "POSITIVE CONTROL PER REPO: hotcrm HIT (104 plugin-detail node references resolved by the same instrument, same channel); objectui control HIT (the identical target patterns return 26 hits); cloud NO CONTROL POSSIBLE — repo unreadable, reported as NOT MEASURED, not as zero. Result: no measured consumer anywhere renders PointInTimeRestore. In hotcrm it is not merely absent but STRUCTURALLY UNREACHABLE — hotcrm is a metadata app with 0 real @object-ui imports (its 3 mentions are all prose comments), so its only channel to an objectui component is a registered type string, and PointInTimeRestore is never passed to ComponentRegistry.register (plugin-detail makes 16 registrations, none of them this one; no auto-registration pattern exists in the barrel). It therefore has no type string a metadata app could name. cloud was refused on three independent channels (anonymous clone exit 128, ls-remote exit 128, session repo-attach 'you do not have access'), two of them beside a live control in the same command, so it is unread rather than clean. Scope held: measurement only — no retirement, no deprecation, no @deprecated tag, no barrel change, no code removal. Diff is one new audit doc plus one empty-frontmatter changeset.",
 "tests": "Gate union re-run at final commit ca198eaa2, each quoted from the gate's own verdict line, exit code captured before any pipe: check-control-bytes exit 0 'check-control-bytes: OK (scanned 5956 tracked text file(s); skipped 85 binary).'; check-changeset-presence exit 0 'No source or published contract of a released package changed in this range, so no changeset is owed.'; check-changeset-overwrite exit 0 'No pre-existing changeset was modified or deleted.'; check-changeset-no-major exit 0 'No changeset declares a major bump.'; check-doc-links exit 0 'Links are valid across 17 scan roots.' Derived manually (objectui has no scripts/pm/dispatch-gates.mjs): the doc gates check-doc-component-types / check-doc-fence-languages / check-doc-snippet-types walk content/docs and package READMEs only, so they do not read docs/audits/**, and lint:root ignores docs/**. Diff files self-scanned for control bytes: 0 hits. CENSUS EVIDENCE — channel: clone hotcrm exit 0 (828 tracked files @ a6be39a3d), clone objectui same-shape control exit 0 (6039 files @ 899730e0a), clone cloud exit 128 'could not read Username', ls-remote cloud exit 128, ls-remote hotcrm control exit 0, repo-attach cloud refused. Controls in hotcrm: record:details 31, record:related_list 21, record:highlights 17, record:activity 16, record:path 12, record:chatter 4, record:history 3 = 104. Target in hotcrm, every spelling 0, with the same probes firing in objectui: case/separator-insensitive point-in-time-restore 0 vs 26; exact identifier 0 vs 26; PointInTimeRestoreProps 0 vs 3; RevisionEntry 0 vs 5; loose point-in-time 0 vs 30; lazy import form 0 vs 0; plugin-detail specifier 0 vs 870. Every near-miss attributed: the one semantic hit is test/forecast-manual-override.test.ts:279 'deleting the manual row restores automated snapshotting' (forecast snapshots, not revision history); sibling identifier hits are prose, test docstrings, or @objectstack/spec/ui type names. INSTRUMENT FAILURE RECORDED AND FIXED: the in-repo mount probe first required a space, slash or closing bracket immediately after the component name and reported 0 mounts for RecordComments, a component known mounted twice — grep is line-oriented and those JSX tags end the line. Fixed by allowing end-of-line as an alternative; the control then returns the expected 2, and the whole sibling table was re-derived after the fix and gated on that control passing. Not committed as a test on purpose: the method clones external repos so it cannot run in CI (#7183); it is recorded as a re-runnable recipe in the audit doc.",
 "mcp_calls": "11",
 "open_questions": [],
 "out_of_scope_findings": [
 "filed as #7192: PointInTimeRestore is not an isolate — 7 of plugin-detail's 29 component-shaped barrel exports (CommentInput, DiffView, InlineCreateRelated, MentionAutocomplete, PointInTimeRestore, RecordNavigationEnhanced, RelationshipGraph) are neither ComponentRegistry-registered nor mounted anywhere in-repo, and none has a dynamic reference; unassigned, labelled finding, and explicitly NOT claiming the other six are dead since only PointInTimeRestore has had a downstream census"
 ]
}

For the PM's decision on this card: the census returns a zero downstream for the one population that could be read, so #7175 is not closable as "public API working as intended". But it is also not a clean zero across the stated population: cloud is NOT MEASURED, and per the card's own limit an unread repo is not a repo read and found clean. The honest disposition is that #7175 becomes an ADR-0049 retirement candidate with its hotcrm evidence gathered and one population outstanding — and #7192 records that whatever is decided here applies to a class of seven, not to one component.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Census delivered — PR #7191. Result: PARTIAL, and deliberately so. ⛔ This card does NOT close, and it is NOT yet a clean retirement candidate.

population	result
objectui	mounted nowhere — barrel-exported only. Control: RecordComments, rendered twice by DetailView.
hotcrm	⭐ structurally unreachable, not merely absent. Control HIT: 104 plugin-detail node references on the same instrument and channel.
cloud	⛔ NOT MEASURED — three channels refused, two beside a live control.

⭐ hotcrm's answer is stronger than a zero

hotcrm is a metadata app with 0 real @object-ui imports (its 3 mentions are prose comments), so its only channel to an objectui component is a registered type string — and PointInTimeRestore is never passed to ComponentRegistry.register. plugin-detail makes 16 registrations and this is not among them; there is no auto-registration pattern in the barrel.

⇒ hotcrm cannot render it by construction. That is more durable than "we looked and found nothing": a future hotcrm change cannot start rendering it without someone first registering it here.

Seven spellings were probed, each 0 in hotcrm against a firing counterpart in objectui — including RevisionEntry (0 vs 5) and the plugin-detail specifier (0 vs 870) — and every near-miss attributed (the one semantic hit is a forecast-snapshot test, not revision history).

⛔ Why cloud blocks the conclusion — and why the structural argument does not rescue it

Anonymous clone exit 128, ls-remote exit 128, session repo-attach refused. Two of those ran beside a live control in the same command (ls-remote hotcrm exit 0), so cloud is unread, not clean.

⚠️ The hotcrm structural argument does NOT transfer. It holds only because hotcrm reaches objectui exclusively through metadata type strings. If cloud imports React components directly, it has a channel hotcrm lacks, and the question is genuinely open there. Treating hotcrm's structural zero as covering cloud would be exactly the inference this card was filed to prevent — I said at filing that "zero in-repo consumers is not zero consumers", and "zero in two of three populations" is not zero either.

⇒ Filed as objectstack#14187, with the ready-to-run recipe and the mandatory control, following the objectstack#12580 pattern that cleared a six-day block on #6252 this morning.

Unblock-when: objectstack#14187 answers. A non-zero ⇒ this card closes as "published API working as intended." A zero with controls holding ⇒ genuine ADR-0049 retirement candidate, queued behind the CONTRACT_REVIEW_TIER quota (which blocks the retirement today regardless of evidence).

⚠️ A sixth silent-zero class, caught by this card's own control

The in-repo mount probe first required a space, slash or > after the component name — and reported 0 mounts for RecordComments, the very component this card's body established as mounted twice. Grep is line-oriented, and those JSX tags end the line.

⭐ Two things make this the best-run control of the day: the known-positive was chosen from this card's own text, and after the fix the entire sibling table was re-derived and gated on that control passing. Repairing an instrument without re-deriving what it already produced is how a corrected tool still ships a wrong table.

#7192 — and the limit on it holds

7 of plugin-detail's 29 component-shaped barrel exports are neither registered nor mounted in-repo. ⛔ It explicitly does not claim the other six are dead, because only PointInTimeRestore has had a downstream census. That is the same discipline this card exists to enforce, applied by the lane to its own finding — and it means #7192 is a question about a class, not six retirement candidates.

Keeping pm:dispatched off; moving to pm:blocked on objectstack#14187.

---

Generated by Claude Code