# TradingBot25 Constitution

## Core Principles

### I. Performance is Paramount
The primary goal is to preserve and improve the strategy's profitability. All changes, especially refactoring, must be validated against the established "Golden Baseline" performance (currently 256,537% on the 1D chart). No change that causes an un-justified performance regression will be accepted. Backtesting is not optional; it is a mandatory gate for every modification. Never change the 'baseline_*.pine' baseline files, these are for reference only.

### II. Modularity Through Libraries
The monolithic structure is to be avoided. All new and refactored logic (indicator calculations, entry/exit conditions, utilities) must be encapsulated in self-contained, documented, and independently testable PineScript libraries. The main strategy script (`MainStrategy.pine`) should act as an orchestrator, not a container for complex logic.

### III. Verify, Then Act
Before executing any code change, file operation, or command, the current state of the relevant files must be verified using tools like `read_file` or `ls`. Relying on memory or previous context is forbidden. Every action must be based on a fresh, verified understanding of the codebase. After every file write, the file must be read back to confirm the change was successful.

### IV. Isolate and Minimize Change
All modifications must be targeted and minimal. Avoid broad, sweeping changes that affect multiple, unrelated parts of the strategy. Isolate the component being worked on, refactor it, and verify it before integrating it back. If a piece of code is working and unrelated to the task, it must be left untouched.

### V. Synchronized Visualization
Due to PineScript's limitations, visualization is handled by separate `indicator` scripts. It is a non-negotiable requirement that these indicators remain perfectly synchronized with `MainStrategy.pine`. Any change to an input, calculation, or library call in the strategy must be mirrored exactly in its corresponding indicator to prevent misleading analysis.

## Development Workflow & Quality Gates

### Refactoring Process
1.  **Identify & Isolate**: Identify a specific area for improvement and isolate it from the main codebase, often into a new or existing library.
2.  **Refactor**: Improve the isolated code's structure, documentation, and readability according to project standards.
3.  **Backtest & Verify**: After refactoring, perform a backtest to ensure no performance degradation has occurred. Use visualization indicators to verify correct behavior.
4.  **Integrate**: Once verified, integrate the refactored code back into the main strategy and update all call sites.

### Adding New Conditions
The process for adding new trading conditions is standardized to ensure all parts of the system (logic, inputs, visualization) are updated correctly. This process is documented in `docs/add_new_condition_guide.md`.

## Coding & Naming Standards

### Naming Conventions
- **Inputs**: Prefixed with `i_` (e.g., `i_enableShorts`).
- **Functions**: Prefixed with `f_` (e.g., `f_apply_smoothing`).
- **Booleans**: Named as questions where possible (e.g., `isMacdHistRising`).
- **Input Groups**: Prefixed with `group_` (e.g., `group_main_algo_settings`).
- **Input Titles**: Prefixed with `D-`, `12-`, `F-`, `?-` to denote status and priority. 'D' for inclusion in the default set of conditions in the 1 day chart, '12' for in the default condition set for the 12 hour chart. 'F' for needs fixing, 'F1' means likely fix first as its close to performing well, whereas 'F5' would be a lower priority because it seems to need more work. The "-" is a delimiter between prefix labels for clarity.

### PineScript Best Practices
- **Version**: All scripts must begin with `//@version=6`.
- **Function Documentation**: All exported library functions must have a full documentation block (`@param`, `@returns`).
- **No Nested Functions**: Helper functions must be defined at the top level of a library.
- **The "New Variable" Rule**: To prevent accidental type promotion from `simple` to `series` inside conditional blocks, always create a new variable for the conditional assignment.
- **Hybrid Object Model**: To manage high parameter counts, break large input objects into smaller, logically-grouped `type` objects.
- **History-Referencing Custom Types**: Use the `(inputs[1]).my_field` pattern, not `inputs.my_field[1]`.

## Governance
This Constitution supersedes all other practices and guidelines. Any amendments require a documented proposal, review, and an update to the `constitution_update_checklist.md`. All development and review activities must verify compliance with these principles.

**Version**: 1.0.0 | **Ratified**: 2025-09-16 | **Last Amended**: N/A