AirBridge v0.1.0-alpha Release Notes

Release type: Public alpha
Version: 0.1.0-alpha
Commit prepared from: be270d3 — docs: prepare v0.1.0-alpha release notes
Date: 2026-06-27
License: Apache-2.0
Publishing checklist: v0.1.0-alpha-publishing-checklist.md

Overview

AirBridge v0.1.0-alpha is the first public alpha release. It delivers the core backup, inspection, and restore planning workflows for Airtable bases. Restore write execution is intentionally disabled — no Airtable data is written by restore operations in this version.

This release is intended for early testers who want to evaluate backup and inspection capabilities and provide feedback before restore execution is approved and enabled.

This is not a production-ready release. It is not recommended for use with production Airtable bases without understanding the limitations documented here.

Platform smoke-test status for this publish: macOS — app launches, no external network on startup, no crash (partial). Linux and Windows smoke tests are deferred for this alpha publish; full platform validation will be completed in a subsequent pass.

What Is Included

Connection Check

Verify a personal access token and inspect read/write/schema permissions before running a backup.
Token is validated for structural completeness before any API call.
Token is never stored, logged, or included in any result.

Backup

Base selection — list all accessible bases for a token and select one to back up.
Backup planning — preview tables, fields, record counts, and field compatibility classifications.
Records export planning — generate a table ordering plan that respects linked record dependencies.
Backup execution — write a .airbridge ZIP package to a user-chosen local path.
- Requires explicit file picker selection.
- Requires the exact confirmation text CREATE BACKUP before any write.
- Output path validation prevents path traversal, wrong extensions, and writes into existing directories.
- Token consumed per-operation and never stored.
- Cancellation supported mid-job.
Attachment metadata — attachment metadata and URLs at time of backup are captured. Attachment file bytes are not downloaded. URLs may expire after backup.

Package Inspection

Open any .airbridge file and review its contents without starting a restore.
Validate manifest integrity, schema consistency, checksum validity, and restore compatibility.
Field compatibility report classifies each field as Restorable, Partially Restorable, Metadata Only, or Unsupported.
Read-only: no files extracted, no token required, no Airtable API calls.

Restore Dry-Run and Planning (Read-Only — Writes Disabled)

All restore planning is read-only. No token is required. No Airtable API calls are made. No Airtable base, table, field, or record is created by any planning step.

Restore dry-run — generate a restore plan preview: tables, field compatibility, record counts, ordering, and warnings.
Restore schema creation plan — generate a full schema creation order from a dry-run result: table creation steps (ordered to satisfy linked record dependencies), field creation steps, deferred linked record fields, manual-action fields, and a dependency graph.
Restore record import plan — generate a record import batch plan: per-table batch counts (batch size 10), field import policies, linked record second-pass update plans, attachment metadata policies, old-to-new record ID mapping strategy, per-table checkpoint plans, and retry policy.
Restore execution gate — validates all preconditions (inspection status, dry-run plan, target mode, token presence, confirmation text RESTORE BACKUP). When all gates pass, the command returns readyButDisabled. No Airtable writes are made. This gate confirms the pipeline is correctly wired; it does not enable execution.
Write engine preview — a six-phase pipeline preview (ValidateInputs, SchemaCreation, RecordCreation, LinkedRecordUpdates, AttachmentHandling, FinalValidation). All phases are disabled. No token required. No Airtable API calls.
Schema write engine foundation — sequenced schema write request plan builder. No Airtable tables or fields created. Write gate always disabled.
Record write engine foundation — sequenced record write request plan builder. No records created, updated, or deleted. No raw record payloads in any result. Write gate always disabled.

Credential Storage (Optional)

Optional save of the Airtable Personal Access Token to the OS keychain (Settings → Saved Credentials).
Token stored via OS credential store (macOS Keychain, Windows Credential Store, Linux Secret Service).
Token never returned by any command. Token never in files, SQLite, localStorage, or logs.
Saved token is not yet auto-retrieved for operations — users must still paste the token manually.

Local Activity History

Recent operations (connection checks, backup jobs, restore attempts) shown on the Reports page.
Safe summaries only: no tokens, no full paths, no record payloads, no attachment URLs.
In-memory only; cleared on application restart.

Release Build Workflow

workflow_dispatch-only GitHub Actions release workflow builds Tauri on macOS, Linux, and Windows.
Artifacts uploaded as workflow run artifacts only. No GitHub release is created automatically.

What Is Intentionally Not Included

Capability	Status	Note
Restore write execution	Disabled by policy	Gate complete; planning complete; live writes require product and security approval
Live schema writes	Disabled	Schema write request plan builder implemented; write gate always blocks execution
Live record writes	Disabled	Record write request plan builder implemented; write gate always blocks execution
Linked record second-pass execution	Disabled	Second-pass plans implemented; execution requires write engine
Attachment binary restore	Not implemented	Metadata and URLs backed up; file bytes not re-uploaded; binary restore is future work
Attachment binary download (backup)	Not implemented	Metadata-only policy; file bytes not downloaded at backup time
UI/Tauri live restore execution surface	Does not exist	No Tauri command, no UI button, no TypeScript path enables live restore
Credential auto-fill	Not implemented	Saved token not yet wired to operations
Job history persistence	Not implemented	In-memory only; SQLite persistence deferred
Streaming progress	Not implemented	Backup progress is polled; streaming deferred
Restore into non-empty bases	Blocked by design	Prevents destructive overwrites
Merge/overwrite restore	Not planned for v0.1	Prevents data loss
Automations, interfaces, sharing settings	Not in scope	Not in v0.1 scope
System field restore (created time, etc.)	Not possible	Airtable API does not support writing system fields
macOS notarization	Not configured	Gatekeeper may warn on first launch
Windows code signing	Not configured	SmartScreen may warn on first launch

