Skip to content

#250 child: Define Atlas data-refresh and visual-change policy #269

Description

@Joncallim

Parent: #250. Live-refresh + camera-state orthogonal pass.

DockerMap refreshes while the user is looking at it. Freeze how model revisions change the Atlas without flicker, camera jumps, or misleading motion.

Model/revision policy

  • state/freshness/finding-only updates change markers/text without moving topology;
  • structural updates apply atomically from one coherent model revision;
  • no intermediate half-layout;
  • Atlas must consume the already generation/provenance/modelRevision-coherent model path rather than starting independent screen-level fetches;
  • selection remains if the exact safe identity survives;
  • disappeared/collided selection fails closed with explicit recovery;
  • removed subjects leave without decorative animation;
  • added subjects appear in their deterministic local region;
  • no physics settling.

Camera/viewport policy

Logical layout stability is insufficient if the viewport auto-fits on every update. Freeze camera state independently from topology state:

  • initial entry may use one deterministic fit/framing rule;
  • once the user has a viewport, unrelated model revisions must not automatically refit/recenter it;
  • state-only, relation-only, attachment-only, and unrelated local structural changes preserve camera transform exactly unless the current target becomes invalid;
  • lens switching preserves camera where the same canonical context remains meaningful;
  • focus/select actions may invoke a documented ensure-visible/local-center operation, not an arbitrary whole-host refit;
  • explicit Reset/Fit is user initiated;
  • Home preview has its own noninteractive framing derived from canonical logical bounds and is not durable camera state;
  • browser resize may clamp/ensure visibility but must not mutate canonical logical coordinates.

Property/browser tests must distinguish logical displacement from screen-space displacement caused by camera changes. Both are stability gates.

Density/theme policy

Theme must never affect logical coordinates. The application density setting must not reorder or globally reflow Atlas topology. Prefer fixed Atlas spatial geometry; density may affect surrounding lists/inspectors and, if Atlas text/padding changes, subject anchor centers/order remain fixed with connector routing derived from documented geometry classes.

Do not animate topology changes in a way that implies causal flow or temporal evidence. If #70 later provides real change events, that evidence may explain a change in the inspector but does not alter deterministic placement/camera rules.

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