refactor: use pure pimdir collection id

Author: soywod

CHANGELOG.md

@@ -31,6 +31,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixed
 
+- Fixed the pimdir backend accepting a collection of any kind as an addressbook. A sync engine caches mail, calendars and contacts in one store, and only the listing narrowed them to `text/vcard`, so `card list -k imap/INBOX` printed a mailbox's messages as blank contacts and a create would have staged a vCard into it. An addressbook id now names an addressbook or nothing, and a wrong one is refused naming the addressbooks the account holds.
 - Fixed a card vanishing from the pimdir backend when another card of the same addressbook carried its `UID`. RFC 6352 requires that `UID` to be unique and servers hand over duplicates anyway, most often after a repeated import; the store keys the second copy apart now, so both cards list, read and act as ordinary cards under their own ids.
 - Fixed `card list` leaving the `TEL` column empty for any card writing its phone above its mail. The preview chained its three property reads, so a line that was not an `EMAIL` never reached the `TEL` read. Every backend was affected.
 - Fixed the pimdir backend linking a card it stages under `uid:<UID>` where the sync engine uses the bare `UID`, which would have stored the card twice and synced it as a duplicate contact. The derivations now come from io-pimdir's own conventions.

cairn/changes/archive/pimdir-collection-id-is-the-addressbook/delta.md

@@ -0,0 +1,20 @@
+---
+cairn: delta
+change: pimdir-collection-id-is-the-addressbook
+---
+
+## ADDED Requirements
+
+### Requirement: A pimdir addressbook is its collection id
+The pimdir backend SHALL show and accept an address book as the store's collection id, verbatim: the collection `carddav/default` is the address book `carddav/default`. It SHALL NOT derive, strip or accept a shortened spelling, and no configuration SHALL offer one.
+
+A sync engine binds a source's collections under a namespace, so an id carries one; the store is opaque to it, neither parsing nor validating an id (pimdir SPEC 9.2) and modelling hierarchy through `parent` rather than through a separator. Shortening is therefore a guess at the producer's convention, and one that makes a single address book answer to two spellings.
+
+An id SHALL name an address book or name nothing: one store holds the collections of every kind a sync caches, so the kind SHALL narrow them at the one seam both the listing and the id check read, never at the listing alone. A kind-less collection counts, a sync having created one before kinds were declared.
+
+An id naming no address book of the account SHALL be refused naming the ones it holds. Ids carry the sync engine's namespace and are not guessable, so an error asking for one that shows none leaves the user nothing to act on.
+
+#### Scenario: A mailbox is not an address book
+- GIVEN a store a sync fills with mail, calendar and contact collections alike
+- WHEN a card command addresses a `message/rfc822` collection
+- THEN it is refused naming the address books the account holds, rather than listing the mailbox's messages as blank contacts

cairn/changes/archive/pimdir-collection-id-is-the-addressbook/proposal.md

@@ -0,0 +1,22 @@
+---
+cairn: change
+id: pimdir-collection-id-is-the-addressbook
+status: landed
+created: 2026-08-28
+---
+
+# A pimdir addressbook is its collection id
+
+## Why
+
+The sync engine binds a source's collections under a namespace, so an address book it caches is keyed `carddav/default` rather than `default`. Cardamum already addresses it by that id and shows it whole, which is the right shape: a collection id is opaque to the store, which neither parses nor validates it (pimdir SPEC 9.2) and models hierarchy through `parent` rather than through a separator, so shortening one would be a guess at the producer's convention rather than a lookup.
+
+Himalaya learnt this the long way, having shipped a derived short name and a `pimdir.namespace` key to rescue the cases the derivation could not decide, and has just removed both. Cardamum never grew either, so the alignment is to say so before someone adds one, and to make the rule usable.
+
+Usable is where two gaps showed. An id that names no collection is refused, but the refusal does not say what the store does hold, and an id carrying a namespace nobody can guess is one the user has to be shown. Worse, `known_collection` read the store's collections unfiltered while the listing filtered them by kind, so an id naming a collection of another kind passed the check: against a store Neverest fills with mail, calendars and contacts alike, `card list -k imap/INBOX` listed a mailbox's messages as blank contacts, and a create would have staged a vCard into it.
+
+## What
+
+The requirement is stated: a pimdir addressbook is its collection id, verbatim, with no derived spelling and no configuration offering one.
+
+The kind filter moves into `collections()`, the one seam both the listing and the check read, so an id names an address book or it names nothing. The refusal then names the address books the account holds, so the id to type is in the error that asks for it.

