You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
finding(plugin-list,plugin-view): the gantt progress / dependencies floors still fabricate field names at two faces — flavour 3 of #7070, carded per the 2026-09-01 ruling #7499
Split out of #7070 as its flavour 3, which the maintainer ruling of 2026-09-01 (总监批 #28, comment 5494805467) ordered to be carded separately and judged on its own terms. Ruling clause 3, verbatim and untranslated:
The same ruling also records the state transition this card completes: #7070 carries the flavour-2 ①-③ sequence and can close once flavour 3 has its own card. This is that card. Filed unassigned by the seat that landed step ③ (session session_01EMrWaQw3XS5DxTHxp4yRyC); nothing here is dispatched.
Measured, on main at 20cb8db9b — TWO faces, not three
Re-measured by this seat rather than inherited from #7070's table:
The app-shell face carries neither key: ganttViewOptions floors only titleField at 'name'. Control for that zero, fired in the same sweep: the same grep over the same file does return titleField: viewDef?.gantt?.titleField || 'name' at :290.
Control for the other direction, also fired: || 'start_date' / || 'end_date' / the timeline || 'created_at' now count 0 across all three files — the date axes are retired, so what remains is exactly this pair.
Why the date-axis conclusion must NOT be applied here
The ruling forbids it, and the measurement behind the ruling says why. A fabricated date axis is a whole-chart error: the renderer lays every bar on a column nobody declared, and getGanttConfig cannot refuse because a name is always present. A fabricated progress / dependencies name is a per-row missing value: rows simply read undefined for that key and render without a progress fill or a dependency link. Different blast radius, different remedy.
Two facts already pinned that this card should build on rather than re-derive:
getGanttConfig gates on the two date fields alone. Keeping this pair cannot resurrect a config, so ObjectGantt's refusal screen stays reachable with both still handed down — pinned in plugin-gantt/src/ObjectGantt.unconfiguredRefusal-7070.test.tsx.
The pair's presence is pinned as scope at both faces, deliberately, so that whoever retires them has a place to declare it: ListView.gantt-binding-7070.test.tsx ("invents no date binding when only the OTHER gantt keys are declared") and ObjectView.ganttBinding-7070.test.tsx ("keeps the out-of-scope progress / dependencies floors").
The question this card exists to answer
Is a fabricated non-axis field name acceptable when its only consequence is a per-row missing value — or does 日期轴永不虚构 generalise to "no field name is ever fabricated"?
Worth weighing when it is triaged, not decided here:
A silent per-row miss is still a silent miss: an author who spelled the key differently gets bars with no progress fill and no diagnostic, which is the same class of no-signal outcome the date-axis ruling objected to, at a smaller radius.
Against that: unlike a date axis, absent progress and absent dependencies are legitimate, common states. Most gantt rows have neither. A refusal would be wrong here, so the remedy — if any — is "omit the key", not "refuse the chart".
Refs: #7070 (parent card and the ruling) · PR #7110 (flavour 1, gantt date axes) · #7459 / PR #7467 (steps ①②) · #6470 (dependencyField alias) · ADR-0047.
Split out of #7070 as its flavour 3, which the maintainer ruling of 2026-09-01 (总监批 #28, comment 5494805467) ordered to be carded separately and judged on its own terms. Ruling clause 3, verbatim and untranslated:
The same ruling also records the state transition this card completes:
#7070carries the flavour-2 ①-③ sequence and can close once flavour 3 has its own card. This is that card. Filed unassigned by the seat that landed step ③ (sessionsession_01EMrWaQw3XS5DxTHxp4yRyC); nothing here is dispatched.Measured, on
mainat20cb8db9b— TWO faces, not threeRe-measured by this seat rather than inherited from #7070's table:
packages/plugin-list/src/ListView.tsx:2558-2559progressField ... 'progress',dependenciesField ... 'dependencies'packages/plugin-view/src/ObjectView.tsx:1402-1403progressField ... 'progress',dependenciesField ... 'dependencies'The app-shell face carries neither key:
ganttViewOptionsfloors onlytitleFieldat'name'. Control for that zero, fired in the same sweep: the same grep over the same file does returntitleField: viewDef?.gantt?.titleField || 'name'at:290.Control for the other direction, also fired:
|| 'start_date'/|| 'end_date'/ the timeline|| 'created_at'now count 0 across all three files — the date axes are retired, so what remains is exactly this pair.Why the date-axis conclusion must NOT be applied here
The ruling forbids it, and the measurement behind the ruling says why. A fabricated date axis is a whole-chart error: the renderer lays every bar on a column nobody declared, and
getGanttConfigcannot refuse because a name is always present. A fabricatedprogress/dependenciesname is a per-row missing value: rows simply readundefinedfor that key and render without a progress fill or a dependency link. Different blast radius, different remedy.Two facts already pinned that this card should build on rather than re-derive:
getGanttConfiggates on the two date fields alone. Keeping this pair cannot resurrect a config, soObjectGantt's refusal screen stays reachable with both still handed down — pinned inplugin-gantt/src/ObjectGantt.unconfiguredRefusal-7070.test.tsx.ListView.gantt-binding-7070.test.tsx("invents no date binding when only the OTHER gantt keys are declared") andObjectView.ganttBinding-7070.test.tsx("keeps the out-of-scopeprogress/dependenciesfloors").The question this card exists to answer
Is a fabricated non-axis field name acceptable when its only consequence is a per-row missing value — or does 日期轴永不虚构 generalise to "no field name is ever fabricated"?
Worth weighing when it is triaged, not decided here:
dependenciesFieldis not the only spelling in play.dependencyFieldis a declared legacy alias in@object-ui/typeswith no spec counterpart (finding(plugin-gantt,types):dependencyFieldis a declared legacy alias in@object-ui/typeswith no spec counterpart — deprecate in place (removal excluded, deferred to enforce-or-remove) #6470, deprecated in place, removal deferred to enforce-or-remove) — so a decision here should be taken next to that one rather than independently.Refs: #7070 (parent card and the ruling) · PR #7110 (flavour 1, gantt date axes) · #7459 / PR #7467 (steps ①②) · #6470 (
dependencyFieldalias) · ADR-0047.Generated by Claude Code
Generated by Claude Code