LocalEndpoint Connect Preview Distribution Plan

Full report

On this page

Executive recommendation

A. Executive recommendation. The best next move is to publish LocalEndpoint Connect Preview as a signed Windows MSIX preview distributed from localendpoint.com through a stable direct .appinstaller URL, while keeping every runtime capability explicitly disabled. In practical terms, that means: keep the current site-wide truth statement that runtime endpoint access is not live; add a human install page at /connect/download/; publish a stable installer locator at /downloads/connect/LocalEndpoint.Connect.appinstaller; publish immutable versioned package artifacts under /downloads/connect/v0.2.0.0/; extend the already-existing connect-scaffold-distribution evidence route family; and block release in CI if any runtime endpoint feature flag, service registration, IPC handler, or public copy suggests live local access. This recommendation fits Microsoft’s current App Installer guidance, which now prefers direct .appinstaller links because the ms-appinstaller:?source= browser protocol is disabled by default, and it fits LocalEndpoint’s current public posture because the site repeatedly says Connect is planned, metadata-only evidence is live, and runtime endpoint access is not.

The distribution decision should be MSIX today, Microsoft Store later. Microsoft’s current Windows packaging guidance says App Installer is built into Windows 10 version 1803 and later and Windows 11, MSIX packages must be signed and trusted, and Azure Artifact Signing is Microsoft’s recommended non-Store signing path. Microsoft’s current code-signing comparison also says self-signed packages block public users, EV certificates no longer provide an instant SmartScreen bypass, and Microsoft Store MSIX is the strongest trust path when broad distribution is the goal. For LocalEndpoint, however, Store publication is not the next best step because the product goal stated in the research brief is not broad consumer adoption of a live runtime, but distribution trust and installability for a non-runtime preview.

My concrete recommendation is therefore this: release 0.2.0.0 as an x64 signed MSIX for public preview, use a 2021-schema .appinstaller file with OnLaunch update checks every 12 hours, ShowPrompt=true, UpdateBlocksActivation=false, and no downgrade support, support Windows 11 and Windows 10 22H2 as the public preview matrix, and treat all runtime endpoint capabilities as future work outside the preview channel. Microsoft’s App Installer documentation supports the 2021 schema for ShowPrompt and UpdateBlocksActivation, and Microsoft’s update-schema documentation makes clear that HoursBetweenUpdateChecks=0 means every launch, which is unnecessarily aggressive for a public preview. A 12-hour prompt-based check is the best operating point for preview safety and recoverability.

Current state of localendpoint.com and the Connect scaffold

B. Current state of localendpoint.com. LocalEndpoint’s public site is already unusually well prepared for a safe preview lane. The homepage says the site is a “public map of route metadata, evidence records, safety boundaries, and machine-readable contracts,” says “runtime endpoint access is not live here,” and says “LocalEndpoint Connect is a planned permissioned layer.” The Connect page says Connect is “planned,” not live today, and explicitly says there is no local agent, tunnel, localhost fetch, filesystem read, MCP relay, webhook replay, or command execution active in the current package. The product-truth page says the public site must honestly label runtime access as planned until Connect is implemented and verified, and the local runtime safety page says no command execution, private probing, credential validation, tunnel startup, webhook replay, mock server startup, or live MCP execution is added. Those statements are the safety backbone of the current public story and should remain intact.

The machine-readable story is also already aligned with a preview distribution lane. llms.txt identifies the current package as localendpoint-v1.5.22-product-quality-ui-ux-brand-redesign.zip, describes LocalEndpoint as a “public map of route metadata, evidence records, safety boundaries, and machine-readable contracts,” and says runtime endpoint access is not live in this package. The public route index says the current package version is 1.5.22, the active runtime kind is custom-wsgi, route registration is explicit only, generic fallback routes were removed, and the release-governance layer already includes SBOM-lite metadata, artifact provenance, deterministic inventory, checksum catalogs, and evidence exports. The architecture page reinforces that LocalEndpoint uses a custom Python standard-library WSGI gateway as the public runtime and that the gateway remains metadata-only unless a separate approved runtime architecture is introduced.

Most importantly, the route index shows that LocalEndpoint already has a Connect distribution governance family. It already registers human pages for /connect-scaffold-distribution-evidence/, /connect-install-boundary/, /connect-platform-requirements/, and /connect-disabled-feature-matrix/, plus machine routes for /api/connect-scaffold-distribution/status.json, distribution-evidence.json, install-boundary.json, platform-requirements.json, scaffold-package-provenance.json, disabled-feature-matrix.json, installer-signing-boundary.json, review checklists, and evidence validate/export routes. The Connect page also links to a “Unified Local Permission Manifest” planning page that describes permission artifacts as metadata-only planning for future runtime, not active runtime. That means the right implementation is not to invent a brand-new governance model; it is to convert the existing route family into a real public preview distribution lane with signed artifacts and stronger install evidence.

