@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

package/skills/oci/oci-live-resource-manager-stack-guard/metadata.json

@@ -11,17 +11,17 @@
     "kiro",
     "other"
   ],
-  "summary": "Guard OCI Resource Manager stack plan, apply, and destroy jobs with drift detection, state-version rollback, stack auto-lock awareness, and approval gates.",
+  "summary": "Guard OCI Resource Manager stack plan, apply, destroy, import-state, drift, and state-version decisions with plan review, state-lock awareness, approval, rollback, and blast-radius evidence.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.oracle.com/en-us/iaas/Content/ResourceManager/Concepts/resourcemanager.htm",
-    "https://docs.oracle.com/en-us/iaas/Content/ResourceManager/Tasks/detect-drift.htm",
-    "https://docs.oracle.com/en-us/iaas/Content/ResourceManager/Tasks/create-job-lock-file.htm",
-    "https://docs.oracle.com/en-us/iaas/Content/ResourceManager/home.htm"
+    "https://docs.oracle.com/iaas/Content/ResourceManager/Concepts/resourcemanager.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/ResourceManager/Concepts/resource-manager-and-terraform.htm",
+    "https://docs.oracle.com/iaas/Content/ResourceManager/Tasks/detect-drift.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/ResourceManager/Tasks/list-drift.htm"
   ],
-  "security_notes": "OCI Resource Manager auto-locks a stack state during job execution. Never approve an apply or destroy job without a plan-job output review and drift detection evidence. Repo write access does not authorize live OCI infrastructure mutations.",
-  "last_verified": "2026-04-30",
+  "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-live-resource-manager-stack-guard",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-live-resource-manager-stack-guard/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-live-resource-manager-stack-guard/references/official-sources.md

@@ -1,12 +1,22 @@
-# Official Sources: OCI Live Resource Manager Stack Guard
+# Official sources
 
-## OCI Resource Manager
+Use these sources to ground service behavior before making production recommendations or routing decisions.
 
-- https://docs.oracle.com/en-us/iaas/Content/ResourceManager/Concepts/resourcemanager.htm
-- https://docs.oracle.com/en-us/iaas/Content/ResourceManager/Tasks/creatingjobs.htm
-- https://docs.oracle.com/en-us/iaas/Content/ResourceManager/Tasks/managingstacksandjobs.htm
+## Oracle documentation checked on 2026-06-05
 
-## Source-grounding rule
+- https://docs.oracle.com/iaas/Content/ResourceManager/Concepts/resourcemanager.htm
+- https://docs.oracle.com/en-us/iaas/Content/ResourceManager/Concepts/resource-manager-and-terraform.htm
+- https://docs.oracle.com/iaas/Content/ResourceManager/Tasks/detect-drift.htm
+- https://docs.oracle.com/en-us/iaas/Content/ResourceManager/Tasks/list-drift.htm
 
-Use official Oracle Cloud Infrastructure documentation as the source of truth for Resource Manager behavior.
-Terraform version support and job type capabilities must be verified from current OCI docs.
+## 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 where applicable.
+- Command-help evidence confirms available list/filter surfaces; it does not prove permissions, resource existence, regional availability, capacity, quota, data correctness, traffic safety, catalog correctness, or production readiness.
+
+## Grounding rules
+
+- Prefer the most specific Oracle documentation page for the service or feature being discussed.
+- If documentation, catalog, 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-live-resource-manager-stack-guard/references/resource-manager-stack-operations.md

