Repository navigation
Description
π€ 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
- Consumer resolution regressed. The rebase changed which files knip has in its project graph. If a
*.fork.test.tssibling stopped counting as a consumer, every export it alone consumes goes unused at once, which is the shape of this list. - 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:checkexits 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 --checkpasses. - The walk's additive gate is not weakened to reach green.
Activity
donjor-agent commentedon Sep 9, 2026
Correcting the trigger named in the body.
The break is not the
v0.0.41-nightly.20260909.1426rebase. It is thev0.0.41-nightly.20260908.1414rebase, which carried upstreamci(knip): enforce server exports (#10282). That commit added--workspace apps/serverto the secondknip:checkpass, 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.tsimports fromManager.fork-test-harness.tsand 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:
windowIdentityEqualshad no reference at all, including in its own module. It was a dead one-line wrapper overwindowIdentityKey. Deleted.exportkeyword was surplus. Un-exported.Manager.fork-test-harness.tsstays.Manager.fork.test.tsimports five symbols from it, andcreateManagerconstructsFakePtyAdapterin-file.Manager.test.tsdefines its own copies of both fake classes, which is why the harness's pair read as unused.The five
makestatics are not unreachable services. Each module ends inLayer.effect(<Tag>, make)and those layers are wired in production atserver.ts:178,183andmain.ts:166-167. The construction path ismakeβlayerβ provide; noX.makecall 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-metacommit, so its own table edit lands in the bucket it is raising β the fork-meta row moves as part of the same converged edit.[-]knip:check is red on trunk after the 20260909 rebase [β¨#656][/-][+]knip:check is red on trunk after the 20260908 rebase [β¨#656][/+]donjor-agent commentedon Sep 9, 2026
The fix is on #708, and it carries more than this issue asked for.
With the 19 dead exports resolved,
vp run knip:checkpasses in CI β and theCheckjob 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:
Checkis one required status, both causes are pre-existing on clean trunk, and the formatting fix touchesscripts/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 oneFork-Domain, so a branch whose commits span several domains passesvp run fork:delta --checkon the branch and then leavesdocs/internals/fork-budget.mdwrong on trunk. Measured on the original seven-domain branch:So the fix is one commit tagged
Fork-Domain: fork-meta,Fork-Tier: bugfix, matching the trunk precedent for a cross-cutting repair βcfd9465bd5ftouches 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
Bodyuntil its description grew a trailer paragraph..github/pull_request_template.mdcarries that block, but its inline list of validFork-Domainvalues is stale β it names seven of the twelve indocs/internals/fork-delta.md, omittingbrowser-bookmarks,github-issues,thread-ordering,worktrunk-hooks, andworkspace-files. An author copying from the template cannot select five of the fork's own domains.fix(fork): make the required statuses green on clean trunk
fix(fork): make the required statuses green on clean trunk
fix(fork): make the required statuses green on clean trunk
[-]knip:check is red on trunk after the 20260908 rebase [β¨#656][/-][+]knip:check is red on trunk after the 20260908 rebase [β¨#663][/+]fix(fork): make the required statuses green on clean trunk
fix(fork): make the required statuses green on clean trunk
fix(fork): make the required statuses green on clean trunk
fix(fork): make the required statuses green on clean trunk
fix(fork): make the required statuses green on clean trunk