Filer och testkommandon
Koden ni ska använda
Alla sökvägar är relativa till repots rot, /home/dev/workspace, i teamets fjärrredigerare. Använd panelen Terminal för skalkommandon och OpenCode-agenten för AI-meddelanden. Kör pwd för att se terminalens aktuella mapp; kör vid behov cd /home/dev/workspace.
| Språk | Workshopkod som anropar Clipper2 | Offentliga tester som ni kan läsa och ändra |
|---|---|---|
| C++ | src/cpp/lab/geometry_lab.cpp; deklarationer i src/cpp/lab/geometry_lab.h | tests/cpp/public_tests.cpp |
| C# | src/csharp/GeometryLab/GeometryAudit.cs | tests/csharp/PublicTests/GeometryAuditTests.cs |
Båda versionerna implementerar ClippedArea och ClassifyPoint. Det större Clipper2-biblioteket finns under src/cpp/Clipper2Lib/ och src/csharp/Clipper2Lib/. Grundövningarna handlar om workshopfunktionerna; extraövning 9 följer avsiktligt ett anrop in i biblioteket.
docs/spec.md anger workshopens förväntade beteende. Ett testfall innehåller en viss indata och jämför resultatet med ett förväntat värde. Ett påstående är denna jämförelse i koden. Ett testnamn beskriver en avsikt; läs påståendet för att se vad som faktiskt testas.
Kör de offentliga testerna
Öppna en terminal i repots rot. För en C++-övning kör ni:
./scripts/test-cpp.shFör en C#-övning kör ni:
./scripts/test-csharp.shDessa kommandon bygger koden och kör de offentliga testerna i respektive fil ovan. Läs terminalutdata: ett kompilator- eller beroendefel betyder att testerna inte kunde köras; det skiljer sig från ett testpåstående som rapporterar fel geometriresultat.
När en övning ber er verifiera hela repot, kör:
./scripts/test-all.shDet kör dokumentations-/innehållsvalidering, sedan C++-tester och därefter C#-tester. Innehållsvalideringen verifierar förväntade workshopfiler, rubriker och länkar; den testar inte geometri. Ett meddelande som börjar med content check failed: visar ett materiellt innehålls-/konfigurationsproblem som ska tas upp med en handledare. Det stannar vid det första steget som misslyckas. Om det stannar tidigt ska ni inte beskriva senare steg som godkända. Kör språkkommandona separat när ni behöver varje resultat.
Teamets miljö innehåller redan byggverktygen. Om ett kommando misslyckas för att något saknas, be OpenCode förklara felet och ta hjälp av en handledare innan ni ändrar miljön.
Kör workshopens extra testtjänst
Kör i teamets workshopmiljö:
workshop-checkTeammiljön förkonfigurerar teamidentitet, tilldelat språk och tjänsteadress; inga extra flaggor eller inloggningar behövs. Som standard kopierar kommandot de sparade filerna i /home/dev/workspace till workshopens testtjänst. Det inkluderar okommittad källkod, tester och dokument, men utesluter .git, build/, språkens byggmappar (bin/ och obj/) och filer som slutar med .env. Tjänsten bygger och testar det tilldelade språket med ytterligare tester som inte visas i repot. Ni behöver inte committa eller pusha först. Spara redigerarens ändringar innan ni kör.
Svaret beskriver hela körningen, inte varje enskilt testfall:
| Fält | Betydelse |
|---|---|
passed | Om tjänstekörningen lyckades |
category | Övergripande utfall, till exempel passed, contract_failed eller timeout |
duration_ms | Hur länge körningen tog, i millisekunder |
evidence_id | En referens till den registrerade körningen |
Läs passed i svaret; att överföringen lyckades betyder inte att testerna lyckades. Kategorin contract_failed kan innehålla både byggfel och misslyckade påståenden. Den anger inte ett särskilt test och säger inte vad ni ska ändra. Om kommandot rapporterar anslutnings- eller autentiseringsfel, dokumentera det felet och fråga en handledare; hitta inte på testresultat eller evidens-ID.
Använd synlig kod, offentliga tester och specifikationen för att undersöka. Ytterligare tester är en andra beläggskälla, inte en ersättning för förståelse. workshop-check tillhandahålls av teamets miljö och kan saknas på en personlig laptop.
Dokumentera användbara belägg
Terminalutdata räcker för huvudfyndet. Om en överlämning behöver en kompakt sammanfattning kan ni använda docs/evidence-template.md för att hålla kommandon, förväntningar och observationer samt ändringens orsak samlade. Extraövningar begär egna små tabeller eller dokument endast när de ingår i lärandemålet.
Repot ignorerar build/ i Git. Lägg tillfälliga körprogram i egna undermappar, till exempel build/experiments/ eller build/hello/. C++-testskriptet hanterar build/cpp/ och kan återskapa den mappen när byggcachen är inaktuell; håll experimenten utanför den. Behåll användbara kommandon, indata och resultat i terminalen eller i ett valfritt evidensprotokoll innan ni tar bort ett tillfälligt körprogram.
Genererade bilder, byggutdata och tillfälliga experiment ska inte ingå i lösningscommits. Granska git status --short och git diff före commit. Behåll andra teammedlemmars arbete intakt.
När teamet är redo att avsluta använder ni det avslutande samtalet. Ingen inlämning krävs.
Nya konversationer och modelljämförelse
För extraövning 17 skriver ni /new i OpenCode för att starta en ny konversation och sedan /models för att välja modell. Det konfigurerade paret är GPT-5.6 Luna och GLM 5.3; GLM 5.2 är reserv. Anteckna de faktiska namnen som visas och fråga en handledare om en modell saknas. Använd samma förberedda förfrågan och kodsnapshot i varje konversation.
Tryck Tab för att välja Plan-agenten innan analysförfrågan skickas. Plan ber som standard om tillåtelse för filändringar och skalkommandon; det garanterar inte att inga ändringar sker. Avböj filändrande åtgärder och kommandon under de två svaren och jämför diffen före och efter. Verifiera påståenden efteråt med de fokuserade testerna eller tillfälliga experimenten som övningen beskriver. Använd en telefontimer för att mäta från att förfrågan skickas tills svaret är klart.