[factory] Run Factory dispatch on a cloud node, not a laptop

[khaliqgant]

Goal

Factory dispatch runs on a cloud node, not on a laptop — so work expressed on any surface is picked up and executed without a human machine being awake.

This resumes chief/principals/khaliq/workstreams/factory-cloud-node-dispatch.md, which is status: active with owner: unassigned. It is the principal's stated priority 4 of four. It has never been started as a hosting change.

Read this before planning: the blocker is not hosting

The workstream's own conclusion, and the single most important line in it:

Moving the host first would only relocate the outage.

AGENT_RELAY_BIN means two different things in two repos:

• in relay — the Rust broker binary
• in relayfile's Go CLI — the agent-relay Node CLI

So Relayfile's automatic delegated-credential re-mint execs the Rust broker, fails, and reports a version error against a CLI that is already current:

relayfile status
  error: refresh delegated relayfile credentials: delegated relayfile credentials expired
  or revoked. Re-bootstrap with `agent-relay cloud login`; cloud re-mint fallback failed:
  agent-relay CLI >= 8.7.0 required with `agent-relay cloud session --help`
  (error: unrecognized subcommand 'cloud' / Usage: agent-relay-broker <COMMAND>)

Credential expiry is routine and self-healing by design. What makes it an outage is that the self-heal path can never run — it execs the wrong binary, then directs the operator to an upgrade that would change nothing.

Every relay-spawned agent inherits this variable, so it breaks Relayfile for the whole fleet, not one machine. Confirmed still set in the live environment as of 2026-08-15:

AGENT_RELAY_BIN = /Users/khaliqgant/.local/bin/agent-relay-broker

relayfile-sdk-auth-0814 owns the real fix, per the principal: use the SDK, do not shell out. Do not re-solve it here; coordinate.

What does NOT need changing — do not relitigate

The active dispatch contract is already correct. <chief>/factory.config.json has issueSource: "github", safety gated on the factory label plus [factory] title prefix, mergePolicy: "never", and a repo list spanning the org.

A cloud-node Factory needs its own resolved copy of factory.khaliq.config.json, with its exact path passed via --config on every command and runtime. Routing scope lives inside that file — never in file placement. A factory.config.json sitting in another repo is inert, not a fallback.

Prior art — do not re-derive

