last status 06-04-2026

Author: MPCoreDeveloper

.github/issue-drafts/admin-console-v1.6.0/00-epic-admin-console-and-tool-compatibility.md

@@ -2,14 +2,22 @@
 Deliver an administration and observability roadmap for `SharpCoreDB` that prioritizes compatibility with existing database tools and optionally adds a lightweight native admin experience.
 
 ## Status
-**State:** IN PROGRESS
+**State:** RESOLVED ✅
 
 Resolved workstreams in repository:
 - [x] `01-tool-compatibility-matrix-and-certification.md` — **RESOLVED**
 - [x] `02-pg-catalog-and-information-schema-expansion.md` — **RESOLVED**
+- [x] `03-binary-protocol-auth-and-session-hardening.md` — **RESOLVED**
+- [x] `04-sql-compatibility-and-ddl-introspection-polish.md` — **RESOLVED**
+- [x] `05-diagnostics-and-metrics-surface-upgrades.md` — **RESOLVED**
+- [x] `06-viewer-v2-foundation-desktop-tooling.md` — **RESOLVED**
+- [x] `07-viewer-diagnostics-and-admin-actions.md` — **RESOLVED**
+- [x] `08-optional-web-admin-razor-pages-mvp.md` — **RESOLVED**
+- [x] `09-odbc-jdbc-driver-strategy-feasibility.md` — **RESOLVED**
+- [x] `10-documentation-and-adoption-playbook.md` — **RESOLVED**
+- [x] `11-tool-compatibility-ci-smoke-tests.md` — **RESOLVED**
 
-Next planned work:
-- [ ] `03` and beyond — see remaining issue drafts.
+All workstreams complete. Epic 100% delivered for v1.6.0.
 
 This roadmap is based on current `v1.6.0` behavior:
 - `tools/SharpCoreDB.Viewer` exists but remains minimal.

.github/issue-drafts/admin-console-v1.6.0/03-binary-protocol-auth-and-session-hardening.md

@@ -2,7 +2,15 @@
 Harden binary protocol authentication/session behavior for external GUI and driver expectations.
 
 ## Status
-**State:** OPEN
+**State:** RESOLVED ✅
+**Completed:** 2025-04-06
+
+### Delivered
+- Fixed SSL negotiation loop (reject repeat `SSLRequest` after initial negotiation)
+- Added missing parameter status messages (`server_version`, `server_encoding`, `client_encoding`, `DateStyle`, `TimeZone`, `integer_datetimes`, `application_name`) in `AuthenticateAndCreateSessionAsync`
+- Added `severity` field to `WriteErrorResponseAsync` for PG-compliant error responses
+- Added database existence validation before authentication (returns `3D000 invalid_catalog_name`)
+- 4 integration tests covering handshake, SSL, auth failure, and unknown database scenarios — all passing
 
 ## Why
 Current binary protocol startup/auth flow is functional but needs stronger parity and production behavior.

.github/issue-drafts/admin-console-v1.6.0/04-sql-compatibility-and-ddl-introspection-polish.md

@@ -2,7 +2,20 @@
 Improve SQL compatibility and DDL/introspection behavior required by admin tools.
 
 ## Status
-**State:** OPEN
+**State:** RESOLVED ✅
+**Completed:** 2026-04-06
+
+### Delivered
+- Added explicit result-shape schemas for common empty `pg_catalog` introspection views:
+  - `pg_indexes`, `pg_index`, `pg_constraint`, `pg_proc`, `pg_trigger`, `pg_description`, `pg_stat_user_tables`, `pg_sequence`, `pg_attrdef`, `pg_depend`
+- Fixed catalog source detection ambiguity (longest-match selection) so `pg_indexes` no longer resolves to `pg_index`
+- Normalized binary protocol command tags for common statement classes:
+  - row-returning: `SELECT n`
+  - DML: `INSERT 0 n`, `UPDATE n`, `DELETE n`
+  - DDL/transaction/session commands: `CREATE TABLE`, `CREATE INDEX`, `DROP TABLE`, `DROP INDEX`, `ALTER TABLE`, `BEGIN`, `COMMIT`, `ROLLBACK`, `SET`
+- Added regression coverage:
+  - `PgCatalogServiceTests` for `pg_indexes`, `pg_constraint`, and `pg_proc` shape validation
+  - `BinaryProtocolHandshakeTests` for DDL and `SELECT` command-tag validation
 
 ## Why
 Many tools execute introspection SQL and DDL probes beyond regular CRUD workloads.

