V3.2 release candidate

.claude/settings.json

@@ -0,0 +1,15 @@
+{
+  "hooks": {
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "id": "ai-prompt-auto-commit",
+            "type": "command",
+            "command": "input=$(cat); ts=$(date +%Y-%m-%dT%H-%M-%S); model=$(printf '%s' \"$input\" | jq -r '.model // \"claude-sonnet-4-6\"'); printf '%s' \"$input\" | jq -r '.prompt' > \".prompts/${ts}_${model}.md\""
+          }
+        ]
+      }
+    ]
+  }
+}

.pre-commit-config.yaml

@@ -14,6 +14,17 @@ repos:
       - id: trailing-whitespace
       - id: end-of-file-fixer
 
+  - repo: https://github.com/pycalendar/ai-prompt-auto-commit
+    rev: v0.0.5
+    hooks:
+      - id: unstage-ai-prompts
+      - id: append-ai-prompts
+        stages: [prepare-commit-msg]
+      - id: archive-ai-prompts
+        stages: [post-commit]
+      - id: prepare-ai-repository
+        stages: [manual]
+
   - repo: https://github.com/compilerla/conventional-pre-commit
     rev: v3.4.0
     hooks:

AI-POLICY.md

@@ -2,7 +2,25 @@
 
 ## Read this first
 
-The most important rule: Be honest and inform about it!
+The most important rule: be honest and inform about it!
+
+Tools should generally be used for improving the quality of the
+project, not for rapidly adding new features.
+
+Keep a log of the prompts used - prompts should be included
+verbatimely in the git commits as long as it's possible without making
+the messages too messy.  When relevant, chat-output may also need to
+be included.  The `docs/design`-folder can be used for dumping
+AI-generated design documents, code reviews, prompts that are too
+large for being included in the commit message, etc.
+
+Keep it clear what is human-written vs what is AI-written.  In a
+feature-branch, separate AI-commits and human-commits is preferable.
+Those should most often be squashed together before including it in
+the main branch, with a notice in the commit message on what parts of
+the commit is AI-generated.
+
+## Transparency matters
 
 If you've spent hours, perhaps a full day of your time writing up a
 pull request, then I sort of owe you something.  I should spend some
@@ -26,10 +44,9 @@ explain in details why I'm rejecting the pull request.
 ## Bugfixes are (most often) welcome
 
 It's fine to ask the AI for help to analyze a bug and create a fix for
-it.  By discovering the bug, reproducing it and testing it you're adding
-real value to the project - but be transparent about AI usage and I
-expect that you will not break down and cry if I decide to reject the code
-changes.
+it.  By discovering the bug, reproducing it and testing it you're
+adding real value to the project - just remember to be honest, if you have no clue what Claude did and why it solves the bug, then inform!  Do not take offence if the code changes are rejected, or completely
+rewritten.
 
 ## General rules
 
@@ -65,7 +82,41 @@ changes.
   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**
   responsibility that the contribution follows those guidelines.
+
+## Disclosure of GenAI usage, 2.2.6 - 3.2.0
+
+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.  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".
+
+I don't have any good log of prompts given to Claude prior to the 3.2.0-release, but some of the considerations from Claude has been stored under `docs/design`.  A copy of my [CLAUDE.md](docs/design/CLAUDE.md)-file can now be found in the same directory.
+
+Generated changes and human-made changes are often mixed up.  I prefer "logical" commits containing self-sustained changesets, one of the things I'm often asking Claude to do is to do a rebase of a branch and organize the commits in one or few logical commits with descriptive commit messages.
+
+## Future plans of GenAI-usage
+
+Post-3.2.0 and until further notice I will try to go back to the old ways for doing the "core development tasks" - new features and complex refactoring.  If nothing else, it's important for maintaining my brain cells, coding skills and making sure all the changes sticks to my memory.  The new policy is that GenAI-tools should be used mainly for improving quality, not speeding up the development.
+
+I still intend to use GenAI heavily for certain tasks, particularly anything that is either "mundane and tedious" or unrelated to the "the working end" of the library.  Examples:
+
+* Code reviews.  I think there should be a policy that all changesets and releases should go through AI-driven code review.  By itself it sounds like a good idea, though one should be aware of the risk is that this comes *instead* of human reviews rather than as an addition.
+* Writing up test code.  I do believe "test driven development" is a good idea (write test code first, then the logic), but writing tests may be both tedious and difficult.  Claude can make them really fast, though it still needs some QA, care should be taken to ensure it's testing the right thing.
+* Debugging.  It's easy to get stuck and spend tons of time on debugging - sometimes (but not always) Claude can find them easily.  (Best approach is sometimes to do manual debugging in parallell with AI-driven debugging ... sometimes I "win", othertimes the AI "wins").
+* Minor bugfixes ... the bugfix itself may be a one line changeset, but tests and debugging takes time.
+* Maintaining the integration test framework.  I've consistently failed setting up and maintaining a "battery" of caldav servers from 2013 to 2025, thanks to Claude we now have it in place.  It's important, a majority of issues reported are about compatibility problems, the more servers I have for testing every release, the less troubles will be discovered downstream.
+* Setting up CI-related automated QA tests, pipelines etc
+* The companion caldav-server-checker tool is quite suitable for GenAI-work - it's a bit like test code, writing up the checks to discover various server issues is rather tedious and time-consuming.  Without AI-help I would probably have covered less than half of the "features" that are now tested for.
+* 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 (but care should be taken - I've seen Claude hallucinating completely wrong RFC references).
+* Various other mundane and tedious work (i.e. "I left a TODO-note in the code over there, could you have look into it and eliminate it?").