proposal: network-neutral enterprise installer and signed connect links

[reachjalil]

Proposal

This PR proposes a network-neutral OpenWork Enterprise installer plus signed connect links:

Install one generic enterprise app. It makes no automatic connection to OpenWork Cloud. The organization then supplies its own server and branding through managed JSON, manual entry, or a signed openwork://connect link.

The branch contains a gated reference implementation so product, security, and operations can review the complete flow before activation. Den remains remote infrastructure; the enterprise artifact connects to an organization-managed deployment and omits the standard desktop's local execution stack.

What this includes

• Enterprise installer / no local execution stack: the enterprise builder excludes the local server, OpenCode/orchestrator sidecars, and computer-use helper; guarded IPC refuses local runtime startup.
• Vendor cloud blocked: the unconfigured enterprise shell blocks openworklabs.com and subdomains at the Electron session boundary and explicitly refuses them at the main-process fetch bridge. Customer domains and lookalikes remain allowed.
• Signed link / no credentials: the Ed25519 envelope contains only organization display, branding, server targets, expiry, audience/version, and one-time id. Authentication still follows separately.
• Name, logo, and native icon applied: the accepted claims map into the canonical bootstrap fields; name and icon apply immediately on macOS, Windows, and Linux, while the wordmark flows into confirmation and sign-in surfaces.
• Branding parity: installer JSON, MDM bootstrap, manual setup, and signed links all converge on the same canonical branding and server fields.

Overall concept and benefits

Benefit	Customer outcome
Network-neutral first run	A fresh enterprise install cannot contact openworklabs.com; it waits at Ready to connect.
One distributable installer	IT does not need a separately rebuilt app for every company.
Organization-owned destination	Managed JSON, manual entry, or a signed link points the app to the company's own web/API endpoints.
Full branding parity	Company app name, wordmark, and native app/taskbar icon work through either JSON or signed links.
Verifiable BYOD onboarding	Email can configure devices without MDM while signatures prove the configuration came from an approved issuer.
Explicit consent	The app previews the branded app, organization, and server; nothing is written until the user confirms.
Authentication remains authoritative	The link grants no access and carries no credentials; normal organization SSO/OTP/password sign-in follows.
Smaller enterprise artifact	The macOS arm64 directory build is about 300 MB vs 662 MB standard because the local execution stack is omitted.
Safe fleet lifecycle	Enterprise uses a distinct app id, artifact name, and updater lane, so it cannot silently turn into the standard bundled flavor.

How the installer points to the company's server

The installer itself does not contain a customer URL. It registers the openwork:// protocol with macOS/Windows/Linux. An administrator asks the organization's remote Den deployment to mint a short-lived signed configuration link. When the employee clicks it, the operating system opens OpenWork Enterprise and passes the full link to Electron main.

Electron main verifies the Ed25519 signature, audience, schema version, expiry, one-time id, and HTTPS URLs. The renderer only receives safe display fields. After the employee confirms the exact branded app and host, main verifies the original bytes again and writes the normalized values to desktop-bootstrap.json. Normal organization sign-in then begins.

sequenceDiagram
  actor Admin
  participant D as Organization's remote Den
  participant OS as Employee OS
  participant E as OpenWork Enterprise
  participant B as desktop-bootstrap.json

  Admin->>D: Create connect link
  D-->>Admin: Signed openwork://connect token
  Admin->>OS: Send by email or portal
  OS->>E: Open registered openwork:// handler
  E->>E: Verify signature, expiry, URLs, and replay id
  E-->>OS: Preview Acme Work + Acme Robotics + server
  OS->>E: User confirms
  E->>E: Re-verify original signed bytes
  E->>B: Save company server + branding
  E->>D: Begin normal organization sign-in

Loading

Branding: preserve and extend the JSON solution

The existing openwork-installer.json side-file solution already supports organization branding. This proposal deliberately preserves it. The deterministic installer normalizes that side file into the same canonical local bootstrap schema used by MDM and signed links:

flowchart LR
  M["Managed device / branded installer"] --> J["desktop-bootstrap.json"]
  L["Signed connect link"] --> V["Verify + preview + confirm"] --> J
  P["Manual server entry"] --> J

  J --> N["brandAppName → product/menu name"]
  J --> W["brandLogoUrl → in-app wordmark"]
  J --> I["brandIconUrl → native app/taskbar icon"]
  J --> S["baseUrl + apiBaseUrl → company's server"]

Loading