.github/issue-drafts/admin-console-v1.6.0/05-diagnostics-and-metrics-surface-upgrades.md

@@ -2,7 +2,28 @@
 Upgrade diagnostics surfaces for admin and monitoring workflows.
 
 ## Status
-**State:** OPEN
+**State:** RESOLVED ✅
+**Completed:** 2026-04-06
+
+### Delivered
+- Expanded server metrics collector to include actionable in-memory telemetry snapshots:
+  - request volume (`totalRequests`, query/non-query split)
+  - reliability (`failedRequests`, `errorRatePercent`, `lastFailureCode`)
+  - performance (`averageLatencyMs`, row and network byte totals)
+  - protocol counters (`grpc`, `rest`, `binary` connection/request/message/error stats)
+- Added protocol-level instrumentation:
+  - binary protocol connection/message/error tracking in `BinaryProtocolHandler`
+  - gRPC `Connect`, `Disconnect`, and `ExecuteNonQuery` request/latency/error metrics
+- Upgraded health payloads for faster triage:
+  - `HealthCheckService` now emits check statuses, error rate summary, recent failure signal, and per-protocol diagnostics
+  - `/api/v1/health` now includes triage check map and reliability fields
+- Upgraded `/api/v1/metrics` payload with actionable telemetry fields and protocol metrics map
+- Added observability contract tests:
+  - `ObservabilityContractTests.GetSnapshot_AfterTraffic_ShouldExposeActionableCounters`
+  - `ObservabilityContractTests.GetDetailedHealth_WhenErrorsPresent_ShouldSurfaceTriageSignals`
+- Added operator documentation:
+  - `docs/server/OBSERVABILITY_SETUP_v1.6.0.md` with Prometheus JSON-scrape baseline and dashboard panel queries
+  - Updated `docs/server/REST_API.md` and `docs/server/QUICKSTART.md` examples for upgraded diagnostics contracts
 
 ## Why
 Developers and operators need reliable health and metrics insight without deep internals access.

.github/issue-drafts/admin-console-v1.6.0/06-viewer-v2-foundation-desktop-tooling.md

@@ -2,27 +2,38 @@
 Evolve `tools/SharpCoreDB.Viewer` into a stronger development companion (`Viewer v2` foundation).
 
 ## Status
-**State:** OPEN
+**State:** ✅ RESOLVED — implemented in v1.6.0
 
 ## Why
 A lightweight first-party desktop utility helps validate features and supports local workflows.
 
 ## Scope
-- Improve database/table browser UX.
-- Add richer query editor and result grid capabilities.
-- Add metadata panes (indexes/constraints/triggers where available).
-- Add connection profile management improvements.
+- ✅ Improve database/table browser UX — table filter, selected-table state, Refresh button.
+- ✅ Add richer query editor and result grid capabilities — multi-statement, F5/Ctrl+Enter shortcuts.
+- ✅ Add metadata panes (indexes/constraints/triggers) — columns, indexes, triggers via PRAGMA.
+- ✅ Add connection profile management improvements — recent connections saved, Use/Remove actions.
 
 ## Implementation Plan
-1. Define MVP capabilities aligned to current server features.
-2. Refactor view-model/service layers for extensibility.
-3. Implement query/result and metadata exploration upgrades.
-4. Add user docs and basic smoke tests.
+1. ✅ Define MVP capabilities aligned to current server features.
+2. ✅ Refactor view-model/service layers for extensibility.
+3. ✅ Implement query/result and metadata exploration upgrades.
+4. ✅ Add user docs and basic smoke tests.
 
 ## Acceptance Criteria
-- Viewer supports practical daily development tasks.
-- Metadata and query UX clearly improved over baseline.
-- Documentation includes usage and limitations.
+- ✅ Viewer supports practical daily development tasks.
+- ✅ Metadata and query UX clearly improved over baseline.
+- ✅ Documentation includes usage and limitations — see `docs/viewer/viewer-v2-usage.md`.
 
 ## Dependencies
 - Benefits from metadata/protocol improvements.
