[Vidhaankhare16]

On Windows, the editor breadcrumb in the bottom bar shows the file's whole absolute path as one
segment, C:\Users\dev\repo\src\main\App.kt, instead of src › main › App.kt.

Defect

BossLeftBottomBar builds the breadcrumb for an EditorTabInfo inline:

val projectRoot =
    currentProject.path.let {
        if (it.endsWith("/")) it else "$it/"
    }
val relativePath = activeTab.filePath.removePrefix(projectRoot)
val pathParts = relativePath.split("/")

On Windows both inputs are native paths:

• Project.path comes from File.absolutePath: Open Project on Windows is a JFileChooser
  in DesktopFilePicker.rememberDirectoryPicker (selectedFile?.absolutePath), and
  DesktopProjectCreationService uses projectDir.absolutePath. So it is C:\Users\dev\repo.
• A file opened from Spotlight arrives as IndexedFile.path = child.absolutePath →
  FileResult.path → onFileSelect → FileEventBus.openFile, so the tab's filePath is
  C:\Users\dev\repo\src\main\App.kt.

projectRoot becomes C:\Users\dev\repo/. That string never occurs in the file path, so
removePrefix is a no-op. split("/") then finds no separator and returns the whole absolute path
as the only segment, rendered as a single button with no arrows.

A file the git panel opens happens to work, because GitDataProviderImpl.openFile joins with /
and builds C:\repo/src/App.kt, which does carry the appended /. So on Windows the breadcrumb is
right or wrong depending on which panel opened the file.

Change

The inline logic moves into one internal function, following the shape memoryIndicatorText
already uses in this package so the logic is testable without a Compose harness. It lives in a new
file, EditorBreadcrumb.kt, rather than beside the composable, because an eleventh function in
BossBottomBar.kt trips detekt's TooManyFunctions (threshold 11) — a new baseline entry seemed
the worse trade:

internal fun editorBreadcrumbSegments(filePath: String, projectPath: String): List<String> {
    val fileSegments = filePath.split('/', '\\').filter { it.isNotEmpty() }
    val projectSegments = projectPath.split('/', '\\').filter { it.isNotEmpty() }
    val inProject =
        projectSegments.isNotEmpty() &&
            fileSegments.size > projectSegments.size &&
            fileSegments.subList(0, projectSegments.size) == projectSegments
    return if (inProject) fileSegments.drop(projectSegments.size) else fileSegments
}

Why both separators on every host, not File.separatorChar: this is a display label, and
plugin-path-utils already documents that rule for display labels: "Both slash styles are separators,
including literal backslashes in POSIX names. These display-label helpers differ deliberately
from host-specific file identity rules." extractFileName, which names the same editor tab in
createEditorTab, follows it. The host separator would also be wrong here in its own right, because
the git panel's path mixes both separators. The one cost is the documented one: a POSIX file name
containing a literal \ is shown as two segments. Nothing is opened or resolved from these segments;
they are BossActionButtons with onClick = {}.

Containment compares whole segments, so /repo still does not claim /repo2/App.kt, which is
what the old appended / was guarding against. Trailing and repeated separators on either side no
longer matter. Because the returned list has no empty entries, the arrow condition reduces to
index < pathParts.lastIndex. One visible side effect on every OS: a doubled separator, such as
/repo/a//b.kt, used to leave an empty segment that suppressed the arrow (a b.kt) and now renders
a › b.kt.

POSIX output is otherwise unchanged: inside the project, outside it, and with no project selected
(Project("No Project", "", 0L)). The tests pin all three.

No detekt baseline entry is added or invalidated: the existing LongMethod entry for
BossLeftBottomBar stays valid, since the function is still 91 lines, over the 60-line threshold.

3 files, +115/-15: the call site, the new helper file, and the test (79 lines of it).

Validation

Windows 11, Temurin 17 (as in CI). dev was rewritten mid-work, so the branch's single commit was
replayed with git rebase --onto origin/dev, and the suite and both linters were re-run on the
new base, dev @ 928ee3647, rather than carried over. The red-test proof below was measured on
the previous base, cf21742df; none of the ten commits in between touches these three files.

