Local Setup And Sync

The local coordinating node is the API process that sits behind the static frontend during local development. It lets the app function as a real local file and workflow manager before any cloud backend is connected. It owns local persistence, object writes, connection manifests, and sync metadata. The browser never receives cloud credentials.

Run the local API and Observable preview together:

npm install
npm run dev:local

The default endpoints are:

Existing .wm-data/workspace.json, .wm-data/sync-items.json, and .wm-data/objects-manifest.json files are imported into SQLite on first run. After that, SQLite is the source of truth for workspace state, sync metadata, and object manifests.

In local-only mode, the application is not connected to AWS or Azure. Records are read from and written to the local API, the SQLite database, and the local object directory. Cloud resources are used only after provider connections are added and sync operations are run.

API Surface

The frontend uses:

The coordinating node also exposes:

Provider Connections

Connections are non-secret manifests. They identify a provider, resource names, and a credential reference. Do not store keys, tokens, connection strings, or passwords in the manifest.

The coordinating node can keep multiple provider surfaces aligned. A local workspace can have a local backup connection, an AWS connection, an Azure connection, or both cloud connections. The sync API converts workspace state into provider-neutral sync items, pushes those items to connected providers, pulls remote items back, and merges them through the same conflict rules.

Current provider roles:

Local connection:

{
  "connection_id": "local_backup",
  "provider": "local",
  "credential_mode": "none",
  "settings": {
    "rootDir": ".wm-data-backup"
  }
}

AWS connection:

{
  "connection_id": "aws_dev",
  "provider": "aws",
  "credential_mode": "aws_profile",
  "credential_ref": "profile:workspace-dev",
  "settings": {
    "region": "us-east-1",
    "bucket": "workspace-management-dev-documents",
    "table": "workspace-management-dev"
  }
}

Azure connection:

{
  "connection_id": "azure_dev",
  "provider": "azure",
  "credential_mode": "azure_cli",
  "credential_ref": "az-login",
  "settings": {
    "resourceGroup": "wm-dev-rg",
    "location": "eastus",
    "storageAccount": "workspacemanagedevdocs",
    "container": "workspace-documents",
    "cosmosAccount": "workspace-management-dev-cosmos",
    "database": "workspace",
    "itemContainer": "workspace_items"
  }
}

Sync Contract

Workspace objects are converted to provider-neutral sync items:

Merges use deterministic checksums and last-writer-wins conflict records. Deleted records travel as tombstones through deleted_at.

This means connected surfaces should converge on the same canonical accounts, projects, document artifacts, grants, metadata records, and write events even when AWS and Azure are both connected. Provider-specific storage services differ, but the application sync payload does not.

Adapter Status

The local filesystem adapter is implemented with SQLite metadata and a local object directory. AWS and Azure adapters are implemented server-side through the local CLI tools:

The adapters use server-side credentials from AWS profiles, instance roles, Azure CLI, managed identity, or deployment environment variables. The browser only calls the coordinating-node API and never receives provider credentials.

AWS requires the aws CLI and a connection with region, bucket, and table.

Azure requires the az CLI and a connection with resourceGroup, location, storageAccount, container, cosmosAccount, database, and itemContainer. The Cosmos item upsert path uses the Azure CLI cosmosdb sql item upsert command; install or enable the relevant Azure CLI support if your local az distribution does not include that command group.