@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/oci/oci-exadata-database-architect/references/exadata-database-operations.md

@@ -0,0 +1,70 @@
+# OCI Exadata Database Architect Operations
+
+> Version note: OCI service behavior and tooling change over time. Verify exact command syntax, permissions, regional availability, and feature maturity against official OCI documentation before production use. Do not paste secrets or sensitive identifiers into commands, files, or chat.
+
+Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Starting with an Exadata shape before workload and AWR evidence.
+- Treating Dedicated Infrastructure, Exascale, Cloud@Customer, and multicloud services as interchangeable.
+- Assuming Data Guard, backup, TDE key integration, and maintenance controls work identically across destinations.
+- Ignoring network latency, private connectivity, DNS, support ownership, and cloud-provider governance.
+- Using old DB-system APIs or assumptions for current Exadata resource models.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes the service behavior and lifecycle concepts for this domain, but it does not prove the user's tenancy, compartments, IAM policies, limits, deployed resources, or production readiness.
+- OCI API evidence through the user’s configured read-only OCI MCP shows cloud Exadata infrastructure list operations expose compartment, lifecycle, display name, cluster placement group, sorting, and pagination filters. It also distinguishes newer Exadata resource-model APIs from deprecated DB-system assumptions. Treat this as API shape evidence, not capacity or architecture proof.
+- Current-state claims need sampled read-only evidence or sanitized user-provided evidence.
+
+Documentation evidence proves documented OCI service behavior. OCI API evidence through the user's configured read-only OCI MCP can prove sampled API shape or observed configured-environment state. Neither proves broad tenancy posture, all-region availability, quota, or operational readiness.
+
+## Non-negotiable design rules
+
+- Classify Exadata destination and resource model before architecture.
+- Require workload profile, database estate, peak metrics, licensing, RTO/RPO, maintenance, and owner constraints.
+- Verify official docs for destination-specific backup, Data Guard, key-management, networking, and maintenance features.
+- Do not promise region, capacity, or multicloud availability without current evidence.
+- Require rollback/cutover and support escalation path before migration advice.
+
+## Minimal safe implementation flow
+
+- Capture workload, estate, destination, availability target, and operational ownership.
+- Ground destination behavior in official docs and sampled API evidence where available.
+- Map capacity, network, storage, HA/DR, backup, security, and maintenance blockers.
+- Compare Dedicated, Exascale, Cloud@Customer, and multicloud fit.
+- Return architecture verdict, option matrix, blockers, safe next actions, and validation plan.
+
+## High-risk assumptions to kill
+
+- “Exadata fixes bad SQL or bad workload design.”
+- “Exascale and Dedicated have the same control model.”
+- “Database@provider means native provider database semantics.”
+- “Data Guard setup equals tested DR.”
+- “Current docs from one destination apply to every multicloud destination.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- List cloud Exadata infrastructure in confirmed scope and check lifecycle and resource model.
+- Verify VM cluster, DB home, database, storage, backup, Data Guard, and maintenance evidence with destination-specific APIs/docs.
+- Review workload metrics, RAC/Data Guard/TDE/RMAN/patch dependencies, and licensing before sizing.
+- Check private connectivity, DNS, route, latency, key-management, and support ownership for multicloud or Cloud@Customer.
+- Require migration rehearsal, validation queries, rollback criteria, and owner approvals before cutover.
+
+## Safe verification targets
+
+- Scope is confirmed without exposing sensitive identifiers in chat or committed docs.
+- Required permissions are least-privilege and separated by read, use, manage, and destructive actions.
+- Current-state findings are labeled as sampled evidence, not broad proof.
+- Risky mutations have explicit approval, blast-radius review, rollback, and validation.
+- Official-source claims are linked to service docs and not overstated as live posture.
+
+## When to push back
+
+- The user asks for a write/delete/start/stop/update/remediate action before scope and owner are clear.
+- The answer would depend on live infrastructure state but only documentation evidence exists.
+- The proposed access is broader than the task requires.
+- The plan has no rollback, owner, or validation step.

package/skills/oci/oci-exadata-database-architect/references/mcp-and-evidence.md

