Tetral v0.1.0-alpha.2

Changes since v0.1.0-alpha.1

This Alpha release adds per-repository Git identities, fixes database permissions required by runtime operations, and separates database preparation from application startup. It also increases resources for newly built Sandbox snapshots and improves tool-failure diagnostics.

The comparison uses the recorded alpha.1 Candidate source (f9f1f7977e766d0478b31e2d47036acbebdecb7a), because alpha.1 has no Git tag or GitHub Release. Alpha.2 contains source 3e9d791f140e664dcd2c1c18e3ca9dd09c1c1847.

Features and fixes

• Per-repository Git identity. A Session's github_repository resource can declare an optional git_identity with name and email. Engine persists it and configures repository-local Git authorship during clone and rematerialization. Different repositories in the same Session can use different identities. Omission retains the platform default; explicit null or malformed values are rejected. The identity cannot be updated after creation, and rotating the repository access token does not change it. #48
• Database permissions for production workloads. Restore missing API, Bridge, and Sandbox grants required for queue admission, Sandbox activation and resource preparation, Git tickets, media staging, Memory and skills, compaction, background-task settlement, and Session deletion. Sandbox queue-consumer failures now emit classified warnings without raw database errors. #45, #47
• Standalone database preparation. The new tetral-db-prepare command applies schema migrations and managed-role grants before services start. API startup no longer performs these operations. V2 adds the Git identity columns without rewriting V1 or existing repository data. Preparation logs report safe failure reasons and migration transaction outcomes. #55
• Sandbox capacity and tool errors. Newly built package snapshots request 4 vCPU, 8 GiB RAM, and 10 GiB disk. Recognized Daytona failures while preparing tool payloads produce concise storage-full, access-denied, or read-only-filesystem messages. Preparation failures distinguish “not started” from errors after submission where execution remains uncertain. Provider diagnostics are sanitized before logging. #54

Verification and release tooling

• Run the forked SDK's integration suite against a local Engine topology in CI, with explicit dependencies and executed-result checks. Add coverage for the Git identity API contract and remove unused external live-test infrastructure. #50, #51, #53
• Remove timing races in interrupt-retry and queue-reconnect tests. These are test corrections, not changes to queue ordering or retry behavior. #49, #55
• Require structured rehearsal evidence bound to the Candidate, including per-step results and a final health check, before promotion. #56

Upgrading from alpha.1

1. Schedule a maintenance window, stop application traffic and workers, and preserve a database backup.
2. Run this release's tetral-db-prepare with a PostgreSQL superuser administrative connection and the full managed-role declarations. It replaces the old standalone tetral-postgresql-roles command and API-startup migration path. Start the updated services only after it exits successfully.
3. If role installation fails after migration commits, correct the reported issue and rerun preparation; the committed migration is not automatically undone. V2 has no automatic downgrade, and older binaries reject the newer schema.
4. Register the release's Tetral Sandbox image as the default Daytona snapshot with the 4/8/10 allocation. Existing Environments and Sandboxes are not automatically resized; existing Environment artifacts can retain their old snapshots. Account for regional resource quotas when planning concurrency.

See the versioned database preparation contract, upgrade and rollback procedure, and Sandbox registration instructions.

Full source comparison: alpha.1 Candidate → alpha.2