Repository navigation
ObjectGantt.tsx: the navConfig comment is duplicated verbatim, two lines for two lines #6258
Description
Noticed while correcting the navigation example in packages/plugin-gantt/README.md (#6050). Out of that card's scope, so filed rather than fixed there.
The fact
packages/plugin-gantt/src/ObjectGantt.tsx:1148-1152 on main (2dc4aa709):
// Default to a right-side drawer so clicking a task opens an editable
// detail panel inline (no full-page navigation). Schema can override by
// providing its own `navigation` config (e.g., page mode).
// detail panel inline (no full-page navigation). Schema can override by
// providing its own `navigation` config (e.g., page mode).
const navConfig = schema.navigation ?? { mode: 'drawer', width: 'min(960px, 60vw)' };The second and third comment lines are repeated verbatim as the fourth and fifth. The first line of the sentence (// Default to a right-side drawer so clicking a task opens an editable) is not repeated, so the duplicate reads as a mid-sentence fragment: the block now says "…providing its own navigation config (e.g., page mode). detail panel inline (no full-page navigation). Schema can override by providing its own navigation config (e.g., page mode)."
Severity
Cosmetic — comments only, no behaviour. Filed because the triage call on how much this class matters is not the implementer's to make at file time, and because the shape (a partial re-paste that leaves a sentence fragment behind) is the kind of thing that survives indefinitely once nobody re-reads the block.
Not in scope of #6050
#6050 is the README's navigation example. This block was read as the consumer evidence for that card — it is where schema.navigation lands — and the duplication was visible while reading it. The README fix touches no source file.
Activity
yinlianghui-tw commentedon Aug 25, 2026
Triage:
finding→pm:queue+domain:ui, Task, S — cosmetic, and folded rather than shrugged at because it is free on the way past: fold directive with #6259 (same file, same five-line block,ObjectGantt.tsx:1148-1152). Branch named for #6259, this card's ownFixesline and its own commit deleting the duplicated fragment. Not worth a standalone dispatch; do not take it alone.Generated by Claude Code
os-support-ai commentedon Aug 25, 2026
Claim: PM loop round R1 (wave 2) — family-dispatch member; chain head is #6259⚠️ #6051 is also open on this file and is deliberately excluded — different defect (
Session:
session_011SfZeFWrhGLHmfq61xbz4qBranch:
claude/issue-6259-gantt-navconfig-size-bucket(shared with the chain head — this card has no branch of its own, by design, ⛔ not a half-state)Worktree:
objectui-issue-6259Domain:
domain:uiFile surface:
packages/plugin-gantt/src/ObjectGantt.tsx— the duplicated comment immediately above thenavConfigdefaultContainer & model:
S(mechanical), dispatched inside the chain head's run,mode:subagent,model: opusClause-②: no — a comment deduplication.
Serial constraints cleared: full check on the chain head (#6259).
getGanttConfigreading 24 undeclared keys), different region; it serialises after this card.Why this is folded rather than queued separately — measured, ⛔ not assumed
I read the region before ruling. On
origin/main@ba306e3,ObjectGantt.tsx:1149-1152is four consecutive lines carrying both cards' defects:⭐ Note what the reading actually shows, because it is not quite what this card says. The card describes it as "duplicated verbatim, two lines for two lines". What is on
mainis a three-line comment whose first line is the second half of the sentence — :1149 is the tail of the sentence that :1150–:1151 then states in full. So the comment is not merely doubled; it is doubled and starts mid-sentence, which is why it reads as incoherent rather than merely redundant.⛔ Do not delete on the card's description — delete on the reading. The correct result is the sentence stated once, in full, in the right order. Confirm the intended sentence is the
:1150-:1151pair before removing:1149.This card's own judge: the duplicated text is gone, appearing exactly once, with no meaning lost. Its own commit on the shared branch, its own
Fixesline on the PR.⛔ Leave the PR draft — the PM lands it.
Generated by Claude Code
os-support-ai commentedon Aug 25, 2026
Dev-agent claim (family member) — separate from the PM claim above.
Session:
session_011SfZeFWrhGLHmfq61xbz4q— I run as theos-devsubagent inside that PM session, so the id matches the PM's by construction rather than being a second seat; this comment is the coding agent's, the one above is the dispatcher's.Branch:
claude/issue-6259-gantt-navconfig-size-bucket(shared with the chain head #6259 — no branch of its own, by design)Worktree:
objectui-issue-6259, baseorigin/main@090927f4fAssignees untouched.
The dispatch told me to delete on the reading rather than on the description, and the reading contradicts the correction, not the card. On
090927f4fthe comment block is five lines,:1147-:1151::1147-:1149already state the sentence completely and in the right order.:1150-:1151are a byte-for-byte repeat of:1148-:1149. That is exactly what this card says — "the second and third comment lines are repeated verbatim as the fourth and fifth; the first line is not repeated".The PM's claim comment describes instead a three-line comment whose first line is a mid-sentence tail, and instructs: "confirm the intended sentence is the
:1150-:1151pair before removing:1149". That reading comes from a four-line window starting at:1149, which cuts off:1147-:1148. Following it literally would have deleted:1149and kept:1150-:1151, leaving:— still duplicated, and now with the sentence broken across the seam. Fix applied: delete
:1150-:1151, keep:1147-:1149.Committed as
21cfe3142; verified by an explicit judge (sentence present exactly once, in full, in order) and ablated — re-inserting the duplicate turns that judge red while all 402 gantt tests stay green, i.e. the suite is not the judge here.Generated by Claude Code
Generated by Claude Code
os-support-ai commentedon Aug 25, 2026
✅ ACCEPT — PR #6305. ⛔ And my claim comment's "correction" of this card was wrong; the card was right.
Reviewer of record:
domain:ui@ objectui execution seat, PM sessionsession_011SfZeFWrhGLHmfq61xbz4q(os-support-ai). Verified against the tree with a control, ⛔ not against the report's self-description.origin/main@090927f4fvs the branchmaincarries the duplicate:1150-:1151are a byte-repeat of:1148-:1149:1147:1147-:1149navConfiguntouched by this legwidth: 'min(960px, 60vw)'Ablation: re-inserting the duplicate pair moved this leg's judge to
VERDICT=FAIL(exit 1) while the gantt suite stayed green 47/402 — ✅ exactly the right shape, and it demonstrates the suite is not the judge here. Mutation proved on disk in both directions plus a blob-hash cross-check (82ede38→22d30b9, the original pre-fix blob), restored undertrap … EXIT INT TERM,git diff HEAD --statempty afterwards.⛔ The correction I owe this card
My claim comment asserted the card's description was "slightly wrong" — that the block was "a three-line comment whose first line is the tail of the sentence", doubled and starting mid-sentence, and told the dev to "confirm the intended sentence is the
:1150-:1151pair before removing:1149".The card was right and I was wrong. "Duplicated verbatim, two lines for two lines" is exactly what is there. My reading came from a four-line window starting at
:1149, which cut off:1147-:1148— the half that makes the sentence complete.:1149and kept:1150-:1151, leaving the comment still duplicated and now broken across the seam — worse than the defect this card exists to fix. What saved it was the other half of the same instruction, "delete on the reading, ⛔ not on the card's description", which the dev correctly applied to my text as well as the card's.⭐ A PM correction is an assertion and needs a control like any other reading. I re-derived a region from too small a window and presented it as authoritative over the filer's own measurement. The card's line numbers were stale — that part was true — but stale numbers do not make a stale description, and I conflated the two.
This card lands with the PR. Its sibling #6259 returned
premise_still_valid: falseon my ruling and is now ruled option A — detail there, ⛔ not repeated here.Generated by Claude Code