The Foundation Models seed in macOS 27 beta 4 (26A5388g) answers a plain
`respond(to:)` as if it were driving a tool-calling harness, so free-form
replies now arrive wrapped: a bare JSON object, a fenced ```json block, a
`tool_call: {…}` literal, `[start_x]`/`[No tools needed]` markers, or a
persona preamble ahead of the answer. Every consumer takes the reply's
first non-empty line, so the wrapper landed verbatim in chat titles and
collapsed summaries — dev even carries a commit named
"Nucleic: {task:Update Website Hero Text}". Guided generation
(@Generable) still binds its schema and is untouched.
Add ModelOutput to NucleicProtocol — the one layer the Mac app, core and
the iOS client all link — and run it at each provider's text choke point,
before the existing line-oriented parsing. Plain replies pass through
byte-identical; an all-scaffolding reply yields nil, which is the "no
result" every caller already handles by falling back to its heuristic, so
no new failure path. DelegatedIntelligence unwraps again on receipt: the
mesh is mixed-version and the agent-CLI backend never unwraps.
Also retune the two prompts the seed broke, measured against the live
on-device model rather than by inspection:
- classifyTurn: the old wording let the agentically-tuned seed reason
about what the agent should do NEXT, so it answered AWAITING for
plainly finished turns — 12/17 on a labeled set (3 samples, majority
vote) with 4 false AWAITING, which silently stops autoship. Reframing
it as "a classifier, NOT an assistant" scores 17/17 with none. Guided
generation was tried here and is worse (81% struct, 68% enum). Applied
to both hand-duplicated twins.
- sessionKeywords: 9 of 9 runs returned a JSON/tool-call envelope, one
inventing a fake Package.swift to "search". Anchoring extraction to
terms already in the input returns 9 of 9 clean comma lists.
Tests pin the captured beta 4 shapes verbatim and the classifier clauses
that earned the accuracy, since they read like boilerplate.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Completes §0.2 item 4. HostMsg.runnerPoolCredential (WireRunnerPoolCredential:
poolId/secret/url/updatedAt) is pushed post-hello to control-scope peers the
way relayMembership is (SyncHost.register → ConnectionHandler gate →
defaulted SyncHostBridge.runnerPoolCredential hook), so every trusted mesh
device manages the SAME pool instead of PoP-enrolling its own — which
rotates the secret out from under whoever shared it.
Receivers converge on updatedAt (newest wins): PeerClient routes the push
into AppStore.mergeRunnerPoolCredential, which persists it and hands it to
any in-flight RunnerPoolClient. The credential store upgrades to a JSON
record (legacy bare "poolId.secret" tolerated as distantPast, so any shared
revision supersedes it). RunnerPoolClient now manages the STORED
credential's pool (possibly another device's), resolves the control-plane
URL the credential carries, and only auto-re-enrolls on 401 for its OWN
pool — a rotated shared credential surfaces "re-share from the owning Mac"
rather than silently creating the wrong pool. iOS handles the new event
inertly (Macs are the pool managers today).
Verified: Darwin builds (app + iOS), wire round-trip/tolerance + sync
suites green.
Co-Authored-By: Claude Fable 5 <[email protected]>
The createProject verb landed host-side but nothing sent it. This adds the
client half (CLOUD_RUNTIME §6 "phone-initiated project creation"):
Wire: WireCreateProjectRequest gains an optional requestID;
HostMsg.projectCreated (WireProjectCreated: requestID echo + projectID/name
on success, error message on failure) answers the requesting connection —
additive (.unknown fallback on old clients) with the SyncClient.Event case
+ messageLoop branch per the §11.2 checklist. SyncHostBridge.createProject
now returns the outcome; ConnectionHandler folds a thrown WireError into a
failed outcome so the asking UI always settles.
iOS: Projects tab gains an Add Project sheet (git URL + optional
name/branch, host picker when several live hosts advertise
canCreateProjects), driven by RemoteStore.addProject state — creating →
created/failed, correlated by requestID so a stale reply can't settle a
newer request. The project row itself arrives via the dashboard push.
Verified: macOS nucleicd/NucleicApp builds + protocol/sync suites green;
iOS xcodebuild green; Linux nucleicd build + protocol suite green (167
tests, incl. new round-trip/legacy-tolerance coverage).
Co-Authored-By: Claude Fable 5 <[email protected]>
ANTIMATTER_RUNNER §0.2 item 1, both layers. A fresh runner could pair but
not receive work — startChat needs an existing project and transfer import
rejects unknown ones.
(a) Interim: nucleicd reads NUCLEIC_RUNNER_PROJECTS (git URLs) and clones +
registers each as a controlled project at boot. Idempotent by normalized
origin remote (AppStore.projectMatching(remote:)), so a persistent-disk
reboot never stacks repo-2 clones; a failed seed logs and moves on.
(b) Wire verb per the §11.4 additive recipe: WireCreateProjectRequest
(gitURL/branch/name, decode-defaulted optionals), ClientMsg.createProject
gated on new WireCapabilities.canCreateProjects (decode-default false),
ConnectionHandler control-scope handling into a defaulted-reject
SyncHostBridge hook, AppStore conformance via addClonedProject (controlled
clone; new optional branch passes through git clone --branch), iOS
RemoteStore switches handled inertly, round-trip + legacy-tolerance tests.
Verified: Linux nucleicd build + protocol suite (166 green) in the swift
6.3 container; boot smoke test — seed cloned on boot 1, skipped as already
registered on boot 2; macOS nucleicd/NucleicApp build + protocol/sync/
transfer suites green; iOS xcodebuild green.
Co-Authored-By: Claude Fable 5 <[email protected]>
abkslm
