Engineering quality baseline

An independent review of whether Fabric Desktop by KratosBI is built like one coherent product: no duplicated services, no functionality that only looks real, no errors that disappear, no tests that prove only their own fakes. Reviewed at main 3bee0db (2026-10-18, "Merge pull request #136"); line numbers refer to that commit.

This review builds on two earlier ones and doesn't repeat them:

• The enterprise hardening audit (docs/hardening/, findings DI-, EP-, EN-, SH-, AR-, TS-, backlog HD-001 to HD-057) covers security, OneLake write integrity, distribution and reliability.
• The UX and simplicity audit (docs/ux/, backlog UX-001 to UX-020) covers workflows, navigation, configuration and documentation coverage.

Where a finding here overlaps theirs, it cites their ID and adds only what is new.

How the review was done#

• The engine (157 Python modules, 41,000 lines), the 29 UI scripts (14,400 lines) and the shell were read at the commit above. Four areas were searched exhaustively: duplication and competing patterns, fake or incomplete functionality and hidden failures, dead code and UI consistency, and test quality and layering.
• Counts come from git grep, the Python syntax tree and coverage data, not from estimates. Dead-code candidates came from vulture and were each checked against the UI, tests, docs, the RPC allowlist and the shell.
• Defects marked Reproduced were shown with a script against the real engine code (fakes only at the network edge). Scripts are in each finding.
• Every test suite that can run on Linux was run. Nothing was run against a Fabric tenant, so no finding claims live Fabric behavior.

Test evidence#

What is not verified at all: any Fabric REST call or OneLake write against a real service; 22 of the 41 FabricClient methods, which never execute even against a fake (QA-018); the Windows-only sign-in broker; the shipped engine build.

Scorecard#

Scores are 0 to 10, weighted as the quality brief sets out.

Release decision#

FAIL for main at 3bee0db, on two counts that no score can override:

1. Known data-loss defect (QA-001): df.write.mode("overwrite").option("replaceWhere", ...).saveAsTable(...), a common Fabric pattern, replaces the entire OneLake table instead of one slice, and prints a successful write.
2. Success reported after failure (QA-002): a failed notebook save shows "Saved", and closing or switching notebooks then drops the unsaved cells.

Both are small to fix (PR-QA-01, PR-QA-02). With them fixed and the hardening audit's P0 items merged, the score would still sit below 8.0 until the High findings QA-003 to QA-007 are closed, so the next release would be a CONDITIONAL PASS at best.

Top 20 engineering quality concerns#

Ten more findings (QA-021 to QA-030) are in the register.

Critical release blockers#

Architectural consolidation opportunities#

Each is a small shared helper replacing copies, not a rewrite. Details in architecture.md.

1. One fsutil with atomic JSON write and a corrupt-file-aside read (replaces ~25 write sites, QA-011).
2. One transient-error rule in retrying.py, imported by the other four (QA-006).
3. One sqlite_util.connect() and tx() (QA-022).
4. One audit chain writer used by both audit logs (QA-012).
5. One redactor that includes the Git secret patterns (QA-016).
6. One public Credential.token(scopes) and a client factory on Service, instead of 23 constructions and _token (QA-014).
7. Method metadata declared once, next to the method, generating METHODS and READ_ONLY (QA-015).
8. One BackgroundRuns helper for Prove and side by side (QA-023).
9. UI: confirmDialog({danger}), tabs(), statusPill(), resultGrid(), poll() in shared code (QA-019).

UX consistency concerns#

The UX audit owns workflows and navigation. At component level this review found: destructive confirmations styled as the primary action; 13 confirm helpers with two body-text classes; the Domains table built twice with different buttons and empty states; 11 tab bars and 13 segmented controls with ARIA on one tab bar and six buttons; three menu implementations, the shared one with no keyboard support; five result grids that show NULL three different ways; seven date and duration formatters ("1m 5s" and "1 min 5 s"); 208 hard-coded colors beside 16 tokens and two amber "warning" pills. All are in QA-019 and PR-QA-11 to PR-QA-13.

Technical debt assessment#

Low where AI-built code is usually worst. No placeholder screens, no simulated progress, no mock responses in shipped code, no "coming soon" stubs, no unused functions in the UI, and every RPC name the UI calls exists. Fakes are confined to tests. That deserves saying plainly.

High where features were built in parallel. The debt is repetition of infrastructure, and it is growing with each feature thread: every new area adds its own JSON store, its own _now(), its own background-run loop, its own confirm dialog, and three more lines in three shared lists. The copies have already drifted in ways that matter (an atomic write in Prove that side by side lacks, synchronous=full in one SQLite store and not its twin, a retry rule that reads the wrong attribute). The biggest single risk pattern is the silent fallback: 98 handlers turn any failure into "nothing configured", which is how QA-003 to QA-007 happen.

Trend. Between the hardening audit (1248ccd) and this one, Service grew from 335 to 347 public methods and type: ignore from 348 to 385. Nine open PRs add new services or mixins. Without PR-QA-05 to PR-QA-09 the pattern costs keep rising per feature.

What happens next#

• Findings go to their owners through the coordinator; this thread doesn't change code in another thread's area.
• Backlog IDs QA-001 to QA-030 go to the product management thread.
• Every PR gets a PASS / CONDITIONAL PASS / FAIL decision in the PR quality gate format, sent to Release management.
• The baseline is re-scored after each merge round, with a row added below.