fix(deps): patch release-blocking frontend advisories
CI and Deploy / test (push) Failing after 3m11s
CI and Deploy / deploy (push) Has been skipped

This commit is contained in:
cesnimda
2026-09-10 00:18:10 +02:00
parent 2024c374ac
commit a861ca4275
7 changed files with 308 additions and 181 deletions
@@ -32,7 +32,7 @@ The numbered order is the default integration order. Independent work may start
| Order / ticket | Size and ownership | Concrete scope and acceptance | Dependencies / rollback risk |
|---|---|---|---|
| **R01a Standalone type gate** | S. `interview-prep.test.tsx`, UI package script, CI workflow. | Narrowly type/narrow the mocked request payload, add explicit standalone type checking to CI. Prove 13 interview tests, standalone tsc, and the changed workflow command. Keep strictness and test coverage. | Can run in parallel with Batch 0. No production-code behavior or schema. Do not weaken the gate to preserve a green build. |
| **R01a Standalone type gate — partially resolved during authorized release repair, 2026-09-10** | S. `interview-prep.test.tsx`, UI package script, CI workflow. | The patched Next build exposed the historical TS2571. A test-only object matcher now preserves the positive/negative content assertions without dereferencing an unknown Axios payload; 13 interview tests, standalone tsc and Next build pass. An explicit standalone CI command remains outstanding; keep strictness and test coverage. See [release evidence](b06-completion.md#release-dependency-gate--2026-09-10-local--2026-09-09-utc). | Can run in parallel with Batch 0. No production-code behavior or schema. Do not weaken the gate to preserve a green build. |
| **R01b Production DB configuration validation** | S. Provider-selection code in `Program.cs` and startup tests. | Fail startup for an unknown production provider or missing required configured connection. Preserve deliberate dev SQLite defaults and valid explicit SQLite/MariaDB. Assert no fallback database is created on rejected startup. | Integrate after Batch 0 `Program.cs` mutations. No schema; rejecting an existing invalid environment can prevent boot, so validate deployed inputs first. |
| **R02 Consistent recovery-set creation** | M. `deploy.sh`, existing backup runner/scripts, isolated fixture and operator documentation. | Replace live SQLite tar as the DB consistency mechanism; coordinate file inventory/checkpoint or a short write pause, manifest/checksums and incomplete-set marking. Preserve keys/tombstone recovery. For MariaDB, coordinate the file set with the consistent SQL dump. | No new app schema. Can develop synthetic fixture in parallel with Batch 0. A backup that is only present is not yet verified. Keep previous verified sets. |
| **R03 Restore drill and schema-compatible rollback** | M. Deploy rollback logic, isolated restore harness and runbook; no production restore in the implementation session. | Restore latest/previous synthetic sets under active-source writes; integrity, FK owner boundaries, attachment hashes, provider-token decryptability and deletion replay must hold. Run previous/new binaries against the intended schema; allow automatic image rollback only when compatible. Record measured RPO/RTO, required key custody and operator steps. | Depends on R02 and Connor's recovery objectives. **Blocks every schema-changing ticket below.** Failed restore is a stop, not permission to reset the source DB. Do not run downgrade migrations automatically. |