…ved-member warning stop teaching `{ name }` as tolerated (objectui#11550)
The four top-level `fields` input descriptions (`object-form`, `view:form`,
`embeddable-form`, `object-master-detail-form`) and the
`warnUnresolvedTopLevelField` text no longer say a `{ name }` object member
"is tolerated". They still say the members are bare field names, and the
warning still names the right spelling. The stored `{ name }` read in
`ObjectForm.tsx` and `flatFields.ts` is unchanged, per the triage ruling that
a stored entry may stay readable.
Patch changeset for `@object-ui/plugin-form`, because the text ships.
Claude-Session: https://claude.ai/code/session_01FjqrwXPfSMkSfkKYDSRkN2
Co-authored-by: Claude <noreply@anthropic.com>
Part of #11550
Clause-②: no
The patch round of objectui#11550: the seat's decision A (comment
5970513384) under triage ruling5969880008item 1, "the authoring faces stop teaching it". The card stays open after this merges: its governed guide PR objectui#11561 is still in flight, and the seat ends the card when both are in.What changes
packages/plugin-form/src/index.tsx: thefieldsinput description ofobject-form,view:formandembeddable-formdrops ";{ name }is tolerated" from "Bare field names to show, in order (each looked up in the object schema; …)". Theobject-master-detail-formone drops "({ name }tolerated)" after "Members are bare field names". Every other sentence is unchanged.packages/plugin-form/src/sectionFields.ts: thewarnUnresolvedTopLevelFieldmessage drops "({ name }is tolerated)". It still says "Top-levelfieldstakes bare field-name strings", still namessections[].fieldsandFormFieldSchema, and still tells the author to use a bare field-name string or asections[].fieldsentry. Its docblock now says the top level takes only bare field-name strings, and that a STORED{ name }entry still reads but is no authoring spelling..changeset/11550-fields-tolerated-teaching-dropped.md:@object-ui/plugin-formpatch, because the text ships (measured indist/below).SimpleObjectForm'sfieldsToShowloop inObjectForm.tsx,buildFlatFieldsinflatFields.ts), the section shape-3 entry, andObjectFormSchema.Premise check, on
main072b7e8is toleratedandtolerated)overpackages/plugin-form/src: 6 hits, exactly the claimed sites (three identical descriptions, the master-detail one, the warning, its docblock). After this change: 0 hits.objectFormFieldsMembers-8071,topLevelFieldsWarnCoverage-8847,flatFields.test.ts) assert the substrings{ field: 'note' },sections[].fields,FormFieldSchemaand "top-levelfields", and all four are kept.Verification, head
701ada6pnpm --workspace-concurrency=2 --filter '@object-ui/plugin-form^...' build: 11 packages built, exit 0.pnpm exec vitest run --maxWorkers=2 packages/plugin-form/(repo-root form):Test Files 163 passed (163),Tests 1889 passed, 1 skipped (1890).pnpm --filter @object-ui/plugin-form type-check: exit 0, with the script name echoed.eslint .inpackages/plugin-form(the package's ownlintscript), JSON output: 203 files, 0 errors. The two edited files carry 22 and 10 warnings, the same counts as their072b7e8copies linted through stdin. The root config extendstseslint.configs.recommendedand enables no type-aware linting, so this diff cannot move an untouched file's verdict. Repo-widepnpm lintis CI's.pnpm --filter @object-ui/plugin-form build, no file indist/containsis tolerated. The new warning sentence is indist/index.jsanddist/index.umd.cjs, and the new description sentence appears 3 times indist/index.js.check:control-bytesOK;check:new-line-citations0 new;check:pending-changeset-literalsOK;check-changeset-presence(2 source files of 1 released package, 1 changeset);check-changeset-no-major;check-changeset-overwrite(0 modified);check-changeset-fixed;check:element-data-source-declaration;check-governed-queue-guard --testanswers NOT GOVERNED.check:changeset-claims(report-only) asked for three pending paragraphs that namesectionFields.tsto be re-read.9884-master-detail-fields-intersection.mdandconsole-formpage-visible-predicates-5594.mdstay true.8738-fields-warn-route1.mdstays true of the read but still says "{ name }tolerated": see the first acceptance note.Acceptance notes
.changeset/8738-fields-warn-route1.mdis still pending, so it publishes into the same CHANGELOG release as this patch. It says "Top-levelfieldsreads only bare field-name strings ({ name }tolerated)". That is still true of the runtime read, but it is the one remaining shipped text that calls{ name }tolerated. It is not edited here. It is a changeset this change does not own (check-changeset-overwritereports exactly that kind of edit), and it is outside the claimed file surface. The seat decides.FlatFieldsContext.fields' docblock inflatFields.tsstill says "objects carrying one ({ name })". It describes the kept read and is not exported; the seat already recorded it in5970513384. Not touched.object-form.fieldsinregistry-inputs-spec-parity.test.tsstill calls the{ name }spelling "the read site's tolerance rather than a second contract". That is test prose about the pinned stored read, not an authoring face. Not touched.Left to CI
Repo-wide
pnpm lint, thepnpm testshards (the console suites included;registry-inputs-spec-parityonly asserts each description is non-empty), e2e and the performance budget.Session:
https://claude.ai/code/session_01FjqrwXPfSMkSfkKYDSRkN2Generated by Claude Code