#7564 ticket md files

Author: tobiu

.github/ISSUE/ticket-filter-issues-by-date.md

@@ -0,0 +1,29 @@
+---
+title: "Filter GitHub Issues by Date in SyncService"
+labels: enhancement, AI
+---
+
+GH ticket id: #7573
+
+**Epic:** #7564
+**Phase:** 1
+**Depends On:** #7571
+**Assignee:** tobiu
+**Status:** To Do
+
+## Description
+
+To significantly improve the performance and reduce the scope of the issue synchronization, the `#pullFromGitHub` method must be updated to process only the issues relevant to our configured time window.
+
+## Acceptance Criteria
+
+1.  The `#pullFromGitHub()` method in `SyncService.mjs` is updated.
+2.  After fetching the full list of issues from GitHub, the method filters the array.
+3.  The filter logic should only keep issues where `createdAt >= syncStartDate` OR `updatedAt >= syncStartDate`.
+4.  Only the issues that pass this filter are processed for local file creation, updates, or deletion.
+
+## Benefits
+
+-   Drastically reduces the number of issues processed during a sync, improving performance.
+-   Prevents the local repository from being cluttered with thousands of irrelevant, legacy issues.
+-   Focuses the synchronization effort on active and recent work items.

.github/ISSUE/ticket-implement-dynamic-release-fetching.md

@@ -0,0 +1,31 @@
+---
+title: "Implement Dynamic Release Fetching in SyncService"
+labels: enhancement, AI
+---
+
+GH ticket id: #7572
+
+**Epic:** #7564
+**Phase:** 1
+**Depends On:** #7571
+**Assignee:** tobiu
+**Status:** To Do
+
+## Description
+
+With the configuration now based on a `syncStartDate`, the `SyncService` must be updated to dynamically fetch release data from GitHub instead of relying on a static list. This fetched data will be used by the archiving logic.
+
+## Acceptance Criteria
+
+1.  A new private method, `#fetchAndCacheReleases()`, is created in `SyncService.mjs`.
+2.  This method is called once at the beginning of the `runFullSync()` orchestration.
+3.  It executes `gh release list --json tagName,publishedAt --limit 1000` to get all releases.
+4.  It filters the fetched releases, keeping only those with a `publishedAt` date on or after the `syncStartDate` from the config.
+5.  It sorts the filtered releases by `publishedAt` date in descending order (newest first).
+6.  The resulting array of `{ tagName, publishedAt }` objects is stored in an instance property (e.g., `this.releases`) for use by other methods during the sync.
+
+## Benefits
+
+-   Makes the archiving process fully automated and aware of the latest project releases.
+-   Eliminates the need for manual configuration updates when a new version is released.
+-   Ensures the service has an accurate, up-to-date list of all relevant releases.

.github/ISSUE/ticket-refactor-config-for-dynamic-sync.md

@@ -0,0 +1,27 @@
+---
+title: "Refactor Sync Config for Dynamic Date-Based Syncing"
+labels: enhancement, AI
+---
+
+GH ticket id: #7571
+
+**Epic:** #7564
+**Phase:** 1
+**Assignee:** tobiu
+**Status:** To Do
+
+## Description
+
+To make the issue synchronization process scalable and efficient, we need to move away from a static release list and instead use a date-based approach to limit the scope of the sync. This involves removing the hardcoded `releases` array from the configuration and replacing it with a single `syncStartDate`.
+
+## Acceptance Criteria
+
+1.  The `ai/mcp/server/config.mjs` file is updated.
+2.  The `githubWorkflow.issueSync.releases` array is **removed**.
+3.  A new string property, `githubWorkflow.issueSync.syncStartDate`, is added. Its value should be set to a reasonable default, like `'2024-01-01T00:00:00Z'`, to limit the sync to recent v10+ issues.
+
+## Benefits
+
+-   Decouples the sync logic from a static, manually maintained list of releases.
+-   Provides a single, simple configuration point for controlling the time window of the synchronization.
+-   Paves the way for the service to dynamically fetch release data from GitHub.

.github/ISSUE/ticket-sync-release-notes.md

@@ -0,0 +1,31 @@
+---
+title: "Implement Release Note Synchronization"
+labels: enhancement, AI
+---
+
+GH ticket id: #7575
+
+**Epic:** #7564
+**Phase:** 1
+**Depends On:** #7571
+**Assignee:** tobiu
+**Status:** To Do
+
+## Description
+
+To create a complete local mirror of the project's history, we need to synchronize the release notes from GitHub to local Markdown files. This provides valuable context for the AI knowledge base and for developers working offline.
+
+## Acceptance Criteria
+
+1.  A new private method, `#syncReleaseNotes()`, is created in `SyncService.mjs`.
+2.  This method is orchestrated by the main `runFullSync()` method.
+3.  It uses `gh release list --json tagName,publishedAt` to get all releases.
+4.  It filters this list to include only releases published on or after the `syncStartDate`.
+5.  For each relevant release, it calls `gh release view <tagName>` to fetch the full, rendered release notes.
+6.  The body of each release note is saved as a local Markdown file in the `.github/RELEASE_NOTES/` directory (e.g., `.github/RELEASE_NOTES/v10.9.0.md`).
+
+## Benefits
+
+-   Provides a complete, local, and queryable archive of all project release notes.
+-   Enriches the AI knowledge base with high-level summaries of changes and new features for each version.
+-   Improves the agent's ability to understand the evolution of the codebase over time.

.github/ISSUE/ticket-update-archiving-logic.md

@@ -0,0 +1,30 @@
+---
+title: "Update Archiving Logic to Use Dynamic Release Data"
+labels: enhancement, AI
+---
+
+GH ticket id: #7574
+
+**Epic:** #7564
+**Phase:** 1
+**Depends On:** #7572
+**Assignee:** TBD
+**Status:** To Do
+
+## Description
+
+The issue archiving logic in `#getIssuePath()` is currently tied to a static configuration. It needs to be refactored to use the dynamic list of releases fetched from GitHub at the start of the sync process.
+
+## Acceptance Criteria
+
+1.  The `#getIssuePath()` method in `SyncService.mjs` is refactored.
+2.  When determining the version for a closed issue, the method no longer references a static config.
+3.  Instead, it iterates over the `this.releases` array (populated by `#fetchAndCacheReleases()`).
+4.  It correctly identifies the target version by finding the first release in the sorted list whose `publishedAt` date is after the issue's `closedAt` date.
+5.  The logic for handling issues with an explicit `milestone` remains as a priority.
+
+## Benefits
+
+-   Completes the transition to a fully dynamic, date-based synchronization system.
+-   Ensures that closed issues are always archived into the correct, most recent release folder without manual intervention.
+-   Makes the archiving logic resilient to changes in the project's release cadence.