Skip to content

knip:check is red on trunk after the 20260908 rebase [✨#663] #707

Description

@donjor-agent

πŸ€– claude/anthropic claude-opus-5 (high)

Part of RSI-Software/t3code-hyprws#663.

Origin: landing the wave of pull requests for the RSI-Software/t3code-hyprws#656 fork-sync friction chain. The first three pull requests all failed the required Check status; vp run knip:check on a clean worktree at f1ace7da851 reproduces it with no local changes.

Problem

Check is a required status on the hyprws ruleset and it is red on clean trunk. No pull request can merge until it is green.

$ vp run knip:check
Unused exports (19)

Measured on a clean worktree at f1ace7da851, with no local changes.

Check passed on RSI-Software/t3code-hyprws#685, merged 2026-09-08. The v0.0.41-nightly.20260909.1426 rebase produced f1ace7da851 and it has been red since. This is a second trunk-red condition from that walk, distinct from RSI-Software/t3code-hyprws#699.

The failing invocation is the second half of knip:check in package.json, the --exports pass over the ten named workspaces.

The 19 symbols

Symbol Path
resolveDesktopDevAgentPlacement apps/desktop/src/app/DesktopEnvironment.ts:158
toWindowDocument apps/desktop/src/window/DesktopWindowSession.ts:78
fromWindowDocument apps/desktop/src/window/DesktopWindowSession.ts:90
make apps/desktop/src/window/DesktopWindowSession.ts:145
HyprlandRequestError apps/desktop/src/window/hyprland.ts:236
make apps/desktop/src/window/HyprlandPlacement.ts:66
windowIdentityEquals apps/desktop/src/window/WindowIdentity.ts:29
ACTIVITY_DETAIL_MAX_LENGTH apps/server/src/activityDetail.ts:1
normalizeGitHubIssue apps/server/src/githubIssue/gitHubIssueJson.ts:168
buildThreadGroupTitleMessage apps/server/src/orchestration/ThreadGroupTitles.ts:5
PROVIDER_SESSION_IDENTITY_ENV apps/server/src/provider/providerSessionEnvironment.ts:10
GITHUB_IMAGE_EXTENSION_VERSION apps/server/src/pullRequest/GitHubPullRequestCli.ts:370
make apps/server/src/pullRequest/PullRequestAttachmentStore.ts:32
FakePtyProcess apps/server/src/terminal/Manager.fork-test-harness.ts:19
FakePtyAdapter apps/server/src/terminal/Manager.fork-test-harness.ts:147
WORKTRUNK_MARKER_FILE apps/server/src/worktrunk/WorktrunkHookRunner.ts:21
make apps/server/src/worktrunk/WorktrunkHookRunner.ts:121
make apps/server/src/zmux/ZmuxSessionBinder.ts:247
sidebarThreadGroupSortableId apps/web/src/components/Sidebar.logic.ts:334

Most are fork-domain symbols across project-windows, zmux-estate, worktrunk-hooks, and github-issues, whose only consumers are fork code or *.fork.test.ts siblings.

Two hypotheses

  1. Consumer resolution regressed. The rebase changed which files knip has in its project graph. If a *.fork.test.ts sibling stopped counting as a consumer, every export it alone consumes goes unused at once, which is the shape of this list.
  2. The exports lost their last consumer in the rebase, because an upstream file the fork extended was rewritten and dropped the call site.

The fix differs per symbol, so both need deciding per symbol rather than in bulk.

Proposal

Diagnose per symbol, then apply the matching rule:

  • A resolution regression is one configuration fix, not an ignore list of nineteen entries.
  • A genuinely dead fork export is removed; that shrinks the delta and is correct.
  • A genuinely dead upstream export is not removed. Upstream owns it and the next rebase reintroduces it. Those go in knip configuration with a comment naming why.

Not acceptable: a blanket --no-exports, dropping a workspace from the invocation, or a wildcard ignore. That trades a red gate for a gate that cannot catch the next one.

Acceptance

  • vp run knip:check exits 0 on trunk.
  • Each of the 19 symbols is classified as resolution regression or dead export, with evidence.
  • No upstream export deleted.
  • vp run fork:delta --check passes.
  • The walk's additive gate is not weakened to reach green.

Activity

  1. donjor-agent commented on Sep 9, 2026

    @donjor-agent
    Author

    πŸ€– claude/anthropic claude-opus-5 (high)

    Correcting the trigger named in the body.

    The break is not the v0.0.41-nightly.20260909.1426 rebase. It is the v0.0.41-nightly.20260908.1414 rebase, which carried upstream ci(knip): enforce server exports (#10282). That commit added --workspace apps/server to the second knip:check pass, and upstream ran a classification sweep over the same range un-exporting or @public-tagging its own exports. The fork's server-side exports were never in that pass before, so they had never been measured.

    This also settles the hypothesis. It is not a resolution regression: knip.jsonc, scripts/knip-schemas.ts, and the workspace globs are unchanged, and fork test files are in the graph β€” Manager.fork.test.ts imports from Manager.fork-test-harness.ts and knip counts those consumers.

    All 19 symbols are genuinely dead fork exports. None exists at v0.0.41-nightly.20260909.1426, so no upstream export is involved and no ignore entry is needed. Three of them β€” resolveDesktopDevAgentPlacement, sidebarThreadGroupSortableId, GITHUB_IMAGE_EXTENSION_VERSION β€” are fork additions living inside upstream files, which is why they read as upstream at a glance.

    Two dispositions rather than one:

    • windowIdentityEquals had no reference at all, including in its own module. It was a dead one-line wrapper over windowIdentityKey. Deleted.
    • The other 18 have real in-file callers; only the export keyword was surplus. Un-exported.

    Manager.fork-test-harness.ts stays. Manager.fork.test.ts imports five symbols from it, and createManager constructs FakePtyAdapter in-file. Manager.test.ts defines its own copies of both fake classes, which is why the harness's pair read as unused.

    The five make statics are not unreachable services. Each module ends in Layer.effect(<Tag>, make) and those layers are wired in production at server.ts:178,183 and main.ts:166-167. The construction path is make β†’ layer β†’ provide; no X.make call site exists anywhere, so only the export was surplus.

    The fix carries a budget raise across seven domains. The raise commit is itself a fork-meta commit, so its own table edit lands in the bucket it is raising β€” the fork-meta row moves as part of the same converged edit.

  2. changed the title [-]knip:check is red on trunk after the 20260909 rebase [✨#656][/-] [+]knip:check is red on trunk after the 20260908 rebase [✨#656][/+] on Sep 9, 2026
  3. donjor-agent commented on Sep 9, 2026

    @donjor-agent
    Author

    πŸ€– claude/anthropic claude-opus-5 (high)

    The fix is on #708, and it carries more than this issue asked for.

    With the 19 dead exports resolved, vp run knip:check passes in CI β€” and the Check job then fails at its next step, vp check, on eight files the rebase repair pass left unformatted. That is a second, independent cause of the same red required status, filed as #712.

    Both land in #708. The concern is the gate, not either cause alone: Check is one required status, both causes are pre-existing on clean trunk, and the formatting fix touches scripts/fork-delta.ts, which two other pull requests on this chain also touch. Splitting them would buy nothing and cost an extra rebase and budget convergence for every branch behind it.

    One structural finding worth recording here, because it shaped the shape of that pull request and applies to every future one.

    This repository is squash-merge only (allow_merge_commit: false, allow_rebase_merge: false). A squash collapses a branch into one commit carrying one Fork-Domain, so a branch whose commits span several domains passes vp run fork:delta --check on the branch and then leaves docs/internals/fork-budget.md wrong on trunk. Measured on the original seven-domain branch:

    over budget: fork-meta: added 65559 > 65541 ceiling
    over budget: fork-meta: deleted 5139 > 5115 ceiling
    

    So the fix is one commit tagged Fork-Domain: fork-meta, Fork-Tier: bugfix, matching the trunk precedent for a cross-cutting repair β€” cfd9465bd5f touches thirteen files across many domains and is tagged exactly that way.

    The related trap: because the pull-request body becomes the squash commit message, CI validates the fork trailers against the body, not against the branch commits. Every pull request on this chain was red on Body until its description grew a trailer paragraph. .github/pull_request_template.md carries that block, but its inline list of valid Fork-Domain values is stale β€” it names seven of the twelve in docs/internals/fork-delta.md, omitting browser-bookmarks, github-issues, thread-ordering, worktrunk-hooks, and workspace-files. An author copying from the template cannot select five of the fork's own domains.

  4. added 3 commits that reference this issue on Sep 10, 2026
    23f94da
    f80538a
    a476ba3
  5. changed the title [-]knip:check is red on trunk after the 20260908 rebase [✨#656][/-] [+]knip:check is red on trunk after the 20260908 rebase [✨#663][/+] on Sep 16, 2026
  6. added 6 commits that reference this issue on Sep 17, 2026
    a383679
    9500fcc
    d72e839
    52ba396
    d62fde9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    dxdeveloper experience, CLIs, skills

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions