ADR-004 — Send-as-TA → Pre-Drafted Messaging

ADR-004: "Send as TA" → Pre-drafted Messaging

Status: Accepted | Date: 2026-04-15 | Supersedes: N/A (feature was proposed, not in v1)

Context -- What was proposed and why it was risky

The stakeholder asked for identity switching across all communication screens: admin composes a message but the student receives it from a named TA. This would require composed_by/sent_as field pairs on every message record, reply-routing logic (does the reply go to the composing admin or the named TA?), TA awareness policies (is the TA notified that messages went out in their name?), and permission scoping (which admins can impersonate which TAs). The feature was classified as Category D because it would bleed across Communication, Teacher Management, and potentially Billing (payment reminders "from" a TA).

The underlying need is personal connection -- students should feel contacted by their teacher, not by a faceless admin system.

Decision

Identity switching is rejected. Instead, admins can pre-draft messages for TAs within the Communication domain. The TA reviews the draft in their own account and sends it themselves. No impersonation, no dual-identity records.

Rationale

Pre-drafting solves the personal-connection goal without the cross-cutting complexity. The message genuinely comes from the TA (authentic sender, correct reply-to, no audit ambiguity). It also keeps TAs in the loop -- they see what goes out in their name before it goes out. Stakeholder confirmed this approach is acceptable: "Yeah that can also be like an option. I mean this isn't like a critical... but I just thought it would be nice to have" (transcript line 263).

Consequences

What the v2 spec should include

• Pre-draft compose flow within Communication (likely Private Messages or Blast Emails): admin selects a TA, writes the message, saves as draft assigned to that TA.
• TA-facing draft queue (production scope, not mockup): TA sees pending drafts, can edit and send or discard.
• Communication Logs records the TA as sender (single identity, no composed_by/sent_as split).

What was avoided

• No identity selector on every communication screen (6 screens spared).
• No composed_by/sent_as dual fields in the data model.
• No reply-routing decision tree.
• No TA-awareness notification subsystem for impersonated messages.
• No RBAC expansion for impersonation permissions.

Implementation notes

• Mockup scope: show a "Draft for TA" action in the compose flow. The TA-facing queue is production-only.
• This feature lives inside the Communication domain established by ADR-003; no new domain or structural addition needed.
• Category downgrade: D → B. The pre-draft pattern is an additive feature on existing communication screens, not a cross-cutting architectural concern.

Open questions

1. Which communication screens support pre-drafting? Private Messages only, or also Blast Emails and Push Notifications?
2. Can an admin pre-draft for multiple TAs at once (e.g., each TA gets a personalized version)?
3. Draft expiry: do unactioned drafts expire or persist indefinitely?