Copy that must remain unchanged or become more explicit. The following claims should remain, verbatim or nearly verbatim, because they are consistent across the site and protect the public trust boundary: “Runtime endpoint access is not live in this package,” “Planned / not live,” “Public metadata is never authorization,” “No localhost fetch, filesystem access, command execution, upload intake, analytics, crawler actions, automatic decisions, or certification claims are active,” and “No runtime, tunnel, command execution, local filesystem access, private-network scanning, or certification is claimed in this package.” The new download lane should add one stronger sentence that clarifies installer scope: “This preview installs UI, onboarding, diagnostics, review, update, signing, and audit-evidence scaffolding only; it does not activate runtime endpoint access.” That addition strengthens the existing truth model instead of weakening it.

C. Current state of the Connect scaffold. I could not access the uploaded ZIP artifact LocalEndpointConnectScaffold-phase23-uai-memory-refresh(1).zip in the tool environment for this session, so I cannot provide a verified file-by-file inventory of the solution structure, WinUI shell, pages, feature flags, worker implementations, IPC scaffolding, packaging project, workflows, or tests. Because of that limitation, every scaffold-specific file path below should be read as a concrete target plan rather than a verified statement about the current repository contents.

That limitation changes how to interpret the scaffold findings section: I cannot state which subsystems are already distribution-ready, which are placeholders, or which manifest fields are already production-ready. What I can state with high confidence is what the public site already expects the scaffold to support: permission-manifest planning, audit-log planning, install-boundary evidence, disabled feature matrices, platform requirement matrices, and distribution evidence without live runtime capability. The implementation plan below is designed to preserve exactly that public promise.

Recommended distribution model and signing strategy

D. Recommended distribution model. Among the candidate distribution paths, the best fit for LocalEndpoint Connect Preview is direct signed MSIX distribution with a stable .appinstaller file hosted on localendpoint.com. Microsoft’s current packaging and distribution guidance positions the Microsoft Store as the broad-reach default for finished apps, but it separately supports MSIX distribution through App Installer using the publisher’s own CDN or website. App Installer is built into supported Windows client versions, MSIX provides clean install/uninstall and package identity, and .appinstaller gives Windows-native update checks without requiring the app to implement a custom updater. Because LocalEndpoint’s current posture is “public safety map now, Connect runtime later,” this is the cleanest way to give users a trusted install path without conveying that LocalEndpoint Connect runtime capability is already active.

The option comparison comes out like this:

That matrix is grounded in current documentation: Microsoft Store MSIX is re-signed by Microsoft; Microsoft Store MSI/EXE paths require publisher-hosted versioned HTTPS installers and manual update handling; MSIX + .appinstaller supports built-in update checks; unpackaged .exe/.msi installs rely on traditional installers and do not give package identity; Intune is the current enterprise LOB distribution path; and GitHub Releases is a binary-hosting/release-notes feature, not a Windows-native installation framework. Velopack is explicitly a community updater and requires app-integrated update initialization and a releases feed.

Two paths should be rejected for this preview. First, MSI/EXE is the wrong primary channel because unpackaged apps remain “fully unrestricted” in file system, registry, elevation, and process model, whereas the preview objective is to emphasize a hard disabled-runtime boundary rather than ship a traditionally powerful local installer. Second, Velopack adds a second update system, app-integrated feed logic, and replacement semantics that are unnecessary when App Installer already gives Windows-native update orchestration for MSIX. For this specific preview, fewer moving parts is safer, easier to audit, and easier to explain publicly.

E. Signing strategy. The preferred signing path is Azure Artifact Signing where available and organizationally acceptable; otherwise a CA-issued OV code-signing certificate; not EV for SmartScreen reasons; not self-signed for public distribution. Microsoft’s current code-signing comparison says Azure Artifact Signing is the recommended non-Store option, roughly $9.99/month, recommended for non-Store distribution, and available to organizations in the USA, Canada, EU, and UK, with individual signup more limited. Microsoft’s MSIX signing guide also says Azure Artifact Signing does not provide instant SmartScreen trust; publisher reputation still builds over time. Microsoft’s current comparison says OV certificates are the fallback when Azure Artifact Signing is unavailable or unsuitable, EV certificates no longer grant an instant SmartScreen bypass, and self-signed certificates are for development/testing only because they block public install on normal devices.

There is one nuance worth stating openly: Microsoft’s code-signing guidance already recommends Azure Artifact Signing for non-Store distribution, but Microsoft’s Artifact Signing documentation page still describes the service as being in public preview. For LocalEndpoint, that means the decision should be operational rather than ideological: if the team is eligible by region/entity type and is comfortable depending on a Microsoft-managed service that the docs still label preview, use it; if not, use an OV certificate from a CA. Do not use EV purely in hopes of bypassing SmartScreen, because Microsoft’s current SmartScreen guidance says that no longer works the way it once did.

The cost and operational burden comparison is straightforward. Azure Artifact Signing is low-cost and CI/CD-friendly, with no hardware token and first-party integrations for SignTool, GitHub Actions, and Azure DevOps, but requires Azure resource setup, identity validation, and regional eligibility. OV certificates are a familiar fallback, currently priced by Microsoft’s comparison around the typical $150–300/year range, and widely available; public CA pricing pages today also show OV pricing around that band and EV materially higher. EV is more expensive and no longer justified for this use case purely as a SmartScreen tactic. Microsoft Store signing is effectively free for MSIX submissions because Microsoft re-signs the package, but Store listing is a broader product/distribution commitment than LocalEndpoint’s current preview objective.