Company choice	Installer side file	Canonical bootstrap	Signed link	Applied result
App name	appName	brandAppName	brand.appName	Product/window/menu name
Wordmark	logoUrl	brandLogoUrl	brand.logoUrl	Branded confirmation and in-app UI
Native icon	iconUrl	brandIconUrl	brand.iconUrl	Native app/taskbar icon
Server	webUrl, apiUrl	baseUrl, apiBaseUrl	den.baseUrl, den.apiBaseUrl	Organization deployment
Sign-in policy	requireSignin	requireSignin	requireSignin	Organization authentication gate

The signed token maps one-for-one into the same fields produced from openwork-installer.json, and branding is applied immediately after confirmation.

What improves over a JSON side file

Managed JSON side file	Signed connect link
Best for MDM, offline, air-gapped, and centrally managed machines	Best for BYOD, contractors, pilots, and migrations
IT must place a trusted file at the correct OS path	Admin sends a clickable or pasteable link to a generic installed app
Trust comes from the managed delivery channel	Trust comes from offline Ed25519 signature verification
Applies on startup	Shows branded organization + exact host before applying
Remains until replaced	Expires and is one-time-use per machine

MDM means Mobile Device Management: tools such as Microsoft Intune or Jamf that let enterprise IT install apps and push configuration files/policies to managed computers. MDM remains the preferred path for tightly controlled fleets. The deterministic installer side file remains the strongest air-gapped/preconfigured path. Signed links add a safe path where neither is available; they replace neither.

Network-neutral state model

stateDiagram-v2
  [*] --> Unconfigured
  Unconfigured: Ready to connect
  Unconfigured: openworklabs.com blocked
  Unconfigured --> Preview: Valid signed link
  Preview --> Unconfigured: Cancel / invalid / expired / replayed
  Preview --> Configured: Confirm
  Unconfigured --> Configured: Managed JSON or manual server
  Configured: Company server and branding active
  Configured: Organization sign-in required
  Configured --> Unconfigured: Clear configuration

Loading

The guard blocks the exact vendor domain and its subdomains only. It does not block customer domains or lookalike hostnames, and it re-locks if configuration is cleared.

Reference implementation

• Browser-safe signed-link claim and IPC contracts with explicit brand claims.
• Dependency-free Ed25519 compact-JWS signer/verifier primitives.
• Privileged, capability-gated, rate-limited Den mint/email endpoint.
• Dedicated signing-key env/Helm configuration and rotation guidance.
• Electron main-process verification, confirmation-before-write, serialized replay ledger, and network guard.
• Existing managed JSON, branded installer, manual server, and auth deep-link paths preserved.
• Separate enterprise app identity, artifacts, updater manifests, build lane, and publication support.
• Documentation, threat model, focused tests, real packaged-app E2E, and fraimz proof.

Security properties

• Configuration is not authentication. A link points the app to a server but grants no access.
• The renderer is not trusted. It relays raw bytes; Electron main verifies and re-verifies them.
• No silent reconfiguration. Verified claims become a preview, not a write.
• Fail closed. Unknown keys, tampering, expiry, insecure targets, replay, and replay-ledger failures leave configuration untouched.
• HTTPS by default. Plain HTTP is accepted only for loopback development targets.
• Purpose-bound keys. A dedicated connect-link key and audience are separate from session authentication keys.

Dark-launch and adoption path

1. Review and agree on the contract, threat model, enterprise boundary, and branding mapping.
2. Keep minting disabled behind deployment and organization capability gates.
3. Establish a production signing-key ceremony and ship overlapping public keys for rotation.
4. Pilot managed JSON and signed-link onboarding with a small enterprise cohort.
5. Add hosted admin UI and choose the long-term self-hosted trust-root/JWKS model before broad enablement.

Out of scope

• Connect links do not authenticate users or contain credentials.
• No production key activation, customer-specific trust roots, online revocation/JWKS refresh, or hosted admin UI is enabled here.
• Existing organization install links, MDM bootstrap delivery, manual server entry, and openwork://den-auth remain supported.

Testing

Automated and build proof

• pass: connect-link package 13/13, typecheck, build
• pass: desktop 67 passed / 1 skipped / 0 failed (68 total), Electron typecheck
• pass: app 172/172, typecheck
• pass: Den route 10/10, prerequisite builds, den-api host build/typecheck
• pass: i18n audit
• pass: real macOS arm64 OpenWork Enterprise.app directory package
• pass: packaged enterprise E2E 14/14, including immediate macOS native-icon application from the signed HTTPS URL
• pass: fraimz 6/6 product frames + voice-over coverage on the enterprise shell and local Den stack
• pass: no server, engine/orchestrator sidecars, computer-use helper, or plugin payload found in packaged ASAR/resources

