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
