Refactor documentation for various filters and indicators to enhance clarity and consistency

- Updated Bessel, Bilateral, Blma, Butter, Conv, Ema, Kama, LSMA, MAMA, MGDI, SSF, USF, ATR, ADL, and ADOSC documentation to use bullet points for key concepts and features.
- Added a new Qodana configuration file for code analysis.
- Removed coverage configuration from Quantower.Tests.csproj to streamline testing setup.

lib/trends/afirma/Afirma.md

@@ -59,9 +59,9 @@ $$ w_k = W(k) \cdot \text{sinc}\left(\frac{\pi (k - c)}{P}\right) $$
 
 Where:
 
-- $c = \frac{N-1}{2}$ is the center tap
-- $P$ is the period parameter
-- $W(k)$ is the window function value at tap $k$
+* $c = \frac{N-1}{2}$ is the center tap
+* $P$ is the period parameter
+* $W(k)$ is the window function value at tap $k$
 
 ### 2. Window Functions
 
@@ -91,9 +91,9 @@ $$ \text{AFIRMA}_t = \frac{\sum_{k=0}^{N-1} w_k \cdot P_{t-k}}{\sum_{k=0}^{N-1}
 
 ### Parameter Selection Guide
 
-- **Period**: Start with half your expected cycle length. For intraday on 1-minute bars with 20-minute cycles, use Period=10.
-- **Taps**: Use odd numbers (5, 7, 9...) for symmetric response. More taps = more lag but sharper cutoff. 6-12 is typical.
-- **Window**: Blackman-Harris for noisy data, Hamming for faster response, Rectangular only for experimentation.
+* **Period**: Start with half your expected cycle length. For intraday on 1-minute bars with 20-minute cycles, use Period=10.
+* **Taps**: Use odd numbers (5, 7, 9...) for symmetric response. More taps = more lag but sharper cutoff. 6-12 is typical.
+* **Window**: Blackman-Harris for noisy data, Hamming for faster response, Rectangular only for experimentation.
 
 ## Usage
 
@@ -174,9 +174,9 @@ For the same Period and Taps, different windows produce different smoothing char
 1. **Tap Inflation:** There is a temptation to set `Taps = 50` thinking it provides "more accuracy." It provides more lag. Keep taps between 5 and 15 for trading. If you need 50 taps, you don't need a filter; you need a weekly chart.
 
 2. **Period vs. Taps Confusion:**
-   - **Period** is the *what* (which frequencies to remove).
-   - **Taps** is the *how* (how much math to throw at the removal).
-   - Increasing Taps without changing Period just makes the filter steeper, not smoother.
+   * **Period** is the *what* (which frequencies to remove).
+   * **Taps** is the *how* (how much math to throw at the removal).
+   * Increasing Taps without changing Period just makes the filter steeper, not smoother.
 
 3. **The "Cold Start" Reality:** AFIRMA is an FIR filter. It requires `Taps` number of bars to fill its buffer. The first `Taps-1` values are approximations. Check `.IsHot` before trading real money.
 
@@ -184,6 +184,6 @@ For the same Period and Taps, different windows produce different smoothing char
 
 ## See Also
 
-- [ALMA](../alma/Alma.md) - Arnaud Legoux's Gaussian approach (similar goal, different math)
-- [JMA](../jma/Jma.md) - Jurik's proprietary-turned-open filter (often slower, high overshoot)
-- [SSF](../ssf/Ssf.md) - Ehlers Super Smoother (2-pole IIR, infinite memory)
+* [ALMA](../alma/Alma.md) - Arnaud Legoux's Gaussian approach (similar goal, different math)
+* [JMA](../jma/Jma.md) - Jurik's proprietary-turned-open filter (often slower, high overshoot)
+* [SSF](../ssf/Ssf.md) - Ehlers Super Smoother (2-pole IIR, infinite memory)

lib/trends/alma/Alma.md

@@ -16,9 +16,9 @@ ALMA is a weighted moving average where weights follow a normal distribution (be
 
 The physics of ALMA rely on shifting the "center of gravity" of the window.
 
-- **SMA:** Center of gravity is always the middle ($0.5$). Lag is fixed.
-- **EMA:** Center of gravity is front-loaded but has an infinite tail.
-- **ALMA:** You move the center. An offset of $0.85$ pushes the bulk of the weight to the most recent 15% of the window.
+* **SMA:** Center of gravity is always the middle ($0.5$). Lag is fixed.
+* **EMA:** Center of gravity is front-loaded but has an infinite tail.
+* **ALMA:** You move the center. An offset of $0.85$ pushes the bulk of the weight to the most recent 15% of the window.
 
 This shift allows the indicator to capture momentum (high responsiveness) while the Gaussian decay kills high-frequency noise (smoothness). It behaves less like a lagging indicator and more like a mass-dampener system.
 
@@ -117,7 +117,7 @@ QuanTAlib validates against reference implementations that respect the Gaussian
 1. **Offset Abuse**: Setting offset to `0.99` creates a filter that barely filters. It tracks price so closely you might as well use `Price[0]`. Setting it to `0.5` makes it a centered moving average (great for smoothing, terrible for trading due to repainting if used as such, but ALMA does not repaint). The magic is in the `0.85` region.
 
 2. **Sigma Confusion**:
-   - $\sigma = 1$: The curve is flat. You have reinvented the Simple Moving Average (badly).
-   - $\sigma = 10$: The curve is a needle. You are sampling one specific bar in history.
+   * $\sigma = 1$: The curve is flat. You have reinvented the Simple Moving Average (badly).
+   * $\sigma = 10$: The curve is a needle. You are sampling one specific bar in history.
 
 3. **Cold Start**: ALMA requires a full window ($L$) to be mathematically valid. First $L-1$ bars are convergence noise. Ignore them.

lib/trends/bessel/Bessel.md

@@ -12,9 +12,9 @@ Originally derived from Friedrich Bessel’s work on Bessel polynomials and late
 
 In trading terms:
 
-- You keep the **relative timing** of swings.
-- You avoid overshoot and ringing common in sharper filters.
-- You accept a gentler roll-off as the price of cleaner turning points.
+* You keep the **relative timing** of swings.
+* You avoid overshoot and ringing common in sharper filters.
+* You accept a gentler roll-off as the price of cleaner turning points.
 
 QuanTAlib implements the **2nd-order low-pass** variant used in Ehlers-style digital filters.
 
@@ -22,31 +22,31 @@ QuanTAlib implements the **2nd-order low-pass** variant used in Ehlers-style dig
 
 BESSEL is implemented as a **2nd-order IIR filter** with a fixed structure:
 
-- State: last two filtered values plus last valid input
-- Behavior:
-  - Short warmup period (a few bars)
-  - Stable, monotonic smoothing
-  - Minimal overshoot on sharp transitions
+* State: last two filtered values plus last valid input
+* Behavior:
+  * Short warmup period (a few bars)
+  * Stable, monotonic smoothing
+  * Minimal overshoot on sharp transitions
 
 Conceptually:
 
-- High frequencies are attenuated gradually.
-- Phase is nearly linear in the passband, so local structures (peaks, troughs, breakout steps) keep their relative timing.
-- It runs as an **O(1)** streaming update:
-  - One input in, one output out, constant work per bar.
+* High frequencies are attenuated gradually.
+* Phase is nearly linear in the passband, so local structures (peaks, troughs, breakout steps) keep their relative timing.
+* It runs as an **O(1)** streaming update:
+  * One input in, one output out, constant work per bar.
 
 ### Specific Architectural Challenge
 
 The main tension is:
 
-- The design demands **IIR smoothness** and responsiveness.
-- Recursive instability or phase warping in turning zones cannot be tolerated.
+* The design demands **IIR smoothness** and responsiveness.
+* Recursive instability or phase warping in turning zones cannot be tolerated.
 
 BESSEL solves this by:
 
-- Fixing a 2nd-order topology with coefficients derived from the Bessel prototype.
-- Using a **safe minimum length** (at least 2) to keep coefficients in a numerically stable region.
-- Treating non-finite values via a last-valid-value cache so NaNs and infinities never poison the state.
+* Fixing a 2nd-order topology with coefficients derived from the Bessel prototype.
+* Using a **safe minimum length** (at least 2) to keep coefficients in a numerically stable region.
+* Treating non-finite values via a last-valid-value cache so NaNs and infinities never poison the state.
 
 ## Mathematical Foundation
 
@@ -70,17 +70,17 @@ $$ \text{BESSEL}[n] = c_1 s[n] + c_2\, \text{BESSEL}[n-1] + c_3\, \text{BESSEL}[
 
 with initialization:
 
-- For the first few bars, the filter output is seeded directly from the price (no recursion) to avoid transient garbage.
+* For the first few bars, the filter output is seeded directly from the price (no recursion) to avoid transient garbage.
 
 ### NaN and Infinity Handling
 
 For robustness:
 
-- Maintain a `LastValidValue` cache $v_{\text{last}}$.
-- For each input $x$:
-  - If $x$ is finite, set $v_{\text{last}} = x$.
-  - If $x$ is `NaN` or infinite, use $x \leftarrow v_{\text{last}}$.
-- The recursive update always runs on a finite input.
+* Maintain a `LastValidValue` cache $v_{\text{last}}$.
+* For each input $x$:
+  * If $x$ is finite, set $v_{\text{last}} = x$.
+  * If $x$ is `NaN` or infinite, use $x \leftarrow v_{\text{last}}$.
+* The recursive update always runs on a finite input.
 
 ## Performance Profile
 
@@ -111,9 +111,9 @@ Validation focuses on internal consistency between streaming, TSeries, and Span
 
 ### Common Pitfalls
 
-- **Expecting razor-sharp cutoff:** Bessel is **not** a Chebyshev or elliptic filter. Roll-off is gentler by design to preserve shape and timing. If you want violent attenuation of high-frequency noise, pick Butterworth, Chebyshev, or a band-pass.
-- **Over-smoothing with large length:** Very large $L$ values will still preserve shape, but you will delay turning points more than necessary. Typical sweet spot for daily data is $L \in [10, 30]$.
-- **Misinterpreting flat response as “weak” filter:** The goal is not to crush all noise. The goal is to keep enough structure that pattern recognition, divergence analysis, and multi-stream alignment still make sense.
-- **Ignoring NaN propagation:** If your upstream feed throws `NaN` or infinities and you do not clean it, BESSEL will fall back to the last valid value. This is intentional. If you want gaps instead, preprocess the series and pass explicit masked values.
+* **Expecting razor-sharp cutoff:** Bessel is **not** a Chebyshev or elliptic filter. Roll-off is gentler by design to preserve shape and timing. If you want violent attenuation of high-frequency noise, pick Butterworth, Chebyshev, or a band-pass.
+* **Over-smoothing with large length:** Very large $L$ values will still preserve shape, but you will delay turning points more than necessary. Typical sweet spot for daily data is $L \in [10, 30]$.
+* **Misinterpreting flat response as “weak” filter:** The goal is not to crush all noise. The goal is to keep enough structure that pattern recognition, divergence analysis, and multi-stream alignment still make sense.
+* **Ignoring NaN propagation:** If your upstream feed throws `NaN` or infinities and you do not clean it, BESSEL will fall back to the last valid value. This is intentional. If you want gaps instead, preprocess the series and pass explicit masked values.
 
 Used correctly, BESSEL gives you a **shape-faithful trend line** with clean timing and low overshoot, ideal for traders who care more about *when* than *how loudly* the filter shouts.

lib/trends/bilateral/Bilateral.md

@@ -17,8 +17,8 @@ The filter operates in two domains simultaneously:
 
 This dual-weighting mechanism ensures that:
 
-- Nearby prices with similar values have high influence (smoothing).
-- Distant prices or prices with very different values have low influence (edge preservation).
+* Nearby prices with similar values have high influence (smoothing).
+* Distant prices or prices with very different values have low influence (edge preservation).
 
 ### Complexity
 
@@ -32,18 +32,18 @@ $$ BF = \frac{\sum_{i=0}^{L-1} W_s(i) \cdot W_r(i) \cdot P_i}{\sum_{i=0}^{L-1} W
 
 Where:
 
-- $L$ is the length (period).
-- $P_i$ is the price at index $i$ (0 is current).
-- $W_s(i)$ is the spatial weight:
+* $L$ is the length (period).
+* $P_i$ is the price at index $i$ (0 is current).
+* $W_s(i)$ is the spatial weight:
     $$ W_s(i) = \exp\left(-\frac{i^2}{2\sigma_s^2}\right) $$
 
-- $W_r(i)$ is the range weight:
+* $W_r(i)$ is the range weight:
     $$ W_r(i) = \exp\left(-\frac{(P_0 - P_i)^2}{2\sigma_r^2}\right) $$
 
 Parameters:
 
-- $\sigma_s = \max(L \cdot \text{ratio}, 10^{-10})$
-- $\sigma_r = \max(\text{StDev}(P, L) \cdot \text{mult}, 10^{-10})$
+* $\sigma_s = \max(L \cdot \text{ratio}, 10^{-10})$
+* $\sigma_r = \max(\text{StDev}(P, L) \cdot \text{mult}, 10^{-10})$
 
 ## Performance Profile
 

lib/trends/blma/Blma.md

@@ -58,5 +58,5 @@ BLMA is validated against a reference implementation using the standard Blackman
 
 ### Common Pitfalls
 
-- **Lag**: BLMA has more lag than EMA or WMA because it suppresses the most recent data. It is a smoothing filter, not a leading indicator.
-- **Warmup**: During the first $N$ bars, the window expands dynamically. The full noise-suppression characteristics are only achieved after $N$ bars.
+* **Lag**: BLMA has more lag than EMA or WMA because it suppresses the most recent data. It is a smoothing filter, not a leading indicator.
+* **Warmup**: During the first $N$ bars, the window expands dynamically. The full noise-suppression characteristics are only achieved after $N$ bars.

lib/trends/butter/Butter.md

@@ -6,9 +6,9 @@ The Butterworth Filter is a signal processing tool designed to provide maximally
 
 ## Core Concepts
 
-- **Maximally flat response**: Provides smooth frequency response with no ripples in the passband, ensuring consistent filtering across all frequencies below the cutoff.
-- **Optimal roll-off**: Offers steeper attenuation of high frequencies than Bessel filters while maintaining better phase characteristics than Chebyshev filters.
-- **Market application**: Particularly effective for identifying underlying trends in noisy market conditions while introducing minimal waveform distortion.
+* **Maximally flat response**: Provides smooth frequency response with no ripples in the passband, ensuring consistent filtering across all frequencies below the cutoff.
+* **Optimal roll-off**: Offers steeper attenuation of high frequencies than Bessel filters while maintaining better phase characteristics than Chebyshev filters.
+* **Market application**: Particularly effective for identifying underlying trends in noisy market conditions while introducing minimal waveform distortion.
 
 The core innovation of the Butterworth filter is its mathematically optimal balance between opposing design constraints. The filter achieves the flattest possible frequency response in the passband without sacrificing roll-off steepness, providing traders with clean signals that maintain essential trend information while effectively eliminating random market noise.
 

lib/trends/conv/Conv.md

@@ -12,10 +12,10 @@ Convolution is the fundamental operation of digital signal processing (DSP). Whi
 
 CONV applies a sliding dot product between the data window and your custom kernel. The "physics" are entirely defined by the kernel you provide.
 
-- **Symmetric Kernel**: Zero phase shift (if centered correctly).
-- **Asymmetric Kernel**: Introduces lag or lead.
-- **Positive Weights**: Smoothing.
-- **Mixed Weights**: Differentiation or band-pass filtering.
+* **Symmetric Kernel**: Zero phase shift (if centered correctly).
+* **Asymmetric Kernel**: Introduces lag or lead.
+* **Positive Weights**: Smoothing.
+* **Mixed Weights**: Differentiation or band-pass filtering.
 
 ## Mathematical Foundation
 
@@ -25,8 +25,8 @@ $$ \text{CONV}_t = \sum_{i=0}^{N-1} P_{t-i} \cdot K_i $$
 
 Where:
 
-- $N$ is the length of the kernel.
-- $K_0$ multiplies the most recent price (or oldest, depending on convention; the QuanTAlib implementation aligns $K_0$ with the oldest data in the window and $K_{N-1}$ with the newest).
+* $N$ is the length of the kernel.
+* $K_0$ multiplies the most recent price (or oldest, depending on convention; the QuanTAlib implementation aligns $K_0$ with the oldest data in the window and $K_{N-1}$ with the newest).
 
 ## Performance Profile
 

lib/trends/ema/Ema.md

@@ -12,8 +12,8 @@ The EMA was brought to the financial world to solve the "drop-off effect" of the
 
 The EMA is defined by its smoothing factor, $\alpha$:
 
-- **High $\alpha$ (close to 1)**: Fast decay, responsive, noisy. Every tick matters. Your signal will fire at shadows.
-- **Low $\alpha$ (close to 0)**: Slow decay, smooth, laggy. You'll catch the trend, but you'll also be late to every party.
+* **High $\alpha$ (close to 1)**: Fast decay, responsive, noisy. Every tick matters. Your signal will fire at shadows.
+* **Low $\alpha$ (close to 0)**: Slow decay, smooth, laggy. You'll catch the trend, but you'll also be late to every party.
 
 The relationship between period $N$ and $\alpha$ is: $\alpha = \frac{2}{N + 1}$. A 10-period EMA has $\alpha \approx 0.18$. A 100-period EMA has $\alpha \approx 0.02$. The period is just a human-friendly way to express exponential decay.
 

lib/trends/kama/Kama.md

@@ -13,9 +13,9 @@ Perry Kaufman introduced KAMA in his book *Smarter Trading* (1998). It was one o
 KAMA uses an **Efficiency Ratio (ER)** to drive the smoothing constant of an EMA.
 
 1. **Efficiency Ratio (ER)**: Measures the fractal efficiency of price movement.
-    - $ER = \frac{\text{Net Change}}{\text{Sum of Absolute Changes}}$
-    - ER approaches 1.0 in a straight line trend.
-    - ER approaches 0.0 in pure noise.
+    * $ER = \frac{\text{Net Change}}{\text{Sum of Absolute Changes}}$
+    * ER approaches 1.0 in a straight line trend.
+    * ER approaches 0.0 in pure noise.
 2. **Smoothing Constant (SC)**: Scales between a "Fast" EMA (e.g., 2-period) and a "Slow" EMA (e.g., 30-period) based on ER.
 
 ## Mathematical Foundation

lib/trends/lsma/.github/instructions/codacy.instructions.md

@@ -7,73 +7,73 @@ applyTo: '**'
 Configuration for AI behavior when interacting with Codacy's MCP Server
 
 ## using any tool that accepts the arguments: `provider`, `organization`, or `repository`
-- ALWAYS use:
- - provider: gh
- - organization: mihakralj
- - repository: QuanTAlib
-- Avoid calling `git remote -v` unless really necessary
+* ALWAYS use:
+ * provider: gh
+ * organization: mihakralj
+ * repository: QuanTAlib
+* Avoid calling `git remote -v` unless really necessary
 
 ## CRITICAL: After ANY successful `edit_file` or `reapply` operation
-- YOU MUST IMMEDIATELY run the `codacy_cli_analyze` tool from Codacy's MCP Server for each file that was edited, with:
- - `rootPath`: set to the workspace path
- - `file`: set to the path of the edited file
- - `tool`: leave empty or unset
-- If any issues are found in the new edits, propose and apply fixes for them.
-- > NOTE: Failure to follow this rule is considered a critical error.
+* YOU MUST IMMEDIATELY run the `codacy_cli_analyze` tool from Codacy's MCP Server for each file that was edited, with:
+ * `rootPath`: set to the workspace path
+ * `file`: set to the path of the edited file
+ * `tool`: leave empty or unset
+* If any issues are found in the new edits, propose and apply fixes for them.
+* > NOTE: Failure to follow this rule is considered a critical error.
 
 ## When you tried to run the `codacy_cli_analyze` tool and the Codacy CLI is not installed
-- Ask the user 'Codacy CLI is not installed. Would you like me to install it now?'
-- If the user responds with "yes", run the `codacy_cli_install` tool and then continue with the original task
-- If the user responds with "no", instruct the user that they can disable automatic analysis in the extension settings
-- Wait for the user to respond before proceeding with any other actions
+* Ask the user 'Codacy CLI is not installed. Would you like me to install it now?'
+* If the user responds with "yes", run the `codacy_cli_install` tool and then continue with the original task
+* If the user responds with "no", instruct the user that they can disable automatic analysis in the extension settings
+* Wait for the user to respond before proceeding with any other actions
 
 ## After every response
-- If you made any file edits in this conversation, verify you ran `codacy_cli_analyze` tool from Codacy's MCP Server
+* If you made any file edits in this conversation, verify you ran `codacy_cli_analyze` tool from Codacy's MCP Server
 
 ## When there are no Codacy MCP Server tools available, or the MCP Server is not reachable
-- Suggest the user the following troubleshooting steps:
- - Try to reset the MCP on the extension
- - If the user is using VSCode, suggest them to review their Copilot > MCP settings in Github, under their organization or personal account. Refer them to Settings > Copilot > Enable MCP servers in Copilot. Suggested URL (https://github.com/settings/copilot/features) or https://github.com/organizations/{organization-name}/settings/copilot/features (This can only be done by their organization admins / owners)
-- If none of the above steps work, suggest the user to contact Codacy support
+* Suggest the user the following troubleshooting steps:
+ * Try to reset the MCP on the extension
+ * If the user is using VSCode, suggest them to review their Copilot > MCP settings in Github, under their organization or personal account. Refer them to Settings > Copilot > Enable MCP servers in Copilot. Suggested URL (https://github.com/settings/copilot/features) or https://github.com/organizations/{organization-name}/settings/copilot/features (This can only be done by their organization admins / owners)
+* If none of the above steps work, suggest the user to contact Codacy support
 
 ## Trying to call a tool that needs a rootPath as a parameter
-- Always use the standard, non-URL-encoded file system path
+* Always use the standard, non-URL-encoded file system path
 
 ## CRITICAL: Dependencies and Security Checks
-- IMMEDIATELY after ANY of these actions:
- - Running npm/yarn/pnpm install
- - Adding dependencies to package.json
- - Adding requirements to requirements.txt
- - Adding dependencies to pom.xml
- - Adding dependencies to build.gradle
- - Any other package manager operations
-- You MUST run the `codacy_cli_analyze` tool with:
- - `rootPath`: set to the workspace path
- - `tool`: set to "trivy"
- - `file`: leave empty or unset
-- If any vulnerabilities are found because of the newly added packages:
- - Stop all other operations
- - Propose and apply fixes for the security issues
- - Only continue with the original task after security issues are resolved
-- EXAMPLE:
- - After: npm install react-markdown
- - Do: Run codacy_cli_analyze with trivy
- - Before: Continuing with any other tasks
+* IMMEDIATELY after ANY of these actions:
+ * Running npm/yarn/pnpm install
+ * Adding dependencies to package.json
+ * Adding requirements to requirements.txt
+ * Adding dependencies to pom.xml
+ * Adding dependencies to build.gradle
+ * Any other package manager operations
+* You MUST run the `codacy_cli_analyze` tool with:
+ * `rootPath`: set to the workspace path
+ * `tool`: set to "trivy"
+ * `file`: leave empty or unset
+* If any vulnerabilities are found because of the newly added packages:
+ * Stop all other operations
+ * Propose and apply fixes for the security issues
+ * Only continue with the original task after security issues are resolved
+* EXAMPLE:
+ * After: npm install react-markdown
+ * Do: Run codacy_cli_analyze with trivy
+ * Before: Continuing with any other tasks
 
 ## General
-- Repeat the relevant steps for each modified file.
-- "Propose fixes" means to both suggest and, if possible, automatically apply the fixes.
-- You MUST NOT wait for the user to ask for analysis or remind you to run the tool.
-- Do not run `codacy_cli_analyze` looking for changes in duplicated code or code complexity metrics.
-- Complexity metrics are different from complexity issues. When trying to fix complexity in a repository or file, focus on solving the complexity issues and ignore the complexity metric.
-- Do not run `codacy_cli_analyze` looking for changes in code coverage.
-- Do not try to manually install Codacy CLI using either brew, npm, npx, or any other package manager.
-- If the Codacy CLI is not installed, just run the `codacy_cli_analyze` tool from Codacy's MCP Server.
-- When calling `codacy_cli_analyze`, only send provider, organization and repository if the project is a git repository.
+* Repeat the relevant steps for each modified file.
+* "Propose fixes" means to both suggest and, if possible, automatically apply the fixes.
+* You MUST NOT wait for the user to ask for analysis or remind you to run the tool.
+* Do not run `codacy_cli_analyze` looking for changes in duplicated code or code complexity metrics.
+* Complexity metrics are different from complexity issues. When trying to fix complexity in a repository or file, focus on solving the complexity issues and ignore the complexity metric.
+* Do not run `codacy_cli_analyze` looking for changes in code coverage.
+* Do not try to manually install Codacy CLI using either brew, npm, npx, or any other package manager.
+* If the Codacy CLI is not installed, just run the `codacy_cli_analyze` tool from Codacy's MCP Server.
+* When calling `codacy_cli_analyze`, only send provider, organization and repository if the project is a git repository.
 
 ## Whenever a call to a Codacy tool that uses `repository` or `organization` as a parameter returns a 404 error
-- Offer to run the `codacy_setup_repository` tool to add the repository to Codacy
-- If the user accepts, run the `codacy_setup_repository` tool
-- Do not ever try to run the `codacy_setup_repository` tool on your own
-- After setup, immediately retry the action that failed (only retry once)
+* Offer to run the `codacy_setup_repository` tool to add the repository to Codacy
+* If the user accepts, run the `codacy_setup_repository` tool
+* Do not ever try to run the `codacy_setup_repository` tool on your own
+* After setup, immediately retry the action that failed (only retry once)
 ---

lib/trends/lsma/Lsma.md

@@ -12,9 +12,9 @@ Linear regression is as old as Gauss (c. 1809). Applying it as a moving window t
 
 LSMA is computationally heavier than an SMA because it minimizes the sum of squared errors for a line equation $y = mx + b$.
 
-- **Slope ($m$)**: Represents the trend strength/direction.
-- **Intercept ($b$)**: Represents the value at the start of the window.
-- **Endpoint**: The value at the current bar ($y = m \times 0 + b$ in our coordinate system where current bar is 0).
+* **Slope ($m$)**: Represents the trend strength/direction.
+* **Intercept ($b$)**: Represents the value at the start of the window.
+* **Endpoint**: The value at the current bar ($y = m \times 0 + b$ in our coordinate system where current bar is 0).
 
 ## Mathematical Foundation
 
@@ -53,6 +53,7 @@ Validated against Skender.
 
 | **Tulip** | N/A | Not implemented. |
 | **Ooples** | N/A | Not implemented. |
+
 ### Common Pitfalls
 
 1. **Overshoot**: Because it projects a trend, LSMA will overshoot significantly when the trend reverses. It assumes the trend continues.

lib/trends/mama/Mama.md

@@ -17,8 +17,8 @@ The architecture is a direct application of the Hilbert Transform Homodyne Discr
 1. **Hilbert Transform**: Decomposes price into In-Phase (I) and Quadrature (Q) components.
 2. **Phase Calculation**: Computes the phase angle from I and Q.
 3. **Alpha Adaptation**: The smoothing alpha is derived from the rate of change of the phase.
-    - Fast Phase Change = High Alpha (Fast MA).
-    - Slow Phase Change = Low Alpha (Slow MA).
+    * Fast Phase Change = High Alpha (Fast MA).
+    * Slow Phase Change = Low Alpha (Slow MA).
 
 Ehlers' genius was recognizing that market cycles have *phase*. When phase advances steadily (trending), use slow alpha. When phase stutters or reverses (cycle breakdown), use fast alpha. This is why MAMA responds instantly to trend changes while staying smooth in established trends.
 
@@ -168,9 +168,9 @@ _state.Phase = Math.Atan2(q1, i1);
 
 Benefits:
 
-- No conditional branches (atan2 handles i1=0 internally)
-- Proper quadrant handling (range [-π, π] instead of [-π/2, π/2])
-- Fewer edge cases during quadrant crossings
+* No conditional branches (atan2 handles i1=0 internally)
+* Proper quadrant handling (range [-π, π] instead of [-π/2, π/2])
+* Fewer edge cases during quadrant crossings
 
 The absolute value in period calculation ensures we always get positive periods, even when the angle is in quadrants 3 or 4. Ehlers' original could produce negative periods that got clamped to 6.0. We handle it mathematically.
 
@@ -180,17 +180,17 @@ QuanTALib MAMA values will diverge slightly from TA-Lib and Skender libraries. E
 
 **Early period (bars 0-100):**
 
-- ±1-5% difference due to initialization and coefficient accumulation
+* ±1-5% difference due to initialization and coefficient accumulation
 
 **Steady state (bars 100+):**
 
-- ±0.01-0.05% difference from constant precision errors
-- Larger spikes (±0.1-1%) during quadrant transitions where atan2's range helps
+* ±0.01-0.05% difference from constant precision errors
+* Larger spikes (±0.1-1%) during quadrant transitions where atan2's range helps
 
 **Trading signals:**
 
-- MAMA/FAMA crossovers will match 98%+ of the time
-- Exact numerical values will differ
+* MAMA/FAMA crossovers will match 98%+ of the time
+* Exact numerical values will differ
 
 This is a feature, not a bug. QuanTAlib is computing the mathematically correct MAMA. Everyone else is computing an approximation that accumulated 20 years of copy-paste errors.
 

lib/trends/mgdi/Mgdi.md

@@ -12,8 +12,8 @@ Published by John McGinley in the *Market Technicians Association Journal* (1991
 
 The MGDI formula is unique. It looks like an EMA, but the smoothing constant is dynamic and depends on the ratio of Price to the previous MGDI value.
 
-- **Price > MGDI**: The market is speeding up (or recovering). The denominator grows, slowing the adjustment to prevent overshoot.
-- **Price < MGDI**: The market is falling. The formula adapts to hug the price without breaking.
+* **Price > MGDI**: The market is speeding up (or recovering). The denominator grows, slowing the adjustment to prevent overshoot.
+* **Price < MGDI**: The market is falling. The formula adapts to hug the price without breaking.
 
 ## Mathematical Foundation
 
@@ -21,9 +21,9 @@ $$ \text{MGDI}_t = \text{MGDI}_{t-1} + \frac{P_t - \text{MGDI}_{t-1}}{k \times N
 
 Where:
 
-- $N$ is the period (roughly analogous to an EMA period).
-- $k$ is a constant (usually 0.6).
-- The term $(P_t / \text{MGDI}_{t-1})^4$ is the accelerator/decelerator.
+* $N$ is the period (roughly analogous to an EMA period).
+* $k$ is a constant (usually 0.6).
+* The term $(P_t / \text{MGDI}_{t-1})^4$ is the accelerator/decelerator.
 
 ## Performance Profile
 
@@ -51,6 +51,7 @@ Validated against Skender and Ooples.
 | **TA-Lib** | N/A | Not implemented |
 
 | **Tulip** | N/A | Not implemented. |
+
 ### Common Pitfalls
 
 1. **Not an EMA**: Do not treat it like an EMA. It does not have a fixed alpha.

lib/trends/ssf/Ssf.md

@@ -12,9 +12,9 @@ John Ehlers introduced the Super Smooth Filter to address the limitations of tra
 
 The SSF is an Infinite Impulse Response (IIR) filter.
 
-- **2-Pole Design**: Uses two poles in the Z-domain to create a sharper cutoff than single-pole filters (like EMA).
-- **Butterworth Characteristic**: Maximally flat passband response, minimizing distortion of the trend.
-- **Minimal Lag**: Despite its smoothing power, it reacts relatively quickly to significant price changes.
+* **2-Pole Design**: Uses two poles in the Z-domain to create a sharper cutoff than single-pole filters (like EMA).
+* **Butterworth Characteristic**: Maximally flat passband response, minimizing distortion of the trend.
+* **Minimal Lag**: Despite its smoothing power, it reacts relatively quickly to significant price changes.
 
 ## Mathematical Foundation
 
@@ -34,9 +34,9 @@ $$ \text{SSF}_t = c_1 \cdot \frac{P_t + P_{t-1}}{2} + c_2 \cdot \text{SSF}_{t-1}
 
 Where:
 
-- $P_t$ is the current price.
-- $P_{t-1}$ is the previous price.
-- $\text{SSF}_{t-1}$ and $\text{SSF}_{t-2}$ are the previous filter outputs.
+* $P_t$ is the current price.
+* $P_{t-1}$ is the previous price.
+* $\text{SSF}_{t-1}$ and $\text{SSF}_{t-2}$ are the previous filter outputs.
 
 > **Note:** This implementation uses high-precision constants (`Math.Sqrt(2)` and `Math.PI`) rather than the approximations (`1.414` and `3.14159`) found in some reference implementations.
 

lib/trends/usf/Usf.md

@@ -36,9 +36,9 @@ $$ USF_t = (1 - c_1) \cdot src_t + (2 \cdot c_1 - c_2) \cdot src_{t-1} - (c_1 +
 
 Where:
 
-- $src_t$ is the input value at time $t$.
-- $USF_t$ is the filter output at time $t$.
-- $period$ is the smoothing period.
+* $src_t$ is the input value at time $t$.
+* $USF_t$ is the filter output at time $t$.
+* $period$ is the smoothing period.
 
 ## Performance Profile
 
@@ -64,8 +64,8 @@ Where:
 
 ### Common Pitfalls
 
-- **Period Sensitivity**: Like all filters, the choice of period is critical. A period that is too short may not filter enough noise, while a period that is too long may introduce lag or miss important trend changes.
-- **Warmup**: The filter requires a few bars to stabilize. The `IsHot` property indicates when the filter has processed enough data to be considered reliable.
+* **Period Sensitivity**: Like all filters, the choice of period is critical. A period that is too short may not filter enough noise, while a period that is too long may introduce lag or miss important trend changes.
+* **Warmup**: The filter requires a few bars to stabilize. The `IsHot` property indicates when the filter has processed enough data to be considered reliable.
 
 ## C# Usage Examples