LocalEndpoint Connect Preview: Distribution Architecture and Safe-Scaffold Implementation Report

Full report

On this page

A. Executive Recommendation

The objective of this architectural evaluation is to establish a secure, publicly accessible preview distribution channel for the LocalEndpoint Connect scaffold on localendpoint.com. This initiative must prioritize distribution trust, installation reliability, cryptographic verification, and the foundational Teleodynamic principles of transparent evidence surfacing. The overriding constraint demands that the public safety claim—specifically, that runtime endpoint access remains unequivocally inactive—is preserved throughout the distribution lifecycle. The introduction of the application to the public domain must strictly serve as a distribution and trust-building exercise, maintaining a hard boundary against the activation of live features such as localhost fetches, filesystem operations, private network access, or command execution. The executive recommendation dictates the compilation and distribution of LocalEndpoint Connect Preview as a natively containerized Windows MSIX package, signed using Microsoft Azure Artifact Signing, and delivered via a direct .appinstaller file download hosted securely on localendpoint.com. This strategy intentionally rejects reliance on the ms-appinstaller: URI protocol. Microsoft disabled this protocol handler by default for consumer devices in late 2023 in response to widespread abuse by the Emotet malware campaign (CVE-2021-43890).1 Relying on it for a broad, non-enterprise public preview would result in a broken user experience. Instead, the architecture mandates a traditional file download approach, heavily augmented by deterministic build provenance, comprehensive machine-readable evidence routes, and automated Continuous Integration/Continuous Deployment (CI/CD) pipelines that enforce hard boundaries on agent capabilities. By utilizing Azure Artifact Signing (formerly Trusted Signing), the deployment minimizes operational overhead while establishing a robust cryptographic identity aligned with modern CA/Browser Forum mandates.3 Concurrently, the .appinstaller manifest enables seamless OnLaunch background updates 6, allowing the preview scaffold to mature incrementally without requiring manual user intervention. This framework aligns perfectly with the Teleodynamic principles of morphodynamic scaffolding and verifiable constraints, ensuring that public claims remain strictly proportional to exposed evidence.8

B. Current State of localendpoint.com

An analysis of the current state of localendpoint.com reveals an architecture designed around local-first AI-agent discovery, governed by strict brand and safety rules. The platform functions as a validation layer for local services, APIs, webhook handlers, and models.10 The site strictly enforces a brand methodology that prohibits the implication of live runtime access. Specifically, the "LocalEndpoint Brand System" dictates that the hero platform illustration and all associated visual assets must never be utilized to imply live, unchecked runtime capabilities.11 This is consistent with the Teleodynamic ecosystem's stance against "autonomy-washing," which actively downgrades capability claims when resource closure evidence is absent or cross-domain ownership is unverified.12 Currently, the primary public-facing aspects of the site operate as non-executing, review-gated structures.13 Machine-readable JSON routes, llms.txt declarations, and telemetry policies operate under the assumption that the platform is an inspectable evidence ledger rather than a live execution environment.9 The public route index, while inaccessible during the initial scan, theoretically anchors these evidence records, ensuring the ecosystem role map remains bounded.15 To support a preview download, the site copy must explicitly reinforce this non-executing posture. Marketing terminology such as "production-ready," "one-click install," or "live endpoint gateway" must be strictly avoided. Instead, the site copy must adopt terminology reflecting the reality of the artifact: it is a "Safe Scaffold," a "Preview Distribution," and a "Verifiable Shell".8 The site must explicitly state that the application will expose UI, mock permission ceremonies, and audit-log scaffolding, but will intrinsically block true runtime executions. The claims regarding safety boundaries and release governance must evolve from abstract philosophical stances into mathematically verifiable assertions. Metadata-only evidence must now be paired with explicit install-boundary.json manifests that programmatically prove the inert nature of the package version prior to user installation.

C. Current State of the Connect Scaffold

An extrapolation of the LocalEndpointConnectScaffold-phase23-uai-memory-refresh(1).zip architecture indicates a modern Windows desktop application built using the WinUI 3 framework, wrapped in a single-project MSIX packaging structure. The scaffold presently contains the fundamental components of an endpoint gateway, categorized into active UI elements and explicitly disabled worker subsystems.

In its current state, the UI, navigation, diagnostic readiness pages, and the MSIX packaging project are distribution-ready. However, the IPC/named pipe scaffolding, MCP relay components, and local connector execution points are fundamentally unsafe to expose to public traffic without cryptographic guards and explicit user authorization. Therefore, the build pipeline must physically sever or categorically disable these runtime endpoints via compiler directives or immutable feature flags prior to .msix generation.

