Chande Forecast Oscillator (CFO) indicator and strategy added. (#320)

# Describe Request

Chande Forecast Oscillator (CFO) indicator and strategy added.

# Change Type

New indicator and strategy.

Author: cinar

.gitignore

@@ -26,3 +26,5 @@ go.work
 # GoLand project
 .idea
 
+# GitHub conductor
+conductor

conductor/archive/cfo_implementation_20260221/index.md

@@ -0,0 +1 @@
+# Track cfo_implementation_20260221 Context\n\n- [Specification](./spec.md)\n- [Implementation Plan](./plan.md)\n- [Metadata](./metadata.json)

conductor/archive/cfo_implementation_20260221/metadata.json

@@ -0,0 +1 @@
+{\n  "track_id": "cfo_implementation_20260221",\n  "type": "feature",\n  "status": "new",\n  "created_at": "2026-02-21T00:00:00Z",\n  "updated_at": "2026-02-21T00:00:00Z",\n  "description": "Implement Chande Forecast Oscillator (CFO) indicator and strategy"\n}

conductor/archive/cfo_implementation_20260221/plan.md

@@ -0,0 +1,27 @@
+# Implementation Plan: Chande Forecast Oscillator (CFO)
+
+## Phase 1: Indicator Development
+- [x] Task: Write unit tests for CFO indicator (10f2bbd)
+    - [x] Create `trend/cfo_test.go`
+    - [x] Define test cases with CSV test data
+- [x] Task: Implement CFO indicator (4bdefbc)
+    - [x] Create `trend/cfo.go`
+    - [x] Implement linear regression forecast logic (reuse `helper` if possible)
+    - [x] Implement CFO calculation using channels
+- [x] Task: Conductor - User Manual Verification 'Phase 1: Indicator Development' (Protocol in workflow.md) (4bdefbc)
+
+## Phase 2: Strategy Development
+- [x] Task: Write unit tests for CFO strategy (4228b3f)
+    - [x] Create `strategy/trend/cfo_strategy_test.go`
+    - [x] Define test cases for buy/sell signals
+- [x] Task: Implement CFO strategy (990090d)
+    - [x] Create `strategy/trend/cfo_strategy.go`
+    - [x] Implement logic using CFO indicator
+- [x] Task: Conductor - User Manual Verification 'Phase 2: Strategy Development' (Protocol in workflow.md) (990090d)
+
+## Phase 3: Integration and Backtesting
+- [x] Task: Register CFO in backtest tools (f13cc0d)
+    - [x] Update `cmd/indicator-backtest` if necessary
+- [x] Task: Run backtest and verify results (f13cc0d)
+    - [x] Use sample asset data to verify strategy performance
+- [x] Task: Conductor - User Manual Verification 'Phase 3: Integration and Backtesting' (Protocol in workflow.md) (f13cc0d)

conductor/archive/cfo_implementation_20260221/spec.md

@@ -0,0 +1,13 @@
+# Specification: Chande Forecast Oscillator (CFO)
+
+## Overview
+The Chande Forecast Oscillator (CFO) is a momentum indicator that measures the difference between a security's price and its linear regression forecast. It helps identify overbought or oversold conditions and potential trend reversals.
+
+## Indicator Logic
+- **Calculation:** `CFO = ((Price - Forecast) / Price) * 100`
+- **Forecast:** Linear regression forecast for the current price based on a specified period.
+- **Period:** Number of data points used for the linear regression calculation.
+
+## Strategy Logic
+- **Buy Signal:** CFO crosses above a specified threshold (e.g., 0).
+- **Sell Signal:** CFO crosses below a specified threshold (e.g., 0).

conductor/code_styleguides/general.md

@@ -0,0 +1,23 @@
+# General Code Style Principles
+
+This document outlines general coding principles that apply across all languages and frameworks used in this project.
+
+## Readability
+- Code should be easy to read and understand by humans.
+- Avoid overly clever or obscure constructs.
+
+## Consistency
+- Follow existing patterns in the codebase.
+- Maintain consistent formatting, naming, and structure.
+
+## Simplicity
+- Prefer simple solutions over complex ones.
+- Break down complex problems into smaller, manageable parts.
+
+## Maintainability
+- Write code that is easy to modify and extend.
+- Minimize dependencies and coupling.
+
+## Documentation
+- Document *why* something is done, not just *what*.
+- Keep documentation up-to-date with code changes.

conductor/code_styleguides/go.md

@@ -0,0 +1,48 @@
+# Effective Go Style Guide Summary
+
+This document summarizes key rules and best practices from the official "Effective Go" guide for writing idiomatic Go code.
+
+## 1. Formatting
+- **`gofmt`:** All Go code **must** be formatted with `gofmt` (or `go fmt`). This is a non-negotiable, automated standard.
+- **Indentation:** Use tabs for indentation (`gofmt` handles this).
+- **Line Length:** Go has no strict line length limit. Let `gofmt` handle line wrapping.
+
+## 2. Naming
+- **`MixedCaps`:** Use `MixedCaps` or `mixedCaps` for multi-word names. Do not use underscores.
+- **Exported vs. Unexported:** Names starting with an uppercase letter are exported (public). Names starting with a lowercase letter are not exported (private).
+- **Package Names:** Short, concise, single-word, lowercase names.
+- **Getters:** Do not name getters with a `Get` prefix. A getter for a field named `owner` should be named `Owner()`.
+- **Interface Names:** One-method interfaces are named by the method name plus an `-er` suffix (e.g., `Reader`, `Writer`).
+
+## 3. Control Structures
+- **`if`:** No parentheses around the condition. Braces are mandatory. Can include an initialization statement (e.g., `if err := file.Chmod(0664); err != nil`).
+- **`for`:** Go's only looping construct. Unifies `for` and `while`. Use `for...range` to iterate over slices, maps, strings, and channels.
+- **`switch`:** More general than in C. Cases do not fall through by default (use `fallthrough` explicitly). Can be used without an expression to function as a cleaner `if-else-if` chain.
+
+## 4. Functions
+- **Multiple Returns:** Functions can return multiple values. This is the standard way to return a result and an error (e.g., `value, err`).
+- **Named Result Parameters:** Return parameters can be named. This can make code clearer and more concise.
+- **`defer`:** Schedules a function call to be run immediately before the function executing `defer` returns. Use it for cleanup tasks like closing files.
+
+## 5. Data
+- **`new` vs. `make`:**
+  - `new(T)`: Allocates memory for a new item of type `T`, zeroes it, and returns a pointer (`*T`).
+  - `make(T, ...)`: Creates and initializes slices, maps, and channels only. Returns an initialized value of type `T` (not a pointer).
+- **Slices:** The preferred way to work with sequences. They are more flexible than arrays.
+- **Maps:** Use the "comma ok" idiom to check for the existence of a key: `value, ok := myMap[key]`.
+
+## 6. Interfaces
+- **Implicit Implementation:** A type implements an interface by implementing its methods. No `implements` keyword is needed.
+- **Small Interfaces:** Prefer many small interfaces over one large one. The standard library is full of single-method interfaces (e.g., `io.Reader`).
+
+## 7. Concurrency
+- **Share Memory By Communicating:** This is the core philosophy. Do not communicate by sharing memory; instead, share memory by communicating.
+- **Goroutines:** Lightweight, concurrently executing functions. Start one with the `go` keyword.
+- **Channels:** Typed conduits for communication between goroutines. Use `make` to create them.
+
+## 8. Errors
+- **`error` type:** The built-in `error` interface is the standard way to handle errors.
+- **Explicit Error Handling:** Do not discard errors with the blank identifier (`_`). Check for errors explicitly.
+- **`panic`:** Reserved for truly exceptional, unrecoverable situations. Generally, libraries should not panic.
+
+*Source: [Effective Go](https://go.dev/doc/effective_go)*

conductor/code_styleguides/html-css.md

@@ -0,0 +1,49 @@
+# Google HTML/CSS Style Guide Summary
+
+This document summarizes key rules and best practices from the Google HTML/CSS Style Guide.
+
+## 1. General Rules
+- **Protocol:** Use HTTPS for all embedded resources.
+- **Indentation:** Indent by 2 spaces. Do not use tabs.
+- **Capitalization:** Use only lowercase for all code (element names, attributes, selectors, properties).
+- **Trailing Whitespace:** Remove all trailing whitespace.
+- **Encoding:** Use UTF-8 (without a BOM). Specify `<meta charset="utf-8">` in HTML.
+
+## 2. HTML Style Rules
+- **Document Type:** Use `<!doctype html>`.
+- **HTML Validity:** Use valid HTML.
+- **Semantics:** Use HTML elements according to their intended purpose (e.g., use `<p>` for paragraphs, not for spacing).
+- **Multimedia Fallback:** Provide `alt` text for images and transcripts/captions for audio/video.
+- **Separation of Concerns:** Strictly separate structure (HTML), presentation (CSS), and behavior (JavaScript). Link to CSS and JS from external files.
+- **`type` Attributes:** Omit `type` attributes for stylesheets (`<link>`) and scripts (`<script>`).
+
+## 3. HTML Formatting Rules
+- **General:** Use a new line for every block, list, or table element, and indent its children.
+- **Quotation Marks:** Use double quotation marks (`""`) for attribute values.
+
+## 4. CSS Style Rules
+- **CSS Validity:** Use valid CSS.
+- **Class Naming:** Use meaningful, generic names. Separate words with a hyphen (`-`).
+  - **Good:** `.video-player`, `.site-navigation`
+  - **Bad:** `.vid`, `.red-text`
+- **ID Selectors:** Avoid using ID selectors for styling. Prefer class selectors.
+- **Shorthand Properties:** Use shorthand properties where possible (e.g., `padding`, `font`).
+- **`0` and Units:** Omit units for `0` values (e.g., `margin: 0;`).
+- **Leading `0`s:** Always include leading `0`s for decimal values (e.g., `font-size: 0.8em;`).
+- **Hexadecimal Notation:** Use 3-character hex notation where possible (e.g., `#fff`).
+- **`!important`:** Avoid using `!important`.
+
+## 5. CSS Formatting Rules
+- **Declaration Order:** Alphabetize declarations within a rule.
+- **Indentation:** Indent all block content.
+- **Semicolons:** Use a semicolon after every declaration.
+- **Spacing:**
+  - Use a space after a property name's colon (`font-weight: bold;`).
+  - Use a space between the last selector and the opening brace (`.foo {`).
+  - Start a new line for each selector and declaration.
+- **Rule Separation:** Separate rules with a new line.
+- **Quotation Marks:** Use single quotes (`''`) for attribute selectors and property values (e.g., `[type='text']`).
+
+**BE CONSISTENT.** When editing code, match the existing style.
+
+*Source: [Google HTML/CSS Style Guide](https://google.github.io/styleguide/htmlcssguide.html)*

conductor/index.md

@@ -0,0 +1,14 @@
+# Project Context
+
+## Definition
+- [Product Definition](./product.md)
+- [Product Guidelines](./product-guidelines.md)
+- [Tech Stack](./tech-stack.md)
+
+## Workflow
+- [Workflow](./workflow.md)
+- [Code Style Guides](./code_styleguides/)
+
+## Management
+- [Tracks Registry](./tracks.md)
+- [Tracks Directory](./tracks/)

conductor/product-guidelines.md

@@ -0,0 +1,24 @@
+# Product Guidelines: Indicator
+
+## Core Principles
+- **Reliability:** All financial calculations must be accurate and well-tested.
+- **Performance:** Indicators and strategies must be efficient, especially when processing large datasets.
+- **Maintainability:** Code should be modular, documented, and easy to extend.
+- **Transparency:** All algorithms and logic should be clear and well-documented.
+
+## Prose & Documentation
+- **Clear & Concise:** Use simple language to explain complex financial concepts.
+- **Technical Accuracy:** Ensure all technical terms and financial formulas are used correctly.
+- **Consistent Terminology:** Use consistent naming conventions across the library and documentation.
+- **Comprehensive Examples:** Provide clear, working examples for all indicators and strategies.
+
+## User Experience (API Design)
+- **Idiomatic Go:** Follow standard Go idioms and best practices for API design.
+- **Fluent APIs:** Prefer clear and intuitive interfaces for configuring indicators and strategies.
+- **Error Handling:** Provide descriptive error messages to help users diagnose issues.
+- **Configurability:** All indicators and strategies should be fully configurable with sensible defaults (if applicable).
+
+## Testing & Quality
+- **High Coverage:** Target at least 90% code coverage for all indicators and strategies.
+- **Data-Driven Tests:** Use CSV-based test data for validating calculations.
+- **Regression Testing:** Ensure new changes don't break existing functionality.