# Task for crew-worker

# Task Assignment

**Task ID:** task-5
**Task Title:** Task 5: Configuration CLAUDE.md Alignment
**PRD:** /Users/terryli/eon/opendeviationbar-py/PRD.md


## Your Mission

Implement this task following the crew-worker protocol:
1. Join the mesh
2. Read task spec to understand requirements
3. Start task and reserve files
4. Implement the feature
5. Commit your changes
6. Release reservations and mark complete

## Concurrent Tasks

These tasks are being worked on by other workers in this wave. Discover their agent names after joining the mesh via `pi_messenger({ action: "list" })`.

- task-3: Task 3: Python Core API CLAUDE.md Alignment
- task-4: Task 4: ClickHouse CLAUDE.md Alignment
- task-6: Task 6: Plugin System CLAUDE.md Alignment
- task-7: Task 7: Scripts CLAUDE.md Alignment
- task-8: Task 8: Cross-Reference Consistency Audit
- task-9: Task 9: Public API vs Documentation Parity

## Recent Activity

12:43 VividNova started task-1 — Task 1: Root CLAUDE.md Alignment
12:43 HappyYak started task-2 — Task 2: Rust Crates CLAUDE.md Alignment

## Task Specification

# Task 5: Configuration CLAUDE.md Alignment

Investigate and verify that `/python/opendeviationbar/config/CLAUDE.md` (2.6KB) matches actual config modules. Create scaffolding directory at `/tmp/crew-config/`. List all files in `config/` directory and compare to "File Map" table (verified: `__init__.py`, `algorithm.py`, `cli_models.py`, `clickhouse.py`, `monitoring.py`, `population.py`, `settings.py`, `sidecar.py`, `streaming.py`); verify Settings singleton pattern works as documented; check environment variable prefixes match; validate pydantic models exist with documented fields. Use Dynamic Task Creation: for missing config files or wrong env var names, create sub-tasks. Broadcast key findings to all peers.


## Plan Context

Now I have a comprehensive understanding of the project. Let me produce the task breakdown.

## 1. PRD Understanding Summary

The PRD requires auditing and aligning 7 CLAUDE.md files (1 root + 6 nested) to reflect the current code state in a Rust/Python hybrid project (`opendeviationbar-py`) that generates open deviation bars — a novel financial data type.

**Key Requirements:**
- Audit each CLAUDE.md for accuracy against current code
- Fix discrepancies between documentation and implementation
- Ensure cross-reference consistency between CLAUDE.md files
- Verify public API documentation matches actual exports
- Validate code examples in docs are runnable

**Project Structure Verified:**
- 9 Rust crates in workspace (opendeviationbar, opendeviationbar-core, opendeviationbar-providers, opendeviationbar-config, opendeviationbar-io, opendeviationbar-streaming, opendeviationbar-batch, opendeviationbar-cli, opendeviationbar-hurst)
- Python module at `python/opendeviationbar/` with submodules (clickhouse, config, plugins)
- Scripts directory with 150+ Python and shell scripts

## 2. Relevant Code/Docs/Resources Reviewed

- **PRD.md**: Full specification with 9 investigative perspectives
- **Cargo.toml**: Workspace configuration with 9 crates
- **CLAUDE.md files**: All 7 files identified and located
- **Directory structures**: Verified crates/, python/, scripts/ contents
- **Python __init__.py**: Confirmed API exports via `__all__`

## 3. Sequential Implementation Steps

1. **Tasks 1-7 (Parallel)**: Each worker investigates their assigned CLAUDE.md file
   - Create scaffolding directory `/tmp/crew-<perspective>/`
   - Audit documentation against actual code
   - Use bash/uvx for empirical validation
   - Broadcast findings to peers

2. **Task 8**: Cross-Reference Consistency Audit (after Tasks 1-7)
   - Verify links between CLAUDE.md files
   - Fix broken references

3. **Task 9**: Public API vs Documentation Parity (after Task 8)
   - Final comprehensive check
   - Run do

[Spec truncated - read full spec from .pi/messenger/crew/plan.md]
## Coordination

**Message budget: 10 messages this session.** The system enforces this — sends are rejected after the limit.

**Broadcasts go to the team feed — only the user sees them live.** Other workers see your broadcasts in their initial context only. Use DMs for time-sensitive peer coordination.

### Announce yourself
After joining the mesh and starting your task, announce what you're working on:

```typescript
pi_messenger({ action: "broadcast", message: "Starting <task-id> (<title>) — will create <files>" })
```

### Coordinate with peers
If a concurrent task involves files or interfaces related to yours, send a brief DM. Only message when there's a concrete coordination need — shared files, interfaces, or blocking questions.

```typescript
pi_messenger({ action: "send", to: "<peer-name>", message: "I'm exporting FormatOptions from types.ts — will you need it?" })
```

### Responding to messages
If a peer asks you a direct question, reply briefly. Ignore messages that don't require a response. Do NOT start casual conversations.

### On completion
Announce what you built:

```typescript
pi_messenger({ action: "broadcast", message: "Completed <task-id>: <file> exports <symbols>" })
```

### Reservations
Before editing files, check if another worker has reserved them via `pi_messenger({ action: "list" })`. If a file you need is reserved, message the owner to coordinate. Do NOT edit reserved files without coordinating first.

### Questions about dependencies
If your task depends on a completed task and something about its implementation is unclear, read the code and the task's progress log at `.pi/messenger/crew/tasks/<task-id>.progress.md`. Dependency authors are from previous waves and are no longer in the mesh.

### Claim next task
After completing your assigned task, check if there are ready tasks you can pick up:

```typescript
pi_messenger({ action: "task.ready" })
```

If a task is ready, claim and implement it. If `task.start` fails (another worker claimed it first), check for other ready tasks. Only claim if your current task completed cleanly and quickly.

