🔍 Reflection Modernization Roadmap¶

1. 📊 Status Dashboard¶

Overall Progress: 60%+ (Phases A, B, I complete; Phase C.1 complete, C.2 design accepted/ready for implementation)

Status Legend: ⚪ Proposed · 🔵 Draft · 🟡 Planned · 🟢 Active · ✅ Complete

graph LR
    A[Phase A<br/>API Simplification] --> B[Phase B<br/>Metrics Architecture]
    B --> I[Phase I<br/>Container/Member Split]
    I --> C[Phase C<br/>Member Parsing Seam<br/>C.1 Complete]
    B --> D[Phase D<br/>Scanning & Resolution Seam]
    B --> E[Phase E<br/>Annotation & Type Hint Providers]
    E --> F[Phase F<br/>Type Checker Strategy]
    F --> G[Phase G<br/>Invocation Architecture]
    classDef completed fill:none,stroke:#4caf50,stroke-width:2px,color:#4caf50;
    classDef active fill:none,stroke:#2196f3,stroke-width:2px,color:#2196f3;
    classDef proposed fill:none,stroke:#9e9e9e,stroke-width:2px,color:#9e9e9e;
    class A,B,I completed;
    class C active;
    class D,E,F,G proposed;

2. 🧭 Overview¶

The reflection subsystem underpins the DI roadmap, but its current architecture exposes too many loosely defined seams and relies on generic metrics. This roadmap modernizes the subsystem in three thematic tracks:

1. API Clarity: Sharpen the public surface of ReflectionContext, optionally removing facades that duplicate responsibilities or leak internal types.
2. Actionable Observability: Replace generic metrics with precise hooks and an opinionated aggregation sink that rolls measurements up hierarchically.
3. Seam Rationalization: Re-evaluate every overridable protocol to determine whether it should remain extensible, be replaced with configuration-driven strategies, or be collapsed entirely.

Goals¶

• Define and document the supported public API for reflection, minimizing accidental coupling.
• Provide a metrics contract that captures concrete events (duration, counts) without requiring per-implementation guesswork.
• Offer clear extension points where they add demonstrable value (e.g., custom import resolution), and remove or reshape seams that complicate maintenance.

Non-Goals¶

• Rewriting downstream DI behaviours beyond what is needed to adopt the new reflection API.
• Tuning performance beyond the impact of clarified seams and targeted metrics (dedicated performance roadmap will follow).
• Revisiting forward-reference resolution algorithms (covered separately in future technical designs).

3. 🚨 Problem Statements¶

• ReflectionContext API breadth: The current facade set (resolve, scan, hints, annotations, invoke, create) overlaps heavily and obscures the canonical entry points. Contributors struggle to reason about which methods are safe to call and which are internal scaffolding.
• Metrics ambiguity: Events like type_hints.resolved or invoke.call carry loosely structured payloads, limiting observability and making aggregation costly. Teams need deterministic hooks such as record_type_resolution_success(qualname: str, duration: float) and derived aggregates.
• Seam sprawl: Protocols exist for almost every component. Some are useful (import resolution), but others introduce cost without demonstrated extensibility (scanner, annotation provider versus metadata on MemberInfo, invocation protocols).
  • Parsing & member-building seam needs to remain powerful but should be expressed via explicit strategy interfaces instead of ad-hoc overrides.
  • Scanning should standardize the reflection algorithm while allowing logistics-level customization (e.g., module source discovery).
  • Annotation and type-hint providers overlap with metadata stored on MemberInfo; we need a single source of truth.
  • Type checking must either be a first-class, opt-in capability with clear configuration or be removed entirely.
  • Invocation protocols are currently pluggable but may only need internal composition rather than public seams.

4. 🛣️ Roadmap Phases¶

Phase A — API Simplification¶

• Objective: Document and reduce the ReflectionContext public API so consumers understand the supported surface.
• Status Update: ✅ Completed via TD-027 — ReflectionContext API Simplification; facades removed, constructor seams collapsed, and TypeInfo utilities introduced.
• Key Activities:
  • Inline facade functionality as first-class ReflectionContext methods and refresh package exports (complete).
  • Catalogue and lock documented workflows with focused integration/unit coverage, including strict/tolerant paths and cache semantics (complete).
  • Provide contributor guidance and utilities (iter_public_*) so downstream code avoids deprecated helpers such as scan_types (complete; compatibility helper retained for legacy callers).
