Pre-push review: T-2066/bugfix-percent-encoded-local-paths

diff --git a/prism/Services/LinkPathResolver.swift b/prism/Services/LinkPathResolver.swiftindex c00455ad..736ad5e6 100644--- a/prism/Services/LinkPathResolver.swift+++ b/prism/Services/LinkPathResolver.swift@@ -170,9 +170,26 @@ enum LinkPathResolver {                 // up as literal characters in the file URL's path (T-861).                 // The query part is intentionally discarded: local file links                 // are resolved by classifyLocal against the filesystem, which-                // has no use for query parameters.+                // has no use for query parameters. Splitting on the RAW source+                // — before any decoding — is what keeps a percent-encoded+                // `%23`/`%3F` inside the path from ever being mistaken for a+                // live fragment/query delimiter: `PrismURL.split` only+                // recognises the literal characters (T-2066).                 let (pathPart, _, fragmentPart) = PrismURL.split(source)-                let url = URL(fileURLWithPath: pathPart).standardized+                // Decode before constructing the file URL: a filesystem path is+                // not percent-encoded, so `URL(fileURLWithPath:)` treats `%20`+                // as three literal characters rather than a space, resolving to+                // a file that doesn't exist (T-2066). This mirrors the+                // plain-relative branch's `decodedPath` below, including its+                // full decode of an encoded `%2F` — a real filesystem entry can+                // never contain a literal `/` in its name, so there is no+                // "structural" reading of the path left to protect by leaving+                // it encoded here, unlike the `.url` branch just below, where+                // decoding `%2F` would change which remote resource is+                // requested (T-1850/T-2140).+                // prism-url-exempt: URL→filesystem, not URL→URL; a filesystem path is not percent-encoded+                let decodedPath = pathPart.removingPercentEncoding ?? pathPart+                let url = URL(fileURLWithPath: decodedPath).standardized                 return classifyLocal(url, fragment: PrismURL.nonEmptyFragment(fragmentPart))             case .url:                 // Split using our own helper rather than URLComponents(string:),

diff --git a/prism/Services/ImagePathResolver.swift b/prism/Services/ImagePathResolver.swiftindex 55ee007a..3ddfe499 100644--- a/prism/Services/ImagePathResolver.swift+++ b/prism/Services/ImagePathResolver.swift@@ -307,9 +307,25 @@ enum ImagePathResolver {                 // Split path/query/fragment so `#fragment` and `?query` don't end                 // up as literal characters in the file URL's path (T-861). Query                 // and fragment are discarded: filesystem image loading has no use-                // for them.+                // for them. Splitting on the RAW source — before any decoding —+                // is what keeps a percent-encoded `%23`/`%3F` inside the path+                // from ever being mistaken for a live fragment/query delimiter:+                // `PrismURL.split` only recognises the literal characters (T-2066).                 let (pathPart, _, _) = PrismURL.split(source)-                let url = URL(fileURLWithPath: pathPart).standardized+                // Decode before constructing the file URL: a filesystem path is+                // not percent-encoded, so `URL(fileURLWithPath:)` treats `%20`+                // as three literal characters rather than a space, resolving to+                // a file that doesn't exist (T-2066). This mirrors the+                // plain-relative branch's `decodedPath` below, including its+                // full decode of an encoded `%2F` — a real filesystem entry can+                // never contain a literal `/` in its name, so there is no+                // "structural" reading of the path left to protect by leaving+                // it encoded here, unlike the `.url` branch just below, where+                // decoding `%2F` would change which remote resource is+                // requested (T-1850/T-2140).+                // prism-url-exempt: URL→filesystem, not URL→URL; a filesystem path is not percent-encoded+                let decodedPath = pathPart.removingPercentEncoding ?? pathPart+                let url = URL(fileURLWithPath: decodedPath).standardized                 return resolvedSource(url: url, asLocal: true)             case .url:                 // Root-relative path in remote context: resolve against origin.

diff --git a/prismTests/LinkPathResolverPercentEncodedAbsolutePathTests.swift b/prismTests/LinkPathResolverPercentEncodedAbsolutePathTests.swiftnew file mode 100644index 00000000..b7b636cb--- /dev/null+++ b/prismTests/LinkPathResolverPercentEncodedAbsolutePathTests.swift@@ -0,0 +1,112 @@+//+//  LinkPathResolverPercentEncodedAbsolutePathTests.swift+//  prismTests+//++import Foundation+import Testing+@testable import prism++// MARK: - T-2066: Percent-Encoded Absolute Local Paths++/// The root-absolute `.file`/`.bundled` branch of `resolveRelativePath` used+/// to hand the still-encoded split path straight to `URL(fileURLWithPath:)`,+/// unlike its plain-relative sibling a few lines below, which already+/// decodes. Foundation treats `%20` in that initializer as three literal+/// characters rather than a space, so `/Users/a/My%20Doc.md` resolved to a+/// file literally named `My%20Doc.md` — one that does not exist.+@Suite("LinkPathResolver percent-encoded absolute local paths")+struct LinkPathResolverPercentEncodedAbsolutePathTests {++    @Test("Percent-encoded absolute local markdown path decodes to real filename (T-2066)")+    func percentEncodedAbsoluteLocalMarkdownPath() {+        let baseURL = URL(fileURLWithPath: "/Users/test/Documents/")+        let result = LinkPathResolver.resolve(+            destination: "/Users/a/My%20Doc.md",+            baseURL: baseURL,+            sourceType: .file+        )+        #expect(result == .markdownFile(URL(fileURLWithPath: "/Users/a/My Doc.md")))+    }++    @Test("Percent-encoded absolute bundled markdown path decodes to real filename (T-2066)")+    func percentEncodedAbsoluteBundledMarkdownPath() {+        let baseURL = URL(fileURLWithPath: "/App/Bundle/Resources/")+        let result = LinkPathResolver.resolve(+            destination: "/App/Bundle/Resources/My%20Guide.md",+            baseURL: baseURL,+            sourceType: .bundled+        )+        #expect(result == .markdownFile(URL(fileURLWithPath: "/App/Bundle/Resources/My Guide.md")))+    }++    @Test("Percent-encoded absolute local path decodes alongside a real fragment (T-2066)")+    func percentEncodedAbsoluteLocalPathWithFragment() {+        let baseURL = URL(fileURLWithPath: "/Users/test/Documents/")+        let result = LinkPathResolver.resolve(+            destination: "/Users/a/My%20Doc.md#section%20one",+            baseURL: baseURL,+            sourceType: .file+        )+        // The fragment travels through LinkPathResolver's existing (encoded)+        // convention — only the filesystem path half of this bug is decoded.+        #expect(result == .markdownFile(+            URL(fileURLWithPath: "/Users/a/My Doc.md"),+            fragment: "section%20one"+        ))+    }++    @Test("Encoded hash inside an absolute local path is not mistaken for a fragment delimiter (T-2066)")+    func percentEncodedHashInsideAbsoluteLocalPath() {+        // `PrismURL.split` must split on the source's RAW characters before+        // any decoding happens: if the encoded path were decoded first, the+        // `%23` here would become a live `#` and everything after it would be+        // misread as a fragment, splitting one filename into a path and a+        // bogus anchor.+        let baseURL = URL(fileURLWithPath: "/Users/test/Documents/")+        let result = LinkPathResolver.resolve(+            destination: "/Users/a/na%23me.md#real",+            baseURL: baseURL,+            sourceType: .file+        )+        #expect(result == .markdownFile(+            URL(fileURLWithPath: "/Users/a/na#me.md"),+            fragment: "real"+        ))+    }++    @Test("Encoded question mark inside an absolute local path is not mistaken for a query delimiter (T-2066)")+    func percentEncodedQuestionMarkInsideAbsoluteLocalPath() {+        // The sibling of `percentEncodedHashInsideAbsoluteLocalPath` for the+        // other delimiter `PrismURL.split` recognises. Splitting on the RAW+        // source is what keeps the `%3F` here inside the filename: were the+        // path decoded first, the resulting live `?` would cut the name in+        // two and the tail would be discarded as a query.+        let baseURL = URL(fileURLWithPath: "/Users/test/Documents/")+        let result = LinkPathResolver.resolve(+            destination: "/Users/a/na%3Fme.md?real=1",+            baseURL: baseURL,+            sourceType: .file+        )+        // The real query is discarded (local file links have no use for one);+        // the encoded one survives into the filename.+        #expect(result == .markdownFile(URL(fileURLWithPath: "/Users/a/na?me.md")))+    }++    @Test("Encoded slash in an absolute local path decodes to a real subdirectory (T-2066)")+    func percentEncodedSlashInAbsoluteLocalPath() {+        // Unlike the remote `.url` branch (T-1850/T-2140), where an escaped+        // `%2F` must stay escaped because it changes which server resource is+        // requested, a local filesystem entry can never contain a literal `/`+        // in its own name. Decoding it here — consistent with the+        // plain-relative branch's existing `decodedPath` — is the only+        // reading that can name a real file.+        let baseURL = URL(fileURLWithPath: "/Users/test/Documents/")+        let result = LinkPathResolver.resolve(+            destination: "/Users/a/folder%2Ffile.md",+            baseURL: baseURL,+            sourceType: .file+        )+        #expect(result == .markdownFile(URL(fileURLWithPath: "/Users/a/folder/file.md")))+    }+}

diff --git a/prismTests/ImagePathResolverPercentEncodedAbsolutePathTests.swift b/prismTests/ImagePathResolverPercentEncodedAbsolutePathTests.swiftnew file mode 100644index 00000000..5c39d51c--- /dev/null+++ b/prismTests/ImagePathResolverPercentEncodedAbsolutePathTests.swift@@ -0,0 +1,92 @@+//+//  ImagePathResolverPercentEncodedAbsolutePathTests.swift+//  prismTests+//++import Foundation+import Testing+@testable import prism++// MARK: - T-2066: Percent-Encoded Absolute Local Paths++/// The root-absolute `.file`/`.bundled` branch of `resolveRelativePath` used+/// to hand the still-encoded split path straight to `URL(fileURLWithPath:)`,+/// unlike its plain-relative sibling a few lines below, which already+/// decodes. Foundation treats `%20` in that initializer as three literal+/// characters rather than a space, so `/Users/a/My%20Image.png` resolved to a+/// file literally named `My%20Image.png` — one that does not exist.+@Suite("ImagePathResolver percent-encoded absolute local paths")+struct ImagePathResolverPercentEncodedAbsolutePathTests {++    @Test("Percent-encoded absolute local image path decodes to real filename (T-2066)")+    func percentEncodedAbsoluteLocalImagePath() {+        let baseURL = URL(fileURLWithPath: "/Users/test/Documents/")+        let result = ImagePathResolver.resolve(+            source: "/Users/a/My%20Image.png",+            baseURL: baseURL,+            sourceType: .file+        )+        #expect(result == .localFile(URL(fileURLWithPath: "/Users/a/My Image.png")))+    }++    @Test("Percent-encoded absolute bundled image path decodes to real filename (T-2066)")+    func percentEncodedAbsoluteBundledImagePath() {+        let baseURL = URL(fileURLWithPath: "/App/Bundle/Resources/")+        let result = ImagePathResolver.resolve(+            source: "/App/Bundle/Resources/My%20Logo.png",+            baseURL: baseURL,+            sourceType: .bundled+        )+        #expect(result == .localFile(URL(fileURLWithPath: "/App/Bundle/Resources/My Logo.png")))+    }++    @Test("Encoded hash inside an absolute local image path is not mistaken for a fragment delimiter (T-2066)")+    func percentEncodedHashInsideAbsoluteLocalImagePath() {+        // `PrismURL.split` must split on the source's RAW characters before+        // any decoding happens: if the path were decoded first, the `%23`+        // here would become a live `#` and everything after it would be+        // stripped as a bogus fragment instead of surviving into the filename.+        let baseURL = URL(fileURLWithPath: "/Users/test/Documents/")+        let result = ImagePathResolver.resolve(+            source: "/Users/a/na%23me.png",+            baseURL: baseURL,+            sourceType: .file+        )+        #expect(result == .localFile(URL(fileURLWithPath: "/Users/a/na#me.png")))+    }++    @Test("Encoded question mark inside an absolute local image path is not mistaken for a query delimiter (T-2066)")+    func percentEncodedQuestionMarkInsideAbsoluteLocalImagePath() {+        // The sibling of `percentEncodedHashInsideAbsoluteLocalImagePath` for+        // the other delimiter `PrismURL.split` recognises. Splitting on the+        // RAW source is what keeps the `%3F` here inside the filename: were+        // the path decoded first, the resulting live `?` would cut the name in+        // two and the tail would be discarded as a query.+        let baseURL = URL(fileURLWithPath: "/Users/test/Documents/")+        let result = ImagePathResolver.resolve(+            source: "/Users/a/na%3Fme.png?real=1",+            baseURL: baseURL,+            sourceType: .file+        )+        // The real query is discarded (filesystem image loading has no use for+        // one); the encoded one survives into the filename.+        #expect(result == .localFile(URL(fileURLWithPath: "/Users/a/na?me.png")))+    }++    @Test("Encoded slash in an absolute local image path decodes to a real subdirectory (T-2066)")+    func percentEncodedSlashInAbsoluteLocalImagePath() {+        // Unlike the remote `.url` branch (T-1850/T-2140), where an escaped+        // `%2F` must stay escaped because it changes which server resource is+        // requested, a local filesystem entry can never contain a literal `/`+        // in its own name. Decoding it here — consistent with the+        // plain-relative branch's existing `decodedPath` — is the only+        // reading that can name a real file.+        let baseURL = URL(fileURLWithPath: "/Users/test/Documents/")+        let result = ImagePathResolver.resolve(+            source: "/Users/a/folder%2Fphoto.png",+            baseURL: baseURL,+            sourceType: .file+        )+        #expect(result == .localFile(URL(fileURLWithPath: "/Users/a/folder/photo.png")))+    }+}

diff --git a/specs/bugfixes/percent-encoded-absolute-local-paths/report.md b/specs/bugfixes/percent-encoded-absolute-local-paths/report.mdnew file mode 100644index 00000000..f4892c33--- /dev/null+++ b/specs/bugfixes/percent-encoded-absolute-local-paths/report.md@@ -0,0 +1,142 @@+# Bugfix Report: Percent-Encoded Absolute Local Paths++**Date:** 2026-09-07+**Status:** Fixed++## Description of the Issue++A markdown link or image whose destination was a percent-encoded root-absolute+local filesystem path resolved to a file named literally after the encoded+text, rather than the file the author meant. `/tmp/my%20file.md` resolved to a+lookup for a file named `my%20file.md`, not `my file.md`.++**Reproduction steps:**+1. Create `/tmp/my file.md` (a local file whose name contains a space).+2. In a local/bundled markdown document, add `[target](/tmp/my%20file.md)` or+   `![](/tmp/my%20image.png)`.+3. Tap the link / view the image. Prism attempts to open/load a file whose+   name literally contains `%20`, which does not exist, so the link fails and+   the image shows an error placeholder.++**Impact:** Any local/bundled document linking to or embedding a percent-+encoded absolute path (spaces, or any other character requiring escaping)+failed to open/load. This affects both document navigation and media+rendering. Root-relative and plain-relative local paths were unaffected —+only root-absolute (`/…`) destinations in `.file`/`.bundled` context.++## Investigation Summary++- **Symptoms examined:** the reported repro (`URL(fileURLWithPath: "/tmp/my%20file.md").path` prints `/tmp/my%20file.md`, i.e. no decoding happens).+- **Code inspected:**+  - `prism/Services/LinkPathResolver.swift`, `resolveRelativePath`, the `source.hasPrefix("/")` branch's `.file, .bundled` case.+  - `prism/Services/ImagePathResolver.swift`, the equivalent branch.+  - The sibling *plain-relative* branches in both files, a few lines below, which already decode (`let decodedPath = pathPart.removingPercentEncoding ?? pathPart`, carrying a `prism-url-exempt` marker).+  - `prism/Services/PrismURL.swift` (`split`, `nonEmptyFragment`) — the shared, order-sensitive splitter.+  - Closed ticket T-1850 (relative URL normalization changing encoded slash path segments) and its closing comment, which explicitly endorses the plain-relative branch's full decode (including `%2F`) as correct for the *URL→filesystem* direction, distinct from the *URL→URL* direction T-1850/T-2140 fixed.+  - `URLEncodingCorpusTests`/`URLEncodingCorpus.swift`: confirmed the shared corpus only drives `.url` (remote) conversion paths, never the `.file`/`.bundled` filesystem branches, so it could not have caught this and needs no new row.+  - `URLChokepointAdoptionTests.swift`: confirmed the exemption-marker convention (`prism-url-exempt: <reason>`, on the flagged line or the line directly above) that the fix's new `removingPercentEncoding` calls must follow.+- **Hypotheses tested:** whether the fix should preserve `%2F` as a literal escape (as the `.url` branches must) or fully decode it (as the existing plain-relative filesystem branch does). Concluded the latter is correct for a *filesystem* destination: a real file can never contain a literal `/` in its own name, so there is no "structural" reading of an absolute local path that decoding `%2F` could corrupt, unlike a remote HTTP resource where an escaped slash can be semantically distinct from a live separator (e.g. GitLab's `group%2Fproj` API routes).++## Discovered Root Cause++**Defect type:** Missing decoding step / inconsistency between two structurally+identical branches in the same function.++**Why it occurred:** `resolveRelativePath` in both resolvers has two branches+that both end in "build a file URL from a filesystem path": the root-absolute+branch (`source.hasPrefix("/")`) and the plain-relative branch below it. The+plain-relative branch decodes its split path before use because+`appendingPathComponent` does no decoding of its own. The root-absolute branch+was never given the same treatment — it split off query/fragment (fixing+T-861) but passed the still-encoded path straight to+`URL(fileURLWithPath:)`, which also does no decoding.++**Contributing factors:** The two branches are adjacent but not shared code+(tracked separately as T-2210, "Unify the forked relative-path resolution"),+so a fix applied to one did not propagate to the other. No existing test drove+a percent-encoded root-absolute local path, so the divergence went unnoticed.++## Resolution for the Issue++**Changes made:**+- `prism/Services/LinkPathResolver.swift` — root-absolute `.file, .bundled` branch: decode the split path (`pathPart.removingPercentEncoding ?? pathPart`) before constructing `URL(fileURLWithPath:)`, carrying a `prism-url-exempt` marker matching the sibling branch's.+- `prism/Services/ImagePathResolver.swift` — same change in the equivalent branch.+- `prismTests/LinkPathResolverPercentEncodedAbsolutePathTests.swift` (new) — regression tests.+- `prismTests/ImagePathResolverPercentEncodedAbsolutePathTests.swift` (new) — regression tests.+- `CHANGELOG.md` — `[Unreleased] / Fixed` entry.++**Approach rationale:** Mirror the existing, already-reviewed plain-relative+branch's decode exactly, rather than invent a different decoding rule for the+root-absolute branch. `PrismURL.split` still runs on the *raw* source before+any decoding, so a percent-encoded `%23`/`%3F` inside the path is never+mistaken for a live fragment/query delimiter — the split already happened by+the time decoding runs. Decoding `%2F` too (rather than preserving it as a+literal escape) matches the sibling branch and is intentional: unlike the+`.url` branches, where `PrismURL.percentEncoded(_, as: .path)` deliberately+preserves an escaped `/` because it can change which remote resource is+requested (T-1850/T-2140), a local filesystem entry can never contain a+literal `/` in its own name, so decoding it here has no "wrong" destination to+protect against — it is the only reading that can name a real file.++**Alternatives considered:**+- **Preserve `%2F` as a literal escape in the filesystem branches too** (mirroring the `.url` branches' selective encoder) — rejected because it would make the two "build a file URL" branches in the same function decode differently from each other for no functional benefit (no real file can be named with a literal `/`), and it would diverge from the plain-relative branch's already-accepted behaviour without a corresponding ticket asking for that broader change.+- **Add a dedicated `PrismURL.decodedFilesystemPath` helper shared by all four call sites** (both root-absolute and both plain-relative) — considered for consistency, but scoped out as unrelated refactor risk beyond this ticket; the existing plain-relative call sites are untouched, and T-2210 already tracks unifying the forked resolution logic.++## Regression Test++**Test files:**+- `prismTests/LinkPathResolverPercentEncodedAbsolutePathTests.swift`+- `prismTests/ImagePathResolverPercentEncodedAbsolutePathTests.swift`++**What they verify:**+- A percent-encoded absolute local/bundled markdown or image path decodes to the real filename (`%20` → space).+- The fix composes correctly with an existing real fragment (link case).+- An encoded `%23` inside the path is not mistaken for a fragment delimiter after decoding (split-before-decode ordering).+- An encoded `%2F` decodes to a real subdirectory separator, consistent with the sibling plain-relative branch.++**Run command:**+```+xcodebuild test -project prism.xcodeproj -scheme prism \+  -destination 'platform=macOS' -configuration Debug -derivedDataPath ./DerivedData \+  -resultBundlePath ./DerivedData/t.xcresult -testPlan prism -only-test-configuration "en (base)" \+  -parallel-testing-worker-count 1 -enableCodeCoverage NO \+  -only-testing:prismTests/LinkPathResolverPercentEncodedAbsolutePathTests \+  -only-testing:prismTests/ImagePathResolverPercentEncodedAbsolutePathTests+```++## Affected Files++| File | Change |+|------|--------|+| `prism/Services/LinkPathResolver.swift` | Decode the split root-absolute path before `URL(fileURLWithPath:)` |+| `prism/Services/ImagePathResolver.swift` | Same, for image resolution |+| `prismTests/LinkPathResolverPercentEncodedAbsolutePathTests.swift` | New regression suite |+| `prismTests/ImagePathResolverPercentEncodedAbsolutePathTests.swift` | New regression suite |+| `CHANGELOG.md` | `[Unreleased] / Fixed` entry |++## Verification++**Automated:**+- [x] Regression tests pass (`LinkPathResolverPercentEncodedAbsolutePathTests`, `ImagePathResolverPercentEncodedAbsolutePathTests`)+- [x] Full `LinkPathResolverTests`/`ImagePathResolverTests` suites pass (145 tests)+- [x] `URLEncodingCorpusTests`, `URLChokepointAdoptionTests` (including `noStaleExemptionMarkers`), `PrismURLAbsoluteURLTests`, `PrismURLSplittingFragmentTests`, and the existing query/fragment-leakage suites for both resolvers pass (56 tests)+- [x] `make lint` passes+- [x] `make build-macos` passes+- [ ] Full `make test-quick`/`make test` — **not run**: this machine's test hosts are currently crashing at launch in `_libsecinit_appsandbox`, a known sandbox-container issue tracked separately from this bug. All targeted suites above (201 tests total) were run individually via `xcodebuild test -only-testing:` and verified with `Tools/check-test-results.sh`, which is the mitigation available while that issue stands.++**Manual verification:** Not performed (no manual repro environment available in this session); relies on the regression suite above, which reproduces the exact reported shapes.++## Prevention++**Recommendations to avoid similar bugs:**+- T-2210 ("Unify the forked relative-path resolution shared by ImagePathResolver and LinkPathResolver") would remove this class of divergence structurally — the root-absolute and plain-relative branches doing the same "build a file URL" work independently is exactly how this defect and T-861 both arose.+- Consider extending `URLEncodingCorpusTests`' conversion-path enumeration to cover the `.file`/`.bundled` filesystem branches (currently only `.url` paths are enumerated), so a future asymmetry between root-absolute and plain-relative filesystem decoding is caught mechanically rather than by inspection.++## Related++- T-2066 (this ticket)+- T-861 (query/fragment stripping on absolute local paths — the fix this one is adjacent to)+- T-1850 (closed; established that full decode, including `%2F`, is correct for the URL→filesystem direction)+- T-2140 (the `PrismURL` chokepoint and the `%2F`/`%20` defect classes for the URL→URL direction)+- T-2210 (open; tracks unifying the forked resolution logic these two branches live in)+- T-2214 (open, not addressed here; protocol-relative links resolving against the wrong host)

diff --git a/CHANGELOG.md b/CHANGELOG.mdindex 8b947fb7..539b5291 100644--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -25,6 +25,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0  ### Fixed +- A local link or image with a percent-encoded absolute path now opens the file it actually names, instead of a file literally named with the percent escapes still in it (T-2066). `LinkPathResolver` and `ImagePathResolver` split query/fragment off a root-absolute `/…` destination before handing the remaining path straight to `URL(fileURLWithPath:)` — which does no decoding of its own — so `[Doc](/Users/me/My%20Doc.md)` or `![](/Users/me/My%20Image.png)` resolved to a nonexistent file named `My%20Doc.md`/`My%20Image.png` rather than the one with a space in its name. Both root-absolute branches now decode the split path first, matching the plain-relative branch a few lines below, which already did. The split itself still runs on the raw, undecoded source, so a percent-encoded `%23`/`%3F` inside the path is never mistaken for a live fragment/query delimiter after decoding. An encoded `%2F` is decoded too, consistent with that same plain-relative branch: a real filesystem entry can never contain a literal `/` in its own name, so — unlike the remote `.url` branches, where an escaped slash must stay escaped because it changes which server resource is requested (T-1850/T-2140) — there is no reading of a local path where leaving it encoded names a real file. - Tapping a note in the compact Notes panel or the regular Notes sidebar now scrolls to the block that note is actually anchored to, instead of always the first occurrence of identical content elsewhere in the document (T-1929). Both note UIs navigated by passing the note's bare content-hash block id, which `BlockDOMID` resolves to its first (or first-visible) occurrence by design — the note's own stored heading path, already recorded for note storage/display disambiguation (T-209), was never consulted. Navigation now resolves the note's specific occurrence against that heading path and builds the same verified composite target TOC/search/scroll-restore already use, falling back to the previous first-occurrence behaviour only when a note carries no heading path (legacy notes) or its heading path no longer matches any occurrence (the block was relocated). A table-row or list-item note anchor resolves to its parent block's correct occurrence, since rows and items are not independently scrollable. - An open document now follows its file when you rename or move it in Finder, the Files app, or another file provider (T-1881). The app watches the open file through a file presenter, and that presenter never implemented the half of its contract that deals with the file moving: it kept pointing at where the file used to be, and so did the document. Reload then failed on a file that is perfectly readable, the title kept the old name, images beside the document were looked for in the old folder, and the notes were left filed under a path nothing would ever look up again. The presenter now retargets itself the moment it is told the file moved, and the document follows it — which is what carries the title, the Save destination, Reload, the remembered reading position and the page's image resolution across the move, since all of them are derived from the one property. The notes move with the document, and the record left at the old path is retired rather than stranded there. Moving them is its own operation rather than a reuse of the one Save As runs, because three things a Save As can take for granted are not true of a rename, and each of them lost notes: a renamed file's notes may not be loaded yet (a rename arriving before you have opened the notes pane, or before the document has finished loading, used to be reported as migrated while nothing moved); an old and a new name can be the same file, so renaming `readme.md` to `README.md` used to write the notes and then delete the file it had just written, taking every note with it; and the document is already at its new name by the time the app is told, so a note written in the instant the rename lands used to clear every note already on the document. Trashing an open document is no longer mistaken for a rename either — it arrives as one, measurably, so the notes would have been rewritten under a path inside the Trash and the ones at the real path deleted; the document now stays where it was, which is where Put Back returns it and where its notes are waiting. Two things deliberately do not move: the Recent Files entry still names the path you opened from (that is T-1842 / T-2172 / T-2173), and the security-scoped access the session holds is left alone — it was granted for the file itself and survives the rename, whereas releasing it is the one way to actually lose access to the file. Two files moved in quick succession — a rename followed by a drag into another folder, or an iCloud reorganisation — are followed all the way, with the notes taken from where they actually are rather than from the intermediate location the document only passed through; before this they were left behind at the original path while everything reported success. And if the notes cannot be written to their new location, you are now told so, with the same alert Save As raises, instead of the notes quietly ceasing to be the document's. - `HTMLImageSourceRewriter` no longer re-emits a mediated `src`/`srcset` value with an embedded quote character left unescaped (T-1942). The rewriter always re-emits these attributes double-quoted, but a value could still contain a raw `"`: the `rewrite` closure's `data:` passthrough hands unencoded `data:` URIs back unchanged, and `rewriteSrcset` re-joins a candidate's descriptor half — never passed through `rewrite` — verbatim. Either one could terminate the re-emitted attribute early, splicing the remainder into attribute position (e.g. `srcset='a.png 1x" onerror=… z='`). The value is now escaped for its double-quoted context before being written, so any quote characters it carries round-trip intact instead of breaking out. The escape leaves a character reference the value already carries alone (the `data:` passthrough re-emits the attribute's text as written, references undecoded, and the browser decodes it once), so an SVG `data:` URI whose author correctly wrote `&` for a literal ampersand still renders that ampersand rather than the reference. This is defence in depth rather than a live exploit: the subsequent `HTMLSanitizer` (SwiftSoup) pass is the actual security boundary and already reduced the broken-out remainder to non-allowlisted junk.