Docs

Runbooks

How Cassette is built, run and moved from branch to release, rendered from the repository's own runbooks at the committed head.

Run and build Cassette

Source
docs/BUILD.md
Last updated
2026-10-31, commit 14e3595
Owner
build lane
Read it

Run Cassette

Cassette 0.1 is a Windows-first Tauri 2 application. It uses the installed WebView2 runtime rather than bundling Chromium. There is no server or account requirement.

Windows

Install Node.js 22 or newer, Rust stable, Microsoft C++ Build Tools (Desktop development with C++), and Microsoft Edge WebView2. Install FFmpeg for conversion, compressed exports, and transcription audio preparation:

winget install Gyan.FFmpeg

Open a fresh terminal so FFmpeg is on PATH, then:

npm ci
npm run desktop

Build an NSIS installer:

npm run desktop:build -- --bundles nsis

The installer is under target/release/bundle/nsis. The checked-in Windows workflow performs tests and uploads the installer as an artifact. Installer signing is not configured.

This cloud workspace

source /workspace/.cassette-env/activate.sh
npm ci
npm run dev       # browser preview, port 1420
npm run desktop   # native desktop; requires a graphical display
npm test
npm run check

The browser preview uses IndexedDB, browser microphone permissions, and WAV exports. It intentionally disables API keys and cloud calls. The desktop uses SQLite, native microphones, and FFmpeg. Sample audio is generated music tones; it contains no speech.

Implemented

  • Local managed library, real audio import, metadata, tags as collections, search, filters, sorting.
  • Native PCM WAV capture, input selection, live meter, pause/resume, flushed temporary capture, explicit interruption recovery.
  • Immutable originals with durable source-range recipes, waveform selection, trim, split, delete, undo/redo, seek, loop, six playback speeds.
  • WAV, MP3, M4A/AAC, FLAC, and OGG exports with intent presets, sample rate, channels, bitrate, normalization, estimated size, progress, cancellation, and same-directory atomic finalization. Codec availability depends on FFmpeg.
  • Explicit cloud transcription and diarization through OpenAI (gpt-4o-transcribe-diarize), Deepgram (nova-3), and AssemblyAI (universal-2). Timestamped speaker segments, transcript export, and recipe-revision checks prevent synchronization against a different edit.
  • Optional API-key persistence through Windows Credential Manager, macOS Keychain, or Linux Secret Service. Keys never enter SQLite, browser preview storage, or logs. Without a working credential store use a key for one request only.

Cloud transcription sends the entire edited recording only after a provider-specific confirmation. Provider charges and retention policies apply. Cancellation stops local work; audio already submitted may still be processed or billed. No retries or cross-provider fallback happen automatically. OpenAI submissions exceeding the upload limit fail before uploading.

Current limits

Windows installer and microphone hardware behavior must be validated on Windows. Live provider requests require your key and were not exercised in this workspace. Long provider calls may take time to acknowledge cancellation. Watched folders, local AI, named speaker profiles, multiple microphones, and cross-device sync are deferred. Local undo history lasts for the current editor session; the current recipe persists across restarts. Recordings have no hard duration cap but large audio uses disk space for the managed source and PCM playback copy.

Branch and release flow

Source
docs/WORKSPACE-RUNBOOK.md
Last updated
2026-10-31, commit 03623f1
Owner
integration lane
Read it

Branch and release flow

the build agent/<change> → PR → staging → promotion PR → main.

  • main is the existing default/release branch; do not create a second Main.
  • staging is the integration and release-candidate branch, initially created from main. Branch new work from refreshed staging.
  • Every feature, fix, documentation update, and hotfix goes through a PR to staging. No direct pushes to staging or main. Builders do not merge their own work. the product owner authorized this workspace's lead to manage integration and CI/CD on 2026-10-31. The lead may merge only after independent approval of the exact source head, recording reviewer, test receipts, limits, and rollback.
  • Main accepts only a PR from this repository's staging branch. No feature PRs, cherry-picked hotfixes, or direct commits into main.
  • Use a merge commit for staging → main promotion to preserve ancestry; do not squash or rebase that promotion. Staging retains main ancestry for the next cycle.
  • Existing open PRs are retargeted to staging. Review overlapping spec/history and dependencies before merging; retargeting alone does not resolve conflicts.

Work and integration

  1. Fetch origin; create a the build agent branch from origin/staging in a clean worktree. Preserve existing dirty work separately. Never reset another worker's files.
  2. Give each lane file ownership and agreed shared contracts. Serialize storage, schema, capture ownership, and version-ledger integration.
  3. Run focused tests and open a PR to staging with behavior, exact test commands and results, remaining limits, and migration/rollback implications.
  4. An independent reviewer reviews; the authorized lead integrates the approved head. Substantive repairs or conflict resolutions require a fresh review. The integrator reconciles Pondo ledger increments against current staging; do not count a promotion twice.
  5. Qualify the combined staging candidate locally on Windows, using copied app data first. Record exact source revision, artifact hash, version, and checks.
  6. Open staging → main with release notes, Pondo census, test receipts, hardware checks, and rollback instructions. Promote only after independent approval.
  7. Release the qualified artifact tied to that source; if rebuilding, verify the new artifact. Keep the previous installer/data backup for rollback.

First-build validation

Source
docs/VALIDATION.md
Last updated
2026-10-31, commit 14e3595
Owner
qualification lane
Read it

First-build validation

The strict TypeScript/Vite production build and cargo check --workspace pass. Four timeline tests and four Rust tests pass, covering SQLite persistence, original preservation, all five export formats, and provider speaker/timestamp normalization.

Browser automation passes for sample import, playback, selection, trim, undo/redo, WAV download, recipe persistence across reload, and the provider dialog, with no JavaScript runtime errors. Screenshots are in artifacts/library.png, artifacts/editor.png, and artifacts/transcription.png.

The Linux Tauri debug executable built at /workspace/.cassette-env/validation/tauri-smoke/target/debug/cassette. The Windows NSIS workflow is configured but has not run here. Physical microphone capture, native desktop interaction, and real provider requests need device-side verification.

Run node scripts/check-ui.mjs with a preview on port 1420. Set CHROMIUM_PATH to your Chromium executable outside this workspace.