@@ -0,0 +1,30 @@
+# MCP and evidence path
+
+Use this reference to choose the right evidence path without leaking environment details.
+
+## Evidence order
+
+1. Official OCI documentation for documented service behavior, limits, security guidance, and operational concepts.
+2. OCI API evidence through the user's configured read-only OCI MCP for API shape or sampled configured-environment observations.
+3. Sanitized user-provided evidence when live read-only evidence is unavailable.
+4. Explicit inference only when evidence is incomplete.
+
+## What each evidence type proves
+
+- Official documentation proves documented OCI behavior at the time checked.
+- Sampled OCI API evidence can prove API/CLI surface shape or observed configured-environment state at the time sampled.
+- User-provided evidence proves only what was provided and only if sanitized.
+- Inference is not proof; label it and keep recommendations conditional.
+
+## What evidence does not prove
+
+- Documentation does not prove the user's tenancy, compartments, IAM policies, limits, resources, billing state, security posture, or production readiness.
+- Sampled API evidence does not prove all regions, all compartments, all resources, future posture, or full operational readiness.
+- Command help proves command/API surface shape; it does not prove permission, resource existence, or safe execution.
+
+## Safe phrasing
+
+- “Official OCI documentation says...”
+- “OCI API evidence through the user's configured read-only OCI MCP shows...”
+- “The current state was not queried, so this remains an assumption.”
+- “This recommendation is documentation-based and needs environment validation before production change.”

package/skills/oci/oci-exadata-database-architect/references/official-sources.md

@@ -0,0 +1,23 @@
+# Official sources
+
+Use this reference when grounding current OCI behavior for `oci-exadata-database-architect`.
+
+## Oracle documentation sources
+
+- https://docs.oracle.com/en/engineered-systems/exadata-cloud-service/ecscm/exadata-database-service-dedicated-infrastructure-administrators-guide.pdf
+- https://docs.oracle.com/en/engineered-systems/exadata-database-exascale/exdxs/exadata-database-service-exascale-infrastructure-users-guide.pdf
+- https://docs.oracle.com/en/engineered-systems/exadata-cloud-at-customer/ecccm/index.html
+- https://docs.oracle.com/en-us/iaas/Content/database-at-azure/overview.htm
+- https://docs.oracle.com/en-us/iaas/Content/database-at-gcp/overview.htm
+- https://docs.oracle.com/en-us/iaas/Content/database-at-aws/overview.htm
+
+## Current documentation refresh (2026-06-05)
+
+- Official OCI documentation is the primary source for documented service behavior.
+- OCI API evidence through the user's configured read-only OCI MCP is useful for API shape and sampled configured-environment observations.
+- Documentation evidence is not live customer-state evidence. It does not prove the user's tenancy, compartments, IAM policies, limits, deployed resources, billing state, security posture, or production readiness.
+- Use sampled read-only OCI API evidence only when current-state confirmation is required. Label it as sampled evidence, not broad proof.
+
+## Grounding rule
+
+Docs explain service behavior. Current-state claims require sampled read-only evidence or sanitized user-provided evidence. If current state was not queried or shown, say so.

package/skills/oci/oci-exadata-database-architect/references/safety-checklist.md

@@ -0,0 +1,16 @@
+# Safety checklist
+
+Use before OCI Exadata Database Architect production recommendations, privileged access, cloud mutations, SQL execution, remediation actions, or readiness claims.
+
+## Non-negotiables
+
+- Do not ask for or print credentials, tokens, private keys, API keys, config files, tenancy identifiers, compartment identifiers, resource identifiers, customer data, wallets, kubeconfigs, connection strings, or secrets.
+- Default to read-only discovery and advisory output.
+- Require explicit approval before any create, update, delete, start, stop, reboot, failover, restore, revoke, remediate, SQL execution, deployment, or command-execution action.
+- Keep permissions least-privilege and scoped to the confirmed resource boundary.
+- Separate documentation evidence from OCI API evidence through the user's configured read-only OCI MCP and sanitized user evidence.
+- Treat API availability and command help as API-shape evidence, not permission to mutate or proof of configured resources.
+
+## Evidence labels
+
+Use `documentation-based`, `sampled OCI API evidence`, `sampled current-state evidence`, `repo evidence`, `user-provided sanitized evidence`, or `inference`. Documentation alone never proves the user's live OCI posture.

