# TASK-010.5 ## Title Feature Definition Registry --- ## Objective Introduce a centralized Feature Definition Registry that becomes the single source of truth for every feature produced by analyzers. This task prepares the architecture for the upcoming Music DNA Builder. No Music DNA implementation is allowed yet. --- # Expected Commit Message Add centralized feature definition registry --- # Requirements Read before implementation: - docs/00_PROJECT_PRINCIPLES.md - docs/01_SPEC.md - docs/02_ARCHITECTURE.md - docs/03_ANALYZER_API.md - docs/04_MUSIC_DNA_SCHEMA.md - docs/05_AI_DEVELOPER_GUIDE.md Follow all existing architectural rules. --- # Motivation Currently analyzers create Feature objects using hardcoded string identifiers such as: signal.rms spectral.centroid rhythm.tempo etc. This does not scale. The project now requires a centralized registry describing every feature in the system. The registry will later become one of the core inputs of the Music DNA Builder. --- # Scope Create a new package src/features/ containing: __init__.py definition.py registry.py default_registry.py --- ## FeatureDefinition Implement an immutable FeatureDefinition object. Required fields: identifier display_name category description unit data_type normalization version --- ### identifier Unique string. Examples signal.rms signal.peak spectral.centroid spectral.rolloff rhythm.tempo harmony.key --- ### category Examples signal spectral dynamic rhythm harmony --- ### data_type Support float int string bool --- ### normalization Supported values: identity minmax log zscore categorical none Only store the normalization strategy. Do NOT implement normalization algorithms. --- ### version Semantic version string. Example 1.0 --- ## FeatureRegistry Implement a registry responsible for register() unregister() contains() get() list() list_by_category() count() The registry must reject duplicate identifiers. --- ## Default Registry Implement build_default_feature_registry() It must register every feature currently produced by BasicSignalAnalyzer SpectralAnalyzer DynamicAnalyzer RhythmAnalyzer HarmonyAnalyzer Every existing feature should have a corresponding FeatureDefinition. --- ## Analyzer integration Analyzers should no longer rely on undocumented magic strings. When creating Feature objects they must use identifiers that exist in the registry. Do NOT tightly couple analyzers to FeatureRegistry. The registry is the authoritative catalog. Analyzers still emit Feature objects exactly as before. --- ## Validation The registry must verify unique identifiers non-empty names supported normalization strategy supported data type --- ## Forbidden Do NOT implement Music DNA Similarity Embeddings Recommendations Vector database Feature normalization Feature weighting --- # Tests Add complete unit tests covering FeatureDefinition immutability Registry registration Duplicate detection Lookup Category filtering Validation Default registry Coverage should include every built-in analyzer feature. --- # Documentation Update Architecture if necessary. Document how new analyzers should add FeatureDefinitions. --- # Definition of Done ✓ FeatureDefinition implemented ✓ FeatureRegistry implemented ✓ Default registry implemented ✓ All current analyzer features registered ✓ Duplicate identifiers rejected ✓ Validation implemented ✓ Tests pass ✓ Ruff passes ✓ Black passes ✓ isort passes --- ## Important This task is an architectural preparation step. It must not change the behavior of the analysis pipeline. Its purpose is to create a stable metadata layer that future Music DNA components can rely on.