Release artifact layout, manifest hardening, versioning, and CI

F. Release artifact layout. The public preview should use a stable mutable installer locator and immutable versioned payloads. I recommend this exact layout:

/connect/download/                                  # human page
/downloads/connect/LocalEndpoint.Connect.appinstaller
/downloads/connect/LocalEndpoint.Connect.appinstaller.sha256

/downloads/connect/v0.2.0.0/LocalEndpoint.Connect_0.2.0.0_x64.msix
/downloads/connect/v0.2.0.0/LocalEndpoint.Connect_0.2.0.0_x64.msix.sha256
/downloads/connect/v0.2.0.0/release-manifest.json
/downloads/connect/v0.2.0.0/install-boundary.json
/downloads/connect/v0.2.0.0/release-notes.md
/downloads/connect/v0.2.0.0/provenance.json
/downloads/connect/v0.2.0.0/sbom-lite.json
/downloads/connect/v0.2.0.0/checksums.json

Use a single x64 .msix for 0.2.0.0 unless the packaging project already requires multi-architecture output. Do not publish a .msixbundle in the first public preview unless arm64 is actually validated in the clean-machine matrix. Microsoft’s App Installer schema supports either <MainPackage> for .msix or <MainBundle> for .msixbundle; the simplest public preview is therefore a single architecture-specific package now and bundle support later if arm64 becomes a real public target. The current LocalEndpoint route design already distinguishes mutable evidence routes from versioned release-governance records, so a stable appinstaller plus immutable payloads is consistent with the site’s existing governance model.

If the app depends on external framework packages, include them only if the build actually emits them and reference them explicitly from the .appinstaller file. Otherwise, keep the preview release to one main package. For this channel, do not add a custom bootstrapper and do not add a second installer technology alongside MSIX. The entire preview story should be: signed package, stable installer manifest, visible publisher, visible hash, explicit disabled-runtime boundary, and update evidence. That is easier to explain and much easier to verify.

G. App Installer manifest changes and versioning. The first public preview needs a single source of truth for five version domains: releaseVersion for human release notes, packageVersion for MSIX numeric versioning, appInstallerVersion for the .appinstaller file, previewEvidenceVersion for the public JSON evidence routes, and sitePackageVersion for the website package that currently remains 1.5.22. The site and the installer channel should be linked but not conflated: the website may continue at 1.5.22 while Connect Preview starts at 0.2.0.0, as long as the machine-readable routes expose both. The route index already treats the website package as a specific deployable artifact, and LocalEndpoint’s release-governance layer already publishes provenance and checksum concepts.

Use a checked-in version file such as eng/version.json:

{
  "channel": "preview",
  "releaseVersion": "0.2.0",
  "packageVersion": "0.2.0.0",
  "appInstallerVersion": "0.2.0.0",
  "previewEvidenceVersion": "0.2.0.0",
  "sitePackageVersion": "1.5.22"
}

Then generate all downstream files from that file during CI: Package.appxmanifest, LocalEndpoint.Connect.appinstaller, release-manifest.json, /api/connect-scaffold-distribution/status.json, and release notes metadata. SemVer can remain 0.2.0 publicly, while MSIX stays numeric 0.2.0.0. Do not rebuild over the same package version. Every public artifact change gets a new version. Every versioned package URL is immutable.

The .appinstaller file must use the 2021 schema, a stable HTTPS Uri, and a package entry whose Name, Publisher, and Version exactly match the package identity in the manifest. Microsoft’s schema reference and signing guidance are explicit on that exact-match requirement, and Microsoft’s update-settings documentation is clear that ShowPrompt and UpdateBlocksActivation need the 2021 schema. For LocalEndpoint Preview, the correct defaults are: OnLaunch, HoursBetweenUpdateChecks="12", ShowPrompt="true", UpdateBlocksActivation="false", and no ForceUpdateFromAnyVersion. That gives rapid enough preview updates, keeps the user in control, and avoids using downgrade semantics as a normal rollback mechanism.

A corrected example for 0.2.0.0:

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller
    xmlns="http://schemas.microsoft.com/appx/appinstaller/2021"
    Version="0.2.0.0"
    Uri="https://localendpoint.com/downloads/connect/LocalEndpoint.Connect.appinstaller">

  <MainPackage
      Name="LocalEndpoint.Connect"
      Publisher="CN=REPLACE_WITH_FINAL_CERT_SUBJECT"
      Version="0.2.0.0"
      ProcessorArchitecture="x64"
      Uri="https://localendpoint.com/downloads/connect/v0.2.0.0/LocalEndpoint.Connect_0.2.0.0_x64.msix" />

  <UpdateSettings>
    <OnLaunch
        HoursBetweenUpdateChecks="12"
        ShowPrompt="true"
        UpdateBlocksActivation="false" />
  </UpdateSettings>
</AppInstaller>

The only placeholder that must be finalized before release is the publisher subject, because Microsoft requires the manifest publisher to match the signing certificate subject exactly, and I could not inspect the scaffold’s current manifest or signing setup in this session.

