---
id: KEY-WP-0018
type: workplan
title: "Make the LLDAP export report its own completeness"
domain: infotech
repo: key-cape
status: finished
owner: claude
topic_slug: export-completeness-evidence
created: "2026-09-07"
updated: "2026-09-07"
state_hub_workstream_id: "82ff99a1-65cc-5e1f-93fc-5bc8911ce77a"
---

Closes gap G05 of `history/2026-09-05-011726-scope-intent-assessment.md`.

`src/internal/migration/lldapexport/exporter.go` discovers groups by walking each
user's memberships, so a group nobody belongs to is absent from the snapshot and
nothing says so. A `LookupGroups` failure is skipped by a `continue` under a
comment claiming it is recorded in the incompatibility report — it is not. The
run then emits `result: "success"` and the CLI reports a clean export. Group
order comes from map iteration, so two exports of an unchanged directory differ.

A second defect falls out of reading the adapter: `LDAPAdapter.LookupGroups`
never populates `Group.Members`, and the exporter builds every membership from
that field. Against a real LLDAP directory the `memberships` block is therefore
always empty, while the fixture-based tests pass because the mock fills it in.

The unit of work is the evidence, not the enumeration: an export that cannot
prove it saw the whole directory must say which one it is.

## Enumerate groups independently of membership

```task
id: KEY-WP-0018-T01
status: done
priority: medium
state_hub_task_id: "abb11f82-06e9-58ee-8be2-6d20491e9524"
```

Add an optional `domain.GroupLister` capability (`ListGroups`) and implement it
on `LDAPAdapter` with a direct group-subtree search that reads `member` and
`uniqueMember`, so `Group.Members` is populated from the directory rather than
left empty. Keep it optional rather than widening `UserRepository`: the OIDC
layer has no use for it, and every existing implementation and test double would
otherwise have to grow a method it never calls.

Added `domain.GroupLister` and `LDAPAdapter.ListGroups`, searching the group
subtree for `groupOfNames`/`groupOfUniqueNames` and reading `member` with
`uniqueMember` as the fallback attribute. Compile-time assertions on the adapter
now state both contracts it satisfies. The adapter tests assert the filter is
*not* a membership filter and that a member-less group survives the mapping,
which is the property the whole task exists for.

## Report or fail on incomplete reads

```task
id: KEY-WP-0018-T02
status: done
priority: medium
state_hub_task_id: "d08f62dd-42e8-5c22-ba50-15b53f7473fd"
```

Record on the result which enumeration actually ran — a complete directory
enumeration or the membership-derived fallback — and treat a failed group
enumeration as fatal rather than as a silent gap. In the fallback path, record
each skipped user in the incompatibility report instead of discarding the error,
and derive memberships from the discovered user/group pairs. Emit `partial`
telemetry, and have the CLI say which enumeration produced the snapshot, so a
degraded export is legible without reading the YAML.

`ExportResult` gained `groupEnumeration` — written unconditionally, so nobody has
to infer completeness from an absent field — and a `Complete()` predicate that
requires both a directory enumeration and an empty report. The fallback path
records its own incompleteness as a report entry before it starts, so the
snapshot says so even when every user lookup succeeds.

The fallback also had to stop deriving memberships from `Group.Members`: the
LLDAP adapter never populated that field, so against a real directory the
`memberships` block was always empty while the fixture-backed tests passed. It
now derives each membership from the user/group pair actually observed.

## Define ordering and test the failure modes

```task
id: KEY-WP-0018-T03
status: done
priority: medium
state_hub_task_id: "3cd47458-9469-5cd9-a0b1-f2894402e1f8"
```

Sort users, groups and memberships on stable keys so an unchanged directory
exports byte-identically. Cover the cases the assessment names and the current
suite does not: an empty group, a group enumeration failure, a per-user lookup
failure in the fallback path, and repeat-run determinism.

Sorted users and groups by ID and memberships by group then user. Four exporter
tests and two adapter tests cover the named cases; the determinism test runs the
export three times over deliberately unsorted input and compares the full
ordering, rather than asserting on a single sorted field.

Recorded in `SCOPE.md` and in G05's status what this does and does not establish:
completeness evidence for the user/group/membership surface, not for credential
migration, which stays under G03.