docs(openspec): add change artifacts for email-loop-prevention

Creates openspec/changes/email-loop-prevention/ with all artifacts:

- proposal.md: Why (MAILER-DAEMON bounce loop incident), what changes
  (automated sender detection + message-count cap), capabilities affected
- design.md: Two-layer defence rationale, detection signal table, decisions
  on channel/agent boundary split, 20-message cap, one-shot alert, CC-only
  routing; risks and trade-offs documented
- specs/email-channel/spec.md: ADDED requirements for detect_automated_message(),
  is_automated/automated_reason message dict fields, no-reply guarantee
- specs/registration-notifications/spec.md: ADDED requirements for
  notify_loop_escalation() — alert content, one-shot guarantee, CC-only
  routing, dev-mode guard
- tasks.md: All 6 sections fully checked (implementation already complete)

https://claude.ai/code/session_01KwvR5hDPjSuJg4kvw5b5e5

openspec/changes/email-loop-prevention/specs/email-channel/spec.md

@@ -0,0 +1,54 @@
+## ADDED Requirements
+
+### Requirement: Automated sender detection
+The system SHALL detect whether an inbound email was sent by an automated system rather than a human, before the message is processed by the agent.
+
+#### Scenario: MAILER-DAEMON sender
+- **WHEN** an email arrives with a sender local-part of `mailer-daemon`, `postmaster`, `noreply`, `no-reply`, `donotreply`, or `bounce` (case-insensitive)
+- **THEN** the system SHALL flag the message as automated with a reason string identifying the sender pattern
+
+#### Scenario: RFC 3834 Auto-Submitted header
+- **WHEN** an email contains an `Auto-Submitted` header with any value other than `no`
+- **THEN** the system SHALL flag the message as automated, citing the header value in the reason
+
+#### Scenario: Auto-Submitted: no is not automated
+- **WHEN** an email contains `Auto-Submitted: no`
+- **THEN** the system SHALL NOT flag the message as automated based on this header
+
+#### Scenario: Microsoft Exchange auto-reply suppression
+- **WHEN** an email contains an `X-Auto-Response-Suppress` header (any value)
+- **THEN** the system SHALL flag the message as automated
+
+#### Scenario: Delivery Status Notification (RFC 3462)
+- **WHEN** an email has `Content-Type: multipart/report`
+- **THEN** the system SHALL flag the message as automated, as this indicates a machine-generated delivery status or read receipt
+
+#### Scenario: X-Loop header
+- **WHEN** an email contains an `X-Loop` header (any value)
+- **THEN** the system SHALL flag the message as automated
+
+#### Scenario: Bulk or junk precedence
+- **WHEN** an email has a `Precedence` header with value `bulk` or `junk`
+- **THEN** the system SHALL flag the message as automated
+
+#### Scenario: Bounce / OOO subject line
+- **WHEN** an email subject matches patterns indicating delivery failure or automated response (e.g. "Undelivered Mail", "Mail Delivery Failed", "Out of Office", "Abwesenheitsnotiz", "Automatische Antwort")
+- **THEN** the system SHALL flag the message as automated
+
+#### Scenario: Normal parent message
+- **WHEN** an email has a normal human sender address and no automated-sender headers
+- **THEN** the system SHALL NOT flag the message as automated
+
+### Requirement: Automated messages are never replied to
+The system SHALL NOT send any reply to a message flagged as automated.
+
+#### Scenario: Bounce message arrives
+- **WHEN** the system receives a message flagged as automated
+- **THEN** the system SHALL mark the message as read (IMAP Seen flag)
+- **AND** the system SHALL call the agent's automated-message handler
+- **AND** the system SHALL NOT send any outbound email reply
+
+### Requirement: Message dict includes automation flag
+Every message returned by `fetch_unread_messages()` SHALL include:
+- `is_automated` (boolean): whether the message was flagged as automated
+- `automated_reason` (string): human-readable reason if flagged, empty string otherwise

openspec/changes/email-loop-prevention/specs/registration-notifications/spec.md

@@ -0,0 +1,31 @@
+## ADDED Requirements
+
+### Requirement: Loop escalation alert to admin
+The system SHALL send a plain-text warning email to the admin when a conversation is stopped due to an automated sender or message-count cap breach.
+
+#### Scenario: First automated message from a sender
+- **WHEN** the first automated/bounce message is received from a sender address
+- **THEN** the system SHALL send one alert email to the admin CC address list
+- **AND** the subject SHALL begin with `[WARNUNG]` for easy inbox filtering
+- **AND** the subject SHALL include the sender's email address
+- **AND** the body SHALL include: sender address, conversation ID, detection reason, and message count
+- **AND** no further alert SHALL be sent for subsequent automated messages from the same sender
+
+#### Scenario: Conversation exceeds message-count cap
+- **WHEN** a conversation accumulates more than 20 inbound user messages without completing
+- **THEN** the system SHALL send one alert email to the admin CC address list on first breach
+- **AND** the body SHALL identify the conversation and state that the message limit was exceeded
+- **AND** no further alert SHALL be sent for subsequent messages in the same capped conversation
+
+#### Scenario: No admin CC address configured
+- **WHEN** `ADMIN_EMAIL_CC` is not set and a loop escalation is triggered
+- **THEN** the system SHALL log a warning
+- **AND** the system SHALL NOT attempt an SMTP connection
+
+#### Scenario: No SMTP host configured (dev mode)
+- **WHEN** `SMTP_HOST` is not set and a loop escalation is triggered
+- **THEN** the system SHALL log the notification content
+- **AND** the system SHALL NOT attempt an SMTP connection
+
+### Requirement: Alert routing
+Loop escalation alerts SHALL be sent only to the admin CC list (`ADMIN_EMAIL_CC`). They SHALL NOT be sent to playgroup leaders (Andrea Sigrist, Barbara Gross), as loop detection is an operational concern, not a registration event.