repository-feature-maplisted

# Repository feature map Produce a compact map that lets a new contributor find where behavior begins, where it is implemented, and how it is verified. ## Scope Map current repository structure and behavior. Do not infer why the design exists; route that question to rationale reconstruction. Do not turn the map into a change plan or a generated wiki. Write files only when the user asks for a maintained artifact; otherwise return the map in the response. ## Build the map 1. Read repository instructions and existing architecture, ownership, and test documentation. 2. Inventory user-facing surfaces and operational entry points from manifests, routes, commands, services, jobs, packages, and public APIs. 3. Trace each major capability to its owning module, important data or state, external boundary, and strongest verification surface. 4. Group by behavior or domain, not by directory alone. Record cross-domain flows only when they help navigation. 5. Check the map against source and runnable discovery commands. Mark generated, vendored, experimental, or unreachable areas explicitly. Use this entry shape: - Capability and user-visible purpose. - Entry points. - Owning modules and state. - Important downstream or external boundaries. - Tests, harnesses, or runtime checks. - Confidence and unresolved gaps. Keep paths searchable and descriptions short. Prefer a top-level index plus focused domain sections over a single exhaustive file list. ## Report State the inspected revis