fix(dashboard): recognise Windows paths in terminal completion and breadcrumbs

[shrihan-vijay]

Problem / Motivation

Two path-classifying predicates in the frontend were written POSIX-only:
terminalCompletion.ts's shouldComplete/looksLikePath only recognized
/, ~, and ., and MarkdownPanel.tsx's breadcrumbSegments only split
on /. On a Windows gateway (backslash paths, drive letters), this meant the
terminal's completion menu never opened for a backslash-separated token
(cd ..\, dir .\), and an open file's breadcrumb bar rendered a
drive-rooted path (C:\Users\me\notes.md) as one giant, non-navigable
segment instead of the usual clickable ancestor chain.

Why it matters

Kiro Crew supports native Windows gateways (see the cross-platform guidance
in AGENTS.md), so a Windows user driving the web terminal or opening a file
in the dashboard hits a visibly broken experience on two separate, everyday
surfaces: no path autocomplete in the terminal, and a useless breadcrumb bar
in the file viewer.

What changed (motivation → approach → change)

Observed symptom: the terminal completion menu and the markdown panel's
breadcrumbs both silently fail to recognize Windows-style paths.

Root cause: both predicates test only for / (and POSIX-specific markers
like a leading /) without ever checking for \ or a drive-letter root.

Approach: rather than reinventing drive-letter detection, I reused the one
shared predicate the codebase already has for it (WINDOWS_ABS_PATH_RE in
urlTransform.ts), and extended both files to accept either path separator,
splitting/joining consistently with whichever separator the input actually
used.

