[aledbf]

What TS does

• configuration in read-configuration, up and set-up is the devcontainer.json object as JSON.parse built it. Its containerEnv, features and each Feature's options keep JS property order: integer-like keys first, ascending, then the others as declared.
• mergedConfiguration.containerEnv is mergeConfiguration's Object.assign over the metadata entries, so a key keeps the position it first had.
• up passes the merged containerEnv to docker run as -e flags in Object.keys order (singleContainer.ts).

Before / after

Input: containerEnv {ZED, 10, ALPHA, 2}, features {zeta: {zz, 10, a, 2}, 10, alpha}.

Place	Before	After (= TS)
configuration.containerEnv	10, 2, ALPHA, ZED	2, 10, ZED, ALPHA
configuration.features	10, alpha, zeta	10, zeta, alpha
configuration.features.zeta	10, 2, a, zz	2, 10, zz, a
mergedConfiguration.containerEnv	10, 2, ALPHA, ZED	2, 10, ZED, ALPHA
docker run -e in up	Go map order (random)	2, 10, ZED, ALPHA

This reuses the orders the loader already records (ContainerEnvOrder, FeatureOrder, FeatureOptionOrder) and MergedConfig.ContainerEnvOrder from #75. The --ca-bundle variables, which TS doesn't have, go after the configured ones.

Tests

• Unit test: TestReadConfigurationWritesNestedObjectsInPropertyOrder. It fails on main.
• Updated test: TestMergedConfigurationOutput reads the ordered containerEnv object's fields. The assertion is unchanged.
• New parity cases. Each one fails with main's code and matches TS with this change; I checked locally with the workspaces under /var/tmp.
  • contract read-configuration.configuration-container-env-and-features-key-order-success
  • runtime read-configuration.merged-container-env-key-order-success
  • runtime up.container-env-run-order-success. It logs the docker run argv through a --docker-path wrapper; Config.Env isn't compared because Docker reorders it.

Checks

• task lint: 0 issues.
• BASE=origin/main task mutate: 16 refused, 0 survived.
• task test:race: pass, with TMPDIR outside /tmp.
• task parity:contract: 116 matched. The 4 failures fail only because of a stray /tmp/.git on the dev machine; that includes the new case, which passes with a /var/tmp workspace.
• task spec:compliance: pass.
• task test:e2e: 13/13 pass.
• Runtime parity: I ran only the new cases locally. CI runs the full runtime lane.

🤖 Generated with Claude Code