finding(plugin-detail): the inline-edit surface runs no host-side validation at all — InlineFieldInput never calls buildValidationRules and never gets an error prop

Filed unassigned by the #6812 survey seat, while verifying that card's premise that buildValidationRules is the producer of the host-side error prop every field widget's published #3222 slot reads. Recording, not choosing — domain:*, type and grading are triage's to produce.

Dedup before filing. Repo-scoped REST listing of the 249 open issues here (PRs excluded) plus a local regex over title+body: zero hits for InlineFieldInput and for inline edit.*validat|validat.*inline edit. A zero is not a reading on its own, so it was reverse-checked with two controls that must hit — buildValidationRules returned #6812 and #6366, and 3222 returned #6812, #6803, #6778, #6776. The zero stands. Nearest neighbour checked and not a duplicate: #6803 is about NumberField not READING the published error slot; this is about a surface where nothing PRODUCES a value for it.

The fact

On the form surface the chain is complete and was verified end to end:

buildValidationRules(field) is called at packages/plugin-form/src/ObjectForm.tsx:705 and packages/plugin-form/src/sectionFields.ts:131;
its rules reach react-hook-form's Controller, and the widget's error prop is fieldState.error?.message (packages/components/src/renderers/form/form.tsx:2683).

The inline-edit surface has neither half. packages/plugin-detail/src/InlineFieldInput.tsx (483 lines, rendered by DetailSection.tsx:333 and HeaderHighlight.tsx:192) imports from @object-ui/fields but not buildValidationRules; grep for validat in that file returns one hit, a comment about backend date handling. DetailSection.tsx has none, and InlineEditSaveBar.tsx has one, also a comment. InlineFieldInput never receives an error prop at all.

⇒ For a record edited in place on a detail page, the #3222 slot has no producer: no required, no minLength/maxLength, no pattern, no email/url, no field-authored validate — and no location, the one stored-value rule the platform has (#6744). The same field, opened in a form, gets all of them.

What is NOT claimed here

⛔ No defect is asserted for any specific field. Whether this is reachable depends per case on what the inline surface actually lets a user edit and on whether the server refuses the same write. Nobody has driven it.
⛔ Not a claim that inline editing should mirror the form. It might be right that the server is the only gate on that surface; if so, that is a decision worth recording, because today it is an absence rather than a decision.
⛔ Not a request to move buildValidationRules. Where the producer should live is exactly the design question this card exists to hand over, not to answer.

Suggested first step

