Forge notifications

forge-notifications: Notifications

Purpose

Inspect email, SMS, push, and in-app notifications for authorization, preferences, retries, privacy, and deliverability.

This is an agent playbook, not a claim of standalone analyzer coverage. Apply

fullstack-forge/references/shared/module-contract.md

for common applicability, evidence, command-safety, mutation, verification, and completion rules.

Never hide failed checks or claim that an operation ran when it did not.

Automatic activation signals

Activate when a request or direct repository evidence involves notifications, when the user explicitly names forge-notifications, or when discovery proves an applicable boundary.

• Transactional, security, lifecycle, or marketing messages

When not to activate

• No outbound or in-product notification system

Automated support

Relevant discovery inputs are:

• message producers and templates
• preference model
• provider integrations

Available deterministic support, where present:

• Use inspect-routes for its bounded evidence when present; treat unavailable runtime evidence as NOT_VERIFIED.

Agent inspection procedure

1. Inventory channels (email, SMS, push, in-app) and triggers, and trace one message per channel from trigger to delivery.
2. Verify authorization and preference checks before send, unsubscribe handling, and an audit of who was notified.
3. Check duplicate prevention: idempotency at the trigger and delivery layers, retry behavior, and scheduled-send time zones.
4. Inspect templates for localization, sensitive-data exposure, and deep-link correctness including authentication state.
5. Verify failed-delivery handling, bounce processing, rate limits, and fatigue controls.

Manual inspection requirements:

• Review content accuracy, accessibility, and deliverability settings
• Confirm legally required and user-controlled preference semantics

Stack-specific guidance:

• Treat provider webhooks as hostile signed input and make handlers idempotent

Evidence to collect

For formal findings, also follow fullstack-forge/references/PROTOCOL.md. Record the module's inspected boundary, relevant tests, direct observations, and unavailable evidence.

Primary standards used as criteria, not proof of compliance:

• OWASP ASVS 5.0
• RFC 8058
• WCAG 2.2

Common production failures

• Trace trigger, recipient authorization, template data, locale, channel selection, send, webhook, and state update
• Inspect idempotency, deduplication, rate limits, quiet hours, retry, expiry, unsubscribe, suppression, and bounce handling
• Check sensitive preview content, deep links, spoof resistance, preference overrides, tenant isolation, and provider secrets

Missing-control checks

For every applicable criterion below, attach direct evidence or record a reasoned NOT_APPLICABLE, NOT_VERIFIED, or BLOCKED status. The list is a routing checklist, not evidence by itself.

• Email delivery
• Templates
• Localization
• Unsubscribe behavior
• Notification preferences
• Duplicate sends
• Retry logic
• Scheduled delivery
• Time zones
• Sensitive information
• Deep links
• Failed delivery
• Push permissions
• Rate limits
• Notification fatigue
• Idempotency

Commands and tools

• Run forge notifications audit --json or fullstack-forge notifications audit --json when an explicit audit is requested and the CLI is installed. Normal feature work does not require it.
• Use the deterministic support named above only for its documented bounded evidence.

Safe fixes

• Add deduplication keys, expiry, and sensitive-data redaction
• Correct accessible template markup

Approval-required changes

• Changing mandatory-message policy, consent, sender identity, or provider

Verification

• Send to controlled sinks and trace provider callbacks
• Exercise duplicate, stale, opted-out, bounced, and cross-tenant cases

Completion contract

Apply the shared module contract and the module-specific limitations below.

Known limitations

• Deliverability and carrier behavior require provider evidence