H. CI/CD release pipeline. The release pipeline should enforce the preview boundary first and treat packaging/signing second. The concrete order should be: restore, build, unit test, safety-boundary test, public-copy scan, manifest/schema validation, MSIX package build, signature step, signature verification, hash generation, release-manifest generation, install-boundary generation, header smoke tests against staged URLs, route-index registration checks, deployment, and tag/release creation. Microsoft now supports Artifact Signing through SignTool, GitHub Actions, and Azure DevOps tasks, and Microsoft’s MSIX guidance also gives the specific signing-tool flow for Artifact Signing client tools.

A concrete GitHub Actions design should look like this in intent:

name: connect-preview-release

on:
  workflow_dispatch:
  push:
    tags:
      - "connect-preview-v*"

jobs:
  build-test-package:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: "8.0.x"

      - name: Restore
        run: dotnet restore LocalEndpoint.Connect.sln

      - name: Build
        run: dotnet build LocalEndpoint.Connect.sln -c Release --no-restore

      - name: Unit tests
        run: dotnet test LocalEndpoint.Connect.sln -c Release --no-build

      - name: Preview safety boundary
        shell: pwsh
        run: ./eng/Verify-PreviewBoundary.ps1

      - name: Public copy guard
        shell: pwsh
        run: ./eng/Verify-PublicCopyBoundary.ps1

      - name: Build MSIX
        shell: pwsh
        run: >
          msbuild .\packaging\LocalEndpoint.Connect.Package.wapproj
          /restore
          /p:Configuration=Release
          /p:UapAppxPackageBuildMode=SideloadOnly
          /p:AppxBundle=Never
          /p:GenerateAppInstallerFile=false
          /p:AppxPackageSigningEnabled=false

      - name: Sign MSIX with Azure Artifact Signing
        if: ${{ vars.USE_ARTIFACT_SIGNING == 'true' }}
        uses: azure/trusted-signing-action@v0
        with:
          azure-tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          azure-client-id: ${{ secrets.AZURE_CLIENT_ID }}
          azure-client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
          endpoint: ${{ secrets.AZURE_TRUSTED_SIGNING_ENDPOINT }}
          trusted-signing-account-name: ${{ secrets.AZURE_CODE_SIGNING_NAME }}
          certificate-profile-name: ${{ secrets.AZURE_CERT_PROFILE_NAME }}
          files-folder: .\artifacts
          files-folder-filter: msix
          file-digest: SHA256

      - name: Verify signature
        shell: pwsh
        run: |
          Get-AuthenticodeSignature .\artifacts\LocalEndpoint.Connect_0.2.0.0_x64.msix | Format-List
          signtool verify /pa /v .\artifacts\LocalEndpoint.Connect_0.2.0.0_x64.msix

      - name: Generate hashes and manifests
        shell: pwsh
        run: |
          ./eng/Write-Checksums.ps1
          ./eng/Write-ReleaseManifest.ps1
          ./eng/Write-InstallBoundary.ps1

      - name: Stage website artifacts
        shell: pwsh
        run: ./eng/Stage-WebsiteArtifacts.ps1

      - name: Deploy to localendpoint.com
        shell: pwsh
        run: ./eng/Deploy-ConnectPreview.ps1

      - name: Header smoke test
        shell: pwsh
        run: ./eng/Verify-DownloadHeaders.ps1

      - name: Create GitHub release
        uses: softprops/action-gh-release@v2

The hard release gates must be deterministic and fail-closed: runtimeEndpointAccess == disabled; tunnel == disabled; mcpRelay == disabled; commandExecution == disabled; filesystemRead == disabled; localhostFetch == disabled; privateNetworkScan == disabled; credentialAccess == disabled; uploads == disabled; paymentOrFormCapture == disabled; analyticsCrawlerActions == disabled; public copy contains no claims that imply live runtime; the final package signature verifies; and staged HTTP responses return the MIME type and Content-Length requirements App Installer expects. Microsoft’s current docs are explicit that incorrect MIME types or missing Content-Length on either GET or HEAD can break App Installer installs.

Hosting, evidence routes, and site UX

I. Hosting implementation. LocalEndpoint’s current public architecture is a custom Python standard-library WSGI gateway with a static Angular human UI shell, and machine-readable routes are already treated as gateway-owned, explicitly registered resources. That means LocalEndpoint can keep the public trust anchor on the same origin, but it should not force the WSGI layer to become a large-binary file server unless it can reliably emit App Installer’s required headers and handle HEAD correctly. The best deployment topology is therefore: keep the public URLs on https://localendpoint.com/downloads/connect/..., but serve immutable versioned binaries from object storage/CDN behind that path if the WSGI tier cannot guarantee correct MIME, Content-Length, range efficiency, and cache semantics.

The required and recommended HTTP behavior is:

• .appinstaller → application/appinstaller
• .msix → application/msix
• .msixbundle → application/msixbundle
• .appx → application/appx
• .appxbundle → application/appxbundle
• .json → application/json
• .sha256 → text/plain; charset=utf-8
• .md → text/markdown; charset=utf-8

Every GET and HEAD response for .appinstaller, .msix, and .msixbundle must include a valid Content-Length. Use HTTPS only. Make the stable .appinstaller URL mutable and short-cache it, and make versioned package URLs immutable and long-cache them. Recommended cache policy: LocalEndpoint.Connect.appinstaller → Cache-Control: public, max-age=300, must-revalidate; versioned binary/hash/provenance artifacts → Cache-Control: public, max-age=31536000, immutable. Use strong ETag values derived from the SHA-256 of each artifact.

