diff --git a/TimeWarp.Architecture/.github/issue_template/ai_agent_task.yml b/TimeWarp.Architecture/.github/issue_template/ai_agent_task.yml
new file mode 100644
index 000000000..55966e704
--- /dev/null
+++ b/TimeWarp.Architecture/.github/issue_template/ai_agent_task.yml
@@ -0,0 +1,123 @@
+name: AI Agent Task
+description: Request AI agent assistance for development work
+title: "[AI Task]: "
+labels: ["ai-agent", "automation"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        🤖 **AI Agent Task Request**
+        
+        Use this template to request AI agent assistance. After creating the issue, mention the AI agent (e.g., @claude) in a comment to trigger automated work.
+
+  - type: textarea
+    id: task-description
+    attributes:
+      label: Task Description
+      description: Clearly describe what you want the AI agent to implement
+      placeholder: |
+        Example: "Add dark mode toggle to the settings page with user preference persistence"
+    validations:
+      required: true
+
+  - type: dropdown
+    id: task-type
+    attributes:
+      label: Task Type
+      description: What type of work is this?
+      options:
+        - Feature Implementation
+        - Bug Fix
+        - Refactoring
+        - Testing
+        - Documentation
+        - Architecture Update
+        - Performance Optimization
+    validations:
+      required: true
+
+  - type: textarea
+    id: requirements
+    attributes:
+      label: Requirements
+      description: Specific requirements and constraints
+      placeholder: |
+        - Must use FluentUI components
+        - Should persist user preference to localStorage
+        - Must include unit tests
+        - Should follow existing patterns in codebase
+    validations:
+      required: true
+
+  - type: textarea
+    id: acceptance-criteria
+    attributes:
+      label: Acceptance Criteria
+      description: How will we know this task is complete?
+      placeholder: |
+        - [ ] Toggle button appears in settings page
+        - [ ] Dark mode applies to all components
+        - [ ] User preference persists across sessions
+        - [ ] Unit tests cover new functionality
+        - [ ] Documentation is updated
+    validations:
+      required: true
+
+  - type: textarea
+    id: context
+    attributes:
+      label: Context and Background
+      description: Provide any relevant context or background information
+      placeholder: |
+        - Related files: src/components/Settings.tsx
+        - Existing patterns to follow: src/theme/ThemeProvider.tsx
+        - Dependencies: FluentUI theme system
+
+  - type: checkboxes
+    id: scope
+    attributes:
+      label: Scope
+      description: Which areas will this task affect?
+      options:
+        - label: Frontend (Client)
+        - label: Backend (API)
+        - label: Database
+        - label: Tests
+        - label: Documentation
+        - label: DevOps/CI-CD
+        - label: Security
+
+  - type: dropdown
+    id: complexity
+    attributes:
+      label: Estimated Complexity
+      description: How complex do you think this task is?
+      options:
+        - Simple - Single file changes, straightforward implementation
+        - Medium - Multiple files, some research needed
+        - Complex - Architecture changes, significant implementation
+        - Research - Unknown complexity, investigation needed
+    validations:
+      required: true
+
+  - type: textarea
+    id: ai-instructions
+    attributes:
+      label: Special Instructions for AI Agent
+      description: Any specific instructions for the AI agent
+      placeholder: |
+        - Please follow the existing code style in the repository
+        - Create feature branch following naming convention: Author/YYYY-MM-DD/Description
+        - Include comprehensive tests
+        - Update relevant documentation
+
+  - type: markdown
+    attributes:
+      value: |
+        ---
+        
+        **Next Steps:**
+        1. After creating this issue, comment with `@claude please work on this task`
+        2. The AI agent will create a branch and implement the solution
+        3. Review the resulting pull request and provide feedback
+        4. Merge when satisfied with the implementation
\ No newline at end of file
diff --git a/TimeWarp.Architecture/.github/issue_template/bug_report.yml b/TimeWarp.Architecture/.github/issue_template/bug_report.yml
new file mode 100644
index 000000000..5c1375df5
--- /dev/null
+++ b/TimeWarp.Architecture/.github/issue_template/bug_report.yml
@@ -0,0 +1,77 @@
+name: Bug Report
+description: Report a bug or issue
+title: "[Bug]: "
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to report a bug! Please fill out the information below to help us investigate.
+
+  - type: textarea
+    id: description
+    attributes:
+      label: Bug Description
+      description: A clear and concise description of what the bug is.
+      placeholder: Describe what happened...
+    validations:
+      required: true
+
+  - type: textarea
+    id: steps
+    attributes:
+      label: Steps to Reproduce
+      description: Steps to reproduce the behavior
+      placeholder: |
+        1. Go to '...'
+        2. Click on '...'
+        3. Scroll down to '...'
+        4. See error
+    validations:
+      required: true
+
+  - type: textarea
+    id: expected
+    attributes:
+      label: Expected Behavior
+      description: A clear and concise description of what you expected to happen.
+      placeholder: What should have happened?
+    validations:
+      required: true
+
+  - type: textarea
+    id: actual
+    attributes:
+      label: Actual Behavior
+      description: A clear and concise description of what actually happened.
+      placeholder: What actually happened?
+    validations:
+      required: true
+
+  - type: textarea
+    id: environment
+    attributes:
+      label: Environment
+      description: Please provide details about your environment
+      placeholder: |
+        - OS: [e.g. Windows 11, macOS 13, Ubuntu 22.04]
+        - Browser: [e.g. Chrome 120, Firefox 119, Safari 17]
+        - .NET Version: [e.g. .NET 9.0]
+        - Template Version: [e.g. 1.0.0]
+    validations:
+      required: true
+
+  - type: textarea
+    id: logs
+    attributes:
+      label: Logs or Error Messages
+      description: If applicable, add any relevant logs or error messages
+      render: shell
+      placeholder: Paste logs here...
+
+  - type: textarea
+    id: additional
+    attributes:
+      label: Additional Context
+      description: Add any other context about the problem here
+      placeholder: Any additional information that might be helpful...
\ No newline at end of file
diff --git a/TimeWarp.Architecture/.github/issue_template/feature_request.yml b/TimeWarp.Architecture/.github/issue_template/feature_request.yml
new file mode 100644
index 000000000..2ed1bd1a4
--- /dev/null
+++ b/TimeWarp.Architecture/.github/issue_template/feature_request.yml
@@ -0,0 +1,91 @@
+name: Feature Request
+description: Suggest a new feature or enhancement
+title: "[Feature]: "
+labels: ["enhancement"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for suggesting a new feature! Please provide as much detail as possible.
+
+  - type: textarea
+    id: summary
+    attributes:
+      label: Feature Summary
+      description: A brief summary of the feature you'd like to see
+      placeholder: Briefly describe the feature...
+    validations:
+      required: true
+
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem Statement
+      description: What problem does this feature solve?
+      placeholder: |
+        As a [user type],
+        I want [functionality],
+        So that [benefit/value].
+    validations:
+      required: true
+
+  - type: textarea
+    id: solution
+    attributes:
+      label: Proposed Solution
+      description: Describe the solution you'd like to see
+      placeholder: How should this feature work?
+    validations:
+      required: true
+
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternative Solutions
+      description: Describe any alternative solutions or features you've considered
+      placeholder: What other approaches could solve this problem?
+
+  - type: dropdown
+    id: priority
+    attributes:
+      label: Priority
+      description: How important is this feature to you?
+      options:
+        - Low - Nice to have
+        - Medium - Would be helpful
+        - High - Important for my use case
+        - Critical - Blocking my usage
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: scope
+    attributes:
+      label: Scope
+      description: Which areas does this feature affect?
+      options:
+        - label: Templates
+        - label: Architecture
+        - label: Documentation
+        - label: Developer Experience
+        - label: Testing
+        - label: DevOps/CI-CD
+        - label: Performance
+        - label: Security
+
+  - type: textarea
+    id: acceptance
+    attributes:
+      label: Acceptance Criteria
+      description: What criteria must be met for this feature to be considered complete?
+      placeholder: |
+        - [ ] Criterion 1
+        - [ ] Criterion 2
+        - [ ] Criterion 3
+
+  - type: textarea
+    id: additional
+    attributes:
+      label: Additional Context
+      description: Add any other context, mockups, or examples
+      placeholder: Any additional information, screenshots, or examples...
\ No newline at end of file
diff --git a/TimeWarp.Architecture/.vscode/settings.json b/TimeWarp.Architecture/.vscode/settings.json
index 0a5001f1f..d2ae7254d 100644
--- a/TimeWarp.Architecture/.vscode/settings.json
+++ b/TimeWarp.Architecture/.vscode/settings.json
@@ -2,6 +2,7 @@
     "cSpell.words": [
         "Fixie",
         "nameof",
+        "reprioritized",
         "Shouldly",
         "Yarp"
     ]
diff --git a/TimeWarp.Architecture/CLAUDE.md b/TimeWarp.Architecture/CLAUDE.md
index 1ede9233e..670418404 100644
--- a/TimeWarp.Architecture/CLAUDE.md
+++ b/TimeWarp.Architecture/CLAUDE.md
@@ -2,6 +2,13 @@
 
 This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
 
+## Architectural Decisions
+
+Key architectural decisions are documented in `Documentation/Developer/Conceptual/ArchitecturalDecisionRecords/Approved/`:
+- **ADR-0004**: Branch naming conventions
+- **ADR-0005**: Git merge strategy (information preservation over presentation)  
+- **ADR-0006**: Hybrid task management (Kanban + GitHub Issues)
+
 ## Development Commands
 
 ### Running the Application
@@ -107,33 +114,53 @@ The solution uses a mixin system for code reuse:
 
 ## Task Management Workflow
 
-This project uses a **Kanban folder-based workflow** for task management:
+This project uses a **hybrid approach** combining Kanban folders for internal development with GitHub Issues for external collaboration and AI agent integration:
 
-### Kanban Structure
+### Folder-Based Kanban (Internal Development)
 - `Kanban/Backlog/` - Tasks not ready (B### prefix, e.g., `B001_task-name.md`)
 - `Kanban/ToDo/` - Tasks ready to work (### prefix, e.g., `001_task-name.md`) 
 - `Kanban/InProgress/` - Currently being worked on
 - `Kanban/Done/` - Completed tasks
 
+### GitHub Issues (External Interface)
+- **Community contributions**: Bug reports, feature requests from users
+- **AI agent integration**: Create issues and mention AI agents (e.g., @claude) for automated work
+- **Cross-repository coordination**: Issues spanning multiple repositories
+- **Public roadmap**: Features requiring external visibility and stakeholder communication
+
 ### Task Workflow
-1. Create tasks in Backlog with `B###_description.md` naming
-2. Move to ToDo when ready, renaming to `###_description.md`
-3. Move through InProgress → Done as work progresses
-4. Update Implementation Notes section during development
+1. **Internal work**: Create tasks in Kanban folders following B### → ### numbering
+2. **External requests**: Use GitHub Issues with appropriate templates
+3. **AI automation**: Comment on GitHub Issues with "@claude please work on this" to trigger AI agents
+4. **Branch naming**: Task numbers integrate with branch naming convention: `Author/YYYY-MM-DD/Task_###`
+
+### Definition of Done (API Endpoints)
+**Implementation:**
+- Server: *Endpoint (required), Server-side Validator, Mapper, *Handler (required)
+- Contracts: *Request (required), *Response (required), *RequestValidator (required)
+
+**Integration Tests (Fixie):**
+- *Handler Tests (required): Valid Response given valid Request
+- *Endpoint Tests (required): Valid http Response, validation error handling
+- *RequestValidator Tests (required): Test all validation rules
+
+**Documentation:**
+- *Request class and properties (required)
+- *Response class and properties (required)
 
-### Definition of Done Requirements
+### Definition of Done (Client Features)
+**Implementation:**
+- *State (required), Actions, Pipeline, Notification, Components, Pages
 
-**API Endpoints require:**
-- Server: Endpoint, Handler, Validator, Mapper
-- Contracts: Request, Response, RequestValidator  
-- Integration tests for Handler and Endpoint
-- Documentation for Request/Response classes
+**Integration Tests:**
+- State: ShouldClone, ShouldSerialize (Redux DevTools support)
+- Every Action should have at least positive test cases
 
-**Client Features require:**
-- State, Actions, Components/Pages
-- Integration tests for State (ShouldClone, ShouldSerialize)
-- Action tests (at least positive cases)
-- End-to-end tests for page rendering and happy paths
+**End-to-end Tests:**
+- Pages render without error given valid states
+- Happy paths for primary use cases
+
+*Items marked with `*` are required. Others are optional based on feature needs.*
 
 ## API Contract Development Guidelines
 
@@ -177,12 +204,23 @@ Use these regions in entity classes to organize associations:
 - **Tailwind Usage**: Limit to spacing (`m-*`, `p-*`), hover effects, and responsiveness
 - **Avoid**: Tailwind color, typography, border, and shadow classes that conflict with FluentUI
 
-### Development Notes
+## Development Workflow
+
+### Git Strategy
+- **Main branch**: `master` (not `main`)
+- **Merge strategy**: Use merge commits (not squash/rebase) to preserve development history
+- **Branch protection**: Direct commits to master prevented via git hooks
 
+### AI Integration
+- **File-based transparency**: AI tools can directly access Kanban task files for project context
+- **GitHub Issues**: External interface for AI agent automation
+- **Branch creation**: AI agents follow standard branch naming conventions
+
+### Development Notes
 - All projects use `TimeWarp.Architecture` as the root namespace
-- Feature constants are defined via preprocessor directives: `cosmosdb`, `api`, `grpc`, `web`, `yarp`
-- Generated code is excluded via `Directory.Build.targets`
-- Tests use the Fixie framework, not MSTest or xUnit
-- The Aspire orchestrator starts all services for local development
+- Feature constants defined via preprocessor directives: `cosmosdb`, `api`, `grpc`, `web`, `yarp`
+- Generated code excluded via `Directory.Build.targets`
+- Tests use Fixie framework, not MSTest or xUnit
+- Aspire orchestrator starts all services for local development
 - Client state uses TimeWarp patterns with Redux DevTools integration
 - Each assembly must contain a sealed `AssemblyMarker` class for reflection operations
\ No newline at end of file
diff --git a/TimeWarp.Architecture/Documentation/Developer/Conceptual/ArchitecturalDecisionRecords/Approved/0004-branch-naming-conventions.md b/TimeWarp.Architecture/Documentation/Developer/Conceptual/ArchitecturalDecisionRecords/Approved/0004-branch-naming-conventions.md
new file mode 100644
index 000000000..57eefb92c
--- /dev/null
+++ b/TimeWarp.Architecture/Documentation/Developer/Conceptual/ArchitecturalDecisionRecords/Approved/0004-branch-naming-conventions.md
@@ -0,0 +1,185 @@
+# Branch Naming Conventions
+
+## Context and Problem Statement
+
+Development teams need consistent branch naming conventions to maintain organization, enable automation, and provide clear context about the work being performed. Without standardized naming, branches become difficult to identify, organize, and manage, especially in repositories with multiple contributors and long-term development cycles.
+
+Which branch naming convention should we adopt for the TimeWarp Architecture repository?
+
+## Considered Options
+
+* **Flat naming**: Simple descriptive names without structure (e.g., `feature-auth`, `bugfix-db`)
+* **Issue-based**: Branch names tied to issue numbers (e.g., `issue-123`, `gh-456`)
+* **Hierarchical with author**: Include developer identification (e.g., `author/feature/description`)
+* **Date-based with author**: Include creation date for temporal organization (e.g., `author/YYYY-MM-DD/description`)
+* **GitFlow convention**: Standard GitFlow prefixes (e.g., `feature/`, `hotfix/`, `release/`)
+
+## Decision Outcome
+
+Chosen option: **Date-based with author naming convention**, because:
+
+* **Clear ownership**: Developer name provides immediate context about who is working on the branch
+* **Temporal organization**: Date component enables chronological tracking and cleanup
+* **Task integration**: Aligns with our Kanban task management system
+* **Conflict avoidance**: Unique author/date combination prevents naming conflicts
+* **Historical context**: Easy to understand when work was started and by whom
+* **Automation friendly**: Structured format enables scripting and automation
+
+## Standard Format
+
+## Main Branch
+
+- **Main Branch**: `master` (not `main`)
+- Direct commits to `master` are prevented via git hooks
+- All feature work should be done in separate branches and merged via pull requests
+
+## Branch Naming Pattern
+
+### Standard Format
+
+```
+{Author}/{YYYY-MM-DD}/{Description}
+```
+
+**Components:**
+- **Author**: Developer's name or identifier (e.g., `Cramer`, `Smith`)
+- **Date**: Branch creation date in `YYYY-MM-DD` format
+- **Description**: Task identifier or feature description
+
+### Examples
+
+**Task-based branches:**
+```
+Cramer/2025-06-18/Task_019
+Cramer/2025-06-20/Task_022
+```
+
+**Feature-based branches:**
+```
+Cramer/2025-06-15/AddUserAuthentication
+Cramer/2025-06-12/UpdateSwagger
+Cramer/2025-06-10/RefactorApiEndpoints
+```
+
+**Bug fix branches:**
+```
+Cramer/2025-06-14/Fix_DatabaseConnection
+Cramer/2025-06-16/Fix_ValidationError
+```
+
+## Branch Types and Descriptions
+
+### Task Branches
+Used when working on numbered tasks from the Kanban system:
+- **Format**: `{Author}/{Date}/Task_{###}`
+- **Example**: `Cramer/2025-06-18/Task_019`
+- **Usage**: Corresponds to tasks in `Kanban/InProgress/` or `Kanban/ToDo/`
+
+### Feature Branches
+Used for new features or enhancements:
+- **Format**: `{Author}/{Date}/{FeatureName}`
+- **Example**: `Cramer/2025-06-15/AddUserDashboard`
+- **Naming**: Use PascalCase for multi-word features
+
+### Bug Fix Branches
+Used for bug fixes:
+- **Format**: `{Author}/{Date}/Fix_{BugDescription}`
+- **Example**: `Cramer/2025-06-14/Fix_DatabaseTimeout`
+- **Naming**: Prefix with `Fix_` followed by brief description
+
+### Experimental Branches
+Used for experimental work or proof-of-concepts:
+- **Format**: `{Author}/{Date}/Experiment_{Description}`
+- **Example**: `Cramer/2025-06-13/Experiment_NewStateManagement`
+- **Naming**: Prefix with `Experiment_`
+
+## Naming Guidelines
+
+### Do's
+- ✅ Use forward slashes (`/`) as separators
+- ✅ Use consistent date format: `YYYY-MM-DD`
+- ✅ Use PascalCase for multi-word descriptions
+- ✅ Keep descriptions concise but descriptive
+- ✅ Use task numbers when working on Kanban tasks
+- ✅ Include fix context for bug fix branches
+
+### Don'ts
+- ❌ Don't use special characters except underscores and hyphens
+- ❌ Don't use spaces in branch names
+- ❌ Don't create branches directly from master without following the pattern
+- ❌ Don't use abbreviations that aren't clear
+- ❌ Don't omit the date component
+
+## Workflow Integration
+
+### With Kanban Tasks
+When working on tasks from the Kanban system:
+1. Move task from `Kanban/ToDo/` to `Kanban/InProgress/`
+2. Create branch: `{Author}/{Date}/Task_{TaskNumber}`
+3. Complete work and create pull request
+4. After merge, move task to `Kanban/Done/`
+
+### Pull Request Titles
+Pull request titles should reflect the branch purpose:
+- **Task**: `Task 019: Implement user authentication`
+- **Feature**: `Add user dashboard with analytics`
+- **Bug Fix**: `Fix database connection timeout issue`
+
+## Git Commands
+
+### Creating a New Branch
+```bash
+# For a task
+git checkout -b "Cramer/2025-06-18/Task_019"
+
+# For a feature
+git checkout -b "Cramer/2025-06-18/AddUserDashboard"
+
+# For a bug fix
+git checkout -b "Cramer/2025-06-18/Fix_DatabaseTimeout"
+```
+
+### Pushing to Remote
+```bash
+git push -u origin "Cramer/2025-06-18/Task_019"
+```
+
+## Branch Lifecycle
+
+1. **Creation**: Create branch from latest `master`
+2. **Development**: Make commits following conventional commit patterns
+3. **Testing**: Ensure all tests pass before creating PR
+4. **Pull Request**: Create PR with descriptive title and summary
+5. **Review**: Address any review feedback
+6. **Merge**: Squash merge into `master`
+7. **Cleanup**: Delete local and remote feature branch after merge
+
+## Enforcement
+
+Currently, branch naming is enforced through:
+- Code review process
+- Documentation standards
+- Team conventions
+
+Future enhancements may include:
+- Git hooks to validate branch names
+- GitHub Actions to check branch naming patterns
+- Automated branch cleanup for merged branches
+
+## Related Documentation
+
+- [How to Prevent Local Commits to Master](HowToPreventLocalCommitsToMaster.md)
+- [How to Rename Default Branch From Main to Master](HowToRenameDefaultBranchFromMainToMaster.md)
+- [Task Management Workflow](../Conceptual/Overview.md#task-management-workflow)
+
+## Examples from Repository History
+
+Historical examples that follow this pattern:
+- `Cramer/2025-06-18/Task_019`
+- `Cramer/2020-02-05/UpdateTo3.2.0-preview1`
+- `Cramer/2019-11-24/AddGlobal`
+- `Cramer/2020-06-03/Swagger`
+
+---
+
+*This convention ensures consistency, enables better branch organization, and provides clear context about the work being performed on each branch.*
\ No newline at end of file
diff --git a/TimeWarp.Architecture/Documentation/Developer/Conceptual/ArchitecturalDecisionRecords/Approved/0005-git-merge-strategy.md b/TimeWarp.Architecture/Documentation/Developer/Conceptual/ArchitecturalDecisionRecords/Approved/0005-git-merge-strategy.md
new file mode 100644
index 000000000..a5e02173d
--- /dev/null
+++ b/TimeWarp.Architecture/Documentation/Developer/Conceptual/ArchitecturalDecisionRecords/Approved/0005-git-merge-strategy.md
@@ -0,0 +1,132 @@
+# Git Merge Strategy: Preserve Information Over Presentation
+
+## Context and Problem Statement
+
+When integrating feature branches into the master branch, development teams must choose between different merge strategies that fundamentally affect how git history is preserved and presented. Each approach has implications for debugging, rollbacks, historical analysis, and information preservation.
+
+The primary strategies are:
+- **Merge commits**: Preserve complete branch history and merge points
+- **Rebase and merge**: Rewrite history to appear linear
+- **Squash and merge**: Combine all commits into a single commit
+
+Which merge strategy should we adopt for the TimeWarp Architecture repository?
+
+## Considered Options
+
+### Option 1: Squash and Merge
+* **Pros**: 
+  - "Clean" linear history appearance
+  - Single commit per feature
+  - Simplified git log presentation
+  - Popular in some development teams
+* **Cons**:
+  - **Destroys intermediate commit information permanently**
+  - Loses individual commit context and progression
+  - Makes debugging individual changes difficult
+  - Cannot easily revert specific parts of a feature
+  - Loses commit author information for individual changes
+  - Makes code review archaeology impossible
+
+### Option 2: Rebase and Merge
+* **Pros**:
+  - Linear history appearance
+  - Preserves individual commits
+  - No merge commit "clutter"
+* **Cons**:
+  - **Rewrites commit history and loses original timestamps**
+  - Destroys the actual development timeline
+  - Loses context of when branches diverged and converged
+  - Makes it difficult to understand parallel development
+  - Can be confusing for debugging when commits appear to be made in different order than reality
+
+### Option 3: Merge Commits (True Merge)
+* **Pros**:
+  - **Preserves complete historical information**
+  - Maintains actual development timeline
+  - Shows parallel development patterns
+  - Enables easy rollback of entire features
+  - Preserves merge conflict resolution context
+  - Supports better debugging and archaeological analysis
+  - Maintains commit author and timestamp integrity
+* **Cons**:
+  - Creates "busier" looking git history
+  - More merge commits in the log
+
+## Decision Outcome
+
+Chosen option: **Merge Commits (True Merge)**, because:
+
+### Information Preservation Philosophy
+* **Data over presentation**: Historical information is irreplaceable once lost, but presentation can be improved through tooling
+* **Archaeological value**: Complete history enables better debugging, code archaeology, and understanding of decision progression
+* **Rollback capabilities**: Easy to revert entire features while preserving the work for potential future reference
+
+### Practical Benefits
+* **Debugging advantages**: When investigating issues, seeing the actual development progression helps understand the thought process
+* **Parallel development visibility**: Shows how different features were developed concurrently
+* **Merge conflict context**: Preserves information about how conflicts were resolved
+* **Authentic timeline**: Maintains the actual sequence of development work
+
+### Presentation Layer Solutions
+* **Tooling handles presentation**: Modern git tools (GitHub, GitKraken, VS Code, etc.) can present history in various ways without losing underlying data
+* **Configurable views**: `git log --oneline`, `--graph`, `--first-parent` provide different presentation options
+* **IDE integration**: Development environments can show simplified views while preserving complete information
+
+## Implementation Guidelines
+
+### Pull Request Merging
+- Use GitHub's "Create a merge commit" option (not squash or rebase)
+- Maintain descriptive merge commit messages
+- Include pull request number in merge commit for traceability
+
+### Branch Cleanup
+- Delete feature branches after merging to reduce visual clutter
+- Use `git branch -d` locally after successful merge
+- Enable automatic branch deletion in GitHub repository settings
+
+### Git Commands
+```bash
+# Preferred merge approach
+git checkout master
+git merge --no-ff feature-branch
+
+# Avoid these approaches
+git merge --squash feature-branch  # Loses information
+git rebase feature-branch         # Rewrites history
+```
+
+### Presentation Tools
+When "clean" history view is desired, use:
+```bash
+# Show only merge commits
+git log --first-parent --oneline
+
+# Show simplified graph
+git log --graph --oneline --decorate
+
+# Custom format for presentations
+git log --pretty=format:"%h %s" --first-parent
+```
+
+## Positive Consequences
+
+* **Complete information preservation**: Never lose development context or progression
+* **Better debugging**: Full history available for investigating issues
+* **Flexible presentation**: Can generate any desired view from complete data
+* **Team learning**: New team members can see how features evolved
+* **Audit trail**: Complete record of what was changed and when
+
+## Negative Consequences
+
+* **Busier git log**: More commits and merge points in default git log view
+* **Team education**: Need to educate team on presentation layer tools
+* **Tool configuration**: May need to configure tools to show preferred views
+
+## Related Decisions
+
+* [ADR-0004: Branch Naming Conventions](0004-branch-naming-conventions.md) - Supports better merge commit context
+* Git workflow requires merge commits for proper branch lifecycle
+
+---
+
+*"We choose to preserve information over presentation, recognizing that lost data cannot be recovered, but presentation can always be improved through tooling."*
\ No newline at end of file
diff --git a/TimeWarp.Architecture/Documentation/Developer/Conceptual/ArchitecturalDecisionRecords/Approved/0006-kanban-development-process.md b/TimeWarp.Architecture/Documentation/Developer/Conceptual/ArchitecturalDecisionRecords/Approved/0006-kanban-development-process.md
new file mode 100644
index 000000000..55f3bc11a
--- /dev/null
+++ b/TimeWarp.Architecture/Documentation/Developer/Conceptual/ArchitecturalDecisionRecords/Approved/0006-kanban-development-process.md
@@ -0,0 +1,193 @@
+# Kanban-Based Development Process
+
+## Context and Problem Statement
+
+Development teams need a structured approach to manage tasks, track progress, and maintain visibility into work in progress. The repository currently contains two different task management approaches: a Process-based system and a Kanban-based system. These parallel systems create confusion, duplicate effort, and make it unclear which process should be followed for new work.
+
+Which task management and development process should we standardize on for the TimeWarp Architecture repository?
+
+## Considered Options
+
+### Option 1: Sprint-Based Process System
+The existing Process folder structure with:
+* **Sprint/iteration planning**: Formal iteration boundaries with per-developer folders
+* **Heavy documentation**: Definition of Done/Ready, user stories, iteration summaries
+* **Multi-developer structure**: Dedicated folders for up to 4 developers per iteration  
+* **Historical tracking**: Past iterations preserved in archive structure
+* **Traditional agile**: Formal sprint planning, review, and retrospective cycles
+
+### Option 2: GitHub Issues + Projects
+Native GitHub project management with:
+* **Issue tracking**: Rich issue templates, labels, milestones, assignees
+* **Project boards**: Kanban-style boards with automation rules
+* **Integration**: Direct link to PRs, commits, and code references
+* **Collaboration**: Comments, mentions, notifications, and external visibility
+* **Reporting**: Built-in metrics, burndown charts, and velocity tracking
+
+### Option 3: Folder-Based Kanban System
+A file-system Kanban implementation with:
+* **Simple workflow**: Backlog → ToDo → InProgress → Done folders
+* **Version controlled**: Task history tracked in git alongside code changes
+* **Self-contained**: No external dependencies or tool integration required
+* **Developer-friendly**: Uses familiar file system and markdown tools
+* **Branch integration**: Task numbers align with branch naming conventions
+* **Continuous flow**: Work moves organically through states without artificial boundaries
+* **Rapid task creation**: Can quickly capture ideas and convert to actionable tasks
+* **Zero tool overhead**: Uses familiar file system and markdown
+* **Offline capable**: Works without external dependencies
+* **Search friendly**: File-based system enables powerful text search
+* **Automation ready**: Can be scripted and automated with git hooks
+
+### Option 4: Hybrid Approach
+Combine multiple systems for different work types
+
+### Option 5: External Tool Integration
+Use dedicated project management tools (Jira, Azure DevOps, Linear, etc.)
+
+## Decision Outcome
+
+Chosen option: **Hybrid: Folder-Based Kanban + GitHub Issues**, because:
+
+### AI-Assisted Development Context
+* **Sprint obsolescence**: With AI assistance, development velocity is unpredictable and sprints become artificial constraints
+* **Continuous delivery**: AI enables rapid iteration cycles that don't align with fixed sprint boundaries
+* **Dynamic prioritization**: Work can be reprioritized instantly based on insights or blockers discovered during development
+* **Context switching optimization**: AI helps maintain context across multiple tasks, reducing traditional WIP concerns
+
+### Hybrid Approach: Best of Both Worlds
+
+**AI Tool Transparency:**
+* **File-based visibility**: Folder-based Kanban enables AI tools to easily search and understand current work state
+* **Context awareness**: AI assistants can quickly scan task files to understand project priorities and progress
+* **No API barriers**: Direct file access eliminates need for GitHub API integration for AI analysis
+* **Real-time insight**: AI tools see task evolution alongside code changes in git history
+
+**GitHub Issues for External Interface:**
+* **Public visibility**: Community contributions, bug reports, feature requests
+* **AI agent integration**: Create issues and mention AI agents (Claude, etc.) for automated work
+* **Cross-repository coordination**: Issues that span multiple repositories
+* **Stakeholder communication**: Professional interface for external collaboration
+* **Automated workflows**: AI agents can create branches, implement features, and submit PRs
+* **Rich linking**: Cross-references between issues, PRs, and commits
+* **Community engagement**: Public roadmap and transparent development process
+
+**Folder-Based Kanban for Internal Development:**
+* **Rapid iteration**: Quick task creation and management for AI-assisted development
+* **Version controlled**: Task evolution tracked alongside code changes
+* **Zero tool overhead**: Uses familiar file system and markdown
+* **Offline capable**: Works without external dependencies
+* **Branch integration**: Task numbers align perfectly with branch naming (ADR-0004)
+
+
+## Implementation Details
+
+### Hybrid Workflow
+
+**GitHub Issues for:**
+* External collaboration and community engagement
+* AI agent task assignment and automation
+* Cross-repository coordination
+* Public roadmap and feature requests
+* Bug reports from users
+
+**Folder-Based Kanban for:**
+* Internal development tasks and rapid iteration
+* AI-assisted development workflow
+* Technical debt and refactoring tasks
+* Architecture and design decisions
+* Template development and maintenance
+
+### Kanban Folder Structure
+```
+Kanban/
+├── Backlog/     # B###_task-name.md (not ready for work)
+├── ToDo/        # ###_task-name.md (ready to start)  
+├── InProgress/  # ###_task-name.md (actively being worked)
+└── Done/        # ###_task-name.md (completed)
+```
+
+### Task Lifecycle
+1. **Creation**: New tasks start in `Backlog/` with `B###_` prefix
+2. **Ready**: Move to `ToDo/` and rename to `###_` when ready to work
+3. **Active**: Move to `InProgress/` when work begins
+4. **Complete**: Move to `Done/` when work is finished
+
+### Task Numbering Convention
+* **Backlog tasks**: `B001_`, `B002_`, etc.
+* **Active tasks**: `001_`, `002_`, etc. (remove B prefix when ready)
+* **Sequential numbering**: Ensures unique identification and chronological order
+
+### Integration with Development Workflow
+* **Branch naming**: Task numbers align with branch naming (e.g., `Author/Date/Task_019`)
+* **Commit references**: Commits can reference task numbers for traceability
+* **Pull requests**: Link to task files for context and requirements
+
+### Definition of Done
+Tasks in `Done/` column must meet criteria appropriate to task type:
+
+**API Endpoints:**
+- Server: Endpoint, Handler, Validator, Mapper implemented
+- Contracts: Request, Response, RequestValidator created
+- Integration tests for Handler and Endpoint written
+- Documentation updated
+
+**Client Features:**
+- State, Actions, Components/Pages implemented
+- Integration tests (ShouldClone, ShouldSerialize) written
+- Action tests for positive cases written
+- End-to-end tests for rendering and happy paths
+
+## Template Implementation
+
+This repository template implements the hybrid approach:
+* **Kanban folders**: Provide internal development workflow structure
+* **GitHub Issues integration**: Enable external collaboration and AI agent automation
+* **Definition of Done/Ready**: Comprehensive completion criteria integrated into Kanban documentation
+* **AI transparency**: File-based system enables direct AI tool access to project state
+
+### AI Agent Integration
+
+**GitHub Issues enable powerful AI automation:**
+* **Issue creation**: Create issue describing feature or bug fix needed
+* **AI agent mention**: Comment mentioning @claude or other AI agents
+* **Automated development**: AI agent creates branch, implements solution, submits PR
+* **Code review integration**: AI agents can respond to review feedback
+* **Continuous improvement**: AI agents learn from issue patterns and solutions
+
+**Example workflow:**
+1. User creates GitHub issue: "Add dark mode toggle to settings page"
+2. Maintainer comments: "@claude please implement this feature"
+3. AI agent creates branch, implements feature, adds tests, submits PR
+4. Human reviews and merges, closing the issue automatically
+
+## Positive Consequences
+
+* **Single workflow**: Eliminates confusion about which process to follow
+* **Visual clarity**: Easy to see work distribution and bottlenecks
+* **Git integration**: Task management history preserved alongside code
+* **Developer experience**: Familiar file-based system using preferred tools
+* **Flexibility**: Can adapt to changing team size and project needs
+* **Traceability**: Clear link between tasks, branches, and delivered features
+
+## Negative Consequences
+
+* **Learning curve**: Team needs to understand Kanban principles
+* **Discipline required**: Success depends on consistent task movement and updates
+* **Limited reporting**: Fewer built-in metrics compared to dedicated project management tools
+* **Manual process**: Requires human discipline to move tasks between columns
+
+## Related Decisions
+
+* [ADR-0004: Branch Naming Conventions](0004-branch-naming-conventions.md) - Task numbers integrate with branch naming
+* [ADR-0005: Git Merge Strategy](0005-git-merge-strategy.md) - Preserves complete task development history
+
+## Future Considerations
+
+* **Automation opportunities**: Scripts to help with task movement and reporting
+* **Metrics collection**: Tools to analyze cycle time, throughput, and bottlenecks
+* **Template standardization**: Common task templates for different work types
+* **Integration possibilities**: Potential connections to CI/CD or notification systems
+
+---
+
+*"We choose a hybrid approach combining folder-based Kanban for internal development with GitHub Issues for external collaboration and AI agent integration, maximizing both development velocity and community engagement."*
\ No newline at end of file
diff --git a/TimeWarp.Architecture/Kanban/Done/023_Create-Architectural-Decision-Records.md b/TimeWarp.Architecture/Kanban/Done/023_Create-Architectural-Decision-Records.md
new file mode 100644
index 000000000..749073394
--- /dev/null
+++ b/TimeWarp.Architecture/Kanban/Done/023_Create-Architectural-Decision-Records.md
@@ -0,0 +1,69 @@
+# Task: 023 = Create Architectural Decision Records
+
+## Description
+
+Create formal Architectural Decision Records (ADRs) to document key development workflow decisions that have been made organically over time. This will provide clarity for new team members and preserve the reasoning behind current practices.
+
+## Requirements
+
+- [x] ADR-0004: Branch naming conventions 
+- [x] ADR-0005: Git merge strategy (merge vs rebase/squash)
+- [x] ADR-0006: Kanban development process (vs Process folder approach)
+- [x] Follow proper MADR format matching existing ADRs
+- [x] Place in `Documentation/Developer/Conceptual/ArchitecturalDecisionRecords/Approved/`
+
+## Acceptance Criteria
+
+- [x] All three ADRs follow the established MADR template format
+- [x] ADRs are numbered sequentially (0004, 0005, 0006)
+- [x] Each ADR includes proper context, considered options, and decision rationale
+- [x] ADRs reference each other where appropriate
+- [x] Content aligns with current repository practices
+- [x] Files are properly placed in the Approved folder
+
+## Implementation Notes
+
+### ADR Topics Covered
+
+**ADR-0004: Branch Naming Conventions**
+- Formalizes the `{Author}/{YYYY-MM-DD}/{Description}` pattern
+- Documents integration with Kanban task numbering
+- Provides clear examples and guidelines
+
+**ADR-0005: Git Merge Strategy** 
+- Documents preference for merge commits over squash/rebase
+- Emphasizes information preservation over presentation aesthetics
+- Explains how tooling can handle presentation layer concerns
+
+**ADR-0006: Kanban Development Process**
+- Documents choice of Kanban over Process folder approach
+- Explains workflow integration with git and branch naming
+- Outlines migration plan for Process folder content
+
+### Work Progress
+
+- ✅ Created all three ADR files with proper content
+- ✅ Followed MADR format matching repository standards
+- ✅ Added proper cross-references between ADRs
+- ✅ Used consistent terminology (master vs main branch)
+- ✅ Created proper branch and followed Kanban workflow
+- ✅ Committed changes following proper process
+- ✅ Updated CLAUDE.md to reference new ADRs
+
+## Related Tasks
+
+- Connects to sync workflow improvements (Task 019-022)
+- Foundation for future development process documentation
+- Supports onboarding of new team members
+
+## Status
+
+**Completed**: All ADRs created and documented
+
+**Completed Steps**:
+1. ✅ Created branch following naming convention: `Cramer/2025-06-23/Task_023`
+2. ✅ Moved task to InProgress 
+3. ✅ Committed ADR files on branch
+4. ✅ Enhanced ADRs based on feedback and comprehensive analysis
+5. ✅ Updated CLAUDE.md to reference new ADRs
+6. ✅ Ready for pull request creation and task completion
\ No newline at end of file
diff --git a/TimeWarp.Architecture/Kanban/Done/024_Migrate-To-Hybrid-Task-Management.md b/TimeWarp.Architecture/Kanban/Done/024_Migrate-To-Hybrid-Task-Management.md
new file mode 100644
index 000000000..3838f00b0
--- /dev/null
+++ b/TimeWarp.Architecture/Kanban/Done/024_Migrate-To-Hybrid-Task-Management.md
@@ -0,0 +1,67 @@
+# Task: 024 = Migrate Repository to Hybrid Task Management Approach
+
+## Description
+
+Implement the hybrid Kanban + GitHub Issues approach documented in ADR-0006 by removing the Process folder methodology and preparing repository for GitHub Issues integration.
+
+## Requirements
+
+- [x] Remove Process folder entirely (no historical preservation needed)
+- [x] Extract valuable patterns from Process folder before deletion:
+  - [x] Integrate Definition of Done into Kanban/Overview.md
+  - [x] Preserve ToastNotification.md example as task template reference
+  - [x] Extract Definition of Ready concepts
+- [x] Update template files to remove Process references
+- [x] Enable GitHub Issues with appropriate templates
+- [x] Update documentation to reflect hybrid approach
+
+## Acceptance Criteria
+
+- [x] Process folder completely removed from repository
+- [x] Kanban/Overview.md enhanced with Definition of Done/Ready
+- [x] GitHub Issues enabled with issue templates
+- [x] No references to Process methodology in template files
+- [x] ADR-0006 migration section can be removed (task completion replaces it)
+- [x] Template instances will only offer Kanban approach going forward
+
+## Implementation Notes
+
+### Process Folder Content to Extract
+
+**Definition of Done** (Process/DefinitionOfDone.md):
+- API endpoint completion criteria
+- Client feature completion criteria
+- Testing requirements
+
+**Definition of Ready** (Process/DefinitionOfReady.md):
+- Task readiness criteria
+- Prerequisites for moving to ToDo
+
+**User Story Example** (Process/Backlog/CurrentIteration/Cramer/ToastNotification.md):
+- Well-structured narrative format
+- Acceptance criteria examples
+
+### GitHub Issues Setup
+
+- Create issue templates for:
+  - Bug reports
+  - Feature requests  
+  - AI agent tasks
+- Enable GitHub Projects for public roadmap
+- Configure labels for categorization
+
+### Template Clean-up
+
+- Remove Process folder references from documentation
+- Update CLAUDE.md to reflect hybrid approach
+- Ensure new template instances only include Kanban
+
+## Related Work
+
+- Implements ADR-0006 hybrid approach decision
+- Connects to Task 023 (ADR creation)
+- Prepares foundation for AI agent integration
+
+## Status
+
+Ready to implement hybrid approach migration.
\ No newline at end of file
diff --git a/TimeWarp.Architecture/Kanban/Overview.md b/TimeWarp.Architecture/Kanban/Overview.md
index 810e379e4..db04a6e79 100644
--- a/TimeWarp.Architecture/Kanban/Overview.md
+++ b/TimeWarp.Architecture/Kanban/Overview.md
@@ -27,10 +27,78 @@ such as `B001_research-authentication-methods.md` or `B002_design-game-rules.md`
 001_002_second-level.md
 002_top-level.md
 
+## Definition of Ready
+
+Before moving a task from Backlog to ToDo, ensure it meets these criteria:
+
+### API Feature Endpoint
+- [ ] Data required by client has been defined
+- [ ] Endpoint requirements are clear
+
+### Client Feature  
+- [ ] Figma designs complete (if UI work)
+- [ ] Requirements and acceptance criteria defined
+- [ ] Dependencies identified and available
+
+## Definition of Done
+
+Tasks are considered complete when they meet the appropriate criteria:
+
+### API Endpoint
+
+**Implementation:**
+- [ ] Server
+  - [ ] *Endpoint (required)
+  - [ ] Server side only Validator  
+  - [ ] Mapper
+  - [ ] *Handler (required)
+- [ ] Api
+  - [ ] *Request (required)
+  - [ ] *Response (required) 
+  - [ ] *RequestValidator (required)
+
+**Integration Tests (Fixie):**
+- [ ] *Handler Tests (required)
+  - [ ] *Returns a valid Response given a valid Request via Handler
+- [ ] *Endpoint Tests (required)
+  - [ ] *Returns valid http Response given valid http Request via Endpoint
+  - [ ] *Should throw a validation error given invalid Request (only need to test one validation rule)
+- [ ] *RequestValidator Tests (required - test all validation rules)
+
+**Documentation:**
+- [ ] *Request class and properties (required)
+- [ ] *Response class and properties (required)
+
+### Client Feature
+
+**Implementation:**
+- [ ] *State (required)
+- [ ] Actions
+- [ ] Pipeline
+- [ ] Notification
+- [ ] Components
+- [ ] Pages
+
+**Integration Tests:**
+- [ ] State
+  - [ ] ShouldClone
+  - [ ] ShouldSerialize (To support Redux DevTools)
+- [ ] Every Action should have at least a positive test
+
+**End-to-end Tests:**
+- [ ] Test each Page can at least render without error given valid states
+- [ ] Test happy paths for each primary use case
+
+*Items marked with `*` are required. Others are optional based on feature needs.*
+
 ## Workflow
 
 1. Create an item in the Backlog folder with a short description as the filename
-2. When an item is ready to be worked on, assign it a unique identifier and move it to the ToDo folder
+2. When an item meets Definition of Ready criteria, assign it a unique identifier and move it to the ToDo folder
 3. As you work on items, move them to the InProgress folder
-4. When an item is complete, move it to the Done folder
+4. When an item meets Definition of Done criteria, move it to the Done folder
 5. Update Implementation notes as work is being done with pertinent information or references
+
+## Task Examples
+
+See `Kanban/Task-Examples/` for detailed examples of well-structured task specifications using narrative format with acceptance criteria.
diff --git a/TimeWarp.Architecture/Kanban/Task-Examples/ToastNotification-UserStory-Example.md b/TimeWarp.Architecture/Kanban/Task-Examples/ToastNotification-UserStory-Example.md
new file mode 100644
index 000000000..a3fd1a3b1
--- /dev/null
+++ b/TimeWarp.Architecture/Kanban/Task-Examples/ToastNotification-UserStory-Example.md
@@ -0,0 +1,58 @@
+# Toast Notification User Story Example
+
+*This file preserves a well-structured user story example from the Process folder as a reference for creating detailed task specifications.*
+
+## Narrative Format
+
+**As** the Architect of the web application,  
+**I want** to design a flexible notification infrastructure,  
+**So that** developers can selectively integrate various types of toast notifications for the end-user when appropriate.
+
+## Acceptance Criteria
+
+### Architectural Foundation
+
+**Given** the potential need to inform users about different system events,  
+**When** designing the notification infrastructure,  
+**Then** it should:
+
+- Be capable of handling INotification messages using MediatR in conjunction with Blazor-State
+- Integrate with FluentUI Toast for the visual representation of messages
+- Allow developers the flexibility to publish a variety of notification types as needed by the application context
+
+### Selective Notification Triggering
+
+**Given** only specific user actions may warrant a notification,  
+**When** implementing the notification logic,  
+**Then** the infrastructure should:
+
+- Provide developers with the mechanisms to decide when and what type of notifications to trigger
+- Ensure that notifications are sent only when they add value to the user experience
+
+### Configurable Notification Management
+
+**Given** the varying levels of urgency and information in notifications,  
+**When** a notification is published,  
+**Then** the infrastructure should support:
+
+- Configurations for different auto-dismissal timers, user-dismissal capabilities, and styles
+- Logic to handle multiple notifications, including their queuing and potential prioritization
+
+## Implementation Notes
+
+- The system must be modular, allowing for straightforward updates or modifications to notification types
+- Employ MediatR for loose coupling between notification dispatching and UI components
+
+## Additional Recommendations
+
+- **Throttle and Debounce Logic**: To avoid overwhelming the user, include logic to throttle and debounce notifications, especially for real-time events or progress updates
+- **Comprehensive Testing Strategy**: Devise a testing strategy that includes unit, integration, and end-to-end tests to ensure reliable notification delivery and presentation
+
+## Considerations
+
+- **Scalability**: Ensure the notification infrastructure is scalable to handle a growing number of notifications as the application expands
+- **Minimal Performance Overhead**: The notification system should introduce minimal latency and performance overhead to the user experience
+
+---
+
+*This example demonstrates how to structure complex technical requirements using the narrative format with clear acceptance criteria, implementation notes, and considerations.*
\ No newline at end of file
diff --git a/TimeWarp.Architecture/Kanban/ToDo/025_Create-File-Naming-Convention-Analysis-Report.md b/TimeWarp.Architecture/Kanban/ToDo/025_Create-File-Naming-Convention-Analysis-Report.md
new file mode 100644
index 000000000..42bd5c922
--- /dev/null
+++ b/TimeWarp.Architecture/Kanban/ToDo/025_Create-File-Naming-Convention-Analysis-Report.md
@@ -0,0 +1,55 @@
+# Task 025: Create File Naming Convention Analysis Report
+
+## Overview
+Generate a comprehensive analysis report of existing file naming conventions across the TimeWarp.Architecture project to identify inconsistencies and establish a standardized approach.
+
+## Problem Statement
+The project currently lacks a documented file naming convention, which may lead to inconsistent naming patterns across different areas of the codebase. This analysis will provide the foundation for creating an ADR and migration path to standardize file naming.
+
+## Scope
+1. **Kanban Folder Analysis**: Document existing naming patterns in the Kanban task management system
+2. **Project-wide Analysis**: Analyze file naming patterns across the entire TimeWarp.Architecture project
+3. **Consistency Evaluation**: Identify inconsistencies and patterns that need standardization
+4. **Report Generation**: Create a comprehensive report with findings and recommendations
+
+## Analysis Areas
+
+### 1. Kanban Task Files
+- Current pattern: `###_Task-Name-With-Hyphens.md` (e.g., `001_Fix-FastEndpointSourceGenerator.md`)
+- Backlog pattern: `B###_Task-Name-With-Hyphens.md` (e.g., `B001_Create-Strongly-Typed-Id-Mixin.md`)
+- Sub-task pattern: `###_###_subtask-name.md` (e.g., `004_001_convert-weatherforecast-to-fastendpoints.md`)
+
+### 2. Project Structure Files
+- Source code files (.cs)
+- Configuration files (.json, .xml, .yml)
+- Documentation files (.md)
+- Build scripts (.ps1, .sh)
+- Test files
+
+### 3. Key Patterns to Analyze
+- Case conventions (PascalCase, camelCase, kebab-case, snake_case)
+- Separator usage (hyphens, underscores, periods)
+- Numbering schemes
+- File extension conventions
+- Directory naming patterns
+
+## Deliverables
+1. **Analysis Report**: Detailed findings of current naming patterns
+2. **Inconsistency Map**: Areas where naming conventions conflict
+3. **Recommendations**: Proposed standardized naming conventions
+4. **Migration Impact**: Assessment of changes needed for consistency
+
+## Success Criteria
+- [ ] Complete inventory of file naming patterns in Kanban folder
+- [ ] Complete inventory of file naming patterns across entire project
+- [ ] Identification of all inconsistencies
+- [ ] Documented recommendations for standardization
+- [ ] Foundation established for creating ADR on file naming conventions
+
+## Follow-up Tasks
+- Create ADR for file naming conventions based on analysis
+- Develop migration plan for inconsistent files
+- Implement automated checks for naming convention compliance
+
+## Notes
+This analysis will inform the creation of a comprehensive file naming convention ADR that ensures consistency across the entire TimeWarp.Architecture ecosystem.
\ No newline at end of file
diff --git a/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Checklist.md b/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Checklist.md
deleted file mode 100644
index 741f0a435..000000000
--- a/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Checklist.md
+++ /dev/null
@@ -1,6 +0,0 @@
-# This is a sample task list
-- [x] Sample task List
-- [x] Choose Source repository host
-- [x] Create new repo 
-- [x] .editorconfig
-- [x] global.json
diff --git a/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Cramer/ToastNotification.md b/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Cramer/ToastNotification.md
deleted file mode 100644
index 2fd748f38..000000000
--- a/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Cramer/ToastNotification.md
+++ /dev/null
@@ -1,72 +0,0 @@
-Notification Infrastructure Architecture
-
-Narrative
-
-As the Architect of the web application,
-I want to design a flexible notification infrastructure,
-So that developers can selectively integrate various types of toast notifications for the end-user when appropriate.
-
-Acceptance Criteria
-
-Architectural Foundation
-
-Given the potential need to inform users about different system events,
-
-When designing the notification infrastructure,
-
-Then it should:
-
-Be capable of handling INotification messages using MediatR in conjunction with Blazor-State.
-
-Integrate with FluentUI Toast for the visual representation of messages.
-
-Allow developers the flexibility to publish a variety of notification types as needed by the application context.
-
-Selective Notification Triggering
-
-Given only specific user actions may warrant a notification,
-
-When implementing the notification logic,
-
-Then the infrastructure should:
-
-Provide developers with the mechanisms to decide when and what type of notifications to trigger.
-
-Ensure that notifications are sent only when they add value to the user experience.
-
-Configurable Notification Management
-
-Given the varying levels of urgency and information in notifications,
-
-When a notification is published
-
-Then the infrastructure should support:
-
-Configurations for different auto-dismissal timers, user-dismissal capabilities, and styles.
-
-Logic to handle multiple notifications, including their queuing and potential prioritization.
-
-Implementation Notes
-
-The system must be modular, allowing for straightforward updates or modifications to notification types.
-
-Employ MediatR for loose coupling between notification dispatching and UI components.
-
-Additional Recommendations
-
-Throttle and Debounce Logic: To avoid overwhelming the user, include logic to throttle and debounce notifications, especially for real-time events or progress updates.
-
-Comprehensive Testing Strategy: Devise a testing strategy that includes unit, integration, and end-to-end tests to ensure reliable notification delivery and presentation.
-
-Considerations
-
-Scalability: Ensure the notification infrastructure is scalable to handle a growing number of notifications as the application expands.
-
-Minimal Performance Overhead: The notification system should introduce minimal latency and performance overhead to the user experience.
-
-
-# Implementation Notes
-
-The primary error handling mechanism in the application is the ProblemDetails Notification Handler. This handler is responsible for adding Notifications to State. The ProblemDetails Notification Handler is a global handler that listens for ProblemDetails notifications and displays the error message to the user.
-
-- [ ] Implement ProblemDetails Notification Handler.
diff --git a/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Developer1/Overview.md b/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Developer1/Overview.md
deleted file mode 100644
index e69de29bb..000000000
diff --git a/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Developer2/Overview.md b/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Developer2/Overview.md
deleted file mode 100644
index e69de29bb..000000000
diff --git a/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Developer3/Overview.md b/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Developer3/Overview.md
deleted file mode 100644
index e69de29bb..000000000
diff --git a/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Developer4/Overview.md b/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Developer4/Overview.md
deleted file mode 100644
index e69de29bb..000000000
diff --git a/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Summary.md b/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Summary.md
deleted file mode 100644
index bf39dccd7..000000000
--- a/TimeWarp.Architecture/Process/Backlog/CurrentIteration/Summary.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Iteration 1 Summary
-
-Build basic process with CI and CD and placeholders.
\ No newline at end of file
diff --git a/TimeWarp.Architecture/Process/Backlog/New/NewIntroduction.md b/TimeWarp.Architecture/Process/Backlog/New/NewIntroduction.md
deleted file mode 100644
index ba986f821..000000000
--- a/TimeWarp.Architecture/Process/Backlog/New/NewIntroduction.md
+++ /dev/null
@@ -1,8 +0,0 @@
-### New Items
-
-We want to capture ideas and we want that to be real simple.
-Just create a file in the `New` folder or add to an existing one.  
-Capture as much detail as you like.
-
-As we progress we can determine file naming conventions.
-To start give it a Short title.
\ No newline at end of file
diff --git a/TimeWarp.Architecture/Process/Backlog/New/Overview.md b/TimeWarp.Architecture/Process/Backlog/New/Overview.md
deleted file mode 100644
index e69de29bb..000000000
diff --git a/TimeWarp.Architecture/Process/Backlog/Past/Iteration1/Overview.md b/TimeWarp.Architecture/Process/Backlog/Past/Iteration1/Overview.md
deleted file mode 100644
index e69de29bb..000000000
diff --git a/TimeWarp.Architecture/Process/Backlog/Past/PastIntroduction.md b/TimeWarp.Architecture/Process/Backlog/Past/PastIntroduction.md
deleted file mode 100644
index d35a0dcba..000000000
--- a/TimeWarp.Architecture/Process/Backlog/Past/PastIntroduction.md
+++ /dev/null
@@ -1,3 +0,0 @@
-### Past Iterations
-
-This folder will contain the previous itterations items.
diff --git a/TimeWarp.Architecture/Process/Backlog/Ready/ReadyIntroduction.md b/TimeWarp.Architecture/Process/Backlog/Ready/ReadyIntroduction.md
deleted file mode 100644
index 03a58dcd3..000000000
--- a/TimeWarp.Architecture/Process/Backlog/Ready/ReadyIntroduction.md
+++ /dev/null
@@ -1,4 +0,0 @@
-### Ready Items
-
-This folder will contain the Items we think are Ready to be worked on.
-In either a single md file with checklists or multiple folders and files.
\ No newline at end of file
diff --git a/TimeWarp.Architecture/Process/DefinitionOfDone.md b/TimeWarp.Architecture/Process/DefinitionOfDone.md
deleted file mode 100644
index 0bf4baff8..000000000
--- a/TimeWarp.Architecture/Process/DefinitionOfDone.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Defintion of Done
-
-`*` indicates required.
-
-## Api Endpoint
-
-- [ ] Implementation
-  - [ ] Server
-    - [ ] *Endpoint
-    - [ ] Server side only Validator
-    - [ ] Mapper 
-    - [ ] *Handler 
-  - [ ] Api
-    - [ ] *Request
-    - [ ] *Response
-    - [ ] *RequestValidator
-- [ ] Integration Tests (Fixie)
-  - [ ] *Handler Tests
-    - [ ] *returns a valid Response given a valid Request via Handler
-  - [ ] *Endpoint Tests
-    - [ ] *returns valid http Response given valid http Request via Endpoint
-    - [ ] *Should throw a validation error given invalid Request (only need to test one validation rule)
-  - [ ] *RequestValidator Tests (Test all validation rules)
-
-- [ ] Documentation
-  - [ ] *Request class and properties
-  - [ ] *Response class and properties
-
-## Client Feature
-- [ ] Implementation
-  - [ ] *State
-  - [ ] Actions
-  - [ ] Pipeline
-  - [ ] Notification
-  - [ ] Components
-  - [ ] Pages
-- [ ] Integration Tests
-  - [ ] State
-    - [ ] ShouldClone
-    - [ ] ShouldSerialize (To support Redux DevTools)
-  - [ ] Every Action should have at least a positive test
-- [ ] End-to-end Tests
-  - [ ] Test each Page can at least render without error given valid states.
-  - [ ] Test happy paths for each primary use case.
-
diff --git a/TimeWarp.Architecture/Process/DefinitionOfReady.md b/TimeWarp.Architecture/Process/DefinitionOfReady.md
deleted file mode 100644
index 6a378abd4..000000000
--- a/TimeWarp.Architecture/Process/DefinitionOfReady.md
+++ /dev/null
@@ -1,14 +0,0 @@
-# Definition of Ready (TODO)
-
-## Figma Designs
-
-- [ ] 
-
-## API Feature Endpoint
-
-- [ ] Data Required by Client has been defined
-
-
-## Client Feature
-
-- [ ] Figma Designs complete
diff --git a/TimeWarp.Architecture/Process/ProcessIntroduction.md b/TimeWarp.Architecture/Process/ProcessIntroduction.md
deleted file mode 100644
index 5df8387c6..000000000
--- a/TimeWarp.Architecture/Process/ProcessIntroduction.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# The TimeWarp Software Development Process
-
-## Features of the process
-
-* Get started quickly
-* Highly customizable
-* Simple
-
-## Current Drawbacks
-
-* No reporting
-* No Burndown charts
-* Search by text files
-
-@import "Backlog/BacklogIntroduction.md"