At the beginning of each coding session, before making any code changes, you should build a comprehensive
understanding of the codebase by invoking the /explore-codebase skill.
This builds an accurate model of the project architecture before changes are made, preventing inconsistencies with the patterns that downstream Ataraxis framework projects depend on.
Before writing, modifying, or reviewing any code or documentation, you MUST invoke the appropriate skill to load Ataraxis framework conventions. This applies to ALL file types:
| Task | Skill to Invoke |
|---|---|
| Writing or modifying Python code | /python-style |
| Writing or modifying README files | /readme-style |
| Writing git commit messages | /commit |
| Writing or modifying pyproject.toml | /pyproject-style |
| Configuring tox.ini | /tox-config |
All contributions must strictly follow these conventions. Key conventions include:
- Google-style docstrings with proper sections
- Full type annotations with explicit array dtypes
- Keyword arguments for function calls
- Third person imperative mood for comments and documentation
- Proper error handling with
console.error() - 120 character line limit
Ataraxis framework projects often depend on other ataraxis-* libraries. These libraries may be
stored locally in the same parent directory as this project (/home/cyberaxolotl/Desktop/GitHubRepos/).
Before writing code that interacts with a cross-referenced library, you MUST:
-
Check for local version: Look for the library in the parent directory (e.g.,
../ataraxis-time/,../ataraxis-base-utilities/). -
Compare versions: If a local copy exists, compare its version against the latest release or main branch on GitHub:
- Read the local
pyproject.tomlto get the current version - Use
gh api repos/Sun-Lab-NBB/{repo-name}/releases/latestto check the latest release - Alternatively, check the main branch version on GitHub
- Read the local
-
Handle version mismatches: If the local version differs from the latest release or main branch, notify the user with the following options:
- Use online version: Fetch documentation and API details from the GitHub repository
- Update local copy: The user will pull the latest changes locally before proceeding
-
Proceed with correct source: Use whichever version the user selects as the authoritative reference for API usage, patterns, and documentation.
Why this matters: Skills and documentation may reference outdated APIs. Always verify against the actual library state to prevent integration errors.
| Skill | Description |
|---|---|
/explore-codebase |
Perform in-depth codebase exploration at session start |
/python-style |
Apply Ataraxis framework Python coding conventions (REQUIRED for code changes) |
/readme-style |
Apply Ataraxis framework README conventions |
/commit |
Draft Ataraxis framework style-compliant git commit messages |
/pyproject-style |
Apply Ataraxis framework pyproject.toml conventions |
/tox-config |
Apply Ataraxis framework tox.ini conventions |
/api-docs |
Apply Ataraxis framework Sphinx API documentation conventions |
/audit-facts |
Fact-check documentation against authoritative source code |
/audit-style |
Audit files for style and convention compliance |
/explore-dependencies |
Build an API snapshot of installed ataraxis dependencies |
/pr |
Draft a style-compliant pull request summary |
/project-layout |
Apply Ataraxis framework project structure conventions |
/release |
Draft style-compliant release notes from merged PRs |
/skill-design |
Generate and verify skill files and CLAUDE.md instructions |
This is ataraxis-data-structures, a Python library that provides classes and structures for storing, manipulating, and sharing data between Python processes. The library is part of the Ataraxis ecosystem and serves as a foundational dependency for other Ataraxis framework projects.
| Directory | Purpose |
|---|---|
src/ataraxis_data_structures/ |
Main library source code |
src/.../shared_memory/ |
SharedMemoryArray for process-safe data sharing |
src/.../data_structures/ |
YamlConfig and ProcessingTracker classes |
src/.../data_loggers/ |
DataLogger and LogArchiveReader for serialized logging |
src/.../processing/ |
Checksum, transfer, and interpolation utilities |
tests/ |
Test suite (mirrors source structure) |
docs/ |
Sphinx API documentation source |
- SharedMemoryArray: Wraps NumPy arrays in shared memory buffers for IPC with multiprocessing.Lock for
process-safety. Requires explicit
connect(),disconnect(), anddestroy()lifecycle management. - YamlConfig: Base dataclass with YAML serialization via
to_yaml()andfrom_yaml()class methods. Uses dacite for deserialization with type-aware conversions for Path and Enum types. - DataLogger: Runs a logger process with an input Queue for buffering serialized LogPackage data. Uses a watchdog
thread for monitoring. Saves individual
.npyfiles that can be assembled into.npzarchives. - LogArchiveReader: Reads
.npzlog archives with onset timestamp discovery. Supports batch generation for parallel processing workflows viaget_batches(). - ProcessingTracker: File-based pipeline state tracker using FileLock for multi-process coordination. Manages job states (SCHEDULED, RUNNING, SUCCEEDED, FAILED) with search and lifecycle features.
- Processing Utilities: Directory checksums (xxHash3-128), parallel directory transfer with integrity verification, and time-series interpolation (linear for continuous, last-known-value for discrete data).
| Component | File | Purpose |
|---|---|---|
| SharedMemoryArray | shared_memory/shared_memory_array.py |
Process-safe NumPy array in shared memory |
| YamlConfig | data_structures/yaml_config.py |
Dataclass with YAML serialization |
| ProcessingTracker | data_structures/processing_tracker.py |
Pipeline state tracking with file locking |
| JobState | data_structures/processing_tracker.py |
Dataclass for job metadata |
| ProcessingStatus | data_structures/processing_tracker.py |
IntEnum (SCHEDULED, RUNNING, SUCCEEDED, FAILED) |
| DataLogger | data_loggers/serialized_data_logger.py |
Process-based serialized data logging |
| LogPackage | data_loggers/serialized_data_logger.py |
Container for source_id, acquisition_time, serialized_data |
| LogArchiveReader | data_loggers/log_archive_reader.py |
Batch reader for .npz archives |
| LogMessage | data_loggers/log_archive_reader.py |
Container for timestamp_us and payload |
| assemble_log_archives | data_loggers/serialized_data_logger.py |
Aggregates .npy files into .npz archives |
| calculate_directory_checksum | processing/checksum_tools.py |
xxHash3-128 directory checksums |
| transfer_directory | processing/transfer_tools.py |
Parallel directory copy with verification |
| delete_directory | processing/transfer_tools.py |
Parallel directory deletion |
| interpolate_data | processing/interpolation.py |
Time-series interpolation |
- MyPy strict mode with full type annotations
- Google-style docstrings
- 120 character line limit
- Ruff for formatting and linting
- Python 3.12, 3.13, 3.14 support
- See style skills for complete conventions
Before modifying any component below, review its source file for the current implementation, then follow the component-specific steps.
Modifying SharedMemoryArray (src/ataraxis_data_structures/shared_memory/shared_memory_array.py):
- Understand the multiprocessing.Lock integration for process-safety
- Maintain the
connect()/disconnect()/destroy()lifecycle contract - Test with actual multiprocessing scenarios (not just single-process)
Modifying YamlConfig (src/ataraxis_data_structures/data_structures/yaml_config.py):
- Understand the dacite integration for nested dataclass conversion
- Maintain type hook support for Path, Enum, and custom conversions
- Test with complex nested structures and edge cases
Modifying DataLogger (src/ataraxis_data_structures/data_loggers/serialized_data_logger.py):
- Understand the Process/Queue/watchdog thread architecture
- Maintain the LogPackage format (uint8 source_id, uint64 acquisition_time, uint8 array serialized_data)
- Test with multiprocessing scenarios and verify proper cleanup
Modifying ProcessingTracker (src/ataraxis_data_structures/data_structures/processing_tracker.py):
- Understand the FileLock integration for concurrent access safety
- Maintain the job state lifecycle (SCHEDULED → RUNNING → SUCCEEDED/FAILED)
- Test with concurrent access from multiple processes
Adding processing utilities (src/ataraxis_data_structures/processing/):
- Review existing utilities for the patterns to follow
- Follow the same conventions for type hints, docstrings, and error handling
- Export new functions in
src/ataraxis_data_structures/__init__.py - Add corresponding tests in
tests/processing/
Important considerations:
- This library is a dependency for other Ataraxis framework projects; maintain backwards compatibility
- Use
console.error()from ataraxis-base-utilities for all error handling - Use
ataraxis-timefor precision timestamps in logging contexts - All multiprocessing code uses an explicit spawn context (
get_context("spawn")) for identical cross-platform behavior