• Deliverables:
  • Updated API surface, fixtures, and docs highlighting the constructor-only model and new utilities.
  • Scenario-driven tests under tests/integration/reflection/context/ and unit suites for TypeInfo helpers.
  • Roadmap/TD updates capturing progress and remaining adoption tasks (tracked under Phase A.3).
• Acceptance Criteria: Met—DI/runtime code builds against the reduced API, tests pass with the new suites, and documentation reflects the simplified surface.

Phase B — Metrics Architecture¶

• Objective: Replace generic metrics events with a strongly typed metrics API and a canonical hierarchical aggregation sink.
• Status Update: ✅ Complete — TD-028 — Reflection Metrics Architecture design and implementation complete. AggregatorTree collection with auto-creating parents and callback aggregation, typed MetricsState attributes, strongly-typed API with context managers for automatic timing, and never-raise semantics fully implemented. All reflection components migrated. Documentation and observability guides updated.
• Key Activities:
  • Implement AggregatorTree[Node, State] collection in loryth.common.collections with auto-creating parents and callback-based aggregation.
  • Define MetricsState dataclass holding counts, durations, rates, and errors with immutable snapshot pattern.
  • Define reflection-specific metrics API using dedicated methods for each domain (resolution, scanning, invocation, etc.) — no try-except needed at call sites.
  • Implement hierarchical aggregation: module a automatically aggregates metrics from a.b, a.c, etc.
  • Remove old ReflectionMetrics protocol and implementations (NullMetrics, LoggingMetrics, HookMetrics).
• Deliverables:
  • AggregatorTree implementation with comprehensive unit tests.
  • MetricsState dataclass and MetricsSnapshot immutable view.
  • ReflectionMetricsCollector with typed API and snapshot retrieval.
  • Updated ReflectionContext constructor to accept optional metrics parameter.
  • Phase 2 migration of all reflection components to new API (removal of try-except blocks).
  • Observability documentation with usage examples and external sink patterns.
• Acceptance Criteria:
  • AggregatorTree and metrics implementations pass strict mypy and test suites.
  • Hierarchical aggregation verified via integration tests.
  • All reflection components updated to use typed API (Phase 2).
  • Legacy generic metrics events removed; no scattered try-except blocks remain.
  • Documentation includes migration guide and observability patterns.

Phase I — Container/Member Type Hierarchy Rationalization¶

• Objective: Separate "containers" (modules/packages) from "members" (types, methods, fields) in the type hierarchy, providing a clearer conceptual model and foundation for Phase C parsing strategies.
• Status Update: ✅ Complete — TD-030 — Container/Member Type Hierarchy Split implemented in 5 phases (terminology, ownership properties, module unification, scanner integration).
• Completed Activities:
  • ✅ Phase 1: ReflectionInfo/MemberInfo hierarchy with explicit module/type properties
  • ✅ Phase 2: Rename *Info → *Handle; reorganize into handles/ package (one class per file)
  • ✅ Phase 3: Add ownership properties (module, type) to all member types
  • ✅ Phase 4: Unified modules model (PackageHandle removed, merged into ModuleHandle with is_package property)
  • ✅ Phase 5: Scanner integration (scan_package merged into scan_module with recursive parameter)
• Deliverables:
  • ✅ Handle hierarchy with clear separation of containers and members
  • ✅ ModuleHandle unified class handling both modules and packages
  • ✅ Updated MemberBuilder, ReflectionContext, PackageScanner APIs
  • ✅ Full test migration to new hierarchy (791 tests passing)
  • ✅ Unified scanning API with recursive parameter
• Acceptance Criteria: ✅ All met — New hierarchy in place and functional; all existing tests pass (791/791); zero breaking changes to DI consumer code; Phase C now ready for implementation.

Phase C — ReflectionEngine & Strategy-Based Handle Building¶

• Objective: Replace monolithic MemberBuilder with ReflectionEngine orchestrating composable strategies. Enable foundation for lazy loading and handle identity management.
• Status Update: 🟢 Active (Phase C.1 complete; TD-031 accepted—C.2 ready for implementation)
• TD-033: ReflectionEngine & HandleRegistry (✅ Complete)
• TD-031: Handle Generation Strategy Protocol & Mappers (✅ Accepted; implementation pending)
• TD-032: ReflectionContext Integration & MemberBuilder Migration (⏳ Pending)

Phase C.1 — ReflectionEngine & HandleRegistry (✅ Complete) · [TD-033]¶

