Summary
After merging #239, a few renderer/linkification edge cases still need a focused follow-up bugfix pass for workspace path links in markdown/chat.
This is not a re-open of the original feature lane from #237 / #239. It is still the existing post-merge workspace-inline-reference follow-up lane discovered while validating the merged behavior on a downstream integration branch.
In Plain English
This issue is about making chat/workspace file links behave the way users naturally expect.
The original feature already made /workspace/... paths clickable, and this follow-up now also treats bare workspace/... as an intentionally supported shorthand for that same canonical workspace target. At the same time, malformed near-misses should still stay plain text — for example bare workspace/ or interior-token forms like path=workspace/foo.md should not become links.
In short: fewer false negatives, fewer false positives, and a clearer contract for accepted workspace inline references.
Scope
- linkify embedded
/workspace/... path slices inside surrounding text
- narrow inline path token typing so the matcher does not overreach
- handle wrapped / punctuation-adjacent workspace inline links correctly
- treat bare
workspace/... as intentional shorthand for canonical /workspace/... within the same workspace-inline-reference lane
- keep malformed negatives plain while tightening workspace-rooted matching and resolve-path guardrails so only intended workspace-style paths become actionable
Provenance
Clean source branch: bugfix/workspace-inline-reference-slice
Commits on that branch:
36cca92 — fix(markdown): linkify embedded workspace path slicesd3d3a64 — fix(markdown): narrow inline path match typinga04876e — Fix wrapped workspace inline path links6cf2616 — Tighten workspace-rooted inline path matchingd0d4b40 — fix(markdown): address PR review follow-upsbea1fa1 — Support bare workspace inline references349dc5c — Clarify workspace shorthand inline path contract
Downstream validation already happened via cherry-picks on a local workhorse integration branch:
4e3c8fb <- 36cca922b064f0 <- d3d3a64719db38 <- a04876e5435706 <- 6cf2616a8faf29 <- 349dc5c
Related prior art
Summary
After merging #239, a few renderer/linkification edge cases still need a focused follow-up bugfix pass for workspace path links in markdown/chat.
This is not a re-open of the original feature lane from #237 / #239. It is still the existing post-merge
workspace-inline-referencefollow-up lane discovered while validating the merged behavior on a downstream integration branch.In Plain English
This issue is about making chat/workspace file links behave the way users naturally expect.
The original feature already made
/workspace/...paths clickable, and this follow-up now also treats bareworkspace/...as an intentionally supported shorthand for that same canonical workspace target. At the same time, malformed near-misses should still stay plain text — for example bareworkspace/or interior-token forms likepath=workspace/foo.mdshould not become links.In short: fewer false negatives, fewer false positives, and a clearer contract for accepted workspace inline references.
Scope
/workspace/...path slices inside surrounding textworkspace/...as intentional shorthand for canonical/workspace/...within the same workspace-inline-reference laneProvenance
Clean source branch:
bugfix/workspace-inline-reference-sliceCommits on that branch:
36cca92—fix(markdown): linkify embedded workspace path slicesd3d3a64—fix(markdown): narrow inline path match typinga04876e—Fix wrapped workspace inline path links6cf2616—Tighten workspace-rooted inline path matchingd0d4b40—fix(markdown): address PR review follow-upsbea1fa1—Support bare workspace inline references349dc5c—Clarify workspace shorthand inline path contractDownstream validation already happened via cherry-picks on a local
workhorseintegration branch:4e3c8fb<-36cca922b064f0<-d3d3a64719db38<-a04876e5435706<-6cf2616a8faf29<-349dc5cRelated prior art