Files and test commands
The code you will use
All paths are relative to the repository root, /home/dev/workspace, in your team's remote web editor. Use the Terminal panel for shell commands and OpenCode agent for AI messages. Run pwd to see the terminal's current folder; if needed, run cd /home/dev/workspace.
| Language | Workshop code that calls Clipper2 | Public tests you can read and edit |
|---|---|---|
| C++ | src/cpp/lab/geometry_lab.cpp; declarations in src/cpp/lab/geometry_lab.h | tests/cpp/public_tests.cpp |
| C# | src/csharp/GeometryLab/GeometryAudit.cs | tests/csharp/PublicTests/GeometryAuditTests.cs |
Both versions implement ClippedArea and ClassifyPoint. The larger upstream Clipper2 library is under src/cpp/Clipper2Lib/ and src/csharp/Clipper2Lib/. The core exercises concern the workshop functions; extra exercise 9 deliberately follows a call into the library.
docs/spec.md states the workshop's expected behaviour. A test case provides particular input and compares the result with an expected value. An assertion is that comparison in code. A test name describes an intention; read the assertion to see what is actually tested.
Run the public tests
Open a terminal at the repository root. For a C++ exercise, run:
./scripts/test-cpp.shFor a C# exercise, run:
./scripts/test-csharp.shThese commands build the code and run the public tests in the corresponding file above. Read the terminal output: a compiler or dependency error means the tests could not run successfully; it is different from a test assertion reporting a wrong geometry result.
When an exercise asks you to verify the whole repository, run:
./scripts/test-all.shThis runs documentation/content validation, then the C++ public tests, then the C# public tests. Content validation verifies expected workshop files, headings, and links; it does not test geometry. A message beginning content check failed: identifies a material/setup problem to raise with a facilitator. It stops at the first failing stage. If it stops early, do not describe later stages as passed. Run the language commands separately when you need each result.
The team environment already contains the build tools. If a command fails because something is missing, ask OpenCode to explain the error and involve a facilitator before changing the environment.
Run the workshop's additional test service
In the team's workshop environment, run:
workshop-checkThe team environment preconfigures the team identity, assigned language, and service address; no extra flag or login is needed. By default, this command copies the saved files in /home/dev/workspace to the workshop's test service. It includes uncommitted source, tests, and documents, while excluding .git, build/, language build folders (bin/ and obj/), and files ending in .env. The service builds and tests the assigned language using additional tests that are not shown in the repository. You do not need to commit or push first. Save editor changes before running it.
The response describes the overall run, not each individual test case:
| Field | Meaning |
|---|---|
passed | Whether the service run passed |
category | Broad outcome, such as passed, contract_failed, or timeout |
duration_ms | How long the run took, in milliseconds |
evidence_id | A reference for this recorded run |
Read passed in the response; successful transmission alone does not mean the tests passed. A contract_failed category can include a build failure as well as a failed assertion. It does not identify a particular test or tell you what to change. If the command reports a connection or authentication error, record that error and ask a facilitator; do not invent a test result or evidence ID.
Use the visible code, public tests, and specification to investigate. Additional tests are a second source of evidence, not a substitute for understanding the change. workshop-check is supplied by the team environment and may not exist on a personal laptop.
Record useful evidence
The terminal output is enough for the main finding. If a handoff needs a compact summary, optionally use docs/evidence-template.md to keep commands, expected and observed results, and the reason for the change. Extra exercises request their own small tables or documents only when those are part of the learning goal.
The repository ignores build/ in Git. Put temporary runners in their own subfolders, such as build/experiments/ or build/hello/. The C++ test script manages build/cpp/ and can recreate that subfolder when its build cache is stale; keep your experiments outside it. Keep useful commands, inputs, and results in the terminal or an optional evidence record before removing a temporary runner.
Generated images, build output, and temporary experiments should not be included in solution commits. Inspect git status --short and git diff before committing. Keep other team members' work intact.
When the team is ready to finish, use the closing conversation. No hand-in is required.
Fresh conversations and model comparison
For extra exercise 17, type /new in OpenCode to start a fresh conversation, then /models to choose a model. The configured pair is GPT-5.6 Luna and GLM 5.3; GLM 5.2 is the reserve. Record the actual names shown and ask a facilitator if a model is unavailable. Use the same prepared prompt and code snapshot in each conversation.
Press Tab to select the Plan agent before sending the analysis request. Plan asks for permission for file edits and shell commands by default; it is not a guarantee that no change can happen. Decline edits and commands that would change files during the two answers, and compare the before/after diff. Verify claims afterwards with the focused tests or temporary experiments described in the exercise. Use a phone timer to measure from sending the prompt to the completed answer.