feat: two-door install model — paste-gated installer, no artifact stamping, zero-env serving

[benjaminshafii]

What — the two-door model

Every download door now has exactly one honest outcome, and artifact stamping is removed as a concept:

• Landing page → normal app. First-run offers a calm fork as option cards ("Use OpenWork Cloud" / "Join your organization — paste your link") with "Get started" restored as the primary CTA — fixes the welcome-button regression from feat: fail-proof org first connection (guided install link, first-run fork, mismatch guard, verified handoff) #2973.
• Org install page → paste-gated installer, always. /v1/install/:platform 302-redirects to the installer release asset (mac: signed DMG — the zip envelope is gone; win: exe with no filename tag); an operator-mounted dir remains as the optional air-gapped mirror knob (unstamped stream). The normal-app fallback is no longer reachable from the install door.
• The link is the only carrier. Installer resolution is now env → build constants → pasted link. Sidecar, filename-tag, and App-Translocation machinery deleted; the whole class of "renamed exe / dragged .app away from sidecar" bugs is gone. The installer does nothing without a valid org link — no wrong server exists by construction.
• Semi-airgapped by default, zero env vars: the den server only issues redirects (no egress, no bytes); open clients fetch the public asset; the installer talks only to the org server.
• Release pipeline now publishes OpenWork-Installer-mac-arm64.dmg, OpenWork-Installer-mac-x64.dmg, OpenWork-Installer-win-x64.exe on every app release (release-generic-installer.yml folded in as workflow_call; standalone dispatch retired).

Validation

• Fresh Daytona Linux sandbox, full first-connection fraimz on this branch: 7/7 frames PASSED (evals/results/2026-07-22T08-36-35-378Z/, committed in-branch). Flow updated to the paste-gated model: frame 3 asserts the 302 target + bare installer refuses to proceed (no bootstrap written, paste screen shown); frame 4 asserts paste → Acme bootstrap + expired-link error.
• Bare installer gate:
• Paste → org confirmed:
• Closed loop on the org page:
• Unit/typecheck: den-api touched suites 40/40, installer 21/21, den-web + app typechecks, eval-runner 4/4. Full den-api suite failures are identical-by-name to dev baseline (DB-dependent local env), diffed and verified — no regressions.
• Workflows actionlint-validated. Welcome option-cards visually verified (screenshot in thread).

After merge

Trigger a real release (release-macos-aarch64.yml, tag push or dispatch) — it now publishes the three installer assets alongside the app; then the semi-airgapped den + Windows-client simulation runs against those real assets.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-app	Ready	Preview, Comment	Jul 22, 2026 8:44am
openwork-den	Ready	Preview, Comment	Jul 22, 2026 8:44am
openwork-den-worker-proxy	Ready	Preview, Comment	Jul 22, 2026 8:44am
openwork-diagnostics	Ready	Preview, Comment	Jul 22, 2026 8:44am
openwork-landing	Ready	Preview, Comment, Open in v0	Jul 22, 2026 8:44am

[benjaminshafii]

v0.17.38 two-door victory-lap validation update (branded Acme run): stopped on a residual handoff blocker.

What passed before the stop:

• Server on dev reported latestAppVersion: 0.17.38; /v1/install/win-x64 redirected exactly to v0.17.38/OpenWork-Installer-win-x64.exe while server-side GitHub egress was blocked.
• The real released Windows installer downloaded through Den, installed as interactive Administrator with no EBUSY, and wrote the branded bootstrap (brandAppName, brandLogoUrl).
• Custom Den-managed wordmark rendered in the installer and installed app forced sign-in.

Blocker found:

• Den Web proxy handoff still returned openwork://den-auth?...&denBaseUrl=https%3A%2F%2F0.0.0.0%3A3005%2Fapi%2Fden, so I did not use a workaround to finish sign-in. Fix PR: fix(den-api): use public handoff URL for forwarded zero host #3009
• Evidence branch updated: test/two-door-semi-airgapped-evidence @ 7884ec11e.

Key screenshots:

Installer confirm with custom wordmark:

Installed app forced sign-in branded as Acme Robotics Desk:

Den Web signed-in handoff screen before the bad deep link:

[benjaminshafii]

Post-#3009 clean victory-lap validation: Passed.

I restarted the same server/Windows Daytona sandboxes, updated the Den server checkout to latest dev (11fcf6b, including #3009), and reran the skipped legs against the real released v0.17.38 Windows installer with server GitHub egress blocked.

Highlights:

• /v1/app-version reported latestAppVersion: 0.17.38, and /v1/install/win-x64 redirected exactly to the GitHub release installer.
• Server-side GitHub/release egress remained blocked; forbidden ss checks stayed at 0.
• Windows installed OpenWork 0.17.38, rendered Acme branding, signed in as the Acme owner, and reached OpenWork Cloud Connected.
• Handoff returned a public Den Web URL (https://3005-zq1qxjuimk2sonr1.daytonaproxy01.net/api/den), not 0.0.0.0.
• Install page flipped to ✓ Connected — OpenWork is set up for Acme Robotics.
• Expired-link negative check and local macOS installer branding spot-check passed.

Evidence branch updated: test/two-door-semi-airgapped-evidence @ 0a338e692.
Report: evals/results/two-door-semi-airgapped-20260722/report.md.

Automation note: Edge/CDP did not expose the external-protocol confirmation dialog in the Windows sandbox, so I invoked Windows Shell on the exact unmodified openwork:// URL minted by Den Web after the button path created the handoff grant. I did not edit denBaseUrl or write app auth state.

Windows app connected:

Install page connected:

macOS installer branding spot-check: