Summary · Composing a Sandcastle request

Key takeaways

The compose → construct boundary is where the academy story Crossplane composes, Sandcastle constructs, Picos behave turns a declarative request into engineering work. Crossplane owns the request; the Sandcastle owns the work.
Crossplane’s Composition emits an EngineeringTask — a declarative record of the construction work the cluster wants done. It writes no code and touches no repository.
The Sandcastle reads the EngineeringTask (never the original XR), runs the same inspect → generate → validate → commit inner loop from Part 1 · Lesson 1, and returns a durable Git branch. The sandbox is then disposed.
The construction stage is parametric on the request: the greeting the branch’s rules/hello.yaml carries is the greeting the XR asked for, not a hard-coded string in the agent.
The compose → construct hand-off is exactly two files: xr-request.yaml on the compose side and engineering-task.yaml as the boundary artifact. Nothing else crosses.
This lesson is runnable end-to-end via the reusable Compose a Sandcastle request lab, whose verify.sh asserts the four hand-off rules programmatically.

Part 3 · Lesson 1 — Handing off to Kubernetes covers the reverse-direction boundary: how the durable branch this lesson produces later becomes a Crossplane XR that the cluster composes into a runtime Job. See Part 3 · Lesson 1 and the runnable Sandcastle → Kubernetes hand-off lab.
Part 3 · Lesson 2 — The outer delivery loop develops the guardrails that live outside the Sandcastle’s boundary — PR review, GitOps promotion, Crossplane reconciliation — and reuses both this lesson’s lab and the Kubernetes lab as its runnable endpoints. See Part 3 · Lesson 2.
Cluster-backed variants — this lesson’s compose.sh is a local simulation of a Crossplane Composition. A cluster-backed variant that runs a real Composition emitting a real EngineeringTask CR is a natural Part 2 follow-up but is intentionally out of scope for this lesson.

Take the Quiz.