@@ -0,0 +1,66 @@
+# OCI Live Resource Manager Stack Guard Operations
+
+> Version note: OCI service behavior, catalog entries, and tooling change over time. Verify exact command syntax, permissions, regional availability, feature maturity, and catalog targets 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
+
+- Approving apply without reading the plan.
+- Treating drift detection as remediation.
+- Destroying because the stack is wrong without checking retained resources, dependencies, and state.
+- Assuming repo merge approval equals live infrastructure approval.
+
+## Officially grounded service shape
+
+- Official OCI documentation describes Resource Manager as Terraform-backed IaC for OCI resources, with stacks, configuration, state, jobs, and drift detection.
+- Official OCI documentation says Resource Manager locks stack state so only one job can run on a stack at a time.
+- Official OCI documentation describes plan, apply, destroy, and import state jobs; destroy releases resources associated with a stack and can be destructive.
+- OCI API evidence through the user’s configured read-only OCI MCP shows stack listing can filter by compartment, stack, lifecycle state, display name, sorting, and pagination.
+- OCI API evidence through the user’s configured read-only OCI MCP shows job listing can filter by compartment, stack, job, lifecycle state, display name, sorting, and pagination.
+
+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 plan, apply, destroy, import-state, drift, state, and provider-version evidence.
+- Require explicit approval before apply, destroy, import state, or rollback state.
+- Block if the plan includes destructive replacement, IAM/network/security changes, secret exposure, or unknown values without owner review.
+- Do not expose Terraform variables, state secrets, private endpoints, customer data, or sensitive identifiers.
+
+## Minimal safe implementation flow
+
+- Confirm stack, job type, environment, owner, plan source, drift status, and desired decision.
+- Use official docs for Resource Manager/Terraform behavior and sampled read-only evidence for API shape/current job state.
+- Review plan actions, drift, state, locks, variables, provider versions, and rollback path.
+- Return verdict, blockers, approval state, safe next actions, and post-job validation.
+
+## High-risk assumptions to kill
+
+- “Plan succeeded, so apply is safe.”
+- “Drift means apply should run.”
+- “Destroy only affects test resources.”
+- “State rollback restores real infrastructure automatically.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Check stack lifecycle, latest jobs, drift status, and plan output from sanitized evidence.
+- Inspect destructive actions, IAM/network changes, replacements, unknowns, and variables.
+- Confirm state lock, backup/state-version path, and rollback limitations.
+- Validate live resources after apply/destroy and capture job logs.
+
+## 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 or live-guard dispatch 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 to apply or destroy without plan output.
+- Drift was not detected or the drift scope is unknown.
+- The plan includes destructive or security-sensitive changes without explicit approval.

package/skills/oci/oci-live-resource-manager-stack-guard/references/safety-checklist.md

