[sxh313]

What

Both places that describe the Sandbox link Apple's Containerization framework to
https://developer.apple.com/documentation/containerization, and that URL is dead - it serves Apple's
documentation 404 page ("The page you're looking for can't be found.").

README.md:83      ... powered by Apple's [Containerization](https://developer.apple.com/documentation/containerization) framework.
docs/SANDBOX.md:5 The Sandbox is a shared Linux container powered by Apple's [Containerization](https://developer.apple.com/documentation/containerization) framework.

Evidence that it is really gone (not a bot block)

developer.apple.com renders its docs as a client-side app, so an HTTP status alone is not proof. I
checked it in a real browser: the page loads, the nav bar renders, and the body is the heading
"The page you're looking for can't be found." with a docs search box. For comparison, a live tech
reference requested the same way in the same session returns content:

$ curl -o /dev/null -w '%{http_code}\n' https://developer.apple.com/documentation/containerization
404
$ curl -o /dev/null -w '%{http_code}\n' https://developer.apple.com/documentation/swift
200

Case variants and plausible successors were all probed and all 404: /documentation/Containerization,
/documentation/containerization/framework, /documentation/containerization/frameworks,
/documentation/containerizationcontainer. So the technology has no developer.apple.com reference
page right now.

Where it points instead

Apple publishes the framework's DocC documentation on its own GitHub Pages host, which is live and
complete - the root page renders the full symbol navigator (136 symbols, e.g. ImageStore,
LinuxContainer) rather than a stub:

https://apple.github.io/containerization/documentation/containerization/

That is Apple's own org (github.com/apple/containerization -> docs site), so it keeps the reference
pointing at Apple rather than at a third-party writeup. Note that the site's shorter URLs
(apple.github.io/containerization/ and .../documentation) are DocC shell pages ~1.7 KB that only
become the real page once the JS bundle loads; the URL used above is the actual module root, and it is
the one I verified in a browser.

Change

Two files, one line each, link target only - no wording touched:

-Apple's [Containerization](https://developer.apple.com/documentation/containerization) framework
+Apple's [Containerization](https://apple.github.io/containerization/documentation/containerization/) framework

git show --numstat for the commit is 1 1 README.md / 1 1 docs/SANDBOX.md; the repo's CRLF files
were committed with core.autocrlf=input, so no line-ending churn is included.

Not related to this PR

I noticed PR #2669 also does README link hygiene; it fixes relative links and its diff does not touch
either of these two occurrences, so there is no overlap.

[sxh313]

The red test-core job is unrelated to this diff. The single failure is a hung XCTestExpectation in WhatsAppConnectionServiceTests:

##[error]Recorded an issue (Time limit was exceeded: 180.000 seconds)
##[error]Recorded an issue (Expectation failed: an error was expected but none was thrown)
##[error]watchSubscribePassesMediaParametersOnlyWhenIngestionIsOn() (180.058 seconds) 2 issue(s)
##[error]Suite WhatsAppConnectionServiceTests failed after 181.355 seconds with 2 issue(s)

The same suite then passed on the retry 44 seconds later, inside the same job:

2026-09-21T00:12:52Z Suite WhatsAppConnectionServiceTests started
2026-09-21T00:12:52Z Suite WhatsAppConnectionServiceTests passed after 0.737 seconds

This PR changes two markdown links (README.md +1/-1, docs/SANDBOX.md +1/-1), so nothing in it can reach that test; test-core is not green on the current tip of main either (its last run was cancelled). Re-running the failed jobs should come back clean.

[sxh313]

One correction to my last line: test-core is green on the current tip of main (dc6a901), so "not green on main either" was the wrong way to put it. The pre-existence evidence I actually have is two commits back, and it is stronger - the job goes red there on different suites that have nothing to do with each other or with this diff:

main commit	test-core	failing suite
289a522	failure	ChatSessionQueuedSendTests - Caught error: Error Domain=ChatSessionQueuedSendTests Code=2 "(null)"
c4320c8	failure	LocalModelDetectionTests - Expectation failed: (session -> OsaurusCore.ChatSession).isStreamingLocalModel -> false
f1ad85c	cancelled	-
dc6a901 (tip)	success	-

So three different suites (ChatSessionQueuedSendTests, LocalModelDetectionTests, and here WhatsAppConnectionServiceTests) account for the recent red runs, and this one cleared itself on the job's own retry as quoted above. That points at runner-side timing rather than at any of the three diffs - and in this PR's case the diff is two markdown links, which cannot reach Swift at all.

Re-running the failed jobs on this PR is the cheap confirmation; I have not pushed anything to chase the red.

[sxh313]

test-core failed on a runner problem, not on these docs. From the job log: repeated ##[error]Failed to create NSXPCConnection, and the run's own triage reports Mode A — build phase did not complete (no xctest bundle on disk) — xctestbuild never produced a bundle, so no test case was executed. This PR changes only README.md and docs/SANDBOX.md, and CI on main is green as of run 35722532717 (2026-09-22T11:38:00Z), so nothing in the tree looks broken.

I cannot re-run it myself (gh run rerun → "Must have admin rights to Repository"), and I would rather not push an empty commit to nudge the check. Could someone with write access re-run the failed job? If it fails again on a fresh runner I will dig into it properly.

[tpae]

Thanks! Apple's old Containerization docs URL now 404s. I merged main into the branch to resolve a conflict: main's README no longer links there, so the remaining fix is the one link in docs/SANDBOX.md.