Chidi cont work

.cursor/rules/coding-standards.mdc

@@ -0,0 +1,58 @@
+---
+description: Project coding standards — commits, type hints, dates, docstrings, naming, dataclasses
+alwaysApply: true
+---
+
+# Coding Standards
+
+## Commit Requests (Always-On)
+
+When the user asks for a commit:
+
+- Generate a commit strategy first; separate changes by concern before committing.
+- For each planned commit, state what will be committed (files/hunks) and the commit message.
+- Keep unrelated concerns in separate commits.
+- Only commit when explicitly requested; never commit proactively.
+- Follow the detailed workflow in `.cursor/skills/commit-strategy/SKILL.md`.
+
+## Type Hints
+
+- Use complete type hints for all function parameters and return values.
+- Use `Union[datetime, str]` for date parameters that accept multiple formats.
+- Use `Optional[T]` for nullable parameters.
+- Import from `typing`: `Optional, Union, List, Dict, Tuple, ClassVar`.
+
+## Date/Time Conversion
+
+- **Always use `to_datetime` from `trade.helpers.helper`** — never `datetime.strptime()` or `pd.to_datetime()` directly.
+- Import: `from trade.helpers.helper import to_datetime`
+- Handles single values and iterables; tries `%Y-%m-%d` first, then lets pandas guess; supports optional `format`.
+
+## Docstrings (Always-On for Python)
+
+Mandatory for every Python file created or edited. Follow PEP 257 and Google-style sections.
+
+- Every module, class, function, and method (including `__init__` and private helpers) must have a docstring with a concise summary line.
+- Add `Args`, `Returns`, and `Raises` when applicable; include `Examples` with executable usage when practical.
+- Keep docstrings factual; update stale docstrings in the same edited scope.
+- For detailed templates, use `.github/skills/docstring-standards/SKILL.md`.
+
+### Module-Level Docstring Format
+
+1. One-sentence summary ending with a period.
+2. Blank line, then a 2–4 line overview paragraph.
+3. Blank line, then structured sections with trailing colons: Core Classes, Core Dataclasses, Core Functions, Processing Flow, Risk/Assumptions, Caching Strategy, Usage (as applicable).
+4. Usage section: short doctest-style snippet when practical.
+
+## Naming Conventions
+
+- **Classes:** Managers end with `Manager`; results end with `Result`; configs end with `Config`.
+- **Methods:** `get_*` for retrieval; `_load_*` for private loading; `_compute_*` for calculations.
+- **Variables:** `_str` suffix for string dates (`start_str`); `_dt` suffix for date objects (`start_dt`).
+
+## Dataclasses
+
+- Prefer `@dataclass` for data containers.
+- Use pydantic `@dataclass` for strict validation (`from pydantic.dataclasses import dataclass as pydantic_dataclass`).
+- Result classes inherit from base `Result`.
+- Use `frozen=True, slots=True` for immutable configs (e.g., `CacheSpec`).

