Inside Nexus Factory: Shipping Dark (Oct 27–Nov 6, 2026)

A behind-the-scenes look at ten days of changes to Nexus Factory, AllCode’s autonomous software factory. Every change below is on dev-main, none of it has landed on main yet, which has been quiet since October 23.

---

The window at a glance

This stretch had one clear headline and two supporting threads:

1. “Ship Dark”: the factory learned to wrap its own changes behind LaunchDarkly feature flags, merge them off by default, and ramp them up autonomously while watching real health signals. This is the biggest capability added in months.
2. An independent, author-blind checker as a new merge gate: a second opinion on every change that isn’t the same model grading its own work.
3. Reactor, dispatch, and cold-start reliability: a long tail of fixes closing out duplicate-dispatch, stuck-in-Coding, and cold-AgentCore-boot failure modes that were otherwise eating into every other feature’s reliability.

---

1. Ship Dark: autonomous, LaunchDarkly-guarded rollouts

This is the real story of the window, and it built in clear stages.

Stage 1: a merge kill-switch (Oct 29)

The capability started defensively: 0f43ec13 added a multi-tenant LaunchDarkly merge kill-switch, a per-org SDK key, resolved the same way GitHub credentials already are (fb367f84, c127dddb, a fail-open LD management API client). dc683839 wired it so merge dispatch itself is gated on the switch, with 60fde200 covering the hold/dispatch paths in tests. 3089f2b0 made the SDK key self-service in org Settings instead of requiring an ops ticket. A nasty crash loop surfaced immediately after (2b8b65a6, missing rustls CryptoProvider at startup breaking every LD evaluation) and was fixed same-day.

Stage 2: flag-wrapping every change (Oct 30–31)

Once the kill-switch existed, the next question was: can the factory wrap every user-facing change in its own flag automatically? 6b1f2d2c marks which recipes are user-facing and need deterministic flag-wrapping; 4f6f8472 and 2af3aaf5 thread that flag-wrap marker and key through the recipe spine and coder dispatch input; ddf04bd8 pre-creates the LD flag OFF before the merge even happens, so nothing is ever live by accident. b71fe013 adds the matching cleanup recipe for flags that are no longer needed, and e232437a adds the management-API plumbing to set/read a percentage rollout.

Alongside this, a second, independent safety net started forming: 8b61a883 (fail-open rollout_health signal module) and 73fdd620 (a meta-gated autonomous reconcile tick), the skeleton of a system that doesn’t just flip flags on a timer, but watches whether doing so is actually safe.

Stage 3: real health signals and the rollout driver (Nov 1–5)

The project page got a face: c570ec1f added a LaunchDarkly connector card to project Integrations, and over Nov 1–2 it grew into a full per-project (not just per-org) connector, 1910980e resolves secrets per-project before falling back to org-level, 497f746e keys those secrets on the engine’s application_id, 2c4b8413 makes the whole thing fail-closed for opted-in projects instead of silently borrowing org credentials, and c6b596cf auto-provisions the control/gate flags on connector save so nobody is hand-creating LD flags. 0004e3dd, 44e2a02a, 2a5825ba, 554821a1, and bee93e78 rounded out the UI (permissions, on/off toggles, a “View in LaunchDarkly” deep link, layout fixes, and a plain-language explainer).

Then the actual health signal arrived: 90faa501 adds per-project CloudWatch health with baseline/control comparison, 3e00b5d2 lets you configure which CloudWatch metric to watch per project, and bef4c710 adds a real dwell-time signal (how long a flag has sat at its current percentage) plus decision logging. 1c7422d1 activates the guarded rollout end-to-end, selecting between the injected demo signal and the real CloudWatch one. f7dffc26 fixed a basic but critical bug here, the driver computed rollout state correctly but never actually started a rollout. 777da42a and b09b7771 exposed the rollout status through the engine API for the dashboard, and 20be4a16 + 3196b57e shipped the Autonomous Rollout status card on the dashboard, complete with demo controls to simulate a healthy vs. regressing flag.

Stage 4: flag hygiene and traceability (Nov 5–6)

