chore: remove dead old_flags entries and superseded incompatibility_description keys

- Remove no_supported_components_support from robur/purelymail (superseded by
  get-supported-components: unsupported new-style feature)
- Remove no_delete_event from zimbra (event_by_url was fixed; flag unused in tests)
- Remove empty old_flags: [] from cyrus and posteo
- Remove from incompatibility_description:
  - no_default_calendar, no_freebusy_rfc6638 (superseded/dead)
  - text_search_is_case_insensitive (superseded by search.text.case-sensitive)
  - date_search_ignores_duration, vtodo_no_dtstart_infinite_duration (dead, uncovered)
  - vtodo_no_dtstart_search_weirdness, vtodo_no_duration_search_weirdness,
    vtodo_with_due_weirdness (dead "Zimbra is weird" entries)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: tobixen

AI-POLICY.md

@@ -70,6 +70,11 @@ rewritten.
   adding value to the project.  You should at least do a quick QA on
   the AI-answer and acknowledge that it was generated by the AI.
 
+* Most AI policies warns about potential copyright infringements.  I
+  can hardly think it's any risk wrg of contributions to the Python
+  CalDAV library.  In particular, if your changeset consists of lots
+  of minor changes to existing code, then it's nothing to worry about.
+
 * The Contributors Guidelines aren't strongly enforced on this project
   as of 2026-02, and I can hardly see cases where the AI would break
   the Code of Conduct, but at the end of the day, it's **YOUR**