• Objective: Build core infrastructure for handle identity management and orchestration
• Key Activities:
  • Create HandleRegistry for handle identity (qualname → Handle mapping)
  • Build ReflectionEngine orchestration layer (delegates to MemberBuilder in C.1)
  • Separate identity management (registry) from performance caching (HierarchicalCache)
  • Implement graph query APIs (find_by_prefix(), find_by_type())
  • Validate thread-safety and single-instance identity guarantees
• Sub-Phases:
  • C.1a: HandleRegistry foundation (register, get, has, remove, clear, count)
  • C.1b: Graph query APIs (find_by_prefix, find_by_type)
  • C.1c: ReflectionEngine scaffold (resolve_type, resolve_module with registry integration)
  • C.1d: Standalone validation (integration tests, thread-safety, performance)
• Deliverables:
  • Working HandleRegistry with 100% test coverage
  • ReflectionEngine using registry for identity, MemberBuilder for building
  • Standalone unit/integration tests (no ReflectionContext changes yet)
  • Graph query validation for DI container use cases
• Status Update: ✅ Complete (2025-11-22) — All sub-phases C.1a-C.1d implemented and tested
• Commits: 4af5ee2 (C.1a+C.1b), 998659c (C.1c), a34bce0 (C.1d)
• 56 new tests (41 unit + 15 integration), all passing
• 0 regressions in existing 230 reflection tests
• Acceptance Criteria:
  • ✅ HandleRegistry enforces single-instance identity per qualname
  • ✅ Thread-safety validated with concurrent access tests (15 threads)
  • ✅ Graph queries functional (find all types in module, find all handles by type)
  • ✅ Engine + registry tests pass with 95%+ coverage
  • ✅ No changes to existing reflection tests (ReflectionContext unchanged)

Phase C.2 — Handle Generation Strategy Protocol & Mappers (🟢 Active — design accepted) · [TD-031]¶

• Objective: Implement composable strategy-based architecture to replace MemberBuilder
• Key Activities:
  • Define HandleGenerationStrategy protocol (single map(source, context) -> spec interface)
  • Implement immutable Spec hierarchy (8 types: Module, Class, Function, Method, Parameter, Field, Property, Constructor)
  • Build HandleGenerationContext (stack-based LIFO discovery)
  • Build HandleBuildingPipeline (strategy orchestration with metrics)
  • Implement 7 core mappers (Module, Type, Function, Method, Parameter, Field, Property)
  • Integrate strategies into ReflectionEngine (replace MemberBuilder delegation)
• Sub-Phases:
  • C.2a: Specs foundation (BaseSpec + 8 immutable spec types)
  • C.2b: Strategy protocol (HandleGenerationStrategy + MappingContext)
  • C.2c: Generation context & pipeline (stack management, strategy composition)
  • C.2d: Core mappers (7 source-specific implementations, each ≤100 lines)
  • C.2e: Engine integration (ReflectionEngine uses strategies instead of MemberBuilder)
• Deliverables:
  • Complete spec hierarchy with copy() + with_*() enrichment pattern
  • Strategy protocol with clear contracts and composition semantics
  • All 7 core mappers implemented with ≥80% coverage each
  • Engine updated to use pipeline (MemberBuilder still exists for comparison)
  • Regression parity tests (outputs match MemberBuilder golden fixtures)
• Acceptance Criteria:
  • ✅ All specs implemented with immutability guarantees (100% coverage)
  • ✅ Strategy protocol documented with examples for framework authors
  • ✅ Pipeline executes strategies in sequence with per-strategy metrics
  • ✅ All 7 mappers implemented (Module, Type, Function, Method, Parameter, Field, Property)
  • ✅ Regression tests validate outputs match MemberBuilder exactly
  • ✅ Performance within 10% of MemberBuilder baseline
  • ✅ MemberBuilder still exists (removal in C.3)

Phase C.3 — ReflectionContext Integration & MemberBuilder Migration (⏳ Pending) · [TD-032]¶

• Objective: Wire engine + strategies into ReflectionContext, remove MemberBuilder
• Key Activities:
  • Update ReflectionContext constructor to use ReflectionEngine instead of MemberBuilder
  • Migrate all reflection components (ImportResolver, Scanner, TypeResolver) to use engine
  • Refine cache API: split clear_caches() into clear_computation_cache() + clear_handle_registry()
  • Remove MemberBuilder class entirely
  • Validate all 791 existing tests pass without modification
• Sub-Phases:
  • C.3a: ReflectionContext integration (constructor update, cache API refinement)
  • C.3b: Component migration (ImportResolver, Scanner, TypeResolver use engine)
  • C.3c: Regression validation (all 791 tests pass, golden fixtures match)
  • C.3d: MemberBuilder removal (delete class, remove imports, final validation)