With flags now being created autonomously, sprawl became the next problem: 342ba60a tags every factory-created flag and adds a gated, dry-run-by-default lifecycle reconcile that skips creating flags nothing references anymore. The closing stretch (Nov 6) is almost entirely about traceability, b28a07e7 links every rollout and task back to its origin (work order → LD flag → GitHub commit), cb9f612e tags flags with requirement/task IDs, 9eb4ba2e backfills origin tags onto flags that predate the tagging, e0aa878b makes sure a flag link in the UI never points at a flag that doesn’t actually exist in LD, and c845eaba + 1bb38925 surface a requirement’s feature flags directly on its detail page in the SPA.

Net effect: the factory can now take a change, ship it dark, ramp it autonomously against a real health signal, and show you, end to end in the UI, exactly which flag controls which requirement and which commit it came from.

---

2. An independent checker as a merge gate

A separate, smaller but philosophically important thread: 28fbf757 introduces “Track E”, an independent checker as a P1 intent-compliance merge gate. The idea is a held-out, author-blind check that the coder never sees while writing the change, so it can’t be gamed by a model that just satisfies its own test cases.

Supporting pieces: 4f856f88 (checker verdict type + pure logic), 6081b9af (author-blind held-out acceptance case store), 7e306bdb (the actual merge-gate rule: require positive evidence, not just absence of failure), 2f588f25 (an append-only, secret-free evidence pack recording what the checker saw), and bbd6a688 / 9bfdf05e (typed acceptance criteria with a held_out marker, partitioned off the task record at ingest so the coder genuinely can’t read it). 892a95bf adds an opt-in property-based-tests coder capability in the same spirit: generate cases instead of trusting hand-written ones.

---

3. Reactor, dispatch, and cold-start reliability

A long tail of fixes, mostly invisible to users but load-bearing for everything above:

• Duplicate dispatch (Oct 27): ae29c5f4 adds a synchronous action_handles guard closing the duplicate-dispatch window; 6956d399 stops terminalize_runtime_action from racing an in-flight dispatch; 3e9db2fd treats transient AgentCore 424/500s as retryable warming instead of a hard failure.
• Cold AgentCore boots (Oct 28): a cluster of runner fixes for the “no warm capacity provider” world, resetting a dirty repo workspace on container reuse (9c92daf, ed7a566e), bumping orphan-exit idle grace from 5 min to 30 (284ab481) after observing healthy agents go quiet for ~5 minutes, and not orphan-exiting a runner that’s actively making progress (50a93597).
• Stuck-in-Coding / merge stalls (Nov 1–5): d688c589 ends “the last task in a chain hangs forever” bug by reaping tasks stuck in Coding/Inspecting; 65a6ad40 adds a per-task re-dispatch thrash guard; cfd13074 raises the engine ALB idle timeout 60s→300s after finding it was the root cause of merge 504s; 520cb40e and 4c6a7c25 fix merge conflict-handling so a “patch did not apply” is a retryable 409, not a terminal failure, and cloud merges now do a real 3-way merge instead of a patch replay at trunk.
• Engine liveness (Nov 1): 131eb964 adds a watchdog so a hung engine auto-restarts instead of staying dead for hours; 493206d7 keeps the ALB health check a plain 200 and moves reactor-staleness detection to a dedicated /health/reactor path so one doesn’t mask the other.
• AgentCore warm-keeper: ec358cb5 fixed the warm-keeper actually booting a cold VM (it had been a 5-second no-op), and 6f0df4b5 fixed the warm-keeper session ID being rejected for being under AgentCore’s 33-character minimum.

Several of these went through a fix → revert → re-fix cycle in the Nov 3–5 range (visible in the log as e.g. 8bd5c9a0 → d45ee70b revert → later re-applied), a sign of a genuinely gnarly concurrency area, not churn for its own sake.

---

Takeaways

• “Flag-as-you-build” is a real, incremental system now, not a one-off integration: create dark → verify dark → ramp against a real signal → clean up → trace back to origin. Each stage shipped independently and in the right order.
• An independent, held-out checker is a meaningfully different safety property than more unit tests: it specifically defends against a model satisfying criteria it can see.
• Idle-timeout and liveness tuning (ALB 60s→300s, orphan grace 5min→30min) came from observed behavior, not guesses: both cite the specific symptom that led to the number.
• Everything here is still on dev-main. None of it is in production yet; expect a main merge (or a batch of them) once this stabilizes.

Built by AllCode. Watch live pipeline progress at nexusfactory.allcode.com.