What the todo said
Voyager began as coop todo #303, written from Dad's rulings in an On Air talk on 2026-10-03. The todo named the engines: Chromium on the Mac "via CEF, bridged into Swift", WebKit on iPhone and iPad, Chrome's extensions kept working, and a superset of Chrome as the bar. Two of those were Dad's rulings. The means were not. CEF as the way to get Chromium into a Swift window, Chromium's enterprise policy for the microphone, and per-tab storage partitions were proposals from WebUI Pippa in the same talk, and they went into the todo without anyone checking them.
So the first thing the plan session did, before a single line of Swift, was treat the todo's means as claims. Each one was checked against a primary source: CEF's own headers and source files, its issue tracker, its branch page, Chrome's release posts, vendor support pages. The result went into docs/ENGINE-EVALUATION.md in the first contract commit, and its short version was blunt: stock CEF is not a superset of Chrome and cannot be embedded in a Swift window the way the todo assumes.
Eight premises, checked one by one
The first version of the evaluation opened with a table of the todo's premises, a finding for each, and a grade. The rows that decided the shell:
- CEF bridged into a Swift window. CEF has two runtime styles. Chrome style is Chrome's own browser layer, with its interface. Alloy style is the one the embedder draws. On macOS, handing CEF a parent
NSViewforces Alloy style (include/internal/cef_types_mac.h), and the source says outright that Chrome style has no native-parent support on macOS, pointing at CEF issue #3294. A Chrome-style window also hosts at most one Chrome-style browser view. - Chrome extensions keep working. Full extension support exists only in Chrome style, and an extension's button, pop-up and side panel need part of Chrome's own interface on screen. There is no extension-management call. So the style that embeds in your window is the style without extensions.
- Nothing is lost against Chrome. Official CEF builds ship without H.264 and AAC (CEF issue #3559). Widevine's Verified Media Path needs a Google-issued certificate. Google has blocked account sign-in from embedded frameworks, naming CEF, since 2021-01-04.
- The smaller premises. The microphone needed no enterprise policy, because an embedder decides each permission request per origin in its own handler. Each browser in CEF can be handed its own request context, which on the Chrome bootstrap is a whole Chrome profile, so splitting logins tab by tab splits each tab's extensions and history too. Keeping only the logins apart while the tabs share the rest, the way Brave's containers do, takes a Chromium patch set. CEF has no call to freeze or discard a background browser. The family app list lives in Firelink's launch catalog, not in the ports table the todo pointed at. And WebKit really is the only engine on iPhone and iPad outside the EU and Japan, which was confirmed.
Put the first two rows together and the premise falls. The Swift window Dad wanted and the Chrome extensions he wanted come from two different CEF styles, and on the Mac you cannot have both in one window.
Every claim carries a grade
What makes the evaluation trustworthy is that it says how each claim is known. It defines the grades at the top:
| Grade | Meaning |
|---|---|
| Verified here | The primary source was read in this session. |
| Measured here | Run on a Mac in this session (added once the probes existed). |
| Research | A research pass read the source; this session did not re-read it. |
| Secondary | A third party's report: a forum, project notes, the press. |
| Unverified | Nobody has shown it either way. These become gate cases. |
The grades are a promise about provenance. "Verified here" means someone in this session opened the file. "Research" means someone opened it, once, and this session is trusting that pass. A reader who doubts a decision can go straight to the weakest grade under it.
The cold read that downgraded four claims
A promise like that is only as good as its audit. Right after the contract landed, a cold read went back over the evaluation asking one question per claim: who actually read this? Four claims carried a stronger grade than their source. The commit that fixed them is titled "grades match who read what":
- Issue #3294 being still open, and Windows and Linux having the feature since 2022: true, but read by a research pass, so Research.
- The Manifest V2 flags removed in Chromium 150 and 151: a secondary report, so Secondary, with Chrome's own timeline graded separately.
- What Brave's containers share across containers: reported, so Secondary.
- The cells about extensions and sign-in in the table of possible shapes: expectations drawn from the sources, now labelled as things the gate would measure.
None of the four changed the conclusion. That is the point of doing it anyway. A grade you never lower is decoration. The downgrade also left the source-backed core standing alone: the native-parent limit is in CEF's own source, read in that session, and that was the row that decided the shell.
What the check left on the table
The first evaluation did not rule anything. It described four shapes the Mac app could take: Chrome's own window with Voyager's pieces attached, Voyager's window with a Chrome-style child per tab, a Chromium fork with a Swift front, or a companion around an existing browser. Each came with its cost, and an engine gate was set before any shell code. Dad then asked what a fork would really cost, which is the next lesson, and after that asked for WebKit to be compared again. That comparison is where the premise finally gave way.
The repo kept the lesson as a house rule. Its CLAUDE.md says what an engine "can do" was wrong once already in this project, and that a claim about the engine goes into the evaluation with its source and date, or it is not a claim the repo makes.