serve-sim host-side embed-token verification code (the submodule is declared update = none, ignore = all and is not checked out; §4.2's claim was read through the GitHub API against newly-app/serve-sim-fork@newly).
Claude, can we verify this now? If yes, lets put another appendix for this bit
Metro /events endpoint vs stdout parsing. §6.3 proposes parsing because the matcher exists and is tested. Metro's reporter hook would be less brittle. Worth a spike during B, before committing to either.
i didn't quite get this question / problem
Do we keep the local venue driver? It is the dev-container path and unaffected by the venue move, but a third driver is a third thing to keep working.
the local venue driver is still booting desktop app local sessions from what i understand, so this is an internal newly behaviour
Is the sandbox egress guarantee explicit? Modal sandboxes currently have unrestricted public egress and the launcher depends on it (npm, Expo CDN, cp-api). On run.cloud this must become a stated contract term, not an accident of configuration.
i didn't quite get this question / problem
If our sessions contend with paying run.cloud customers for capacity, someone has to decide who loses
always other runcloud customers win, its okay to have downtime on newly, its not okay to have downtime for customers
Do we want run.cloud's spans in our trace at all, if run.cloud is willing? Propagate and echo says we must not require it. Accepting it when offered is strictly better for debugging but makes the two systems' retention and sampling policies interact.
i would say run.cloud should offer otel, other runcloud customers might want to use it too
bootstrap.run.cloud hardcodes the dev cp-api origin (_worker.js:1). Was that deliberate, and what should it point at post-split?
good question, idk
Newly's credits vs run.cloud's billing. If run.cloud owns metering end-to-end, does Newly pre-purchase capacity, or get invoiced in arrears like a customer? This is a commercial decision, not a technical one.
Tim to decide
Does run.cloud get its own Postgres instance, or a separate schema first? Schema-first is cheaper and reversible; instance-first is the honest end state. Recommendation: schema-first during F, instance before G.
separate instance imo
Who owns serve-sim? It serves Newly frontend, Newly desktop, modal-backend and run.cloud simulator sessions. This RFC keeps it shared, but "shared between two independent companies" needs an owner and a release cadence.
run.cloud imo
Fix snapshot/restore before sessions depend on it, or explicitly declare sessions non-snapshotting on run.cloud for now
tim is already fixing it
Dotted edges are the breaks. Gap 2 is the cheap one: the sending half is written and the receiving half is written — only the SDK initialization is missing.
this describes the current implementation (not the proposed one); and it proposes a few places with easy wins
They are linked by an opaque external_account_id — a value, not a foreign key.
instead of hardcoding a custom external field, we could just suport a "metadata" field which would be a json blob, and our cutsomers could send whatever they want in the metadata? wdyt?
which is why Metro observability needs nothing from run.cloud (§6.1).
Metro part i understand, but what about otel spans/traces from sim fleet? how will they propagate back to newly?
Everything inside the box is one deploy, one process, one database. The two products do not call each other; they are each other. Receipts throughout — paths are repo-relative.
what a reviewer might ask is "why is this a problem?"
my answer: - imagine a scenartio where Newly needs a new feature; this new feature lands on run.cloud automatically, even though run.cloud does not need that feature; - imagine a scenario where run.cloud needs a new feature; thsi new feature lands on Newly automatically, even though Newly does not need that feature
this becomes unmaintainable very fast
rungs A and B
what are rungs A and B?
the desktop app
newly desktop app or web app
Baggage
what is Baggage?
Papaya
Papaya is codename for this rfc / rafactor
Splitting
test comment
4. Consent flows Link modal (the consent moment; no Figma frame yet — built from this spec's copy, Winston restyles later). Opened from any + LINK badge, onboarding, or settings. detected: one-click "Use my existing Codex login". Discloses before the click: runs on this computer using your ChatGPT subscription; autonomy mode (interim: "with full access to your computer"; post-containment: "sandboxed to your project folder"); Newly skills note (interim: "adds Newly skills to your Codex"; post-containment: "Newly's skills stay in Newly's own directory"); model/effort shown in the composer; unlink anytime in Settings. installed-no-auth: in-app sign-in (ChatGPT OAuth via codex login, or API key). Completing an in-app login is the grant (method: in-app-oauth | api-key). not-installed: install flow first (existing ConnectCard mechanics), then sign-in. Claude mirrors: shell-token "Enable" adopt = grant with existing-login; claude setup-token OAuth; paste token. Newly-proxy path requires none of this. Onboarding (ConnectOnboardingScreen): the connect step always renders — never auto-skipped by detection or sidecar errors. Detected harnesses show "detected — link?", never "connected". Still skippable ("Skip for now"); Newly Agent works ungranted. Settings: per-harness row = state + link method + mode line. Unlink revokes only Newly's grant (copy: your CLI login on this machine is untouched). Sign out of Codex appears only when method != existing-login. A shell-env Claude token shows provenance ("from your shell environment") and Unlink stops Newly from using it.
this needs design from winston