Packaged-app behaviors proved

1. Fresh enterprise install opens Ready to connect with enterpriseNetworkLocked: true.
2. Valid link previews Set up Acme Work for Acme Robotics? and the exact target host.
3. Nothing is persisted before confirmation.
4. Confirmation writes exact Den/API targets, sign-in requirement, app name, wordmark, and native icon.
5. Confirmation changes the build state to enterpriseNetworkLocked: false.
6. The signed square native icon is fetched, validated, cached, and applied immediately (applied: true) on the real packaged macOS app.
7. Replaying the same link is refused without altering configuration.
8. An expired link is refused and writes nothing.

Visual product proof on the final branch: fraimz PR walkthrough.

Docker note

packaging/docker/Dockerfile.den includes the connect-link workspace manifest and sources, and builds @openwork/connect-link before Den consumers. The authoritative Den API artifact build passes in PR CI.

Final CI status

• 10/10 code, package, Helm, i18n, macOS, and Linux checks passed, including the authoritative Den API artifact build.
• Three Vercel previews report Authorization required to deploy (openwork-app, openwork-den, and openwork-den-worker-proxy). These are repository integration/auth gates, not code failures; the landing preview deployed successfully.

Risk and rollback

• Production activation requires replacing the committed evaluation key with a deliberately managed production key and following the documented overlap rotation sequence.
• One-time use is per machine. A forwarded, unexpired link can configure another machine by design, but still grants no authentication.
• The standard desktop remains the default and also understands connect links; existing bootstrap/install/auth paths are unchanged.
• Rollback: disable minting by clearing the signing-key environment pair or the capability gate, remove enterprise artifacts/manifests from releases, or revert these eight commits. No database migration is introduced.

Issue

• Closes N/A

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
openwork-landing	Ready	Preview, Comment, Open in v0	Jul 11, 2026 9:10pm

[vercel]

@reachjalil is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

[reachjalil]

fraimz — ✅ PASSED

1 passed · 0 failed · 0 skipped — run 2026-07-11T07-12-08-395Z

Full frame proof with validated screenshots: evals/results/2026-07-11T07-12-08-395Z/fraimz.html (re-run: pnpm fraimz --flow client-connect-link)

✅ client-connect-link — A clean enterprise client pairs to its company through one signed, confirmed link

User-facing flow demo

1. OpenWork Client starts in a neutral ready-to-connect state

   🎙 A teammate installs OpenWork Client, and it opens not to folders and engines but to a single quiet screen: ready to connect — check your email for your organization's connection link.

   • ✅ Visible text includes "OPENWORK CLIENT"
   • ✅ Visible text includes "Ready to connect"
   • ✅ Visible text includes "Check your email"
   • ✅ The fresh client has no desktop bootstrap configuration
   • 📸 client-connect-link-01-client-ready-to-connect.png — 8 validations passed
2. Acme's admin mints a signed link and the real connect email reaches the dev outbox

   🎙 Acme's admin sends her a connect link, and the "Connect your desktop" email is on its way — org name, logo, and a single button.

   • ✅ The seeded admin can load the Acme organization
   • ✅ Acme exposes an organization id
   • ✅ The admin connect-link route accepts the request
   • ✅ Den reports that the connect email was sent
   • ✅ Den returns one opaque signed connect envelope
   • ✅ The dev outbox contains Maya's connect email
   • ✅ Visible text includes "Connect your desktop"
   • ✅ Visible text includes "Connect your desktop to Acme Robotics"
   • ✅ Visible text includes "it never signs you in"
   • 📸 client-connect-link-02-connect-desktop-email.png — 6 validations passed
3. The client sends the opaque link to Electron for offline signature verification

   🎙 She clicks it and the app wakes, checking the link's signature against the OpenWork key it shipped with before trusting a byte of it.

   • ✅ Electron accepts the signature with the public key embedded for this key id
   • ✅ Visible text includes "Connect to Acme Robotics?"
   • ✅ Visible text does not include "This link can't be used"
   • ✅ Verification alone does not write the desktop bootstrap
   • 📸 client-connect-link-03-connect-link-signature-verified.png — 6 validations passed