.cursor/skills/commit-strategy/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: commit-strategy
+description: >-
+  Plans and executes git commits with concern-based grouping, pre-commit scan,
+  and safe git workflow. Use when the user asks to commit, create commits, propose
+  a commit plan, stage changes, or review changes for commit.
+---
+
+# Commit Strategy
+
+## Project Context
+
+Before planning or executing commits, read `.cursor/rules/coding-standards.mdc` for repo-specific coding standards and commit triggers. Match commit message areas and conventions to that rule and recent `git log` output.
+
+## When to Use
+
+- User explicitly asks to commit, stage, or propose commits.
+- User asks for a commit plan or message review.
+- **Do not** commit proactively. **Do not** activate for general git questions unless committing is involved.
+
+## Objectives
+
+- Separate changes into the most relevant concerns.
+- Produce a clear commit strategy before committing.
+- Ensure each commit is cohesive, minimal, and reversible.
+
+## Required Workflow
+
+### 1. Inspect (run in parallel)
+
+From the repo root that has changes:
+
+```bash
+git status
+git diff
+git log -10 --oneline
+```
+
+If scoping a branch: `git diff main...HEAD` (or the repo default base).
+
+Multi-root workspace: confirm which repo has changes before planning.
+
+### 2. Pre-Commit Quality Scan
+
+Scan changed files only:
+
+- Potential bugs and logic failures
+- Misspellings (strings, docs, logs)
+- Commented-out code blocks (not plain explanatory comments)
+- Debug artifacts (`print`, `pdb`, local paths)
+- Secrets and credential files — warn and **exclude** from commit
+
+### 3. Group by Concern
+
+- One concern per commit: feature, bugfix, refactor, docs, tests, config, tooling
+- Split by subsystem when changes are independent
+- Keep tests with the behavior they verify
+- Isolate formatting, IDE settings, and tooling config when mixed with code
+- Order commits: base/refactor first, then dependent changes
+- No empty commits — if nothing to commit, say so and stop
+
+### 4. Present Strategy (before executing)
+
+Use this template:
+
+**0. Pre-Commit Scan**
+- Potential bugs: \<findings or "none"\>
+- Logic failures: \<findings or "none"\>
+- Misspellings: \<findings or "none"\>
+- Commented-out code blocks: \<findings or "none"\>
+- Excluded files: \<files left unstaged, with reason\>
+
+**N. Commit N**
+- Scope: \<files/hunks\>
+- Concern: \<single concern\>
+- Why: \<brief grouping rationale\>
+- Message: \<commit message\>
+
+### 5. Execute (only after explicit user approval)
+
+For each planned commit, sequentially:
+
+1. Stage only that commit's files
+2. Commit via HEREDOC:
+
+```bash
+git commit -m "$(cat <<'EOF'
+<area>: <imperative message>
+
+EOF
+)"
+```
+
+3. Run `git status` to verify
+4. Repeat for remaining commits; final `git status` when done
+
+## Commit Message Rules
+
+- Imperative mood; concise subject (~50–72 chars)
+- Format: `<area>: <action>`
+- Explain intent, not implementation noise
+- Match recent repo style from `git log` when unclear
+
+## Git Safety
+
+- Never update git config
+- Never `--no-verify`, `--no-gpg-sign`, force push, or hard reset unless user explicitly asks
+- Never force push to `main`/`master` — warn if requested
+- Never push unless explicitly asked
+- Never use interactive git (`-i` flags)
+- **Amend only if all apply:** user requested amend (or hook auto-modified files after your successful commit); HEAD was created by you this session; commit not pushed
+- If commit fails or hook rejects: fix and create a **new** commit — do not amend
+
+## Examples
+
+**Bug fix + regression (one commit):**
+- Scope: `path/to/module.py`, `path/to/test_module.py`
+- Message: `riskmanager: fix quantity math in pnl monitor`
+
+**Code + IDE config (two commits):**
+1. `datamanager: add forward timeseries caching`
+2. `config: update vscode python settings`

.github/copilot-instructions.md

@@ -5,6 +5,16 @@ This is a quantitative trading system focused on options pricing and risk manage
 
 ## Code Style & Standards
 
+### Commit Requests (Always-On)
+- Every time the user asks for a commit, first generate a commit strategy.
+- Separate changes into the most relevant concerns before committing.
+- For each planned commit, state:
+    - What will be committed (files/hunks grouped by concern).
+    - The commit message.
+- Keep unrelated concerns in separate commits.
+- Use the commit strategy skill for detailed grouping and message rules:
+    - `.github/skills/commit-strategy/SKILL.md`
+
 ### Type Hints
 - Always use complete type hints for all function parameters and return values
 - Use `Union[datetime, str]` for date parameters that accept multiple formats
@@ -41,6 +51,67 @@ date_obj = to_datetime(datetime.now())
 - Include Args, Returns, Raises, and Examples sections
 - Examples should be executable and demonstrate real-world usage
 