@@ -79,7 +84,7 @@ rewritten.
 
 The maintainer started playing with Claude Code in the end of 2025 - and [blogged about it](https://www.redpill-linpro.com/techblog/2026/03/20/from-luddite-to-vibe-coder.html)
 
-Releases 2.2.6 - 3.2.0 has been heavily assisted by Claude - which is pretty obvious when looking into the commit messages.  My experiences has been mixed - sometimes it seems to be doing a better and faster job than me, other times it seems to be making a mess a lot faster than what I can do it.  Despite (or because of?) using Claude extensively, I spent much more time on it than estimated.
+Releases 2.2.6 - 3.2.0 has been heavily assisted by Claude - which is pretty obvious when looking into the commit messages.  My experiences has been mixed - sometimes it seems to be doing a better and faster job than me, other times it seems to be making a mess a lot faster than what I can do it.  Despiteof (or because of?) using Claude extensively, I spent much more time on the 3.0.0-release than estimated.
 
 Lots of time and efforts have been spent on doing QA on the changes, fixing up things and/or asking Claude to do a better job.  The surge of issues reported after the 3.0-release is probably unrelated to the AI usage - it's a result of trying to shoehorn both async and API changes into it without breaking backward compatbility and without duplicating too much code.  The CHANGELOG.md entry for 3.0 explicitly declared a caveat: "there are massive code changes in version 3.0, so if you're using the Python CalDAV client library in some sharp production environment, I would recommend to wait for two months before upgrading".
 
@@ -104,4 +109,4 @@ I still intend to use GenAI heavily for certain tasks, like:
 * Investigations of different architectural choices - like with the async work I had claude develop different design approaches and chose the one that I felt most comfortable with (though I'm still not sure that I did the right choice).
 * Reading RFCs and quickly give a pointer to the relevant sections, or verifying that the code is according to the standards or not.
 
-I will do some research on how to log prompts and chat.
+I will do some research on how to log prompts and chat - but it's difficult, my feedback to Claude is maningless without the context - Claude may deliver tons of text and rejected code changes for every commit.

README.md

@@ -56,6 +56,8 @@ Other documentation:
 * [Apache License](COPYING.APACHE)
 * [GPL license](COPYING.GPL)
 
+There is also a directory [docs/design](docs/design) containing lots of documents, mostly AI-generated, containing things like design decisions and other things that neither is deemed important enough to have a document on the root of the project nor deemed to be "user documentation".
+
 The package is published at [Pypi](https://pypi.org/project/caldav)
 
 ## HTTP Libraries

caldav/compatibility_hints.py

@@ -725,13 +725,6 @@ def dotted_feature_set_list(self, compact=False):
 ## * Perhaps some more readable format should be considered (yaml?).
 ## * Consider how to get this into the documentation
 incompatibility_description = {
-    'no_default_calendar':
-        """The given user starts without an assigned default calendar """
-        """(or without pre-defined calendars at all)""",
-
-    'no_freebusy_rfc6638':
-        """Server does not support a freebusy-request as per RFC6638""",
-
     'calendar_order':
         """Server supports (nonstandard) calendar ordering property""",
 
@@ -746,10 +739,6 @@ def dotted_feature_set_list(self, compact=False):
     'event_by_url_is_broken':
         """A GET towards a valid calendar object resource URL will yield 404 (wtf?)""",
 
-    'no_delete_event':
-        """Zimbra does not support deleting an event, probably because event_by_url is broken""",
-
-
     'propfind_allprop_failure':
         """The propfind test fails ... """
         """it asserts DAV:allprop response contains the text 'resourcetype', """
@@ -773,20 +762,6 @@ def dotted_feature_set_list(self, compact=False):
         """before the date search interval.  This is in breach of rfc4791"""
         """section 9.9""",
 
-    'vtodo_no_dtstart_infinite_duration':
-        """date search will find todo-items without dtstart if due is """
-        """after the date search interval.  This is in breach of rfc4791"""
-        """section 9.9""",
-
-    'vtodo_no_dtstart_search_weirdness':
-       """Zimbra is weird""",
-
-    'vtodo_no_duration_search_weirdness':
-       """Zimbra is weird""",
-
-    'vtodo_with_due_weirdness':
-       """Zimbra is weird""",
-
     'vtodo-cannot-be-uncompleted':
         """If a VTODO object has been set with STATUS:COMPLETE, it's not possible to delete the COMPLTEDED attribute and change back to STATUS:IN-ACTION""",
 
@@ -803,12 +778,6 @@ def dotted_feature_set_list(self, compact=False):
     'dav_not_supported':
         """when asked, the server may claim it doesn't support the DAV protocol.  Observed by one baikal server, should be investigated more (TODO) and robur""",
 
-    'text_search_is_case_insensitive':
-        """Probably not supporting the collation used by the caldav library""",
-
-    'date_search_ignores_duration':
-        """Date search with search interval overlapping event interval works on events with dtstart and dtend, but not on events with dtstart and due""",
-
     'date_todo_search_ignores_duration':
         """Same as above, but specifically for tasks""",
 
@@ -933,7 +902,7 @@ def dotted_feature_set_list(self, compact=False):
     #'save-load.todo.mixed-calendar': {'support': 'unsupported'}, ## Why?  It started complaining about this just recently.
     'principal-search.by-name.self': {'support': 'unsupported'},
     'principal-search': {'support': 'ungraceful'},
-    'old_flags': ['unique_calendar_ids'],
+    #'old_flags': ['unique_calendar_ids'],
     ## I'm surprised, I'm quite sure this was passing earlier.  Caldav commit a98d50490b872e9b9d8e93e2e401c936ad193003, caldav server checker commit 3cae24cf99da1702b851b5a74a9b88c8e5317dad
     'search.combined-is-logical-and': False
 }
@@ -986,16 +955,13 @@ def dotted_feature_set_list(self, compact=False):
     "scheduling.mailbox.inbox-delivery": {"support": "unsupported"},
 
     "old_flags": [
-    ## apparently, zimbra has no journal support
-
     ## setting display name in zimbra does not work (display name,
     ## calendar-ID and URL is the same, the display name cannot be
     ## changed, it can only be given if no calendar-ID is given.  In
     ## earlier versions of Zimbra display-name could be changed, but
     ## then the calendar would not be available on the old URL
     ## anymore)
     ## 'event_by_url_is_broken' removed - works in zimbra/zcs-foss:latest
-    'no_delete_event',
     'vtodo_datesearch_notime_task_is_skipped',
     'no_relships',
 
@@ -1118,7 +1084,6 @@ def dotted_feature_set_list(self, compact=False):
         "support": "quirk",
         "behaviour": "server delivers iTIP notification to inbox AND auto-schedules into calendar",
     },
-    'old_flags': []
 }
 
 ## See comments on https://github.com/python-caldav/caldav/issues/3
@@ -1261,7 +1226,6 @@ def dotted_feature_set_list(self, compact=False):
     "scheduling": {"support": "unsupported"},
     'old_flags': [
         'non_existing_raises_other', ## AuthorizationError instead of NotFoundError
-        'no_supported_components_support',
         'no_relships',
     ],
     'test-calendar': {'cleanup-regime': 'wipe-calendar'},
@@ -1302,9 +1266,6 @@ def dotted_feature_set_list(self, compact=False):
     'sync-token': {'support': 'ungraceful'},
     'principal-search': {'support': 'unsupported'},
     "scheduling": {"support": "unsupported"},
-    'old_flags': [
-        #'no_recurring_todo', ## todo
-    ]
 }
 
 #calendar_mail_ru = [
@@ -1446,9 +1407,6 @@ def dotted_feature_set_list(self, compact=False):
     },
     ## Known, work in progress
     "scheduling": {"support": "unsupported"},
-    'old_flags': [
-        'no_supported_components_support',
-    ],
     ## Known, not a breach of standard
     "get-supported-components": {"support": "unsupported"},
 }

docs/design/README.md

@@ -1,6 +1,6 @@
 # CalDAV Design Documents
 
-End-user documentation belongs under `../srv` and more or less important stuff belongs under the project root.  "Everything else" may be thrown into this directory.
+End-user documentation belongs under `../source` and more or less important stuff belongs under the project root.  "Everything else" may be thrown into this directory.
 
 Admittedly it's quite much junk in this folder.
 

docs/source/http-libraries.rst

@@ -25,8 +25,7 @@ decisions, it may have been due to personal conflicts - or, perhaps
 the quality of the code was found not to be good enough.  It works for
 me.  I've had Claude to do a code review of niquests and urllib3 - it
 gave a thumbs-up for Niquests, while urllib3.future could benefit from
-some refactoring (claude also recommends shedding backward
-compatibility).
+some refactoring.
 
 I see some possible reasons why one would like to avoid niquests:
   * Many projects are already dependent on requests and/or httpx, and one