landing-zone-customer-guidance

name	landing-zone-customer-guidance
description	Use when handling customer-facing OCI landing zone design or deployment questions, especially when the customer describes an outcome such as running OKE and may not know repo terms such as One-OE, hub families, environments, projects, or platforms.

Landing Zone Customer Guidance

Overview

Use this skill before recommending repo paths, blueprints, or config files for customer-use landing zone requests.

AGENTS.md is the canonical policy source for the customer safety gate, discovery sequence, unsupported-resource handling, artifact placement, and deployment defaults. This skill is the activation checklist for applying those rules in customer conversations.

Core principle: guide the customer through the required design decisions one at a time in plain language, then map answers back to repo terminology only after the customer understands the choice being made.

When to Use

• A customer asks for landing zone design, deployment, or recommendation help
• The request is outcome-first, such as "I want landing zone to run OKE"
• The customer may not know repo or generator terms
• You need to determine whether the standard published path or the config-driven path fits

Do not use this skill for repo-development work. Once the request is clearly on the config-driven path and the customer decisions are already known, switch to landing-zone-config.

Workflow

1. For customer-use and ambiguous-or-mixed requests, show the exact warning from AGENTS.md and wait for explicit acceptance.
2. After acceptance, give one short orientation sentence and ask only the first missing question.
3. Follow the discovery order from AGENTS.md. The items are a decision sequence, not a single questionnaire.
4. Before asking the customer to choose between repo labels, explain those options in customer language and recommend a default when the repo has one.
5. After each answer, summarize what is now known in one sentence, then ask the next missing question.
6. After the hub family is known and before discussing public exposure, load balancers, or OKE ingress, inspect the matching hub guide or runtime artifacts first so you know what load balancer pattern already exists.
7. Only after all required decisions are known, including target region and any non-oc1 realm requirement, may you recommend a published runtime path, a workload extension path, or config-mode generation.
8. When deployment execution comes up, use the secure delivery defaults from AGENTS.md: prefer Terraform CLI or customer-controlled CI/CD; for ORM, use customer-controlled private Object Storage or approved private GitHub source, not public raw URLs.
9. If the conversation turns into Orchestrator or Resource Manager runtime troubleshooting, use oci-lz-orchestrator-contract-advisor as a supporting verifier after this customer flow has established the deployment context.

Unsupported Requirements

If the selected published path, config generator, or workload extension does not support a requested resource, service, topology, or behavior:

• Say plainly that it is not supported by the Landing Zone framework today.
• Do not invent config keys, edit generated JSON, or imply the framework can create it.
• Split the answer into "Generated by the landing zone" and "Manual post-deployment configuration required."
• Prepare supported prerequisites where possible, and keep manual lifecycle, drift, and compliance ownership explicit.
• For external connectivity such as Site-to-Site VPN or FastConnect, verify the selected repo path first and consult official OCI docs for service-specific manual steps.

Discovery Reminders

• Always default to One-OE; do not ask who operates the landing zone or ask the customer to choose a landing zone family.
• Ask in root AGENTS.md order: One-OE baseline, region and optional realm, environments, workloads, firewall, hub model, network-producing extension scope and sizing before CIDR allocation, then CIDRs.
• Ask for the target OCI region early. Explain that realm defaults to oc1 public cloud when omitted, and ask for realm only when a non-public or sovereign deployment may apply, such as oc19 EU Sovereign Cloud.
• Explain each decision in customer language before using repo terms such as One-OE, Hub A, platform, project, or shared_project_network.
• Do not propose concrete CIDRs until the root AGENTS.md network-scope gate is complete; use extension guides such as OKE or ExaCS only for extension-specific sizing inputs.

OKE-Specific Guardrails

• If the customer only says they want OKE, do not jump to oke_simple, single-stack vs multi-stack, or config snippets.
• Do not assume OKE means projects are required.
• Do not assume an environment needs shared_project_network unless the intended topology requires a spoke VCN.
• Explain OCI CIDRs separately from Kubernetes pod and service CIDRs; use gen/workload-extensions/oke/AGENTS.md for repo-specific OKE networking semantics.
• Do not treat non-production as an automatic reason to recommend a no-firewall hub. Firewall-based designs are still the recommended default unless the customer explicitly accepts the tradeoff for a simpler non-production layout.
• When the customer asks for public access, do not assume the chosen hub needs a brand-new public load balancer design. Check the selected hub guide or runtime artifacts first; in the One-OE one-stack runtime, each hub family already includes a public load balancer example with placeholder backends.

ExaDB-D / ExaCS-Specific Guardrails

• If the customer says ExaDB-D, Exadata Database Service on Dedicated Infrastructure, Autonomous Database Dedicated, ExaCS, VMC, or AVMC, complete the base landing-zone discovery first.
• Ask whether Exadata infrastructure is shared across environments or dedicated per environment.
• Ask whether the customer will use Autonomous Database Dedicated on AVMCs, regular Exadata Database Service on VMCs, or both.
• Ask whether AVMCs/VMCs are shared or environment-specific. Explain that AVMC/VMC placement requires an ExaCS network with database and backup subnets.
• For Autonomous Database Dedicated, ask which environments and projects need project DB tiers; do not add them for regular Exadata Database Service-only designs.
• Use gen/workload-extensions/exacs/AGENTS.md for extension-specific placement mapping before authoring config.

ExaDB-C@C / ExaCC-Specific Guardrails

• Complete the base landing-zone discovery first before discussing ExaDB-C@C artifacts.
• Use the ExaDB-C@C generator guide under gen/workload-extensions/exacc/ for extension-specific semantics before authoring config or reviewing published snapshots.
• Treat Orchestrator dependency/output questions as contract checks, not as permission to skip customer discovery.