• The tests were shown to FAIL first, by mutating editorBreadcrumbSegments' body back to
  the pre-fix removePrefix + split("/") rather than reverting the file, because the test calls the
  helper by name and a revert would not compile. Result: BUILD FAILED, 9 tests, 6 failures, 0
  errors, 0 skipped, and every failure is the defect itself, the whole path returned as one
  segment. For example: expected: <[src, main, App.kt]> but was: <[C:\Users\dev\repo\src\main\App.kt]>.
• Green on the fixed tree: EditorBreadcrumbSegmentsTest 9 tests, 0 failures, 0 errors, 0 skipped.
• Full :composeApp:desktopTest: 5276 tests in 559 classes, 17 skipped, 2 failures. Both
  failures are this machine's known Windows symlink-privilege limitation, not regressions: they
  fail with java.nio.file.FileSystemException: ... A required privilege is not held by the client
  while creating a symlink, in DesktopFileScannerTest and DiscardDownloadContainmentTest.
  Neither class is touched by this change.
• ktlintCheck and detekt: BUILD SUCCESSFUL, detekt report empty, no baseline changes.

What the tests can honestly prove. editorBreadcrumbSegments never reads the host, so all
nine tests assert the same thing on every runner. There is no host-separator case to be red on one OS
and vacuous on another. Under the mutation, 6 go red. The 3 that pass are the POSIX inside-project
case, the outside-project case, and the git panel's mixed-separator path, which the old code handled
by accident. Those three are regression guards, not evidence of the fix. Three of the six red tests
also contain a POSIX assertion that passes under the mutation, and they go red on their Windows
assertion.

Not done: no app was launched, so the rendered bar was not inspected visually. The evidence
is the segment list, which is exactly what the composable iterates.

Overlap

A paginated sweep (gh api .../files --paginate) of all 98 open PRs listed 33 that touch
BossBottomBar.kt. I confirmed each hit with a local diff against a re-derived merge base, since
the API file list is dominated by stale-base noise here. Every real diff is MCP governance UI in the
right-hand half of the bar (McpPolicyManagerDialog, McpProviderTrustControls,
McpActivityLogDialog, the history overlay). None touches BossLeftBottomBar, RightArrow, or
the breadcrumb lines. Those hunks are far from this change, so it should not conflict with any
of them.

Separate from my open #716, which fixes a different Windows separator defect in
GlobalSearchService.searchFiles, in a different file.

[kshivang]

@claude Please review current head 91c562a against dev for correctness, regressions, security and test coverage. This is the bounded vidhaan-753-785 review sweep; please distinguish verified defects from optional improvements.

[claude]

Claude finished @kshivang's task in 3m 45s —— View job

---

Review — 91c562a (editor breadcrumb, Windows paths)

• Read the diff and the surrounding call site
• Verify the stated root cause and the fix's behaviour on every input shape
• Check for regressions (POSIX, no-project, git-panel mixed paths, detekt baselines)
• Security review
• Test-coverage review

Verdict: no verified defects. The change is correct, narrowly scoped, and the claims in the PR body hold up against the code. Everything below the first section is optional.

---

Verified correct

Root cause is accurately diagnosed. origin/dev still carries the inline version (BossBottomBar.kt, projectRoot = "$it/" then removePrefix then split("/")). On a C:\Users\dev\repo project path the appended / makes the prefix unmatchable and the single-character split finds no separator, so the whole absolute path becomes one BossActionButton. Confirmed by reading dev's copy directly.

The arrow simplification is sound. editorBreadcrumbSegments filters empty strings, so the old && pathParts[index + 1].isNotEmpty() guard is dead by construction and index < pathParts.lastIndex is exactly equivalent. The doubled-separator behaviour change the body admits (a › b.kt where it used to be a b.kt) is the correct rendering, not a regression.

Containment is safe. fileSegments.size > projectSegments.size guards the subList(0, projectSegments.size) call, so no IndexOutOfBounds is reachable, and whole-segment comparison preserves the /repo vs /repo2 protection the old appended / gave. projectSegments.isNotEmpty() correctly makes Project("No Project", "", 0L) fall through to the full path — matching old behaviour, where projectRoot became "/" and removePrefix stripped only the leading slash.

No behavioural drift on POSIX. I traced inside-project, outside-project, empty-project and empty-filePath (renders nothing before and after) through both implementations; they agree apart from the doubled-separator case above.