cairn/changes/archive/pimdir-collection-id-is-the-addressbook/tasks.md

@@ -0,0 +1,9 @@
+---
+cairn: tasks
+change: pimdir-collection-id-is-the-addressbook
+---
+
+- [x] State the requirement in the backends spec
+- [x] Filter by kind in `collections()`, so the check and the listing agree
+- [x] `known_collection` names the address books the account holds
+- [x] Verify against the real store: a mailbox id and an unknown id are both refused naming `carddav/default`

cairn/log/2026-08-28-pimdir-collection-id-is-the-addressbook.md

@@ -0,0 +1,25 @@
+---
+cairn: log
+date: 2026-08-28
+change: pimdir-collection-id-is-the-addressbook
+---
+
+# A pimdir addressbook is its collection id
+
+Neverest binds a source's collections under a namespace, so the address book it caches is keyed `carddav/default`. Cardamum already addressed it by that whole id, which is the right shape and was never written down: a collection id is opaque to the store, which neither parses nor validates it (pimdir SPEC 9.2) and models hierarchy through `parent` rather than through a separator, so shortening one is a guess at the producer's convention rather than a lookup. Himalaya had shipped such a guess, with a `pimdir.namespace` key to rescue the stores it could not decide, and removed both the same day. Stating the rule here is what stops it being added.
+
+Writing it down found the two things that made the rule hard to live with.
+
+## What landed
+
+**The kind narrows at one seam, in src/pimdir/backend.rs.** `collections()` returned the account's collections of every kind, and only `list_addressbooks` filtered them down to `text/vcard`. `known_collection` read the same unfiltered list, so an id naming a collection of another kind passed the check. Against a store Neverest fills with mail, calendars and contacts alike, `card list -k imap/INBOX` listed a mailbox's messages as blank contacts, and a create would have staged a vCard into it. The filter moved into `collections()`, which both callers read, so an id names an address book or it names nothing.
+
+**The refusal names what the account holds.** `Addressbook \`default\` not found` became `Addressbook \`default\` not found; this account holds: carddav/default`. An id carrying a namespace is not guessable, so an error asking for one has to show the choices, and the same message now answers a wrong-kind id and a mistyped one.
+
+## Capabilities moved
+
+- backends: added *A pimdir addressbook is its collection id*
+
+## Verification
+
+Built clean and run against the live Neverest store at `~/.local/state/neverest/posteo`, which holds eighteen collections across three kinds under one account. Before the fix, `card list -k imap/INBOX` printed sixteen blank contacts; after it, that id and `default` are both refused naming `carddav/default`, `card list -k carddav/default` lists the contacts, and `addressbook list` is unchanged.

cairn/spec/backends.md

@@ -34,6 +34,15 @@ vdir and pimdir SHALL adapt io-vdir and io-pimdir. vdir stores each addressbook
 ### Requirement: A cache renames nothing it cannot push
 The pimdir backend SHALL refuse every `addressbook update` field. Its collection row (id, display name, description, colour) is written by the sync from the server, and the backend stages item actions only, so any local edit of it is a change no sync would carry. A missing body SHALL fall back to the summary preview in a listing, as an unhydrated card does, rather than render as a blank row.
 