• Deliverables:
  • ReflectionContext fully integrated with ReflectionEngine
  • All reflection components using engine for handle resolution
  • Cache API with clear semantics (computation cache vs registry)
  • MemberBuilder completely removed from codebase
  • All 791 tests passing with zero public API changes
• Acceptance Criteria:
  • ✅ ReflectionContext creates ReflectionEngine (not MemberBuilder)
  • ✅ clear_computation_cache() + clear_handle_registry() added
  • ✅ clear_caches() marked deprecated, clears both for compatibility
  • ✅ All reflection components delegate to engine
  • ✅ All 791 existing tests pass without modification
  • ✅ MemberBuilder removed; no remaining references
  • ✅ Performance within 10% of baseline

Phase C.4 — Lazy Loading (⚪ Proposed) · Future¶

• Objective: Enable on-demand handle materialization to reduce memory footprint
• Status: Deferred until Phase C.1-C.3 complete and stabilized
• Key Activities:
  • Design lazy handle proxy protocol
  • Implement handle-level lazy loading (load details on first access)
  • Add configurable hydration strategies (eager, lazy, hybrid)
  • Performance optimization and benchmarking
• Deliverables:
  • Lazy handle proxy implementation
  • Hydration strategy configuration
  • Performance benchmarks showing memory/speed trade-offs
• Acceptance Criteria:
  • ✅ Lazy loading reduces peak memory by >50% for large modules
  • ✅ Performance acceptable (latency on first access tolerable)
  • ✅ All existing tests pass with lazy loading enabled

Phase D — Scanning & Resolution Seam¶

• Objective: Ensure the scanning algorithm is consistent across runtime contexts while allowing specific logistics overrides.
• Key Activities:
  • Collapse the Scanner protocol if it only varies the algorithm; replace with a concrete scanner that accepts injectable logistics (e.g., module locator, filesystem strategy).
  • Re-evaluate interaction between scanning and import resolution to prevent drift.
  • Provide configuration knobs for alternate discovery roots instead of full protocol overrides.
• Deliverables:
  • Concrete scanning module with explicit extension points for logistics.
  • Updated import resolution strategies (protocol retained) to reflect the clarified responsibilities.
  • Migration guidance for existing custom scanners, if any.
• Acceptance Criteria: Scanning behaviour matches current tests, with additional coverage for custom logistics; DI bootstrap retains its scanning capabilities using the new configuration model.

Phase E — Annotation & Type Hint Providers¶

• Objective: Consolidate metadata ownership so annotations and type hints flow through a coherent pipeline.
• Key Activities:
  • Determine whether MemberInfo should deliver annotations and type hints directly, potentially making providers internal implementation details.
  • If providers remain, define a split of responsibilities (e.g., augmentation vs. extraction) and expose them as distinct, purposeful seams.
  • Audit usage to remove redundant lookups or caching, documenting concrete examples where metadata diverges (e.g., decorator-derived annotations that are not present on the MemberInfo instance today).
• Deliverables:
  • Updated metadata acquisition strategy (either enriched MemberInfo or redesigned providers).
  • Documentation clarifying how annotations/type hints are obtained, including strict vs. permissive behaviours.
  • Tests validating that DI and other consumers receive consistent metadata after the change.
• Acceptance Criteria: No duplication between MemberInfo data and provider outputs; provider interfaces (if any) have explicit contracts; metrics capture metadata resolution durations where relevant.

Phase F — Type Checker Strategy¶

• Objective: Decide whether runtime type checking is necessary and, if so, how it should be configured.
• Key Activities:
  • Evaluate current TypeChecker usage (strict invocation, DI safety checks).
  • Shape a lightweight interface focused on comparing two type objects for compatibility, while retaining strict invocation/instantiation pathways.
  • Extract the checker into its own component and expose public accessors on ReflectionContext so consumers can leverage it directly.
• Deliverables:
  • Decision record detailing the chosen interface and exposure model.
  • Implementation aligning with the decision (streamlined checker plus strict mode integration).
  • Updated tests reflecting the enforced behaviour and public API.
• Acceptance Criteria: Consumers understand the supported type-checker entry points; strict invocation path remains with deterministic behaviour; checker can be reused by clients without coupling to invocation internals.

Phase G — Invocation Architecture¶