4. The confirmation names Acme and its exact server before any write

   🎙 Verified, the app shows exactly what's about to happen — connect to Acme Robotics on Acme's own server — and until she confirms, nothing is written.

   • ✅ Visible text includes "Connect to Acme Robotics?"
   • ✅ Visible text includes "localhost"
   • ✅ Visible text includes "Nothing has been changed yet."
   • ✅ The signed target remains unapplied until Maya confirms
   • 📸 client-connect-link-04-connect-link-confirmation.png — 7 validations passed
5. One confirmation persists Acme's server and hands control to SSO

   🎙 One confirm and it's Acme's app: the company server is set and the familiar sign-in takes over — the link never logged her in, it only told the app where home is.

   • ✅ Confirmation writes desktop-bootstrap.json
   • ✅ The persisted configuration keeps SSO required and applies Acme branding
   • ✅ The derived configured flag is never persisted
   • ✅ Visible text includes "Acme Robotics"
   • ✅ Visible text includes "Sign in"
   • 📸 client-connect-link-05-acme-sso-after-connect.png — 6 validations passed
6. Tampered and expired links are refused without changing Acme's configuration

   🎙 A tampered token or an expired one gets the same calm refusal with a reason, and the app stays exactly as it was.

   • ✅ A tampered token leaves the existing bootstrap untouched
   • ✅ Visible text includes "This link can't be used"
   • ✅ Visible text includes "link has expired"
   • ✅ Visible text includes "Nothing about this app was changed."
   • ✅ An expired token leaves the existing bootstrap untouched
   • 📸 client-connect-link-06-expired-connect-link-refused.png — 6 validations passed
   • ✅ Script frame 1 narrated: "A teammate installs OpenWork Client, and it opens not to folders and engines but to a si"
   • ✅ Script frame 2 narrated: "Acme's admin sends her a connect link, and the "Connect your desktop" email is on its wa"
   • ✅ Script frame 3 narrated: "She clicks it and the app wakes, checking the link's signature against the OpenWork key "
   • ✅ Script frame 4 narrated: "Verified, the app shows exactly what's about to happen — connect to Acme Robotics on Acm"
   • ✅ Script frame 5 narrated: "One confirm and it's Acme's app: the company server is set and the familiar sign-in take"
   • ✅ Script frame 6 narrated: "A tampered token or an expired one gets the same calm refusal with a reason, and the app"

(screenshot upload failed: BLOB_READ_WRITE_TOKEN is not set and could not be fetched from Infisical (infisical secrets get BLOB_READ_WRITE_TOKEN --plain --silent) — run infisical login once, or export it: export BLOB_READ_WRITE_TOKEN="$(infisical secrets get BLOB_READ_WRITE_TOKEN --plain --silent)" — images available in the run directory)

[reachjalil]

fraimz — ✅ PASSED

1 passed · 0 failed · 0 skipped — run 2026-07-11T19-07-32-825Z

Full frame proof with validated screenshots: evals/results/2026-07-11T19-07-32-825Z/fraimz.html (re-run: pnpm fraimz --flow client-connect-link)

✅ client-connect-link — A network-neutral enterprise install becomes the organization's branded app

User-facing flow demo

1. OpenWork Enterprise starts network-neutral and ready to connect

   🎙 A teammate installs OpenWork Enterprise, and it opens without contacting OpenWork Cloud: ready to connect — check your email for your organization's connection link.

   • ✅ Visible text includes "OPENWORK ENTERPRISE"
   • ✅ Visible text includes "Ready to connect"
   • ✅ Visible text includes "will not connect to OpenWork Cloud automatically"
   • ✅ The fresh client has no desktop bootstrap configuration
   • ✅ The enterprise shell reports vendor-cloud networking locked before configuration
   • 📸 client-connect-link-01-client-ready-to-connect.png — 8 validations passed
2. Acme's admin mints a signed link and the real connect email reaches the dev outbox

   🎙 Acme's admin sends her a connect link, and the "Connect your desktop" email is on its way — org name, logo, and a single button.

   • ✅ The seeded admin can load the Acme organization
   • ✅ The reusable eval organization uses Acme's approved name and app brand
   • ✅ Acme exposes an organization id
   • ✅ The admin connect-link route accepts the request
   • ✅ Den reports that the connect email was sent
   • ✅ Den returns one opaque signed connect envelope
   • ✅ The dev outbox contains Maya's connect email
   • ✅ Visible text includes "Connect your desktop"
   • ✅ Visible text includes "Connect your desktop to Acme Robotics"
   • ✅ Visible text includes "it never signs you in"
   • 📸 client-connect-link-02-connect-desktop-email.png — 6 validations passed