Concrete server examples:

# WSGI static download handler sketch
import hashlib
import mimetypes
from pathlib import Path

MIME = {
    ".appinstaller": "application/appinstaller",
    ".msix": "application/msix",
    ".msixbundle": "application/msixbundle",
    ".appx": "application/appx",
    ".appxbundle": "application/appxbundle",
    ".json": "application/json",
    ".sha256": "text/plain; charset=utf-8",
    ".md": "text/markdown; charset=utf-8",
}

def serve_file(environ, start_response, path):
    p = Path(path)
    body = p.read_bytes()
    etag = hashlib.sha256(body).hexdigest()
    headers = [
        ("Content-Type", MIME.get(p.suffix, "application/octet-stream")),
        ("Content-Length", str(len(body))),
        ("ETag", f"\"{etag}\""),
        ("Cache-Control",
         "public, max-age=300, must-revalidate" if p.name.endswith(".appinstaller")
         else "public, max-age=31536000, immutable"),
    ]
    start_response("200 OK", headers)
    return [b""] if environ["REQUEST_METHOD"] == "HEAD" else [body]

location = /downloads/connect/LocalEndpoint.Connect.appinstaller {
    types { application/appinstaller appinstaller; }
    add_header Cache-Control "public, max-age=300, must-revalidate" always;
    etag on;
    try_files $uri =404;
}

location /downloads/connect/v0.2.0.0/ {
    types {
        application/msix msix;
        application/msixbundle msixbundle;
        application/appx appx;
        application/appxbundle appxbundle;
        application/json json;
        text/plain sha256;
        text/markdown md;
    }
    add_header Cache-Control "public, max-age=31536000, immutable" always;
    etag on;
    try_files $uri =404;
}

<!-- IIS web.config -->
<configuration>
  <system.webServer>
    <staticContent>
      <mimeMap fileExtension=".appinstaller" mimeType="application/appinstaller" />
      <mimeMap fileExtension=".msix" mimeType="application/msix" />
      <mimeMap fileExtension=".msixbundle" mimeType="application/msixbundle" />
      <mimeMap fileExtension=".appx" mimeType="application/appx" />
      <mimeMap fileExtension=".appxbundle" mimeType="application/appxbundle" />
      <mimeMap fileExtension=".json" mimeType="application/json" />
      <mimeMap fileExtension=".sha256" mimeType="text/plain" />
      <mimeMap fileExtension=".md" mimeType="text/markdown" />
    </staticContent>
  </system.webServer>
</configuration>

For Cloudflare R2 or equivalent object storage, the right pattern is origin-preserving CDN: upload immutable binaries under downloads/connect/v0.2.0.0/..., attach explicit HTTP metadata for Content-Type and Cache-Control, and reverse-proxy that bucket behind localendpoint.com/downloads/connect/. This keeps the public download origin aligned with LocalEndpoint’s safety and provenance story.

J. Site UX and final copy. The site needs one new human route: /connect/download/. The current home page and /connect/ page are already close to what is needed. The change is not to soften the boundary; it is to narrow the scope of the download. Keep the current “planned / not live” positioning, but add one preview CTA that is explicitly bounded: “Download Connect Preview” with subcopy “UI and install preview only. Runtime endpoint access remains disabled.” The home page currently says “Planned / not live” and “What this site does not do,” and the Connect page already enumerates the disabled runtime capabilities. Those are the authoritative claims the download page should echo, not replace.

A final page copy draft:

LocalEndpoint Connect Preview

Public preview for Windows

Version

0.2.0.0

Preview status

Public preview. Runtime endpoint access is not live in this release.

Download

Download App Installer for Windows

What this preview includes

UI shell, onboarding, diagnostics, review pages, mock pairing, mock permission ceremonies, audit-log scaffolding, signing evidence, install evidence, and update evidence.

What this preview does not do

This preview does not activate runtime endpoint access. No localhost fetch, filesystem read, command execution, MCP relay, tunnel, private-network scan, credential access, uploads, payment capture, form capture, analytics actions, or crawler actions are enabled.

Publisher identity

Displayed exactly as signed in Windows App Installer and in the release evidence below.

Signing status

Signed for public Windows installation. Signature and checksums can be verified locally.

Supported Windows versions

Windows 11

Windows 10 22H2

Install steps

1. Download the App Installer file.

2. Open the downloaded .appinstaller file.

3. Review the publisher name shown by Windows.

4. Select Install.

Update behavior

Windows checks this preview channel for updates on launch. If an update is available, Windows prompts before applying it.

Uninstall

Remove LocalEndpoint Connect Preview from Installed apps in Windows Settings.

Troubleshooting

If install fails, verify the checksum, confirm App Installer is present, and review the troubleshooting steps below.

Release evidence

SHA-256 checksums

Release notes

Install boundary JSON

Provenance JSON

SBOM-lite

Trust boundary

LocalEndpoint Connect Preview is a signed distribution preview, not a live runtime channel. Public metadata is never authorization.

Known limitations

x64 only in this preview.

No runtime endpoint access.

