move docs to docs/ folder, merge architecture files, update references

docs/AGENTS.md

@@ -0,0 +1,70 @@
+# MosisService Agent Guidelines
+
+## Build, Lint, and Test Commands
+
+### Build Commands
+- `./gradlew build` - Build the entire project
+- `./gradlew assembleDebug` - Build debug version
+- `./gradlew assembleRelease` - Build release version
+- `./gradlew clean` - Clean build outputs
+- `./gradlew :app:build` - Build specific module (if needed)
+
+### Lint Commands
+- `./gradlew lint` - Run lint checks
+- `./gradlew lintDebug` - Run lint for debug build
+- `./gradlew lintRelease` - Run lint for release build
+
+### Test Commands
+- `./gradlew test` - Run unit tests
+- `./gradlew connectedAndroidTest` - Run connected device tests
+- `./gradlew testDebugUnitTest` - Run debug unit tests
+- `./gradlew testReleaseUnitTest` - Run release unit tests
+- `./gradlew :app:test` - Run tests for specific module
+- `./gradlew :app:testDebugUnitTest` - Test specific module debug unit tests
+
+**Important Note:** The project contains C++ native code that uses CMake with both `mosis-service` and `mosis-test` libraries defined in `CMakeLists.txt`. Tests are built as shared libraries with the suffix `.so`.
+
+## Code Style Guidelines
+
+### Naming Conventions
+- `PascalCase` for class and function names (e.g., `MosisService`, `RenderTexture`)
+- `camelCase` for variables and parameters (e.g., `renderTarget`, `inputData`)
+- `UPPER_CASE` for constants (e.g., `MAX_BUFFER_SIZE`, `DEFAULT_TIMEOUT`)
+- Class names should be descriptive and follow Android naming conventions (e.g., `MosisService`)
+- Files should use meaningful names that match their content
+
+### Imports & Formatting
+- Import statements are grouped logically: Android imports, third-party imports, first-party imports
+- Imports are sorted alphabetically within each group
+- Use of fully qualified names is allowed for clarity when needed
+
+### Types & Variables
+- Use primitive types when possible
+- Use `final` keyword for constants
+- Prefer `val` over `var` in Kotlin
+- Use `final` for native C++ variables that don't change
+- Use appropriate data types (int, long, float, double) based on precision requirements
+
+### Error Handling
+- C++ code uses standard C++ exception handling
+- Android code leverages standard Android error handling patterns
+- Use try-catch blocks appropriately in Kotlin code
+- Log errors via Android's logging framework in Kotlin
+- C++ logging via `logger.cpp` component
+
+### Coding Standards
+- Follow Android development best practices
+- C++ code should follow modern C++23 conventions (including use of std::span, std::format, etc.)
+- Use RAII (Resource Acquisition Is Initialization) principles in C++
+- Ensure memory management is handled properly in native code
+- Avoid magic numbers in C++ code - use constants instead
+- Use smart pointers like `std::unique_ptr` and `std::shared_ptr` where appropriate
+- Proper resource cleanup in destructors
+- Avoid memory leaks in C++ components
+
+### Structure
+- Kotlin code following Android project structures
+- C++ code organized in separate files within `src/main/cpp/`
+- Clear separation between platform-specific code and shared logic
+- Use Android build system capabilities for multi-architecture support
+- Follow Gradle conventions for dependency management