+### Strict Docstring Policy (Always-On)
+- These rules are mandatory for every Python file that is created or edited.
+- Follow PEP 257 conventions for all docstrings.
+- Use Google-style docstring sections.
+- Every module must have a module-level docstring as the first statement.
+- Every class must have a class docstring.
+- Every function and method must have a docstring, including `__init__` and private helpers.
+- Every docstring must include a concise summary line.
+- Add `Args`, `Returns`, and `Raises` sections when applicable.
+- Include an `Examples` section with executable usage when practical.
+- Keep docstrings factual and behavior-focused; avoid placeholder text.
+- When updating code, also update stale docstrings in the same edited scope.
+
+### Module-Level Docstring Format
+- All Python modules must start with a module docstring as the very first statement.
+- Use this schema for module docstrings:
+    1) First line: one-sentence summary title ending with a period.
+    2) Blank line.
+    3) One short overview paragraph (2-4 lines) describing scope and purpose.
+    4) Blank line.
+    5) Structured sections for module schema using heading labels with trailing colons.
+- Preferred section labels (choose those that apply):
+    - Core Classes:
+    - Core Dataclasses:
+    - Core Functions:
+    - Processing Flow:
+    - Risk/Assumptions:
+    - Caching Strategy:
+    - Usage:
+- Keep section content concise and domain-specific.
+- For Usage, use a short executable doctest-style snippet when practical.
+
+**Module docstring example:**
+```python
+"""Position attribution workflows for EventDriven backtests.
+
+Provides quantity normalization, option attribution loading, and position-level
+PnL decomposition with trade-aware adjustments (fills, commission, and slippage).
+
+Core Dataclasses:
+        QuantityTimeSeries: Daily quantity state and execution metadata.
+        BacktestPositionAttribution: Attribution output for a single trade.
+
+Core Functions:
+        create_position_attribution: Loads and combines leg-level attribution.
+        compute_position_attribution: Applies quantity and trade adjustments.
+        compute_backtest_position_attribution: End-to-end portfolio integration.
+
+Processing Flow:
+        1. Build trade quantity time series from ledgers.
+        2. Load/aggregate raw leg attribution by date.
+        3. Scale by quantity and apply open/close trade adjustments.
+        4. Return normalized attribution components.
+
+Usage:
+        >>> analyzer = PositionAttributionAnalyzer(portfolio)
+        >>> result = analyzer.analyze_trade(trade_id)
+        >>> daily_attr = result.attribution
+"""
+```
+
 **Example:**
 ```python
 def get_forward_timeseries(

.github/skills/commit-strategy/SKILL.md

@@ -0,0 +1,67 @@
+# Commit Strategy Skill
+
+Use this skill whenever the user asks to create commits, propose commits, or requests a commit plan.
+
+## Objectives
+- Separate code changes into the most relevant concerns.
+- Produce a clear commit strategy before committing.
+- Ensure each commit is cohesive, minimal, and reversible.
+
+## Required Workflow
+1. Inspect changed files and classify each change by concern.
+2. Run a pre-commit quality scan on changed files for:
+   - Potential bugs.
+   - Failure in logic.
+   - Misspellings.
+   - Commented-out code blocks (do not flag plain explanatory comments).
+3. Group files/hunks into concern-based commit buckets.
+4. Present a commit strategy that lists:
+   - What each commit includes.
+   - Why the grouping is correct.
+   - The commit message for each commit.
+   - A concise scan summary of findings (or explicitly state no findings).
+5. Keep unrelated changes out of the same commit.
+6. Prefer multiple small focused commits over one mixed commit.
+
+## Concern Grouping Rules
+- Separate by behavior surface (feature, bug fix, refactor, docs, tests, config).
+- Separate by subsystem when changes are independent.
+- Keep tests with the behavior they verify.
+- Keep formatting-only changes isolated when possible.
+- Do not mix broad cleanup with functional changes.
+
+## Commit Message Rules
+- Use imperative mood.
+- Keep the subject concise and specific.
+- Explain intent, not implementation noise.
+- Suggested style: `<area>: <action>`
+
+## Output Template
+When a commit is requested, provide:
+
+0. Pre-Commit Scan
+   - Potential bugs: <findings or "none">
+   - Logic failures: <findings or "none">
+   - Misspellings: <findings or "none">
+   - Commented-out code blocks: <findings or "none">
+
+1. Commit 1
+   - Scope: <files/hunks>
+   - Concern: <single concern>
+   - Message: <commit message>
+
+2. Commit 2
+   - Scope: <files/hunks>
+   - Concern: <single concern>
+   - Message: <commit message>
+
+## Example
+1. Commit 1
+   - Scope: `EventDriven/riskmanager/position/cogs/pnl_monitor.py`
+   - Concern: Fix quantity math and logging edge cases.
+   - Message: `riskmanager: fix pnl monitor quantity and logging bugs`
+
+2. Commit 2
+   - Scope: `EventDriven/riskmanager/position/cogs/pnl_monitor.py`, `EventDriven/riskmanager/position/cogs/test_pnl_monitor.py`
+   - Concern: Add regression coverage for updated behavior.
+   - Message: `tests: add pnl monitor regression cases`