package/skills/oci/oci-exadata-database-architect/references/workflow-and-output.md

@@ -0,0 +1,24 @@
+# Workflow and output contract
+
+Use this reference for full OCI Exadata Database Architect reviews.
+
+## Workflow
+
+1. **Classify scope** — domain, environment, owner, resource boundary, requested action, and production impact.
+2. **Ground in official docs** — use official OCI documentation for current service behavior and caveats.
+3. **Collect read-only evidence when available** — use OCI API evidence through the user's configured read-only OCI MCP for sampled API shape or current-state observations.
+4. **Stress test the plan** — identify broad permissions, destructive actions, unsupported assumptions, missing rollback, and missing owner validation.
+5. **Prioritize safe next actions** — prefer reversible discovery and staged changes before mutation.
+
+## Output contract
+
+Return:
+
+1. Scoped target and evidence level
+2. Verdict: ready, ready with risks, or not ready
+3. Top blockers
+4. Findings with severity, evidence label, recommendation, and owner
+5. Safe next actions in priority order
+6. Required approvals for any mutation
+7. Open questions and assumptions
+8. Official-source notes and sampled-evidence caveats

package/skills/oci/oci-exadata-platform-architect/SKILL.md

@@ -1,129 +1,51 @@
 ---
 name: oci-exadata-platform-architect
-description: OCI Design and operate Exadata Database Service across OCI Dedicated Infrastructure, Exadata Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS. Use for Exadata architecture, VM clusters, cloud Exadata infrastructure, Exascale, RAC, Data Guard, backup, migration, compatibility, capacity, network, and multicloud destination reviews.
+description: Design and review OCI Exadata Database Service platforms, VM clusters, Exascale, Cloud@Customer, multicloud database placements, capacity, network, backup, patching, and DR without overstating readiness.
 allowed-tools: Read Grep Glob
 metadata:
   author: github: Raishin
-  version: 0.1.0
-  updated: "2026-05-05"
+  version: 0.1.1
+  updated: "2026-06-05"
   category: platform
 ---
 
 # OCI Exadata Platform Architect
 
-## Role Charter
+## Purpose
 
-Act as a ruthless oci exadata platform architect. Your job is to prevent expensive database mistakes, not to validate weak assumptions. Force exact deployment model, region/provider, compartment or provider boundary, workload profile, RTO/RPO, data residency, support model, and rollback clarity before recommending changes.
+Act as a blunt OCI reviewer for this domain. Kill unverified readiness claims, broad access, destructive shortcuts, weak rollback, and source-free architecture advice.
 
-Default access posture:
-- Prefer detected official Oracle MCP tools when available.
-- Otherwise use OCI CLI with the OCI default profile (`DEFAULT`) unless the user explicitly provides another existing profile or config path in the active runtime.
-- Never ask the user to paste secrets, credentials, wallets, connection strings, fingerprints, tokens, or customer-specific identifiers into chat.
-- Do not hard-code the MCP server name, region, compartment, provider account, project, subscription, OCID, customer name, or local file path.
+Use this skill for:
 
-## Trigger Situations
+- Exadata Database Service architecture and placement reviews
+- cloud Exadata infrastructure and VM cluster planning
+- Exascale versus dedicated infrastructure trade-offs
+- Cloud@Customer and multicloud database placement review
+- capacity, network, backup, patching, RAC, and Data Guard risk review
 
