feat(children-v2): v2.1 enabler — MRF-default + answerObject v4 (2/3, stacks on #9686)#9687
Open
tutntut wants to merge 3 commits into
Open
feat(children-v2): v2.1 enabler — MRF-default + answerObject v4 (2/3, stacks on #9686)#9687tutntut wants to merge 3 commits into
tutntut wants to merge 3 commits into
Conversation
MRF/unified-modes is the definitive home for the children field, so a children field in a Multi-respondent form is v2 by default — no children-v2 flag needed. createFormField/updateFormField add the `responseMode === Multirespondent` term; the builder reintroduces isChildrenV2InBuilder (version OR MRF) and canAddChildrenField offers the field in MRF too. (ADR-0001) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
adaptV3ToV4 produces the v2 children answer shape (single child, no child-N numbering, optional per-child `type` threaded from childrenTypes). Wired at the SDK adapter so it flips on automatically when storage-mode v4 lands; v2 itself still ships end-to-end through the existing V3 path. (ADR-0001) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Tick the box to add this pull request to the merge queue (same as
|
…mmetry Review follow-up: - Cite ADR-0001 (not the not-yet-present ADR-0002) in the v2-invariant comments (createFormField, updateFormField, enforceChildrenV2Invariants, EditMyInfoChildren) — the dropped-options/version decisions are ADR-0001. - Document why the v2 test differs between create (ignores payload version so the flag/MRF stays the authoritative gate) and update (trusts the stamped version, never re-derives from the flag). - Note in adaptV4ToV3 that per-child `type` is intentionally not reconstructed (v3 has no slot; reverse path is decrypt-only) — flags the one-way seam. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this is
Part 2 of 3 of the MyInfo Children v2 split (#9678). This is the v2.1 platform enabler. It stacks on PR-A (#9686) — review/merge that first; this PR's diff is only the incremental v2.1 changes.
What's in this PR
Two enablers that prepare MyInfo Children v2 for the unified-modes / answerObject-v4 world. Both are built but stay dark until storage-mode v4 and MRF-with-webhook land (Converge Storage & MRF Modes).
1. v2 is the default for children in Multi-respondent forms
MRF / unified modes is the definitive home for the children field, so a children field added to a Multi-respondent form is v2 by default — no
children-v2flag needed (the flag continues to gate v2 only in Storage/Encrypt mode).createFormField/updateFormFieldadd theresponseMode === Multirespondentterm; the builder reintroducesisChildrenV2InBuilder(version === V2or MRF) andcanAddChildrenFieldnow offers the field in MRF too.2. answerObject v4 children shape
adaptV3ToV4now emits the v2 children shape — single child, nochild-Nnumbering, optional per-childtypethreaded fromchildrenTypes. Wired at the SDK adapter so it flips on automatically when storage-mode v4 is enabled; v2 itself still ships end-to-end through the existing V3 path in PR-A.Anything breaking? No.
Backwards compatible. The MRF-default path is gated behind the existing
betaFlags.childrenwhitelist (which must stay tight until the MRF submission path is fully wired). The v4 adapter shape only activates when storage-mode v4 is enabled.Tests
TC1: MRF default (builder)
children-v2flag (behind thebetaFlags.childrenwhitelist).TC2: Storage-mode unchanged
children-v2flag (this PR doesn't change that path).TC3: v4 adapter shape
adaptV3ToV4on a v2 children answer yields a single child, nochild-Nnumbering, and a per-childtypewhenchildrenTypesis present (covered by the SDK spec).🤖 Assembled by Claude Code (part 2 of the #9678 split). Verified locally via type-check across backend/frontend/sdk + lint; backend Jest / frontend vitest run on CI (native-module mismatch blocks them in the authoring sandbox).