3. The client sends the opaque link to Electron for offline signature verification

   🎙 She clicks it and the app wakes, checking the link's signature against the OpenWork key it shipped with before trusting a byte of it.

   • ✅ Electron accepts the signature with the public key embedded for this key id
   • ✅ Visible text includes "Set up Acme Work for Acme Robotics?"
   • ✅ Visible text does not include "This link can't be used"
   • ✅ Verification alone does not write the desktop bootstrap
   • 📸 client-connect-link-03-connect-link-signature-verified.png — 6 validations passed
4. The confirmation names Acme and its exact server before any write

   🎙 Verified, the app shows exactly what's about to happen — set up Acme Work for Acme Robotics on Acme's own server — and until she confirms, nothing is written.

   • ✅ Visible text includes "Set up Acme Work for Acme Robotics?"
   • ✅ Visible text includes "localhost"
   • ✅ Visible text includes "Nothing has been changed yet."
   • ✅ The signed target remains unapplied until Maya confirms
   • 📸 client-connect-link-04-connect-link-confirmation.png — 7 validations passed
5. One confirmation persists Acme's server and hands control to SSO

   🎙 One confirm and it's Acme's app: the existing bootstrap JSON now carries Acme's app name, wordmark, icon, and server, then familiar sign-in takes over.

   • ✅ Confirmation writes desktop-bootstrap.json
   • ✅ The persisted JSON keeps SSO required and applies Acme's managed app name
   • ✅ The derived configured flag is never persisted
   • ✅ A confirmed organization config unlocks the enterprise network boundary
   • ✅ Visible text includes "Acme Work"
   • ✅ Visible text includes "Sign in"
   • 📸 client-connect-link-05-acme-sso-after-connect.png — 6 validations passed
6. Tampered and expired links are refused without changing Acme's configuration

   🎙 A tampered token or an expired one gets the same calm refusal with a reason, and the app stays exactly as it was.

   • ✅ A tampered token leaves the existing bootstrap untouched
   • ✅ Visible text includes "This link can't be used"
   • ✅ Visible text includes "link has expired"
   • ✅ Visible text includes "Nothing about this app was changed."
   • ✅ An expired token leaves the existing bootstrap untouched
   • 📸 client-connect-link-06-expired-connect-link-refused.png — 6 validations passed
   • ✅ Script frame 1 narrated: "A teammate installs OpenWork Enterprise, and it opens without contacting OpenWork Cloud:"
   • ✅ Script frame 2 narrated: "Acme's admin sends her a connect link, and the "Connect your desktop" email is on its wa"
   • ✅ Script frame 3 narrated: "She clicks it and the app wakes, checking the link's signature against the OpenWork key "
   • ✅ Script frame 4 narrated: "Verified, the app shows exactly what's about to happen — set up Acme Work for Acme Robot"
   • ✅ Script frame 5 narrated: "One confirm and it's Acme's app: the existing bootstrap JSON now carries Acme's app name"
   • ✅ Script frame 6 narrated: "A tampered token or an expired one gets the same calm refusal with a reason, and the app"

(screenshot upload failed: BLOB_READ_WRITE_TOKEN is not set and could not be fetched from Infisical (infisical secrets get BLOB_READ_WRITE_TOKEN --plain --silent) — run infisical login once, or export it: export BLOB_READ_WRITE_TOKEN="$(infisical secrets get BLOB_READ_WRITE_TOKEN --plain --silent)" — images available in the run directory)

[reachjalil]

fraimz — ✅ PASSED

1 passed · 0 failed · 0 skipped — run 2026-07-11T21-12-56-058Z

Full frame proof with validated screenshots: evals/results/2026-07-11T21-12-56-058Z/fraimz.html (re-run: pnpm fraimz --flow client-connect-link)

✅ client-connect-link — A network-neutral enterprise install becomes the organization's branded app

User-facing flow demo

1. OpenWork Enterprise starts network-neutral and ready to connect

   🎙 A teammate installs OpenWork Enterprise, and it opens without contacting OpenWork Cloud: ready to connect — check your email for your organization's connection link.

   • ✅ Visible text includes "OPENWORK ENTERPRISE"
   • ✅ Visible text includes "Ready to connect"
   • ✅ Visible text includes "will not connect to OpenWork Cloud automatically"
   • ✅ The fresh client has no desktop bootstrap configuration
   • ✅ The enterprise shell reports vendor-cloud networking locked before configuration
   • 📸 client-connect-link-01-client-ready-to-connect.png — 8 validations passed