• Objective: Simplify the invocation stack while capturing necessary extensibility for complex execution scenarios.
• Key Activities:
  • Review SafeCallableInvoker, TypeInstanceFactory, and related composites to confirm protocols can be replaced with internal composition (no custom invokers currently in use).
  • Collapse to configuration toggles (e.g., whether to allow packed args) rather than user-supplied implementations.
  • Align invocation metrics with the new typed metrics API.
• Deliverables:
  • Streamlined invocation component(s) with clear layering.
  • Documentation describing invocation guarantees (arity checks, exception wrapping).
  • Tests covering invocation edge cases and metrics emission.
• Acceptance Criteria: Invocation path is easier to reason about; metrics match the new schema; any retained seams have explicit justifications.

5. ⚙️ Dependencies & Alignment¶

• Technical Designs: Coordinates with upcoming TDs for reflection API simplification and metrics (to be drafted after Phase A scoping). Existing guidance in docs/notes/reflection-refactor-plan.md and docs/notes/reflection-refactor-findings.md informs prioritization.
• Roadmap Linkage: Aligns with DI Roadmap Phase 10 (Reflection Integration) by providing a stable reflection surface; sequencing ensures DI migration planning begins after Phase B completion.
• Documentation: Builds on docs/contributors/reflection-architecture.md, which must be updated after each major phase to keep the reference accurate.

6. 🧪 Verification Strategy¶

• Testing: Expand unit and integration coverage mirroring each seam (e.g., new parsing strategy tests, scanning logistics scenarios). Maintain strict typing (mypy) adherence throughout refactors.
• Metrics Validation: Introduce snapshot tests or golden files for the hierarchical aggregator to guarantee deterministic aggregation. Provide example dashboards/log outputs as part of documentation.
• Documentation Updates: Each phase requires corresponding updates to contributor guides, roadmap status dashboard, and architecture docs. Deprecations must be captured in CHANGELOG entries.

7. 📅 Timeline & Milestones¶

• Sequencing: Phase A must complete before Phase B. Phases C–E unlock after Phase B and can proceed in parallel with coordination on shared components. Phase F requires the outcomes of Phase E, and Phase G depends on Phase F.
• Synchronization Points: Hold design reviews between C/D/E to keep extension seams compatible; run a metrics/observability check-in before starting Phase F.
• Feedback Loops: After each phase, update the reflection architecture document and reassess downstream DI impacts before advancing.

8. ❓ Open Questions¶

• Parsing Strategy Guarantees: Beyond functional correctness, what performance or caching guarantees must the extensibility surface offer when accommodating dynamic libraries (e.g., SQLAlchemy-style ORMs)?
• Annotation vs Type Hint Ownership: Provide concrete examples of where annotation metadata currently diverges from type-hint data so we can judge whether MemberInfo should remain the single source of truth.
• Type Checker Exposure: How should the extracted checker be surfaced on ReflectionContext (e.g., context.type_checker.compare(lhs, rhs)) while keeping invocation strict-mode semantics intuitive?

9. 🔮 Future Work (Deferred from Phase C)¶

During Phase C implementation planning (TD-033), the following edge cases and optimization opportunities were identified as out-of-scope for Phase C but critical for future phases:

Scope Optimization (Phase C - Secondary)¶

• Large Scope Expansion (Risk 2): Currently, resolving my_app.Customer expands to build the entire module + all discovered dependencies via breadth-first queueing. This is correct for semantic completeness but can be expensive for large codebases.
• Planned Solution: Phase C will implement lazy-hydration on top of the current full-scope model, allowing partial Handle materialization with on-demand completion of ownership chains.
• Implementation Strategy: Wrap finalized handles with lazy-loading proxies that transparently fetch missing details when accessed.

Static Reflection Limitations (Phase TBD - Enhancement)¶

• Conditional/Dynamic Members (Risk 4): The mapping pipeline uses vars(source) to discover members, which misses runtime-added attributes (e.g., SQLAlchemy hybrid_property added after class definition, Pydantic fields added via config).
• Planned Solution: Extend framework-specific mappers (SQLAlchemyHandleMapper, PydanticHandleMapper) to discover these via metadata introspection rather than source inspection.
• Implementation Strategy: Add hooks for framework-specific member discovery; update mapper composition patterns to include framework enrichers.

Type Hint Resolution (Phase F - Type Checker Strategy)¶

• Forward References (Risk 5): String-based forward references in type hints (e.g., def place_order(self) -> "Order") are not resolved during member mapping to avoid circular resolution loops.
• Planned Solution: Phase F (Type Checker Strategy) will implement deferred type-hint resolution as a separate pass after handle graph finalization.
• Implementation Strategy: Collect unresolved type hints during mapping; resolve after ownership chains are established; validate with TypeChecker interface.