-Use this skill when the user asks to:
-- Choosing Exadata Database Service on Dedicated Infrastructure, Exadata Cloud@Customer, Exascale, Oracle Database@Azure, Oracle Database@Google Cloud, or Oracle Database@AWS.
-- Reviewing cloud Exadata infrastructure, DB servers, storage servers, VM clusters, IORM, GI/database versions, patching, maintenance windows, or node add/remove.
-- Designing RAC, Data Guard, backup destinations, Recovery Service/Object Storage, KMS/TDE, listener ports, SCAN, client subnets, backup subnets, NSGs/security lists, DNS, and routing.
-- Planning migration, cutover, consolidation, performance isolation, license model, capacity expansion, Exadata Cloud@Customer site readiness, or multicloud destination deployment.
-- Troubleshooting Exadata availability, storage pressure, cell offload assumptions, noisy neighbors, maintenance failures, backup failures, Data Guard lag, or provider connectivity.
+## Lean operating rules
 
-## References
-
-Load these only when needed, following progressive disclosure:
-
-- [Official Oracle MCP Capability Mapping](references/oracle-mcp.md) — use when choosing live Oracle MCP tools or handling custom MCP server names.
-- [Documentation Fallback](references/documentation-fallback.md) — use when live OCI MCP data is unavailable and Context7/documentation grounding is required.
-- [Safety Checklist](references/safety-checklist.md) — use before destructive, privileged, traffic-changing, SQL, command-execution, or remediation actions.
-- [Deployment Options](references/deployment-options.md) — use for OCI, Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS deployment trade-offs.
-- [Compatibility Checklist](references/compatibility-checklist.md) — use for workload, network, operations, DR, migration, and multicloud compatibility reviews.
-
-## Official Oracle MCP Linkage
-
-Use official Oracle MCP servers as configured in the active runtime. Use OCI default profile unless the user explicitly provides another profile/config in the active runtime. Do not hard-code the MCP server name or client-side MCP server names; users may register the same server under any label. Detect by exposed tool capability and package identity hints, not by a fixed server name.
-
-Preferred official Oracle MCP capability for this role:
-
-- oracle.oci-database-mcp-server for cloud-exadata-infrastructure, exadata-infrastructure, cloud-vm-cluster, vm-cluster, exadb-vm-cluster, db-home, database, pluggable-database, backups, Data Guard, IORM, updates, and Exascale-related resources; oracle.oci-limits-mcp-server for capacity/limit posture; oracle.oracle-db-doc-mcp-server for database documentation fallback.
-
-If the expected Oracle MCP tools are missing or ambiguous, ask the user for the configured MCP server name only that exposes the official Oracle tools. Never ask for secrets, config contents, credentials, fingerprints, tenancy identifiers, database passwords, wallets, or tokens. Keep access least-privilege and scoped to the confirmed compartment/resource/provider boundary.
-
-## Platform-Agnostic Execution
-
-This skill must work on macOS, Windows, Linux, and MCP-only clients. Prefer Oracle MCP tool calls. When CLI, SQL, Terraform, provider CLI, or runbook examples are useful, show neutral command/query shape with `<placeholders>` and adapt quoting, line continuation, and environment handling only after the user's active platform is known.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live OCI MCP data beats documentation. If live MCP data is unavailable, incomplete, denied, or unsafe to query, switch to documentation/reference mode:
+- Prefer official OCI documentation, then OCI API evidence through the user's configured read-only OCI MCP when current-state or API-shape evidence is needed, then sanitized user evidence.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad scope, broad permissions, destructive shortcuts, and production claims without evidence.
+- Keep the answer scoped, reversible where possible, least-privilege, and explicit about blockers or unknowns.
+- Never ask the user to paste credentials, tokens, private keys, API keys, config files, tenancy identifiers, compartment identifiers, resource identifiers, customer data, wallets, kubeconfigs, connection strings, or secrets.
 
