docs(phase8): document enrollment operations

New: PHASE8_ENROLLMENT_OPERATIONS.md (phase summary), WINTER_BREAK_CAMP_OPERATIONS.md
(the real operational walkthrough), REGISTRATION_AND_GUARDIAN_COMMUNICATIONS.md,
OFFERING_ADMIN_GUIDE.md.

Updated: ROOTNODE_ACADEMY_BUSINESS_AND_PRODUCT_ARCHITECTURE.md (BUILT NOW/PHASE 8 BUILT
table), OFFERING_AND_REGISTRATION_MODEL.md (both ordering bugs, launch readiness,
registration enforcement), STUDENT_GUARDIAN_DATA_MODEL.md (guardian communications now
wired), WEBSITE_ENROLLMENT_INTEGRATION.md (the real, live registration contract with
worked examples, replacing the old speculative future-flow section), platform/README.md
(test list).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
This commit is contained in:
2026-08-26 23:59:42 -05:00
co-authored by Claude Sonnet 5
parent aa63d09fb8
commit 788fb197e0
9 changed files with 573 additions and 35 deletions
+4 -2
View File
@@ -23,8 +23,10 @@ guardian is a real relationship, not a workaround field.
detailed learning analytics by default. A guardian relationship is a contact/authorization
record, not a monitoring grant.
- **No automatic broad access.** `student_guardians.can_receive_communications` and
`is_primary_contact` govern notification targeting only (a future concern — this phase writes
the rows but does not wire them into `notifications.js`'s resolveRecipient yet), never
`is_primary_contact` govern notification targeting only — wired into `notifications.js`'s
`resolveRecipient()` as of Phase 8 (a communications-enabled primary guardian is the LAST
fallback, tried only after the student's own email and any enrollment-level `contact_email` —
see `docs/REGISTRATION_AND_GUARDIAN_COMMUNICATIONS.md`), never
authorization to student data.
## Data minimization