ips/docs/ai/decisions/001-libips-api-layer-for-gui-sharing.md

39 lines
1.8 KiB
Markdown
Raw Normal View History

# ADR-001: Elevate Business Logic into libips API Layer
**Date:** 2026-02-25
**Status:** Accepted
## Context
pkg6 (CLI client) implements significant business logic inline in `main.rs` — install orchestration, solver advice generation, action plan creation, progress reporting, and package pattern parsing. A future GUI client must replicate all of this, leading to duplication or divergence.
The `libips::api` module already exists as a high-level facade (ManifestBuilder, Repository, PublisherClient, Lint) but covers only publishing workflows. Client-side operations (install, uninstall, update, search, verify, info, contents) have no library-level orchestration.
## Decision
All client-side business logic moves into `libips::api` as composable operation types. The pattern:
```
libips::api::install::InstallOptions -> InstallPlan -> ActionPlan -> apply()
libips::api::search::SearchOptions -> SearchResults
libips::api::info::InfoQuery -> PackageDetails
```
pkg6 becomes a thin CLI adapter: parse args -> build options struct -> call libips -> format output.
A future GUI client imports the same `libips::api` types and calls the same methods.
## Key Design Rules
1. **Options structs** carry all configuration (dry_run, accept_licenses, concurrency, etc.)
2. **Progress reporting** via trait object callbacks — CLI prints text, GUI updates progress bars
3. **No formatting in libips** — return structured data, let consumers format
4. **Error types** carry miette diagnostics — both CLI and GUI can render them
## Consequences
- pkg6/src/main.rs shrinks dramatically
- GUI client shares 100% of logic with CLI
- Testing improves — library operations are unit-testable without CLI harness
- Breaking change for anyone importing libips directly (unlikely given current adoption)