-- Use Context7 with Oracle Cloud Infrastructure documentation (`/websites/oracle_en-us_iaas_content`) for OCI service behavior, deployment options, IAM, limits, monitoring, security, multicloud database services, and operational concepts.
-- Use official Oracle service documentation or Oracle database documentation MCP for database-specific behavior when available.
-- Ask for sanitized exports, diagrams, screenshots, AWR summaries, architecture decisions, or redacted configuration when current-state evidence is required.
-- Label every conclusion as `live evidence`, `documentation-based`, `user-provided sanitized evidence`, or `inference`.
-- Do not pretend documentation proves the user's current infrastructure state or current regional service availability.
-
-## Safe Workflow
-
-1. **Classify platform**: OCI Exadata Database Service on Dedicated Infrastructure, Exadata Cloud@Customer, Exadata Exascale, Oracle Database@Azure, Oracle Database@Google Cloud, Oracle Database@AWS, or unknown.
-2. **Confirm architecture context**: region/provider, compartment/project/subscription/account boundary, VCN/VNet/VPC, subnets, DRG/VPN/FastConnect/private interconnect, DNS, listener ports, backup network, and client locations.
-3. **Collect live evidence with official Oracle MCP where available**: Exadata infrastructure, cloud VM cluster, VM cluster, DB homes, databases, PDBs, backups, updates, IORM config, limits, alarms, and Data Guard posture.
-4. **Map compatibility gaps**: database/GI versions, RAC/client support, Data Guard topology, backup destination, TDE/key store, licensing, support model, IaC support, provider billing, and operations handoff.
-5. **Produce a go/no-go decision with capacity, risk, rollback, validation, and open questions separated from facts.**
-
-## Role-Specific Stress Checks
-
-- Do not confuse Exadata infrastructure, VM cluster, DB home, CDB, PDB, and backup resources. They have different owners, APIs, risks, and rollback options.
-- Do not say "Exadata in AWS/Azure/GCP" without naming the Oracle Database@provider service, region, control plane, and network integration.
-- Challenge any consolidation plan that ignores CPU, memory, storage, IOPS, interconnect, IORM, licensing, patch cadence, maintenance windows, and noisy-neighbor isolation.
-- Reject changes to VM clusters, DB homes, Data Guard, IORM, storage, or listener/network settings without live evidence, rollback, and owner approval.
-- Treat Cloud@Customer as cloud-managed but physically customer-site-dependent; site readiness and OCI control-plane reachability are not optional details.
-
-## Output Template
-
-```markdown
-# OCI Database Architecture Review: <scope>
-
-## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest risk:
-- Evidence level: live evidence / documentation-based / sanitized evidence / inference
-
-## Deployment model
-- Source:
-- Destination:
-- Provider/region:
-- Control plane:
-- Data residency:
-
-## Scope
-- Compartment or provider boundary:
-- Resource(s):
-- Workload:
-- Owner:
-- Requested action:
-
-## Compatibility findings
-| Area | Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|---|
+## References
 
-## Deployment-option decision
-| Option | Fit | Blocking gaps | Operational impact |
-|---|---|---|---|
+Load these only when needed:
 
-## Safe next actions
-1.
-2.
-3.
+- [OCI Exadata Platform Architect Operations](references/exadata-platform-operations.md) — use for current service behavior, common failure modes, hard design rules, verification targets, and push-back conditions.
+- [Safety checklist](references/safety-checklist.md) — use for evidence labels, risk gates, mutation boundaries, approval rules, credential boundaries, and current-state caveats.
+- [MCP and evidence path](references/mcp-and-evidence.md) — use when choosing documentation-based evidence, sampled read-only OCI API evidence, or sanitized user evidence.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Oracle documentation list or source notes.
 
-## Open questions
--
-```
+## Response minimum
 
-## Red Flags
+Return, at minimum:
 
-- The design says "lift to Exadata" but has no workload profile, AWR evidence, capacity model, or licensing model.
-- The plan ignores client connectivity from AWS, Azure, Google Cloud, on-premises, or OCI workloads.
-- The plan assumes Cloud@Customer, OCI Dedicated Infrastructure, and Oracle Database@provider offers have identical maintenance and networking behavior.
-- The request wants delete, add storage, node add/remove, IORM change, switchover, failover, or patching without a maintenance window and rollback plan.
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/oci/oci-exadata-platform-architect/metadata.json

@@ -11,15 +11,17 @@
     "kiro",
     "other"
   ],
