Hello World Pico Sandcastle

Run a real Sandcastle end-to-end to construct the hello-world-pico artifact on a dedicated branch.

See the Open Engineering Language Server (OELS) onboarding guide for the local install and editor setup.

TipOELS in your editor

While you work through this content, keep the Open Engineering Language Server (OELS) active in VS Code (or any LSP-capable editor). See the OELS onboarding guide linked at the top of this page (also linked from the academy Resources page) for the one-time install and configuration steps.

What OELS validates. OELS only recognizes OE-shaped YAML/JSON: files with a mapping root that declare an apiVersion beginning with open-engineering.io/, a non-empty kind, and a DNS-1123 metadata.name. Ordinary academy metadata.yaml, Quarto/QMD pages and front matter, Kubernetes/Crossplane/runtime manifests, JSON payload samples, and shell scripts are intentionally non-OE — OELS ignores them silently and you should not add synthetic apiVersion/kind headers to force recognition.

Where you see diagnostics. OELS surfaces UnknownProperty, MissingRequiredProperty, IncorrectType, InvalidEnumValue, MalformedIdentifier, UnknownDefinition, and reference-shape hints in the editor Problems panel as you type. These are independent of quarto render: OELS diagnostics do not block rendering, and Quarto errors do not appear in the Problems panel.

The executable check still comes from this exercise. OELS speeds up editing, but the exercise’s own parser, verifier, or verify.sh (for example the pico parse … command shown below) remains the authoritative success check. Run it as usual.

Overview

Hello World Pico Sandcastle is the first runnable Sandcastle lab of the Open Engineering Academy. You will execute a small Sandcastle driver that provisions an isolated workspace, runs an engineering agent under a constrained tool allowlist, has the agent author and validate rules/hello.yaml using the reference pico CLI, commits the file on a dedicated branch, hands the branch back to a durable target repository, and disposes of the workspace.

This lab is reusable across courses: it lives at the repository root under labs/hello-world-pico-sandcastle/ and is referenced from the Sandcastle course.

Structure

What you will produce

A durable branch named sandcastle/hello-world-pico on a local target repository, containing exactly one committed file (rules/hello.yaml). Recomposing from that branch with the reference pico CLI produces the hello-world-pico executable and prints Hello, Pico!.

The final artifact matches the produces entry hello-world-pico-sandcastle-branch in metadata.yaml. The durable evidence is captured outside the sandbox under work/hello-world-pico-sandcastle/results/ (branch info, a fresh clone of the target branch, and the greeting printed by the recomposed Pico).

Downloads and screenshots

Runnable files live under downloads/:

  • blueprint.yaml — a filled-in Sandcastle blueprint following the shape from the Sandcastle course’s Part 1 Exercise.
  • sandcastle-run.sh — driver that provisions the isolated workspace, seeds a target repo, runs the agent under a PATH allowlist, hands the branch back, and disposes of the workspace.
  • sandcastle-agent.sh — the engineering-agent inner iteration loop (inspect → generate → validate → commit) run inside the sandbox.
  • verify.sh — automatable check that runs the full path and asserts the branch, artifact, and boundary.

Screenshot targets for the walkthrough live under screenshots/. No image files ship yet; screenshots/README.md catalogues the three intended terminal moments (driver tail, durable branch, verify: OK), their filenames, capture regions, and alt text, so the lab is screenshot-ready as soon as contributor captures land.

Metadata

Machine-readable descriptor: metadata.yaml. Fields follow the same schema as labs/hello-pico/metadata.yaml.

Referenced from