No tunnel or relay behavior.

No private-network interaction.

No production support claim.

No certification claim.

Do not use “one-click install,” because Microsoft now says the ms-appinstaller browser protocol is disabled by default. Do not use “production-ready,” “audited,” “verified safe,” or “certified,” because LocalEndpoint’s current public verification boundary explicitly says public metadata cannot certify runtime safety, deployment success, or formal compliance status.

K. Machine-readable evidence routes. Do not create a parallel evidence family. Extend the existing /api/connect-scaffold-distribution/ family already registered in the public route index. All routes should share a common envelope:

{
  "schemaVersion": "1.0",
  "channel": "preview",
  "releaseVersion": "0.2.0",
  "packageVersion": "0.2.0.0",
  "sitePackageVersion": "1.5.22",
  "generatedAtUtc": "2026-06-08T00:00:00Z",
  "owner": "LocalEndpoint",
  "sourceArtifact": "LocalEndpoint.Connect_0.2.0.0_x64.msix",
  "safetyBoundary": {
    "runtimeEndpointAccess": "disabled",
    "tunnel": "disabled",
    "mcpRelay": "disabled",
    "commandExecution": "disabled",
    "filesystemRead": "disabled",
    "localhostFetch": "disabled",
    "privateNetworkScan": "disabled",
    "credentialAccess": "disabled",
    "uploads": "disabled",
    "paymentOrFormCapture": "disabled",
    "analyticsCrawlerActions": "disabled"
  }
}

Then define the route payloads like this:

LocalEndpoint’s current route index already catalogs the connect scaffold distribution family and release-governance objects, and the index enforces explicit registration with generic fallbacks removed. That means every one of the routes above should also be inserted into the public route index before release.

Safety verification, validation matrix, rollback, and privacy

L. Safety-boundary verification plan. The release should not be considered valid unless LocalEndpoint can mechanically prove the preview is still non-runtime. The best design is a two-layer proof: first, repository/build assertions; second, public artifact assertions. Repository assertions should inspect feature-flag files, dependency-injection registration, worker startup, IPC/named-pipe/gRPC bindings, permission-request services, diagnostics exporters, and review/export code. Public artifact assertions should inspect the generated install-boundary.json, the copied website text, and the machine-readable evidence routes. The asserted values should be the exact disabled matrix your brief specifies: runtimeEndpointAccess, tunnel, mcpRelay, commandExecution, filesystemRead, localhostFetch, privateNetworkScan, credentialAccess, uploads, paymentOrFormCapture, and analyticsCrawlerActions all disabled. That disabled vocabulary is already consistent with the current site, which repeatedly disclaims localhost fetch, filesystem access, command execution, uploads, analytics, crawler actions, tunnels, probing, and certification.

A practical schema for the public install boundary:

{
  "schemaVersion": "1.0",
  "channel": "preview",
  "releaseVersion": "0.2.0",
  "packageVersion": "0.2.0.0",
  "publisher": "CN=REPLACE_WITH_FINAL_CERT_SUBJECT",
  "packageIdentity": "LocalEndpoint.Connect",
  "uiScope": [
    "shell",
    "onboarding",
    "diagnostics",
    "review-pages",
    "mock-pairing",
    "mock-permission-ceremony",
    "audit-log-scaffolding",
    "install-evidence",
    "update-evidence"
  ],
  "runtimeCapabilities": {
    "runtimeEndpointAccess": false,
    "tunnel": false,
    "mcpRelay": false,
    "commandExecution": false,
    "filesystemRead": false,
    "localhostFetch": false,
    "privateNetworkScan": false,
    "credentialAccess": false,
    "uploads": false,
    "paymentOrFormCapture": false,
    "analyticsCrawlerActions": false
  },
  "updateSettings": {
    "mode": "OnLaunch",
    "hoursBetweenUpdateChecks": 12,
    "showPrompt": true,
    "updateBlocksActivation": false,
    "forceUpdateFromAnyVersion": false
  },
  "evidence": {
    "releaseManifestUrl": "https://localendpoint.com/api/connect-scaffold-distribution/release-manifest.json",
    "checksumsUrl": "https://localendpoint.com/api/connect-scaffold-distribution/checksums.json",
    "windowsValidationUrl": "https://localendpoint.com/api/connect-scaffold-distribution/windows-validation.json"
  }
}

The repository tests should include, at minimum, PreviewBoundaryFlagsTests, NoRuntimeServiceRegistrationTests, DisabledAgentWorkerTests, NoLiveIpcHandlersTests, PermissionManifestNoOpTests, DiagnosticsRedactionTests, ReviewExportLocalOnlyTests, PublicCopyBoundarySnapshotTests, and EvidenceRouteConsistencyTests.

M. Install and update validation matrix. The public validation matrix should intentionally be smaller than what Windows technically supports. Microsoft says App Installer is built into Windows 10 version 1803 and later and Windows 11, but the richer 2021-schema update features sit on Windows 10 version 2004 and later and Windows 11. For LocalEndpoint Preview, that argues for a public support statement of Windows 11 and Windows 10 22H2, while treating older versions as out of scope for the preview channel.