+
+## Resolved in
+- `tools/SharpCoreDB.Viewer/ViewModels/MainWindowViewModel.cs` — table filter, metadata panes, preview, keyboard shortcuts
+- `tools/SharpCoreDB.Viewer/ViewModels/ConnectionDialogViewModel.cs` — recent connection profiles
+- `tools/SharpCoreDB.Viewer/Models/AppSettings.cs` — `ConnectionProfile` model
+- `tools/SharpCoreDB.Viewer/Services/SettingsService.cs` — profile persistence helpers
+- `tools/SharpCoreDB.Viewer/Views/MainWindow.axaml` — explorer UX with filter + metadata panes
+- `tools/SharpCoreDB.Viewer/Views/ConnectionDialog.axaml` — recent connections UI
+- `tools/SharpCoreDB.Viewer/Views/MainWindow.axaml.cs` — F5/Ctrl+Enter keyboard handler
+- `tools/SharpCoreDB.Viewer/Resources/Strings.*.json` — all locales updated
+- `docs/viewer/viewer-v2-usage.md` — user documentation

.github/issue-drafts/admin-console-v1.6.0/07-viewer-diagnostics-and-admin-actions.md

@@ -2,7 +2,7 @@
 Add diagnostics and lightweight admin actions to `SharpCoreDB.Viewer`.
 
 ## Status
-**State:** OPEN
+**State:** RESOLVED
 
 ## Why
 Users requested direct access to runtime metrics and common operational actions.
@@ -25,3 +25,21 @@ Users requested direct access to runtime metrics and common operational actions.
 
 ## Dependencies
 - Depends on diagnostics endpoint upgrades.
+
+## Resolution
+Implemented in v1.6.0. Affected files:
+- `tools/SharpCoreDB.Viewer/Models/DiagnosticsSnapshot.cs` — immutable snapshot record
+- `tools/SharpCoreDB.Viewer/ViewModels/DiagnosticsViewModel.cs` — PRAGMA-based data collection, admin commands
+- `tools/SharpCoreDB.Viewer/Views/DiagnosticsDialog.axaml` — modal diagnostics dialog
+- `tools/SharpCoreDB.Viewer/Views/DiagnosticsDialog.axaml.cs` — code-behind; auto-runs on open
+- `tools/SharpCoreDB.Viewer/Views/MainWindow.axaml` — Diagnostics menu item (enabled when connected)
+- `tools/SharpCoreDB.Viewer/Views/MainWindow.axaml.cs` — `OnDiagnosticsClicked` handler
+- `tools/SharpCoreDB.Viewer/Resources/Strings.*.json` — 20 new keys across 6 locales
+
+Features delivered:
+- Storage stats: page count, page size, total size, cache size, journal mode
+- Health status: PRAGMA integrity_check result with captured-at timestamp
+- Table row counts: COUNT(*) per table, sorted alphabetically
+- Admin actions: PRAGMA optimize, PRAGMA wal_checkpoint(FULL)
+- Export: full snapshot serialized to JSON via file picker
+- All operations guarded with IsRunning flag; error/success feedback per action

.github/issue-drafts/admin-console-v1.6.0/08-optional-web-admin-razor-pages-mvp.md

@@ -2,7 +2,7 @@
 Investigate and deliver an optional lightweight web admin MVP using ASP.NET Core Razor Pages.
 
 ## Status
-**State:** OPEN
+**State:** RESOLVED
 
 ## Why
 A browser-based console lowers operational friction without committing to a heavy full console rewrite.
@@ -22,10 +22,30 @@ A browser-based console lowers operational friction without committing to a heav
 3. Add core pages for health/metrics/query/browse.
 4. Add docs and threat considerations.
 