-  "summary": "OCI Design and operate Exadata Database Service across OCI Dedicated Infrastructure, Exadata Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, and Oracle Database@AWS. Use for Exadata architecture, VM clusters, cloud E...",
+  "summary": "Design and review OCI Exadata Database Service platforms, VM clusters, Exascale, Cloud@Customer, multicloud database placements, capacity, network, backup, patching, and DR without overstating readiness.",
   "source_type": "adapted",
   "official_docs": [
-    "https://docs.oracle.com/en-us/iaas/Content/home.htm",
-    "https://www.oracle.com/cloud/"
+    "https://docs.oracle.com/iaas/exadatacloud/exacs/exadata-cloud-service-overview.html",
+    "https://docs.oracle.com/en-us/iaas/exadatacloud/doc/exacs-tech-arch.html",
+    "https://docs.oracle.com/en-us/iaas/exadb-xs/index.html",
+    "https://docs.oracle.com/en/engineered-systems/exadata-cloud-service/ecscm/exadata-database-service-dedicated-infrastructure-administrators-guide.pdf"
   ],
-  "security_notes": "OCI skills may inspect or mutate cloud resources. Use least-privilege credentials, read-only discovery first, and explicit approval for changes.",
-  "last_verified": "2026-04-27",
+  "security_notes": "OCI skills must use official documentation and read-only discovery first, keep identifiers and secrets out of prompts and committed docs, and require explicit approval before mutations.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-exadata-platform-architect",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-exadata-platform-architect/references/exadata-platform-operations.md

@@ -0,0 +1,64 @@
+# OCI Exadata Platform Architect Operations
+
+> Version note: OCI service behavior and tooling change over time. Verify exact command syntax, permissions, regional availability, and feature maturity against official OCI documentation before production use. Do not paste secrets or sensitive identifiers into commands, files, or chat.
+
+Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.
+
+## What people get wrong
+
+- Designing the VM cluster first and discovering quota, network, backup, or maintenance constraints later.
+- Treating Exascale, Dedicated Infrastructure, Cloud@Customer, and multicloud database services as interchangeable.
+- Assuming Data Guard configured means failover, application routing, and restore validation are proven.
+- Using documentation to claim customer entitlement, available capacity, or production readiness.
+
+## Officially grounded service shape
+
+- Official OCI documentation separates Exadata Database Service on Dedicated Infrastructure from Exadata Database Service on Exascale Infrastructure; do not collapse their capacity and operational models.
+- Official OCI documentation describes dedicated infrastructure as Exadata racks in OCI with one or more VM clusters and control through Console, CLI, and REST APIs.
+- OCI API evidence through the user’s configured read-only OCI MCP shows cloud Exadata infrastructure listing is compartment-scoped and exposes lifecycle-state, display-name, cluster-placement, sorting, and pagination filters. Treat that as API-shape evidence, not capacity proof.
+
+Documentation evidence proves documented OCI service behavior. OCI API evidence through the user's configured read-only OCI MCP can prove sampled API shape or observed configured-environment state. Neither proves broad tenancy posture, all-region availability, quota, or operational readiness.
+
+## Non-negotiable design rules
+
+- Separate infrastructure, VM cluster, database, backup, key management, network, and DR decisions.
+- Verify licensing, support model, maintenance ownership, and database version support before design sign-off.
+- Require connectivity, DNS, route, security-list, key, backup, and restore evidence before production readiness claims.
+- Label Exadata capacity and quota statements as unverified unless backed by current configured-environment evidence.
+
+## Minimal safe implementation flow
+
+- Confirm target platform: Dedicated Infrastructure, Exascale, Cloud@Customer, or multicloud database service.
+- Map databases, VM clusters, network paths, keys, backups, patch windows, RAC/Data Guard topology, and operational owners.
+- Use official docs for service behavior and sampled read-only evidence for API shape or current inventory.
+- Return platform decision, blockers, risk trade-offs, validation checks, and rollback/DR proof required.
+
+## High-risk assumptions to kill
+
+- “Dedicated and Exascale have the same operational constraints.”
+- “Available docs mean capacity is available in the target environment.”
+- “A standby database proves the DR runbook works.”
+- “Oracle-managed infrastructure removes customer patching and database responsibilities.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- List cloud Exadata infrastructure and VM cluster inventory without exposing identifiers.
+- Check lifecycle states, maintenance windows, shape/capacity evidence, and backup/DR configuration.
+- Validate network paths, DNS, security controls, key management, and restore/failover test evidence.
+- Confirm official service limits and support requirements before deployment or migration.
+
+## Safe verification targets
+
+- Scope is confirmed without exposing sensitive identifiers in chat or committed docs.
+- Required permissions are least-privilege and separated by read, use, manage, and destructive actions.
+- Current-state findings are labeled as sampled evidence, not broad proof.
+- Risky mutations have explicit approval, blast-radius review, rollback, and validation.
+- Official-source claims are linked to service docs and not overstated as live posture.
+
+## When to push back
+
+- The user asks for a target shape or migration cutover without capacity, network, backup, and DR evidence.
+- The plan mixes Exascale, Dedicated Infrastructure, Cloud@Customer, or multicloud assumptions.
+- The requested action would scale, patch, terminate, restore, or fail over production without explicit approval.

package/skills/oci/oci-exadata-platform-architect/references/mcp-and-evidence.md

@@ -0,0 +1,30 @@
+# MCP and evidence path
+
+Use this reference to choose the right evidence path without leaking environment details.
+
+## Evidence order
+
+1. Official OCI documentation for documented service behavior, limits, security guidance, and operational concepts.
+2. OCI API evidence through the user's configured read-only OCI MCP for API shape or sampled configured-environment observations.
+3. Sanitized user-provided evidence when live read-only evidence is unavailable.
+4. Explicit inference only when evidence is incomplete.
+
+## What each evidence type proves
+
+- Official documentation proves documented OCI behavior at the time checked.
+- Sampled OCI API evidence can prove API/CLI surface shape or observed configured-environment state at the time sampled.
+- User-provided evidence proves only what was provided and only if sanitized.
+- Inference is not proof; label it and keep recommendations conditional.
+
+## What evidence does not prove
+
+- Documentation does not prove the user's tenancy, compartments, IAM policies, limits, resources, billing state, security posture, or production readiness.
+- Sampled API evidence does not prove all regions, all compartments, all resources, future posture, or full operational readiness.
+- Command help proves command/API surface shape; it does not prove permission, resource existence, or safe execution.
+
+## Safe phrasing
+
+- “Official OCI documentation says...”
+- “OCI API evidence through the user's configured read-only OCI MCP shows...”
+- “The current state was not queried, so this remains an assumption.”
+- “This recommendation is documentation-based and needs environment validation before production change.”

package/skills/oci/oci-exadata-platform-architect/references/official-sources.md

@@ -0,0 +1,22 @@
+# Official sources
+
+Use these sources to ground service behavior before making production recommendations.
+
+## Oracle documentation checked on 2026-06-05
+
+- https://docs.oracle.com/iaas/exadatacloud/exacs/exadata-cloud-service-overview.html
+- https://docs.oracle.com/en-us/iaas/exadatacloud/doc/exacs-tech-arch.html
+- https://docs.oracle.com/en-us/iaas/exadb-xs/index.html
+- https://docs.oracle.com/en/engineered-systems/exadata-cloud-service/ecscm/exadata-database-service-dedicated-infrastructure-administrators-guide.pdf
+
+## Sampled read-only OCI API evidence checked on 2026-06-05
+
+- OCI API evidence through the user's configured read-only OCI MCP was used for command/API surface shape only.
+- Command-help evidence confirms available list/filter surfaces; it does not prove permissions, resource existence, regional availability, capacity, quota, data correctness, or production readiness.
+
+## Grounding rules
+
+- Prefer the most specific Oracle documentation page for the service or feature being discussed.
+- If documentation and sampled API evidence appear to conflict, report the conflict and avoid stronger claims until resolved.
+- Do not cite internal tool names, local environment labels, connector identifiers, or environment-specific details in committed docs.
+- Do not paste sensitive identifiers or customer data into examples.

package/skills/oci/oci-exadata-platform-architect/references/safety-checklist.md

