Observation-class finding, recorded while implementing #4633 (PR #6532). Nothing a user hits today — dormant code, not a defect.
What
ExportFieldMeta in packages/rest/src/export-format.ts carries eight keys that exist solely to feed the import dry run's hand-copied pre-check mirror:
required, system, readonly, hasDefault, min, max, minLength, maxLength
Their own doc comments said so verbatim — "The following four drive the import path's required-field pre-check (import-runner.ts)" and "The bounds below drive the import path's field-constraint pre-check (import-coerce.ts firstConstraintViolation)".
#4633 ruling D retires that mirror: the dry run now asks DataProtocol.validateData for the engine's verdict, and the engine reads the object's own schema. So buildFieldMetaMap still computes and stores all eight on every import, and after PR #6532 nothing in the repo reads any of them. PR #6532 rewrote the comments so they no longer describe a caller that does not exist, but left the keys in place — retiring them is a separable change with its own sweep, and keeping it out of an already-delicate PR was the deliberate call.
Why it is not simply "delete them"
ExportFieldMeta is exported from @objectstack/rest, so removal is a public-surface change with its own reviewers. It also needs:
buildFieldMetaMap to stop computing them (the hasDefault line carries a substantive comment mirroring applyFieldDefaults's != null gate — that reasoning retires with it);export-format.test.ts cases that pin the built map;- a sweep of
prepareImportRequest consumers, notably plugin-auth's identity import, which builds a metaMap through the same helper.
Suggested disposition
Retire them under ADR-0049's enforce-or-remove posture — they are declared-and-unread, which is the shape that rule exists for. Or, if a reader is found (an import-template surface that wants to show "required" in the UI), record it and keep them. Either way the current state — computed on every import, read by nobody — should not be the resting state.
Observation-class finding, recorded while implementing #4633 (PR #6532). Nothing a user hits today — dormant code, not a defect.
What
ExportFieldMetainpackages/rest/src/export-format.tscarries eight keys that exist solely to feed the import dry run's hand-copied pre-check mirror:required,system,readonly,hasDefault,min,max,minLength,maxLengthTheir own doc comments said so verbatim — "The following four drive the import path's required-field pre-check (import-runner.ts)" and "The bounds below drive the import path's field-constraint pre-check (import-coerce.ts
firstConstraintViolation)".#4633 ruling D retires that mirror: the dry run now asks
DataProtocol.validateDatafor the engine's verdict, and the engine reads the object's own schema. SobuildFieldMetaMapstill computes and stores all eight on every import, and after PR #6532 nothing in the repo reads any of them. PR #6532 rewrote the comments so they no longer describe a caller that does not exist, but left the keys in place — retiring them is a separable change with its own sweep, and keeping it out of an already-delicate PR was the deliberate call.Why it is not simply "delete them"
ExportFieldMetais exported from@objectstack/rest, so removal is a public-surface change with its own reviewers. It also needs:buildFieldMetaMapto stop computing them (thehasDefaultline carries a substantive comment mirroringapplyFieldDefaults's!= nullgate — that reasoning retires with it);export-format.test.tscases that pin the built map;prepareImportRequestconsumers, notably plugin-auth's identity import, which builds ametaMapthrough the same helper.Suggested disposition
Retire them under ADR-0049's enforce-or-remove posture — they are declared-and-unread, which is the shape that rule exists for. Or, if a reader is found (an import-template surface that wants to show "required" in the UI), record it and keep them. Either way the current state — computed on every import, read by nobody — should not be the resting state.