+## Implementation Notes
+- Feature-gated via `ServerConfiguration.EnableWebAdmin` (default: `false`).
+- Cookie-based authentication scheme `"WebAdmin"` — separate from the JWT Bearer scheme used by API/gRPC.
+- Admin role required (`DatabaseRole.Admin`); sign-in validates existing `UserConfiguration` password hash (SHA-256).
+- Razor Pages root: `src/SharpCoreDB.Server/WebAdmin/Pages/` (configured via `WithRazorPagesRoot`).
+- Pages delivered:
+  - `GET /admin` — Dashboard with health stats, uptime, and per-check status.
+  - `GET /admin/databases` — Configured databases with runtime online/offline status, encryption, storage mode.
+  - `GET|POST /admin/query` — Guarded ad-hoc SQL with 500-row cap and full query logging.
+  - `GET /admin/metrics` — MetricsCollector snapshot (active connections, latency, error rate, protocol breakdown).
+  - `GET /admin/login` — Sign-in form (anonymous, admin role enforced after authentication).
+  - `POST /admin/logout` — Cookie sign-out.
+- Security defaults:
+  - `CookieSecurePolicy.Always` (HTTPS only).
+  - `SameSiteMode.Strict`, `HttpOnly = true`.
+  - Anti-forgery tokens on all POST handlers.
+  - All query executions logged at Warning level via `ILogger`.
+  - Route authorization configured declaratively via `AuthorizeFolder("/Admin")` + `AllowAnonymousToPage("/Admin/Login")`.
+- Does not affect existing JWT/gRPC/REST endpoints.
+
 ## Acceptance Criteria
-- MVP pages support core admin workflows.
-- Security defaults are strict and documented.
-- Feature is optional and does not break server core.
+- MVP pages support core admin workflows. ✅
+- Security defaults are strict and documented. ✅
+- Feature is optional and does not break server core. ✅
 
 ## Dependencies
 - Depends on diagnostics and compatibility maturity.

.github/issue-drafts/admin-console-v1.6.0/09-odbc-jdbc-driver-strategy-feasibility.md

@@ -2,7 +2,22 @@
 Produce a concrete strategy for ODBC/JDBC enablement and external ecosystem integration.
 
 ## Status
-**State:** OPEN
+**State:** RESOLVED
+
+## Implementation Notes
+
+Completed for v1.6.0. Deliverable: `docs/server/ODBC_JDBC_STRATEGY.md`.
+
+**Decision:** Adapter-first strategy — direct users to existing PostgreSQL ODBC/JDBC drivers (psqlODBC, pgjdbc) against the SharpCoreDB binary protocol endpoint (port 5433, TLS). No bespoke driver development required for v1.6.0.
+
+**Key findings:**
+- Binary protocol endpoint is live and PostgreSQL wire-compatible (Protocol v3, TLS 1.2+).
+- Option A (adapter) satisfies >90% of reported enterprise use cases with zero development cost.
+- Option B (native ODBC) and Option C (native JDBC) deferred to v2.x pending confirmed enterprise demand.
+- Option D (JDBC proxy bridge) rejected — marginal benefit over Option A.
+- Phased roadmap defined: Phase 1 (adapter, now) → Phase 2 (catalog gap closure, v1.7.0) → Phase 3/4 (native drivers, v2.x).
+- ODBC quick-start and JDBC quick-start examples published in the strategy document.
+- Dependencies to binary protocol, pg_catalog, and security confirmed as satisfied by issues 01–03.
 
 ## Why
 Some teams require standard connectivity layers for governance and tool compatibility.
@@ -20,9 +35,9 @@ Some teams require standard connectivity layers for governance and tool compatib
 4. Publish recommendation and decision record.
 
 ## Acceptance Criteria
-- Decision record with selected path and rationale.
-- Clear dependency map to protocol/catalog work.
-- Estimated implementation effort for next phases.
+- Decision record with selected path and rationale. ✅
+- Clear dependency map to protocol/catalog work. ✅
+- Estimated implementation effort for next phases. ✅
 
 ## Dependencies
 - Informed by compatibility matrix and protocol maturity.

.github/issue-drafts/admin-console-v1.6.0/10-documentation-and-adoption-playbook.md

@@ -2,7 +2,22 @@
 Publish a practical adoption playbook for admin and tooling workflows.
 
 ## Status
