OCI WAF Reliability Review
Purpose
Review OCI Well-Architected reliability posture with source-grounded checks for regions, domains, backups, replication, alarms, Full Stack DR, RTO/RPO, restore drills, and operational runbooks.
Use When
- Reviewing this OCI domain for stale, missing, risky, vague, over-permissive, or under-specified guidance.
- Comparing current official OCI documentation against existing operational assumptions.
- Producing a source-grounded advisory that separates documented behavior, sampled configured-environment evidence, inference, and unknowns.
Operating Rules
- Keep primary responses lean; put detailed service behavior and caveats in references.
- Use official OCI documentation for documented service behavior.
- Use OCI API evidence through the user’s configured read-only OCI MCP only for command shape or sanitized sampled current-state observations.
- Do not mention local connector names, internal tool names, profile names, account-specific identifiers, or environment-specific paths.
- Never ask for credentials, tokens, tenancy details, compartment or resource identifiers, customer data, private keys, wallets, or config contents.
- Require explicit approval before any mutation or external support-channel action.
Reference Pack
references/oci-waf-reliability-review-operations.md — service shape, wrong assumptions, operating rules, and pushback triggers.references/safety-checklist.md — risk gates, mutation boundaries, credential boundaries, and evidence labels.references/mcp-and-evidence.md — official docs versus sampled OCI API evidence discipline.references/workflow-and-output.md — execution flow and final response contract.references/official-sources.md — official OCI source URLs and current evidence notes.
Response Contract
Return verdict, evidence_level, blockers, safe_next_actions, and open_questions. Be blunt when evidence is insufficient.
1---2name: oci-waf-reliability-review3description: OCI WAF Reliability Review4---56# OCI WAF Reliability Review78## Purpose910Review OCI Well-Architected reliability posture with source-grounded checks for regions, domains, backups, replication, alarms, Full Stack DR, RTO/RPO, restore drills, and operational runbooks.1112## Use When1314- Reviewing this OCI domain for stale, missing, risky, vague, over-permissive, or under-specified guidance.15- Comparing current official OCI documentation against existing operational assumptions.16- Producing a source-grounded advisory that separates documented behavior, sampled configured-environment evidence, inference, and unknowns.1718## Operating Rules1920- Keep primary responses lean; put detailed service behavior and caveats in references.21- Use official OCI documentation for documented service behavior.22- Use OCI API evidence through the user’s configured read-only OCI MCP only for command shape or sanitized sampled current-state observations.23- Do not mention local connector names, internal tool names, profile names, account-specific identifiers, or environment-specific paths.24- Never ask for credentials, tokens, tenancy details, compartment or resource identifiers, customer data, private keys, wallets, or config contents.25- Require explicit approval before any mutation or external support-channel action.2627## Reference Pack2829- `references/oci-waf-reliability-review-operations.md` — service shape, wrong assumptions, operating rules, and pushback triggers.30- `references/safety-checklist.md` — risk gates, mutation boundaries, credential boundaries, and evidence labels.31- `references/mcp-and-evidence.md` — official docs versus sampled OCI API evidence discipline.32- `references/workflow-and-output.md` — execution flow and final response contract.33- `references/official-sources.md` — official OCI source URLs and current evidence notes.3435## Response Contract3637Return `verdict`, `evidence_level`, `blockers`, `safe_next_actions`, and `open_questions`. Be blunt when evidence is insufficient.
VincentChuWaiChow