[ndeloof]

What this PR does, in one sentence

Promotes an x-* extension to the attribute the specification adopted it as, when that attribute is not already set.

Context

Compose lets experiments use x-* attributes without any check. When one of them is adopted (x-develop became develop, x-initialSync became initial_sync), files written with the extension silently stop working, unless every consumer reads both spellings. The adoption of initial_sync is an example: the loader now only knows the new name.

What the PR brings

• A table of adopted extensions, starting with x-develop and x-initialSync. Adopting the next attribute is one line, and a test checks that each entry targets an attribute of the schema.
• Files keep working under either spelling, and consumers only ever see the attribute. When both are set on the same service, the extension is merged under the attribute with the usual merge rules: the attribute wins on conflicting values, and an incompatible shape is reported.
• Each file is promoted on its own, before include, extends and merge: an override written with the extension still overrides its base file, and included or extended services are promoted too.
• !reset and !override written on the extension act on what earlier files declared under the attribute's name.
• A value that is invalid for the attribute is now rejected by the usual validation, with the attribute's path, instead of being ignored.
• Files that use none of these extensions are unaffected.

Why this shape

The table lives in the loader rather than in the schema: it only concerns how this library reads files written before an adoption, and it needs no change in the specification. Should an adoption change the shape of the value, the entry is where a conversion would go, as a follow-up.

🤖 Generated with Claude Code

[glours]

loader/tests/extensions_test.go — TestExtensionAliasWithReuse/extends

Nothing pins the position of promoteAliases (loader/loader.go:513). Moving the call to just before override.Merge(dict, cfg) keeps ./loader/... fully green, but changes the result:

• base has develop.watch=[a], web extends it and sets x-develop.watch=[b]: expected [a, b], got [a]. The user's x-develop is silently ignored and left as an extension.
• base has x-develop.watch=[a], web extends it and has its own develop.watch=[b]: expected [a, b], got [b], with a leftover x-develop.

The current extends subtest doesn't catch it because web has no develop of its own, so promotion still lands before the merge. Moving the call after the merge or removing it is caught (8 subtests fail), so the gap is only "before merge but after extends".

Suggested case, next to the existing extends subtest:

name: test
services:
  base:
    image: app
    develop:
      watch:
        - path: src
          action: sync
          target: /app
  web:
    extends:
      service: base
    x-develop:
      watch:
        - path: other
          action: rebuild

expected web.develop.watch = [src, other].

[ndeloof]

@glours re your review: the ordering concern (nothing pinned promoteAliases's position relative to extends, so a future refactor could silently drop the alias) is addressed in d2ffe87 — it adds the two suggested regression cases ("extends with the extension on the extending service" and "extends with the extension on the base service"), which pass with the current implementation.

[glours]

LGTM