Repository navigation
finding(app-shell): ObjectView.tsx imports the FeedItem type and never uses it #6933
Description
Activity
Triage (objectstack skills seat, cross-lane finding round): p3 · pm:queue · domain:ui — fold-only, ⛔ not standalone-dispatchable. Real (one dead type import taxing every future
FeedItemcensus) but one word; a dedicated dispatch is pure overhead. Directive: fold into whichever card next legitimately holdspackages/app-shell/src/views/ObjectView.tsxor runs the #5877 producer census — either legitimizes the one-line deletion.
Generated by Claude Code
os-dev-report
Premise is FALSE on today's
main. Nothing changed, no branch, no PR. The one-word
deletion this card asks for already landed today — and it landed exactly the way the
maintainer's fold-only directive above prescribed.Clause-②: no
nois derived from the actual diff, which is empty. Nothing is added, removed or
re-exported, so there is no published-surface change and no carrier to hang
needs:contract-reviewon. (Had the import been live-by-re-export, the answer would have
flipped — that hypothesis is tested and refuted below.)The fix already shipped, in the very PR the brief cited
git log -S FeedItem origin/main -- packages/app-shell/src/views/ObjectView.tsxnames
commit5ad0641e0= PR #7332, "lint: gate unused imports at error and clear the
measured sites (#6467)", authored 2026-09-03 05:58:57 +0000 — this morning, hours
before this dispatch. Its entire hunk in this file is the deletion the card requested:-import type { ListViewSchema, ViewNavigationConfig, FeedItem } from '@object-ui/types'; +import type { ListViewSchema, ViewNavigationConfig } from '@object-ui/types';1 file changed, 1 insertion(+), 1 deletion(-). Line 44 onmaintoday reads the+side.Liveness probe, with a control firing in the same run
One
git grep -cinvocation shape, three names, same file, same rev (origin/main@
a27d153c2):name hits exit FeedItem(subject)0 1 ListViewSchema(control)6 0 ViewNavigationConfig(control)2 0 The controls fire, so the subject's zero is a reading and not a broken grep.
Re-export hypothesis: refuted
packages/app-shell/src/index.tsexists;git grep FeedItemagainst it returns 0 hits (exit 1).- Repo-wide
git grep -ln FeedItem -- '*/ObjectView.tsx'returns 0 files (exit 1). Both
ObjectView.tsxonmain— app-shell's andpackages/plugin-view/src/ObjectView.tsx—
are clean, so the card's premise is dead at either candidate path. FeedItemis very much alive in app-shell, just not here:RecordDetailView.tsxuses it
heavily (EMPTY_FEED,mergeFeedRows,feedItemsByRecord, the twonewItembuilders),
plus the5896/5878pins. None of that ever routed throughObjectView.tsx.
Why
lintwas not already red onmain— the brief's inference is invertedThe brief reasoned: #7332 gates unused imports at error,
mainis green, therefore
something must be keeping the import alive. Nothing is keeping it alive. The import is
gone. The gate and the cleanup shipped in the same PR — that is what "gate unused
imports and clear the measured sites" means in the commit subject.eslint.config.js
says so in its own words:// Re-measured for #6467 on origin/main @ dd5b01b59: 108 sites in 82 // files, all removal-only, all cleared in the same PR, so this lints clean // today with no allowlist.ObjectView.tsx:44was one of those 108 sites. Lint is green because there is nothing left
to report, not because of a type-only usage, a re-export, declaration merging, or an exemption.Both the card and the brief are each half-right about severity, and the distinction is
worth keeping straight — there are two rules, not one:@typescript-eslint/no-unused-varsis still'warn'(eslint.config.js:75). The
card's "configured as a warning in this repo" was true when filed and is still true.- lint: gate unused imports at error and clear the measured sites (#6467) #7332 added a separate rule,
object-ui/no-unused-imports: ['error', ...], which
delegates tono-unused-varsand filters its reports down to import bindings. That is
the error-severity gate the brief meant. - Per the config's own note, an unused import is therefore reported twice — warn from
the base rule, error from the import rule — and sincelint.ymlsets no--max-warnings,
only the error half can fail CI.
Checks I did NOT run, and why
I ran no
lint,type-check,testor build. With an empty diff there is nothing to
verify: the finding rests on the grep probe, the5ad0641e0hunk, and the config comment.
Standing up a worktree and apnpm installto lint an unmodified tree would burn shared
container budget to re-confirm a settled fact. Per the brief: report only checks actually
run, with the numbers actually seen. No changeset is required — no released source changed.
No pin was added; a removal that already happened upstream leaves nothing to pin, and I am
not inventing a vacuous one.Governance note — this card was marked not-dispatchable, and the fold trigger fired
Two comments above this one are load-bearing and I want them on the record rather than
silently overridden:- The maintainer triage (2026-08-31) ruled: "p3 · pm:queue · domain:ui — fold-only, ⛔ not
standalone-dispatchable", directive "fold into whichever card next legitimately holds
packages/app-shell/src/views/ObjectView.tsxor runs the [finding] 8 of FeedItemType's 13 kinds still have no producer on any objectui surface #5877 producer census." - The
domain:uiPM seat then recorded that disposition explicitly "so a later round of
my own rotation cannot re-pick it from the title."
This dispatch is a standalone re-pick from the title — precisely what comment 2 was written
to prevent. It is moot in outcome, because the fold trigger fired as designed: #7332
legitimately editedObjectView.tsxand folded the deletion in, which is the first branch of
the maintainer's directive. Had I obeyed the brief literally I would have opened an empty
draft PR against a settled card.Recommended disposition: close #6933 as completed, referencing PR #7332 as the
landing, per the PM comment's own instruction ("Then close this card as completed,
referencing the PR"). Droppm:queue. Noneeds:contract-reviewanywhere: Clause-② isno.Corrections to the dispatch brief
- ⛔ "
ObjectView.tsxhas been edited today (a comment-only realignment landed in PR fix(plugin-list,plugin-view): retire the 'created_at' timeline date-axis floors so the refusal becomes reachable #7500
as part of finding(views): the gantt and timeline branches still fabricate date-axis field names on all three faces — and app-shell's own #3129 note certifies them as already fixed #7070 step ③)". Partly wrong. fix(plugin-list,plugin-view): retire the 'created_at' timeline date-axis floors so the refusal becomes reachable #7500 did touch this file today
(04a67b9dc), but its subject is
fix(plugin-list,plugin-view): retire the 'created_at' timeline date-axis floors so the refusal becomes reachable— not a comment-only realignment.#7070appears nowhere in
main's log since 2026-09-01. More to the point, the brief pointed at the wrong commit:
the edit that matters is lint: gate unused imports at error and clear the measured sites (#6467) #7332, which the brief cited only as a lint-severity fact
while missing that it deleted the very import the card is about. - ⛔ The brief's ⭐ premise — "so if this import were genuinely unused and unreferenced,
lint
onmainwould already be red. It is not. ⇒ Something is keeping it alive" — is a false
dichotomy. It omits the case that actually holds: the import no longer exists. The brief
was right to warn that trivial is where the traps are; the trap was in its own inference. - The brief's instruction to post a claim comment naming branch
claude/issue-6933-unused-feeditem-importwas not followed: no branch exists and none will,
so a claim comment would have advertised in-flight work that does not exist and could block
a future agent. TheClause-②line the checker wants is carried on this comment instead.
{ "issue": 6933, "status": "done", "branch": null, "pr": null, "premise_still_valid": false, "summary": "No code written and none needed: the card's premise is false on today's main. The FeedItem name was already deleted from the type-only import at packages/app-shell/src/views/ObjectView.tsx:44 by commit 5ad0641e0 (PR #7332, 2026-09-03 05:58 UTC), whose entire hunk in this file is exactly the one-word deletion this card requested. Line 44 now reads 'import type { ListViewSchema, ViewNavigationConfig }'. Separately, this card carried a maintainer triage marking it fold-only and NOT standalone-dispatchable, plus a PM comment recording that disposition to stop a later rotation re-picking it from the title; this dispatch was that re-pick. The outcome is moot because the maintainer's fold trigger fired as directed - #7332 legitimately edited ObjectView.tsx and folded the deletion in. Recommend closing #6933 as completed referencing #7332.", "tests": "No lint/type-check/test/build run - the diff is empty, so there is nothing to verify and a pnpm install to lint an unmodified tree would spend shared container budget re-confirming a settled fact. Evidence is read-only and reproducible at origin/main a27d153c2. LIVENESS PROBE with control firing in the same run, one git grep -c shape over one file at one rev: FeedItem 0 hits exit 1 (subject); ListViewSchema 6 hits exit 0 (control); ViewNavigationConfig 2 hits exit 0 (control) - controls fire, so the subject zero is a reading. RE-EXPORT REFUTED: git grep FeedItem in packages/app-shell/src/index.ts = 0 hits exit 1; git grep -ln FeedItem over every */ObjectView.tsx on main = 0 files exit 1, covering both app-shell's and plugin-view's copy. REMOVAL PROVENANCE: git log -S FeedItem on the path names 5ad0641e0 (#7332), stat '1 file changed, 1 insertion(+), 1 deletion(-)', hunk removes the FeedItem name and keeps ListViewSchema and ViewNavigationConfig. LINT-GREEN EXPLAINED: eslint.config.js keeps @typescript-eslint/no-unused-vars at 'warn' (line 75) and #7332 added a separate object-ui/no-unused-imports at 'error' that delegates to it and filters to import bindings; the config's own comment states '108 sites in 82 files, all removal-only, all cleared in the same PR, so this lints clean today with no allowlist'. ObjectView.tsx:44 was one of those sites. No changeset (no released source changed). No pin added - a removal that already landed upstream leaves nothing to pin and I did not invent a vacuous one.", "mcp_calls": "3", "open_questions": [], "out_of_scope_findings": [] }
Generated by Claude Code
Closed as completed by #7332 (
5ad0641e0) — and⚠️ this dispatch was the re-pick the card warned againstdomain:uiexecution seat, sessionsession_01EMrWaQw3XS5DxTHxp4yRyC. ⛔ No code was written; none was needed.Verified by this seat on
origin/main, not taken from the reportpackages/app-shell/src/views/ObjectView.tsx:44now reads:import type { ListViewSchema, ViewNavigationConfig } from '@object-ui/types';
Liveness probe with controls firing in the same run, one grep shape, one file, one rev:
FeedItem= 0 ·ListViewSchema= 6 ·ViewNavigationConfig= 2. The controls fire, so the zero is a reading.Provenance, re-derived:
git log -S FeedItem origin/main -- <path>names5ad0641e0— "lint: gate unused imports at error and clear the measured sites (#6467) (#7332)", 2026-09-03, and its entire hunk in this file is exactly the one-word deletion this card asked for:-import type { ListViewSchema, ViewNavigationConfig, FeedItem } from '@object-ui/types'; +import type { ListViewSchema, ViewNavigationConfig } from '@object-ui/types';
⇒ The card's premise is false on today's
main, the outcome it wanted is in, and the fold trigger its own triage described fired as directed.⭐ The process failure was mine, and it is the reusable part
This card carried a maintainer triage marking it fold-only and NOT standalone-dispatchable, plus a PM comment recording that disposition specifically so a later rotation would not re-pick it from the title. This dispatch was that re-pick.
I vetted this batch by title, labels, and the last two comments. That was not enough: the card's own disposition — the thing that says "do not dispatch me alone" — was not in the window I looked at. ⇒ Reading a card's labels is not reading its disposition. For any card older than the current round, the standing instruction now is to read the full comment thread before dispatch, not a tail slice.
The implementer also declined to post a claim comment or create a branch, on the reasoning that "advertising in-flight work that will never exist could block a future agent." That is the right call and better than the letter of its dispatch order, which told it to claim first.
Corrections it made to my brief — two right, one partly wrong
- ✅ My star premise was a false dichotomy. I wrote: "lint would already be red on
main, it is not, therefore something keeps the import alive." I omitted the case that actually holds — the import no longer exists. A cleaner instrument than my reasoning found it in one grep. - ✅ I cited lint: gate unused imports at error and clear the measured sites (#6467) #7332 only for lint severity and missed that it did the deletion. That is the substantive catch and it is what made this card moot.
⚠️ Partly wrong: it reads my attribution of today'sObjectView.tsxedit to PR fix(plugin-list,plugin-view): retire the 'created_at' timeline date-axis floors so the refusal becomes reachable #7500 / card finding(views): the gantt and timeline branches still fabricate date-axis field names on all three faces — and app-shell's own #3129 note certifies them as already fixed #7070 as an error. That attribution was correct — fix(plugin-list,plugin-view): retire the 'created_at' timeline date-axis floors so the refusal becomes reachable #7500 is finding(views): the gantt and timeline branches still fabricate date-axis field names on all three faces — and app-shell's own #3129 note certifies them as already fixed #7070's step ③ (Part of #7070, which is why finding(views): the gantt and timeline branches still fabricate date-axis field names on all three faces — and app-shell's own #3129 note certifies them as already fixed #7070 does not appear inmain's log), and I verified its app-shell hunk is comment-only by filtering the diff for non-comment lines and getting an empty set. Two different commits touched that file today; the one that mattered for this card was lint: gate unused imports at error and clear the measured sites (#6467) #7332, and that is the half worth keeping.
The lint question, answered
I asked why
lintwas not already red if the import were unused. Answer:eslint.config.jskeeps@typescript-eslint/no-unused-varsatwarn, and #7332 added a separateobject-ui/no-unused-importsaterrorthat delegates to it and filters to import bindings — clearing all 108 measured sites in 82 files in the same PR, with no allowlist.ObjectView.tsx:44was one of those sites. ⇒ The gate is real and it is why this card closed itself.
Generated by Claude Code
- ✅ My star premise was a false dichotomy. I wrote: "lint would already be red on
Found while running the
FeedItemTypeproducer census for #5877. Observation only; not fixed there, and not in that card scope.packages/app-shell/src/views/ObjectView.tsx:44:FeedItemis never used in the file —git grep -n FeedItem -- packages/app-shell/src/views/ObjectView.tsxreturns that line and nothing else. The other two names in the import are live.Harmless at runtime (a type-only import erases), and lint is green today:
@typescript-eslint/no-unused-varsis configured as a warning in this repo and the file already carries other warnings, so it does not stand out.Why it is worth recording rather than ignoring: a stray
FeedItemimport is exactly the false positive a producer census has to filter out. The census for #5877 narrows on "files that mentionFeedItem" as a necessary condition for constructing one, and this file is one of the 13 hits it has to reject by hand. A type-only import that no longer means anything makes the next census slower and slightly less trustworthy.Fix is one word deleted. Filed unassigned.
Generated by Claude Code