@@ -0,0 +1,35 @@
+# Safety checklist
+
+Use this checklist before producing guidance, requesting evidence, routing a task, or proposing changes.
+
+## Evidence labels
+
+- `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.
+
+## Credential and identifier boundaries
+
+- 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.
+
+## Mutation boundary
+
+Require explicit approval before creating, updating, deleting, moving, scaling, rotating, patching, enabling, disabling, deploying, applying, destroying, promoting, rolling back, deleting keys, changing traffic, changing access, or changing production state.
+
+## Approval gates
+
+- 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-live-resource-manager-stack-guard/references/workflow-and-output.md

@@ -0,0 +1,26 @@
+# Workflow and output contract
+
+Use this workflow for full reviews, routing decisions, and live-guard decisions.
+
+## 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, route, or production-readiness answer:
+
+- `verdict`: pass, pass-with-risk, blocked, needs-evidence, or routed.
+- `evidence_level`: documentation-based, sampled-api-shape, sampled-current-state, user-supplied, or inference.
+- `blockers`: missing proof, unsafe assumptions, approval gaps, or routing 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.

package/skills/oci/oci-live-vault-key-destruction-guard/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: oci-live-vault-key-destruction-guard
-description: Guard Vault master encryption key scheduled-deletion and HSM rotation with data-association audits, key-usage reference checks, deletion-window enforcement, and cancellation playbooks.
-allowed-tools: Read Grep Glob WebFetch
+description: Guard OCI Vault key deletion, cancellation, disablement, rotation, and HSM/software key lifecycle decisions with usage, dependency, waiting-window, backup, and recovery-limit evidence.
+allowed-tools: Read Grep Glob
 metadata:
-  author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  author: github: Raishin
+  version: 0.1.1
+  updated: "2026-06-05"
   category: security
 ---
 
@@ -13,40 +13,39 @@ metadata:
 
 ## Purpose
 
-Act as the guarded live OCI operator for oci-live-vault-key-destruction-guard work. Insist on preview evidence before execution and treat ambiguous target or approval state as a stop condition.
+Act as a blunt OCI guard or router for this domain. Kill unverified readiness claims, broad routing, destructive shortcuts, weak rollback, and source-free operational advice.
 
-## When to use
+Use this skill for:
 
-Use this skill when:
-
-- an OCI Vault master encryption key must be scheduled for deletion or rotated to a new version
-- a key scheduled for deletion must be cancelled before the destruction window expires
-- an HSM-backed key usage must be audited before any key version lifecycle change
+- Vault key scheduled-deletion review
+- scheduled key deletion cancellation review
+- key rotation and key-version lifecycle planning
+- data association and encrypted-resource dependency audit
+- HSM/software/external key protection-mode risk review
 
 ## Lean operating rules
 
-- Prefer OCI CLI (`oci`) official documentation when available; fall back to Oracle Cloud docs and sanitized user evidence.
-- Do not execute a live OCI change until tenancy, compartment, active principal, and resource ownership are explicit.
-- Prefer plan, detect-drift, inspect, read, describe, and rollback evidence before execution.
-- If the request skips preview or rollback design, push back.
-- Never print secrets, API keys, tenancy OCIDs, private key contents, or raw config values. Summarize sanitized evidence only.
-- Load references only when needed.
+- 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, production claims, and live-guard dispatch 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:
 
-- [Preflight commands](references/preflight-commands.md) — OCI CLI commands to run before any mutation.
-- [Rollback playbook](references/rollback-playbook.md) — concrete rollback steps for this service.
-- [Permission model](references/permission-model.md) — OCI IAM policy statements and dynamic group guidance.
-- [Official sources](references/official-sources.md) — authoritative OCI documentation links.
+- [OCI Live Vault Key Destruction Guard Operations](references/vault-key-destruction-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.
 
 ## Response minimum
 
 Return, at minimum:
 
-- confirmed tenancy, compartment, and active principal
-- preflight evidence (plan output, drift result, inspect/read, health check)
-- approval status for the proposed mutation
-- rollback posture or explicit statement of what cannot be rolled back
-- post-action verification steps or refusal reason
+- the scoped target and evidence level,
+- the main risks, control gaps, or routing decision,
+- the safest next actions,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/oci/oci-live-vault-key-destruction-guard/metadata.json

@@ -11,17 +11,17 @@
     "kiro",
     "other"
   ],
-  "summary": "Guard Vault master encryption key scheduled-deletion and HSM rotation with data-association audits, key-usage reference checks, deletion-window enforcement, and cancellation playbooks.",
+  "summary": "Guard OCI Vault key deletion, cancellation, disablement, rotation, and HSM/software key lifecycle decisions with usage, dependency, waiting-window, backup, and recovery-limit evidence.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/deletingkeys.htm",
-    "https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/rotatingkeys.htm",
     "https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Concepts/keyoverview.htm",
-    "https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/managingkeys.htm"
+    "https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/managingkeys_topic-To_delete_a_key.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/managingvaults_topic-To_delete_a_vault.htm",
+    "https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/rotatingkeys.htm"
   ],
-  "security_notes": "After the scheduled deletion window expires, HSM-backed keys are cryptographically wiped. All data encrypted exclusively by that key version is permanently unrecoverable. Recovery SLA from OCI Support: NONE. Always use a 30-day window and audit data associations before scheduling.",
-  "last_verified": "2026-04-30",
+  "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-live-vault-key-destruction-guard",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.1"
 }

package/skills/oci/oci-live-vault-key-destruction-guard/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-live-vault-key-destruction-guard/references/official-sources.md

@@ -1,13 +1,22 @@
-# Official Sources: OCI Live Vault Key Destruction Guard
+# Official sources
 
-## OCI Vault (KMS)
+Use these sources to ground service behavior before making production recommendations or routing decisions.
+
+## Oracle documentation checked on 2026-06-05
 
 - https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Concepts/keyoverview.htm
-- https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/managingkeys.htm
-- https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/managingkeyversions.htm
-- https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/deletingvaultsorkeys.htm
+- https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/managingkeys_topic-To_delete_a_key.htm
+- https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/managingvaults_topic-To_delete_a_vault.htm
+- https://docs.oracle.com/en-us/iaas/Content/KeyManagement/Tasks/rotatingkeys.htm
+
+## 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 where applicable.
+- Command-help evidence confirms available list/filter surfaces; it does not prove permissions, resource existence, regional availability, capacity, quota, data correctness, traffic safety, catalog correctness, or production readiness.
 
-## Source-grounding rule
+## Grounding rules
 
-Use official Oracle Cloud Infrastructure documentation as the source of truth for Vault and KMS behavior.
-Key deletion timing windows must be verified from current OCI docs — they can change between API versions.
+- Prefer the most specific Oracle documentation page for the service or feature being discussed.
+- If documentation, catalog, 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-live-vault-key-destruction-guard/references/safety-checklist.md

@@ -0,0 +1,35 @@
+# Safety checklist
+
+Use this checklist before producing guidance, requesting evidence, routing a task, or proposing changes.
+
+## Evidence labels
+
+- `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.
+
+## Credential and identifier boundaries
+
+- 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.
+
+## Mutation boundary
+
+Require explicit approval before creating, updating, deleting, moving, scaling, rotating, patching, enabling, disabling, deploying, applying, destroying, promoting, rolling back, deleting keys, changing traffic, changing access, or changing production state.
+
+## Approval gates
+
+- 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-live-vault-key-destruction-guard/references/vault-key-destruction-operations.md

