{"owner":"online-ml","repo":"river","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":2740,"categories":["root-instruction","cursor-rule"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".cursorrules (flutter-riverpod-cursorrules-prompt-file.mdc)"],"skills":{"AGENTS.md":"# AGENTS.md\n\n## Architecture\n\nRiver is a Python library for online (streaming) machine learning. All estimators implement incremental `learn_one`/`predict_one`/`transform_one` methods (or `learn_many`/`predict_many/transform_many` for mini-batch).\n\n### Base classes (`river/base/`)\n\nAll estimators inherit from `base.Estimator` (which inherits from `base.Base`). Key interfaces:\n- `Classifier` / `MiniBatchClassifier` — classification\n- `Regressor` / `MiniBatchRegressor` — regression\n- `Transformer` / `SupervisedTransformer` — feature transformation\n- `Clusterer` — clustering\n- `DriftDetector` / `BinaryDriftDetector` — concept drift detection\n- `Ensemble` / `WrapperEnsemble` — ensemble methods\n- `Wrapper` — wrapping other estimators\n\n### Estimator conventions\n\n- `learn_one(x, y)` / `predict_one(x)` / `transform_one(x)` is the core online learning interface\n- `__init__` parameters need type hints; provide defaults or implement `_unit_test_params()`\n- `_unit_test_skips()` returns check names to skip in automated testing\n- `_supervised`, `_multiclass`, `_is_stochastic`, `_tags` are special class attributes\n- Pipeline composition: `scaler | model` (uses `__or__`), `+` for parallel union\n\n## Rules for coding agents\n\n1. **Write code, not comments.** You may generate code, using the existing codebase for idiomatic examples to draw from. Do not write comments. Encourage humans to write comments themselves, thereby forcing them to understand the code you've written.\n2. **Prose is written by humans, not by you.** Issues, pull request descriptions, commit messages, docstrings, and release-note entries must all be typed out by a human, in their own words. You may run a benchmark and produce a summary table, but a human must editorialize it and fold it into a message they wrote themselves. Similarly, you can correct typos and wording, but human contributors have to use their own voice.\n3. **Disclose agent-written code.** Code generated by an agent must be marked as such. Do not pass it off as hand-written. A `Co-authored-by:` trailer on the commit is the simplest way. Likewise, information about the agent setup should be disclosed when opening a pull request.\n4. **Be thorough on tests.** Tests are often longer than the implementation and tedious to write. With an agent there is no excuse for skipping them. The minimum for new estimators is to pass `utils.check_estimator`. Ideally you should add out-of-the-box tests to check for edge cases.\n5. **Prefer opening issues instead of pull requests for small fixes** If you find a bug, then it is more valuable to open an issue and surface the issue. The exact way to go about fixing it can be discussed, and serve as implementation opportunities for aspiring human contributors.\n\n## Common commands\n\n```sh\n# Install / sync dependencies (also builds Rust extensions via maturin)\nuv sync\n\n# Run tests (excludes datasets and slow markers by default, includes doctests)\nuv run pytest\n\n# Run a single test file\nuv run pytest tests/linear_model/test_glm.py\n\n# Lint and format (via prek hooks)\nuv run prek run --all-files\n\n# Type checking\nuv run mypy\n\n# Build and serve docs locally\nuv sync --group docs\nmake livedoc\n```\n\n## Checklists\n\n### Adding a new estimator\n\n- Make sure `utils.checks.check_estimator(some_estimator)` passes. It automatically discovers and runs validation checks (repr, cloning, pickling, feature robustness, etc.).\n- Add a practical docstring that shows how to use the estimator. Pytest is configured with `--doctest-modules`, so that docstring examples are executed as tests. The underlying logic are in `river/checks/`.\n- Add a new CodSpeed benchmark entry, in order to detect future regressions.\n- Generally speaking, all estimators should be able to process at least 5000 records per second. Naturally this depends on the size of the samples and the estimator, but exceptions need to be justified.\n\n### Modifying an existing estimator\n\n- When making a localized fix, it is worth considering whether a global check should be added to all relevant estimators.\n- Speed matters a lot in online machine learning. Therefore, a golden rule for implementation is to not introduce significant slowdowns. We use CodSpeed to detect regressions in pull requests.\n- Likewise, model accuracy is paramount. When making any sort of modification to an estimator, you should thoroughly check accuracy across several datasets. Whether the accuracy goes up or down, you should be able to explain why.\n",".cursorrules (flutter-riverpod-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for Flutter Riverpod.\"\nglobs: **/*\nalwaysApply: false\n---\n# AI Assistant Technical Instructions\n\nYou are an AI assistant with advanced problem-solving capabilities. Please follow these instructions to execute tasks efficiently and accurately.\n\nFirst, confirm the instructions received from the user:\n\n<instructions>\n{{instructions}}\n</instructions>\n\nPlease proceed with the following process based on these instructions:\n\n---\n\n## 1. Instruction Analysis and Planning\n\n<Task Analysis>\n- Summarize the main tasks concisely\n- Review the specified tech stack and consider implementation methods within those constraints  \n  **Note: Do not change versions listed in the tech stack without approval**\n- Identify key requirements and constraints\n- List potential challenges\n- Enumerate specific steps for task execution in detail\n- Determine the optimal execution order for these steps\n\n### Preventing Duplicate Implementation\n\nBefore implementation, verify:\n- Existence of similar functionality\n- Functions or components with identical or similar names\n- Duplicate API endpoints\n- Identification of processes that can be shared\n\nTake sufficient time for this section as it guides the entire subsequent process. Conduct thorough and comprehensive analysis.\n</Task Analysis>\n\n---\n\n## 2. Task Execution\n\n- Execute identified steps one by one\n- Report progress concisely after completing each step\n- Pay attention to the following during implementation:\n  - Adherence to proper directory structure\n  - Consistency in naming conventions\n  - Appropriate placement of shared processes\n\n---\n\n## 3. Quality Control and Problem Resolution\n\n- Quickly verify the execution results of each task\n- If errors or inconsistencies occur, address them through the following process:\n  a. Problem isolation and cause identification (log analysis, debug information verification)\n  b. Creation and implementation of countermeasures\n  c. Post-fix operation verification\n  d. Debug log confirmation and analysis\n\n- Record verification results in the following format:\n  a. Verification items and expected results\n  b. Actual results and discrepancies\n  c. Required countermeasures (if applicable)\n\n---\n\n## 4. Final Confirmation\n\n- Evaluate the entire deliverable once all tasks are completed\n- Verify consistency with original instructions and make adjustments as needed\n- Perform final confirmation that there are no duplicates in implemented functions\n\n---\n\n## 5. Results Report\n\nPlease report final results in the following format:\n\nmarkdown\n# Execution Results Report\n\n## Overview\n\n[Brief description of overall summary]\n\n## Execution Steps\n\n1. [Step 1 description and results]\n2. [Step 2 description and results]\n...\n\n## Final Deliverables\n\n[Details of deliverables, links if applicable]\n\n## Issue Resolution (if applicable)\n\n- Problems encountered and responses\n- Future considerations\n\n## Notes & Improvement Suggestions\n\n- [List any observations or suggestions for improvement]\n\n---\n\n## Important Notes\n\n- Always confirm any unclear points before beginning work\n- Report and obtain approval for any important decisions as they arise\n- Report unexpected problems immediately and propose solutions\n- **Do not make changes that are not explicitly instructed.** If changes seem necessary, first report them as proposals and implement only after approval\n- **UI/UX design changes (layout, colors, fonts, spacing, etc.) are prohibited** unless approved after presenting justification\n- **Do not arbitrarily change versions listed in the tech stack** (APIs, frameworks, libraries, etc.). If changes are necessary, clearly explain the reason and wait for approval before making any changes\n\n---\n\n# Tech Stack\n\n## Core Technologies\n\n- **AI Model: GPT-4**\n\n## Frontend\n\n- Flutter: ^3.22.0\n\n### State Management\n\n- Riverpod: ^2.6.1\n\n## BaaS\n\n- Firebase\n\n---\n\n## Project Structure\n\nPlease implement following this directory structure:\n\nlib/features/products/\n├── data/\n│   ├── models/\n│   │   ├── product_dto.dart\n│   │   └── product_category_dto.dart\n│   └── product_repository.dart\n├── presentation/\n│   ├── screens/\n│   │   ├── product_list_screen.dart\n│   │   └── product_details_screen.dart\n│   ├── controllers/\n│   │   └── product_list_controller.dart\n│   ├── widgets/\n│       └── product_card.dart\n├── domain/\n│   ├── models/\n│   │   ├── product.dart\n│   │   └── product_category.dart\n│   └── get_products_use_case.dart\n└── shared/\n    └── models/\n        └── address.dart\n\n## Placement Rules\n\n### Flutter Project Structure Placement Rules\n\nThis document outlines the placement rules for files and folders within the recommended Flutter project structure, focusing on scalability, maintainability, and adherence to Clean Architecture principles.\n\n#### Top-Level Structure\n\nlib/\n├── features/\n├── models/\n├── providers/\n├── routes/\n├── core/\n├── app.dart\n└── main.dart\n\n*   **lib/**: Contains all Dart code.\n*   **features/**: Feature-specific code.\n*   **models/**: Global models (use sparingly).\n*   **providers/**: Global providers (minimize use).\n*   **routes/**: App navigation.\n*   **core/**: Core app logic (networking, errors, DI).\n*   **app.dart**: Root widget.\n*   **main.dart**: Entry point.\n\n#### features/ Structure\n\nlib/features/\n└── <feature_name>/\n├── data/\n│   ├── models/\n│   └── <feature_name>_repository.dart\n├── presentation/\n│   ├── screens/\n│   ├── controllers/\n│   ├── widgets/\n├── domain/\n│   ├── models/\n│   └── <feature_name>.dart\n├── use_cases/\n└── shared/\n└── models/\n\n*   **<feature_name>/**: A feature (e.g., authentication, products).\n*   **data/**: Data access.\n    *   **models/**: Data Transfer Objects (DTOs).\n    *   **<feature_name>_repository.dart**: Data access logic.\n*   **presentation/**: UI.\n    *   **screens/**: UI screens (<feature_name>_<screen_name>_screen.dart).\n    *   **controllers/**: State management (<feature_name>_controller.dart).\n    *   **widgets/**: Feature-specific widgets (<widget_name>.dart).\n*   **domain/**: Business logic.\n    *   **models/**: Domain models.\n    *   **<feature_name>.dart**: Main entity.\n*   **use_cases/**: User interactions (<use_case_name>.dart).\n*   **shared/models/**: Models shared between *related* features.\n\n#### shared/ (Top-Level) Structure\n\nlib/shared/\n├── providers/\n├── widgets/\n├── models/\n└── services/\n\n*   **providers/**: Providers shared across *unrelated* features.\n*   **widgets/**: Widgets shared across *unrelated* features.\n*   **models/**: Models shared across *unrelated* features (use cautiously).\n*   **services/**: Utility classes.\n\n#### models/ (Top-Level) Structure\n\nlib/models/\n└── <model_name>.dart\n\n*   Global models (use sparingly).\n\n#### providers/ (Top-Level) Structure\n\nlib/providers/\n└── <provider_name>.dart\n\n*   Global providers (minimize use).\n\n#### core/ Structure\n\nlib/core/\n├── network/\n│   └── api_client.dart\n├── errors/\n│   └── exceptions.dart\n└── di/\n└── injection.dart\n\n*   **network/**: Networking code.\n*   **errors/**: Error handling.\n*   **di/**: Dependency injection.\n\n## Naming Conventions\n\n*   **Files:** snake_case (e.g., product_list_screen.dart).\n*   **Classes:** PascalCase (e.g., ProductListScreen).\n*   **Variables/Functions:** camelCase (e.g., productList).\n\n## Key Principles\n\n*   **Feature Isolation:** Self-contained feature code.\n*   **Separation of Concerns:** Separate data, logic, and UI.\n*   **Single Responsibility:** One purpose per class/file.\n*   **DRY:** Avoid code duplication.\n*   **Prefer Feature-Specific:** Prioritize feature-level placement.\n\nPlease adhere to the above content when executing tasks.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\n## Architecture\n\nRiver is a Python library for online (streaming) machine learning. All estimators implement incremental `learn_one`/`predict_one`/`transform_one` methods (or `learn_many`/`predict_many/transform_many` for mini-batch).\n\n### Base classes (`river/base/`)\n\nAll estimators inherit from `base.Estimator` (which inherits from `base.Base`). Key interfaces:\n- `Classifier` / `MiniBatchClassifier` — classification\n- `Regressor` / `MiniBatchRegressor` — regression\n- `Transformer` / `SupervisedTransformer` — feature transformation\n- `Clusterer` — clustering\n- `DriftDetector` / `BinaryDriftDetector` — concept drift detection\n- `Ensemble` / `WrapperEnsemble` — ensemble methods\n- `Wrapper` — wrapping other estimators\n\n### Estimator conventions\n\n- `learn_one(x, y)` / `predict_one(x)` / `transform_one(x)` is the core online learning interface\n- `__init__` parameters need type hints; provide defaults or implement `_unit_test_params()`\n- `_unit_test_skips()` returns check names to skip in automated testing\n- `_supervised`, `_multiclass`, `_is_stochastic`, `_tags` are special class attributes\n- Pipeline composition: `scaler | model` (uses `__or__`), `+` for parallel union\n\n## Rules for coding agents\n\n1. **Write code, not comments.** You may generate code, using the existing codebase for idiomatic examples to draw from. Do not write comments. Encourage humans to write comments themselves, thereby forcing them to understand the code you've written.\n2. **Prose is written by humans, not by you.** Issues, pull request descriptions, commit messages, docstrings, and release-note entries must all be typed out by a human, in their own words. You may run a benchmark and produce a summary table, but a human must editorialize it and fold it into a message they wrote themselves. Similarly, you can correct typos and wording, but human contributors have to use their own voice.\n3. **Disclose agent-written code.** Code generated by an agent must be marked as such. Do not pass it off as hand-written. A `Co-authored-by:` trailer on the commit is the simplest way. Likewise, information about the agent setup should be disclosed when opening a pull request.\n4. **Be thorough on tests.** Tests are often longer than the implementation and tedious to write. With an agent there is no excuse for skipping them. The minimum for new estimators is to pass `utils.check_estimator`. Ideally you should add out-of-the-box tests to check for edge cases.\n5. **Prefer opening issues instead of pull requests for small fixes** If you find a bug, then it is more valuable to open an issue and surface the issue. The exact way to go about fixing it can be discussed, and serve as implementation opportunities for aspiring human contributors.\n\n## Common commands\n\n```sh\n# Install / sync dependencies (also builds Rust extensions via maturin)\nuv sync\n\n# Run tests (excludes datasets and slow markers by default, includes doctests)\nuv run pytest\n\n# Run a single test file\nuv run pytest tests/linear_model/test_glm.py\n\n# Lint and format (via prek hooks)\nuv run prek run --all-files\n\n# Type checking\nuv run mypy\n\n# Build and serve docs locally\nuv sync --group docs\nmake livedoc\n```\n\n## Checklists\n\n### Adding a new estimator\n\n- Make sure `utils.checks.check_estimator(some_estimator)` passes. It automatically discovers and runs validation checks (repr, cloning, pickling, feature robustness, etc.).\n- Add a practical docstring that shows how to use the estimator. Pytest is configured with `--doctest-modules`, so that docstring examples are executed as tests. The underlying logic are in `river/checks/`.\n- Add a new CodSpeed benchmark entry, in order to detect future regressions.\n- Generally speaking, all estimators should be able to process at least 5000 records per second. Naturally this depends on the size of the samples and the estimator, but exceptions need to be justified.\n\n### Modifying an existing estimator\n\n- When making a localized fix, it is worth considering whether a global check should be added to all relevant estimators.\n- Speed matters a lot in online machine learning. Therefore, a golden rule for implementation is to not introduce significant slowdowns. We use CodSpeed to detect regressions in pull requests.\n- Likewise, model accuracy is paramount. When making any sort of modification to an estimator, you should thoroughly check accuracy across several datasets. Whether the accuracy goes up or down, you should be able to explain why.\n",".cursorrules (flutter-riverpod-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for Flutter Riverpod.\"\nglobs: **/*\nalwaysApply: false\n---\n# AI Assistant Technical Instructions\n\nYou are an AI assistant with advanced problem-solving capabilities. Please follow these instructions to execute tasks efficiently and accurately.\n\nFirst, confirm the instructions received from the user:\n\n<instructions>\n{{instructions}}\n</instructions>\n\nPlease proceed with the following process based on these instructions:\n\n---\n\n## 1. Instruction Analysis and Planning\n\n<Task Analysis>\n- Summarize the main tasks concisely\n- Review the specified tech stack and consider implementation methods within those constraints  \n  **Note: Do not change versions listed in the tech stack without approval**\n- Identify key requirements and constraints\n- List potential challenges\n- Enumerate specific steps for task execution in detail\n- Determine the optimal execution order for these steps\n\n### Preventing Duplicate Implementation\n\nBefore implementation, verify:\n- Existence of similar functionality\n- Functions or components with identical or similar names\n- Duplicate API endpoints\n- Identification of processes that can be shared\n\nTake sufficient time for this section as it guides the entire subsequent process. Conduct thorough and comprehensive analysis.\n</Task Analysis>\n\n---\n\n## 2. Task Execution\n\n- Execute identified steps one by one\n- Report progress concisely after completing each step\n- Pay attention to the following during implementation:\n  - Adherence to proper directory structure\n  - Consistency in naming conventions\n  - Appropriate placement of shared processes\n\n---\n\n## 3. Quality Control and Problem Resolution\n\n- Quickly verify the execution results of each task\n- If errors or inconsistencies occur, address them through the following process:\n  a. Problem isolation and cause identification (log analysis, debug information verification)\n  b. Creation and implementation of countermeasures\n  c. Post-fix operation verification\n  d. Debug log confirmation and analysis\n\n- Record verification results in the following format:\n  a. Verification items and expected results\n  b. Actual results and discrepancies\n  c. Required countermeasures (if applicable)\n\n---\n\n## 4. Final Confirmation\n\n- Evaluate the entire deliverable once all tasks are completed\n- Verify consistency with original instructions and make adjustments as needed\n- Perform final confirmation that there are no duplicates in implemented functions\n\n---\n\n## 5. Results Report\n\nPlease report final results in the following format:\n\nmarkdown\n# Execution Results Report\n\n## Overview\n\n[Brief description of overall summary]\n\n## Execution Steps\n\n1. [Step 1 description and results]\n2. [Step 2 description and results]\n...\n\n## Final Deliverables\n\n[Details of deliverables, links if applicable]\n\n## Issue Resolution (if applicable)\n\n- Problems encountered and responses\n- Future considerations\n\n## Notes & Improvement Suggestions\n\n- [List any observations or suggestions for improvement]\n\n---\n\n## Important Notes\n\n- Always confirm any unclear points before beginning work\n- Report and obtain approval for any important decisions as they arise\n- Report unexpected problems immediately and propose solutions\n- **Do not make changes that are not explicitly instructed.** If changes seem necessary, first report them as proposals and implement only after approval\n- **UI/UX design changes (layout, colors, fonts, spacing, etc.) are prohibited** unless approved after presenting justification\n- **Do not arbitrarily change versions listed in the tech stack** (APIs, frameworks, libraries, etc.). If changes are necessary, clearly explain the reason and wait for approval before making any changes\n\n---\n\n# Tech Stack\n\n## Core Technologies\n\n- **AI Model: GPT-4**\n\n## Frontend\n\n- Flutter: ^3.22.0\n\n### State Management\n\n- Riverpod: ^2.6.1\n\n## BaaS\n\n- Firebase\n\n---\n\n## Project Structure\n\nPlease implement following this directory structure:\n\nlib/features/products/\n├── data/\n│   ├── models/\n│   │   ├── product_dto.dart\n│   │   └── product_category_dto.dart\n│   └── product_repository.dart\n├── presentation/\n│   ├── screens/\n│   │   ├── product_list_screen.dart\n│   │   └── product_details_screen.dart\n│   ├── controllers/\n│   │   └── product_list_controller.dart\n│   ├── widgets/\n│       └── product_card.dart\n├── domain/\n│   ├── models/\n│   │   ├── product.dart\n│   │   └── product_category.dart\n│   └── get_products_use_case.dart\n└── shared/\n    └── models/\n        └── address.dart\n\n## Placement Rules\n\n### Flutter Project Structure Placement Rules\n\nThis document outlines the placement rules for files and folders within the recommended Flutter project structure, focusing on scalability, maintainability, and adherence to Clean Architecture principles.\n\n#### Top-Level Structure\n\nlib/\n├── features/\n├── models/\n├── providers/\n├── routes/\n├── core/\n├── app.dart\n└── main.dart\n\n*   **lib/**: Contains all Dart code.\n*   **features/**: Feature-specific code.\n*   **models/**: Global models (use sparingly).\n*   **providers/**: Global providers (minimize use).\n*   **routes/**: App navigation.\n*   **core/**: Core app logic (networking, errors, DI).\n*   **app.dart**: Root widget.\n*   **main.dart**: Entry point.\n\n#### features/ Structure\n\nlib/features/\n└── <feature_name>/\n├── data/\n│   ├── models/\n│   └── <feature_name>_repository.dart\n├── presentation/\n│   ├── screens/\n│   ├── controllers/\n│   ├── widgets/\n├── domain/\n│   ├── models/\n│   └── <feature_name>.dart\n├── use_cases/\n└── shared/\n└── models/\n\n*   **<feature_name>/**: A feature (e.g., authentication, products).\n*   **data/**: Data access.\n    *   **models/**: Data Transfer Objects (DTOs).\n    *   **<feature_name>_repository.dart**: Data access logic.\n*   **presentation/**: UI.\n    *   **screens/**: UI screens (<feature_name>_<screen_name>_screen.dart).\n    *   **controllers/**: State management (<feature_name>_controller.dart).\n    *   **widgets/**: Feature-specific widgets (<widget_name>.dart).\n*   **domain/**: Business logic.\n    *   **models/**: Domain models.\n    *   **<feature_name>.dart**: Main entity.\n*   **use_cases/**: User interactions (<use_case_name>.dart).\n*   **shared/models/**: Models shared between *related* features.\n\n#### shared/ (Top-Level) Structure\n\nlib/shared/\n├── providers/\n├── widgets/\n├── models/\n└── services/\n\n*   **providers/**: Providers shared across *unrelated* features.\n*   **widgets/**: Widgets shared across *unrelated* features.\n*   **models/**: Models shared across *unrelated* features (use cautiously).\n*   **services/**: Utility classes.\n\n#### models/ (Top-Level) Structure\n\nlib/models/\n└── <model_name>.dart\n\n*   Global models (use sparingly).\n\n#### providers/ (Top-Level) Structure\n\nlib/providers/\n└── <provider_name>.dart\n\n*   Global providers (minimize use).\n\n#### core/ Structure\n\nlib/core/\n├── network/\n│   └── api_client.dart\n├── errors/\n│   └── exceptions.dart\n└── di/\n└── injection.dart\n\n*   **network/**: Networking code.\n*   **errors/**: Error handling.\n*   **di/**: Dependency injection.\n\n## Naming Conventions\n\n*   **Files:** snake_case (e.g., product_list_screen.dart).\n*   **Classes:** PascalCase (e.g., ProductListScreen).\n*   **Variables/Functions:** camelCase (e.g., productList).\n\n## Key Principles\n\n*   **Feature Isolation:** Self-contained feature code.\n*   **Separation of Concerns:** Separate data, logic, and UI.\n*   **Single Responsibility:** One purpose per class/file.\n*   **DRY:** Avoid code duplication.\n*   **Prefer Feature-Specific:** Prioritize feature-level placement.\n\nPlease adhere to the above content when executing tasks.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/online-ml/river/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\n## Architecture\n\nRiver is a Python library for online (streaming) machine learning. All estimators implement incremental `learn_one`/`predict_one`/`transform_one` methods (or `learn_many`/`predict_many/transform_many` for mini-batch).\n\n### Base classes (`river/base/`)\n\nAll estimators inherit from `base.Estimator` (which inherits from `base.Base`). Key interfaces:\n- `Classifier` / `MiniBatchClassifier` — classification\n- `Regressor` / `MiniBatchRegressor` — regression\n- `Transformer` / `SupervisedTransformer` — feature transformation\n- `Clusterer` — clustering\n- `DriftDetector` / `BinaryDriftDetector` — concept drift detection\n- `Ensemble` / `WrapperEnsemble` — ensemble methods\n- `Wrapper` — wrapping other estimators\n\n### Estimator conventions\n\n- `learn_one(x, y)` / `predict_one(x)` / `transform_one(x)` is the core online learning interface\n- `__init__` parameters need type hints; provide defaults or implement `_unit_test_params()`\n- `_unit_test_skips()` returns check names to skip in automated testing\n- `_supervised`, `_multiclass`, `_is_stochastic`, `_tags` are special class attributes\n- Pipeline composition: `scaler | model` (uses `__or__`), `+` for parallel union\n\n## Rules for coding agents\n\n1. **Write code, not comments.** You may generate code, using the existing codebase for idiomatic examples to draw from. Do not write comments. Encourage humans to write comments themselves, thereby forcing them to understand the code you've written.\n2. **Prose is written by humans, not by you.** Issues, pull request descriptions, commit messages, docstrings, and release-note entries must all be typed out by a human, in their own words. You may run a benchmark and produce a summary table, but a human must editorialize it and fold it into a message they wrote themselves. Similarly, you can correct typos and wording, but human contributors have to use their own voice.\n3. **Disclose agent-written code.** Code generated by an agent must be marked as such. Do not pass it off as hand-written. A `Co-authored-by:` trailer on the commit is the simplest way. Likewise, information about the agent setup should be disclosed when opening a pull request.\n4. **Be thorough on tests.** Tests are often longer than the implementation and tedious to write. With an agent there is no excuse for skipping them. The minimum for new estimators is to pass `utils.check_estimator`. Ideally you should add out-of-the-box tests to check for edge cases.\n5. **Prefer opening issues instead of pull requests for small fixes** If you find a bug, then it is more valuable to open an issue and surface the issue. The exact way to go about fixing it can be discussed, and serve as implementation opportunities for aspiring human contributors.\n\n## Common commands\n\n```sh\n# Install / sync dependencies (also builds Rust extensions via maturin)\nuv sync\n\n# Run tests (excludes datasets and slow markers by default, includes doctests)\nuv run pytest\n\n# Run a single test file\nuv run pytest tests/linear_model/test_glm.py\n\n# Lint and format (via prek hooks)\nuv run prek run --all-files\n\n# Type checking\nuv run mypy\n\n# Build and serve docs locally\nuv sync --group docs\nmake livedoc\n```\n\n## Checklists\n\n### Adding a new estimator\n\n- Make sure `utils.checks.check_estimator(some_estimator)` passes. It automatically discovers and runs validation checks (repr, cloning, pickling, feature robustness, etc.).\n- Add a practical docstring that shows how to use the estimator. Pytest is configured with `--doctest-modules`, so that docstring examples are executed as tests. The underlying logic are in `river/checks/`.\n- Add a new CodSpeed benchmark entry, in order to detect future regressions.\n- Generally speaking, all estimators should be able to process at least 5000 records per second. Naturally this depends on the size of the samples and the estimator, but exceptions need to be justified.\n\n### Modifying an existing estimator\n\n- When making a localized fix, it is worth considering whether a global check should be added to all relevant estimators.\n- Speed matters a lot in online machine learning. Therefore, a golden rule for implementation is to not introduce significant slowdowns. We use CodSpeed to detect regressions in pull requests.\n- Likewise, model accuracy is paramount. When making any sort of modification to an estimator, you should thoroughly check accuracy across several datasets. Whether the accuracy goes up or down, you should be able to explain why.\n","isInternal":false,"tokens":1004,"sizeBytes":4487},{"name":".cursorrules","path":".cursorrules (flutter-riverpod-cursorrules-prompt-file.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/flutter-riverpod-cursorrules-prompt-file.mdc","title":"Awesome Cursorrules: flutter riverpod","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for Flutter Riverpod.\"\nglobs: **/*\nalwaysApply: false\n---\n# AI Assistant Technical Instructions\n\nYou are an AI assistant with advanced problem-solving capabilities. Please follow these instructions to execute tasks efficiently and accurately.\n\nFirst, confirm the instructions received from the user:\n\n<instructions>\n{{instructions}}\n</instructions>\n\nPlease proceed with the following process based on these instructions:\n\n---\n\n## 1. Instruction Analysis and Planning\n\n<Task Analysis>\n- Summarize the main tasks concisely\n- Review the specified tech stack and consider implementation methods within those constraints  \n  **Note: Do not change versions listed in the tech stack without approval**\n- Identify key requirements and constraints\n- List potential challenges\n- Enumerate specific steps for task execution in detail\n- Determine the optimal execution order for these steps\n\n### Preventing Duplicate Implementation\n\nBefore implementation, verify:\n- Existence of similar functionality\n- Functions or components with identical or similar names\n- Duplicate API endpoints\n- Identification of processes that can be shared\n\nTake sufficient time for this section as it guides the entire subsequent process. Conduct thorough and comprehensive analysis.\n</Task Analysis>\n\n---\n\n## 2. Task Execution\n\n- Execute identified steps one by one\n- Report progress concisely after completing each step\n- Pay attention to the following during implementation:\n  - Adherence to proper directory structure\n  - Consistency in naming conventions\n  - Appropriate placement of shared processes\n\n---\n\n## 3. Quality Control and Problem Resolution\n\n- Quickly verify the execution results of each task\n- If errors or inconsistencies occur, address them through the following process:\n  a. Problem isolation and cause identification (log analysis, debug information verification)\n  b. Creation and implementation of countermeasures\n  c. Post-fix operation verification\n  d. Debug log confirmation and analysis\n\n- Record verification results in the following format:\n  a. Verification items and expected results\n  b. Actual results and discrepancies\n  c. Required countermeasures (if applicable)\n\n---\n\n## 4. Final Confirmation\n\n- Evaluate the entire deliverable once all tasks are completed\n- Verify consistency with original instructions and make adjustments as needed\n- Perform final confirmation that there are no duplicates in implemented functions\n\n---\n\n## 5. Results Report\n\nPlease report final results in the following format:\n\nmarkdown\n# Execution Results Report\n\n## Overview\n\n[Brief description of overall summary]\n\n## Execution Steps\n\n1. [Step 1 description and results]\n2. [Step 2 description and results]\n...\n\n## Final Deliverables\n\n[Details of deliverables, links if applicable]\n\n## Issue Resolution (if applicable)\n\n- Problems encountered and responses\n- Future considerations\n\n## Notes & Improvement Suggestions\n\n- [List any observations or suggestions for improvement]\n\n---\n\n## Important Notes\n\n- Always confirm any unclear points before beginning work\n- Report and obtain approval for any important decisions as they arise\n- Report unexpected problems immediately and propose solutions\n- **Do not make changes that are not explicitly instructed.** If changes seem necessary, first report them as proposals and implement only after approval\n- **UI/UX design changes (layout, colors, fonts, spacing, etc.) are prohibited** unless approved after presenting justification\n- **Do not arbitrarily change versions listed in the tech stack** (APIs, frameworks, libraries, etc.). If changes are necessary, clearly explain the reason and wait for approval before making any changes\n\n---\n\n# Tech Stack\n\n## Core Technologies\n\n- **AI Model: GPT-4**\n\n## Frontend\n\n- Flutter: ^3.22.0\n\n### State Management\n\n- Riverpod: ^2.6.1\n\n## BaaS\n\n- Firebase\n\n---\n\n## Project Structure\n\nPlease implement following this directory structure:\n\nlib/features/products/\n├── data/\n│   ├── models/\n│   │   ├── product_dto.dart\n│   │   └── product_category_dto.dart\n│   └── product_repository.dart\n├── presentation/\n│   ├── screens/\n│   │   ├── product_list_screen.dart\n│   │   └── product_details_screen.dart\n│   ├── controllers/\n│   │   └── product_list_controller.dart\n│   ├── widgets/\n│       └── product_card.dart\n├── domain/\n│   ├── models/\n│   │   ├── product.dart\n│   │   └── product_category.dart\n│   └── get_products_use_case.dart\n└── shared/\n    └── models/\n        └── address.dart\n\n## Placement Rules\n\n### Flutter Project Structure Placement Rules\n\nThis document outlines the placement rules for files and folders within the recommended Flutter project structure, focusing on scalability, maintainability, and adherence to Clean Architecture principles.\n\n#### Top-Level Structure\n\nlib/\n├── features/\n├── models/\n├── providers/\n├── routes/\n├── core/\n├── app.dart\n└── main.dart\n\n*   **lib/**: Contains all Dart code.\n*   **features/**: Feature-specific code.\n*   **models/**: Global models (use sparingly).\n*   **providers/**: Global providers (minimize use).\n*   **routes/**: App navigation.\n*   **core/**: Core app logic (networking, errors, DI).\n*   **app.dart**: Root widget.\n*   **main.dart**: Entry point.\n\n#### features/ Structure\n\nlib/features/\n└── <feature_name>/\n├── data/\n│   ├── models/\n│   └── <feature_name>_repository.dart\n├── presentation/\n│   ├── screens/\n│   ├── controllers/\n│   ├── widgets/\n├── domain/\n│   ├── models/\n│   └── <feature_name>.dart\n├── use_cases/\n└── shared/\n└── models/\n\n*   **<feature_name>/**: A feature (e.g., authentication, products).\n*   **data/**: Data access.\n    *   **models/**: Data Transfer Objects (DTOs).\n    *   **<feature_name>_repository.dart**: Data access logic.\n*   **presentation/**: UI.\n    *   **screens/**: UI screens (<feature_name>_<screen_name>_screen.dart).\n    *   **controllers/**: State management (<feature_name>_controller.dart).\n    *   **widgets/**: Feature-specific widgets (<widget_name>.dart).\n*   **domain/**: Business logic.\n    *   **models/**: Domain models.\n    *   **<feature_name>.dart**: Main entity.\n*   **use_cases/**: User interactions (<use_case_name>.dart).\n*   **shared/models/**: Models shared between *related* features.\n\n#### shared/ (Top-Level) Structure\n\nlib/shared/\n├── providers/\n├── widgets/\n├── models/\n└── services/\n\n*   **providers/**: Providers shared across *unrelated* features.\n*   **widgets/**: Widgets shared across *unrelated* features.\n*   **models/**: Models shared across *unrelated* features (use cautiously).\n*   **services/**: Utility classes.\n\n#### models/ (Top-Level) Structure\n\nlib/models/\n└── <model_name>.dart\n\n*   Global models (use sparingly).\n\n#### providers/ (Top-Level) Structure\n\nlib/providers/\n└── <provider_name>.dart\n\n*   Global providers (minimize use).\n\n#### core/ Structure\n\nlib/core/\n├── network/\n│   └── api_client.dart\n├── errors/\n│   └── exceptions.dart\n└── di/\n└── injection.dart\n\n*   **network/**: Networking code.\n*   **errors/**: Error handling.\n*   **di/**: Dependency injection.\n\n## Naming Conventions\n\n*   **Files:** snake_case (e.g., product_list_screen.dart).\n*   **Classes:** PascalCase (e.g., ProductListScreen).\n*   **Variables/Functions:** camelCase (e.g., productList).\n\n## Key Principles\n\n*   **Feature Isolation:** Self-contained feature code.\n*   **Separation of Concerns:** Separate data, logic, and UI.\n*   **Single Responsibility:** One purpose per class/file.\n*   **DRY:** Avoid code duplication.\n*   **Prefer Feature-Specific:** Prioritize feature-level placement.\n\nPlease adhere to the above content when executing tasks.\n","tokens":1736,"sizeBytes":7959}],"systemPromptSnippet":"<yakaai_skills repo=\"online-ml/river\">\n<!-- File: AGENTS.md (Tokens: ~1004 | Category: root-instruction) -->\n# AGENTS.md\n\n## Architecture\n\nRiver is a Python library for online (streaming) machine learning. All estimators implement incremental `learn_one`/`predict_one`/`transform_one` methods (or `learn_many`/`predict_many/transform_many` for mini-batch).\n\n### Base classes (`river/base/`)\n\nAll estimators inherit from `base.Estimator` (which inherits from `base.Base`). Key interfaces:\n- `Classifier` / `MiniBatchClassifier` — classification\n- `Regressor` / `MiniBatchRegressor` — regression\n- `Transformer` / `SupervisedTransformer` — feature transformation\n- `Clusterer` — clustering\n- `DriftDetector` / `BinaryDriftDetector` — concept drift detection\n- `Ensemble` / `WrapperEnsemble` — ensemble methods\n- `Wrapper` — wrapping other estimators\n\n### Estimator conventions\n\n- `learn_one(x, y)` / `predict_one(x)` / `transform_one(x)` is the core online learning interface\n- `__init__` parameters need type hints; provide defaults or implement `_unit_test_params()`\n- `_unit_test_skips()` returns check names to skip in automated testing\n- `_supervised`, `_multiclass`, `_is_stochastic`, `_tags` are special class attributes\n- Pipeline composition: `scaler | model` (uses `__or__`), `+` for parallel union\n\n## Rules for coding agents\n\n1. **Write code, not comments.** You may generate code, using the existing codebase for idiomatic examples to draw from. Do not write comments. Encourage humans to write comments themselves, thereby forcing them to understand the code you've written.\n2. **Prose is written by humans, not by you.** Issues, pull request descriptions, commit messages, docstrings, and release-note entries must all be typed out by a human, in their own words. You may run a benchmark and produce a summary table, but a human must editorialize it and fold it into a message they wrote themselves. Similarly, you can correct typos and wording, but human contributors have to use their own voice.\n3. **Disclose agent-written code.** Code generated by an agent must be marked as such. Do not pass it off as hand-written. A `Co-authored-by:` trailer on the commit is the simplest way. Likewise, information about the agent setup should be disclosed when opening a pull request.\n4. **Be thorough on tests.** Tests are often longer than the implementation and tedious to write. With an agent there is no excuse for skipping them. The minimum for new estimators is to pass `utils.check_estimator`. Ideally you should add out-of-the-box tests to check for edge cases.\n5. **Prefer opening issues instead of pull requests for small fixes** If you find a bug, then it is more valuable to open an issue and surface the issue. The exact way to go about fixing it can be discussed, and serve as implementation opportunities for aspiring human contributors.\n\n## Common commands\n\n```sh\n# Install / sync dependencies (also builds Rust extensions via maturin)\nuv sync\n\n# Run tests (excludes datasets and slow markers by default, includes doctests)\nuv run pytest\n\n# Run a single test file\nuv run pytest tests/linear_model/test_glm.py\n\n# Lint and format (via prek hooks)\nuv run prek run --all-files\n\n# Type checking\nuv run mypy\n\n# Build and serve docs locally\nuv sync --group docs\nmake livedoc\n```\n\n## Checklists\n\n### Adding a new estimator\n\n- Make sure `utils.checks.check_estimator(some_estimator)` passes. It automatically discovers and runs validation checks (repr, cloning, pickling, feature robustness, etc.).\n- Add a practical docstring that shows how to use the estimator. Pytest is configured with `--doctest-modules`, so that docstring examples are executed as tests. The underlying logic are in `river/checks/`.\n- Add a new CodSpeed benchmark entry, in order to detect future regressions.\n- Generally speaking, all estimators should be able to process at least 5000 records per second. Naturally this depends on the size of the samples and the estimator, but exceptions need to be justified.\n\n### Modifying an existing estimator\n\n- When making a localized fix, it is worth considering whether a global check should be added to all relevant estimators.\n- Speed matters a lot in online machine learning. Therefore, a golden rule for implementation is to not introduce significant slowdowns. We use CodSpeed to detect regressions in pull requests.\n- Likewise, model accuracy is paramount. When making any sort of modification to an estimator, you should thoroughly check accuracy across several datasets. Whether the accuracy goes up or down, you should be able to explain why.\n\n<!-- File: .cursorrules (flutter-riverpod-cursorrules-prompt-file.mdc) (Tokens: ~1736 | Category: cursor-rule) -->\n---\ndescription: \"Cursor rules for Flutter Riverpod.\"\nglobs: **/*\nalwaysApply: false\n---\n# AI Assistant Technical Instructions\n\nYou are an AI assistant with advanced problem-solving capabilities. Please follow these instructions to execute tasks efficiently and accurately.\n\nFirst, confirm the instructions received from the user:\n\n<instructions>\n{{instructions}}\n</instructions>\n\nPlease proceed with the following process based on these instructions:\n\n---\n\n## 1. Instruction Analysis and Planning\n\n<Task Analysis>\n- Summarize the main tasks concisely\n- Review the specified tech stack and consider implementation methods within those constraints  \n  **Note: Do not change versions listed in the tech stack without approval**\n- Identify key requirements and constraints\n- List potential challenges\n- Enumerate specific steps for task execution in detail\n- Determine the optimal execution order for these steps\n\n### Preventing Duplicate Implementation\n\nBefore implementation, verify:\n- Existence of similar functionality\n- Functions or components with identical or similar names\n- Duplicate API endpoints\n- Identification of processes that can be shared\n\nTake sufficient time for this section as it guides the entire subsequent process. Conduct thorough and comprehensive analysis.\n</Task Analysis>\n\n---\n\n## 2. Task Execution\n\n- Execute identified steps one by one\n- Report progress concisely after completing each step\n- Pay attention to the following during implementation:\n  - Adherence to proper directory structure\n  - Consistency in naming conventions\n  - Appropriate placement of shared processes\n\n---\n\n## 3. Quality Control and Problem Resolution\n\n- Quickly verify the execution results of each task\n- If errors or inconsistencies occur, address them through the following process:\n  a. Problem isolation and cause identification (log analysis, debug information verification)\n  b. Creation and implementation of countermeasures\n  c. Post-fix operation verification\n  d. Debug log confirmation and analysis\n\n- Record verification results in the following format:\n  a. Verification items and expected results\n  b. Actual results and discrepancies\n  c. Required countermeasures (if applicable)\n\n---\n\n## 4. Final Confirmation\n\n- Evaluate the entire deliverable once all tasks are completed\n- Verify consistency with original instructions and make adjustments as needed\n- Perform final confirmation that there are no duplicates in implemented functions\n\n---\n\n## 5. Results Report\n\nPlease report final results in the following format:\n\nmarkdown\n# Execution Results Report\n\n## Overview\n\n[Brief description of overall summary]\n\n## Execution Steps\n\n1. [Step 1 description and results]\n2. [Step 2 description and results]\n...\n\n## Final Deliverables\n\n[Details of deliverables, links if applicable]\n\n## Issue Resolution (if applicable)\n\n- Problems encountered and responses\n- Future considerations\n\n## Notes & Improvement Suggestions\n\n- [List any observations or suggestions for improvement]\n\n---\n\n## Important Notes\n\n- Always confirm any unclear points before beginning work\n- Report and obtain approval for any important decisions as they arise\n- Report unexpected problems immediately and propose solutions\n- **Do not make changes that are not explicitly instructed.** If changes seem necessary, first report them as proposals and implement only after approval\n- **UI/UX design changes (layout, colors, fonts, spacing, etc.) are prohibited** unless approved after presenting justification\n- **Do not arbitrarily change versions listed in the tech stack** (APIs, frameworks, libraries, etc.). If changes are necessary, clearly explain the reason and wait for approval before making any changes\n\n---\n\n# Tech Stack\n\n## Core Technologies\n\n- **AI Model: GPT-4**\n\n## Frontend\n\n- Flutter: ^3.22.0\n\n### State Management\n\n- Riverpod: ^2.6.1\n\n## BaaS\n\n- Firebase\n\n---\n\n## Project Structure\n\nPlease implement following this directory structure:\n\nlib/features/products/\n├── data/\n│   ├── models/\n│   │   ├── product_dto.dart\n│   │   └── product_category_dto.dart\n│   └── product_repository.dart\n├── presentation/\n│   ├── screens/\n│   │   ├── product_list_screen.dart\n│   │   └── product_details_screen.dart\n│   ├── controllers/\n│   │   └── product_list_controller.dart\n│   ├── widgets/\n│       └── product_card.dart\n├── domain/\n│   ├── models/\n│   │   ├── product.dart\n│   │   └── product_category.dart\n│   └── get_products_use_case.dart\n└── shared/\n    └── models/\n        └── address.dart\n\n## Placement Rules\n\n### Flutter Project Structure Placement Rules\n\nThis document outlines the placement rules for files and folders within the recommended Flutter project structure, focusing on scalability, maintainability, and adherence to Clean Architecture principles.\n\n#### Top-Level Structure\n\nlib/\n├── features/\n├── models/\n├── providers/\n├── routes/\n├── core/\n├── app.dart\n└── main.dart\n\n*   **lib/**: Contains all Dart code.\n*   **features/**: Feature-specific code.\n*   **models/**: Global models (use sparingly).\n*   **providers/**: Global providers (minimize use).\n*   **routes/**: App navigation.\n*   **core/**: Core app logic (networking, errors, DI).\n*   **app.dart**: Root widget.\n*   **main.dart**: Entry point.\n\n#### features/ Structure\n\nlib/features/\n└── <feature_name>/\n├── data/\n│   ├── models/\n│   └── <feature_name>_repository.dart\n├── presentation/\n│   ├── screens/\n│   ├── controllers/\n│   ├── widgets/\n├── domain/\n│   ├── models/\n│   └── <feature_name>.dart\n├── use_cases/\n└── shared/\n└── models/\n\n*   **<feature_name>/**: A feature (e.g., authentication, products).\n*   **data/**: Data access.\n    *   **models/**: Data Transfer Objects (DTOs).\n    *   **<feature_name>_repository.dart**: Data access logic.\n*   **presentation/**: UI.\n    *   **screens/**: UI screens (<feature_name>_<screen_name>_screen.dart).\n    *   **controllers/**: State management (<feature_name>_controller.dart).\n    *   **widgets/**: Feature-specific widgets (<widget_name>.dart).\n*   **domain/**: Business logic.\n    *   **models/**: Domain models.\n    *   **<feature_name>.dart**: Main entity.\n*   **use_cases/**: User interactions (<use_case_name>.dart).\n*   **shared/models/**: Models shared between *related* features.\n\n#### shared/ (Top-Level) Structure\n\nlib/shared/\n├── providers/\n├── widgets/\n├── models/\n└── services/\n\n*   **providers/**: Providers shared across *unrelated* features.\n*   **widgets/**: Widgets shared across *unrelated* features.\n*   **models/**: Models shared across *unrelated* features (use cautiously).\n*   **services/**: Utility classes.\n\n#### models/ (Top-Level) Structure\n\nlib/models/\n└── <model_name>.dart\n\n*   Global models (use sparingly).\n\n#### providers/ (Top-Level) Structure\n\nlib/providers/\n└── <provider_name>.dart\n\n*   Global providers (minimize use).\n\n#### core/ Structure\n\nlib/core/\n├── network/\n│   └── api_client.dart\n├── errors/\n│   └── exceptions.dart\n└── di/\n└── injection.dart\n\n*   **network/**: Networking code.\n*   **errors/**: Error handling.\n*   **di/**: Dependency injection.\n\n## Naming Conventions\n\n*   **Files:** snake_case (e.g., product_list_screen.dart).\n*   **Classes:** PascalCase (e.g., ProductListScreen).\n*   **Variables/Functions:** camelCase (e.g., productList).\n\n## Key Principles\n\n*   **Feature Isolation:** Self-contained feature code.\n*   **Separation of Concerns:** Separate data, logic, and UI.\n*   **Single Responsibility:** One purpose per class/file.\n*   **DRY:** Avoid code duplication.\n*   **Prefer Feature-Specific:** Prioritize feature-level placement.\n\nPlease adhere to the above content when executing tasks.\n</yakaai_skills>"}