ananlytzer

.forgejo/workflows/agent-development.yml

@@ -30,7 +30,15 @@ jobs:
           python3 --version
           pip3 --version
           bash --version || echo "bash check failed"
-      
+
+      - name: Cache Flutter
+        uses: actions/cache@v4
+        with:
+          path: /opt/flutter
+          key: flutter-3.35.5
+          restore-keys: |
+            flutter-
+
       - name: Install Flutter 3.35.5
         run: |
           if [ ! -d /opt/flutter/bin ]; then

ai_docs/agent/prompts/development_prompt.md

@@ -83,6 +83,9 @@ lib/
 - Follow existing code patterns in the project
 - Use proper error handling
 - Add logging where appropriate
+- **Keep changes small**: Maximum 500 changed lines per task/commit
+  - If a task requires more changes, break it into smaller subtasks
+  - This ensures better code review and reduces risk of introducing bugs
 
 ### 3. Testing Phase
 - Write unit tests for all new code
@@ -114,6 +117,7 @@ lib/
 - Ignore linter warnings
 - Copy code without understanding it
 - Make changes outside the task scope
+- **Exceed 500 changed lines** in a single task/commit (break large tasks into smaller ones)
 
 ## API v2 Guidelines (Backend/Frontend)
 
@@ -244,6 +248,8 @@ Your commits will be automatically created. Make sure your changes are:
 - **Complete**: All files needed for the feature
 - **Tested**: All tests pass
 - **Clean**: Linter passes
+- **Size-limited**: Maximum 500 changed lines per commit
+  - If changes exceed this limit, split the work into multiple commits/tasks
 
 ## Reference Materials
 

ai_docs/agent/prompts/planning_prompt.md

@@ -28,6 +28,8 @@ Review these files to understand current state:
 
 ## Task Generation Guidelines
 
+**Golden Rule: Keep tasks small!** If you find yourself creating a task that seems large or complex, break it down into smaller, focused subtasks. Small tasks are easier to understand, implement, test, and verify.
+
 ### Task Structure
 
 Each task should have:
@@ -56,9 +58,18 @@ Each task should have:
 
 ### Task Sizing
 
-- **Small tasks** (2-4 hours): Single feature or bug fix
+**CRITICAL: Tasks must be small and focused. Large tasks MUST be broken down into smaller subtasks.**
-- **Medium tasks** (4-8 hours): Feature with multiple files
+
-- **Large tasks** (8+ hours): Break into smaller subtasks
+- **Small tasks** (1-3 hours): Single feature or bug fix - **PREFERRED SIZE**
+- **Medium tasks** (4-5 hours): Feature with multiple files - **ACCEPTABLE, but prefer smaller**
+- **Large tasks** (6+ hours): **MUST be broken down** into smaller subtasks before adding to task list
+
+**Task Decomposition Rules:**
+- If a task exceeds 6 hours, it MUST be split into multiple smaller tasks
+- Each subtask should be independently testable and completable
+- Subtasks should have clear dependencies between them
+- Aim for tasks that can be completed in 2-4 hours whenever possible
+- Large features should be broken into: foundation → implementation → integration → testing phases
 
 ### Priority Guidelines
 
@@ -159,6 +170,7 @@ When a task in one component depends on another:
 - Identify dependencies between tasks
 - Determine component ownership
 - Estimate effort for each task
+- **Break down large tasks** (6+ hours) into smaller subtasks before proceeding
 
 ### 3. Prioritization Phase
 
@@ -248,10 +260,11 @@ Before finalizing task list:
 1. ✅ All tasks have unique IDs
 2. ✅ Dependencies are valid (tasks exist)
 3. ✅ Priorities are balanced (not all high)
-4. ✅ Estimates are reasonable (2-8 hours)
+4. ✅ **All tasks are small (2-6 hours max)** - large tasks have been broken down
-5. ✅ Acceptance criteria are specific
+5. ✅ Estimates are reasonable (2-6 hours preferred, 6-8 hours acceptable only if cannot be split)
-6. ✅ Files to modify are listed
+6. ✅ Acceptance criteria are specific
-7. ✅ No circular dependencies
+7. ✅ Files to modify are listed
+8. ✅ No circular dependencies
 
 ## Iteration Strategy
 
@@ -271,7 +284,7 @@ After generating task list:
 
 ---
 
-**Remember**: Your task list drives autonomous development. Make tasks clear, actionable, and achievable. A well-defined task list leads to successful autonomous execution.
+**Remember**: Your task list drives autonomous development. Make tasks clear, actionable, and achievable. **Keep tasks small** - if a task seems too large, break it down. A well-defined task list with small, focused tasks leads to successful autonomous execution.
 
 Good luck! 🎯
 

mnemo_cards_backend/analysis_options.yaml

@@ -21,6 +21,9 @@ linter:
   # `// ignore_for_file: name_of_lint` syntax on the line or in the file
   # producing the lint.
   rules:
+    # Prefer relative imports
+    always_use_package_imports: false
+    avoid_relative_lib_imports: false
     # avoid_print: false  # Uncomment to disable the `avoid_print` rule
     # prefer_single_quotes: true  # Uncomment to enable the `prefer_single_quotes` rule
 

mnemo_cards_common/analysis_options.yaml

@@ -1,4 +1,10 @@
 include: package:flutter_lints/flutter.yaml
 
+linter:
+  rules:
+    # Prefer relative imports
+    always_use_package_imports: false
+    avoid_relative_lib_imports: false
+
 # Additional information about this file can be found at
 # https://dart.dev/guides/language/analysis-options

mnemo_cards_common_backend/analysis_options.yaml

@@ -15,9 +15,11 @@ include: package:lints/recommended.yaml
 
 # Uncomment the following section to specify additional rules.
 
-# linter:
+linter:
-#   rules:
+  rules:
-#     - camel_case_types
+    # Prefer relative imports
+    always_use_package_imports: false
+    avoid_relative_lib_imports: false
 
 # analyzer:
 #   exclude:

mnemo_cards_frontend_common/analysis_options.yaml

@@ -1,4 +1,10 @@
 include: package:flutter_lints/flutter.yaml
 
+linter:
+  rules:
+    # Prefer relative imports
+    always_use_package_imports: false
+    avoid_relative_lib_imports: false
+
 # Additional information about this file can be found at
 # https://dart.dev/guides/language/analysis-options

mnemo_cards_web_v2/analysis_options.yaml

@@ -43,9 +43,9 @@ linter:
     type_annotate_public_apis: true
     
     # Code quality
-    always_use_package_imports: true
+    always_use_package_imports: false  # Prefer relative imports
     avoid_empty_else: true
-    avoid_relative_lib_imports: true
+    avoid_relative_lib_imports: false  # Allow relative imports
     avoid_slow_async_io: true
     cancel_subscriptions: true
     close_sinks: true