docs(project): refresh baseline verification artifacts
Check in the PM product requirements, refreshed QA acceptance evidence, shared execution split plans, and current-phase status notes so the repo matches the current delivery baseline. Co-Authored-By: Paperclip <noreply@paperclip.ing>
This commit is contained in:
@@ -45,6 +45,7 @@ Use a four-zone workspace:
|
||||
|
||||
- Connection library
|
||||
- New connection form entry point
|
||||
- Active connection session summary with clear ready/testing/demo/retry states
|
||||
- Active DB switcher
|
||||
- Safety posture and backend boundary summary
|
||||
- Local smoke fixture assist for repeatable QA runs
|
||||
@@ -85,12 +86,14 @@ Use a four-zone workspace:
|
||||
- `apps/desktop` now runs on React and Tailwind-based styling.
|
||||
- The shell now consumes the existing Tauri bridge for `backend_bootstrap`, `test_redis_connection`, `browse_redis_keys`, `read_redis_value`, `write_redis_value`, and `execute_redis_command`.
|
||||
- The inspector now consumes `update_redis_key_ttl` for live TTL set and persist actions in desktop runtime.
|
||||
- The repository now also contains a visible string-only `Add key` dialog wired to `create_redis_value`, but that capability remains a separately tracked next-phase surface rather than part of this baseline milestone's required acceptance.
|
||||
- The repository now also contains a visible string-only `Add key` dialog wired to `create_redis_value`; that entry is explicitly labeled `Preview`, and the capability remains a separately tracked next-phase surface rather than part of this baseline milestone's required acceptance.
|
||||
- shadcn-style UI primitives are used locally for buttons, inputs, textareas, badges, and dialogs.
|
||||
- Browser-only dev mode uses explicit demo fallback so the visible shell can still be reviewed without a Tauri runtime.
|
||||
- Tauri desktop mode now allows live connection tests, live key browsing, live value inspection, string save for supported keys, live TTL updates, and live command execution while keeping browser dev mode on explicit demo fallback.
|
||||
- Non-string live values now render in structured read-only panels for `hash`, `list`, `set`, `zset`, and `stream`, so operators can scan typed payloads without reading raw JSON dumps.
|
||||
- The visible shell now validates draft-connection name, host, port, and DB input before creation, and prevents duplicate profile names inside the local shell state.
|
||||
- The active connection area now also exposes a dedicated session summary so operators can see whether the current scope is ready, testing, demo-only, or waiting for retry without inferring that state from scattered card copy.
|
||||
- Live connection test completion now only reapplies the returned DB scope when the same connection is still active, preventing a stale test response from silently replacing the operator's newer active workspace selection.
|
||||
- The DB switcher now exposes a predictable default operator range from `db0` through `db15` and keeps an out-of-range active DB visible instead of depending on a four-item hardcoded list.
|
||||
- Zero-result key searches now place the inspector into an explicit empty state instead of leaving a stale key visible.
|
||||
- Frontend error handling now routes stable backend error codes through a shared operator-facing notice layer so live failures render with consistent copy and banner tone across connection, browse, inspect, write, TTL, and command flows.
|
||||
@@ -106,6 +109,7 @@ Use a four-zone workspace:
|
||||
- The utility rail exposes a copyable QA snapshot with runtime, connection, selection, and latest command context.
|
||||
- The utility rail exposes the seeded local smoke fixture path and safe smoke shortcuts without requiring manual re-entry from the runbook.
|
||||
- The active connection and active DB stay visible without opening a modal.
|
||||
- The active connection area shows a dedicated session summary with explicit ready, testing, demo fallback, or retry-needed wording plus a visible next-step hint.
|
||||
- The DB switcher exposes `db0` through `db15` by default and still keeps the current DB visible when the active scope falls outside that range.
|
||||
- Search filters the browser list and shows a no-results state.
|
||||
- Search now exposes explicit mode feedback so operators can see whether the current input is being treated as a contains search or a raw Redis pattern.
|
||||
@@ -113,6 +117,7 @@ Use a four-zone workspace:
|
||||
- When search returns zero keys, the inspector switches to an empty state instead of showing the last selected key.
|
||||
- Empty browser and inspector states now distinguish between an empty DB and a filtered no-match result instead of using one generic no-results sentence.
|
||||
- The connection action distinguishes desktop live testing from browser demo fallback.
|
||||
- If a live connection test finishes after the operator switches to a different connection, the tested connection card updates but the newly active DB scope remains unchanged.
|
||||
- Invalid draft connections cannot be created from the visible shell.
|
||||
- Live backend failures are shown through a consistent banner treatment instead of per-surface ad hoc copy.
|
||||
- Non-string keys are explicitly read-only.
|
||||
@@ -123,6 +128,7 @@ Use a four-zone workspace:
|
||||
- String save and TTL mutations now require a second review step that repeats scoped current-vs-next state before continuing.
|
||||
- Failed save and TTL attempts keep the current draft value or TTL input in place so operators can adjust and retry without rebuilding context.
|
||||
- Browser demo mode keeps mock string-save and TTL changes visible for the current session while still labeling the runtime as non-live.
|
||||
- The visible `Add key` entry and dialog keep a `Preview` label so operators do not mistake that next-phase flow for approved current-baseline scope.
|
||||
- Current baseline sign-off does not require the visible `Add key` surface to pass or fail; keep any Add Key evidence separate unless PM explicitly promotes it into the active milestone.
|
||||
- Delete requires a second confirmation step that includes key name and DB context.
|
||||
- The command tray visibly blocks dangerous administrative commands.
|
||||
|
||||
Reference in New Issue
Block a user