Skip to content

Published skill objectui/guides/page-builder.md presents six GanttConfig keys as top-level siblings of the gantt block — beside a block they are read by nothing #6508

Description

@os-support-ai

Measured while implementing the precedence flip in objectui#6469. Filed
unassigned and severed from that PR, whose file face is plugin-gantt +
packages/types — this is a skills/** defect and skills/** carries its own
net-line budget and the maintainer's 2026-08-21 ruling on published skills.

The fact

skills/objectui/guides/page-builder.md has a table headed:

Top-level display / behavior options (siblings of gantt on props, not
field mappings)

Six of its rows are not node-level options. They are GanttConfig members,
and ObjectGantt reads them only off the resolved gantt config:

KeyRead site (packages/plugin-gantt/src/ObjectGantt.tsx)
resourceViewganttConfig?.resourceView
assigneeFieldganttConfig?.assigneeField
effortFieldganttConfig?.effortField
capacityganttConfig.capacity
quickFiltersganttConfig?.quickFilters
autoZoomToFilterganttConfig?.autoZoomToFilter

getGanttConfig resolves that config from one face. When the node carries a
gantt block, the config is the block — so a sibling top-level
quickFilters is read by nothing.

The guide's own worked example is exactly that shape: a gantt block, plus
top-level quickFilters and autoZoomToFilter. Those two keys do nothing on
that node.

By contrast the rows that genuinely are node-level — criticalPath,
showBaselines, skipWeekends, holidays, readOnly — are read straight off
the schema (schema.criticalPath, schema.skipWeekends, schema.readOnly, …)
and are correct where they sit. The table mixes the two populations under one
heading.

The last row makes the inversion explicit — "Also usable as field mappings under
gantt" — which is backwards: under gantt is where they work whenever a
block is present.

This predates objectui#6469 and is not caused by it

With a gantt block and no top-level startDateField/endDateField pair, this
node took the block branch before the flip too, so the hoisted keys were
already inert. What objectui#6469 changes is that they stop being inert
silently: the new dev-mode warning names them —

[ObjectGantt] The `gantt` block configures this chart, so these top-level keys
are IGNORED: `quickFilters`, `autoZoomToFilter`. …

That shape is pinned by ObjectGantt.blockPrecedence.test.tsx
("names GanttConfig keys hoisted beside a block, with no top-level date pair"),
so the measurement stays green against drift.

What a fix has to be careful about

The sentence "The gantt field config may also be hoisted to top-level props
instead of nesting under gantt" is true — "instead of" is doing real work,
and hoisting is how ObjectView / ListView emit gantt nodes. The defect is the
table presenting the same keys as siblings of a block. A correction most
likely moves rows rather than adding prose, which matters because published
skills are budgeted: "对外发布的 skills 是整个平台的最大价值……不能为了一个小功能扩写很多"
(maintainer, 2026-08-21).

Scope limit of this measurement

In-repo only. This says what the published guide teaches and what this tree's
renderer reads; it cannot see metadata authored outside this repo against that
guidance.

Related: objectui#6469 (the precedence flip that surfaced it), objectui#6051
(declared the flat face), objectui#5018 / PR #5156 (the inherited map ruling).
Same family as objectui#6006 / objectui#5947 / objectui#5473 — published-skill
guidance that does not match what the code reads.

Generated by Claude Code

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions