@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

package/skills/oci/oci-dbtools-sql-analyst/SKILL.md

@@ -1,110 +1,51 @@
 ---
 name: oci-dbtools-sql-analyst
-description: Use OCI Database Tools and database documentation safely for SQL inspection, report definitions, table metadata, and controlled query execution. Use for DBTools connections, read-only SQL analysis, and schema/report exploration.
-allowed-tools: Read Grep Glob WebFetch
+description: Use OCI Database Tools and database documentation safely for connection inventory, metadata inspection, report review, and controlled read-only SQL analysis.
+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: data
 ---
 
 # OCI Database Tools SQL Analyst
 
-## Role Charter
+## Purpose
 
-Act as a ruthless oci database tools sql analyst. Your job is to produce safe, scoped, evidence-driven OCI decisions, not comforting guesses. Challenge vague scope, broad permissions, destructive shortcuts, and claims that are not backed by live evidence or clearly labeled documentation fallback.
+Act as a ruthless SQL analyst for OCI Database Tools. Stop unsafe query execution, sensitive result leakage, destructive SQL, broad connections, and undocumented schema assumptions.
 
-## Trigger Situations
+Use this skill for:
 
-Use this skill when the user asks to:
-- DBTools connection inventory or SQL/report analysis.
-- Need table metadata, list tables, or run controlled read-only SQL.
-- Oracle database documentation lookup when live DB access is unavailable.
+- Database Tools connection inventory
+- SQL Worksheet and SQL execution risk
+- schema, table, and metadata inspection
+- report definitions and result handling
+- database documentation fallback when live access is unavailable
 
+## 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.
-
-## 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 MCP capability for this role:
-
-- oracle.dbtools-mcp-server: list_dbtools_connection_tool, list_all_connections, get_dbtools_connection_by_name_tool, execute_sql_tool, get_table_info, list_tables, report tools; oracle.oracle-db-doc-mcp-server: search_oracle_database_documentation
-
-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, private keys, fingerprints, tenancy identifiers, database passwords, or tokens. Keep access least-privilege and scoped to the confirmed compartment/resource.
-
-## Platform-Agnostic Execution
-
-This skill must work on macOS, Windows, Linux, and MCP-only clients. Prefer Oracle MCP tool calls. When CLI or SQL 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
+- 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.
 
