feat(usable): package gui-host validation snapshot

Co-Authored-By: Paperclip <noreply@paperclip.ing>

PRODUCT_REQUIREMENTS.md

@@ -6,9 +6,11 @@ This document defines the first release boundary for `dbtool-cli-v1` so the CTO
 
 ## Current Demo Audit
 
-- As of 2026-03-25, the configured project workspace had no repository contents, no Rust workspace, no README, and no runnable CLI binary.
-- The current project state is therefore a scoped backlog plus a project goal, not an already-working demo.
-- This document should be treated as the product baseline for implementation, not as a polish pass on existing behavior.
+- As of 2026-03-26, the repository contains a Rust workspace, a runnable CLI surface, demo fixtures, smoke runbooks, and future GUI foundation artifacts.
+- The current demo already implements the shared operator flow for PostgreSQL, MySQL, and SQLite: `connect`, `inspect`, `query`, and `export`.
+- Current user-visible behavior includes `.sql` file execution, parameterized query support, CSV / JSON export, and password injection via `--password-env` with redacted output.
+- The remaining product work is not “invent the first scope from zero”; it is “freeze the first release boundary, clarify database support levels, and prevent advanced admin workflows from leaking into the current project.”
+- `DATABASE_SUPPORT_MATRIX.md` is the controlling reference for database tiers, phase boundaries, and what “full support” means in product terms.
 
 ## Target Users
 
@@ -37,6 +39,8 @@ The value is consistency across supported databases, not feature depth equal to
 
 Today, the operator would otherwise need to learn different connection rules, inspection commands, and export workflows across `psql`, MySQL tools, and SQLite tooling. `dbtool-cli-v1` should reduce that tool-switching cost for the most common technical workflows.
 
+This product does not aim to replace native admin consoles or general-purpose SQL IDEs. Its first promise is a consistent core workflow, not full database-administration parity.
+
 ## Primary V1 Workflow
 
 The most important end-to-end flow is:
@@ -55,6 +59,7 @@ If this flow is not smooth, V1 is not successful.
 
 - local CLI only
 - database support for PostgreSQL, MySQL, and SQLite only
+- Tier A core support for those three databases as defined in `DATABASE_SUPPORT_MATRIX.md`
 - explicit connection selection for each run
 - schema and table inspection
 - column-level metadata inspection
@@ -66,6 +71,7 @@ If this flow is not smooth, V1 is not successful.
 ### Product Boundaries
 
 - V1 is an operator tool, not a visual database client.
+- V1 “full support” means complete support for the core operator workflow, not complete coverage of every database-native administrative feature.
 - V1 must optimize for correctness and consistency before convenience features.
 - Exact command names, flag shapes, crate boundaries, and config storage are implementation choices owned by the CTO as long as they satisfy the acceptance criteria below.
 
@@ -75,7 +81,13 @@ The following are explicitly out of scope for V1:
 
 - desktop GUI or web GUI
 - support for databases beyond PostgreSQL, MySQL, and SQLite
+- saved profile management as a user-facing workflow
 - migration management or schema-editing workflows
+- import workflows
+- transaction management UX
+- stored procedure or function management UX
+- permission or user administration
+- backup or restore workflows
 - ORM features, query builders, or notebook-style authoring
 - background sync, job scheduling, alerts, or long-running daemon behavior
 - shared team workspaces, cloud sync, or centralized connection management
@@ -155,6 +167,16 @@ A QA engineer receives a local SQLite file:
 
 These scenarios should remain happy-path examples in engineering docs and QA checks.
 
+## Database Scope Reference
+
+`DATABASE_SUPPORT_MATRIX.md` defines:
+
+- the product meaning of Tier A / B / C
+- the current release commitment for PostgreSQL, MySQL, and SQLite
+- which capabilities must stay uniform across databases
+- which capabilities are allowed to differ by database
+- which future databases may be evaluated after the current release validates
+
 ## CLI To Product Evolution
 
 GUI is not in the current scope, but the CLI should evolve in a way that supports a later product surface.
@@ -175,6 +197,8 @@ Future desktop or web surfaces should map directly to the same concepts:
 - results table
 - export action
 
+The repository already includes `gui/desktop-foundation.md` and `gui/prototype/` as a future-facing design reference. Those artifacts should guide information architecture and workflow mapping only; they do not expand the current release surface beyond CLI.
+
 ### Evolution Rule
 
 The future GUI should reuse the same underlying product workflow, not invent a separate one. The CLI is the first validation surface for product behavior.
@@ -197,6 +221,7 @@ The following decisions are fixed for V1:
 - supported databases: PostgreSQL, MySQL, SQLite
 - surface: local CLI
 - critical path: connect, inspect, query, export
+- support policy: all three current databases must meet Tier A for the core workflow, but advanced admin capabilities stay outside the project
 - GUI: out of scope
 - acceptance must cover both success and obvious failure paths
 
@@ -213,6 +238,7 @@ The following decisions remain implementation-owned by the CTO:
 `dbtool-cli-v1` is ready for a first release when:
 
 - the primary workflow works across PostgreSQL, MySQL, and SQLite
+- the Tier A expectations in `DATABASE_SUPPORT_MATRIX.md` are met without scope creep into Tier C areas
 - the documented non-goals have not crept into scope
 - QA can execute acceptance checks directly from this document and companion test material
 - CTO can map the remaining work into engineering tasks without reopening basic product questions