Move to objective based interface

.cursor/rules/conda-environment.mdc

@@ -0,0 +1,10 @@
+---
+description:
+globs:
+alwaysApply: true
+---
+
+To run anything in the terminal or console, ALWAYS:
+1. Run: conda activate confopt_env
+2. Run: pip install .
+3. Run your command

.cursor/rules/python-best-practice-instructions.mdc

@@ -0,0 +1,25 @@
+---
+description:
+globs:
+alwaysApply: true
+---
+# Coding Style Guidelines
+
+- Adopt the DRY principle. If code is repeated in multiple places, it should be functionalized and called in those places.
+- Make all inputs explicit. Avoid relying on state or shared context unless encapsulated.
+- Avoid implicit behavior (e.g., mutation of input lists, in place dataframe modification).
+- Variable names should be descriptive and reduced to the shortest possible length.
+- If a function returns multiple types, refactor. Don't return Union[str, dict, None].
+- Use pytest.mark.parametrize for testing functions with categorical input values.
+- If mocking in unit testing is required, mock external APIs and I/O only.
+- No print() statements anywhere in the code. Use logging instead.
+- No single-letter variable names unless in mathematical contexts or loops.
+- No hard coded values. Use constants or configuration files.
+- Don't use early returns in if else statements.
+- Don't create classes if functions are sufficient.
+- Keep modules small and focused (under 500 lines).
+- Comments should explain why, not what. Keep comments under 10% of code.
+- Don't write docstrings.
+- Don't rely on default values for function arguments.
+- Avoid *args or **kwargs unless absolutely necessary.
+- Use pydantic models for configuration values.

.cursor/rules/software-engineering-best-practices.mdc

@@ -0,0 +1,10 @@
+---
+description:
+globs:
+alwaysApply: true
+---
+- Always comply with DRY and SOLID principles.
+- Use as little code as is necessary to carry out the desired functionality, do not over-engineer or over-validate your code.
+- Write easily testable and maintainable code.
+- Maximize separation of concerns.
+- Consider how your changes will affect the wider codebase, think several dependancies ahead.

.cursor/rules/system-permissions.mdc

@@ -0,0 +1,8 @@
+---
+description:
+globs:
+alwaysApply: true
+---
+- NEVER commit any changes.
+- NEVER revert commits or affect the commit history.
+- NEVER push commits or pull from remote, or interact at all with remote branches.

.github/copilot-instructions.md

@@ -0,0 +1,31 @@
+# Coding Style Guidelines
+
+- Adopt the DRY principle. If code is repeated in multiple places, it should be functionalized and called in those places.
+- Make all inputs explicit. Avoid relying on state or shared context unless encapsulated.
+- Avoid implicit behavior (e.g., mutation of input lists, in place dataframe modification).
+- Variable names should be descriptive and reduced to the shortest possible length.
+- If a function returns multiple types, refactor. Don't return Union[str, dict, None].
+- Use pytest.mark.parametrize for testing functions with categorical input values.
+- If mocking in unit testing is required, mock external APIs and I/O only.
+- No print() statements anywhere in the code. Use logging instead.
+- No single-letter variable names unless in mathematical contexts or loops.
+- No hard coded values. Use constants or configuration files.
+- Don't use early returns in if else statements.
+- Don't create classes if functions are sufficient.
+- Keep modules small and focused (under 500 lines).
+- Comments should explain why, not what. Keep comments under 10% of code.
+- Don't write docstrings.
+- Don't rely on default values for function arguments.
+- Avoid *args or **kwargs unless absolutely necessary.
+- Use pydantic models for configuration values.
+- Always comply with DRY and SOLID principles.
+- Use as little code as is necessary to carry out the desired functionality, do not over-engineer or over-validate your code.
+- Write easily testable and maintainable code.
+- Maximize separation of concerns.
+- Consider how your changes will affect the wider codebase, think several dependancies ahead.
+
+
+To run anything in the terminal or console, ALWAYS:
+1. Run: conda activate confopt_env
+2. Run: pip install .
+3. Run your command

.github/documentation-instructions.md

