Skip to content

#250 child: Define Atlas implementation file/module map and ownership boundaries #266

Description

@Joncallim

Parent: #250. Coding-standards review finding; close as part of #251.

Before coding, freeze the expected file/module map so an implementation agent does not recreate a monolith or scatter topology logic across screens.

At minimum separate: atlas/types, source adapters/projection, projection rules, deterministic layout, layout constants/version, visual grammar, renderer primitives, lens policies, interaction/URL state, accessible semantic alternative, fixtures/builders, property tests, geometry/browser tests. Existing ServiceMap.tsx remains legacy until cutover and should not become the Atlas implementation container.

Define dependency direction: screens → Atlas presentation/interaction → layout/projection → existing model/contracts; never renderer → raw API; never screens → duplicate topology derivation. Closed unions/exhaustive handling required for semantic kinds. Any exception must be documented in #251 before implementation.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions