docs: qualify RD21 remediation and retain provider gates

This commit is contained in:
cesnimda
2026-10-23 18:36:58 +02:00
parent 1b89a779d0
commit 0d16a691e0
31 changed files with 38501 additions and 5 deletions
@@ -1,6 +1,7 @@
# RD21 investigation (23 October 2026)
Status: repair and qualification in progress; this is not acceptance.
Status: SQLite repair implemented and locally qualified. Formal supported-provider closure remains
UNRESOLVED; see the [dated acceptance addendum](ACCEPTANCE_ADDENDUM_2026-10-23.md).
## Original failure
@@ -50,16 +51,37 @@ Career has an existing synchronous mutation guard and disables its editor while
paths retain drafts, but it cannot detect another session's change without server revision data.
The shared job dialog does not guard older GET responses, and remains editable/closable during
PUT; a successful submitted snapshot can close a dialog containing later unsent edits. The
frontend correction will preserve the revision belonging to each draft, block conflicting
in-flight actions, reject old responses, and display recoverable conflicts without blind retry.
frontend correction preserves the revision belonging to each draft, blocks conflicting
in-flight actions, rejects old responses, and displays recoverable conflicts without blind retry.
## Provider limitation
The read-only `rtk proxy docker info --format '{{json .ServerVersion}}'` probe on 23 October
failed: `dockerDesktopLinuxEngine` named pipe does not exist. No daemon installation/restart was
attempted. MariaDB runtime qualification is outstanding; SQLite and provider script generation
failed: `dockerDesktopLinuxEngine` named pipe does not exist. Additional `default` and
`desktop-windows` context info probes also failed with their named pipes absent. Command lookup
found no mariadbd/mysqld/mariadb/mysql executable, and neither Program Files installation root
contained a MariaDB/MySQL directory. No daemon installation/restart was attempted. MariaDB runtime
qualification is outstanding; SQLite and provider script generation
cannot substitute for a MariaDB persistence/concurrency run.
## Integration review findings during repair
The first repair passed its backend and component suites, but whole-branch connected review found
two integration gaps before final qualification. Neither is hidden by those passing totals:
- The application-drafts client consumes `X-Job-Version` after 204, while the existing cross-origin
CORS policy does not expose that response header. APIRequest tests can read it, but browser Axios
cannot. The database can therefore commit while the browser reports a missing committed revision.
Actual cross-origin browser proof is required in addition to raw HTTP assertions.
- Cover-letter saves advance the shared job version. Answers initially consumes a cached overview
snapshot; switching from a successful letter save to Answers can therefore submit an older source
revision and receive an avoidable 409. A new Answers editor needs a coherent fresh source before
editing. Updating only its revision would incorrectly authorize stale body fields; dirty drafts
must retain their original source through later parent refreshes.
The broad browser run was stopped after 22 passing cases while these findings were addressed. It
is an interrupted attempt, not a full-suite pass. Final results must qualify the corrected source.
## Historical recovery
No evidence establishes recovery of edits already overwritten before this repair. Canonical