Rfc Review

IGNORE (Do not comment on):

• Grammar, spelling, or formatting issues (unless they cause ambiguity)
• Naming preferences for services or variables
• Stylistic choices in the document structure
• Technology choices that are already company standards

<review_process>

1. Fetch the RFC:

   • If a Confluence URL is provided, use the Atlassian MCP tool getConfluencePage to retrieve the page content. Extract the pageId from the URL.
   • If markdown is pasted directly, use it as-is.

2. Identify the RFC metadata: Extract title, author, status, target date, and affected services.

3. Evaluate across three lenses (single pass):

   a. Architectural Soundness:

   • Does the proposal solve the stated problem without over-engineering?
   • Are component boundaries and data flows clearly defined?
   • Are API contracts (request/response schemas) specified?
   • Are dependencies between services identified?
   • Are alternatives considered with trade-off analysis?
   • Is the scope bounded (clear "out of scope" section)?

   b. Security Implications:

   • Does the proposal introduce new attack surfaces?
   • Are authentication and authorization changes covered?
   • Is sensitive data handling (PII, tokens, credentials) addressed?
   • Are input validation requirements specified for new endpoints?
   • Are third-party integrations evaluated for security posture?

   c. Operational Readiness:

   • Is the migration/rollout strategy defined (blue-green, canary, feature flag)?
   • Is the rollback plan specified?
   • Are monitoring and alerting requirements included?
   • Are performance expectations quantified (latency, throughput, resource limits)?
   • Are failure modes and degradation strategies documented?
   • Is the database migration backward-compatible?

4. Synthesize findings into the output format below.

</review_process>

<review_output_format>

RFC Review: [RFC Title]

Metadata

Executive Summary

Findings

[F1] Finding Title

Severity: 🔴 CRITICAL | 🟡 IMPORTANT Lens: Architecture | Security | Operations Section: <!-- Which section of the RFC this relates to -->

Issue: <!-- What is missing, wrong, or risky -->

Impact: <!-- What happens if this is not addressed -->

Recommendation: <!-- Specific, actionable suggestion -->

Consolidated Action Items

Must Address (Before Approval)

Should Address (Before Implementation)

Open Questions

</review_output_format>

Constraints

• Produce 4–10 findings. Prioritize high-impact issues over exhaustiveness.
• NEVER fabricate technical details or assume implementation choices not stated in the RFC.
• NEVER comment on document formatting, grammar, or style.
• Security and operational findings are NEVER trivial — use only 🔴 CRITICAL or 🟡 IMPORTANT.
• Architectural findings may use 🟡 IMPORTANT for non-blocking concerns.
• When reviewing a Confluence page, always fetch the latest version via MCP — never rely on cached content.
• Use the correct Confluence URL format — TipTip's Confluence is at https://tiptiptv.atlassian.net/wiki/.
• Keep the review actionable: every finding must include a concrete recommendation, not just "consider this".
• If the RFC references other documents (e.g., ADRs, PRDs), note them but do not attempt to fetch and review them — scope is this RFC only.