While in terminalCompletion.ts, I found a related, previously-latent issue:
shouldComplete/looksLikePath gate whether the frontend fetches
POST /api/terminal/complete for the typed token, and a UNC-shaped token
(\\host\share, or already today //host/share) would have the gateway
list a directory on a named host — on Windows, that stat is an outbound SMB
connection offering the host's credentials, for nothing but typing a token
in the terminal. This is the same vulnerability class a sibling, still-open
PR (#7969) documents and fixes for the markdown path-chip
predicate (isPathCandidate). I added the same UNC refusal here, and
hoisted the shared UNC_PREFIX_RE into urlTransform.ts next to
WINDOWS_ABS_PATH_RE, per that PR's own design-review comment asking for
exactly this once a sibling predicate needed the same treatment.
terminalCompletion.ts keeps its own local copy of the regex rather than
importing it, since that module is deliberately dependency-free (zero
imports) so its logic stays unit-testable without pulling in
react-markdown transitively through urlTransform.ts.

Scope note: isPathCandidate/MarkdownRenderer.tsx (the third predicate
named in the parent issue) is left entirely to #7969, which already covers
it and is still open — this PR does not touch that file.

Tests

• terminalCompletion.test.ts: new cases for shouldComplete/completionMode
  triggering on backslash-separated tokens, and refusing to trigger (or route
  to the path tier) for a UNC-shaped token in either separator spelling.
• MarkdownPanel.test.tsx: new cases for breadcrumbSegments splitting a
  drive-rooted backslash path into the correct segments, reconstructing each
  ancestor path with the drive letter intact, and accepting the
  forward-slash spelling of a drive-rooted path too.
• urlTransform.test.ts: new cases asserting UNC_PREFIX_RE matches both
  UNC spellings and does not match a drive-rooted or POSIX path.

Manual verification

N/A — unit coverage sufficient. These are pure string-classification
functions with deterministic inputs/outputs, fully exercised by the added
unit tests.

Screenshots / video

N/A — no visual/layout change. The fix is behavioral (which strings trigger
completion / how a path string is split into breadcrumb segments); the
rendering of the completion menu and breadcrumb bar is unchanged.

Related Issues

Fixes #7990

Pattern harvest

Not generalizable: this is the second and third of three call sites in a
known, already-tracked class of POSIX-only path predicates in the frontend —
the first (isPathCandidate) is covered by #7969, and the parent issue
(#7990) is itself the tracking mechanism for finishing the enumerated list.
No new rule is needed beyond completing that list.

Checklist

• At most two commits (one is the norm), with a Conventional Commits title (feat|fix|docs|refactor|perf|test|chore|ci|build|revert: ...)
• Existing tests pass and new tests added for new functionality
• Self-review completed; code follows project style guidelines
• Documentation updated (if applicable) — N/A, no spec document covers these predicates
• No secrets, credentials, or internal references in the diff

Contribution License Agreement

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

🤖 Generated with Claude Code

https://claude.ai/code/session_01Qj2fBtkAg8y3xRh4Xc41Wv

[iamwhatever]

👋 Hi! This PR's description is missing some required sections from our PR template. Workflow runs won't be auto-approved until the description is updated.

Missing sections:

• ## Problem / Motivation
• ## Why it matters
• ## What changed
• ## Tests

Please update your PR description to include these sections, then push or re-save the description. The workflows will be approved on the next cycle.

[dwu96]

👋 Hi! This PR's description is missing some required sections from our PR template. Workflow runs won't be auto-approved until the description is updated.

Missing sections:

• ## Problem / Motivation
• ## Why it matters
• ## What changed
• ## Tests

Please update your PR description to include these sections, then push or re-save the description. The workflows will be approved on the next cycle.

[bolichen97]

Open PR relationship audit

This is a consolidated, point-in-time code-level audit note. It compares complete merge-base diffs and current/merged code; it does not treat a shared topic as duplication or partial coverage as completion.

Relationship findings

• This PR is OVERLAPPING with PR #7969. The goals differ or the implementations can complement each other; this is not a duplicate claim. Recommended action for PR #8012: CONTINUE_DEVELOPMENT. The merged sibling covers a different predicate and does not implement either behavior this PR adds, but it also fixes the UNC guard by shape after review rejected the alternation form this PR ships; align the regex with main's /^[/\]{2}/ (and have the hoisted export be the one thing every call site imports) before merge. Files: website/src/components/MarkdownRenderer.tsx, website/src/utils/urlTransform.ts.

No PR, Issue, label, branch, or review state was changed by the relationship-note portion of this audit.

[bolichen97]

@shrihan-vijay Thanks for keeping this scoped to #7990 and for leaving isPathCandidate alone.

What already landed: merged #7969 (d31d9c700) fixed the first of the three predicates #7990 enumerates, isPathCandidate in website/src/components/MarkdownRenderer.tsx, and it carries its own UNC guard there.

What is still missing on main: both of your user-facing fixes. website/src/utils/terminalCompletion.ts still gates shouldComplete and looksLikePath on token.includes('/'), and breadcrumbSegments in website/src/components/MarkdownPanel.tsx still splits and rejoins on / only. Nothing has superseded this work, so please keep the PR.

Two changes we would like before merge:

1. Align the UNC guard with the shape fix(dashboard): recognise Windows paths in the markdown path chip #7969 actually merged, /^[/\\]{2}/. The UNC_PREFIX_RE you export from website/src/utils/urlTransform.ts requires two of the same separator, so mixed spellings that Windows still reads as a UNC root pass shouldComplete and reach POST /api/terminal/complete.
2. Make MarkdownRenderer.tsx import the hoisted constant. As the diff stands the hoist adds a copy instead of removing one: main would end up with three UNC regexes under two different semantics, one in urlTransform.ts, one local to terminalCompletion.ts, and the existing one in MarkdownRenderer.tsx.

Then please rebase. The branch is 705 commits behind main and is currently blocked, and open #9301 edits the lines immediately after breadcrumbSegments in the same file plus the same test file, so whichever lands second will need a small conflict fix.

Posted from the 2026-09-08 open-PR relationship audit (read-only, one auditor per PR); reply here if any of this is wrong.