Safeguarding: SELF DV/SA 999 parity, CHILD_AT_RISK_EXIT wiring, professional regression tests - #21
Conversation
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
…ll site Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
… for DV and SA exits Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
…m 79 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
james-cross
left a comment
james-cross
left a comment
There was a problem hiding this comment.
This is good. I'm happy with the PR as is. There's just a couple of small things for you to take a look at that I've added inline.
| test('CHILD_AT_RISK_EXIT resolves to base entry with 999 line for SELF and PROFESSIONAL', () => { | ||
| // The call site passes session.userType (not a boolean). There is only a | ||
| // base CHILD_AT_RISK_EXIT entry — no __SUPPORTER or __PROFESSIONAL variant. | ||
| // Both registers must fall through to the base entry and still surface the | ||
| // 999 line. Guards the wiring so adding a variant later can't silently | ||
| // break either register. | ||
| const NINE_NINE_NINE = 'If a child is in immediate danger, call 999.'; | ||
| for (const userType of ['SELF', 'PROFESSIONAL'] as const) { | ||
| // B7D_4A option 4 = Child safety -> CHILD_AT_RISK_EXIT | ||
| const session = sessionAt('B7D_4A_PREVENTION_SAFEGUARDING_FOLLOW_UP', { userType }); | ||
| const result = select(session, 4); | ||
| expect(result.text).toContain(NINE_NINE_NINE); | ||
| } | ||
| }); |
There was a problem hiding this comment.
The test loops ['SELF', 'PROFESSIONAL'] and the comment says "Both registers must fall through to the base entry". There are actually three registers, and SUPPORTER is the one not asserted. It resolves to base by the same path, so behaviour is correct, but since the point of the test is to guard the wiring against a future variant being added, adding 'SUPPORTER' to the loop would lock all three registers rather than two. One-word change to the array.
There was a problem hiding this comment.
The code is right. The 999 line is added to the SELF base entries (the ones a self-discloser actually receives, since getPhrase returns base for 'SELF'), uses second-person wording to match the audience, sits at the end mirroring the already-approved __SUPPORTER pattern, and isn't duplicated anywhere. 999 is a sanctioned hard-coded safeguarding route and it's phrasebank content, not generated The two new SELF tests enforce that every DV and SA SELF exit includes it, so the parity can't silently regress.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
2 participants
Safeguarding follow-ups surfaced in the PR #20 review. Three items, all on the DV/SA/child-at-risk exit paths.
Scope
__SUPPORTERpattern; uses second-person wording (If you're in immediate danger, call 999.).session.userTypethrough thesafeguardingExit('CHILD_AT_RISK_EXIT', ...)call site (was passing theisSupporterboolean), matching the DV/SA call sites and completing safeguarding-pathway selector coverage. No behaviour change — there is only a baseCHILD_AT_RISK_EXITentry, so every register resolves to it.__PROFESSIONALregression tests (DV Male, DV LGBTQ+, SA Male, SA LGBTQ+), each asserting professional framing present, supporter framing absent, and the 999 line present, with helpline numbers read from each variant's actual phrasebank entry.Verification
tsc --noEmitclean.Commits
f274f2afeat(safeguarding): add 999 line to SELF DV and SA exits for paritybe11c58refactor(safeguarding): thread userType through CHILD_AT_RISK_EXIT call sitebb73d03test(safeguarding): add Male and LGBTQ+ professional regression tests for DV and SA exitsVA_BACKLOG.md)🤖 Generated with Claude Code