Restore Safety Status

Restore execution is disabled. This is a deliberate product policy, not a missing implementation. The following invariants hold unconditionally in this version:

evaluate_write_gate() returns Disabled/DisabledByProductPolicy — there is no enabled branch.
RestoreWriteEngineStatus::Succeeded does not exist in the type system.
No Tauri command, no UI surface, and no TypeScript path exposes live restore execution.
App runtime reads, writes, and execution remain disabled.
noChangesMade is always true for all restore planning commands.
networkWritesAttempted is always false for all planning commands.
No token, full path, record payload, raw HTTP body, old/new record IDs, or attachment URL is exposed by any restore planning command.

The restore release readiness snapshot (build_restore_release_readiness_snapshot) returns AlphaReadyRestoreRuntimeDisabled when all safety gates pass. This status does NOT mean user-facing restore execution is complete or approved. Runtime restore execution (RRRS-AREA-10), attachment handling (RRRS-AREA-11), and product/security approval (RRRS-AREA-12) remain disabled or pending in all cases.

Restore is best-effort schema reconstruction — not a perfect clone. When execution is eventually enabled, the intended restore target is a new or empty Airtable base. Restore does not support non-empty bases, merge, or overwrite in v0.1.

Known Limitations

See known-limitations.md for the full list. Key limitations:

Restore write execution not yet enabled — all planning steps complete; live writes deferred.
Attachment binary handling disabled — metadata and URLs captured at backup time only; file bytes not downloaded or re-uploaded; attachment URLs may expire.
Credential auto-fill not implemented — saved keychain token not yet retrieved automatically.
Job history is in-memory only — does not persist between application restarts.
Computed field types (formula, rollup, lookup) must be recreated manually after any future restore.
Old-to-new record ID mapping requires live execution — available only after first-pass record creation.
No streaming backup progress — progress is polled.
No automatic rate-limit retry — user must retry manually.
Linked record second-pass updates are planned but not executed.
Release build artifacts require smoke-testing on all platforms before any public distribution.
macOS .dmg is not notarized — Gatekeeper may warn on first launch.
Windows .msi is not code-signed — SmartScreen may warn on first launch.
greet Tauri scaffold command remains registered (harmless, unused in UI).
Write-permission pre-verification for restore targets is not implemented — checked at write time only.

QA Status

Suite	Count	Result
Rust unit tests (non-ignored)	2561	All pass
Rust integration tests (ignored by default)	5	Opt-in only — see Maintainer Sandbox Harness section
Frontend tests	1533	All pass
Total (default suite)	4094	All pass

The default test suite performs no Airtable network calls. All 2561 Rust unit tests and 1533 frontend tests run offline. No live harness runs in the default suite.

Maintainer-Only Sandbox Harnesses

Five Rust integration tests are present for maintainer-only opt-in validation of each restore phase:

Harness	File	Opt-in Env Var
Schema write	`tests/live_schema_write_sandbox.rs`	`AIRBRIDGE_ENABLE_LIVE_SCHEMA_WRITE_TEST=true`
Record write	`tests/live_record_write_sandbox.rs`	`AIRBRIDGE_ENABLE_LIVE_RECORD_WRITE_TEST=true`
Linked update	`tests/live_linked_update_sandbox.rs`	`AIRBRIDGE_ENABLE_LIVE_LINKED_UPDATE_TEST=true`
Final validation read	`tests/live_final_validation_sandbox.rs`	`AIRBRIDGE_ENABLE_LIVE_FINAL_VALIDATION_TEST=true`
E2E restore	`tests/live_e2e_restore_sandbox.rs`	`AIRBRIDGE_ENABLE_LIVE_E2E_RESTORE_TEST=true`

All five harnesses are #[ignore] by default — they do not run in standard cargo test and are not reachable from normal app runtime. Each requires all relevant environment variables to be set explicitly and must only be run against a disposable sandbox Airtable base. The test may leave tables or records in the sandbox base; no automatic cleanup is performed.

These harnesses do not enable app runtime restore execution. evaluate_write_gate() remains Disabled/DisabledByProductPolicy before and after each harness run.

Before Publishing Checklist

Complete all items before creating a GitHub release or distributing artifacts:

Installation

See installation guide if available, or follow the platform-specific notes:

macOS: Mount the .dmg and drag AirBridge to Applications. If Gatekeeper blocks launch, right-click the application and choose Open.

Linux: Mark the .AppImage as executable (chmod +x) and run it directly. For the .deb package, install with sudo dpkg -i <package>.deb.

Windows: Run the .msi installer. If Windows SmartScreen shows a warning, click "More info" and then "Run anyway."

Feedback

Please report issues and feedback on the project issue tracker. Include:

Operating system and version.
Steps to reproduce.
What you expected vs. what happened.
Whether the issue involves token input (do not include the token value itself).

Navigation Menu

AirBridge v0.1.0-alpha

Choose a tag to compare

Sorry, something went wrong.