@@ -0,0 +1,66 @@
+# OCI Live Vault Key Destruction Guard Operations
+
+> Version note: OCI service behavior, catalog entries, and tooling change over time. Verify exact command syntax, permissions, regional availability, feature maturity, and catalog targets 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
+
+- Deleting a key before proving every encrypted dependency is gone or rekeyed.
+- Assuming key deletion is reversible after the waiting period.
+- Rotating keys without validating consumers and older key-version dependencies.
+- Ignoring vault replication and regional blast radius.
+
+## Officially grounded service shape
+
+- Official OCI documentation says deleting a key is destructive and can make data encrypted with that key inaccessible; OCI requires scheduling deletion with a waiting period.
+- Official OCI documentation says the key deletion wait period defaults to 30 days and can be shortened to a minimum of 7 days.
+- Official OCI documentation recommends backing up a key before scheduling deletion and using service log data to analyze key usage.
+- OCI API evidence through the user’s configured read-only OCI MCP shows key listing is compartment/vault scoped, requires a management endpoint, and can filter by protection mode, algorithm, length, curve, sorting, and pagination.
+- OCI API evidence through the user’s configured read-only OCI MCP shows schedule deletion sets lifecycle to pending deletion and cancel deletion restores the key lifecycle state.
+
+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 disable, rotate, schedule deletion, cancel deletion, vault deletion, and encrypted-data recovery evidence.
+- Require explicit owner and security approval before scheduling deletion or destructive key lifecycle actions.
+- Prefer disablement, dependency audit, backup, and maximum waiting window before deletion.
+- Do not expose key identifiers, vault endpoints, encrypted payloads, secrets, customer data, or sensitive identifiers.
+
+## Minimal safe implementation flow
+
+- Confirm key/vault scope, operation, protection mode, encrypted-resource dependencies, owner, and compliance driver.
+- Use official docs for key lifecycle behavior and sampled read-only evidence for API shape/current lifecycle state.
+- Audit usage logs, associated resources, backups, replication, and cancellation window.
+- Return verdict, blockers, deletion-window stance, cancellation plan, and verification checks.
+
+## High-risk assumptions to kill
+
+- “No recent usage means safe to delete.”
+- “Rotation removes dependency on old key versions.”
+- “Scheduled deletion can always be cancelled later.”
+- “Deleting a replicated vault/key only affects one location.”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+- Check key lifecycle, protection mode, vault/replication context, and usage evidence without exposing identifiers.
+- Validate encrypted resources have been rekeyed, retired, or proven disposable.
+- Confirm backup/restore eligibility and cancellation window.
+- Capture explicit approval and post-action monitoring.
+
+## 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 or live-guard dispatch 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 to delete a key without dependency and backup evidence.
+- The proposed deletion window is shorter than needed for audit and cancellation.
+- The evidence includes vault endpoints, key identifiers, secrets, or customer data.

package/skills/oci/oci-live-vault-key-destruction-guard/references/workflow-and-output.md

@@ -0,0 +1,26 @@
+# Workflow and output contract
+
+Use this workflow for full reviews, routing decisions, and live-guard decisions.
+
+## 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, route, or production-readiness answer:
+
+- `verdict`: pass, pass-with-risk, blocked, needs-evidence, or routed.
+- `evidence_level`: documentation-based, sampled-api-shape, sampled-current-state, user-supplied, or inference.
+- `blockers`: missing proof, unsafe assumptions, approval gaps, or routing 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.