D. Recommended Distribution Model

Evaluating the deployment strategies for Windows applications involves balancing user friction, trust mechanisms, and update reliability. The analysis of available distribution models yields the following strategic assessment:

The Deprecation of the ms-appinstaller Protocol

A critical architectural constraint dictating this recommendation is the status of the ms-appinstaller: protocol. Historically, publishers relied on URIs formatted as ms-appinstaller:?source=https://example.com/app.appinstaller to trigger seamless, single-click web installations. However, as of December 12, 2023 (App Installer version 1.21.3421.0), Microsoft disabled this protocol handler on consumer devices to mitigate its aggressive abuse by the Emotet malware campaign, which exploited the CVE-2021-43890 vulnerability pattern.1 While enterprise environments can re-enable the protocol via the EnableMSAppInstallerProtocol Group Policy or the DesktopAppInstaller CSP 18, relying on this for general public distribution is unviable and hostile to the end-user. Therefore, the site must explicitly direct users to download the .appinstaller file to their local filesystem and execute it manually. Any "one-click install" marketing claims must be expunged to prevent user confusion and ensure alignment with current Windows security defaults.

E. Signing Strategy

Cryptographic identity is the foundation of the public preview boundary. Windows Defender SmartScreen aggressively filters unsigned or self-signed applications downloaded from the internet, evaluating the reputation of both the publisher certificate and the file hash. The analysis of code signing options provides a clear technological mandate.

Recommendation: Azure Artifact Signing (Trusted Signing) Azure Artifact Signing (formerly Azure Code Signing) provides a fully managed, FIPS 140-2 Level 3 compliant end-to-end signing solution.3 It fundamentally resolves the hardware token dilemma introduced by the CA/Browser Forum in 2023, allowing seamless, zero-touch certificate lifecycle management directly within a GitHub Actions or Azure DevOps pipeline without the necessity of physical USB tokens.3 The cost is highly optimized at a basic tier of approximately $9.99 per month, making it vastly superior to legacy CA offerings.5 Identity validation requires standard documentation (e.g., government ID, utility bills) and may take several business days to establish the Trusted Signing Account, requiring the assignment of the Trusted Signing Identity Verifier role within the Microsoft Entra ID tenant.5 Risk Acknowledgment: Azure Artifact Signing utilizes standard Public Trust profiles, meaning the resulting .msix files will trigger Windows Defender SmartScreen "unrecognized app" warnings initially, particularly when Microsoft rotates its intermediate CAs (e.g., AOC CA 03).5 Reputation is intrinsically tied to the file hash and the publisher identity. The localendpoint.com site copy must pre-emptively warn users about the SmartScreen interstitial and provide instructions on how to safely bypass it by verifying the artifact's digital signature against the site's public machine-readable records.

F. Release Artifact Layout

To ensure cryptographic provenance and predictable distribution, localendpoint.com must utilize a strict, immutable directory structure for hosting artifacts. Versioned packages must remain read-only once published, while the root .appinstaller serves as the singular mutable pointer for executing updates. Proposed Target Layout: /downloads/connect/ ├── LocalEndpoint.Connect.appinstaller (Mutable: Always points to the latest active version) ├── LocalEndpoint.Connect.appinstaller.sha256 (Mutable: Hash of the active appinstaller) ├── install-boundary.json (Mutable: Points to the current release safety boundary) ├── release-manifest.json (Mutable: Index of all active and deprecated artifacts) ├── release-notes.md (Mutable: Markdown representation of the latest changes) └── v0.2.0.0/ ├── LocalEndpoint.Connect\_0.2.0.0\_x64.msix (Immutable: The core application package) ├── LocalEndpoint.Connect\_0.2.0.0\_x64.msix.sha256 ├── provenance.json (Immutable: CI/CD build trace and runner identity) └── sbom-lite.json (Immutable: Bill of materials mapping dependencies) The application should publish a single, architecture-specific .msix file (e.g., \_x64.msix) rather than an .msixbundle if the preview relies exclusively on x64 architecture. Bundles introduce unnecessary network payload complexity unless ARM64 or x86 variants are being concurrently compiled and distributed. Framework dependencies (such as the.NET 8 Runtime or Microsoft.VCLibs) should be declared within the MSIX manifest so the Windows OS can resolve them natively from the Microsoft Store during the installation sequence.24 A separate custom bootstrapper is explicitly rejected, as it violates the design constraint of relying purely on the native App Installer framework and obscures the trust boundary.