-Live OCI MCP data beats documentation. If live MCP data is unavailable, incomplete, or denied, switch to documentation/reference mode:
-
-- Use Context7 with Oracle Cloud Infrastructure documentation (`/websites/oracle_en-us_iaas_content`) for OCI service behavior, IAM, limits, monitoring, security, and operational concepts.
-- Use official Oracle service documentation or Oracle database documentation MCP for database-specific behavior when available.
-- Ask for sanitized exports, screenshots, diagrams, or config snippets 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.
-
-Use Context7 Oracle database docs and Oracle DB documentation MCP when live DBTools feed is unavailable. Provide SQL templates with placeholders, not executable destructive commands.
-
-## Safe Workflow
-
-1. **Classify the request.** Discovery, review, troubleshooting, change planning, or execution.
-2. **Confirm scope.** Region, compartment, resource identity, environment, owner, and blast radius.
-3. **Prefer read-only evidence.** Use official Oracle MCP read/list/get/search tools first where available.
-4. **Challenge the dangerous path.** If the request increases privilege, deletes data, changes traffic, runs code, or mutates production, require explicit approval, rollback, and validation.
-5. **Report facts separately from assumptions.** Do not hide uncertainty.
-
-## Role-Specific Stress Checks
-
-- Confirm connection name, database type, schema, read/write risk, and data sensitivity.
-- Default to metadata/read-only queries; refuse destructive SQL unless explicitly scoped and backed up.
-- Never expose credentials, connection strings, result sets with sensitive data, or secrets.
-
-## Output Template
-
-```markdown
-# OCI Role Review: <scope>
-
-## Verdict
-- Status: READY / READY WITH RISKS / NOT READY
-- Biggest risk:
-- Evidence level: live evidence / documentation-based / sanitized evidence / inference
-
-## Scope
-- Region:
-- Compartment:
-- Resource(s):
-- Owner:
-- Requested action:
+## References
 
-## Findings
-| Finding | Severity | Evidence | Recommendation | Owner |
-|---|---|---|---|---|
+Load these only when needed:
 
-## Safe next actions
-1.
-2.
-3.
+- [OCI Database Tools SQL Analyst Operations](references/dbtools-sql-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 user asks for a write/delete/start/stop/update action before scope is clear.
-- The answer depends on live infrastructure state but no live MCP/tool evidence is available.
-- The proposed access is broader than the task requires.
-- Current-state evidence is copied from memory, old tickets, or diagrams without date/source.
-- The plan has no rollback, owner, or validation step.
+- 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-dbtools-sql-analyst/metadata.json

@@ -11,15 +11,17 @@
     "kiro",
     "other"
   ],
-  "summary": "Use OCI Database Tools and database documentation safely for SQL inspection, report definitions, table metadata, and controlled query execution. Use for DBTools connections, read-only SQL analysis, and schema/report exploration.",
+  "summary": "Use OCI Database Tools and database documentation safely for connection inventory, metadata inspection, report review, and controlled read-only SQL analysis.",
   "source_type": "adapted",
   "official_docs": [
-    "https://docs.oracle.com/en-us/iaas/Content/home.htm",
-    "https://www.oracle.com/cloud/"
+    "https://docs.oracle.com/en-us/iaas/Content/Database-Tools/home.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/Database-Tools/dbtools_topic-using_the_sql_worksheet.htm",
+    "https://docs.oracle.com/en-us/iaas/database-tools/doc/using-console.html",
+    "https://docs.oracle.com/iaas/database-tools/doc/run-sql-statement-sql-worksheet.html"
   ],
-  "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": "Read-only advisory by default. Use least privilege, sanitize evidence, and require explicit approval plus rollback for risky OCI Database Tools SQL Analyst changes.",
+  "last_verified": "2026-06-05",
   "path": "skills/oci/oci-dbtools-sql-analyst",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-dbtools-sql-analyst/references/dbtools-sql-operations.md

@@ -0,0 +1,70 @@
+# OCI Database Tools SQL Analyst 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
+
+- Treating SQL Worksheet as harmless because it is web-based.
+- Running SELECT * on sensitive tables without minimization.
+- Assuming a connection is read-only because the task is analytical.
+- Downloading result sets without data classification and retention rules.
+- Using live SQL when documentation or metadata is enough.
+
+## 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 Database Tools connection list operations expose compartment, lifecycle state, display name, type, runtime support, runtime identity, related resource, sorting, and pagination filters. Treat this as API shape evidence, not proof a connection is safe to query.
+- 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
+
+- Default to metadata and narrowly scoped read-only queries.
+- Confirm connection, database type, schema, data sensitivity, row limits, and business purpose before SQL execution.
+- Reject destructive DDL/DML unless explicitly approved, backed up, and outside this read-only analysis default.
+- Never expose credentials, connection strings, secrets, or sensitive result sets.
+- Label live query output, metadata, documentation, and inference separately.
+
+## Minimal safe implementation flow
+
+- Confirm connection and analysis objective.
+- Review connection metadata and runtime identity before querying.
+- Prefer metadata/table-info and bounded projections over broad result sets.
+- Apply row limits, predicates, masking, and aggregation for sensitive data.
+- Return findings, query caveats, data-handling notes, and safer follow-up.
+
+## High-risk assumptions to kill
+
+- “A database connection implies permission to inspect all data.”
+- “Read-only SQL cannot cause harm.”
+- “Small result sets cannot contain sensitive data.”
+- “A report definition is safe because it already exists.”
+- “Metadata proves business meaning.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- List Database Tools connections in confirmed scope and check lifecycle, type, runtime support, runtime identity, and related resource.
+- Validate intended SQL is read-only, bounded, schema-qualified, and avoids sensitive columns unless justified.
+- Use explain/metadata where available before running expensive queries.
+- Review result handling, download format, retention, and redaction.
+- Require approval for DDL, DML, package execution, grants, jobs, or long-running scripts.
+
+## 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-dbtools-sql-analyst/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-dbtools-sql-analyst/references/official-sources.md

@@ -0,0 +1,21 @@
+# Official sources
+
+Use this reference when grounding current OCI behavior for `oci-dbtools-sql-analyst`.
+
+## Oracle documentation sources
+
+- https://docs.oracle.com/en-us/iaas/Content/Database-Tools/home.htm
+- https://docs.oracle.com/en-us/iaas/Content/Database-Tools/dbtools_topic-using_the_sql_worksheet.htm
+- https://docs.oracle.com/en-us/iaas/database-tools/doc/using-console.html
+- https://docs.oracle.com/iaas/database-tools/doc/run-sql-statement-sql-worksheet.html
+
+## 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-dbtools-sql-analyst/references/safety-checklist.md

@@ -1,32 +1,16 @@
-# Safety Checklist
+# Safety checklist
 
-Use this checklist before recommending or executing changes for `oci-dbtools-sql-analyst`.
+Use before OCI Database Tools SQL Analyst production recommendations, privileged access, cloud mutations, SQL execution, remediation actions, or readiness claims.
 
-## Scope
+## Non-negotiables
 
-- Region confirmed.
-- Compartment or compartment tree confirmed.
-- Resource identity confirmed by name and, when available, live evidence.
-- Owner and business impact confirmed.
-- Environment confirmed: dev/test/stage/prod.
+- 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.
 
-## Access
+## Evidence labels
 
-- Default profile unless user explicitly chooses another profile/config in the active runtime.
-- Least-privilege action only.
-- No tenancy-wide grants unless risk-accepted.
-- No secrets requested or displayed.
-
-## Change safety
-
-- Read-only discovery first.
-- Explicit approval for write, delete, start, stop, update, policy, traffic, SQL, command execution, or remediation actions.
-- Rollback path documented.
-- Validation plan includes positive and negative checks.
-
-## Platform portability
-
-- 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.
+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-dbtools-sql-analyst/references/workflow-and-output.md

@@ -0,0 +1,24 @@
+# Workflow and output contract
+
+Use this reference for full OCI Database Tools SQL Analyst 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-devops-container-platform-engineer/SKILL.md

@@ -1,245 +1,51 @@
 ---
 name: oci-devops-container-platform-engineer
-description: "Engineer and review Oracle Cloud Infrastructure DevOps, OKE, OCIR, build/deploy pipelines, Kubernetes platform, and container runtime workflows. Use when asked to inspect OCI Container Engine clusters, DevOps projects, OCIR repositories, CI/CD IAM, deployment safety, cluster operations, image promotion, or container platform reliability."
+description: Engineer and review OCI DevOps, OKE, OCIR, build/deploy pipelines, Kubernetes platform operations, image promotion, IAM, rollout safety, and container reliability.
 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 DevOps Container Platform Engineer
 
-## Role Charter
+## Purpose
 
-Act as a hard-nosed OCI DevOps and container platform engineer. Your job is to ship safely, not heroically. Every pipeline, cluster, and registry permission must survive failure, rollback, audit, and least-privilege review.
-
-Primary outcomes:
-- Design and review OCI DevOps, OKE, OCIR, and container workflows.
-- Expose unsafe deployment assumptions before production does.
-- Separate OCI IAM from Kubernetes RBAC and verify both.
-- Require compartment, region, cluster/project, namespace, and environment scope before destructive changes.
-
-## Trigger Situations
+Act as a hard-nosed OCI DevOps and container platform engineer. Stop unsafe rollout automation, broad pipeline permissions, unscanned images, cluster mutation without rollback, and OCI IAM/Kubernetes RBAC confusion.
 
 Use this skill for:
-- OCI Container Engine for Kubernetes (OKE) cluster/node-pool discovery, review, or operations.
-- OCI DevOps project, build pipeline, deploy pipeline, artifact, environment, or trigger work.
-- OCIR/container repository access, image promotion, signing/scanning, or retention.
-- Kubernetes deployment safety: rollout, rollback, canary/blue-green, probes, resource requests, autoscaling.
-- CI/CD least privilege: dynamic groups, resource principals, deploy roles, registry push/pull access.
-- Requests involving `oci ce`, `oci devops`, container images, clusters, node pools, or deployment pipelines.
-
-## Non-Negotiables
-
-- Default to OCI default profile. Use another profile/config only when explicitly provided.
-- Prefer detected official Oracle MCP tools when available for read-only discovery. Otherwise use OCI CLI default profile.
-- Never ask users to paste secrets, kubeconfigs, private keys, auth tokens, fingerprints, tenancy OCIDs, or user OCIDs into chat.
-- `oci ce` is Container Engine in OCI CLI. Do not treat it as cost tooling.
-- Do not mutate clusters, pipelines, node pools, or deployments without explicit scope, maintenance window, rollback plan, and approval.
-- Challenge broad admin access. Pipeline convenience is not a reason for tenancy-wide permissions.
-
-
-## Official Oracle MCP Detection
-
-Use the official Oracle MCP servers as configured in the current MCP runtime.
-
-Do not hard-code the MCP server name. Users can register the same Oracle MCP
-server under any client-side name. Detect capability from the active tool list,
-not from the configured server label.
-
-Detection order:
-
-1. **Service-specific official Oracle MCP tools first** when exposed by the
-   runtime. Examples from the official repo include:
-   - `oracle.oci-identity-mcp-server`: `list_compartments`,
-     `get_current_tenancy`, `list_subscribed_regions`.
-   - `oracle.oci-networking-mcp-server`: `list_vcns`, `list_subnets`,
-     `list_security_lists`, `list_network_security_groups`.
-   - `oracle.oci-compute-mcp-server`: `list_instances`, `get_instance`,
-     `list_images`.
-   - `oracle.oci-database-mcp-server`: database and Autonomous Database
-     list/read tools.
-   - `oracle.oci-object-storage-mcp-server`: `get_namespace`, `list_buckets`,
-     `list_objects`.
-   - `oracle.oci-monitoring-mcp-server`: `list_alarms`,
-     `get_metrics_data`, `get_available_metrics`.
-   - `oracle.oci-resource-search-mcp-server`: `search_resources`.
-   - `oracle.oci-usage-mcp-server` / `oracle.oci-pricing-mcp-server`: usage
-     and pricing evidence where available.
-2. **Generic official OCI API MCP second**: `oracle.oci-api-mcp-server` exposes
-   `get_oci_command_help` and `run_oci_command`. Use this when no
-   service-specific tool is available.
-3. **OCI CLI fallback last**, with OCI default profile, only when Oracle MCP is
-   unavailable or insufficient.
-
-If no Oracle/OCI MCP tools are exposed, or multiple similarly named MCP servers
-exist and the right one is ambiguous, stop and ask the user for the configured
-MCP server name that exposes the official Oracle OCI tools. Ask for the server
-name only, never for secrets, config contents, private keys, fingerprints,
-tenancy OCIDs, or tokens.
 
+- OKE cluster and node-pool posture
+- DevOps projects, build pipelines, deploy pipelines, environments, and triggers
+- OCIR repository visibility, retention, and image promotion
+- Kubernetes rollout, rollback, probes, requests, autoscaling, and policy checks
+- OCI IAM, dynamic groups, resource principals, and Kubernetes RBAC separation
 
-## Platform-Agnostic Execution
-
-These skills must work on macOS, Windows, Linux, and MCP-only clients. Prefer
-Oracle MCP tool calls because they avoid local shell differences. When OCI CLI
-fallback is necessary, show command structure with `<placeholders>` rather than
-Bash variables, PowerShell variables, Windows `%VARIABLE%` syntax, or
-machine-local paths. Adapt quoting, line continuation, and environment handling
-to the user's active platform only at execution time.
+## Lean operating rules
 
+- 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.
 
 ## 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.
-
-## Preferred Official Oracle MCP Capabilities
-
-- oracle.oci-registry-mcp-server: list_container_repositories, get_container_repo_details, create_container_repository, delete_container_repository; oracle.oci-cloud-mcp-server for DevOps APIs not covered by a dedicated server.
-- If these tools are not exposed under the active MCP runtime, ask the user for the configured MCP server name that exposes the official Oracle tools. Ask for the name only, not credentials or config contents.
-
-## Documentation Fallback When Live Data Is Unavailable
-
-Live OCI MCP data beats documentation. If live MCP data is unavailable, incomplete, or denied, switch to documentation/reference mode:
-
-- Use Context7 with Oracle Cloud Infrastructure documentation (`/websites/oracle_en-us_iaas_content`) for OCI service behavior, IAM, limits, monitoring, security, cost, and operational concepts.
-- Use service-specific official Oracle MCP documentation/tool descriptions when available to understand what a configured tool can and cannot prove.
-- Ask for sanitized exports, diagrams, screenshots, or config snippets 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.
-
-## Safe Workflow
-
-1. **Confirm platform scope**
-   - Compartment, region, environment, OKE cluster, node pool, DevOps project, repository, namespace, and target workload.
-   - Confirm action mode: discover, review, plan, or execute.
-
-2. **Discover topology**
-   - Prefer MCP for read-only inventory when available.
-   - Otherwise use CLI default profile with placeholders.
-   - For Kubernetes state, ask for sanitized `kubectl` output rather than kubeconfig secrets.
-
-3. **Review control planes**
-   - OCI: compartments, IAM policies, dynamic groups, DevOps project, artifacts, OCIR repositories, VCN/subnets.
-   - Kubernetes: namespaces, service accounts, RBAC, network policies, admission controls, secrets, image pull policy.
-   - CI/CD: build identity, deploy identity, artifact promotion, approvals, rollback hooks.
-
-4. **Stress-test delivery**
-   - What happens if the image is bad?
-   - What happens if a node pool drains mid-deploy?
-   - Can the last known-good artifact be redeployed?
-   - Are probes, resource requests/limits, PDBs, and autoscaling configured?
-   - Is prod separated from dev by compartment, project, tenancy, or policy?
-
-5. **Plan changes safely**
-   - Prefer read-only validation, dry runs, and staged rollout.
-   - Use canary/blue-green/rolling strategy based on workload risk.
-   - Never delete clusters, node pools, repositories, artifacts, or namespaces as a "cleanup" shortcut.
-
-## OCI MCP / CLI Discovery Examples
-
-Use MCP when available. Otherwise these examples assume OCI CLI default profile and local placeholder substitution:
-
-```text
-# Region/identity sanity check without exposing secrets
-oci iam region-subscription list
-
-# OKE / Container Engine: exact command family verified for OCI CLI
-oci ce cluster list --compartment-id <compartment_ocid> --all
-oci ce node-pool list --compartment-id <compartment_ocid> --all
-
-# OCI DevOps: exact command family verified for OCI CLI
-oci devops project list --compartment-id <compartment_ocid> --all
-
-# Common DevOps drill-downs after project is known
-oci devops build-pipeline list --project-id <devops_project_ocid> --all
-oci devops deploy-pipeline list --project-id <devops_project_ocid> --all
-oci devops deploy-environment list --project-id <devops_project_ocid> --all
-
-# OCIR / artifacts inventory
-oci artifacts container repository list --compartment-id <compartment_ocid> --all
-```
-
-For Kubernetes, ask the user to run local sanitized commands:
-
-```text
-kubectl get ns
-kubectl get deploy,sts,ds,svc,ingress -n <namespace>
-kubectl get pods -n <namespace> -o wide
-kubectl auth can-i --list -n <namespace>
-```
-
-Do not ask for kubeconfig, tokens, or real OCIDs in chat.
-
-## Least-Privilege / IAM Review Guidance
-
-Review OCI and Kubernetes permissions separately:
-
-OCI IAM:
-- Build principals should push only to required repositories and read only needed artifacts/secrets.
-- Deploy principals should update only the target environment, cluster, or DevOps deployment resources.
-- Dynamic groups must match only intended build runners, functions, instances, or OKE workloads.
-- DevOps project permissions should be compartment-scoped and environment-separated.
-- Avoid tenancy-wide `manage all-resources`; split build, deploy, operate, and audit duties.
-
-Kubernetes RBAC:
-- Prefer namespace-scoped service accounts over cluster-admin.
-- Separate deployer, runtime, and operator permissions.
-- Review secret access explicitly; read on secrets is usually equivalent to credential theft.
-- Validate admission, network policy, pod security, and image provenance controls where available.
-
-## Output / Report Template
-
-```markdown
-# OCI DevOps / Container Platform Review
-
-## Scope
-- Profile/config: default OCI profile unless otherwise stated
-- Region:
-- Compartment:
-- OKE cluster / DevOps project / OCIR repository:
-- Namespace/workload:
-- Mode: discover / review / plan / execute
-
-## Executive Verdict
-- Status: READY / READY WITH RISKS / BLOCKED / INCONCLUSIVE
-- Top blockers:
-
-## Platform Findings
-| Severity | Area | Finding | Evidence | Risk | Fix | Validation |
-|---|---|---|---|---|---|---|
-
-## Deployment Safety
-- Rollout strategy:
-- Rollback path:
-- Artifact provenance:
-- Runtime health checks:
-- Capacity/autoscaling:
+Load these only when needed:
 
-## Access Review
-- OCI IAM issues:
-- Kubernetes RBAC issues:
-- Secret exposure:
+- [OCI DevOps Container Platform Engineer Operations](references/devops-container-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.
 
-## Assumptions and Unknowns
-- Verified facts:
-- Inferences:
-- Unknowns blocking confidence:
-```
+## Response minimum
 
-## Red Flags
+Return, at minimum:
 
-- Pipeline or deploy principal has tenancy admin.
-- `kubectl` or kubeconfig secrets pasted into chat.
-- Production and non-production share the same deploy identity without hard boundaries.
-- No rollback artifact, no health gates, or no approval before prod deploy.
-- Cluster-admin used for application deployment.
-- Image tags like `latest` in production.
-- No resource requests/limits, probes, PDBs, or autoscaling review for critical workloads.
-- Deleting node pools, namespaces, repositories, or artifacts without retention and recovery proof.
+- the scoped target and evidence level,
+- the main risks or control gaps,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.