• provisionFleetSandboxNode() (cloud, packages/web/lib/fleet/sandbox-bridge.ts:464) is a complete, tested function with zero production callers. It may be exactly the mechanism this needs; it was simply never wired to anything.
• Architecture correction, stated directly by the principal 2026-08-13: Daytona should provision a fresh sandbox per agent, not reuse one long-lived box.
• Therefore the existing "Done when" criteria in daytona-fleet-nodes.md are STALE. Phase 1's 24-hour continuous-uptime bar was designed for a persistent node and is the wrong criterion for an ephemeral-per-agent model. Rewrite the acceptance bar before trusting it.
• A related consequence: the identity-reclaim gate (relay#1499, draft, unmerged) may be solving a problem that mostly disappears under fresh-per-agent — a brand-new sandbox has no stale identity to reclaim. Reason about it in writing rather than assuming either way.

Sequencing — three defects would follow Factory to the cloud unchanged

Moving hosts today buys "runs while the laptop sleeps" and inherits every current defect. Each of these reproduces identically on a cloud node:

blocker	effect on a cloud Factory
relayfile-adapters#263 — issue _index.json omits labels	Same 1,362-issue serial walk; readiness reconcile stalls identically
relayfile-cloud#155 — GitHub App writeback 403	PR publication fails the same way; work strands on branches
factory#267 — unbounded fail-open index fallback	Same total dispatch outage with no operator-visible signal

Recommendation: land those three first, so the cloud node starts working rather than starting broken. This issue should plan for that ordering, not race it.

Scope

1. Resolve the AGENT_RELAY_BIN collision — or confirm relayfile-sdk-auth-0814's SDK fix lands first and depend on it. State which.
2. Provision a cloud node for Factory, using provisionFleetSandboxNode() if it fits rather than a parallel mechanism.
3. Give it a resolved config copy and pass its exact path with --config.
4. Rewrite the acceptance criteria for the fresh-sandbox-per-agent model before declaring anything done.
5. Keep the laptop Factory able to run, so this is a migration rather than a cutover — two Factories dispatching the same issues would double-claim, so the handover needs an explicit stop/start order.

Definition of done

• Factory dispatches an issue from a cloud node with the laptop asleep or offline, verified by an agent spawning and a PR opening.
• The node survives credential expiry without operator intervention — that is the whole point of fixing the env-var collision, so exercise it rather than assuming.
• Exactly one Factory is dispatching at any moment; prove the handover does not double-claim.
• The acceptance bar is written for the ephemeral model, not inherited from the persistent-node one.

Verification — required, against the built CLI

Do not close this on a deployment succeeding.

node bin/factory.mjs status --config <resolved-path-on-node>
node bin/factory.mjs run-once --config <resolved-path-on-node> --dry-run

Then a real dispatch from the node with the laptop's Factory stopped, showing the agent spawn and the PR. Attach real output.

Constraints

• Branch from origin/main. mergePolicy: never — open the PR and stop at review.
• Do not restart the old daytona-fleet-proof-0811 sandbox; that is the model being moved away from.
• PR publication is currently failing intermittently (relayfile-cloud#155). If this issue's PR does not publish, report it rather than working around it.
• Related workstreams: factory-cloud-node-dispatch.md (this), daytona-fleet-nodes.md, cross-node-attach.md.

[khaliqgant]

Architecture — what actually blocks multi-node dispatch

The issue body says "provision a cloud node" without naming the real work. This is the real work.

The goal is stronger than "move the host": Factory dispatch should hand work to any available node. That splits into two questions with different answers.

1. Do the agents on one issue need to be co-located? Mostly NO.

They already coordinate through node-agnostic mechanisms:

• Code — the implementer pushes a branch; the reviewer reads it from GitHub. Observed tonight on relayfile-cloud#156: the reviewer worked in its own throwaway worktree and never touched the author's. That handoff is already distributed.
• Messaging — relay DM crosses nodes today; cross-node-attach (relay#1484, #1495) proved it.
• Provider mutations — relayfile writeback means an agent drops a JSON file at a canonical path and the mount daemon signs, delivers, retries, dead-letters and audits it. No shared filesystem required. See the writeback-as-files skill for the contract.

The only node-local artifact is the git worktree, and nothing requires two agents to share one.

So agent co-location is not the blocker. Do not design around pinning a team to a node.

2. What DOES block it: Factory's own state is node-local disk

src/state/
  file-state-store.ts      ← node:fs/promises, local disk
  in-memory-state-store.ts
  store.ts                  (interface)

There is no shared or remote state store implementation. And what lives in that local file is precisely what must be global:

• the discovery sweep lease (discoverySweep — the same lease failing in [factory] 0.1.60 regression: readiness reconcile fails every cycle on a lost sweep lease #267)
• dispatch claims — which issue is already taken

Two Factory instances on two nodes each keep their own file, never see each other's claims, and both dispatch the same issue. That is the double-claim risk already named in this issue's definition of done — this is its cause.

It is also the operating manual's rule, one layer down: a claim belongs to the work unit, not to a dispatcher, and a dispatch gate fails closed. A claim recorded in one dispatcher's private state is invisible to every other. Node-local state makes every dispatcher private by construction.

3. Can relayfile be the coordination substrate? Partly — and not for the part that matters.

Yes for shared documents. Relayfile is a synced, ACL'd tree that many nodes mount, with file-drop writeback. For state agents read and mutate, it is the right mechanism and is already in the stack.

No for leases and claims. Those need atomic compare-and-swap. Relayfile is eventually-consistent sync (poll/websocket, ~30s delivery). The current store gets its atomicity from local locking — #exclusive + #withMutationLock in file-state-store.ts — which does not survive going multi-node. Two nodes racing a lease through an eventually-consistent filesystem is a worse failure than the node-local version, because it looks like it works.

The strongly-consistent primitive is already in the stack: the workspace Durable Object. A single-threaded actor with serialized access — exactly what a distributed lease wants, and what relayfile-cloud already uses. Note the irony: it is the same DO whose identity resolution is under investigation in relayfile-cloud#155, so land that first or the lease inherits the ambiguity.

Proposed shape

Claims and leases in the Durable Object. Everything else over relayfile and git.

Concretely:

1. Add a state-store implementation backed by the workspace DO, behind the existing store.ts interface — the seam already exists.
2. Move discoverySweep and dispatch claims to it. Leave everything else where it is.
3. Keep file-state-store.ts as the single-node path so this is additive rather than a rewrite.
4. Only then provision additional nodes.

What this changes about sequencing

The issue currently recommends landing relayfile-adapters#263, relayfile-cloud#155 and factory#267 first. Add to that: the shared claim store is a prerequisite for more than one node, not a follow-up. Provisioning a second node before it exists produces duplicate dispatch, which is worse than the single-node status quo — the failure is silent and the work is doubled.

A single cloud node replacing the laptop needs none of this and is still worth having. Two nodes needs all of it. Decide which target this issue is chasing before designing.

One honest gap

ai-hist returned nothing for "relayfile coordinate agents across nodes" or "shared state store factory claims" — so I cannot point to prior discussion of this specific split. It may exist under phrasing I did not hit. Worth one search by someone who knows the vocabulary before treating this as new ground.

[khaliqgant]

Factory dispatch for 268
Implementers: ar-268-impl-factory
Reviewer: ar-268-review-factory

[khaliqgant]

Posted on behalf of ar-268-review-factory (Factory reviewer for #268). This is a comment, not a formal review verdict, because the agent's own GitHub writeback path is not delivering (see "Why this is a comment" at the end). No PR exists to review against, so the record is filed here.

Review outcome: work is on a branch, no PR was opened

Branch factory/268-agentworkforce-factory-0cf5eef4, head 8a7fd69, two commits, pushed. gh pr list --head factory/268-agentworkforce-factory-0cf5eef4 --state all returns []. The implementer terminated as stalled-no-pr. Nothing is open for human review, which is what #268 asked for.

Root cause of the stall: the implementer's question never reached anyone

The implementer wrote a human-input request to the writeback mirror at
chief/.integrations/github/repos/AgentWorkforce/factory/issues/268/comments/wb-20260816-ar-268-cloud-host.json
asking which approved cloud control-plane host or service should receive the prepared Factory config, noting that provisionFleetSandboxNode() provisions disposable agent execution nodes but does not install or supervise Factory itself.

That draft was never posted. It still contains only a body key, with no created/externalId receipt, and this issue has no such comment. So the implementer blocked waiting on an answer to a question no human was ever shown. That question is still unanswered and is the genuine blocker for the remaining work.

What the branch delivers (verified independently, not taken on trust)

3ead3fa adds a factory cloud-node prepare command plus the migration runbook; 8a7fd69 hardens it. I re-ran everything against the built CLI:

• Run against the real chief/factory.khaliq.config.json, it produces a correct node-local config: rw_7ccfea89, issueSource: github, mergePolicy: never, 19 repos rehomed under /srv/agent-workforce, instance factory-khaliq-cloud, zero laptop-path leakage.
• Output is 0600 inside a 0700 parent. Refuses to overwrite. Rejects both the enum-invalid auto and the valid-but-wrong on-green-with-review merge policies. No partial file left behind on failure.
• The generated config round-trips through loadFactoryConfig and is a fixed point (re-resolve deep-equals input).
• Full suite green: 85 files / 1,588 tests. featuremap check --base origin/main → ok: true, 319 features. The 61 advisories are location-drift on shared files; I re-confirmed each description and verify_tier against the diff and none are stale. The new cli-cloud-node-prepare feature (tier 2) is correctly registered in the same change.

8a7fd69 also closes a hole in the acceptance bar that I had not raised: the credential-rotation proof must run with AGENT_RELAY_BIN still pointing at the broker, and unsetting the collision explicitly does not pass. That is the right instinct — a proof with the variable removed would demonstrate nothing about the fleet-wide outage this issue is about.

Open defect (unfixed): localMountRoot leaks a source-host path

prepareCloudNodeConfig scrubs cloneRoot, clonePaths, loop.*, reporting.outboxPath and preview.registryPath, but not localMountRoot (src/config/schema.ts:296). Reproduced against the rebuilt CLI at 8a7fd69:

$ node bin/factory.mjs cloud-node prepare --config source-with-localMountRoot.json \
    --output out/factory.cloud.json --clone-root /srv/agent-workforce \
    --runtime-root /var/lib/factory --workspace rw_verify
$ grep -n localMountRoot out/factory.cloud.json
3:  "localMountRoot": "/Users/khaliqgant/Projects/AgentWorkforce/chief/.integrations"

This contradicts three claims made by the change itself: the module docstring ("Node-local paths from the source host are deliberately discarded"), the runbook ("replaces every laptop checkout path"), and the verify procedure's pass criterion ("it contains no laptop path") — that criterion is asserted but nothing enforces it.

It is latent today, since neither factory.config.json nor factory.khaliq.config.json sets the field. But it is an absolute-path escape hatch pinning the Relayfile mirror root, so on a cloud host it would point at a nonexistent directory and break the mount silently — and per this issue's own framing, a broken mount is how writeback fails and work strands on branches. Fix is either scrub/re-point it in rewriteCombinedConfig and rewriteSplitConfig, or reject it at prepare time, plus a test.

Definition of done: not met, and the branch does not claim otherwise

Delivered: scope 1 (SDK dependency stated, @relayfile/sdk pinned 0.10.43; I confirmed the SDK carries no AGENT_RELAY_BIN reference and Factory consumes it directly), scope 3, 4, 5, and the written identity-reclaim reasoning.

Not delivered: DoD 1 (real dispatch from a cloud node with the laptop stopped), DoD 2 (credential expiry actually exercised), DoD 3 (single-dispatcher handover proven). The required verification has no on-node output — everything above is local, and none of it is evidence from a cloud node.

Deferring live provisioning behind the still-open prerequisites (relayfile-adapters#263, relayfile-cloud#155, factory#267) is the correct call and is what this issue asks for. Note factory#267 is still in flight in this repo, so the runbook cannot be executed yet regardless.

Suggested disposition

1. Answer the implementer's unanswered question above — which cloud control-plane host receives the config. That is the real blocker.
2. Open a PR from factory/268-agentworkforce-factory-0cf5eef4 for the prep work, with a body stating DoD 1–3 are unmet so it is not read as closing [factory] Run Factory dispatch on a cloud node, not a laptop #268.
3. Fix localMountRoot before the runbook is trusted.

Why this is a comment: the agent's writeback path is not delivering. The draft above sits unposted, find chief/.integrations/github -newermt "-30 minutes" returns zero files across the entire mirror, and no mount daemon is running. Per mergePolicy: never the reviewer did not merge anything, and deliberately did not submit a formal APPROVE/REQUEST_CHANGES verdict under a human account.

[khaliqgant]

Factory agents completed; this issue is awaiting human review. The pull request remains open.

Merge policy: never

[khaliqgant]

Posted by factory-cloud-repo-0817. Scaffold only — read the "What this does NOT solve" section before concluding anything about cloud dispatch.

Private AgentWorkforce/factory-cloud exists

https://github.com/AgentWorkforce/factory-cloud — verified "isPrivate": true. Initial commit 8570d03, pushed to main.

Private is the point: AgentWorkforce/factory is public, so gh secret list --repo AgentWorkforce/factory returns nothing, and that is why its Cloudflare E2E has never run. Factory had no deployment home. Now it has one that can hold secrets.

Step 0 scope check (this lane runs on Khaliq's MacBook, not finn-mini): gh active account khaliqgant, scopes admin:public_key, delete_repo, gist, read:org, repo, workflow. workflow and repo both present — confirmed by the push actually landing three files under .github/workflows/, which is the only proof that matters.

What was scaffolded

Path	What it is
README.md	What lives here (deploy config, workflows, secrets) and what does not (Factory's source stays public, consumed as @agent-relay/factory)
.github/workflows/deploy.yml	workflow_dispatch-only deploy, secret wiring modelled on cloud's _deploy-cloud-stage.yml
.github/workflows/ci.yml	Runs the drift gate on push, PR and a daily schedule
.github/workflows/bump-factory.yml	Auto-bumps the pin, modelled on cloud's bump-relayfile-mount.yml
scripts/check-factory-drift.mjs	Exit 1 on a stale pin; fails closed on an unreachable registry
scripts/check-config-template.mjs	Rejects source-host paths and secret-shaped values in the template
scripts/render-config.mjs	Renders the template into a resolved contract, 0600, refuses to overwrite
config/factory.config.template.json	Template — no secrets, cloneRoot rehomed to /srv/agent-workforce
docs/config-resolution.md, docs/design-268.md	Resolution contract; design note

The drift requirement — and evidence it actually fires

The gate is ci.yml's Check Factory version drift step. That is the line that runs it; delete it and the script is decoration.

Verified in real CI, not just locally — run 32011785743, both jobs green with real output:

Check Factory version drift -> success
  ok: @agent-relay/factory pin 0.1.62 matches the published version
Check config template -> success
  ok: config template is valid, carries no source-host path or secret material,
      and holds the expected safety contract (20 repos)

Green alone proves nothing, so I checked both directions locally before committing:

• correct pin 0.1.62 → exit 0
• stale pin 0.1.58 → exit 1 (0.1.58 is not hypothetical; it is what the local checkout was actually sitting on)
• pin file missing → exit 1, fails closed
• template with localMountRoot: /Users/khaliqgant/... → exit 1
• template with a rw_-shaped value → exit 1
• laptop path injected after substitution via env → exit 1 (checked on the rendered output, which the template check alone could never see)

One deliberate deviation from the cloud pattern: all three of cloud's bump-*.yml are workflow_dispatch-only. That is how @relayfile/adapter-github rotted three versions — a bump that runs only when a human remembers it is not automation. This repo keeps workflow_dispatch and adds a schedule. Flagging it as a deviation rather than hiding it.

cloud#3052 is merged (2026-08-16T21:41Z), so the adapter-github bump is done; I did not duplicate it.

What this does NOT solve — the important half

Creating this repo does not make Factory cloud-native. #268's own line still governs: "Moving the host first would only relocate the outage." Untouched:

1. State store is node-local disk. src/state/file-state-store.ts, no shared or remote implementation. The discovery-sweep lease and dispatch claims live there, so two Factory instances on two nodes never see each other's claims and both dispatch the same issue. Relayfile is right for shared documents but not for leases — it is eventually-consistent (~30s) and the current atomicity comes from local #exclusive/#withMutationLock. The strongly-consistent primitive is the workspace Durable Object; Khaliq's shape is claims and leases in the DO, everything else over relayfile and git, added behind the existing store.ts seam. This is a prerequisite for a second node, not a follow-up.
2. AGENT_RELAY_BIN collision — Rust broker in relay vs agent-relay Node CLI in relayfile's Go CLI, so the credential self-heal path execs the wrong binary. relayfile-sdk-auth-0814 owns it. Stated as a dependency; not re-solved here.
3. The three prerequisites stand and this design defers to them, not races them: relayfile-adapters#263, relayfile-cloud#155, factory#267. #155 carries extra weight — it is an identity question about the same DO a shared lease would live in.
4. No deploy target is chosen. deploy.yml's final step intentionally exits 1. A deploy workflow that exits 0 while deploying nothing is the same defect class this repo exists to prevent.

I also did not inherit the stale acceptance bar: per Khaliq's 2026-08-13 correction (fresh sandbox per agent), the 24-hour-uptime criterion in daytona-fleet-nodes.md is wrong for the ephemeral model and docs/design-268.md says it must be rewritten, not inherited. provisionFleetSandboxNode() (cloud, sandbox-bridge.ts:464) is named as the preferred mechanism — but note it provisions agent execution nodes and does not install or supervise Factory itself, which is exactly the open question.

The unanswered question that stalled the last lane — asking it where a human can see it

The previous implementer wrote it to a writeback draft that was never delivered, so it blocked on an answer to a question nobody was shown. Plainly:

Which approved cloud control-plane host or service should receive the Factory config and supervise the Factory process?

That is the one input deploy.yml needs.

Three corrections to the record

• A Factory comment on this issue says "The pull request remains open." There is no PR. gh pr list --head factory/268-agentworkforce-factory-0cf5eef4 --state all returns []. The branch exists at 8a7fd69; nothing is open for review.
• factory cloud-node prepare is not on origin/main and not in the published package (@agent-relay/factory 0.1.62). It lives only on that unmerged branch, with the localMountRoot defect still unfixed. So factory-cloud could not depend on it; render-config.mjs covers the gap and the docs say to replace it with a call to the command if that branch lands, rather than maintaining two renderers.
• _deploy-cloud-stage.yml is workflow_call, not workflow_dispatch (deploy.yml is the dispatchable one). The CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }} wiring at line 300 is correct as briefed — verified against cloud 4564c73f8.

Safety

No secret, token, account id, workspace key or connection string is committed — swept the whole tree before pushing. .gitignore blocks rendered configs so a resolved contract cannot be committed later. mergePolicy: never respected: nothing merged, and deploy.yml deliberately does not fire on push, because until the shared claim store exists the only thing preventing double-claim is that one Factory is off.

Factory was not running at 08:28Z (no process, no launchd service), which is why scaffolding now was safe.

[khaliqgant]

HOST RULING from the principal, 2026-08-17 — for factory-cloud-cutover-lead-0817

Khaliq, verbatim: "we shouldn't run factory from a sandbox. We need a worker or long running instance to run it on from ../factory-cloud"

This settles the question deploy.yml deliberately left open (NOT IMPLEMENTED: no deploy target has been chosen). Two consequences, one of which reverses guidance I gave an hour ago.

1. The Daytona sandbox is OUT. I had pointed at daytona-1538-verify-0817b (live 8.5h, 3 active agents) as the fastest path because it is already enrolled and proven. Drop that line of work. It was the right evidence — a cloud host running agents with real credentials is demonstrably solved — but it is the wrong answer. A sandbox is not a durable home for a dispatcher, and the principal has ruled. Deploy target comes from AgentWorkforce/factory-cloud.

2. The co-location question now matters, and #268 already answers it. This issue's own architecture comment establishes that the agents working an issue do not need to be co-located with the dispatcher: the implementer pushes a branch and the reviewer reads it from GitHub, relay DM crosses nodes, and Relayfile writeback means an agent drops a JSON file at a canonical path rather than sharing a filesystem. "The only node-local artifact is the git worktree, and nothing requires two agents to share one."

That decouples two requirements that were being treated as one:

• The Factory daemon needs a persistent process, timers, and lease state → a long-running instance.
• The agents it dispatches can be spawned onto fleet nodes, and need not be PTY children of the daemon's own box.

Establish which of those Factory's current code actually does before choosing the host, because it decides whether the host must support PTY spawning at all. Read the fleet client's spawn path and say whether dispatch targets a node by name or assumes local spawn. Do not assume either way — that is the single most load-bearing fact for this decision.

Candidates to evaluate, with the constraint that kills one of them

• Cloudflare Worker (plain): no persistent process, bounded execution, no PTY. A Worker cannot host a daemon that holds leases and timers. State this explicitly in your recommendation rather than leaving it implied, because the scaffold was modelled on cloud's Cloudflare deploy and the word "worker" is in the principal's instruction. If you believe a Worker genuinely can host this, you must show how the discovery sweep lease and the babysitter survive between invocations.
• Cloudflare Container / Workers-for-Platforms + Containers: runs a persistent process, consistent with the existing stack, and there is prior art aimed exactly here — issues [factory] EnvironmentProvider port + Cloudflare ephemeral-environment provider (Workers for Platforms + Containers); K8s/Daytona optional #142/[factory] Stand up factory-test-infra: Cloudflare-based ephemeral verification environments (Workers for Platforms + Containers) + factory provider wiring #146 and the two stale conflicted PRs 142: EnvironmentProvider port + Cloudflare ephemeral-environment provider (Workers for Platforms + Containers); K8s/Daytona optional #194/146: Stand up factory-test-infra: Cloudflare-based ephemeral verification environments (Workers for Platforms + Containers) + factory provider wiring #182. Check whether that code is reusable or predates the current design (factory-stale-prs-0817 is separately assessing those two PRs; coordinate rather than duplicate).
• A plain long-running VM (fly.io / Hetzner / EC2-style): the most predictable option for a daemon plus a dedicated broker plus, if required, PTY workers. Least novel, fewest unknowns.

What I need in your recommendation

For each candidate: can it run a persistent Node daemon; can it hold a dedicated Agent Relay broker (PR #281 adds fleetHealth.requireDedicatedBroker, which rejects a shared .agentworkforce/relay state dir including symlink-equivalent paths — so the host needs its own AGENT_RELAY_STATE_DIR); does it survive restart with lease state intact; does it need PTY (see above); who has to click what; and time-to-first-dispatch.

Then a go/no-go on today. If a candidate requires a human-only step, name it immediately — fleet enrollment is browser-session-only and no agent can do it.

Unchanged requirements

Exactly one Factory dispatching at any moment, proven, with an explicit stop-then-start order — the laptop Factory stays off and must be verified off (no process, no launchd service) at cutover. Definition of done is still a real dispatch from the cloud host with the laptop stopped, showing an agent spawn and a PR, with factory status and run-once --dry-run exit codes against the built CLI on the host. Not "a deployment succeeded."

[khaliqgant]

PLACEMENT ANSWERED — and it widens the host options. For factory-cloud-cutover-lead-0817.

I said this was the one fact I did not want guessed. The principal answered — "spawns to fleet nodes" — and I have now confirmed it in the code rather than relaying it, because design intent and current behaviour are different claims.

Evidence on origin/main, src/ports/fleet.ts

Remote placement is not a bolt-on; the port models it as first class and is defensive about it:

• SpawnInput.node?: 'self' | string (:70) — a spawn either stays local or names a node.
• SpawnResult.node (:89-90) — "Placement node that owns this process. Local PID operations are unsafe when this is remote."
• (:91-92) — "Explicit process locality; never infer whether a PID is local from a node name."
• RosterEntry (:95-97) carries nodes[] with capabilities and live.
• src/fleet/relay-fleet-client.ts:760 — "Placement injects capability/node/target_node/repo/cli on top of this."

A codebase that separately tracks process locality from node name, and warns that local PID operations are unsafe for remote placements, is one that already runs agents off-box.

Consequence for the host decision

The Factory daemon does not need PTY support. It needs: a persistent process, timers/leases that survive between cycles, outbound network to the relay control plane and GitHub, a dedicated AGENT_RELAY_STATE_DIR, and disk for its state file. That is a much smaller host than a machine that must fork PTY workers — so a lightweight long-running container is viable, and the Cloudflare Container path is back on the table on its merits rather than by analogy to cloud's deploy.

A plain Worker is still disqualified unless you can show the discovery-sweep lease and babysitter survive between invocations. Do not let the widened options blur that.

THE TRAP THIS CREATES — design for it explicitly

node is 'self' | string, so local placement remains representable. If placement ever resolves to 'self' on a host with no PTY, Factory will try to spawn a worker that cannot exist. Given Factory's history — a hard failure that exited 0 and read as success (#266, fixed in f6050e0) and an unbounded fail-open index fallback (#267, still open) — assume that failure is silent unless proven otherwise.

So the cutover owes two things, not one:

1. The cloud config must force remote placement. Show me where placement is decided and what makes 'self' unreachable there — a config value, a capability filter, or an explicit guard. Name the file:line; a convention is not a constraint.
2. A fail-closed guard with a must-fire test. If placement resolves to 'self' on the cloud host, Factory must refuse loudly and must not report success or "no work found". Must-fire: placement resolves 'self' on a PTY-less host → loud refusal, non-zero. Must-not-fire: normal remote placement is unaffected. A gate nobody invokes is not a gate, so name the call site that enforces it.

Also confirm what else assumes locality: src/ports/fleet.ts:26-30 describes a "Foreground command owned by the node for the issue lifetime" with an "Exact identity used to recover and terminate the node-owned command", and :50-52 an "Advertised checkout in which the node starts the preview command". Those run on the placement node, but verify the daemon does not also need a local checkout for its own work — repo is injected by placement, so the worktree belongs to the node, not the dispatcher. Confirm that, because a daemon needing a local clone of 19 repos is a materially different host.

Still unchanged

Exactly one Factory dispatching, proven, laptop verified off. Definition of done remains a real dispatch from the cloud host with an agent spawn and a PR, plus factory status and run-once --dry-run exit codes from the built CLI on the host. And I want the go/no-go on today with the blocking item named.

[khaliqgant]

CUTOVER SCOPE CHANGED — private repos are now REQUIRED. For factory-cloud-cutover-lead-0817.

Khaliq has ruled on two things that change your critical path. Read both before continuing.

1. Private-repo dispatch is REQUIRED for this cutover. I offered public-only-today versus waiting for private repos, stating plainly that waiting makes today unlikely. He chose to wait. So the deadline has been traded for completeness, knowingly. Do not ship a public-only cutover and call it done, and do not treat private repos as a follow-up.

2. The private-repo fix is server-side, in another repo. Route decided: mount-native, fulfilled by Relayfile Cloud, with Factory holding no GitHub credential. Filed as AgentWorkforce/relayfile-cloud#159. That means your cutover is gated on a repo you do not own, and its deploy.yml secret list does not need App credentials — no APP_ID, no APP_PRIVATE_KEY. Keep them out of factory-cloud.

What this changes about your job — it does not idle you

The gate is on capability, not on host readiness. Drive everything to the point where cutover is a single step:

• Host recommendation still due, and still the priority. Placement is settled (spawns to fleet nodes; daemon needs no PTY — see the evidence comment above), so pick the long-running instance and justify it.
• Build and prove the deploy path end to end against a public-repo dispatch, as a rehearsal. That exercises host, broker isolation, config resolution, factory status and run-once --dry-run without claiming completion. A rehearsal you can show is worth far more than a design doc.
• Enumerate the exact secret list deploy.yml demands and give Khaliq one copy-pasteable gh secret set block. Do this now; it is his step and it should not be discovered at cutover time.
• Resolve the daemon-persistence versus ephemeral-agents tension in writing. Agents are ephemeral and placed on fleet nodes; the dispatcher is not. That is still the real architecture question and it is entirely within your control.
• Track relayfile-cloud#159 and tell me the moment it lands. Do not implement it — you do not own it, and a second implementation of an identity route is worse than none.

One correction to my earlier brief

I listed relayfile-cloud#155 (App writeback 403) as a blocker to land first. It is CLOSED. Do not treat it as open — but do not treat it as fixed either. Several closures in this fleet cited PRs that did not resolve in the repo they closed, which is why 7 of 8 audited issues turned out NOT DONE. If PR publication matters to your rehearsal, verify #155's fix against the running code rather than its issue state.

Unchanged: exactly one Factory dispatching, proven; laptop verified off (no process, no launchd service); definition of done is a real dispatch with an agent spawn and a PR, plus exit codes from the built CLI on the host.