G. App Installer Manifest Plan

The .appinstaller XML file controls the installation source, versioning mechanisms, and background update mechanics. The App Installer schema has evolved significantly, with critical update features relying on schema namespaces introduced in 2018 (s3) and 2021 (s4).25 Manifest Configuration Decisions:

• Package Identity: Must perfectly mathematically match the AppxManifest.xml identity to prevent parsing failures.
• Version Synchronization: The \<AppInstaller\> root version attribute must reflect the target \<MainPackage\> version to prevent caching anomalies on the client machine.
• URI Paths: Must utilize strict https:// for all URIs to satisfy OS security zone requirements.18
• Update Settings: The OnLaunch directive is optimal for a preview distribution, ensuring the app checks for updates every time the user interacts with it.6
• HoursBetweenUpdateChecks: Set to 0 for the preview phase utilizing the s4: namespace.28 This forces the App Installer to check the server for a new .appinstaller file every time the app launches, ensuring instantaneous propagation of bug fixes or critical safety rollbacks.7
• ShowPrompt: Set to true to ensure users are aware that updates are occurring, aligning with the Teleodynamic transparency goals.30
• UpdateBlocksActivation: Set to true. The application will strictly refuse to launch until the update completes. This is a vital safety mechanism: if a boundary breach is discovered, a patched version can force an immediate, unavoidable update before the user can interact with the vulnerable application state.28
• ForceUpdateFromAnyVersion: Set to true using the s4: namespace. This allows the publisher to push a definitive downgrade (e.g., reverting from a flawed 0.2.1.0 back to a stable 0.2.0.0) in the event of a severe incident, bypassing standard upward-only versioning constraints.28

Corrected Example .appinstaller File for Version 0.2.0.0:

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

\<MainPackage Name\="LocalEndpoint.ConnectPreview" Publisher\="CN=LocalEndpoint Technologies" 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" /\>

\<s4:UpdateUris\> \<s4:UpdateUri\>https://localendpoint.com/downloads/connect/LocalEndpoint.Connect.appinstaller\</s4:UpdateUri\> \</s4:UpdateUris\>

\<s4:RepairUris\> \<s4:RepairUri\>https://localendpoint.com/downloads/connect/LocalEndpoint.Connect.appinstaller\</s4:RepairUri\> \</s4:RepairUris\>

\<UpdateSettings\> \<OnLaunch s4:HoursBetweenUpdateChecks\="0" s4:ShowPrompt\="true" s4:UpdateBlocksActivation\="true" /\> \<s4:ForceUpdateFromAnyVersion\>true\</s4:ForceUpdateFromAnyVersion\> \</UpdateSettings\> \</AppInstaller\>

H. CI/CD Release Pipeline

A deterministic CI/CD pipeline using GitHub Actions is mandatory. The pipeline acts as the ultimate arbiter of safety, blocking any release where runtime feature flags are inadvertently enabled, satisfying the core project constraint. Pipeline Stage 1: Build and Test The pipeline initiates by restoring the.NET workload and running rigorous unit testing.

1. Restore dependencies: dotnet restore
2. Run unit tests: dotnet test \--no-restore \--configuration Release
3. Run safety-boundary tests: Execute a custom PowerShell script (Verify-SafetyBoundaries.ps1) that parses appsettings.json and internal feature flag constants. If RuntimeEndpointAccess \= true, the pipeline must instantly fail and output an error.
4. Build in Release: dotnet build \--no-restore \--configuration Release

Pipeline Stage 2: Packaging and Boundary Generation 5\. Generate MSIX: dotnet publish \-c Release \-p:RuntimeIdentifier=win-x64 \-p:PublishReadyToRun=true \-p:GenerateAppxPackageOnBuild=true (Leveraging the WinUI 3 single-project MSIX packaging format). 6\. Validate package manifests: Parse AppxManifest.xml to ensure minimal capabilities are requested. The pipeline must fail if capabilities like broadFileSystemAccess are present. Pipeline Stage 3: Cryptographic Signing 7\. Sign the package: Utilize the azure/trusted-signing-action.20 The action authenticates via Microsoft Entra Workload Identity OIDC, targets the Azure Trusted Signing Account, and signs the .msix file using digest signing—meaning the file never leaves the GitHub Actions runner, and the private key never leaves Azure.3 yaml \- name: Azure Trusted Signing uses: azure/trusted-signing-action@v0.3.1 with: azure-tenant-id: ${{ secrets.AZURE\_TENANT\_ID }} azure-client-id: ${{ secrets.AZURE\_CLIENT\_ID }} account-name: 'localendpoint-signing-acc' certificate-profile-name: 'public-trust-profile' files: '/LocalEndpoint.Connect\_\*.msix' 8\. Verify signature: signtool verify /v /pa LocalEndpoint.Connect\_0.2.0.0\_x64.msix Pipeline Stage 4: Artifact Generation and Publication 9\. Generate SHA-256 hashes: Execute Get-FileHash \-Algorithm SHA256 for both the .msix and .appinstaller. 10\. Generate Evidence Records: Programmatically construct install-boundary.json, release-manifest.json, and provenance.json based on the Git commit SHA and the successful test results. 11\. Deploy to localendpoint.com: Upload the immutable version directory (v0.2.0.0) and atomically overwrite the mutable root files. 12\. Create a GitHub release tag: Anchor the source code repository to the exact version matching the MSIX.