+### Requirement: A pimdir addressbook is its collection id
+The pimdir backend SHALL show and accept an address book as the store's collection id, verbatim: the collection `carddav/default` is the address book `carddav/default`. It SHALL NOT derive, strip or accept a shortened spelling, and no configuration SHALL offer one.
+
+A sync engine binds a source's collections under a namespace, so an id carries one; the store is opaque to it, neither parsing nor validating an id (pimdir SPEC 9.2) and modelling hierarchy through `parent` rather than through a separator. Shortening is therefore a guess at the producer's convention, and one that makes a single address book answer to two spellings.
+
+An id SHALL name an address book or name nothing: one store holds the collections of every kind a sync caches, so the kind SHALL narrow them at the one seam both the listing and the id check read, never at the listing alone. A kind-less collection counts, a sync having created one before kinds were declared.
+
+An id naming no address book of the account SHALL be refused naming the ones it holds. Ids carry the sync engine's namespace and are not guessable, so an error asking for one that shows none leaves the user nothing to act on.
+
 ### Requirement: pimdir is a cache, not a server
 The pimdir backend SHALL treat the store as a possibly-partial cache. `get_card` on a card whose body is not local (`level < Full`, no stored object) SHALL report a clear "body not fetched" state, the cue to sync, rather than a data-loss error. The card still lists: `list_cards` SHALL project the stored `v: 1` summary into a minimal preview vCard (`UID`, `FN`, `EMAIL`) so a contact list reads correctly before a full sync, while `get_card` refuses outright so a preview can never be mistaken for the document of record.
 

src/pimdir/backend.rs

@@ -58,7 +58,6 @@ impl PimdirBackend {
         let mut addressbooks: Vec<Addressbook> = self
             .collections()?
             .into_iter()
-            .filter(|collection| collection.kind.is_empty() || collection.kind == CARD_KIND)
             .map(|collection| Addressbook {
                 name: if collection.name.is_empty() {
                     collection.id.clone()
@@ -229,8 +228,13 @@ impl PimdirBackend {
         Ok(())
     }
 
-    /// The store's collections, narrowed to the configured account when the
-    /// store groups several (pimdir SPEC §9.2).
+    /// The store's address book collections, narrowed to the configured
+    /// account when the store groups several (pimdir SPEC §9.2).
+    ///
+    /// One store holds the collections of every kind a sync caches, so the
+    /// kind is what separates an address book from a mailbox or a calendar.
+    /// A kind-less collection counts: a sync that created one before kinds
+    /// were declared left the column empty.
     fn collections(&self) -> Result<Vec<PimdirCollection>> {
         let collections = match self.inner.account.as_deref() {
             Some(account) => self
@@ -240,7 +244,10 @@ impl PimdirBackend {
             None => self.inner.reader.list_collections()?,
         };
 
-        Ok(collections)
+        Ok(collections
+            .into_iter()
+            .filter(|collection| collection.kind.is_empty() || collection.kind == CARD_KIND)
+            .collect())
     }
 
     /// Pulls every live item of a collection by keyset paging, in the
@@ -309,23 +316,32 @@ impl PimdirBackend {
         })
     }
 
-    /// Fails unless `collection` is a collection the store knows.
+    /// Fails unless `collection` is a collection the store knows, naming the
+    /// ones it does hold.
     ///
     /// The store's read seam answers an unknown collection with an empty page
     /// and its queue accepts an action for any name, so without this a typo in
     /// `-k` would read as an empty addressbook and stage into one nothing will
-    /// ever apply.
+    /// ever apply. An addressbook is its collection id, which carries the sync
+    /// engine's namespace and is not guessable, so the refusal shows the ids to
+    /// choose from.
     fn known_collection(&self, collection: &str) -> Result<()> {
-        let known = self
+        let mut ids: Vec<String> = self
             .collections()?
             .into_iter()
-            .any(|candidate| candidate.id == collection);
+            .map(|candidate| candidate.id)
+            .collect();
 
-        if !known {
-            bail!("Addressbook `{collection}` not found");
+        if ids.iter().any(|id| id == collection) {
+            return Ok(());
         }
 
-        Ok(())
+        ids.sort();
+
+        bail!(
+            "Addressbook `{collection}` not found; this account holds: {}",
+            ids.join(", "),
+        )
     }
 
     /// The stored item behind a public card id, or a clear miss.