Add automated ISAC system notifications

docs/DESIGN_SYSTEM.md

@@ -129,6 +129,21 @@ daily delivery targets 10:00 AM in `America/New_York` so the Eastern wall-clock
 time remains stable across daylight-saving transitions. On mobile, cadence
 segments wrap to two columns and each review category becomes its own row.
 
+ISAC System Configuration is a distinct navigation domain from System
+Oversight. It contains operational configuration such as Automated Messages and
+read-only observability such as System Metrics. Automated-message editors use
+the standard horizontal edit lifecycle: successful edits close the editor,
+validation preserves it, and event triggers remain explicit. Content, enabled
+state, post-event delay, primary destination, and up to eight action callouts
+are displayed as structured fields rather than raw JSON.
+
+Automated ISAC messages may expose multiple square action callouts in the
+notification inbox and detail view. Callouts wrap on desktop and become
+full-width touch targets on mobile. Each retains a specific verb and
+destination; do not replace the set with a generic “open” action. External
+community actions such as Discord use secure HTTPS destinations while internal
+actions use routed paths.
+
 Contact notifications use the mandatory ISAC visual identity because they are
 operational inbound messages. The notification carries a concise preview and a
 specific action to an authorization-checked full record. Full messages never

docs/architecture.md

@@ -342,3 +342,29 @@ window. Daily rows are assigned to the next 10:00 AM wall-clock boundary in
 dispatched rows retain `delivered_at` evidence and are never selected again.
 The existing ISAC notification delivery preferences still determine optional
 browser and email fan-out after the consolidated inbox message is created.
+
+## Automated ISAC system messages
+
+Automated message definitions live in `automated_system_messages` and are
+managed through ISAC → System Configuration → Automated Messages by agents with
+`system.notifications.manage`. Edits are recorded under the
+`system_configuration` audit category. Definitions identify a lifecycle event,
+enabled state, delay in minutes, message content, primary destination, and
+structured action callouts.
+
+`account.created` is emitted by password, magic-link, and Discord registration.
+The delivery table has a unique message/user/event/event-ID constraint, so the
+same account creation cannot deliver the Welcome Agent message more than once.
+The default welcome introduces News, Database, Builds, Guides, Builder, ISAC
+Contributor Mode, and the SHD Discord community.
+
+Immediate definitions are delivered in the registration request. Definitions
+with a delay are persisted in `automated_system_message_deliveries`. Production
+must run the delayed dispatcher once per minute:
+
+```text
+* * * * * cd /path/to/shd.build && npm run notifications:system:production
+```
+
+Only one dispatcher instance should run for the embedded database. Delivered
+rows retain both their delivery timestamp and generated notification ID.