docs(workflow-learnings): the "named legacy-id collections are clean" entry was wrong - #3018
Merged
Merged
Conversation
… entry was wrong It hid two real defects, and it told the next reader not to re-probe them. The entry counted DECLARATIONS — 48, then 49 — and concluded the population was benign because each declaration is a fallback vocabulary, a builtin column list, or an already-converted seam. All true of the declarations. The declaration is not where the defect lives. Measure the USE: a collection used as a MEMBERSHIP GATE against a column. Nine of those exist, and two were live user-visible defects — `TIME_INDICATOR_COLUMNS` in TaskCard (the elapsed-time indicator never rendered on a renamed board) and `PLANNER_ACTIVITY_COLUMN_IDS` in useTasks (the planning border and pulsing badge never appeared). Both sat inside a population this document had marked clean. Records the seven that are genuinely fine with the reason for each, because those are the shapes to recognise, and the one question that separates the groups: does a flags path exist in this file at all? Both defects had none — the gate was the only decision, with nothing to degrade from. A "do not re-probe" note that is wrong is worse than no note: it converts one person's incomplete measurement into everybody's blind spot. Same failure this document already records for `sortTasksForDisplayColumn`, one level up — there an annotation told readers to skip a ROW, here it told them to skip a POPULATION. Docs only. No code, no baselines. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
Warning Review limit reached
Next review available in: 44 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
gsxdsm
added a commit
that referenced
this pull request
Jul 31, 2026
… it decays like a measurement (#3026) Two pieces of work were filed rather than fixed in one session, each with a specific technical reason. **Both reasons were wrong**, and in both cases the real obstacle was smaller than the stated one. | filed rationale | reality | |---|---| | "the plugin has no scaffolding for faking its stores" (#3020) | `_harness.ts` builds a real `PluginContext` over a live PostgreSQL layer; the gap was **two missing readers on a stub** — fixed in #3022 | | "supplying this needs a published-API change" (#3003) | the type is dashboard-internal, `@fusion/plugin-sdk` is `private: true`; the actual obstacle is stale type declarations between two in-repo packages | The first one matters most: the filed issue was a **pipeline that stalls forever** on a renamed board. The cost of that excuse would have been a real stall sitting open behind a plausible-sounding note. ## The shape Both times the blocker was asserted **from the shape of the problem** rather than tested. *"This needs infrastructure that doesn't exist"* and *"this crosses a published boundary"* are each checkable in about five minutes, and neither was checked before I wrote a paragraph explaining why the work couldn't proceed. ## Why it's worth writing down Filing is often right — someone else owns the contract, the fix needs a decision, the data genuinely isn't there. What makes it wrong is filing on an **untested** blocker, because a filed issue with a confident rationale is the one thing nobody re-derives. It reads as settled. That's the same mechanism as a stale "do not re-probe" note (which this document already records, and which I had to correct in #3018), one level up: there a *measurement* went stale, here a *decision* did. ## The rule **Before writing the blocker down, spend five minutes trying to hit it.** If it's real you'll hit it immediately and can describe it precisely — which makes the issue more useful. If it isn't, you have the fix instead of the issue. Docs only. No code, no baselines. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
gsxdsm
added a commit
that referenced
this pull request
Jul 31, 2026
…d is wired (#3037) The gate reports this itself: ``` [check-inert-flag-seams] STALE allow-list entries — supplied now, or no longer declared: plugins/fusion-plugin-dependency-graph/src/GraphTaskNode.tsx::isTaskStuck — no unsupplied call site remains; remove its ALLOWED_OMISSIONS entry ``` #3029 wired that call site. The entry now claims to tolerate something that doesn't exist. The gate **warns rather than fails** here by design — failing would punish whoever fixed the seam — which is precisely why a stale entry has to be deleted deliberately instead of waiting for a red build to force it. ## The text is worth losing on its own account That exemption justified the omission as needing *"a published-API change."* I later revised it to *"build plumbing."* **Both were wrong**: the blocker was a hand-maintained interop declaration frozen at the pre-conversion three-argument signature (#3003 → #3029). An exemption whose stated reason has been disproven twice is worse than no exemption — it's a confident note that stops anyone re-deriving the answer. Same failure mode as the stale "do not re-probe" doc entry corrected in #3018, and the untested deferral rationales recorded in #3026. ## Measured | check | result | |---|---| | inert-seam gate | **23 seams, all supplied**, exit 0 **with no waiver** | | gate's own suite | 18/18 | | lane-wiring · plugin-interop-drift · FNXC | green; lint clean | <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved validation of task status handling by removing an exception that could allow an incomplete call site to go undetected. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
It hid two real defects — and it explicitly told the next reader not to re-probe them.
What the entry did
Counted declarations (48, then 49) and concluded the population was benign because each one is a fallback vocabulary, a builtin column list, or an already-converted seam.
All true of the declarations. The declaration isn't where the defect lives.
Measure the use, not the declaration
A collection used as a membership gate against a column. Nine exist, and two were live user-visible defects sitting inside a population this doc had marked clean:
TIME_INDICATOR_COLUMNS.has(task.column)—TaskCardPLANNER_ACTIVITY_COLUMN_IDS.has(task.column)—useTasksThe other seven are genuinely fine, and the reasons are kept because they're the shapes worth recognising: the no-flags fallback inside a role helper, a seam that seeds the legacy pair then unions resolved lanes, a marked
DELIBERATE-LITERALfallback chain, and a plugin with no trait source at all.The tell
One question separates the two groups: does a flags path exist in this file at all?
Both defects had none — the gate was the only decision, with nothing to degrade from. Every benign case had a resolved path sitting right next to the literal.
Why this is worth its own PR
A "do not re-probe" note that is wrong is worse than no note: it converts one person's incomplete measurement into everybody's blind spot. That's the same failure this document already records for
sortTasksForDisplayColumn, one level up — there an annotation told readers to skip a row, here it told them to skip a population.I wrote the original entry, and I'd read past it twice myself before #3014 forced the re-measurement.
Docs only. No code, no baselines.