Max Mayfield
72a0f26a7b
Per-product surgical additions to existing epics (not cross-cutting): - P1 route: 8pts (key redaction, SSE billing, token math, CI runner) - P2 drift: 12pts (mTLS revocation, state lock recovery, pgmq visibility, RLS leak, entropy scrubber) - P3 alert: 10pts (HMAC replay, claim-check, out-of-order correlation, free tier, tenant isolation) - P4 portal: 9pts (partial scan recovery, ownership conflicts, Meilisearch rebuild, VCR freshness, free tier) - P5 cost: 7pts (concurrent baselines, remediation RBAC, Clock interface, property tests, Redis fallback) - P6 run: 15pts (shell AST parsing, canary suite, intervention TTL, streaming audit, crypto signatures) Total: 61 story points across 30 new stories
2.9 KiB
dd0c/alert — Epic Addendum (BMad Review Findings)
Source: BMad Code Review (March 1, 2026) Approach: Surgical additions to existing epics — no new epics created.
Epic 1 Addendum: Webhook Ingestion
Story 1.6: HMAC Timestamp Freshness (Replay Prevention)
As a security-conscious operator, I want webhook payloads older than 5 minutes to be rejected, so that captured webhooks cannot be replayed to flood my ingestion pipeline.
Acceptance Criteria:
- Datadog: Rejects
dd-webhook-timestampolder than 300 seconds. - PagerDuty: Rejects payloads with missing timestamp header.
- OpsGenie: Extracts timestamp from payload body and validates freshness.
- Fresh webhooks (within 5-minute window) are accepted normally.
Estimate: 2 points
Story 1.7: SQS 256KB Claim-Check Round-Trip
As a reliable ingestion pipeline, I want large alert payloads (>256KB) to round-trip through S3 claim-check without data loss, so that high-cardinality incidents are fully preserved.
Acceptance Criteria:
- Payloads > 256KB are compressed and stored in S3; SQS message contains S3 pointer.
- Correlation engine fetches from S3 and processes the full payload.
- S3 fetch timeout (10s) sends message to DLQ without crashing the engine.
- Engine health check returns 200 after S3 timeout recovery.
Estimate: 3 points
Epic 2 Addendum: Correlation Engine
Story 2.6: Out-of-Order Alert Delivery
As a reliable correlation engine, I want late-arriving alerts to attach to existing incidents (not create duplicates), so that distributed monitoring delays don't fragment the incident timeline.
Acceptance Criteria:
- Alert arriving after window close but within 2x window attaches to existing incident.
- Alert arriving after 3x window creates a new incident.
- Attached alerts update the incident timeline with correct original timestamp.
Estimate: 2 points
Epic 5 Addendum: Slack Bot
Story 5.6: Free Tier Enforcement (10K alerts/month)
As a PLG product, I want free tier tenants limited to 10K alerts/month with 7-day retention, so that the free tier is sustainable and upgrades are incentivized.
Acceptance Criteria:
- Alert at count 9,999 accepted; alert at count 10,001 returns 429 with Stripe upgrade URL.
- Counter resets on first of each month.
- Data older than 7 days purged for free tier; 90-day retention for pro tier.
Estimate: 2 points
Epic 6 Addendum: Dashboard API
Story 6.7: Cross-Tenant Negative Isolation Tests
As a multi-tenant SaaS, I want explicit negative tests proving Tenant A cannot read Tenant B's data, so that confused deputy vulnerabilities are caught before launch.
Acceptance Criteria:
- Tenant A query returns zero Tenant B incidents (explicit assertion, not just "works for A").
- Cross-tenant incident access returns 404 (not 403 — don't leak existence).
- Tenant A analytics reflect only Tenant A's alert count.
Estimate: 1 point
Total Addendum: 10 points across 5 stories