Am I the only one who finds the OpenClaw DSL documentation kind of sparse?

I've been evaluating OpenClaw for a potential shift in how we manage our foundational cloud resources—VPCs, IAM roles, KMS keys, that sort of thing. The promise of a declarative DSL that can generate both Terraform HCL and Pulumi code is incredibly compelling for a multi-team environment like ours, where different squads have different tool preferences but need to share core modules.

However, I've hit a consistent wall: the documentation. It feels more like a series of abbreviated examples rather than a comprehensive guide. For instance, when I tried to implement a fairly standard hub-and-spoke network pattern, the reference materials showed a trivial single VPC definition, but gave no guidance on how to create multiple interconnected resources with dependencies, or how to use loops and conditionals within their DSL. I spent an afternoon reverse-engineering from the generated outputs, which defeats the purpose of a clean abstraction.

Here's the extent of the example for a VPC, straight from their "Getting Started":

```claw
resource aws_vpc "main" {
cidr_block = "10.0.0.0/16"
tags = {
Name = "example-vpc"
}
}
```

But what about more complex, real-world scenarios? For example:
* How do I reference the ID of this VPC in a subsequent subnet resource *within the same OpenClaw config*? Is there an intrinsic `self` attribute, or a `ref` keyword?
* Where is the full schema for every supported provider and resource? I found a JSON Schema file buried in the GitHub repo, but it wasn't linked from the main docs.
* The testing section is a single sentence: "You can test generated code with your existing tools." That's not enough. I need to know if there are unit testing primitives *within* OpenClaw itself, before code generation, to validate business logic.

This lack of depth makes it risky to adopt. In our SRE world, we rely on clear runbooks and postmortems. A tool's documentation is its first-line runbook. If I can't easily answer "how do I do X?" or, more importantly, "why did this generate Y?", it introduces uncertainty into our change management process. My team's learning curve is already steep with our current on-call rotations; a new tool needs to be immediately clear in its capabilities and limitations.

Am I missing a hidden trove of tutorials or a detailed spec somewhere? Or are others also navigating mostly by inspecting the generated Terraform/Pulumi and working backwards? I'm concerned about the long-term maintenance burden if the foundational docs aren't robust.