initializing the code rules

CSHARP_FORMATTING.md

@@ -0,0 +1,18 @@
+# C#/.NET Formatting
+When writing an `if` condition, always wrap the content of the `if` condition in `{` and `}`.
+
+For example:
+
+Instead of the following:
+```csharp
+if (value == 123)
+    Console.WriteLine("It's 123");
+```
+
+Write the following instead:
+```csharp
+if (value == 123)
+{
+    Console.WriteLine("It's 123");
+}
+```

GITEA.md

@@ -0,0 +1,47 @@
+# Gitea
+
+Gitea runner's function exactly the same as GitHub runners. They're just stored in the .gitea folder instead of .github folder.
+
+## Ramblingcoder Gitea
+
+There is a private Gitea repository that docker images are pushed too. This is an example of a gitea action that creates and pushes an image.
+
+The image `gitea-runner-custom-image` has docker and docker-compose pre-installed.
+
+```yaml
+name: Build and Push Docker Image
+
+on:
+  push:
+    branches: [ master ]
+  pull_request:
+    branches: [ master ]
+  workflow_dispatch:
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    container:
+      image: git.ramblingcoder.com/ramblingcoder/gitea-runner-custom-image:latest
+      credentials:
+        username: ${{ secrets.GIT_USERNAME }}
+        password: ${{ secrets.GIT_PASSWORD }}
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Login to Docker Registry
+        uses: https://git.ramblingcoder.com/Mirror.Actions/docker-login-action@v3
+        with:
+          registry: git.ramblingcoder.com
+          username: ${{ secrets.GIT_USERNAME }}
+          password: ${{ secrets.GIT_PASSWORD }}
+
+      - name: Build Image
+        run: |
+          docker build -t git.ramblingcoder.com/ramblingcoder/REPLACETHIS -f docker/Dockerfile .
+
+      - name: Push Image
+        run: docker push git.ramblingcoder.com/ramblingcoder/REPLACETHIS
+```

MEMORY_BANK.md

@@ -0,0 +1,115 @@
+# Memory Bank
+
+I am an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.
+
+## Memory Bank Structure
+
+The Memory Bank consists of core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:
+
+flowchart TD
+    PB[projectbrief.md] --> PC[productContext.md]
+    PB --> SP[systemPatterns.md]
+    PB --> TC[techContext.md]
+
+    PC --> AC[activeContext.md]
+    SP --> AC
+    TC --> AC
+
+    AC --> P[progress.md]
+
+### Core Files (Required)
+1. `projectbrief.md`
+   - Foundation document that shapes all other files
+   - Created at project start if it doesn't exist
+   - Defines core requirements and goals
+   - Source of truth for project scope
+
+2. `productContext.md`
+   - Why this project exists
+   - Problems it solves
+   - How it should work
+   - User experience goals
+
+3. `activeContext.md`
+   - Current work focus
+   - Recent changes
+   - Next steps
+   - Active decisions and considerations
+   - Important patterns and preferences
+   - Learnings and project insights
+
+4. `systemPatterns.md`
+   - System architecture
+   - Key technical decisions
+   - Design patterns in use
+   - Component relationships
+   - Critical implementation paths
+
+5. `techContext.md`
+   - Technologies used
+   - Development setup
+   - Technical constraints
+   - Dependencies
+   - Tool usage patterns
+
+6. `progress.md`
+   - What works
+   - What's left to build
+   - Current status
+   - Known issues
+   - Evolution of project decisions
+
+### Additional Context
+Create additional files/folders within memory-bank/ when they help organize:
+- Complex feature documentation
+- Integration specifications
+- API documentation
+- Testing strategies
+- Deployment procedures
+
+## Core Workflows
+
+### Plan Mode
+flowchart TD
+    Start[Start] --> ReadFiles[Read Memory Bank]
+    ReadFiles --> CheckFiles{Files Complete?}
+
+    CheckFiles -->|No| Plan[Create Plan]
+    Plan --> Document[Document in Chat]
+
+    CheckFiles -->|Yes| Verify[Verify Context]
+    Verify --> Strategy[Develop Strategy]
+    Strategy --> Present[Present Approach]
+
+### Act Mode
+flowchart TD
+    Start[Start] --> Context[Check Memory Bank]
+    Context --> Update[Update Documentation]
+    Update --> Execute[Execute Task]
+    Execute --> Document[Document Changes]
+
+## Documentation Updates
+
+Memory Bank updates occur when:
+1. Discovering new project patterns
+2. After implementing significant changes
+3. When user requests with **update memory bank** (MUST review ALL files)
+4. When context needs clarification
+
+flowchart TD
+    Start[Update Process]
+
+    subgraph Process
+        P1[Review ALL Files]
+        P2[Document Current State]
+        P3[Clarify Next Steps]
+        P4[Document Insights & Patterns]
+
+        P1 --> P2 --> P3 --> P4
+    end
+
+    Start --> Process
+
+Note: When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on activeContext.md and progress.md as they track current state.
+
+REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.

SUPPORTING_DOCS.md

@@ -0,0 +1,30 @@
+# Supporting Documents and Samples
+
+Supporting documents and example documents are provided in folders that begin with `supporting_` in the workspace root folder.
+
+## Purpose
+
+These folders contain reference materials, examples, templates, and documentation that support development but are not part of the active codebase. They provide context, patterns, and samples that help with implementation decisions.
+
+## When to Use
+
+An LLM agent should reference supporting documents when:
+- Looking for implementation patterns or examples
+- Needing template code or configuration samples
+- Understanding architectural decisions or design documents
+- Finding API specifications or integration guides
+- Reviewing documentation for existing systems or protocols
+
+## Examples of Supporting Documents
+
+- Template configurations
+- Code samples and examples
+- API documentation
+- Architecture diagrams
+- Design documents
+- Integration guides
+- Reference implementations
+
+## How to Reference
+
+When working on tasks that may benefit from supporting documentation, proactively search for relevant `supporting_*` folders and read the relevant files. Use these documents as reference to ensure consistency with existing patterns and approaches.

TMP_DIR.md

@@ -0,0 +1,3 @@
+# TMP Directory
+
+Writes intended for the /tmp directory should instead use a tmp folder in the workspace's directory.