Replace the bds-cli stub with the automation commands in specs/cli.allium, using the same database, projects, settings, engines, and domain events as the desktop app.
Current state
crates/bds-cli/src/main.rs only prints that the surface is not implemented.
Core engines already provide most underlying operations.
db_notifications and cli_sync.allium define desktop synchronization.
This issue depends on the shared domain event bus.
Required behavior
Resolve the same application data directory, database, active/project selection, filesystem layout, and settings as the desktop.
Implement full and incremental rebuild, repair, render, upload, Git sync, post creation, media creation, gallery creation, config operations, project operations, TUI launch, Lua task execution, and launcher installation from specs/cli.allium.
Route every mutation through shared engines and write the CLI notification/event required for an open desktop app.
Preserve airplane-mode AI gating for language detection, media enrichment, translation, and other automatic AI work.
Return the specified successful/error exit codes and useful machine-readable output where the spec requires it.
Never start desktop UI infrastructure for ordinary headless commands.
Implementation notes
Reuse engine functions directly; do not duplicate validation, publishing, persistence, metadata flushing, or rebuild logic.
Add only the argument parsing needed by the current command contract.
Follow red/green TDD. The CLI process tests should use temporary projects/databases and exercise actual command dispatch.
Acceptance criteria
Every command family in specs/cli.allium has dispatch and success/failure tests.
CLI-created and updated data is immediately readable by core queries, filesystem metadata, and rebuild.
An open desktop receives one notification per CLI mutation.
AI-dependent commands behave correctly online, with a configured local airplane endpoint, and without one.
The stub message is gone and --help documents all implemented commands.
cargo fmt --all -- --check, cargo build --workspace, and cargo test --workspace pass.
## Goal
Replace the bds-cli stub with the automation commands in specs/cli.allium, using the same database, projects, settings, engines, and domain events as the desktop app.
## Current state
- crates/bds-cli/src/main.rs only prints that the surface is not implemented.
- Core engines already provide most underlying operations.
- db_notifications and cli_sync.allium define desktop synchronization.
- This issue depends on the shared domain event bus.
## Required behavior
- Resolve the same application data directory, database, active/project selection, filesystem layout, and settings as the desktop.
- Implement full and incremental rebuild, repair, render, upload, Git sync, post creation, media creation, gallery creation, config operations, project operations, TUI launch, Lua task execution, and launcher installation from specs/cli.allium.
- Route every mutation through shared engines and write the CLI notification/event required for an open desktop app.
- Preserve airplane-mode AI gating for language detection, media enrichment, translation, and other automatic AI work.
- Return the specified successful/error exit codes and useful machine-readable output where the spec requires it.
- Never start desktop UI infrastructure for ordinary headless commands.
## Implementation notes
- Reuse engine functions directly; do not duplicate validation, publishing, persistence, metadata flushing, or rebuild logic.
- Add only the argument parsing needed by the current command contract.
- Follow red/green TDD. The CLI process tests should use temporary projects/databases and exercise actual command dispatch.
## Acceptance criteria
- Every command family in specs/cli.allium has dispatch and success/failure tests.
- CLI-created and updated data is immediately readable by core queries, filesystem metadata, and rebuild.
- An open desktop receives one notification per CLI mutation.
- AI-dependent commands behave correctly online, with a configured local airplane endpoint, and without one.
- The stub message is gone and --help documents all implemented commands.
- cargo fmt --all -- --check, cargo build --workspace, and cargo test --workspace pass.
The bds-cli stub is now a typed native Clap CLI over the same application paths, SQLite database, project registry, settings, filesystem metadata, rebuild/render/publish/Git, post/media/gallery, config/project, Lua, notification, and AI-gating engines used by the desktop app. It provides stable text/JSON output and 0/1 exit semantics, guarded launcher installation, and a localized Settings > Data installer. The packaged macOS app now ships both bds-ui and bds-cli.
The implementation adds full/incremental rebuild, exact transactional repairs, full/forced/incremental rendering, upload, push/pull with post-pull cache sync, JSON or flag-driven post/gallery creation, shared media enrichment and translation, utility Lua execution, and deduplicated CLI domain notifications. Airplane mode blocks network commands and exclusively selects the local AI endpoint; unavailable AI uses documented fallbacks/notices. Later engines are handled honestly: embeddings fail when enabled until #23 supplies the real model, and direct TUI dispatch retains the baseline launcher guard until #27 supplies the terminal surface.
Neutral review compared the implementation with the issue, bDS2 CLI/launcher behavior, and specs/cli.allium. It caught and fixed fresh-database FTS initialization, Lua notification persistence, notification deduplication/final actions, exact media-link transactions, publish cache selection, packaged-binary omission, thumbnail format validation, gallery excerpt persistence, search repair notification, and full-rebuild thumbnail repair.
Verification passed: cargo fmt --all -- --check; cargo build --workspace; strict workspace clippy; cargo test --workspace including 9 CLI unit dispatch tests, 2 real-process suites, 423 core tests plus integration suites; isolated CLI/event/media suites; allium check and analyse with zero findings; cargo-packager macOS app build; and packaged Settings visual QA.
Implemented in fdfae20 and pushed to main.
The bds-cli stub is now a typed native Clap CLI over the same application paths, SQLite database, project registry, settings, filesystem metadata, rebuild/render/publish/Git, post/media/gallery, config/project, Lua, notification, and AI-gating engines used by the desktop app. It provides stable text/JSON output and 0/1 exit semantics, guarded launcher installation, and a localized Settings > Data installer. The packaged macOS app now ships both bds-ui and bds-cli.
The implementation adds full/incremental rebuild, exact transactional repairs, full/forced/incremental rendering, upload, push/pull with post-pull cache sync, JSON or flag-driven post/gallery creation, shared media enrichment and translation, utility Lua execution, and deduplicated CLI domain notifications. Airplane mode blocks network commands and exclusively selects the local AI endpoint; unavailable AI uses documented fallbacks/notices. Later engines are handled honestly: embeddings fail when enabled until #23 supplies the real model, and direct TUI dispatch retains the baseline launcher guard until #27 supplies the terminal surface.
Neutral review compared the implementation with the issue, bDS2 CLI/launcher behavior, and specs/cli.allium. It caught and fixed fresh-database FTS initialization, Lua notification persistence, notification deduplication/final actions, exact media-link transactions, publish cache selection, packaged-binary omission, thumbnail format validation, gallery excerpt persistence, search repair notification, and full-rebuild thumbnail repair.
Verification passed: cargo fmt --all -- --check; cargo build --workspace; strict workspace clippy; cargo test --workspace including 9 CLI unit dispatch tests, 2 real-process suites, 423 core tests plus integration suites; isolated CLI/event/media suites; allium check and analyse with zero findings; cargo-packager macOS app build; and packaged Settings visual QA.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Goal
Replace the bds-cli stub with the automation commands in specs/cli.allium, using the same database, projects, settings, engines, and domain events as the desktop app.
Current state
Required behavior
Implementation notes
Acceptance criteria
Implemented in
fdfae20and pushed to main.The bds-cli stub is now a typed native Clap CLI over the same application paths, SQLite database, project registry, settings, filesystem metadata, rebuild/render/publish/Git, post/media/gallery, config/project, Lua, notification, and AI-gating engines used by the desktop app. It provides stable text/JSON output and 0/1 exit semantics, guarded launcher installation, and a localized Settings > Data installer. The packaged macOS app now ships both bds-ui and bds-cli.
The implementation adds full/incremental rebuild, exact transactional repairs, full/forced/incremental rendering, upload, push/pull with post-pull cache sync, JSON or flag-driven post/gallery creation, shared media enrichment and translation, utility Lua execution, and deduplicated CLI domain notifications. Airplane mode blocks network commands and exclusively selects the local AI endpoint; unavailable AI uses documented fallbacks/notices. Later engines are handled honestly: embeddings fail when enabled until #23 supplies the real model, and direct TUI dispatch retains the baseline launcher guard until #27 supplies the terminal surface.
Neutral review compared the implementation with the issue, bDS2 CLI/launcher behavior, and specs/cli.allium. It caught and fixed fresh-database FTS initialization, Lua notification persistence, notification deduplication/final actions, exact media-link transactions, publish cache selection, packaged-binary omission, thumbnail format validation, gallery excerpt persistence, search repair notification, and full-rebuild thumbnail repair.
Verification passed: cargo fmt --all -- --check; cargo build --workspace; strict workspace clippy; cargo test --workspace including 9 CLI unit dispatch tests, 2 real-process suites, 423 core tests plus integration suites; isolated CLI/event/media suites; allium check and analyse with zero findings; cargo-packager macOS app build; and packaged Settings visual QA.