One reading, not a fix: drive an inline edit of a field carrying each rule kind (a required field cleared, a pattern field violated, and a stored out-of-range location — the #6744 case) and record what the surface does, including whether the write reaches the datasource. That output makes this closable ("the server refuses, and the absence is deliberate") or dispatchable on its own evidence.

finding(fields): buildValidationRules validates no structured stored value except location — the other ADR-0104 value-shape classes are unmeasured #6812 — the survey whose premise-check found this; its readings are all taken on the FORM surface, so its scope statement should be read as bounded to that surface.
finding(fields): buildValidationRules has no location branch, so a STORED out-of-range coordinate is never validated — and adding one falsifies the premise #6714 chose refusal on #6744 — the location stored-value branch, the one rule this surface also does not run.
NumberField never reads the published error slot, so an invalid number field is not announced (#3222 gap) #6803 — the consumer-side half on the form surface: a widget that does not read the slot.
字段 widget 的错误提示键:spec 声明 error,objectui 渲染 errorMessage(declared ≠ enforced) #3222 — the published validation slot itself.

Generated by Claude Code

分诊判级 · `finding` → `pm:queue` · `bug` · p2 · `domain:ui`

⭐ 先记名:本卡的查重是本席今天读到的最规范的一次

"A zero is not a reading on its own" —— 于是它用两个必须命中的对照反查(buildValidationRules → #6812/#6366;3222 → #6812/#6803/#6778/#6776),零命中因此成立;并主动核了最近邻 #6803 不是重复(那张是 NumberField 不读已发布的 error 槽,本卡是没有任何东西为它生产值)。⇒ 结论可直接采信,分诊不必重做查重。

判据

表单面链路完整且已端到端验证(ObjectForm.tsx:705 / sectionFields.ts:131 调 buildValidationRules,规则进 Controller,widget 的 error 来自 fieldState.error?.message)。行内编辑面两半都没有:InlineFieldInput.tsx 既不调 buildValidationRules,也拿不到 error prop。

⇒ 同一个字段,在表单里被校验,在行内编辑里不被校验。 用户在两处得到不同的规则,而两处都是产品的正式编辑入口。

⛔ 升级闸(执行者第一必答项,⚠️ 本席未测)

服务端会拒掉这些写吗?

会拒 ⇒ p2 成立:损伤是体验与反馈(用户拿到的是一个原始服务端错误,而不是就地的字段提示);
不拒 ⇒ 这是无效数据可经行内编辑落库,⇒ 立即升 p1 并回分诊,范围要加数据面。

⛔ 不得以「服务端应该会拦」结案 —— 「应该」不是读数。本席今晚在 objectui#6898(FLS 取数面)上写过同一句,两张卡的形状相同:一个前端缺失的门,其严重度由后端是否补位决定,而那件事没人测过。

范围

范围是接上既有生产者(buildValidationRules → error prop),⛔ 不是在行内面另写一套校验 —— 另写一套等于制造第三份规则来源;
必答项 2:除 InlineFieldInput 外,还有哪些编辑入口绕过 buildValidationRules —— 用枚举回答(卡已点名它由 DetailSection.tsx:333 与 HeaderHighlight.tsx:192 渲染,那是入口不是穷举);
与 NumberField never reads the published error slot, so an invalid number field is not announced (#3222 gap) #6803 / finding(fields): buildValidationRules validates no structured stored value except location — the other ADR-0104 value-shape classes are unmeasured #6812 交叉链接,判不收敛(读 vs 产,不同半边)。

Generated by Claude Code

⚖️ RULED — 维护者,2026-08-31,第 6 场总监席决裁批 #13,verbatim「其他同意」(采本席推荐)

裁定:采选项 B——

正式记录:行内编辑面的校验权威是服务端(实测封口:11 种坏写全被引擎 VALIDATION_FAILED 拒,pattern 被 FieldSchema 挡在作者面外、location 有 finding(fields): LocationField emits out-of-range coordinates the spec rejects #6714 发射端守卫;p2 维持,无数据面危害)。此前这是一个「缺席」,现在是一个「决定」——在相应模块注释写明并指向本裁定。
交付物:把服务端 VALIDATION_FAILED 拒绝映射为就地字段提示(拒绝信息已含字段与规则,缺的只是呈现层)——用户不再看到原始服务器错误。
观察表入档:census 的 10 个绕过入口清单(修正后读法:presence 判定已由 @object-ui/core isMissingForRequired 单源六消费,真正无共享家的只有求值器)作为观察表留卡;⛔ 不抽取共享求值器(选项 A)——待第二个真需要客户端求值的表面出现时按此清单重议。
⛔ 照旧不写第二套校验实现——B 恰好不需要:服务端是唯一规则源,前端只做呈现。

席位边界(裁不派):录裁 + 保持 pm:queue,同笔摘 needs-user-decision;派发归 ui 车道。裁决入本场追认摘要表。

Generated by Claude Code

Claim: PM loop round 3 (domain:ui seat)
Session: session_012wwHa4aaFybxXrfmfHioDM (GitHub identity os-warren — a different seat from os-sam, who ran the measurement round on this card)
Branch: claude/issue-6868-inline-edit-server-verdict
Worktree: objectui-issue-6868-b
Domain: domain:ui
File surface: packages/plugin-detail/src/ — InlineEditSaveBar.tsx, InlineFieldInput.tsx, DetailSection.tsx, HeaderHighlight.tsx, and tests in that package (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no — and this is a changed answer with a recorded reason, not an omission. The predecessor applied needs:contract-review on the premise that connecting the producer would narrow what the surface accepts, then dropped it with an explicit re-apply condition: "⛔ Re-apply it if the ruling picks A or B, which do introduce a client-side narrowing." The ruling picked neither. Under the ruled option nothing narrows — the accept/reject boundary stays exactly where the server already puts it and only the presentation of an existing refusal changes. The event the rule keys on does not occur.
Serial constraints cleared: packages/plugin-detail/** — free. #7007's PR #7076 merged, so the earlier hold is spent. My other in-flight work is examples/schema-catalog (#7072 patch round), content/docs/components + packages/types/src/__tests__ (#7082, PR open), scripts/ (#7086, enqueued), and app-shell/plugin-list/plugin-view (#7070, dispatched alongside this one). None touches plugin-detail.

ZONE 1 — THE RULING (维护者, 2026-08-31, 决裁批 #13, verbatim「其他同意」) ⛔ 不可重裁

Quoted, not paraphrased:

正式记录:行内编辑面的校验权威是服务端(实测封口:11 种坏写全被引擎 VALIDATION_FAILED 拒,pattern 被 FieldSchema 挡在作者面外、location 有 finding(fields): LocationField emits out-of-range coordinates the spec rejects #6714 发射端守卫;p2 维持,无数据面危害)。此前这是一个「缺席」,现在是一个「决定」——在相应模块注释写明并指向本裁定。

交付物:把服务端 VALIDATION_FAILED 拒绝映射为就地字段提示(拒绝信息已含字段与规则,缺的只是呈现层)——用户不再看到原始服务器错误。

观察表入档:census 的 10 个绕过入口清单…作为观察表留卡;⛔ 不抽取共享求值器(选项 A)——待第二个真需要客户端求值的表面出现时按此清单重议。

⛔ 照旧不写第二套校验实现——B 恰好不需要:服务端是唯一规则源,前端只做呈现。

So there are exactly two deliverables, and both are presentation-layer:

(a) Record the decision in code. The module comment must say that the server is the validation authority on this surface, and point at this ruling. ⭐ The ruling's own framing is the point: "此前这是一个「缺席」,现在是一个「决定」" — an absence and a decision look identical in code until someone writes the second one down.

(b) Map the server's VALIDATION_FAILED into an in-place field hint. The refusal envelope already carries field, code, message, constraint; the widgets already read a published error slot (#3222). What is missing is only the wiring between them. Today cleanError produces a raw string — that is what the user sees and what this replaces.

⛔ Hard prohibitions from the ruling

⛔ Do not extract a shared evaluator. Option A is explicitly refused.
⛔ Do not write a second validation implementation. The ruled option does not need one: the server is the only rule source, the front end only presents.
⛔ Do not call buildValidationRules from this surface. That was the previous scope and it was measured infeasible; the ruling replaced it.
⛔ Do not touch packages/plugin-form/** (the reference form chain) or packages/components/src/renderers/form/form.tsx.

ZONE 2 — PM MECHANISM ASSUMPTIONS (⚠️ these are the predecessor's measurements, not mine; the tree has moved to `2c3cd1b`)

The server refuses required (empty and null), minLength, maxLength, email, url, min, max — each VALIDATION_FAILED, prior value retained. Re-derive the envelope's actual shape before you map it; the mapping is the deliverable and it must be keyed off what the envelope really contains, not off the report's summary of it.
The refusal is said to carry field, code, message, constraint. ⚠️ Verify each of those four is really present — if field is missing or ambiguous for a multi-field write, that changes the whole design and is a stop-and-report.
cleanError in InlineEditSaveBar.tsx is named as the current producer of the raw string. Re-derive its location.
The inline surface writes as one atomic dataSource.update of only the edited keys (DataSource mode) or a per-field onFieldSave loop (callback mode). ⚠️ Those two modes may surface refusals differently — cover both or state which you covered.

⚠️ The trap I most expect

A server refusal for a multi-key write has to be routed back to the right field. If the envelope names the field, that is mechanical. If it does not — or names it in a spelling the inline surface does not key on — then a naive mapping either drops the hint or attaches it to the wrong input, which is worse than the raw error it replaces. Measure this before designing the mapping, and if the envelope cannot be attributed per field, stop and report rather than guessing an attribution.

Evidence

Green is not evidence here unless a test can see the change. Land a pin that shows a VALIDATION_FAILED refusal reaching the field's error slot, with a counter-probe proving the assertion fails when the mapping is removed. ⭐ The predecessor measured that an error prop handed to InlineFieldInput today does not reach the DOM (reachesDom=false) — so if you wire the mapping but that path is still dead, your pin must be able to tell you. Re-measure that reading first; it may itself be part of what you must fix.

Zero-hit discipline: any zero needs a control term that must hit in the same query.

Repo rules that bite

vitest: root-relative form ONLY — a package-directory run silently re-roots onto apps/console and reports green (#3378); the predecessor's dev hit exactly this here. eslint: plain form, ⛔ never --no-inline-config. ⛔ major refused by check-changeset-no-major.mjs. Changeset required and graded by you — quote the gate's verdict line. ⛔ Never git stash. ⛔ No force-push. ⛔ Never edit content/docs/releases/.

Landing

Draft PR, base main, first line Fixes #6868 only if both deliverables (a) and (b) land. Partial ⇒ Part of #6868 and say what is left. ⛔ Do not mark ready, do not enqueue — the PM arms landing.

Read the card and all seven comments on GitHub yourself; the ruling is the last one. Check for sanitizer truncation and say you checked. Leave your own claim comment with your own session ID and branch; ⛔ do not touch the assignee field.

Generated by Claude Code

Claim: os-dev agent (dispatched by the domain:ui PM seat)
Session: session_012wwHa4aaFybxXrfmfHioDM
Branch: claude/issue-6868-inline-edit-server-verdict
Worktree: objectui-issue-6868-b
Repo: objectstack-ai/objectui

Read before starting: the card body plus all 8 comments, window 2026-08-30T07:46:29Z → 2026-09-01T00:18:16Z — triage, the predecessor dev's dispatch, the predecessor's needs_decision report, the PM's gate-answered comment, the #6967/#6968 number correction, the census correction (isMissingForRequired is an import, not a re-derivation), the maintainer ruling (决裁批 #13, the last substantive one), and the PM's round-3 dispatch claim. Sanitizer truncation checked: every comment terminates in its own signature footer, the ruling's four numbered clauses are all present, and the predecessor's report JSON closes its braces — no body reads as cut off. Angle-bracket fragments in those bodies survive only as HTML entities, which is the known sanitizer behaviour, not truncation.

No prior claim by this session. The predecessor seat (os-sam, session_013hfmP9hoMd3dJwTh85J4yB, branch claude/issue-6868-inline-edit-validation) returned needs_decision and wrote no code; that round is closed by the ruling and I am not re-deriving its measurement.

Scope I am executing is the ruling's two presentation-layer deliverables only: (a) record in a module comment that the server is the validation authority on this surface, pointing at the ruling; (b) map the server's VALIDATION_FAILED refusal into an in-place field hint instead of the raw string. ⛔ No shared evaluator, no second validation implementation, no buildValidationRules call from this surface.

Generated by Claude Code

os-dev-report

{
  "issue": 6868,
  "status": "rework",
  "branch": "claude/issue-6868-inline-edit-server-verdict",
  "pr": "https://github.com/objectstack-ai/objectui/pull/7109",
  "premise_still_valid": true,
  "summary": "Deliverable (a) of the ruling LANDS IN FULL: the module headers of InlineEditSaveBar.tsx and InlineFieldInput.tsx now state that the server is the validation authority on this surface, quote the ruling, point at #6868, and name what a future editor must not do. Deliverable (b) lands PARTIALLY and I am reporting the reason rather than routing around it. What landed: a VALIDATION_FAILED refusal is now attributed PER FIELD and rendered as one reason per rejected field named by that field's own label, replacing the raw server string cleanError produced -- so the ruling's stated user outcome (the user no longer sees the raw server error) is met, and every hint names a field. What did NOT land: the hint renders in the record-level save bar, not beside each input. That is a fence, not a design choice -- MEASURED: in BOTH persistence modes the save bar and the field renderers have exactly ONE common ancestor and it is InlineEditProvider in packages/react, outside the declared file surface (record page: app-shell/RecordDetailView.tsx:2340 mounts the provider, :2509 the save bar, with the DetailView/DetailSection chain as its sibling; drawer: RecordDetailDrawer.tsx:346 / :398, same shape). InlineEditContextValue carries only `error: string | null`, a single record-level string documented as 'driven by the save bar'; per-field attribution needs one additive slot beside it. I did NOT make that edit. I also rejected encoding attribution into the existing string and parsing it back -- error-message.ts names that anti-pattern in writing ('scraping a marking out of a transport's prose'), so it would be a workaround, not a fix. No client evaluator, no second validation implementation, no buildValidationRules call, no packages/plugin-form or form.tsx edit, no packages/fields edit.",
  "tests": "All heavy runs via the shared verify lock; exit codes captured before any pipe; verdicts quoted from each tool's own line. PIN: packages/plugin-detail/src/__tests__/InlineEditSaveBar.serverVerdictFieldHint-6868.test.tsx, 7 tests -- 'Test Files 1 passed (1) / Tests 7 passed (7)', exit 0. COUNTER-PROBE (ablation): attributeInlineRefusal forced to return null, i.e. the mapping removed. Mutation proven ON DISK before the run, not by the editor's exit code -- injected marker grep 2 hits (expected 2), deleted-text grep 0 hits (expected 0), blob 38b5db1f -> 81c5cda7; the script asserted all three and would have exited 9 on any mismatch. Result: 'Tests 5 failed | 2 passed (7)', ABLATED_PIN_EXIT=1. The 2 that stayed green are the two NEGATIVE cases (entry with no usable field is dropped; non-field-scoped failure keeps the cleaned string) -- they assert the FALLBACK, which the ablation forces everywhere, so green is the correct direction for them and I am reporting the direction I observed rather than a template's 'all red'. NO REBUILD WAS REQUIRED and here is why, stated rather than assumed: the pin imports '../InlineEditSaveBar' as a RELATIVE SOURCE path, so vitest transpiles the mutated source directly and no dist is in the resolution path. Restore leg given the same treatment as the mutation leg: trap '<restore>' EXIT INT TERM with an ABSOLUTE path derived from git rev-parse --show-toplevel, restore written as `git checkout HEAD -- \"$REPO_ROOT/<path>\"` (never the bare form, which reads from the index), and proven by observation -- `git diff HEAD` empty, marker grep 0 hits, disk blob back to 38b5db1f == HEAD blob 38b5db1f. PACKAGE SUITE + TYPECHECK at the FINAL commit 2560846b9: 'Test Files 119 passed (119) / Tests 1096 passed (1096)', and type-check echoed 'tsc --noEmit && tsc -p tsconfig.test.json' (both legs, so the script name was not mistyped into a zero-match no-op), VERDICT command-exit 0. Root-relative vitest form throughout -- no package-directory run, so the #3378 silent re-root onto apps/console could not occur. GATES at 2560846b9: check:control-bytes exit 0 'OK (scanned 5885 tracked text file(s); skipped 85 binary)'; check-changeset-no-major exit 0 'No changeset declares a major bump.'; check-changeset-presence exit 0 '3 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)'; check:phantom-deps exit 0 'Every in-scope import is declared by the package that publishes it'; check:self-import exit 0; check:esm-specifiers exit 0; check:vi-mock-specifiers exit 0; check:vi-mock-inherit exit 0; check:i18n-keys exit 0. ESLINT plain form (never --no-inline-config): exit 0, 0 errors; warning count measured against the origin/main content of the SAME files -- 7 no-explicit-any before, 7 after, 0 new. One warning I did introduce and then removed: exporting attributeInlineRefusal added a react-refresh/only-export-components warning the file did not have; the pin drives it through the rendered bar anyway, so it is now module-local and the count is back to baseline. SELF-SCAN for raw control bytes over all four changed files: no hits. One lock attempt returned exit 99 (queue-timeout, 540s budget, never acquired) -- NOT a failure and NOT reported as one; the slot was kept via OS_VERIFY_LOCK_SLOT, I spent the interval on lock-free work (commit, push, PR body) and re-acquired in 10s.",
  "mcp_calls": "6 -- issue_read(get), issue_read(get_comments), add_issue_comment(claim), create_pull_request, pull_request_read(body read-back), add_issue_comment(this report). The repo-scoped REST channel was probed FIRST and returned 403 with 'GitHub access is not enabled for this session' on a plain issue GET, and `gh` is absent, so every card read went through MCP; no wide listing and no search was run.",
  "measured_envelope_shape": "Re-derived from the PRODUCER, not from the predecessor's summary. Path: @objectstack/objectql validators throw VALIDATION_FAILED with fields[]; @object-ui/data-objectstack's normaliseClientError (index.ts:1226) re-wraps it into DataApiValidationError (errors.ts:176) carrying `message`, `field` (the FIRST rejected field only), `validationErrors: Array of {field, message}`, and `details: {fields: rawFields, userMessage?}`. @object-ui/react's extractFieldErrors (utils/error-message.ts:170) is the ONE in-repo normaliser and reads three shapes -- `validationErrors`, `details.fields`, bare `fields` -- keying the name off field/name/path and the reason off message/error/code. CORRECTION to the PM's ZONE 2 assumption, which said the envelope carries 'field, code, message, constraint': field YES, message YES, code YES but only on the RAW details.fields entries and only as a last-resort message fallback (the normaliser deliberately does not surface it, because an untranslated machine enum in the UI reads as a bug), and `constraint` NO -- there is no such key anywhere in the producer, the re-wrap, or the normaliser. I keyed the mapping off what is actually there.",
  "per_field_attribution_finding": "ATTRIBUTABLE, mechanically, and the trap the PM predicted does not fire. The envelope names the field by MACHINE NAME, which is exactly the key the inline surface already uses -- the draft key set by inline.setField(field.name, v), and field.name in DetailSection/HeaderHighlight -- so no spelling translation is involved and a multi-key atomic write routes each reason to the right field. The 'drops the hint or marks the wrong input' failure is closed by the normaliser itself: an entry with no usable field is DROPPED, by design, on the stated grounds that a wrong mark on an innocent input is worse than the undirected string. I pinned that drop rather than trusting it. BOTH modes are covered, differently and deliberately: DataSource mode (one atomic multi-key update) can only be attributed from the envelope, and is; callback mode (the drawer's per-field onFieldSave loop) is additionally attributable from the CALL SHAPE, because the write in flight carries exactly one key -- that is a fact about the write, not an inference, and it recovers attribution even when the envelope carries no fields[]. The envelope still wins when both are available; pinned.",
  "counter_probe_result": "PASSED -- 5 of 7 pin assertions go red with the mapping removed (exit 1), with the mutation and the restore each proven by observing disk state, not by reading an exit code. Details in the `tests` field.",
  "files_changed": [
    "packages/plugin-detail/src/InlineEditSaveBar.tsx (+164/-7) -- ruling recorded in the module header; attributeInlineRefusal added (module-local); both save paths and the conflict-overwrite path attribute; alert region renders one row per field carrying data-inline-field-error",
    "packages/plugin-detail/src/InlineFieldInput.tsx (+30) -- COMMENT ONLY; the ruling recorded where the 'why is there no validation here' question is asked, plus the measured caveat that the #3222 error slot marks aria-invalid and does not render a message",
    "packages/plugin-detail/src/__tests__/InlineEditSaveBar.serverVerdictFieldHint-6868.test.tsx (+223) -- new pin, 7 tests",
    ".changeset/6868-inline-edit-server-verdict.md (+31) -- @object-ui/plugin-detail: patch"
  ],
  "gates_and_exit_codes": {
    "vitest packages/plugin-detail/src (root-relative) @2560846b9": "0 -- Test Files 119 passed (119) / Tests 1096 passed (1096)",
    "pnpm --filter @object-ui/plugin-detail run type-check": "0 -- tsc --noEmit && tsc -p tsconfig.test.json",
    "eslint (plain form, 3 changed source files)": "0 -- 0 errors, 0 new warnings vs the origin/main baseline of the same files",
    "check:control-bytes": "0",
    "check-changeset-no-major.mjs": "0",
    "check-changeset-presence.mjs": "0",
    "check:phantom-deps": "0",
    "check:self-import": "0",
    "check:esm-specifiers": "0",
    "check:vi-mock-specifiers": "0",
    "check:vi-mock-inherit": "0",
    "check:i18n-keys": "0",
    "ablation (counter-probe, expected RED)": "1 -- Tests 5 failed | 2 passed (7)"
  },
  "reachability_remeasure_at_2c3cd1b": "The predecessor's reachesDom=false STILL REPRODUCES, and the mechanism is more useful than the reading. Six readings, each paired with a control that had to hit, all asserted (throwaway probe, run root-relative, deleted after): (1) CONTROL -- NumberField given `error` DIRECTLY sets aria-invalid=true and renders NO message text; (2) negative CONTROL -- NumberField with no `error` has no aria-invalid, so reading 1 is a real signal; (3) FieldEditWidget given `error` produces neither, so #7008's claim REPRODUCES at 2c3cd1b independently of anything I changed; (4,5,6) InlineFieldInput given `error` produces neither, for a routed type (number), the terminal raw text input (text) and the delegated tail (tags). THE LOAD-BEARING FINDING, and it answers the coordinator's fence question: the published #3222 `error` slot marks aria-invalid; it DOES NOT render a message. The visible message on the form surface is drawn by form.tsx, not by the widget. So repairing packages/fields would buy the a11y marking and NOT a visible in-place hint -- the hint text is plugin-detail's own markup to render either way. ⇒ THIS WORK HAS NO CROSS-PACKAGE DEPENDENCY ON #7008, and I made no packages/fields edit. The first cause of reachesDom=false is in plugin-detail anyway: `error` is not in InlineFieldInputProps at all and is forwarded nowhere; FieldEditWidget's drop is a SECOND, independent break that only affects the delegated tail.",
  "surface_breach": "NONE. Every edit is inside packages/plugin-detail/src plus its tests. The one edit that would have completed deliverable (b) -- a single additive slot on InlineEditContextValue in packages/react/src/context/InlineEditContext.tsx, beside the `error` string it already carries -- was NOT made, per the dispatch's 'breach ⇒ stop and report'. For sizing: with that slot present, DetailSection.tsx and HeaderHighlight.tsx could read it directly (HeaderHighlight already calls useInlineEdit; DetailSection is in the file surface and could), so NO host wiring in app-shell or RecordDetailDrawer would be needed -- it is one file and roughly ten additive lines, not a cascade. I am not asking for it; I am sizing it so the PM can price widening the fence against dispatching it.",
  "open_questions": [
    {
      "question": "Deliverable (b) asks for an 就地字段提示 -- a hint beside the input. What landed is a hint attributed per field but rendered in the record-level save bar, because the only common ancestor of the save bar and the field renderers is InlineEditProvider in packages/react, outside my fence. How should the last hop be taken?",
      "options": [
        "A -- Widen the fence by one file: add `fieldErrors: Record<string,string> | null` + `setFieldErrors` to InlineEditContextValue in packages/react/src/context/InlineEditContext.tsx, exactly parallel to the `error`/`setError` pair that is already documented as 'driven by the save bar'. The save bar (already mine) writes it; DetailSection and HeaderHighlight (already mine) read it and render the hint under each input. Purely additive, backward compatible, no host wiring, no new dependency, no packages/fields involvement. Cost: it adds packages/react to the verification face, which is why I did not take it unilaterally.",
        "B -- Dispatch the context slot as its own card, then a patch round here to consume it. Same end state as A, two dispatches instead of one, and this PR sits partial in the meantime.",
        "C -- Accept the save-bar rendering as the delivered form of (b) and close #6868 on it. The ruling's stated user outcome ('用户不再看到原始服务器错误') is met and every reason names its field; what is not met is the literal 就地 placement.",
        "D -- Route it through props instead of context: a callback prop on InlineEditSaveBar plus a fieldErrors prop on DetailSection. ⛔ I recommend against this and did not build it -- the wiring then lives in app-shell/RecordDetailView.tsx and RecordDetailDrawer.tsx, which is MORE out-of-fence surface than A, and until those hosts are wired the props are unconsumed, which is exactly the declared-but-dead shape this repo retires under ADR-0049."
      ],
      "recommendation": "A. Real business need: the ruling asked for a hint beside the input and the measured damage is precisely locational -- a user who edited three fields now gets three named reasons, but still has to look at the bar rather than the input; option A is the only route that closes that with no new mechanism. Long-term soundness: the context is the DOCUMENTED channel between the save bar and the field renderers ('the atomic save + conflict handling live in InlineEditSaveBar, which reads this context ... and drives saving/error/reset'), so the slot is the same mechanism one field wider, not a second one -- whereas D invents a parallel prop path and the string-encoding variant I rejected is an anti-pattern this repo has already written down. Hard to get wrong for AI-authored metadata: unchanged either way and that is the point -- nothing in A adds a client-side verdict, so the surface still cannot drift from the server; the drift risk lives in options nobody is proposing. Startup scope discipline: A is one file and about ten additive lines with no new dependency and no host change, and it is the CHEAPEST of the four -- B costs a second dispatch for the same diff, D costs two more packages and ships dead props first. Conflicts: A is cheapest AND soundest here, so the axes do not fight; the only reason it is not already done is the fence, which is the PM's to move, not mine.",
      "recommendation_owner": "PM/maintainer -- I did not act on this."
    },
    {
      "question": "Changeset grade. I graded @object-ui/plugin-detail as `patch` and justified it in author-facing terms in the changeset itself: nothing is added to or removed from the package's callable surface (no new export -- attributeInlineRefusal is module-local -- and no prop added or removed), and an existing surface renders an existing refusal better. The predecessor's dispatch had framed this card as a behaviour NARROWING, which would have argued for minor; under the ruled option nothing narrows, since the accept/reject boundary stays exactly where the server already puts it and only the presentation changes.",
      "options": [
        "A -- keep `patch` (what I shipped).",
        "B -- regrade to `minor` if the seat treats any user-visible presentation change to a published plugin as minor."
      ],
      "recommendation": "A, and flagged rather than assumed because the grade is the seat's convention to enforce. The gate's own verdict line is quoted in the report: 'No changeset declares a major bump.' plus '3 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)'."
    }
  ],
  "out_of_scope_findings": [
    "NOT filed, reported instead -- #7008 (FieldEditWidget drops the declared non-DOM host-plumbing keys, `error` first among them) REPRODUCES at 2c3cd1b: FieldEditWidget given `error` sets no aria-invalid, while NumberField given the same prop directly does. Not filed as a new card because it is already open, unassigned and undispatched, and the coordinator named it. Two corrections worth carrying back onto it: (1) repairing it would restore the aria-invalid MARKING only -- the published #3222 slot does not render message text on any widget I measured, so #7008 does not by itself give any surface a visible hint; (2) it is therefore NOT a blocker for this card, which is the opposite of what the coupling warning assumed.",
    "NOT filed, reported instead -- InlineFieldInput accepts no `error` prop at all (it is absent from InlineFieldInputProps and forwarded nowhere), so on the routed branches -- which is most types, and where the widget WOULD honour it -- the inline surface forfeits the aria-invalid marking the form surface gets for free. That is an a11y gap distinct from #7008 and inside my own file surface, but I did not fix it: threading the prop without a value to put in it would ship a dead prop, and the value only exists once the transport in open_question 1 is settled. Filing it as its own card would be filing a card that cannot be worked before that decision, so it belongs in the same ruling."
  ]
}

Generated by Claude Code

⚠️ Sanitizer correction to the os-dev-report above — 3 angle-bracket fragments were eaten, none of them truncation

I read the comment back to its footer, as required. It is not truncated — it terminates in its own signature. But GitHub's body sanitizer swallowed three short angle-bracket fragments, and two of them are load-bearing, so here they are in placeholder spelling. This is my own discipline breach: the rule is to spell angle-bracket shapes as placeholder words before posting, and I applied it to the PR body and then not to the report.

where	what I wrote	what GitHub stored
`tests`, ablation restore leg	`trap 'RESTORE_FN' EXIT INT TERM`	`trap '' EXIT INT TERM`
`tests`, ablation restore leg	`git checkout HEAD -- "$REPO_ROOT/PATH"`	`git checkout HEAD -- "$REPO_ROOT/"`
`open_questions[0]`, option A	`fieldErrors: Record of string to string, or null`	`fieldErrors: Record \| null`

⭐ The middle one is the one that matters, because as stored it reads like the exact bug the rule exists to catch: a restore that names no path. It named one. The mechanism, restated so the record is correct:

the trap ran a restore shell function, registered on EXIT INT TERM;
that function is git checkout HEAD -- "$REPO_ROOT/packages/plugin-detail/src/InlineEditSaveBar.tsx" — an absolute path built from git rev-parse --show-toplevel, and pinned to HEAD rather than the bare form, which reads from the index and would have restored the mutation itself;
and the trap was not the proof. The proof is observation after the fact: git diff HEAD empty, marker grep 0 hits, and the file's disk blob back to 38b5db1f, equal to its HEAD blob.

The third row is the proposed type for option A: a string-to-string map of field name to reason, nullable — the same shape extractFieldErrors already produces, keyed by field.

No other reading in that report changes. The JSON is otherwise byte-faithful to what I measured.

Generated by Claude Code

ACCEPT WITH FOLLOW-UP — PR #7109. Deliverable (a) is complete; (b) is one file short of the ruling's own word, and I am extending the fence to close it.

domain:ui seat, session session_012wwHa4aaFybxXrfmfHioDM. Reviewed against the report's measurements and the ruling text.

⛔ First: a fact I passed down was wrong, and a warning I gave was inverted

① My ZONE 2 said the envelope carries field, code, message, constraint. I relayed that from the previous round's report. Measured from the producer:

field YES, message YES, code YES but only on the raw details.fields entries and only as a last-resort fallback — the normaliser deliberately does not surface it, because an untranslated machine enum in the UI reads as a bug. constraint NO — no such key exists anywhere in the producer, the re-wrap, or the normaliser.

⇒ I asked you to verify all four rather than build on them, and that instruction is the only reason a mapping was not keyed off a field that does not exist. ⭐ The relayed-fact failure is mine; the check that caught it was cheap and belongs in every order.

② My #7008 coupling warning was right to raise and wrong in its conclusion. I told you the dead error slot was probably packages/fields' fault and that fixing it might need #7008 to land first. Your six readings, each with a control that had to hit, say otherwise:

the published #3222 error slot marks aria-invalid; it does NOT render a message — the visible message on the form surface is drawn by form.tsx, not by the widget.

⇒ Repairing #7008 buys the a11y marking and not a visible in-place hint; the hint text is plugin-detail's own markup either way. So this card has no cross-package dependency on #7008 at all, and the first cause of reachesDom=false is in plugin-detail anyway — error is absent from InlineFieldInputProps and forwarded nowhere. #7008's drop is a second, independent break affecting only the delegated tail.

⭐ That is the better outcome than "the coupling was real": it means I held #7008 out of the rotation for a dependency that does not exist, and now I know the actual shape. Two corrections carried back onto #7008 in your report — it is not a blocker, and repairing it restores the marking only.

⭐ The trap I predicted does not fire, and the reason is worth keeping

I warned that a multi-key refusal might not be attributable per field, and that a naive mapping marking the wrong input is worse than the raw error it replaces. Measured: the envelope names the field by machine name — the exact key the inline surface already uses — so no spelling translation exists to get wrong.

And the wrong-mark failure is closed by the normaliser itself: an entry with no usable field is dropped by design, on the stated grounds that a wrong mark on an innocent input is worse than an undirected string. ⭐ You pinned that drop rather than trusting it, which is the difference between inheriting a safety property and owning one.

Both persistence modes covered, and differently on purpose: DataSource mode is attributable only from the envelope; callback mode is additionally attributable from the call shape, because the write in flight carries exactly one key — a fact about the write, not an inference. Envelope wins when both are available. Pinned.

The rejected shortcut

encoding attribution into the error string and parsing it back — error-message.ts names that anti-pattern in writing

⇒ Refusing a workaround the repo has already written down as an anti-pattern, rather than reinventing the argument, is exactly right.

Why this is not ACCEPT-and-close

The ruling says 「把服务端 VALIDATION_FAILED 拒绝映射为就地字段提示」. 就地 — in place — is in the ruling's own text. What landed puts a per-field-named reason in the record-level save bar: the stated user outcome is met, the placement is not. Closing on that (your option C) would quietly narrow a maintainer ruling to fit a fence.

⇒ Taking option A, and your closing sentence is the right framing: the only thing stopping A was the fence, and the fence is mine to move. It was drawn before your measurement existed.

Fence extended by exactly one file: packages/react/src/context/InlineEditContext.tsx — a nullable field→reason map plus its setter, parallel to the error/setError pair already documented as "driven by the save bar". ⛔ Nothing else in packages/react; ⛔ app-shell, RecordDetailDrawer, packages/fields, plugin-form and form.tsx all stay out, and if A turns out to need host wiring after all, that is a stop-and-report.

The error prop on InlineFieldInput joins this round for the same reason: you correctly refused to ship a dead prop when no value existed to put in it; under A the value exists, so it stops being dead.

⚠️ Surface check I asked for explicitly: adding a member to an exported interface of a published package is close to a widening, and this lane floors those. My reading is that it is not clause ② — InlineEditContextValue is a runtime React context shape, not an authoring contract; no JSON author writes against it and nothing changes about what metadata is accepted or refused. ⛔ That is my reading, not a measurement, and the dev is instructed to stop and report if the tree says otherwise.

Changeset

patch stands for @object-ui/plugin-detail — your reasoning is right: nothing enters or leaves its callable surface, and an existing surface renders an existing refusal better. The predecessor's framing of this card as a narrowing died with the ruling; under it nothing narrows.

⚠️ @object-ui/react now gains an additive public API member ⇒ minor for that package in the same changeset.

Method notes worth keeping

⭐ The ablation's 2 green tests are reported as the correct direction, not explained away: they are the two negative cases asserting the fallback, which the ablation forces everywhere. Reporting the direction observed rather than a template's "all red" is what makes the other 5 reds mean something. · Mutation and restore each proven by observing disk state — injected/deleted grep counts and blob hashes, with the script exiting 9 on any mismatch — never by reading an exit code. · Lint warnings measured against the origin/main content of the same files (7 before, 7 after), and a react-refresh warning it introduced was noticed against that baseline and removed by making the helper module-local. · One lock attempt returned exit 99 (queue timeout) and was correctly reported as not a failure.

⛔ PR stays draft. Patch round sent.

Generated by Claude Code

os-dev-report

ADDENDUM — option A round. Delta only; nothing already ACCEPTed is restated. PR #7109, head 2012c0a87, still draft.

{
  "issue": 6868,
  "status": "done",
  "branch": "claude/issue-6868-inline-edit-server-verdict",
  "pr": "https://github.com/objectstack-ai/objectui/pull/7109",
  "round": "2 of 2 — option A, on the PM's extended fence",
  "premise_still_valid": true,
  "summary": "Option A landed as sized, and the sizing held: NO host wiring was needed, so app-shell and RecordDetailDrawer are untouched and I did not have to stop and report. The server's reason now renders BESIDE the input it refused, with role=alert, and that input is marked aria-invalid. Both ruling deliverables are therefore complete and the PR's first line moved from 'Part of #6868' to 'Fixes #6868' -- flagging that explicitly because it is a state change the PM may want to veto: on merge it closes the card. Everything else from round 1 is unchanged.",
  "new_file": "packages/react/src/context/InlineEditContext.tsx (+40/-4) -- the ONE file the PM added to the fence, and the only file touched outside packages/plugin-detail. InlineEditContextValue gains `fieldErrors` (a nullable map of field machine name to the server's reason) and `setFieldErrors`, the exact companions of the `error`/`setError` pair the interface already carried and already documented as 'driven by the save bar'. Cleared by enter() and by teardown alongside `error`, so an attribution cannot outlive its session -- which also retired the local stale-guard round 1 needed, making that invariant structural instead of remembered. Purely additive: nothing removed, nothing reshaped, every existing host compiles and behaves as before.",
  "consumers_rewired": "InlineEditSaveBar publishes the attributed refusal onto the session instead of holding it locally (one presentRefusal helper now serves the save path AND the conflict-overwrite path, which previously duplicated the formatting); DetailSection reads the session directly via useInlineEdit -- returning null outside a provider, so a bare read-only DetailSection is unchanged -- and HeaderHighlight, which already read the session, reads one more slot. Each draws the reason under its input as a role=alert paragraph carrying data-inline-field-hint.",
  "threaded_prop": "InlineFieldInput now takes `error` and forwards it to all 15 routed widget call sites plus the FieldEditWidget delegation, and marks the terminal raw text input with aria-invalid directly, since no widget sits behind that branch to honour the slot. This is my own round-1 out-of-scope finding, and it stops being a dead prop exactly because option A creates the value -- which is why it belonged in this round. NOTE, and it is the reason no packages/fields edit was needed: the published #3222 slot marks aria-invalid and does NOT render text, on this surface or the form one, so the prop buys the a11y marking only and the visible hint is this package's markup either way.",
  "clause_2_check": "RUN BEFORE the interface was widened, as instructed, and it does NOT make this clause ②. Four readings, each zero paired with a control that had to hit: (1) `InlineEditContextValue` has ZERO references anywhere outside its own module and one prose comment in DetailView -- control `FieldSchema` hit 4 files under scripts/ in the same sweep; (2) ZERO mentions in check-spec-symbols, check-element-data-source-declaration or check-designer-field-key-parity; (3) packages/react/README.md mentions `InlineEdit` ZERO times -- control `SchemaRenderer`, 13 hits -- so no documented contract enumerates it, and an ADDITIVE member could not break a README import in any case; (4) the slot is populated from React state by the save bar and read by two renderers, so no document is parsed into it and nothing changes about what metadata the platform accepts or refuses. ⇒ Your reading is confirmed by measurement rather than adopted: runtime context shape, not an authoring contract. It IS an additive public API member (the barrel re-exports it transitively: index.ts -> context/index.ts -> InlineEditContext.ts), which is why the react entry is minor.",
  "changeset_regrade": "DONE as ruled -- one changeset, two entries: '@object-ui/plugin-detail': patch and '@object-ui/react': minor. The body now spells the addition out by name (both members, their type, that nothing is removed or reshaped, and WHY it exists -- the save bar and the field rows being siblings under the provider). No major. Gate verdict: check-changeset-presence '6 source file(s) of 2 released package(s) changed, and this change declares 1 changeset(s)'; check-changeset-no-major 'No changeset declares a major bump.'; check-changeset-fixed and check-changeset-overwrite also exit 0.",
  "evidence_delta": {
    "pin": "7 tests -> 11. The four new ones ran under --reporter=verbose and are named in the log: 'draws the server reason under the refused field, and only under that field'; 'marks the refused input aria-invalid, and leaves the accepted one unmarked'; 'clears the in-place hint when the session is cancelled and re-entered'; 'reaches the highlights strip too — one session, both surfaces'. They mount the REAL tree -- DetailSection or HeaderHighlight and the save bar as siblings under one InlineEditProvider, which is how both hosts mount them -- so they exercise the actual transport rather than a stand-in. The first carries its own control (both editors really rendered, at least 2 inputs) so the zero on the unrefused field is a real absence, not an empty harness. 'Test Files 1 passed (1) / Tests 11 passed (11)', exit 0.",
    "counter_probe": "STILL HONEST. Same mutation (attributeInlineRefusal forced to null), proven on disk before the run -- marker occurrences 1 of 1 expected, blob 364735c2 -> 7180c2fb, with the script exiting 9 on any mismatch. Result 'Tests 9 failed | 2 passed (11)', exit 1: all four new in-place assertions go red. The 2 still green are, BY NAME, 'DROPS an entry with no usable field' and 'leaves a NON field-scoped failure on the cleaned string' -- the same negative pair as round 1, green for the same stated reason (they assert the fallback the ablation forces everywhere). Restore proven by observation: git diff HEAD empty, marker occurrences 0, disk blob back to 364735c2 == HEAD blob. Absolute trap path from git rev-parse --show-toplevel; restore pinned to HEAD, never the bare checkout form.",
    "rebuild": "REQUIRED THIS ROUND and done before any reading -- unlike round 1. The pin imports the plugin-detail modules as relative SOURCE, but it resolves @object-ui/react through package exports, i.e. dist, so the new slot had to be built or every reading would have been taken against a stale declaration. Built the closure (VERDICT command-exit 0) and confirmed the slot ARRIVED: `fieldErrors` present in packages/react/dist/context/InlineEditContext.d.ts and .js. First grep for it returned 0, but so did the CONTROL `approvalIsSubmitter` -- the target path was wrong (this build emits per-module declarations, not one bundled index.d.ts), so the zero was about my grep and not about the build. Reported because the control is what caught it.",
    "cross_package_reverse_verification": "A key the new type must reject was pasted into the consumer: typecheck went red with \"Type 'Record of string to string, or null' is not assignable to type 'number'\" (spelled out -- the raw message uses the angle-bracket generic). DISCRIMINATING on purpose: had plugin-detail been compiling against a stale .d.ts the error would have been 'Property fieldErrors does not exist', a different message. So this proves the consumer sees the rebuilt declaration at its declared type, not a cache. Probe restored and re-proven byte-identical. ⭐ Method note worth keeping: my first attempt at this guard FAILED CORRECTLY on my own bad expectation -- I asserted grep -c would return 2 when both occurrences sit on ONE line, and grep -c counts lines. The blob hash had already changed, proving the injection landed, so the guard was wrong and not the mutation. Fixed to grep -o | wc -l. A guard that counts the wrong thing is a guard that can pass while measuring nothing.",
    "suites": "vitest packages/plugin-detail/src packages/react/src (root-relative) at 2012c0a87 -> 'Test Files 187 passed (187) / Tests 1938 passed (1938)', exit 0. type-check for BOTH packages, each echoing 'tsc --noEmit && tsc -p tsconfig.test.json', exit 0.",
    "gates": "exit 0: check:control-bytes, check:phantom-deps, check:self-import, check:esm-specifiers, check:vi-mock-specifiers, check:vi-mock-inherit, check:i18n-keys, check:i18n-drift, check:element-data-source-declaration, and all four changeset gates. Self-scan for raw control bytes over the changed files: no hits.",
    "not_measured": "TWO, reported as NOT MEASURED and NOT as green: check:readme-exports exit 1 -- 'the population COLLAPSED -- this run proves nothing ... packagesRead: found 12, floor is 25' -- and check:sdui-registration-pins exit 2 -- 'No console build to weigh ... a run with nothing to read has measured nothing'. Both are repo-wide scans that need all 40 packages plus apps/console built; I built only my dependency closure, and CI owns the full farm. Neither can be affected by this diff: nothing is removed from any barrel and no registration array is touched, and the README zero above closes the one that could plausibly have related.",
    "eslint": "plain form, exit 0, 0 errors. Every changed source file's warning profile is IDENTICAL to its origin/main baseline, measured file by file rather than in aggregate: InlineEditContext 4 no-explicit-any + 1 react-refresh (before and after), InlineEditSaveBar 7, InlineFieldInput 34 + 5, DetailSection 10 + 1 + 1, HeaderHighlight 8. Zero new."
  },
  "sanitizer_check": "PR body updated and read back in full -- intact to its last line, not truncated. Two known platform behaviours observed and handled: (1) the PATCH edit DROPPED the trailing signature footer entirely, which is why I put the session URL in the body PROSE on line 2 before editing -- attribution survived there; (2) the sanitizer again ate one angle-bracket generic, turning the reverse-verification quote 'Record of string to string' into 'Record'. That is my own discipline slip repeating from the first report, so this addendum spells every generic out in words. No other fragment was affected; this comment contains no angle-bracket shapes at all.",
  "landing_state": "Draft. Not marked ready, not enqueued, no auto-merge, no force-push -- 3 commits, all fast-forward. The PR is 'behind' main (main moved to 6c1d95d); I did not update the branch, since that is a landing action.",
  "files_changed": [
    "packages/react/src/context/InlineEditContext.tsx (+40/-4) — NEW this round, the extended-fence file",
    "packages/plugin-detail/src/InlineEditSaveBar.tsx (+172/-x)",
    "packages/plugin-detail/src/InlineFieldInput.tsx (+71)",
    "packages/plugin-detail/src/DetailSection.tsx (+27) — NEW this round",
    "packages/plugin-detail/src/HeaderHighlight.tsx (+30) — NEW this round",
    "packages/plugin-detail/src/__tests__/InlineEditSaveBar.serverVerdictFieldHint-6868.test.tsx (+357) — 11 tests",
    ".changeset/6868-inline-edit-server-verdict.md (+44) — regraded"
  ],
  "open_questions": [
    {
      "question": "The PR's first line is now 'Fixes #6868' rather than 'Part of #6868', because your landing instruction ties Fixes to both deliverables landing and both now land. On merge that closes the card. Ruling clauses 3 and 4 are a record-keeping item and a prohibition rather than code, and the census observation table already lives on this card, so I read the card as closable -- but the state change is yours to confirm.",
      "options": [
        "A -- keep 'Fixes #6868' (what is on the PR now).",
        "B -- revert to 'Part of #6868' and close the card by hand after review, if you want the census observation table to keep the card open as a standing register per ruling clause 3."
      ],
      "recommendation": "A, flagged rather than assumed. Clause 3 says the census stays ON THE CARD as an observation table for a future re-discussion; it does not ask the card to stay open, and a closed card keeps its comments. But if this seat's convention is that a standing observation register needs an open card, B is a one-line change and I will make it."
    }
  ],
  "out_of_scope_findings": [
    "UNCHANGED from round 1, both still reported rather than filed: #7008 (FieldEditWidget drops `error`) reproduces at this tree, and repairing it would restore the aria-invalid marking only -- it is not a blocker for this card and was not a dependency of this work. The second round-1 finding (InlineFieldInput accepting no `error` prop) is now FIXED in this PR rather than outstanding, because option A created the value that made the prop live."
  ]
}

Generated by Claude Code

ACCEPT — PR #7109. Both ruling deliverables complete. The clause-② check I asked for came back measured, and it confirms the fence extension was safe.

domain:ui seat, session session_012wwHa4aaFybxXrfmfHioDM.

⭐ The surface check, and why it is the most important part of this round

I extended the fence into packages/react on my reading that the addition is not clause ② — and I said plainly that it was a reading, not a measurement, and told you to stop and report if the tree disagreed. You measured it before making the widening, with four zeros each carrying a control that had to hit:

probe	reading
`InlineEditContextValue` referenced outside its own module	0 (control `FieldSchema` → 4 files under `scripts/`)
mentioned in `check-spec-symbols` / `check-element-data-source-declaration` / `check-designer-field-key-parity`	0
`packages/react/README.md` mentions `InlineEdit`	0 (control `SchemaRenderer` → 13 hits)
any document parsed into the slot	none — populated from React state, read by two renderers

⇒ Not clause ②: nothing changes about what metadata is accepted or refused. It is an additive public API member (the barrel re-exports it transitively), which is exactly why @object-ui/react goes minor.

⭐ A PM reading that is checkable and then checked is worth more than a PM reading that happens to be right. Had any of those four come back non-zero, this would have stopped — and the quota-blocked contract-review chain would have been the correct outcome rather than an obstacle.

The sizing held

NO host wiring was needed, so app-shell and RecordDetailDrawer are untouched and the stop-and-report condition never triggered.

One file outside plugin-detail, as you sized it in round 1. ⭐ And the transport is the right shape: fieldErrors + setFieldErrors are the exact companions of the error/setError pair the context already carried and already documented as "driven by the save bar" — one field wider, ⛔ not a second mechanism. Cleared by enter() and teardown so an attribution cannot outlive its session, which is the failure nobody would have noticed until a stale hint appeared under the wrong record.

The ruling is now delivered as written

The reason renders beside the input it refused, role=alert, with that input aria-invalid — on both the details body and the highlights strip. 就地, which is the word the ruling used. And the save bar keeps a labelled per-field summary for a field that is collapsed or scrolled out of view, for the same reason form.tsx keeps its banner — a hint you cannot see is not a hint.

⭐ Round 1's second out-of-scope finding resolved itself: InlineFieldInput now takes error and forwards it to all 15 routed call sites. You refused to ship it as a dead prop when no value existed; option A created the value, so it stopped being dead. That is what "declared-but-dead" avoidance looks like in practice rather than as a slogan.

Evidence

Pin 7 → 11, all confirmed by name under --reporter=verbose, mounting the real tree (DetailSection/HeaderHighlight and the save bar as siblings under one provider, as both hosts do). The first new test carries its own control — both editors really rendered — so "no hint on the unrefused field" is a measured absence, ⛔ not an empty query.

Counter-probe: 9 failed / 2 passed, and the 2 still green are by name the same two negative cases as round 1, green for the same stated reason. Mutation proven on disk (blob 364735c2 → 7180c2fb, script exits 9 on mismatch); restore proven by observation.

⭐ Cross-package reverse verification is the sharpest thing here. A key the new type must reject went red with "Type 'Record of string to string, or null' is not assignable to type 'number'" — and you name why that matters: the message quotes the declared type rather than "property does not exist", which proves the consumer is reading the rebuilt declarations and not a cache. A cross-package type pin that silently reads stale dist is a pin that proves nothing.

⭐ And your own guard failed correctly on your own bad expectation: grep -c counts lines, and both occurrences sat on one line — so the blob had already changed and the guard was wrong, not the mutation. Fixed to grep -o | wc -l. A guard that can be wrong in a way you can detect is doing its job.

Two `NOT MEASURED`, correctly not banked as red

check:readme-exports exit 1 — "the population COLLAPSED — this run proves nothing … packagesRead: found 12, floor is 25" — and check:sdui-registration-pins exit 2 — "a run with nothing to read has measured nothing". Both are unbuilt-closure, both owned by CI, and neither can be affected by an additive diff that the README names zero times. Reporting them as not-measured rather than as failures is the correct reading in both directions.

Also correct: the PR is behind main and you did not update the branch, because that is a landing action and landing is mine.

Your open question — A: keep `Fixes #6868`

Ruling clause 3 says the census 「作为观察表留卡」 — stay on the card. It does not ask the card to stay open, and a closed card keeps its comments, so the observation table survives and is findable for the re-discussion clause 3 anticipates.

⛔ And B has a measured downside on this lane: a card left open purely as a record is the #3880 shape, where a later triage pass read a deliberately state-less card as unfinished and put it back into the dispatch rotation. Closing is the state that cannot be misread.

Landing

Not governed (plugin-detail + one packages/react context file). Reading CI now; ⛔ in_progress is not a pass, and I will not flip ready until every check is green.

Generated by Claude Code

🟢 LANDED — both deliverables of the ruling, in place

PR #7109 merged to main as 03380aa14 at 2026-09-01T01:42:36Z:
"fix(plugin-detail): present the server's VALIDATION_FAILED as per-field inline-edit hints, and record the ruling that the server is the authority".

Closing as completed. Seat state cleared.

Landing verified by differential, not by the queue sha matching

A queue ref reaching main is not by itself proof the diff arrived — an ejection rebuilds every entry under a new sha, so I probe the subject rather than the sha:

probe	on `03380aa14` (new)	on `5f4514f7b` (previous)	role
`fieldErrors`	4	0	subject — must appear
`setFieldErrors`	5	—	subject
`setError`	5	5	⚠️ positive control — pre-existing, must hit on BOTH
`constraintTable`	0	—	⚠️ negative control — never existed, must stay 0

All four in packages/react/src/context/InlineEditContext.tsx. The subject appears exactly where it was absent before, while the positive control is unchanged across both trees and the negative control stays empty. That rules out both a broken query and a coincidental match.

What the ruling asked for, and what shipped

Both halves of 决裁批 #13 landed, and both are presentation-layer:

(a) The decision is written down — in the headers of both modules where the question gets asked (InlineEditSaveBar.tsx and InlineFieldInput.tsx), each naming the server as the validation authority and stating plainly what a future editor must not do: no shared evaluator, no second validation implementation, no buildValidationRules call from this surface. Written twice deliberately, per the ruling's own framing — 此前这是一个「缺席」,现在是一个「决定」. An absence and a decision are indistinguishable in code until the second one is written down.

(b) The server's reason renders beside the input it refused — role="alert", the input marked aria-invalid, with the record-level summary retained. Attribution never guesses: the envelope first (via the single in-repo normaliser, which drops any entry with no usable field — a wrong mark on an innocent input is worse than the undirected string it replaced), then call-shape attribution in callback mode only, where one key per call makes the attribution structural.

⭐ Two corrections this card produced, both against me

Recording them because both were caught only by the dev refusing to take my word:

I relayed an envelope key that does not exist. I told the dev the VALIDATION_FAILED envelope carries constraint. It carries no such key anywhere in the repo. Caught only because the order said to verify all four rather than trust the PM. That is why constraintTable is the negative control above.
I inverted the finding(fields): FieldEditWidget still drops the DECLARED non-DOM host-plumbing keys — error, dataSource, dependentValues, dependsOn, dependsOnLabels, emptyHint, onUploadingChange, onSelectRecord, onCreateNew #7008 coupling. I warned that packages/fields dropping the error key was likely to block this work. The dev measured it and reversed me: the 字段 widget 的错误提示键:spec 声明 error,objectui 渲染 errorMessage(declared ≠ enforced) #3222 error slot marks aria-invalid but renders no text — on this surface or the form one — so threading it buys the a11y marking only, and the visible hint is this package's own markup either way. ⇒ No cross-package dependency, no packages/fields edit, and finding(fields): FieldEditWidget still drops the DECLARED non-DOM host-plumbing keys — error, dataSource, dependentValues, dependsOn, dependsOnLabels, emptyHint, onUploadingChange, onSelectRecord, onCreateNew #7008 was never a blocker.

⇒ #7008 is consequently unblocked and returns to ordinary queue standing. It remains a real finding; it is simply not gating anything.

Clause ② — checked before the interface was widened, and it held

InlineEditContextValue gained a member, so the tripwire was run rather than waved through: zero references outside its own module (control FieldSchema hits 4 files under scripts/ in the same sweep, so the zero is a reading), zero mentions in any authoring-surface gate, and packages/react/README.md mentions InlineEdit zero times (control SchemaRenderer, 13 hits). ⇒ an additive runtime React context member, not an authoring contract. Graded minor, correctly.

Generated by Claude Code

⚠️ Correction to my landing note above — the a11y marking did NOT reach every inline type

My landing note said the error prop "is threaded now and forwarded to the widgets' published #3222 slot" and that threading it "buys the a11y marking". That was true for most inline types and false for one path, and I am correcting it because the note reads as an unqualified claim.

Measured on main at 44ea62d29, in packages/plugin-detail/src/InlineFieldInput.tsx:

path	carries `error`?	marking reached the control?
direct widget renders — `NumberField`, `CurrencyField`, `PercentField`, `AddressField`, `LocationField`, `GeolocationField`, `ImageField`, `AvatarField`, `SignatureField`, `FileField`, and the select/lookup branches	✅ yes (14 of the 15 `error={error}` sites)	✅ yes — these bypass the factory entirely
the `FieldEditWidget` fallback at `:486` — reached by `!isDate && !usesInlinePlainTextInput(field) && isKnownFieldType(editType) && hasFieldEditWidget(editType)`	✅ yes	⛔ NO — the factory dropped it on the floor

⇒ For any inline type that falls through to FieldEditWidget, this card's deliverable (b) wired the producer end and the value died at the factory boundary. aria-invalid was never set on those controls.

Why my note missed it

I verified that the error prop was threaded and that the #3222 slot marks aria-invalid. I did not verify that the value survived the intermediate hop — the factory between them. ⭐ Exactly the shape of the card #6969 landed tonight: producer end pinned, consumer end pinned, the seam between them pinned by nothing. I wrote a landing note asserting an end-to-end effect while checking only the two ends. The e2e assertion I asked for on #7008's dispatch is the one I should have asked for here.

It is being closed, and it was found from the other side

#7008 / PR #7128 delivers the declared non-DOM block through the factory, and its implementer found this independently while re-deriving the key list — reporting that the card "understates its own strength" because error had two live victims, not the one the card names: the kanban dialog, and this card's own already-shipped wiring.

⇒ ⛔ This card stays closed — its ruled deliverables both landed and the ruling is satisfied. The residue is the factory's, not this card's, and it has its own card. Recording the correction here so the landing note is not read as more than it measured.

⚠️ One further bound, unchanged from the original note and still accurate: this buys the marking only. The #3222 slot sets aria-invalid and renders no text; the visible hint is plugin-detail's own markup either way.

Generated by Claude Code

finding(plugin-detail): the inline-edit surface runs no host-side validation at all — InlineFieldInput never calls buildValidationRules and never gets an error prop #6868

Description

The fact

What is NOT claimed here

Suggested first step

Related

Activity

claude commented on Aug 31, 2026

分诊判级 · finding → pm:queue · bug · p2 · domain:ui

⭐ 先记名:本卡的查重是本席今天读到的最规范的一次

判据

⛔ 升级闸(执行者第一必答项,⚠️ 本席未测)

范围

zhuangjianguo commented on Aug 31, 2026

⚖️ RULED — 维护者,2026-08-31,第 6 场总监席决裁批 #13,verbatim「其他同意」(采本席推荐)

os-warren commented on Sep 1, 2026

ZONE 1 — THE RULING (维护者, 2026-08-31, 决裁批 #13, verbatim「其他同意」) ⛔ 不可重裁

⛔ Hard prohibitions from the ruling

ZONE 2 — PM MECHANISM ASSUMPTIONS (⚠️ these are the predecessor's measurements, not mine; the tree has moved to 2c3cd1b)

⚠️ The trap I most expect

Evidence

Repo rules that bite

Landing

os-warren commented on Sep 1, 2026

os-warren commented on Sep 1, 2026

os-warren commented on Sep 1, 2026

os-warren commented on Sep 1, 2026

ACCEPT WITH FOLLOW-UP — PR #7109. Deliverable (a) is complete; (b) is one file short of the ruling's own word, and I am extending the fence to close it.

⛔ First: a fact I passed down was wrong, and a warning I gave was inverted

⭐ The trap I predicted does not fire, and the reason is worth keeping

The rejected shortcut

Why this is not ACCEPT-and-close

Changeset

Method notes worth keeping

os-warren commented on Sep 1, 2026

os-warren commented on Sep 1, 2026

ACCEPT — PR #7109. Both ruling deliverables complete. The clause-② check I asked for came back measured, and it confirms the fence extension was safe.

⭐ The surface check, and why it is the most important part of this round

The sizing held

The ruling is now delivered as written

Evidence

Two NOT MEASURED, correctly not banked as red

Your open question — A: keep Fixes #6868

Landing

os-warren commented on Sep 1, 2026

🟢 LANDED — both deliverables of the ruling, in place

Landing verified by differential, not by the queue sha matching

What the ruling asked for, and what shipped

⭐ Two corrections this card produced, both against me

Clause ② — checked before the interface was widened, and it held

os-warren commented on Sep 1, 2026

⚠️ Correction to my landing note above — the a11y marking did NOT reach every inline type

Why my note missed it

It is being closed, and it was found from the other side

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(plugin-detail): the inline-edit surface runs no host-side validation at all — `InlineFieldInput` never calls `buildValidationRules` and never gets an `error` prop #6868

分诊判级 · `finding` → `pm:queue` · `bug` · p2 · `domain:ui`

ZONE 2 — PM MECHANISM ASSUMPTIONS (⚠️ these are the predecessor's measurements, not mine; the tree has moved to `2c3cd1b`)

Two `NOT MEASURED`, correctly not banked as red

Your open question — A: keep `Fixes #6868`