@maverickcer/env-cap
    Preparing search index...

    Function detectDuplicateVariableShapes

    • Flags differently-named variables in different contracts that share an identical type shape -- a soft signal that two features may be independently modelling the same underlying configuration value under two names, worth a human glance before they drift apart.

      Parameters

      Returns CompatibilityIssue[]

      Always severity: "info", and never escalated to blocking by any flag, including --strict -- an identical shape is genuinely common and frequently correct (two unrelated features can both take a number timeout with a validator, and that is not a defect). This is an observation offered to a reader, not a rule; making it blockable would make it noise a team has to suppress rather than a signal they can scan.

      Scope, deliberately narrow on every axis:

      • Different keys only. Same-key collisions across contracts are detectCompatibilityIssues()'s own, entirely separate concern above; reporting them here too would double-report one problem under two codes.
      • Different contracts only. Two same-shaped variables inside one contract are that contract's own deliberate design.
      • Active contracts only. An inactive contract is wired into nothing, so an overlap with it is not a live duplication.
      • No exclusive-grouped contracts. Members of an exclusive group are interchangeable alternatives by explicit authorial declaration -- matching shapes there are the point, not a smell.
      • Pairwise, never transitive. Three mutually-matching variables emit three independent findings (A-B, A-C, B-C), never one merged "cluster": each pair is its own question a reader answers on its own, and a cluster would imply a transitive relationship this check never established.