2. Acme's admin mints a signed link and the real connect email reaches the dev outbox

   🎙 Acme's admin sends her a connect link, and the "Connect your desktop" email is on its way — org name, logo, and a single button.

   • ✅ The seeded admin can load the Acme organization
   • ✅ The reusable eval organization uses Acme's approved name and app brand
   • ✅ Acme exposes an organization id
   • ✅ The admin connect-link route accepts the request
   • ✅ Den reports that the connect email was sent
   • ✅ Den returns one opaque signed connect envelope
   • ✅ The dev outbox contains Maya's connect email
   • ✅ Visible text includes "Connect your desktop"
   • ✅ Visible text includes "Connect your desktop to Acme Robotics"
   • ✅ Visible text includes "it never signs you in"
   • 📸 client-connect-link-02-connect-desktop-email.png — 6 validations passed
3. The client sends the opaque link to Electron for offline signature verification

   🎙 She clicks it and the app wakes, checking the link's signature against the OpenWork key it shipped with before trusting a byte of it.

   • ✅ Electron accepts the signature with the public key embedded for this key id
   • ✅ Visible text includes "Set up Acme Work for Acme Robotics?"
   • ✅ Visible text does not include "This link can't be used"
   • ✅ Verification alone does not write the desktop bootstrap
   • 📸 client-connect-link-03-connect-link-signature-verified.png — 6 validations passed
4. The confirmation names Acme and its exact server before any write

   🎙 Verified, the app shows exactly what's about to happen — set up Acme Work for Acme Robotics on Acme's own server — and until she confirms, nothing is written.

   • ✅ Visible text includes "Set up Acme Work for Acme Robotics?"
   • ✅ Visible text includes "localhost"
   • ✅ Visible text includes "Nothing has been changed yet."
   • ✅ The signed target remains unapplied until Maya confirms
   • 📸 client-connect-link-04-connect-link-confirmation.png — 7 validations passed
5. One confirmation persists Acme's server and hands control to SSO

   🎙 One confirm and it's Acme's app: the existing bootstrap JSON now carries Acme's app name, wordmark, icon, and server, then familiar sign-in takes over.

   • ✅ Confirmation writes desktop-bootstrap.json
   • ✅ The persisted JSON keeps SSO required and applies Acme's managed app name
   • ✅ The derived configured flag is never persisted
   • ✅ A confirmed organization config unlocks the enterprise network boundary
   • ✅ Visible text includes "Acme Work"
   • ✅ Visible text includes "Sign in"
   • 📸 client-connect-link-05-acme-sso-after-connect.png — 6 validations passed
6. Tampered and expired links are refused without changing Acme's configuration

   🎙 A tampered token or an expired one gets the same calm refusal with a reason, and the app stays exactly as it was.

   • ✅ A tampered token leaves the existing bootstrap untouched
   • ✅ Visible text includes "This link can't be used"
   • ✅ Visible text includes "link has expired"
   • ✅ Visible text includes "Nothing about this app was changed."
   • ✅ An expired token leaves the existing bootstrap untouched
   • 📸 client-connect-link-06-expired-connect-link-refused.png — 6 validations passed
   • ✅ Script frame 1 narrated: "A teammate installs OpenWork Enterprise, and it opens without contacting OpenWork Cloud:"
   • ✅ Script frame 2 narrated: "Acme's admin sends her a connect link, and the "Connect your desktop" email is on its wa"
   • ✅ Script frame 3 narrated: "She clicks it and the app wakes, checking the link's signature against the OpenWork key "
   • ✅ Script frame 4 narrated: "Verified, the app shows exactly what's about to happen — set up Acme Work for Acme Robot"
   • ✅ Script frame 5 narrated: "One confirm and it's Acme's app: the existing bootstrap JSON now carries Acme's app name"
   • ✅ Script frame 6 narrated: "A tampered token or an expired one gets the same calm refusal with a reason, and the app"

(screenshot upload failed: BLOB_READ_WRITE_TOKEN is not set and could not be fetched from Infisical (infisical secrets get BLOB_READ_WRITE_TOKEN --plain --silent) — run infisical login once, or export it: export BLOB_READ_WRITE_TOKEN="$(infisical secrets get BLOB_READ_WRITE_TOKEN --plain --silent)" — images available in the run directory)

[reachjalil]

Closing this draft after realigning on the existing deterministic enterprise installer. The replacement work will review and strengthen that established path, add convenient organization-bundle tooling, and document managed enterprise deployment rather than introducing a separate signed deep-link installer or application flavor.