Summary

Refactors createConfigExtensionSpecification to accept optional deployConfig, transformLocalToRemote, and transformRemoteToLocal parameters directly, alongside the existing transformConfig. This is a prerequisite for the app module contracts migration — it unblocks all per-module PRs (#6909–#6915).

Why this is necessary

Today, createConfigExtensionSpecification derives both forward (transformLocalToRemote) and reverse (transformRemoteToLocal) transforms from a single transformConfig parameter. There is no way to express "no forward transform" — resolveAppConfigTransform always returns a function.

The contract migration requires exactly this: each core app config module needs to stop sending CLI-transformed payloads and instead send TOML-shaped data directly via deployConfig, while preserving the reverse transform (since the server still returns Layer 2 field names and app config link/pull depends on transformRemoteToLocal).

Without this change, per-module migrations would have to either:

1. Hack transformConfig with dummy forward functions that are never called
2. Switch to createContractBasedModuleSpecification, which removes the reverse transform entirely and breaks app config link and app config pull

What changes

createConfigExtensionSpecification now accepts three new optional parameters:

• deployConfig — passed through to the extension spec. When set, the deploy path uses this instead of transformLocalToRemote (the existing fallback chain in extension-instance.ts:211 is deployConfig ?? transformLocalToRemote ?? undefined).
• transformLocalToRemote — overrides the forward transform derived from transformConfig. Can be left undefined to express "no forward transform."
• transformRemoteToLocal — overrides the reverse transform derived from transformConfig.

Resolution logic:

transformLocalToRemote = direct param ?? (derive from transformConfig if present) ?? undefined
transformRemoteToLocal = direct param ?? derive from transformConfig/schema

Backward compatibility

• transformConfig is now optional but fully supported — all existing specs using it are unchanged
• When only transformConfig is provided, behavior is identical to before
• Direct params take precedence over transformConfig-derived values when both are provided
• No existing spec files are modified in this PR

How per-module PRs (#6909–#6915) use this

Each module migrates from:

createConfigExtensionSpecification({
  identifier: 'branding',
  schema: BrandingSchema,
  transformConfig: {name: 'name', app_handle: 'handle'},
})

To:

createConfigExtensionSpecification({
  identifier: 'branding',
  schema: BrandingSchema,
  deployConfig: async (config) => configWithoutFirstClassFields(config),
  transformRemoteToLocal: (content: object) => ({
    name: (content as {name: string}).name,
    handle: (content as {app_handle: string}).app_handle,
  }),
})

This sends TOML-shaped data directly (via deployConfig), with no forward transform. The server's write adapter normalizes to Layer 2 for storage. The reverse transform is preserved for app config link/pull.

Test plan

• Existing transformConfig usage still derives both transforms correctly
• deployConfig + transformRemoteToLocal work without transformConfig (forward transform is undefined)
• Direct params take precedence over transformConfig-derived values
• All 47 existing specification integration tests pass

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 (1M context) [email protected]