The clean-machine matrix should include these exact environments: Windows 11 current stable; Windows 10 22H2; standard user; admin user; SmartScreen defaults; clean VM with no dev certificate; machine with prior preview installed; and machine that loses network after successful install to test launch without update-path dependency. Each environment should run: direct .appinstaller install, raw MSIX install, first launch, page-navigation smoke, visible disabled-feature UI, no runtime activation, upgrade from 0.2.0.0 to 0.2.1.0, failed-update recovery, uninstall, reinstall, signature verification, hash verification, HEAD/MIME verification, broken package URL handling, and expired/revoked cert simulation where feasible. Microsoft’s App Installer/Learn guidance specifically recommends isolating installation problems by testing both package and .appinstaller installations, and Microsoft’s troubleshooting guidance identifies the Appx deployment event logs as the source of truth for failure analysis.

The validation scripts should use official Windows tooling:

# Verify App Installer presence/version
(Get-AppxPackage Microsoft.DesktopAppInstaller).Version

# Install from appinstaller
Add-AppxPackage -AppInstallerFile .\LocalEndpoint.Connect.appinstaller

# Verify installed package
Get-AppxPackage | Where-Object Name -eq "LocalEndpoint.Connect"

# Verify signature
Get-AuthenticodeSignature .\LocalEndpoint.Connect_0.2.0.0_x64.msix
signtool verify /pa /v .\LocalEndpoint.Connect_0.2.0.0_x64.msix

# Verify server HEAD/Content-Length/MIME
$u = "https://localendpoint.com/downloads/connect/LocalEndpoint.Connect.appinstaller"
Invoke-WebRequest -Method Head -Uri $u

# Review deployment logs
Get-WinEvent -LogName "Microsoft-Windows-AppxDeployment-Server/Operational" -MaxEvents 50

Microsoft documents Add-AppxPackage -AppInstallerFile, Get-AuthenticodeSignature, SignTool verification, App Installer package-version checks, and Get-AppxLog/Appx deployment logs as the supported paths for verification and troubleshooting.

N. Rollback, incident response, and privacy/security review. The rollback rule should be simple: never mutate a versioned package artifact after publication. If v0.2.0.0 is bad, do not replace the binary in place. Instead, revoke it in evidence routes, update the stable .appinstaller to point at a new fixed release such as 0.2.0.1, and update /connect/download/ plus status.json immediately. This rule is consistent with LocalEndpoint’s existing release-governance posture, which already treats provenance, package manifests, SBOM-lite, and checksums as durable review artifacts.

Immediate mitigation steps should be predefined. If a package is signed incorrectly: remove the download CTA, keep the versioned artifact for evidence, mark the release revoked in status.json, publish 0.2.0.1. If the .appinstaller points to the wrong package: fix the stable .appinstaller, bump the release, regenerate hashes, and record the incident in distribution-evidence.json. If a hash mismatch is published: update checksums.json and status.json, and if the binary itself is wrong, revoke and reissue. If SmartScreen blocks too aggressively: do not switch to EV as a workaround; keep signing consistently and make the trust evidence page more explicit. If clean-machine install fails: freeze rollout, collect Appx deployment IDs, and do not claim support until the matrix passes. If a safety-boundary violation is discovered or runtime flags are accidentally enabled: immediately remove the stable installer pointer, set the download page status to paused, update all evidence routes, and ship a higher fixed version after the boundary tests pass again. Microsoft’s current SmartScreen and signing guidance is clear that OV and EV both build reputation over time and that self-signed/public-bypass shortcuts are not the right answer.

For privacy and security, the public preview should write only what it must: normal Windows package-local settings, a small local diagnostics log, and optional user-requested review/export files. It should not transmit telemetry unless that telemetry is explicitly disclosed, user-visible, and easy to disable. It should not include crash reporting in 0.2.x unless the crash path is equally disclosed and redacted. The public privacy copy should say: “This preview stores local application settings and local diagnostic records on your device. It does not activate runtime endpoint access, does not read your local files as part of product functionality, and does not transmit private endpoint data because runtime endpoint capability is disabled in this preview.” The preview terms copy should say: “LocalEndpoint Connect Preview is pre-release software intended for evaluation of installer flow, UI, onboarding, diagnostics, and review artifacts. It is not production software and does not provide live runtime endpoint access.” That language is aligned with the current LocalEndpoint trust and verification boundaries.

Implementation sequence, risks, open questions, and definition of done

O. Implementation sequence.

Phase 2.4.1 — Release identity and version source. Goal: create one checked-in version source for release, package, appinstaller, and evidence versions. Files to change: central version file, packaging props, release-manifest generator, evidence-route generator. Commands/scripts to add: Write-VersionArtifacts.ps1. Tests: version-consistency test across manifest/appinstaller/evidence outputs. Acceptance: one source changes all downstream versioned outputs. Owner decision: confirm final package identity string and publisher naming strategy.

Phase 2.4.2 — MSIX/App Installer manifest hardening. Goal: lock Name, Publisher, and Version, move .appinstaller to 2021 schema, set OnLaunch preview defaults, convert all URLs to HTTPS, remove downgrade support. Files to change: Package.appxmanifest, LocalEndpoint.Connect.appinstaller, packaging project properties. Tests: XML schema validation, identity-matches-certificate-subject test, URL/HTTPS test. Acceptance: manifest identity stable and .appinstaller validates.

