Problem
When a new group is inserted into source.json (e.g. adding "More Sights" between "Sights" and "Accommodation"), the auto-generated section IDs shift (e.g. preamble-main-content-p1-4 becomes preamble-main-content-p1-5).
The map.json currently resolves mappings using the source field (the section ID), which means inserting a new group breaks existing mappings — the mapping that pointed at Accommodation now points at the new "More Sights" section instead.
Each section already has a StableKey (the group ID from source.json), and map.json already stores a sourceKey field. But the mapping resolution appears to prioritise the positional section ID over the stable key.
Expected Behaviour
- When a
sourceKey is present in a mapping, it should be used to resolve the source section, not the source (section ID) field
- The
source field should be treated as a display/fallback reference only
- Inserting, removing, or reordering groups in
source.json should not break existing mappings
Reproduction Steps
- Set up a workflow with groups mapped in
map.json (e.g. Sights → block, Accommodation → block)
- Insert a new group between them in
source.json
- Re-run the source extraction
- Observe that the mapping for the section after the insertion now points to the wrong section
Real-World Example (Tailored Travel)
- Accommodation was mapped via
preamble-main-content-p1-4
- After adding "More Sights" group, Accommodation became
preamble-main-content-p1-5
- The Accommodation mapping landed on "More Sights" instead
- Had to manually fix
map.json to update both the source ID and the sourceKey
Additional Context
The sourceKey in the existing Accommodation mapping (7df15acf-5938-45ce-a789-9ea2e8483437) did not match the Accommodation group's actual ID (96c2347e-4944-4d26-8a90-757cc45aae18), suggesting the sourceKey may not have been populated correctly when the mapping was originally created via the UI.
Planning
See planning/STABLEKEY_MAP_RESOLUTION.md for investigation notes and implementation approach.
Problem
When a new group is inserted into
source.json(e.g. adding "More Sights" between "Sights" and "Accommodation"), the auto-generated section IDs shift (e.g.preamble-main-content-p1-4becomespreamble-main-content-p1-5).The
map.jsoncurrently resolves mappings using thesourcefield (the section ID), which means inserting a new group breaks existing mappings — the mapping that pointed at Accommodation now points at the new "More Sights" section instead.Each section already has a StableKey (the group ID from
source.json), andmap.jsonalready stores asourceKeyfield. But the mapping resolution appears to prioritise the positional section ID over the stable key.Expected Behaviour
sourceKeyis present in a mapping, it should be used to resolve the source section, not thesource(section ID) fieldsourcefield should be treated as a display/fallback reference onlysource.jsonshould not break existing mappingsReproduction Steps
map.json(e.g. Sights → block, Accommodation → block)source.jsonReal-World Example (Tailored Travel)
preamble-main-content-p1-4preamble-main-content-p1-5map.jsonto update both the source ID and the sourceKeyAdditional Context
The
sourceKeyin the existing Accommodation mapping (7df15acf-5938-45ce-a789-9ea2e8483437) did not match the Accommodation group's actual ID (96c2347e-4944-4d26-8a90-757cc45aae18), suggesting the sourceKey may not have been populated correctly when the mapping was originally created via the UI.Planning
See
planning/STABLEKEY_MAP_RESOLUTION.mdfor investigation notes and implementation approach.