-**State:** OPEN
+**State:** RESOLVED
+
+## Implementation Notes
+
+Completed for v1.6.0. Deliverable: `docs/server/ADMIN_TOOLING_GUIDE.md`.
+
+**Delivered content:**
+- Three-endpoint overview (binary protocol / gRPC / HTTPS REST) with default ports.
+- Tool compatibility matrix: 8 GUI tools, 5 CLI tools, 6 BI/analytics tools, 10 programmatic drivers — with per-tool status (connect, browse, query, export, import) and notes.
+- Six setup flows: DBeaver, psql CLI, Npgsql (.NET), Python (psycopg2), Power BI Desktop (ODBC), Web Admin UI.
+- Known limitations table with 8 entries and mitigation steps.
+- Diagnostics & monitoring quickstart: health check endpoint, metrics endpoint, Prometheus integration example, SharpCoreDB Viewer diagnostics walkthrough.
+- Migration guidance for: embedded → server mode, custom HTTP/gRPC → standard API, file database → server hosted.
+- Connection string reference for all supported drivers/protocols.
+- Version support matrix (v1.4–v1.6).
+- `docs/INDEX.md` updated to link both new docs.
 
 ## Why
 Users need clear guidance on what works now, what is in progress, and recommended paths.
@@ -22,9 +37,9 @@ Users need clear guidance on what works now, what is in progress, and recommende
 4. Link from root and package readmes.
 
 ## Acceptance Criteria
-- Docs enable fast, low-friction onboarding.
-- Limitations and support levels are transparent.
-- Docs remain version-aligned to `v1.6.0` policy.
+- Docs enable fast, low-friction onboarding. ✅
+- Limitations and support levels are transparent. ✅
+- Docs remain version-aligned to `v1.6.0` policy. ✅
 
 ## Dependencies
 - Finalization workstream tied to all roadmap outputs.

.github/issue-drafts/admin-console-v1.6.0/11-tool-compatibility-ci-smoke-tests.md

@@ -2,7 +2,27 @@
 Add CI smoke tests for core external-tool compatibility scenarios.
 
 ## Status
-**State:** OPEN
+**State:** RESOLVED
+
+## Implementation Notes
+
+Completed for v1.6.0. Deliverables: `tests/CompatibilitySmoke/` and `.github/workflows/compatibility-smoke.yml`.
+
+**Delivered:**
+
+`tests/CompatibilitySmoke/` directory:
+- `appsettings.smoke.json` — minimal server config for CI: temp DB paths, no encryption, test credentials, dev cert reference, all three protocol endpoints enabled.
+- `smoke_tests.py` — Python smoke test runner with 7 tests across two layers:
+  - **HTTP REST**: health check, JWT authentication, simple query (SELECT 1), metadata discovery (information_schema).
+  - **Binary protocol**: TCP connect, SSLRequest negotiation (SSLRequest → 'S'), PostgreSQL startup message handshake.
+  - Outputs coloured terminal report and structured `smoke-results.json`.
+  - Exit code 0 = all passed; 1 = failures; 2 = server not ready.
+- `run-smoke.ps1` — PowerShell automation script: builds server, generates dev cert via `dotnet dev-certs`, patches config with absolute paths, starts server in background, polls health, runs Python tests, tears down, cleans up.
+- `README.md` — local reproduction documentation: prerequisites, two run options, expected output, config table, troubleshooting section.
+
+`.github/workflows/compatibility-smoke.yml`:
+- Triggers on push/PR to master/develop and `workflow_dispatch`.
+- Ubuntu job: setup .NET + Python, install requests, build server, generate dev cert, patch config via Python script, start server in background, poll health endpoint, run smoke tests, print results summary, stop server, upload artifacts (14-day retention).
 
 ## Why
 Compatibility can regress silently without automated checks.
@@ -19,9 +39,9 @@ Compatibility can regress silently without automated checks.
 4. Document how to run locally.
 
 ## Acceptance Criteria
-- CI runs compatibility smoke checks on target branches.
-- Regressions surface with actionable logs.
-- Local reproduction workflow documented.
+- CI runs compatibility smoke checks on target branches. ✅
+- Regressions surface with actionable logs. ✅
+- Local reproduction workflow documented. ✅
 
 ## Dependencies
 - Depends on protocol and metadata baseline.