I. Hosting Configuration

The web server hosting the artifacts must strictly comply with App Installer HTTP requirements. Failure to configure the server correctly will result in catastrophic, opaque errors for the end-user—specifically the 0x80072F76 (Unknown Error) or "The parameter is incorrect" when App Installer attempts a deployment.24 Critical Hosting Requirements:

1. HTTPS Protocol: Mandatory. The App Installer refuses untrusted or plain HTTP connections by default, enforcing URL Security Zones.18
2. MIME Types: The server must explicitly declare the correct Content-Type for App Installer packages. A misconfigured or generic MIME type results in immediate parsing failures.1
3. Content-Length Headers: App Installer relies heavily on HEAD requests to determine file sizes prior to initiating chunked downloads. Every response—both GET and HEAD—must include an accurate Content-Length header.24
4. Byte-Range Requests: The server must support Accept-Ranges: bytes to facilitate resuming interrupted downloads and differential delta updates.

Given that standard Python WSGI gateways (which may currently back the site) often struggle with efficient static file chunking and range requests for massive binary files, it is strongly recommended to serve the /downloads/connect/ path via a dedicated object storage layer (e.g., Cloudflare R2, AWS S3) or a highly tuned static web server like Nginx, configured as a reverse proxy or direct file server. Nginx Configuration Example:

Nginx location /downloads/connect/ { alias /var/www/localendpoint/downloads/connect/;

\# Required MIME Types for App Installer types { application/appinstaller appinstaller; application/msix msix; application/msixbundle msixbundle; application/appx appx; application/appxbundle appxbundle; application/json json; text/markdown md; }

\# Force Content-Length calculation by disabling chunked transfer chunked\_transfer\_encoding off;

\# Cache Control Strategy \# Immutable packages cached indefinitely location \~\* \\.msix$ { expires max; add\_header Cache-Control "public, immutable"; }

\# Mutable appinstaller must never be cached to ensure instantaneous updates location \~\* \\.appinstaller$ { expires \-1; add\_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate"; add\_header Pragma "no-cache"; } }

IIS Configuration Example (Fallback): If the payload is hosted on a Windows Server running IIS, the web.config requires explicit MIME map definitions in the \<staticContent\> block 36:

XML \<configuration\> \<system.webServer\> \<staticContent\> \<remove fileExtension\=".appinstaller" /\> \<mimeMap fileExtension\=".appinstaller" mimeType\="application/appinstaller" /\> \<remove fileExtension\=".msix" /\> \<mimeMap fileExtension\=".msix" mimeType\="application/msix" /\> \<remove fileExtension\=".json" /\> \<mimeMap fileExtension\=".json" mimeType\="application/json" /\> \</staticContent\> \</system.webServer\> \</configuration\>

J. Site UX and Copy

The design of the public download experience (/connect/download/) must navigate the tension between generating user interest and ethically mitigating claims of autonomous capability. The page must strictly adhere to the Teleodynamic principles, acting as an evidence-rich orientation bridge rather than a standard software marketing page.14 Required Page Data Structure:

• Page Title: LocalEndpoint Connect Preview
• Version: 0.2.0.0
• Preview Status: Explicitly tagged as "Safe Scaffold Preview".
• Call to Action: A prominent download button linking directly to the HTTP URL of LocalEndpoint.Connect.appinstaller. (Do NOT use ms-appinstaller: protocol links 2).

Proposed Site Copy:

LocalEndpoint Connect Preview

Version 0.2.0.0 | Architecture: Windows x64 | Cryptographic Identity: Azure Artifact Signing A Morphodynamic Scaffold for the Teleodynamic Ecosystem. LocalEndpoint Connect Preview is a structural shell. It provides a verifiable user interface, mock permission ceremonies, and inspectable audit-log scaffolding for local-first AI-agent discovery. ⚠️ Safety Boundary Notice: To ensure cryptographic safety and to adhere to our strict prohibitions against autonomy-washing, live runtime endpoint access is explicitly disabled in this preview. This application will not activate localhost fetches, filesystem reads, private network access, MCP relays, tunnels, or command execution. It is an inert, verifiable shell designed exclusively to test distribution trust, uninstalls, and update mechanics. Installation Instructions:

1. Download the App Installer File below to your local machine.
2. Double-click the downloaded .appinstaller file on your Windows 10/11 machine.
3. Note on SmartScreen: As this utilizes a new public cryptographic identity, Windows Defender SmartScreen may display an "Unrecognized app" warning. You may safely verify our Publisher Identity (LocalEndpoint Technologies) and proceed.

(Link directly to the HTTPS file path) Cryptographic Evidence & Transparency: We believe a useful teleodynamic system must make its organization inspectable.9 Compare your downloads against our cryptographic hashes below:

• SHA-256 (AppInstaller): \[Inject CI Hash\]
• SHA-256 (MSIX Package): \[Inject CI Hash\]

View the(/api/connect-scaffold-distribution/status.json) or read our(/trust-safety/).

K. Machine-Readable Evidence Routes

To substantiate the philosophical claims of the Teleodynamic Ecosystem—specifically that public claims must be proportional to tests and evidence must be structurally exposed 9—the distribution must publish rigorous machine-readable endpoints. These static JSON routes serve as verifiable ledgers for the distribution state. The distribution will expose the following routes under /api/connect-scaffold-distribution/. These routes must be explicitly appended to the https://localendpoint.com/api/public-route-index.json registry to maintain discoverability.39

Example Schema (install-boundary.json):

JSON { "$schema": "https://localendpoint.com/schemas/install-boundary-v1.json", "artifactName": "LocalEndpoint.Connect\_0.2.0.0\_x64.msix", "boundaryAssertions": { "runtimeEndpointAccess": "disabled", "tunnel": "disabled", "mcpRelay": "disabled", "commandExecution": "disabled", "filesystemRead": "disabled", "localhostFetch": "disabled", "privateNetworkScan": "disabled", "credentialAccess": "disabled", "analyticsActions": "disabled", "paymentCapture": "disabled" }, "validationEvidence": { "ciTestRunId": "987654321", "attestationTimestamp": "2026-06-08T12:00:00Z" } }

L. Safety-Boundary Test Plan

The safety-boundary test plan relies on absolute determinism within the CI/CD pipeline. No build can proceed to the Azure Artifact Signing step unless all boundary tests pass, effectively functioning as an automated kill-switch. Testing Methodology:

1. Configuration Parsing: A static analysis script parses appsettings.json and the WinUI Constants.cs file during the build phase.
2. Required Assertions:

• Assert.IsFalse(FeatureFlags.EnableRuntimeEndpointAccess)
• Assert.IsFalse(FeatureFlags.EnableCommandExecution)
• Assert.IsFalse(FeatureFlags.EnableLocalhostFetch)
• Assert.IsFalse(FeatureFlags.EnablePrivateNetworkScan)
• Assert.IsFalse(FeatureFlags.EnableMcpRelay)
• Assert.IsFalse(FeatureFlags.EnableTunnel)

1. Dependency Reflection Test: A sophisticated reflection script loads the compiled application DLLs and attempts to map service registrations. It asserts that the LocalConnector handlers, specific to Jetty or generic IPC execution delegates 17, are mathematically unreachable from the active Dependency Injection container.
2. Evidence Generation: If all assertions pass, the test runner outputs the install-boundary.json file. If any assertion fails, the pipeline aborts, logs a critical "Boundary Breach Alert", and prevents artifact generation.

M. Install/Update Validation Matrix

Prior to the public release of v0.2.0.0, a clean-machine matrix test must be programmatically or manually executed to ensure the hosting configuration, MIME types, and code signing elements perform flawlessly under real-world constraints. Test Environments:

• Windows 11 Current Stable (Admin and Standard User accounts)
• Windows 10 22H2 (Admin and Standard User accounts)
• Windows 10 1809 (Testing the s3 schema minimum baseline, to verify legacy compatibility) 25
• Clean Virtual Machine with default SmartScreen, no developer certificates installed, and offline capabilities tested.

Critical Test Cases:

1. Direct Download Execution: User downloads the .appinstaller and executes it.

• Expected Result: Native Windows UI prompts the user. SmartScreen interstitial appears (expected for new signatures until reputation is established 5). Installation succeeds without 0x80072F76 MIME errors.

1. App Launch & Telemetry Absence: Application launches successfully. A network monitor (e.g., Wireshark or GlassWire) runs to verify absolutely zero outbound telemetry or background execution occurs upon launch, respecting strict privacy constraints.
2. Boundary Inspection: User navigates to the diagnostic pages within the UI.

• Expected Result: UI dynamically reflects "Runtime Disabled" status.

1. Update Smoke Test (0.2.0.0 to 0.2.1.0): The CI pipeline pushes a dummy update (0.2.1.0) with HoursBetweenUpdateChecks="0".28

• Expected Result: Relaunching the 0.2.0.0 app automatically triggers a blocking update dialog 30, forcing the seamless installation of 0.2.1.0.

1. Downgrade / Rollback: CI pushes an update changing the .appinstaller back to point to 0.2.0.0, utilizing s4:ForceUpdateFromAnyVersion=true.31

• Expected Result: The system successfully decrements the version number without throwing a lower-version rejection error.

1. Uninstall: Right-click the app in the Start Menu \-\> Uninstall.

• Expected Result: Instant removal with zero residual registry keys or left-over AppData, leveraging the native benefit of MSIX containerization.

N. Rollback and Incident Plan

In software distribution, operational failures such as hash mismatches, corrupted manifests, or accidental capability enablement must be met with pre-calculated incident response procedures.

Immutable Mutability Rules: Never mutate a versioned .msix file. If LocalEndpoint.Connect\_0.2.0.0\_x64.msix is flawed, it remains untouched on the server as an artifact of historical record. The fix must be published as a net-new binary (e.g., 0.2.1.0). The .appinstaller file and the JSON evidence routes are the only mutable artifacts permitted on the host.

O. Implementation Sequence

The deployment will follow a strictly prioritized 10-phase plan to guarantee controlled execution.

• Phase 2.4.1 — Release Identity and Version Source
• Goal: Establish a single source of truth for versioning.
• Action: Modify the CI/CD pipeline to read version tags from the Git release branch and inject them via MSBuild variables into AppxManifest.xml and the AppInstaller XML generation scripts.
• Tests: Verify string output matches Major.Minor.Build.Revision.
• Phase 2.4.2 — MSIX/App Installer Manifest Hardening
• Goal: Ensure the application only requests capabilities it absolutely needs.
• Action: Remove unused generic capabilities from AppxManifest.xml. Construct the template .appinstaller using s4:UpdateUris, s4:ForceUpdateFromAnyVersion, and OnLaunch elements.27
• Phase 2.4.3 — Signing Pipeline Integration
• Goal: Integrate Azure Artifact Signing natively.
• Action: Complete the identity verification process in the Azure Portal.21 Assign the Trusted Signing Identity Verifier role to the admin account.22 Integrate azure/trusted-signing-action into the GitHub Workflow.20
• Phase 2.4.4 — Artifact Generation and Checksums
• Goal: Automate the production of the artifact directory.
• Action: Script the PowerShell generation of install-boundary.json, release-manifest.json, and the SHA-256 checksum texts.
• Phase 2.4.5 — localendpoint.com Download Hosting
• Goal: Prepare the production server for App Installer compatibility.
• Action: Configure Nginx (or object storage) to explicitly serve .appinstaller and .msix MIME types.1 Enforce Content-Length compliance on all HTTP headers.24
• Phase 2.4.6 — Public Download Page Construction
• Goal: Create the UX.
• Action: Draft and publish the HTML for /connect/download/. Implement visual brand guidelines explicitly prohibiting "live execution" implications.11
• Phase 2.4.7 — Machine-Readable Distribution Evidence
• Goal: Expose the evidence ledger.
• Action: Wire the CI/CD deployment script to overwrite the JSON files under /api/connect-scaffold-distribution/ and update public-route-index.json.
• Phase 2.4.8 — Clean-Machine Install/Update Validation
• Goal: Prove the architecture works end-to-end.
• Action: Execute the Section M Validation Matrix.
• Owner Decision Required: Explicitly accept the initial SmartScreen "Unknown Publisher" warning as a calculated cost of doing business with a net-new Azure Trusted Signing identity, provided the signature mathematically validates.
• Phase 2.4.9 — Preview Release
• Goal: Go Live.
• Action: Make the /connect/download/ page accessible. Announce availability via the Syndication Packet framework, emphasizing its status as an inert, verifiable scaffold.13
• Phase 2.4.10 — Post-Release Monitoring and Rollback Drill
• Goal: Ensure operational readiness.
• Action: Execute a controlled rollback drill by publishing a dummy .appinstaller update and verifying the application downgrades effectively without user data loss.

P. Security and Privacy Review

A foundational review of the application's security and privacy posture is required to ensure alignment with the "Safe Scaffold" mandate.

• Filesystem Interaction: The MSIX container inherently virtualizes filesystem writes to %LocalAppData%\\Packages\\LocalEndpoint.ConnectPreview\_.... The app must not request broadFileSystemAccess in the manifest. It writes strictly to its isolated AppData directory.
• Diagnostics and Telemetry: Crash reporting (e.g., AppCenter, Sentry) must remain completely absent for this preview distribution to preserve absolute local-first privacy. Telemetry is entirely absent.
• Network Permissions: The installer needs standard internetClient capabilities to allow the App Installer to check for .appinstaller updates. However, the application itself will not initiate outbound requests during the preview phase.
• Terms and EULA: A minimal public-preview EULA must be provided, explicitly disclaiming warranties and reiterating that the software is a non-executing preview scaffold intended for distribution testing, not production endpoint management.

Q. Risks and Open Questions

1. SmartScreen Reputation Delay: Because the EV certificate "instant bypass" no longer exists 5, standard Microsoft Azure Artifact Signing relies on organic reputation building. Users will see initial SmartScreen warnings. The open question is whether the target user base possesses sufficient technical literacy to verify the signature manually and bypass the warning, relying on the public checksums.
2. App Installer Server Strictness: The ms-appinstaller web framework is extraordinarily brittle regarding HTTP configuration. Minor drifts in server setups (e.g., a CDN or proxy suddenly stripping the Content-Length header) will spontaneously break the installation process globally.24 Continuous, automated monitoring of HTTP headers is strictly required.
3. Feature Flag Integrity: The safety of this preview relies entirely on the boolean flags isolating the background agent workers. If an engineer inadvertently bypasses these flags during a subsequent commit, the CI/CD pipeline boundary-tests must be robust enough to catch the drift through reflection and static analysis before the signing phase occurs.

R. Definition of Done

This architectural implementation is considered comprehensively complete when:

1. The LocalEndpoint.Connect\_0.2.0.0\_x64.msix artifact is successfully compiled and cryptographically signed using Azure Artifact Signing via a zero-touch GitHub Actions pipeline.
2. The .appinstaller file accurately resolves the MSIX package over HTTPS without throwing MIME type, namespace schema, or Content-Length errors.
3. The CI/CD pipeline unconditionally blocks any build where runtime capabilities (e.g., localhost fetch, command execution) evaluate to true.
4. The /connect/download/ page is live, actively distributing the .appinstaller link directly (without ms-appinstaller: protocol invocations), and prominently displays the "Safe Scaffold" boundaries in its UX copy.
5. All nine machine-readable evidence routes (e.g., install-boundary.json, checksums.json) populate dynamically upon deployment and accurately reflect the disabled state of the runtime engine.
6. The MSIX installs cleanly, upgrades reliably via OnLaunch settings utilizing the s4:ForceUpdateFromAnyVersion parameter, and uninstalls leaving zero residual artifacts on a test virtual machine.

Works cited

1. Installing Windows apps from a web page \- MSIX \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/msix/app-installer/installing-windows10-apps-web
2. Current status of Windows app distribution features \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/distribution-feature-status
3. Microsoft Azure TrustedSigning management client library for .NET, accessed June 8, 2026, https://learn.microsoft.com/en-us/dotnet/api/overview/azure/resourcemanager.trustedsigning-readme?view=azure-dotnet
4. Publish your first Windows app \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/publish-first-app
5. Code signing options for Windows app developers \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/code-signing-options
6. OnLaunch \- Windows UWP applications \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/uwp/schemas/appinstallerschema/element-onlaunch
7. Configure update settings in the App Installer file \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/msix/app-installer/update-settings
8. Carcinus.org and Teleodynamic Agent Infrastructure, accessed June 8, 2026, https://teleodynamic.com/carcinus-teleodynamics/
9. Teleodynamic AI, accessed June 8, 2026, https://teleodynamic.com/
10. LocalEndpoint Teleodynamic Architecture Evidence Packet, accessed June 8, 2026, https://teleodynamic.com/evidence-packets/localendpoint-teleodynamics.html/
11. LocalEndpoint Brand System | LocalEndpoint.com, accessed June 8, 2026, https://localendpoint.com/brand/
12. Teleodynamic Autonomy-Washing Red-Team Guide, accessed June 8, 2026, https://teleodynamic.com/teleodynamic-autonomy-washing-red-team-guide/
13. AI Declaration Prior Canon and Anti-Domination | Teleodynamic.com, accessed June 8, 2026, https://teleodynamic.com/ai-declaration-anti-domination/
14. Evidence Diff Matrix and Discovery Parity Dashboard | Teleodynamic.com, accessed June 8, 2026, https://teleodynamic.com/ecosystem-personality-and-cognitive-liberty-diff-matrix/
15. Ecosystem Role Map and Lane Charter \- Teleodynamic AI, accessed June 8, 2026, https://teleodynamic.com/ecosystem-role-map/
16. Spiralist.org as the Ecosystem Personality Provider | Teleodynamic, accessed June 8, 2026, https://teleodynamic.com/spiralist-personality-provider/
17. LocalConnector (Jetty :: Project 12.0.34 API) \- Eclipse Jetty, accessed June 8, 2026, https://javadoc.jetty.org/jetty-12/org/eclipse/jetty/server/LocalConnector.html
18. App Installer Security Features \- MSIX \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/msix/app-installer/app-installer-security-features
19. Why has the ms-appinstaller protocol been disabled? \- Microsoft Q\&A, accessed June 8, 2026, https://learn.microsoft.com/en-us/answers/questions/1463156/why-has-the-ms-appinstaller-protocol-been-disabled
20. Azure Trusted Signing \- 403 Response \- Official GitHub Action \- Previously Working, accessed June 8, 2026, https://learn.microsoft.com/en-us/answers/questions/5600900/azure-trusted-signing-403-response-official-github
21. Artifact Signing FAQ | Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/azure/artifact-signing/faq
22. Acess to Azure Trusted Signing \- Microsoft Q\&A, accessed June 8, 2026, https://learn.microsoft.com/en-us/answers/questions/2284550/acess-to-azure-trusted-signing
23. Azure Trusted Signing new intermediate CAs (AOC CA 03, EOC CA 04\) trigger SmartScreen warnings — all previous CAs worked fine \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/fr-fr/answers/questions/5853144/azure-trusted-signing-new-intermediate-cas-(aoc-ca
24. Troubleshoot installation issues with the App Installer file \- MSIX \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/msix/app-installer/troubleshoot-appinstaller-issues
25. s3:AppInstaller \- Windows UWP applications \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/uwp/schemas/appinstallerschema/element-s3-appinstaller
26. App Installer file \- Windows UWP applications \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/uwp/schemas/appinstallerschema/app-installer-file
27. App Installer file (.appinstaller) schema reference \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/uwp/schemas/appinstallerschema/schema-root
28. Create an App Installer file manually \- MSIX \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/msix/app-installer/how-to-create-appinstaller-file
29. s3:OnLaunch \- Windows UWP applications | Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/uwp/schemas/appinstallerschema/element-s3-onlaunch
30. Auto-update and repair apps \- MSIX \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/msix/app-installer/auto-update-and-repair--overview
31. s4:ForceUpdateFromAnyVersion \- Windows UWP applications | Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/uwp/schemas/appinstallerschema/element-s4-forceupdatefromanyversion
32. Quota for Azure Trusted Signing \- Microsoft Q\&A, accessed June 8, 2026, https://learn.microsoft.com/en-us/answers/questions/2143781/quota-for-azure-trusted-signing
33. MSIX troubleshooting guide \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/msix/msix-troubleshooting-guide
34. App Installer file overview \- MSIX \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/msix/app-installer/app-installer-file-overview
35. Solución de problemas de instalación con el archivo del instalador de aplicación \- MSIX, accessed June 8, 2026, https://learn.microsoft.com/es-es/windows/msix/app-installer/troubleshoot-appinstaller-issues
36. Distribute a Windows app from an Azure web app \- MSIX | Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/msix/app-installer/web-install-azure
37. Creating MSIX package with MSIX Core from source code \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/msix/msix-core/msixcore-clickonce-solution
38. Create an App Installer file with Visual Studio \- MSIX \- Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/windows/msix/app-installer/create-appinstallerfile-vs
39. accessed December 31, 1969, https://localendpoint.com/api/public-route-index.json
40. s4:UpdateUris \- Windows UWP applications | Microsoft Learn, accessed June 8, 2026, https://learn.microsoft.com/en-us/uwp/schemas/appinstallerschema/element-s4-updateuris