@appport/appboundry

Build and verify an AppPort application for AppBoundry. The default commands operate on the current repository's authoritative contract, implementation, and WASM artifact.

The canonical AppBoundry product tooling is available under the explicit product subcommand, so it cannot be confused with a customer application build:

# Wrap the customer application in the current directory
npx appport add
npx @appport/appboundry test
npx @appport/appboundry build
npx @appport/appboundry verify

# Build the canonical AppBoundry product
npx @appport/appboundry product build
npx @appport/appboundry product certify

The package ships templates/appboundry.gitignore for generated or copied AppBoundry workspaces. Installers copy it to .gitignore; it excludes macOS metadata (.DS_Store and .DS_changes) and node_modules/.

npx @appport/appboundry product build --out AppBoundry.app
npx @appport/appboundry product certify # defaults to AppBoundry.app

test opens AppPort Studio against the current repository's running application so its capability boundary can be exercised before deployment. build emits a repository-named immutable AppPort/application-bundle/1 .app directory plus its browser-uploadable .appbundle. verify checks that application and its declared capabilities. product build and product certify are reserved for the canonical AppBoundry platform artifact.

WASM providers

AppBoundry reuses the same .app package for a verified Synapse WASM capability. Synapse owns module discovery, validation, the capability contract, and WASM execution semantics; AppBoundry owns packaging, provider composition, binding, authorization, and invocation routing:

.app
 └── WASM provider
       ↓
  Synapse capability
       ↓
 AppBoundry discovery → bind → invoke

For example, a packaged change-context-resolver continues to advertise [email protected]. A consumer requires that capability through the normal AppBoundry composition API and does not need to know the artifact path, module filename, or runtime. Inspecting or installing the package reports runtime: wasm while preserving the Synapse capability identity.

To share a private HTTP application through an AppBoundry edge, keep the application bound to localhost and run:

npx @appport/appboundry connect 3000 --edge https://edge.example

Or set APPBOUNDRY_EDGE_URL and optionally APPBOUNDRY_CREDENTIAL.

The connectivity path is provider-neutral and does not require an AppPort application runtime. The client makes an authenticated outbound connection to the configured edge, receives an edge-issued share and endpoint, and proxies a bounded HTTP subset to the local port.

The package also exposes an in-memory capability composition runtime plus snapshot-backed inspection commands so provider/consumer/binding state stays observable without requiring direct application-to-application integration:

# publish a local capability provider into a runtime snapshot
npx @appport/appboundry capabilities publish llm.generate@1 \
  --provider local-llm \
  --application example.local-llm

# register a consumer requirement
npx @appport/appboundry capabilities require llm.generate@1 \
  --consumer my-app \
  --application example.consumer

# inspect currently reachable providers
npx @appport/appboundry providers llm.generate@1

# create a logical binding
npx @appport/appboundry bind llm.generate@1 \
  --consumer-application example.consumer \
  --provider-application example.local-llm

# inspect the application view
npx @appport/appboundry capabilities --application example.consumer

By default these commands read and write .appboundry/runtime.json in the current working directory. Pass --runtime <path> to target a different snapshot file, and --json for machine-readable output.

Current connectivity surface:

• shared AppBoundry/connect protocol with hello, ready, request, response, heartbeat, close, and error messages
• edge-owned connection_id, share_id, endpoint_id, and authenticated application_id
• explicit bounded buffering with:
  • max request body: 524288 bytes
  • max response body: 524288 bytes
  • max frame size: 2097152 bytes
• supported methods: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS
• hop-by-hop header filtering in both directions
• heartbeat/liveness, disconnect, reconnect, revoke, and expire handling

Current limitations:

• buffering is bounded rather than streamed
• the development edge is single-node and keeps share/endpoint state in memory
• status / revoke CLI commands are not yet exposed; revocation and expiry are edge capabilities