The user released the full run once it was clear nothing there is productive
yet. All three report lines appeared (401 created / 9 memberships added / 0
groups adopted, renamed or deleted), and the amber default-marker line stayed
absent as it should when nothing was deleted.
The run doubles as the end-to-end proof for the 260811-f9i fix: the imported
group survived the sweep with its memberships filled, where the old filter
would have deleted it in exactly this run.
Roadmap marks Phase 16 complete; Phase 15 keeps its 7/8 with the reason named.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The user has no write access to the company AD, so tests 1, 3, 4 and 8 cannot
be run there, and building a throwaway domain controller for them was judged
disproportionate now that the one substantive defect at this spot is found and
fixed (UAT test 2 -> quick task 260811-f9i).
Recorded rather than hidden: A1 (objectGUID survives a rename) now rests on
Microsoft's documentation, not on our own measurement. The Tessera-side rename
and delete logic stays covered by unit tests against fixtures. If a rename ever
fails to propagate in production, 16-VERIFICATION.md names that as the starting
point.
Phase 16 marked complete in STATE.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Quick task 260811-f9i: plan and summary of the fix, STATE.md row, and the UAT
test 2 result. Test 2 was the read-only A2 check against the real directory --
it turned assumption A2 from "unverified" into "false as implemented" and
surfaced a defect that would have deleted every AD-bound group on the first
real sync.
Also records why the defect survived review: the spec mocks built their
expected filter with the same escape helper the production code used, so the
test asserted self-consistency rather than directory behaviour.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ran the Phase 16 browser walkthrough against alpha.tessera.ctl.de with the
real AD (balios.ctl.local) behind it.
- Test 5 (AD group import section): passed. 236 discovered entries, none of
them OUs; selection count, disabled-at-zero button, already-imported badge,
result block and the discovery error state all behave as specified.
- Test 6 (group dialog, three states): passed. Includes the WR-02 case — a
409 name collision stays visible in the dialog with the input preserved.
- Test 7: partial. Error path of the sync report and the grants-matrix column
search under both internal and AD name pass; the number rows of a successful
sync run are still open because a real sync was skipped by request (no
group/OU filter set, so it would import every person under DC=ctl,DC=local).
Tests 1-4 and 8 remain open — they need AD write access or are backstop
assertions. CN=Claude_VT stays imported on alpha because tests 3 and 4 need it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Marks all four Warning findings from 16-REVIEW.md as resolved with their
fix commit hashes; the two Info findings (IN-01/IN-02) remain open and
out of scope for this fix pass. Appends a note to 16-03-SUMMARY.md
recording the WR-02/WR-03/WR-04 behavior change in
syncBoundGroupsForTenant(), since that summary still described the
pre-fix behavior.
- 16-05-SUMMARY.md documents the two-task plan (sync-report wiring,
grants-matrix internal-name fallback).
- PERM-02 marked complete in REQUIREMENTS.md: all five Phase-16 success
criteria are code-complete across plans 16-01..16-03; this plan
delivered the last missing visibility layer (D-05/D-06) and the
third D-04 display site.
- WINDOWS.md #6: this plan's own manual browser walkthrough (sync
report three-line render, amber default-marker line, grants-matrix
two-name search) not executed — no browser tool in this session.
Documents the GroupFormModal three-state rebuild (D-03/D-04/D-07), the
groups-list internalName fallback, and the ldapBind i18n cleanup for
Phase 16 Plan 4.
schalli