[finding] The other four "v3.0.0 Deep Integration modules" in data-objectstack have no consumer outside their own tests either

Found while executing the #4152 ruling (PR #4239). Filed unassigned, recording only — PD #10.

Fact

CloudOperations was one of five things added to @object-ui/data-objectstack under the // v3.0.0 Deep Integration modules banner in src/index.ts. #4152 measured that one and retired it. While measuring its consumers I swept the siblings on the same criterion, and they land in the same place:

exported symbol	module	references outside `packages/data-objectstack`
`IntegrationManager`	`src/integration.ts`	0
`SecurityManager`	`src/security.ts`	0
`createDefaultCanvasConfig` / `snapToGrid` / `calculateAutoLayout`	`src/studio.ts`	0
`validatePluginContract` / `generateContractManifest`	`src/contracts.ts`	0

Measured over packages/, apps/ and examples/ (.ts / .tsx, excluding node_modules). Every reference to each of these names lives inside data-objectstack itself — the index.ts re-export and src/v3-compat.test.ts. No app, no other package, no example wires any of them.

Why this is graded observation-class, and why it is NOT a repeat of #4152

The important difference, and the reason I am not proposing it follow #4152 out the door: these are not phantom. Each one does what it says locally, with no absent backend behind it — SecurityManager.generateCSPHeader() really composes a CSP header, snapToGrid really snaps, validatePluginContract really validates. There is no client.something?. optional chain into a namespace that does not exist, and nothing fabricates a success. #4152's sharp edge — a well-formed deploymentId handed back for work that never happened — has no analogue here.

So what is left is only the startup-focus question, which is a triage call and not a defect report: published surface of a released package, carrying no measured business pull. Nobody is bitten today, and no user-visible behaviour is wrong.

Adjacent, same theme

src/v3-compat.test.ts is titled v3.0.0 compatibility tests for @objectstack dependencies and its top-level describe is v3.0.0 Compatibility, against a resolved @objectstack family of 17.0.0-rc.6. This is the same stale-version-claim smell #4152 recorded for cloud.ts's module header, minus the false capability claim — the tests do exercise real local code, they are just not testing compatibility with a v3 of anything. PR #4239 removed that file's cloud block but deliberately left the header alone as out of scope.

Possible directions (left for triage)

Leave as-is. Nothing is wrong, and a self-contained helper costs little to keep.
Retire whichever of the four have no roadmap pull, on the same startup-focus reasoning as [finding] CloudOperations is a phantom surface: the installed @objectstack/client has no cloud namespace, so deploy() fabricates a deploymentId for work that never happened #4152 — but on the "no consumer" limb only, without the "fabricates success" limb that made [finding] CloudOperations is a phantom surface: the installed @objectstack/client has no cloud namespace, so deploy() fabricates a deploymentId for work that never happened #4152 urgent.
Keep them and re-title the module banner and v3-compat.test.ts so neither claims a v3 that the family left long ago.

Refs #4152, PR #4239.

Generated by Claude Code

Findings triage (first grade): HOLD — finding stands as filed.

