fix(staging): launch tagged builds in automation mode

[BenevolentFutures]

Summary

• Scrub inherited C11/CMUX surface, workspace, surface-number, tab, and panel identity from tagged launches.
• Launch Release/staging builds with an automation-mode socket so an external CLI can reach the staging instance.
• Document staging socket and QA-launch behavior in the c11 hotload skill.

Validation

• git diff --check
• bash -n scripts/reloads.sh scripts/reload.sh scripts/reloadp.sh scripts/launch-tagged-automation.sh
• Release staging proof from inside c11 with sentinel identity variables and C11_QA_LAUNCH=fresh: ** BUILD SUCCEEDED ** in 662 seconds.
• External C11_SOCKET_PATH=/tmp/c11-c11-219-staging-launch-env-proof.sock c11 ping: PONG.
• External c11 tree --no-layout returned the ready staging workspace.
• Staging process environment contained C11_SOCKET_ENABLE=1, C11_SOCKET_MODE=automation, and C11_QA_LAUNCH=fresh; no C11/CMUX identity sentinels remained.
• Staging app, sockets, and temporary DerivedData were removed after validation.

The runtime probe ran before rebasing onto the current origin/main; exact-head shell and diff checks passed after the rebase, and hosted CI is the final exact-head gate.

Scope

reloadp.sh remains unchanged because it is the untagged production Release path. Installed skills were not synchronized, per ticket scope. No merge or deployment was performed.

[github-actions]

Summary

This PR fixes two genuine defects in the staging launch path (reloads.sh): inherited c11/cmux surface & workspace identity leaking from the launching shell into the staging app, and the staging Release build binding a socket no external CLI could actually reach. It brings reloads.sh's clean-env scrub closer to reload.sh's (adding C11_SURFACE_ID/C11_WORKSPACE_ID/C11_SURFACE_NUM plus the CMUX_ twins), launches with C11_SOCKET_ENABLE=1 C11_SOCKET_MODE=automation so a local CLI can drive the staging instance, and updates the c11-hotload skill to match. Thank you — this is exactly the kind of dev-tooling correctness fix that quietly saves everyone a confusing debugging session, and the validation writeup in the PR body is excellent.

Alignment

Solidly in scope: socket/CLI correctness plus dev/staging tooling — both explicitly "clearly wanted" per the policy. The change deliberately tracks its sibling launchers rather than inventing a convention: reload.sh already launches tagged Debug builds with C11_SOCKET_ENABLE=1 C11_SOCKET_MODE=automation (scripts/reload.sh:501-503) and launch-tagged-automation.sh defaults to automation, so this closes a parity gap. It correctly routed to deep review — it touches scripts/** (deny-listed) and a skill file, both of which always escalate.

One intended behavior worth naming for the maintainer (not a regression): after this change every reloads.sh launch exposes an automation-mode socket, which SocketControlSettings.swift:44 documents as "external local automation clients from this macOS user (no ancestry check)." That's the same posture reload.sh/launch-tagged-automation.sh already take, so it's fine on a single-operator dev box — just note that staging sockets are now reachable by any same-user process, not only c11-spawned ones. I confirmed the override is honored unconditionally: effectiveMode (SocketControlSettings.swift:754-773) returns .automation given C11_SOCKET_ENABLE=1 + C11_SOCKET_MODE=automation.

Findings

No blockers and no correctness bugs in the launch logic itself. The env -u … KEY=VALUE open invocation, the identity scrub, and the socket-mode override all check out.

1. (minor) reloads.sh still doesn't scrub C11_DEBUG_LOG / CMUX_DEBUG_LOG, unlike reload.sh. This PR squares the surface/workspace/surface-num lists, but reload.sh's OPEN_CLEAN_ENV also unsets C11_DEBUG_LOG and CMUX_DEBUG_LOG (scripts/reload.sh:475,485) and reloads.sh (scripts/reloads.sh:342-366) still does not. An inherited C11_DEBUG_LOG from a parent c11 shell could leak into the staging launch. Low impact and arguably beyond the stated scope, but since you're aligning the two lists, adding -u C11_DEBUG_LOG and -u CMUX_DEBUG_LOG completes the parity in one stroke.

2. (minor) The skill's QA-launch safety sentence no longer holds for the newly-documented reloads.sh path. The new examples (skills/c11-hotload/SKILL.md:77-79) document C11_QA_LAUNCH=fresh ./scripts/reloads.sh --tag <tag>, which works because reloads.sh's OPEN_CLEAN_ENV intentionally leaves C11_QA_LAUNCH/CMUX_QA_LAUNCH in the environment (the new comment at scripts/reloads.sh:51-54 calls this out). But the very next sentence in the skill (line 80, unchanged) says "The launcher unsets any inherited C11_QA_LAUNCH/CMUX_QA_LAUNCH … so a stray value in your shell can't silently flip a normal run into QA mode." That guarantee is launch-tagged-automation.sh's, not reloads.sh's — reloads.sh passes an inherited value straight through, so a stray C11_QA_LAUNCH in the operator's shell would silently flip a reloads.sh run into QA mode. Consider a one-line note distinguishing the two launchers, so the reader doesn't over-generalize the safety claim.

3. (nit) The concrete socket example won't match what lands on disk. skills/c11-hotload/SKILL.md:68 gives /tmp/c11-rel-v0.65.2.sock, but reloads.sh names the socket /tmp/c11-${STAGING_SLUG}.sock where the slug comes from sanitize_path (scripts/reloads.sh:72-80,299,302), which lowercases and collapses every non-alphanumeric run to a single hyphen. So a rel/v0.65.2 tag actually binds /tmp/c11-rel-v0-65-2.sock — the dots become hyphens. A hyphenated example or a plain <tag>/<slug> placeholder avoids a "why doesn't this path exist?" moment. The same applies to the C11_SOCKET_PATH=/tmp/c11-<tag>.sock phrasing on that line, since <tag> is sanitized before it reaches the path.

4. (informational, no action) Skill sync not required here. The PR body notes installed skills weren't synced "per ticket scope." For the record that's correct: c11-hotload is not in skills/MANIFEST.json's installable list, so CLAUDE.md's sync-installed-skills HARD RULE doesn't apply to this edit — nothing to do.

No prompt-injection or other untrusted-content concerns in the diff.

Recommendation

Merge after fixes — the change is correct, well-aligned, and thoroughly validated; finding #1 (debug-log parity) is a quick one-liner and #2/#3 are small doc tightenings that would make the skill airtight. Since mergeable_state is currently unstable and the PR body notes the runtime probe predated the rebase onto origin/main, please confirm the required checks (workflow-guard-tests, remote-daemon-tests, web-typecheck, build) conclude green at the exact head before merging — hosted CI is the real exact-head gate here.

---

🌉 Drawbridge deep review (lane 3) — an automated pass; a maintainer has been notified and makes the final call.

---

🌉 Drawbridge deep review (lane 3) — an automated pass; a maintainer has been notified and makes the final call.