Task library RCONSENT Privacy engineering · Phased project Keep communication preferences consistent across dispatch channels A fictional event workspace offers optional product announcements and operational booking messages. Its product policy treats these as separate purposes. A stale audience cache currently sends optional messages after a member opts out. The brief implements fictional preference rules and makes no legal-consent certification.
Practice brief · Version 5
Project scope 10 tickets / 3 phases
Total focused work estimate 30h + setup
Suggested stack TypeScript · PostgreSQL · Queue adapter · Email provider double Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.
Choose a bounded subset for an assessment or practice session. Prerequisites and remaining project work must be agreed separately.
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned.
Recommended next step Start with RCONSENT-101 Open the first ticket for its prerequisites, acceptance criteria, verification plan, and an editable task draft.
What the engineer takes away Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries.
What the team gains Create an inspectable preference workflow that can be reviewed against a company-approved communication policy.
Before you start Create synthetic members, versioned notice text and two purpose-tagged message types. Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages. Delivery agreement Ten tickets using provider doubles and synthetic choices. No live mailing lists, legal advice or real outreach are part of the project.
AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.
Delivery phases PHASE 1 Make purpose, notice version and user intent distinguishable.
PHASE 2 Handle stale audiences and queued work with current policy checks.
PHASE 3 Reconcile replicas and explain what was actually enforced.
Model explicit choices Make purpose, notice version and user intent distinguishable.
RCONSENT-101 Entry ticket; project setup still required Estimated field mix
Privacy engineering 80% Backend 20% RCONSENT-102 Depends on RCONSENT-101 Estimated field mix
Privacy engineering 50% Data engineering 30% Security 20% RCONSENT-103 Depends on RCONSENT-102 Estimated field mix
Frontend 40% Privacy engineering 30% Accessibility 30% Enforce choices at delivery Handle stale audiences and queued work with current policy checks.
RCONSENT-104 Depends on RCONSENT-101, RCONSENT-102 Estimated field mix
Privacy engineering 50% Security 30% Platform engineering 20% RCONSENT-105 Depends on RCONSENT-101, RCONSENT-104 Estimated field mix
Privacy engineering 60% Data engineering 40% RCONSENT-106 Depends on RCONSENT-102, RCONSENT-104 Estimated field mix
Distributed systems 60% Privacy engineering 40% Review history and consistency Reconcile replicas and explain what was actually enforced.
RCONSENT-107 Depends on RCONSENT-103, RCONSENT-104, RCONSENT-105 Estimated field mix
Privacy engineering 60% Integrations 40% RCONSENT-108 Depends on RCONSENT-102, RCONSENT-107 Estimated field mix
Security 50% Privacy engineering 50% RCONSENT-109 Depends on RCONSENT-104, RCONSENT-106 Estimated field mix
Distributed systems 40% Privacy engineering 40% Data engineering 20% RCONSENT-110 Depends on RCONSENT-103, RCONSENT-105, RCONSENT-106, RCONSENT-107, RCONSENT-108, RCONSENT-109 Estimated field mix
Quality engineering 40% Privacy engineering 40% Integrations 20% Use this project CSV keeps grouping and dependency keys as descriptive fields. Import mapping depends on your tracker configuration.