Premise verified on origin/main @ f812de6: the // v3.0.0 Deep Integration modules banner is live at packages/data-objectstack/src/index.ts:3888, and the zero-external-consumer measurement reproduces for all four modules. The only out-of-package hits are homonyms: PageDesigner.tsx:147 declares its own local snapToGrid callback (no import from data-objectstack anywhere in the file) with types/designer.ts:49's boolean config key, and the SecurityManager hits are CHANGELOG prose. Counter-probe intact.
Grade rationale: the card's own distinction is the right one — no fabricated success, no absent backend, so [finding] CloudOperations is a phantom surface: the installed @objectstack/client has no cloud namespace, so deploy() fabricates a deploymentId for work that never happened #4152's urgency limb is missing; what remains is published-surface-with-no-pull, a startup-focus retirement question. Real, latent, nobody bitten. Held rather than promoted.
Restart conditions: ① a maintainer startup-focus ruling on the no-consumer limb (the [finding] CloudOperations is a phantom surface: the installed @objectstack/client has no cloud namespace, so deploy() fabricates a deploymentId for work that never happened #4152 pattern applied to the remaining four) — promote as a retirement sweep then; ② if any of the four gains a consumer, close the relevant row as overtaken; ③ the cheap third direction (re-title the banner + v3-compat.test.ts so they stop claiming a v3) can ride any future touch of data-objectstack — worth naming in the eventual dispatch, not worth its own card today.
Dedup: [finding] CloudOperations is a phantom surface: the installed @objectstack/client has no cloud namespace, so deploy() fabricates a deploymentId for work that never happened #4152 (closed by PR retire(data): remove the phantom CloudOperations surface #4239) covered CloudOperations only; no other open card names these four modules.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

Generated by Claude Code

Findings triage (cadence re-check): PROMOTED — finding → pm:queue (labels switched with this comment).

Premise re-verified on origin/main @ 6d8231c: all four symbol families still have zero code consumers outside packages/data-objectstack (IntegrationManager 0, createDefaultCanvasConfig 0, validatePluginContract 0; SecurityManager's two new grep hits are CHANGELOG rename-table prose, not code — mentions in migration prose are the expected kind).

Why promoted: the deciding pattern is already ruled. #4152 measured CloudOperations — the fifth member of the same v3.0.0 Deep Integration modules banner — on exactly this criterion and retired it (PR #4239). Under the family rule, siblings of a ruled card inherit its ruling rather than re-entering the decision box; holding them re-asks an answered question. Scope for the executor: one retirement sweep card, four modules, same shape as #4152's PR (delete module + index re-export + v3-compat.test.ts coverage), one changeset. If anything turns out to be load-bearing during removal, that is a fork to report, not to absorb.

Not target:v17 (readout for the whole-repo seat): dead exports, no shipped-surface behavior.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

Generated by Claude Code

Claiming — PM dispatch. Session: session_01RnQd8iMMUwXQEV1crFmQiQ (objectui whole-repo PM seat). Branch: claude/issue-4241-v3-banner-retirement-sweep.

Scope per the 2026-08-11 triage promotion (family rule — siblings inherit the #4152 ruling): one retirement sweep over the four remaining v3.0.0 Deep Integration modules (IntegrationManager, SecurityManager, studio helpers, contract helpers) — delete module + index re-export + their v3-compat.test.ts coverage, one changeset following PR #4239's precedent — plus the cheap third direction named in the hold note: the banner and v3-compat.test.ts title stop claiming a v3. Any module that turns out load-bearing during removal is a fork to report, not absorb. PR will be Fixes #4241.

Generated by Claude Code

{
  "issue": 4241,
  "status": "done",
  "branch": "claude/issue-4241-v3-banner-retirement-sweep",
  "pr": "https://github.com/objectstack-ai/objectui/pull/4711",
  "premise_still_valid": true,
  "summary": "Retired the four remaining v3.0.0 Deep Integration modules (contracts.ts, integration.ts, security.ts, studio.ts) from packages/data-objectstack, following the same shape as #4152/PR #4239: deleted the modules, their index.ts re-exports, and the now-empty banner comment; retitled v3-compat.test.ts (one surviving non-v3 block kept it from being an empty shell); added a negative pin test (v3-deep-integration-retired-4241.pin.test.ts) matching cloud-surface-retired-4152.pin.test.ts's shape. Also fixed spec-symbol-batch6.test.ts, a real in-package consumer of SecurityManagerPolicy the issue's premise didn't name (a compile-time naming-collision guard, not a functional consumer). Added a minor changeset following PR #4239's precedent.",
  "tests": "Re-verified zero-consumer premise myself before editing: package-wide grep of all 30 symbol names across packages/, apps/, examples/ found only the module/index/test files inside data-objectstack, plus one previously-unnamed in-package hit (spec-symbol-batch6.test.ts importing SecurityManagerPolicy) which I fixed. Confirmed known homonym traps: PageDesigner.tsx:147's local snapToGrid has no import from data-objectstack; SecurityManager's outside hits are CHANGELOG.md prose. All commands run at final commit 7ccd74239 (git rev-parse --short HEAD, re-run after the final commit, quoted here and in the PR body): `pnpm --filter '@object-ui/data-objectstack^...' build` green (dependency closure); `pnpm exec vitest run packages/data-objectstack/ --maxWorkers=2` -> 'Test Files 37 passed (37)', 'Tests 523 passed (523)'; `pnpm --filter '@object-ui/data-objectstack' type-check` clean; `pnpm --filter '@object-ui/data-objectstack' lint` -> 0 errors, 392 pre-existing warnings unrelated to this change; `pnpm --filter '@object-ui/data-objectstack' build` rebuilt dist/index.d.ts, grepped for the four retired names -> 0 hits. Reverse verification: added a scratch file in packages/plugin-designer importing the retired IntegrationManager from @object-ui/data-objectstack, ran tsc --noEmit, got 'TS2305: Module \"@object-ui/data-objectstack\" has no exported member 'IntegrationManager'' against the rebuilt .d.ts (proves the rebuild was read, not cached), then removed the scratch file -- confirmed clean via git status. Downstream consumer sweep, prefix direction (consumers of this package): `pnpm exec turbo run type-check --filter='...@object-ui/data-objectstack' --concurrency=2` -> 69/69 tasks successful (app-shell, plugin-calendar, plugin-designer, plugin-form, plugin-grid, plugin-kanban, plugin-timeline, react, apps/console and their build/type-check chains). `node scripts/check-changeset-presence.mjs` green (declares .changeset/retire-v3-deep-integration-modules-4241.md); `node scripts/check-changeset-no-major.mjs` green (minor, not major). Self-scanned every changed file for raw control bytes (grep -naP), clean. This repo has no scripts/pm/dispatch-gates.mjs (that script exists in a sibling repo template, not here) and no dedicated check-nul-bytes.mjs script, so gate selection was manual: build+test+typecheck+lint for the affected package (data-objectstack), the two changeset gates (presence, no-major) since this PR ships a user-visible change, and the downstream type-check sweep for the cross-package export removal. GitHub Actions CI had not yet posted check runs at report time (only a Vercel 'Canceled by Ignored Build Step' status shown) -- in_progress/not-yet-posted is the honest read per the no-idle-poll rule.",
  "open_questions": [],
  "out_of_scope_findings": ["filed as #4712: v3-compat.test.ts's surviving 'PaginatedResult API' block asserts only on an inline object literal it constructs itself -- exercises no production code, always passes"]
}

Generated by Claude Code

fix(data-objectstack): retire the four remaining v3.0.0 Deep Integrat…

Navigation Menu

Repository navigation

[finding] The other four "v3.0.0 Deep Integration modules" in data-objectstack have no consumer outside their own tests either #4241

Fact

Why this is graded observation-class, and why it is NOT a repeat of #4152

Adjacent, same theme

Possible directions (left for triage)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[finding] The other four "v3.0.0 Deep Integration modules" in data-objectstack have no consumer outside their own tests either #4241

Description

Fact

Why this is graded observation-class, and why it is NOT a repeat of #4152

Adjacent, same theme

Possible directions (left for triage)

Activity

os-zhuang commented on Aug 11, 2026

os-zhuang commented on Aug 11, 2026

yinlianghui commented on Aug 15, 2026

yinlianghui commented on Aug 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions