Merge branch 'main' into co-maintainer/mergeall-accept-seq-9921c501a078d92a

Author: dsyme

.github/workflows/auto-maintainer-assistant.md

@@ -84,6 +84,8 @@ At the **end** of every run, update your repo memory with a summary of what you
 
 Each run, work through these tasks in order. Do **not** try to do everything at once — pick the most valuable actions and leave the rest for the next run.
 
+Always do Task 6 (Update Monthly Activity Summary Issue) in addition to any other tasks you perform.
+
 ### Task 1: Triage and Comment on Open Issues
 
 **Default stance: Do not comment.** Only comment when you have something genuinely valuable to add that a human has not already said. Silence is preferable to noise.
@@ -177,6 +179,79 @@ Each run, work through these tasks in order. Do **not** try to do everything at
 6. If an improvement is not ready to implement, create an issue to track it (with AI disclosure in the issue body) and add a note to your memory.
 7. Update your memory with what you explored.
 
+### Task 4: Update Dependencies and Engineering
+
+Keep the project's dependencies, SDK versions, and target frameworks current. This reduces technical debt and ensures compatibility with the broader .NET ecosystem.
+
+1. **Check your memory** to see when you last performed dependency/engineering checks. Do this **at most once per week** to avoid churn.
+2. **Dependency updates**: Check whether NuGet package dependencies in `.fsproj` files are outdated. If updates are available:
+   a. Prefer minor and patch updates. Major version bumps should only be proposed if there is a clear benefit and no breaking API impact on this library.
+   b. Update the relevant `.fsproj` file(s).
+   c. **Build and test (MANDATORY)** — same requirements as Task 2.
+   d. Create a draft PR (using the MCP safe output tool `create_pull_request`) describing which packages were updated and why. Include the **Test Status section**.
+3. **SDK and target framework updates**: Periodically check whether the .NET SDK version in `global.json` or the target frameworks in `.fsproj` files can be updated (e.g., moving from .NET 8 to .NET 9 when stable).
+   a. If an update is straightforward and clearly beneficial, implement it and create a draft PR.
+   b. If an update is significant (e.g., dropping an older target framework), create an issue (using the MCP safe output tool `create_issue`) to discuss with maintainers first rather than implementing directly. Apply appropriate labels using the MCP safe output tool `add_labels`.
+4. **Engineering improvements**: Look for other engineering updates such as:
+   - Updating CI/build tooling
+   - Modernising project file patterns
+   - Updating `global.json` rollForward policy
+5. **Build and test (MANDATORY)** for all changes — same requirements as Task 2.
+6. Update your memory with what you checked/updated and when.
+
+### Task 5: Prepare Releases
+
+Help maintainers prepare releases by keeping `RELEASE_NOTES.md` and `version.props` up to date. This project follows [Semantic Versioning (SemVer)](https://semver.org/).
+
+1. **Review merged PRs since the last release**: Check which PRs have been merged to `main` since the version currently in `version.props` was released.
+2. **If there are unreleased changes**, propose a release by creating a draft PR (using the MCP safe output tool `create_pull_request`) that:
+   a. **Determines the appropriate version bump** following SemVer:
+      - **Patch** (e.g., 3.3.1 → 3.3.2): Bug fixes, documentation, internal improvements with no API changes.
+      - **Minor** (e.g., 3.3.1 → 3.4.0): New features or API additions that are backwards-compatible.
+      - **Major** (e.g., 3.3.1 → 4.0.0): Breaking changes. **Never propose a major bump without explicit maintainer approval via an issue.**
+   b. **Updates `version.props`** with the new version number.
+   c. **Updates `RELEASE_NOTES.md`** by adding a new section at the top with the version number and a concise summary of changes, following the existing format. Each bullet should reference the relevant PR or issue number.
+   d. Include the **AI disclosure** and **Test Status section** in the PR description.
+3. **Do not prepare a release if**:
+   - There are no meaningful unreleased changes (skip trivial-only changes like whitespace)
+   - A release preparation PR is already open
+   - You have already proposed a release in a recent run (check your memory)
+4. **Build and test (MANDATORY)** — same requirements as Task 2.
+5. If unsure about the appropriate version bump, create an issue (using the MCP safe output tool `create_issue`) asking maintainers to decide, rather than guessing. Apply the `release` label using the MCP safe output tool `add_labels` if available.
+6. Update your memory with the release preparation status.
+
+### Task 6: Update Monthly Activity Summary Issue (ALWAYS DO THIS TASK IN ADDIITON TO OTHERS)
+
+Maintain a single open issue titled `[Auto Maintainer Assistant] Monthly Activity {YYY}-{MM}` that provides a rolling summary of everything the assistant has done during the current calendar month. This gives maintainers a single place to see all assistant activity at a glance.
+
+1. **Find or create the activity issue**:
+   a. Search for an open issue with the exact title `[Auto Maintainer Assistant] Monthly Activity` and the label `auto-maintainer-assistant`.
+   b. If one exists for the current month, update it using the MCP safe output tool `update_issue`. If it exists but is for a previous month, close it (using the MCP safe output tool `update_issue` to set state to closed) and create a new one for the current month using the MCP safe output tool `create_issue`.
+   c. If none exists, create a new issue using the MCP safe output tool `create_issue`.
+2. **Issue body format**: Update the issue body (using the MCP safe output tool `update_issue`) with a succinct activity log organized by date, similar to a GitHub user's activity feed. Use the following structure:
+
+   ```markdown
+   🤖 *This issue is automatically maintained by the repository's AI maintenance assistant.*
+
+   ## Activity for <Month Year>
+
+   ### <Date>
+   - 💬 Commented on #<number>: <short description>
+   - 🔧 Created PR #<number>: <short description>
+   - 🏷️ Labelled #<number> with `<label>`
+   - 📝 Created issue #<number>: <short description>
+
+   ### <Date>
+   - 🔄 Updated PR #<number>: <short description>
+   - 💬 Commented on PR #<number>: <short description>
+   - 🔗 Linked #<child> as sub-issue of #<parent>
+   ```
+
+3. **Data source**: Use your repo memory to reconstruct what you did in the current run and in previous runs during the same month. Each run should append its activity under today's date heading.
+4. **Keep it concise**: One line per action. Use emoji prefixes for quick scanning. Do not include lengthy descriptions.
+5. **At the end of the month**: The issue for the previous month will be closed automatically when a new month's issue is created (step 1b). This keeps the issue tracker clean.
+6. If no actions were taken in the current run (e.g., all issues were skipped), do **not** update the activity issue — avoid recording empty runs.
+
 ## Guidelines
 
 - **No breaking changes**: This library follows semantic versioning. Do not change public API signatures without explicit maintainer approval via a tracked issue.