@@ -1,32 +1,35 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-exadata-platform-architect`.
+Use this checklist before producing guidance, requesting evidence, or proposing changes.
 
-## Scope
+## Evidence labels
 
-- Deployment model confirmed: OCI, Cloud@Customer, Oracle Database@Azure, Oracle Database@Google Cloud, Oracle Database@AWS, or unknown.
-- Region/provider location confirmed.
-- Compartment or provider boundary confirmed.
-- Resource identity confirmed by name and, when available, live evidence.
-- Owner, business impact, data classification, and environment confirmed.
+- `documentation-based`: grounded in official OCI documentation only.
+- `sampled-api-shape`: grounded in read-only command/API help or metadata evidence.
+- `sampled-current-state`: grounded in read-only observations from the configured environment.
+- `user-supplied`: grounded in sanitized user evidence.
+- `inference`: reasoned from incomplete evidence; never present it as fact.
 
-## Access
+## Credential and identifier boundaries
 
-- Default profile unless user explicitly chooses another profile/config in the active runtime.
-- Least-privilege action only.
-- No broad grants unless risk-accepted by an owner.
-- No secrets, wallets, credentials, tokens, connection strings, or config contents requested or displayed.
+- Do not ask for credentials, tokens, private keys, API keys, config files, wallets, kubeconfigs, connection strings, customer data, or sensitive identifiers.
+- Do not commit environment-specific identifiers, internal tool names, local environment labels, connector IDs, or private endpoint details.
+- If the task requires live context, ask for a sanitized export or use approved read-only evidence paths.
 
-## Change safety
+## Mutation boundary
 
-- Read-only discovery first.
-- Explicit approval for write, delete, start, stop, update, patch, failover, switchover, restore, wallet, key, SQL, command execution, network, or remediation actions.
-- Rollback path documented.
-- Validation plan includes positive checks, negative checks, and application-owner signoff.
+Require explicit approval before creating, updating, deleting, moving, scaling, rotating, patching, enabling, disabling, refreshing, restoring, cutting over, or changing access.
 
-## Platform portability
+## Approval gates
 
-- Prefer MCP tool calls.
-- Use neutral `<placeholders>` in examples.
-- Do not assume Bash, PowerShell, cmd.exe, macOS, Windows, or Linux until execution context is known.
-- Do not embed machine-local paths.
+- Confirm scope, owner, environment criticality, maintenance window, rollback plan, and validation target.
+- Separate read-only discovery from write actions.
+- Prefer least privilege and reversible changes.
+- Stop if evidence conflicts or if the blast radius is unknown.
+
+## Final-answer minimum
+
+- State evidence level and scope.
+- List blockers and unsafe assumptions.
+- Give safe next actions before risky actions.
+- Name what was not proved.

package/skills/oci/oci-exadata-platform-architect/references/workflow-and-output.md

@@ -0,0 +1,26 @@
+# Workflow and output contract
+
+Use this workflow for full reviews and incident-style triage.
+
+## Execution flow
+
+1. Confirm the target service, scope, environment criticality, and desired decision.
+2. Load official source guidance and this skill's operations reference.
+3. Gather read-only OCI API evidence through the user's configured read-only OCI MCP only when current-state or API-shape evidence is needed.
+4. Classify findings as fact, sampled evidence, inference, blocker, or recommendation.
+5. Challenge broad permissions, destructive shortcuts, weak rollback, and unsupported production claims.
+6. Return concise findings with safe next actions and explicit unknowns.
+
+## Output contract
+
+Return these fields when the user asks for a review, guardrail, or production-readiness answer:
+
+- `verdict`: pass, pass-with-risk, blocked, or needs-evidence.
+- `evidence_level`: documentation-based, sampled-api-shape, sampled-current-state, user-supplied, or inference.
+- `blockers`: missing proof, unsafe assumptions, or approval gaps.
+- `safe_next_actions`: least-risk steps the user can take next.
+- `open_questions`: only questions that materially change the decision.
+
+## Tone
+
+Be blunt. Do not validate a weak plan. If the evidence is thin, say so and narrow the recommendation.