Performance Optimization (Phase C - Optimization)¶

• Test Performance Regression (Risk 6): With full scope expansion, tests that previously built only a single type now build entire modules. This baseline slowdown needs characterization and optimization strategies.
• Planned Solution: Phase C optimization will add configurable scope limiting for tests; benchmark baseline; profile hot paths.
• Implementation Strategy: Implement test-mode mappers that limit discovery depth; add performance regression tests; document caching strategies for test speedup.

10. 📝 Change Log¶

• 2025-11-22 — Phase C.1 moved to ✅ Complete status; TD-033 implementation complete with all 4 sub-phases:
• Phase C.1a: HandleRegistry foundation (commit 4af5ee2)
• Phase C.1b: Graph query APIs (integrated with C.1a)
• Phase C.1c: ReflectionEngine scaffold (commit 998659c)
• Phase C.1d: Standalone validation (commit a34bce0)
• Total: 56 new tests (41 unit + 15 integration), all passing
• 0 regressions in existing 230 reflection tests
• Dual-layer architecture validated: HandleRegistry (identity) + HierarchicalCache (performance)
• Thread-safety validated with 15 concurrent threads
• Phase C.2 (TD-031) ready for implementation
• Overall roadmap progress: 60%+ (Phases A, B, I, C.1 complete)
• 2025-10-26 — Phase C design updated (TD-033 refinement):
• Refactored from two-protocol (inspection + annotation) to single HandleMappingStrategy protocol
• Mapping-centric design: map(source, builder, context) → enhanced builder
• Source-specific implementations (ModuleHandleMapper, TypeHandleMapper, FunctionHandleMapper)
• Breadth-first queueing with ParsingContext managing pending builders
• Full scope expansion (Option A) selected to ensure complete ownership chains
• Circular import mitigation via next_pending() deduplication
• Edge cases 1, 3, 7 covered in test matrix; risks 2, 4, 5, 6 deferred to future phases
• Future work section added to roadmap documenting deferred optimizations and enhancements
• Phase C ready for implementation; all protocols and semantics finalized
• 2025-10-26 — Phase I moved to ✅ Complete status; TD-030 implementation complete with all 5 phases:
• Phase 1: ReflectionInfo/MemberInfo hierarchy with explicit module/type properties
• Phase 2: Renamed *Info → *Handle; reorganized into handles/ package
• Phase 3: Added ownership properties (module, type) to all member types
• Phase 4: Unified modules model (PackageHandle removed, merged into ModuleHandle)
• Phase 5: Scanner integration (scan_package merged into scan_module with recursive parameter)
• Phase C unblocked for implementation
• All 791 tests passing, zero breaking changes
• 2025-10-25 — Phase I moved to 🔵 Draft status; TD-030 created with:
• New ReflectionInfo base for all introspectable entities
• ContainerInfo hierarchy for scopes (modules, packages)
• MemberInfo redefined for actual members (types, methods, fields)
• PackageInfo consolidated into ModuleInfo with is_package property
• Four-phase implementation plan (foundation → consolidation → integration → tests)
• Phase C marked as "Blocked on Phase I" dependency
• 2025-10-25 — Phase C moved to 🔵 Draft status; TD-033 created with:
• Two-protocol architecture: MemberInspectionStrategy + MemberAnnotationStrategy
• Source-type granular inspectors (ClassInspectionStrategy, ModuleInspectionStrategy, PackageInspectionStrategy)
• Hybrid annotation strategies (metadata-type and member-type specific)
• Two-phase execution pipeline (discovery → enrichment)
• Stackable, composable strategies with metadata merging
• Three-phase implementation plan (foundation → composability → examples)
• 2025-10-21 — Phase B moved to 🟡 Planned status; TD-028 design ACCEPTED with:
• Typed attributes for MetricsState/MetricsSnapshot (not dicts)
• AggregatorTree with auto-creating parents and clear() support
• Context managers for automatic timing: resolution_timer(), scan_timer(), hint_lookup_timer()
• Two-phase implementation plan (foundation + migration)
• 2025-10-21 — TD-028 created in Draft status with detailed AggregatorTree design, MetricsState dataclass, and strongly-typed API.
• 2025-10-24 — Phase A marked complete following TD-027 implementation (facades removed, TypeInfo utilities delivered, new test suites added).
• 2025-10-22 — Initial draft created (proposed status).