fix: report nested workspace conflicts

This commit is contained in:
2026-08-04 07:05:51 +02:00
parent 234b40e7cf
commit 8effdc6c89
6 changed files with 225 additions and 2 deletions
+37 -1
View File
@@ -39,6 +39,20 @@
without a second publish, active-commit rendering, and every canonical diagnostics conflict
path; these initially failed against the pull/reload-only UI and narrow path parser.
## Review round 2
- Fixed recursive registry diffs so add/remove changes to optional nested diagnostics branches
report their actual canonical paths instead of the fallback `workspace.id`. The regression cases
cover both add and remove for `diagnostics.dwh_rest` and
`diagnostics.vector_rest.reversible_probe`.
- Extended the conflict-path allowlist to accept the optional `diagnostics` root and every
optional diagnostics branch. The existing structural rebase now saves an explicitly selected
branch (including an added or removed branch) in the revised browser draft, still pinned to the
registry's actual revision and requiring normal validation and confirmation before publishing.
- Wrote the backend/frontend cases first and observed the expected RED failures: backend conflict
fields were `workspace.id`, while the frontend rejected the safe conflict payload before the
resolution UI could render.
## Verification
Run in `frontend/` after the final changes:
@@ -53,5 +67,27 @@ npx tsc -b
```text
npx vitest run
# 51 files passed, 392 tests passed
# 51 files passed, 398 tests passed
```
Round-2 focused verification:
```text
backend: npx vitest run test/workspace-registry.test.ts
# 1 file passed, 23 tests passed
backend: npx tsc --noEmit -p .
# exit 0
frontend: npx vitest run
# 51 files passed, 398 tests passed
frontend: npx tsc -b
# exit 0
```
The full backend `npx vitest run` was also attempted after allowing its local SSE test socket.
The Task 10 registry tests passed, but seven unchanged SSE/session tests fail because their
default, unbootstrapped registry makes session authorization return the intentional
`session storage is unavailable` response. This failure is outside the Task 10 diff; it persists
without any changed Task 10 route or test-harness code.