@@ -0,0 +1,95 @@
+# Quantile Estimation Module Documentation Template
+
+This template provides a step-by-step guide and example prompt for documenting any Python module (e.g., `quantile_estimation.py`) in a style consistent with best practices for technical and developer documentation.
+
+---
+
+## 1. Docstring Requirements
+
+Add or update detailed and informative Google-style docstrings following these guidelines:
+
+### Module-level docstring:
+- Brief description of the module's purpose and core functionality
+- Key methodological approaches or architectural patterns used
+- Integration context within the broader framework
+- Focus on salient aspects, avoid trivial descriptions
+- Do not add any type hints in the doc strings.
+
+---
+
+## 2. Documentation File Requirements
+
+Create a comprehensive `.rst` documentation file in `docs/developer/components/[module_name].rst` with:
+
+### Structure Example:
+
+```
+[Module Name] Module
+===================
+
+Overview
+--------
+[Brief description and key features]
+
+Key Features
+------------
+[Bullet points of main capabilities]
+
+Architecture
+------------
+[Class hierarchy, design patterns, architectural decisions]
+
+[Methodology/Algorithm Sections]
+-------------------------------
+[Detailed explanations of key approaches, mathematical foundations where relevant]
+
+Usage Examples
+--------------
+[Practical code examples showing common usage patterns]
+
+Performance Considerations
+-------------------------
+[Computational complexity, scaling considerations, best practices]
+
+Integration Points
+-----------------
+[How this module connects with other framework components]
+
+Common Pitfalls
+---------------
+[Common mistakes and how to avoid them]
+
+See Also
+--------
+[Cross-references to related modules]
+```
+
+### Content requirements:
+- Technical depth appropriate for developers
+- Mathematical foundations with LaTeX equations where relevant (cite relevant papers if mainstream, do not hallucinate, if unsure do not cite any)
+- Practical usage examples with actual code
+- Performance and scalability guidance
+- Integration context within the framework
+- Best practices and common pitfalls
+- Cross-references to related components
+
+---
+
+## 3. Index Update
+
+Update `docs/developer/components/index.rst` to include the new module documentation in the appropriate section.
+
+---
+
+## 5. Best Practices
+- Documentation should be contextually relevant and technically accurate
+- Focus on methodology and implementation details that matter to developers
+- Provide both theoretical understanding and practical guidance
+- Ensure consistency with existing documentation style and organization
+- Make it easy for both newcomers and experienced developers to understand and use the module
+
+---
+
+## 6. Example Output (for quantile_estimation.py)
+
+See the current `quantile_estimation.py` for a fully documented example, and `docs/developer/components/quantile_estimation.rst` for a comprehensive documentation file.

.github/testing-instructions.md

@@ -0,0 +1,22 @@
+# Coding Style Guidelines
+
+- Use pytest for all testing, use unittest for mocking.
+- Use pytest.mark.parametrize for testing functions with categorical input values:
+    - For literals, you should automatically cycle through all possible Literal values in your parametrization.
+    - For ordinal categories or discrete inputs (eg. n_observations, n_recommendations, etc.) pick some sensible ranges (eg. 0 if allowed, or minimum otherwise, then a sensible every day value, say 10, then a very large value, if it's not computationally expensive, say 1000).
+- Mock external APIs and I/O only, do not use mocking as a crutch to abstract away components who's behaviour you need to test.
+- Use fixtures to store toy data, mocked objects or any other object you plan to reference in the main tests, particularly if it will be used more than once. If the toy data is small and specific to the one test it's called in, it's ok to define it inside the test function.
+- Never define nested functions (function def is inside another function) unless explicitly required because of scope (eg. nested generator builders).
+- Avoid defining helper functions at the top of a test module, tests should be simple and mostly check existing methods' outputs. Very complex tests may require helper functions, but this should be limited.
+- ALL fixtures need to be defined in the tests/conftest.py file, NEVER define them directly in a test module.
+- Do not test initialization of classes. Do not use asserts that just check if an attribute of a class exists, or is equal to what you just defined it as, these are bloated tests that accomplish little, but add maintenance cost.
+- If you're testing a function or method that returns a shaped object, always check the shape (should it be the same as the input's? Should it be different? Should it be a specific size based on the inputs you passed to the function? etc. based on these questions formulate asserts that check those shape aspects)
+- Test the intent behind a function or method, not form or attributes. Read through the function or method carefully, understand its goals and approach, then write meaningful tests that check quality of outputs relative to intent.
+- Do not add strings after asserts, eg. do NOT do this:
+    assert len(final_alphas) == len(initial_alphas), "Alpha count should remain consistent"
+    after any assert statement, it should just be assert len(final_alphas) == len(initial_alphas)
+- Keep comments to a minimum, comments should just explain more obscure asserts or tests.
+- Each unit test should be a function, functions should not be grouped in testing classes and should not have self attributes.
+- When testing mathematical functions, understand the derivations and test assumptions and outputs given mathematical constraints and theory.
+- Do not write excessive amounts of tests, focus on the most important aspects of each function.
+- Avoid lenghty code repetition. If multiple tests share the same set ups or fixture processing but only differ in asserts, join them in a single test and add comments before each assert.