Phase 2.4.3 — Signing pipeline. Goal: wire Azure Artifact Signing or OV-signing fallback into CI. Files to change: pipeline file, signing metadata JSON, secret references, signature verification script. Commands/scripts to add: Artifact Signing client install, SignTool verification, PowerShell signature dump. Tests: signed package verification on CI and clean VM. Acceptance: package installs on a clean machine without importing a dev cert. Owner decision: choose Artifact Signing or OV certificate.

Phase 2.4.4 — Artifact generation and checksums. Goal: generate immutable versioned artifacts, hashes, provenance, SBOM-lite, install boundary, release manifest. Files to change: packaging outputs, checksum script, manifest script, provenance script. Tests: hash consistency and artifact completeness tests. Acceptance: all sidecars emitted and referenced from release manifest.

Phase 2.4.5 — localendpoint.com download hosting. Goal: stand up /downloads/connect/ with correct MIME, HEAD, Content-Length, cache headers, and same-origin HTTPS URLs. Files to change: WSGI/static serving config, reverse proxy or object storage manifest, route registrations if needed. Tests: automated header smoke tests. Acceptance: .appinstaller and .msix pass official header checks. Owner decision: same-origin WSGI vs reverse-proxied object storage/CDN.

Phase 2.4.6 — Public download page. Goal: add /connect/download/ with bounded preview language, hashes, install/update/uninstall steps, and evidence links. Files to change: page template/content source, route table, navigation, page metadata. Tests: snapshot/banned-phrase tests. Acceptance: page contains no live-runtime implication and links directly to .appinstaller.

Phase 2.4.7 — Machine-readable distribution evidence. Goal: turn the existing connect-scaffold-distribution family into a live release-evidence channel. Files to change: route registry, route index generator, evidence JSON generators. Tests: route registration test, schema validation, cross-link check. Acceptance: every public preview artifact is reflected in machine-readable evidence and listed in the public route index.

Phase 2.4.8 — Clean-machine install/update validation. Goal: execute matrix on Windows 11 and Win10 22H2, plus update from 0.2.0.0 to 0.2.1.0. Files to change: validation scripts, VM definitions, evidence exporter. Tests: all cases in the validation matrix. Acceptance: documented pass receipts in windows-validation.json and update-smoke-test.json.

Phase 2.4.9 — Preview release. Goal: publish 0.2.0.0, stable .appinstaller, /connect/download/, release notes, and evidence routes. Files to change: production deployment manifests and release tags. Tests: final production smoke on live URLs. Acceptance: download works from live site, route index updated, trust copy consistent.

Phase 2.4.10 — Post-release monitoring and rollback drill. Goal: rehearse mis-sign, wrong-URL, hash-mismatch, and safety-violation incidents. Files to change: incident runbook, status-route updater, rollback scripts. Tests: tabletop plus live dry run on staging. Acceptance: team can revoke the stable installer pointer and publish a corrected version without mutating prior versioned artifacts.

P. Risks and open questions.

The biggest open question is the scaffold itself. Because the uploaded ZIP was not accessible in this session, I could not verify whether the current packaging project, App Installer file, manifest publisher, feature flags, workers, or CI files already exist and how close they are to releasable shape. The plan above is therefore concrete and releaseable, but the exact file-level delta inside the scaffold remains to be confirmed once the artifact is available for inspection.

The second real open question is signing choice. Microsoft currently recommends Azure Artifact Signing for non-Store distribution, but Microsoft’s Artifact Signing documentation still labels the service as public preview. If organizational or contractual policy disallows that dependency, OV should be the fallback. That is a straightforward tactical switch, but it must be decided before identity and manifest hardening finish.

A smaller but important open question is architecture scope. Unless the scaffold is already producing a validated multi-architecture output, the first public preview should stay x64-only. Supporting arm64 is a good future improvement, but not a requirement for achieving the primary goal of trusted, reproducible, publicly installable distribution with runtime still disabled.

Q. Definition of done. The work is done when all of the following are true:

• https://localendpoint.com/connect/download/ exists and uses explicit non-runtime preview language.
• https://localendpoint.com/downloads/connect/LocalEndpoint.Connect.appinstaller is live over HTTPS.
• The .appinstaller points to immutable versioned package URLs under /downloads/connect/v0.2.0.0/.
• The package is signed with Azure Artifact Signing or a CA-trusted OV certificate, and signature verification passes on a clean machine.
• App Installer delivery headers are correct, including MIME types and Content-Length on both GET and HEAD.
• /api/connect-scaffold-distribution/status.json, distribution-evidence.json, install-boundary.json, installer-signing-boundary.json, release-manifest.json, checksums.json, windows-validation.json, and update-smoke-test.json are live and listed in the public route index.
• CI blocks any build where runtime endpoint access, tunnels, relay paths, command execution, filesystem read, localhost fetch, private-network scan, uploads, payment/form capture, or analytics/crawler actions are enabled.
• Clean-machine install, launch, update, uninstall, and reinstall all pass on Windows 11 and Windows 10 22H2.
• The stable public claim remains true everywhere: LocalEndpoint Connect Preview is publicly downloadable, but runtime endpoint access is still not live.