Nothing else in composeApp has the same defect. grep for split("/") across composeApp/src leaves only PasskeyConfigHelper.kt:42, which splits a URL host, not a filesystem path. This PR removes the only instance.

Baselines are undisturbed. composeApp/detekt-baseline.xml:255 keys on the signature LongMethod:BossBottomBar.kt$@Composable fun RowScope.BossLeftBottomBar(tabsComponent: BossTabsComponent? = null), which is unchanged, and the function still spans lines 125–215 (91 lines, over the 60 threshold). The file has 10 top-level functions, so the "an eleventh would trip TooManyFunctions" reasoning for the separate file is accurate.

Placement and testability follow existing precedent. internal in commonMain + a desktopTest caller is exactly the memoryIndicatorText / PerformanceIndicatorTextTest shape this package already uses. The KDoc link [ai.rever.boss.utils.extractFileName] resolves (composeApp/src/commonMain/kotlin/ai/rever/boss/utils/PathUtils.kt:17), and the "both slash styles" rule it cites is the documented one (plugin-path-utils/.../PathUtils.kt:16-17).

Security: nothing to flag. The segments are display labels only — BossActionButton(text = part, onClick = {}). Nothing is opened, resolved, canonicalised or passed to a shell from them, and no path reaches a new surface: the same absolute path was already rendered in the bar, just as one unsplit string. No new plugin-observable data, no new write path.

---

Optional improvements (none blocking)

1. Windows containment stays case-sensitive (EditorBreadcrumb.kt:26). C:\Users\dev\repo vs a filePath that arrives as c:\users\dev\repo\src\App.kt — reachable when the two paths come from different producers (JFileChooser's absolutePath vs a boss://file deep link, a CLI argument, or a hand-typed path) — compares unequal, and the bar falls back to the absolute path. This is pre-existing: removePrefix was case-sensitive too, so it is not a regression introduced here. A host-conditional ignoreCase would cut against the deliberately host-independent display-label rule the KDoc cites, so the cheapest honest fix is a KDoc line recording the limitation rather than a code change. Fix this →

2. Outside-project Windows paths now show a bare C: crumb — C: › repo2 › App.kt, pinned by the test at EditorBreadcrumbSegmentsTest (a sibling directory sharing the project's prefix is not inside it). Strictly better than the old single unsplit segment, and symmetric with POSIX dropping the leading /, but a lone C: reads oddly as a clickable-looking crumb. Dropping a leading ^[A-Za-z]:$ segment would read better. Deliberate as written, so purely a UI-taste call.

3. Recomputed per recomposition (BossBottomBar.kt:148). Not wrapped in remember(activeTab.filePath, currentProject.path). Pre-existing and trivially cheap (two splits on a short string), but it is inside a bar that recomposes on tab/title churn.

4. Test-coverage gaps, all cheap and none load-bearing. The nine cases cover the defect and the three regression shapes well, and the mutation evidence in the PR body is the right kind of proof. Not covered: filePath == projectPath (returns the full path — correct, and unreachable for an EditorTabInfo), a UNC project/file pair (works: \\srv\share\repo → [srv, share, repo], containment holds), and an empty filePath (returns an empty list, so the row renders nothing, same as before). Adding the UNC case would be the most valuable of the three, since plugin-path-utils explicitly calls UNC out as a known-lexical limitation. Fix this →

---

What I could not verify here

• No Gradle run. :composeApp:desktopTest, ktlintCheck and detekt were not executed in this environment; I checked the things those gates would catch by inspection instead (max line length is 140 in .editorconfig and the longest new line is ~104; baseline signatures unchanged; function count 10). The PR body's own run reports green, with two known Windows symlink-privilege failures in untouched classes.
• origin/dev could not be fetched (network restricted), and the ref available locally (c0584c4) shares no merge base with this branch — dev appears to have been rewritten again since the rebase described in the PR body. So this review is of the commit's own diff, not a three-dot diff against current dev. The target region in dev's BossBottomBar.kt is byte-identical to the pre-image, so the change should still apply, but the branch will need another rebase onto current dev before merge.
• No app launch, so the rendered bar was not inspected visually — same caveat the PR body states.
  · branch fix/editor-breadcrumb-windows-paths