Langchain Test Org → catalog_product migration

A bespoke flat-price converter, an org-wide V3 versioning seed helper, and two shared schema fixes that keep renewal-seed config and custom end-date overrides from silently disappearing across the V2↔V3 round trip.

1. Why this exists

Dealops is migrating each customer org off the legacy V2 pricingSpec + dataSheet pair onto the unified catalog_product data model (Dealops 3). Every org needs its own converter because the way prices and attributes are encoded in V2 differs per org — and the publish seam must reproduce that org's V2 spec 1-1 after a round trip, or it can't be cut over safely.

The roundtrip-catalog-migration skill orchestrates this. This PR is the Langchain Test Org output of that skill, plus three corrections that fell out of running it: two silently-dropped V2 fields, and a refactor that lifts the previously-throwaway "seed the V3 versioning store" step into shared, reusable code.

2. What changes — file map

3. The Langchain converter, in one picture

Base product = the category

The baseProductId is the product's productLine attribute, which is literally V2's categoryId (e.g. langsmithDeployment, agentBuilder, langsmithOE, platformSubscription, professionalServices). baseProductName is that category's display name (from productCategories[].name). The category-less internal commitment product falls back to its own name.

This is catalog-UI grouping only — the reverse converter never reads it, so it cannot break the 1-1 round trip.

The internal commitment product

Langchain's V2 spec contains one priceless internal product used by the engine for minimum-commit calculations. The default sku==datapoint planner drops it (no datapoint → no SKU). The bespoke converter keeps it: price = {}, isActive: false, isNotSelectable: true, no pricebook, no category. It round-trips into V2 unchanged. adminOnly stays false deliberately — flipping it would change the V2 productSpec and break 1-1.

4. The two silent-drop bugs this PR fixes

Both bugs affected every org, not just Langchain. They surfaced because Langchain happens to use these fields in production data, and a 1-1 round trip exposed the loss.

OUT_OF_SCOPE_FIELD_KEYS = [
  'startDate',
  'endDate',
  'customEndDateOverrideInWeeks',  // dropped
];

STRUCTURAL_FIELD_KEYS = [
  ...,
  'customEndDateOverrideInWeeks',
  'includeInRenewalSeed',
  'renewalSeedProductSpecIds',
  'renewalSeedProductSpecId',
];

Renewal-seed fields — never had a V3 home

The renewal-substitution config (23 Langchain SKUs use it) consists of three top-level V2 productSpec fields the engine reads to determine what a product renews into. The V2↔V3 converter pair had no mapping for any of them. This PR:

1. Adds them to v3ProductSpecSchema in pricingSpec/types.ts.
2. Copies them V2→V3 in pricingSpec/converter.ts (only when set, to avoid stamping undefined).
3. Copies them V3→V2 in pricingSpec/v2Converter.ts symmetrically.
4. Lists them in STRUCTURAL_FIELD_KEYS so productSpecToRow stashes them in systemAttributes.

// pricingSpec/converter.ts — convertProductSpec
...(v2.includeInRenewalSeed !== undefined && {
  includeInRenewalSeed: v2.includeInRenewalSeed,
}),
...(v2.renewalSeedProductSpecIds?.length && {
  renewalSeedProductSpecIds: v2.renewalSeedProductSpecIds,
}),
...(v2.renewalSeedProductSpecId && {
  renewalSeedProductSpecId: v2.renewalSeedProductSpecId,
}),

The matching catalogProductMapping.test.ts assertion is updated so the "out-of-scope drop" test now verifies preservation of customEndDateOverrideInWeeks alongside the still-dropped startDate/endDate.

5. The registry seam — how publish picks this up

The shared _utils/registry.ts is the dispatch table the real publish path (trpc/router/v3Admin/_helpers.ts and publishDrafts.ts) consults. Adding an org is intentionally minimal — one entry, two function references:

'langchain-test-org': {
  pricingSpecToV2: langchainCatalogToV2PricingSpec,
  catalogToV2Datapoints: langchainCatalogToV2Datapoints,
},

The Langchain reverse functions are thin wrappers over the shared converters — the org has no variant families to collapse, and its single flat_price → LIST_PRICE mapping is exactly what convertToV2DataSheet(deriveV3Datasheet(...)) already produces. No bespoke per-org reverse logic, unlike Xendit.

6. The versioning-store seed, lifted into shared code

A migrated org isn't usable on DEALOPS_V3 from catalog_product rows alone. The V3 admin shell, publish, and the Config Agent all read from the versioning store (OrgSpecVersion rows + one OrgGlobalVersion), and all five SpecTypes must exist or those surfaces throw.

Previously this was done by hand with throwaway scripts (seedAttributesFromCatalog.ts, seedAttributesFromPayload.ts, …). This PR moves the work into _utils/versioningSeed.ts and rewrites Xendit's initV3.ts on top of it, so every future org seeds identically.

Attribute derivation enforces the reader's rules

deriveCustomAttributeDefs() walks the planned rows and infers each key's valueType (boolean / number / enum ≤ 50 distinct strings / string / multi_enum for array values). It drops anything that would make loadAttributeSchema throw at read time:

• Reserved keys (productId, pricebookId) — dropped.
• Keys colliding with a system attribute — dropped (else "Key conflict" at read).
• Unrepresentable values (nested objects) — dropped.
• Every emitted def is validated against attributeDefSchema.

Atomic five-spec write

// seedV3VersioningStore — applies in fixed order:
['pricingSpec', 'datasheet', 'attributes', 'flowSpec', 'workflowSpec']
// 1. validate every body against its strict V3 schema
// 2. refuse if org already has a global version (unless --force-reseed)
// 3. saveSpecVersion × 5
// 4. createGlobalVersion pointing at all five

7. Safety guards — env + org pinning

Both migrate.ts and initV3.ts run in dry-run by default. Any DB write goes through two independent guards, lifted into _utils/safety.ts:

8. Verification — what the PR proves

The verify.ts harness diffs through the real publish seam (the registry dispatch), bucketing diffs into acceptable (engine-neutral attributes mirror, isRequired: false → undefined) vs must-resolve. A non-clean run exits non-zero.

9. What this PR does not change

10. Order of operations (when this gets rolled out)

11. Risks & open notes