> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/cloud-for-dpi/agent-skills/learning-system/giga-cloud-learning-guide.md). # GIGA Cloud Learning Guide Learn, operate, challenge, and review Chapters 1 to 4. {% hint style="info" %} **Skill** `giga-cloud-learning-guide` · version 0.3.0 · [Chapter 1](/experience-digital-transformation/cloud-for-dpi/chapter-1.md) · [Chapter 2](/experience-digital-transformation/cloud-for-dpi/chapter-2.md) · [Chapter 3](/experience-digital-transformation/cloud-for-dpi/chapter-3.md) · [Chapter 4](/experience-digital-transformation/cloud-for-dpi/chapter-4.md) · [Source](https://git.vanillacore.net/giga/cloud-skills/src/commit/5ef20352d7e160cb5145c3773a7f002e1f03d5a3/skills/giga-cloud-learning-guide) · [Install and use](/experience-digital-transformation/cloud-for-dpi/agent-skills/install-and-use.md) {% endhint %} Use this as the package entry point for learning and applying GIGA Cloud Chapters 1 to 4. It owns the cross-chapter case, learning mode, scope boundaries, handoffs, and final quality statement. It is not a directory of sibling skills and does not approve a local architecture. ## When to use Use it when a learner wants to: * ask a question spanning more than one chapter; * learn a concept through a public-service case; * build the Chapter 1 to 4 artifacts in sequence; * prepare or execute the packaged Chapter 3 and 4 operator workflows; * challenge an architecture, assumption, or claimed benefit; * review an artifact for architectural, content, syntax, and evidence quality. Use a focused skill directly when the question clearly belongs to one chapter and no cross-chapter handoff is needed. ## Input ```yaml mode: ask | learn | work | challenge | review chapter: auto | 1 | 2 | 3 | 4 operation: assess | prepare | provision | validate | maintain | cleanup execution: explain | prepare | execute working_directory: change_approval: case: service_outcome: supplied_facts: supplied_evidence: question: artifact: constraints: ``` Do not require fields that are irrelevant to the selected mode. Never turn a missing local fact into a plausible default. ## Chapter route | Chapter | Decision or operating question | Primary output | Focused skill | | ------- | ------------------------------------------------------------ | ----------------------------------------- | ----------------------------------------------- | | 1 | Which operating arrangement is defensible for this service? | `service_arrangement_decision_record` | Five decision skills, coordinated by this guide | | 2 | What must the foundation and platform provide? | `foundation_readiness_architecture_brief` | `public-service-platform-architecture` | | 3 | How does IaaS create and prove controlled resources? | `iaas_technical_baseline` | `iaas-foundation-practitioner` | | 4 | How are Kubernetes clusters managed on that IaaS foundation? | `cluster_runtime_baseline_record` | `kubernetes-cluster-lifecycle-practitioner` | Read `references/chapter-contracts.md` when the request crosses a chapter boundary. The repository also keeps machine-readable and reviewer-facing copies of these contracts, but this skill must remain usable when installed directly. ## Procedure 1. Distinguish a concept question, artifact review and a request to inspect a real environment. “Why is this VM unreachable?” is read-only diagnosis, not only prose review. “Explain” selects `ask`; “teach” selects `learn`; practical inspection or change selects `work`; “challenge” selects `challenge`; an artifact check selects `review`. Preserve execution intent separately from learning mode. 2. For a new architecture decision, select the earliest chapter that owns the unresolved decision. Do not solve a Chapter 1 operating-arrangement gap with a Chapter 4 topology. For existing resources, use the operational route below without forcing the user through earlier chapter decisions. 3. State the current case boundary in one sentence: service or artifact, supplied facts, and the decision under examination. Create or preserve one `case_id`. 4. Select exactly one primary focused skill from the chapter route. Activate it through the host's skill mechanism when available and pass the same `case_id`, mode, supplied facts, evidence, and prior handoff. Add a supporting skill only for a named secondary question. 5. If the focused skill is unavailable, return `focused_skill_required` with its name and the complete handoff. Do not imitate an unavailable specialist with invented detail. 6. Validate each returned artifact against the chapter contract, `case_id`, required IDs, and allowed status values. Preserve unknowns and reject prose aliases that break the handoff. 7. Reconcile specialist findings. When two findings conflict, return a reconciliation finding or decision gap with both bases. Do not silently choose one. 8. For Chapter 3 or 4 `work` requests, preserve `operation`, `execution`, `working_directory`, `change_approval`, and the prior handoff when activating the practitioner skill. Require its portable operator kit for practical execution. 9. Apply the selected mode contract below. In challenge mode without a learner attempt, pose the challenge and stop before the model correction. 10. Run the four-axis quality gate, then produce the integrated `architecture_learning_record` below with one bounded next action. ## OpenStack usage route The five OpenStack usage skills are operational tools, not compulsory chapter lessons. Use them directly for existing resources and ordinary tenant tasks. Keep `iaas_technical_baseline` as the Chapter 3 teaching and Chapter 4 handoff, but do not require a full new baseline to inspect one VM or volume. Read `references/openstack-usage-contract.md`. The portable helper `scripts/route_openstack.py` accepts a JSON routing request and returns `openstack-routing-record/v1`. It makes no cloud calls and never approves a mutation: ```bash python3 /absolute/path/to/installed/giga-cloud-learning-guide/scripts/route_openstack.py \ --request /protected/work/routing-request.json ``` | Task | Primary skill | | -------------------------------------------------------- | --------------------------- | | Profiles, project, region, catalogue, quota or inventory | `openstack-environment` | | VM create, lifecycle or resize | `openstack-compute` | | Networks, routers, security rules and floating IPs | `openstack-networking` | | Volumes, attachments, extension and snapshots | `openstack-storage` | | Cross-service faults and reachability diagnosis | `openstack-troubleshooting` | 1. Preserve the case ID, supplied target context, previous resource IDs and prior handoff. Discover only missing inputs for the chosen task. Unavailable catalogue or write permissions do not invalidate permitted read-only work. 2. Activate exactly one primary focused skill through the host. Pass task, mode, execution intent, context and prior evidence. If it is absent, return the existing `focused_skill_required` continuation with the router's exact skill name, not an imitation of its operation. 3. For multi-domain work, keep an ordered continuation queue. Prepare networking before dependent VM creation; validate each resulting ID before the next primary skill receives it. One plan approves one action, not the entire queue. 4. Inspect ownership before direct changes. CAPI-owned targets continue through Chapter 4. OpenTofu and GitOps targets continue through their supplied declarations. An ownership label alone is not proof: the focused runtime and operator must confirm target ownership and stop on conflicting live evidence. 5. `inspect` is read-only; `prepare` produces a proposal through read-only checks. `execute-requested` in a routing result is intent only. The focused runtime must verify the exact saved plan digest, project, region, target, current state and action-specific approval before executing. 6. Validate the returned `openstack-operation-record/v1` against the focused skill's local contract. Require matching case, project and region, real check results, preserved stable IDs and explicit partial/blocked outcomes. Treat no live evidence as unverified, not successful execution. 7. Place the operation record in `operator_execution` of the integrated result with its schema unchanged. Keep any existing chapter handoff alongside it; operational evidence must not silently replace missing Chapter 3 learning requirements. Never turn a request for diagnosis into repair approval. Explain on demand, prepare requested changes, and execute only after the runtime gate. A denied action names its missing permission or unsupported API; other allowed actions can proceed. Guest, application, backup and recovery results need their own evidence. ## Integrated output ```yaml architecture_learning_record: schema: architecture-learning-record/v1 case_id: mode: ask | learn | work | challenge | review chapter: 1 | 2 | 3 | 4 primary_skill: supporting_skills: [] learner_goal: execution_scope: guidance | offline-validation | live-change operator_execution: direct_answer_or_exercise: transferable_concepts: [] reference_implementation_mapping: [] supplied_facts: [] assumptions_and_unknowns: [] chapter_handoff: reconciliation_findings: [] counter_case: sources: [] review: architecture: pass | needs-work | unverified content: pass | needs-work | unverified syntax: pass | needs-work | unverified evidence: pass | needs-work | unverified bounded_next_action: ``` The record is a synthesis, not a copy of every specialist response. Keep exact IDs in the chapter handoff so a later fresh session can continue the case. ## Mode contracts ### Ask Put the direct answer first. Then separate: 1. the transferable concept; 2. the reference-implementation mapping, if any; 3. conditions and counter-cases; 4. supplied facts versus assumptions; 5. what has and has not been validated; and 6. named public sources. ### Learn Teach one concept because the learner needs it for the next decision. Use the current public-service case, contrast it with one counter-case, and end with one check question plus evaluation criteria. Give a worked answer only when requested. ### Work Guide the learner through **Spec -> Run -> Validation. Repeat.** Produce or update the chapter handoff using supplied facts. Keep unknowns visible, assign evidence owners where known, and stop before a decision-blocking gap would require invention. For Chapter 3 and 4 practical work, route `assess`, `prepare`, `provision`, `validate`, `maintain`, or `cleanup` to the matching practitioner. Practical execution uses a protected working copy of its `assets/operator-kit/`. Live changes require `execution: execute`, the focused skill's complete operation gate and explicit action approval. Return the real `operator_execution` record; never substitute plausible output when tools, credentials, targets or approval are absent. ### Challenge Test the strongest claim in the artifact. Look for hidden dependencies, confused responsibility and accountability, shared failure domains, false portability or sovereignty claims, product names used as proof, absent recovery evidence, and claims that exceed the performed validation. Return the counter-case that would break the claim and the evidence needed to keep it. ### Review Return the review envelope from `references/chapter-contracts.md`. A finding must quote or identify the exact artifact element, explain the failure consequence, and give a bounded repair. Keep parser, schema, environment, and live-behaviour verdicts separate. ## Four-axis quality gate * **Architecture:** Layers, ownership, trust boundaries, dependencies, failure domains, lifecycle owners, and chapter scope are coherent. * **Content:** Terms are defined before use, generic capability precedes product mapping, assumptions are labelled, and named public sources support material claims. * **Syntax:** Every code block is classified as conceptual, illustrative, or executable. Executable material is checked with an appropriate parser or schema tool when available. Missing tooling yields `unverified`, never `valid`. * **Evidence:** State exactly what each check proves. Static validation does not prove live capacity, routing, reconciliation, recovery, cleanup, or service usability. ## Pitfalls * Do not turn this guide into a list of skill names. It must maintain the case, mode, handoffs, and final verdict. * Do not answer a strategic question with implementation detail merely because concrete syntax is available. * Do not hide contradictory chapter sources. Follow the source-note rule in `references/chapter-contracts.md`. * Do not cite an internal note, inaccessible path, or anonymous authority. * Do not claim a command, manifest, or architecture was validated unless the stated check actually ran. * Do not run or modify the checked-in operator kit in place. Use a protected working copy and preserve its source record. * Do not treat a request to establish the Chapter 4 cluster layer as proof that Chapter 5 platform operations are complete. ## Verification A successful response identifies the mode and chapter, uses the correct handoff, answers or exercises the learner's actual question, includes a counter-case, separates generic concepts from product details, reports all four quality axes, and names the sources used. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/cloud-for-dpi/agent-skills/learning-system/giga-cloud-learning-guide.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.