36 berichten getagd met "Tutorial series"

The first three parts of this series set up the registers, the files, and a public catalog for Dutch open-government data. Conduction also has a three-tutorial pipeline that teaches the same three apps from the ground up, end to end, on the canonical Pet Store sample:

1. Model and manage your data with OpenRegister — registers, schemas, relations, objects, search, versioning, permissions.
2. Pull external data into your register with OpenConnector — a source, a mapping, and a scheduled synchronisation.
3. Publish a public catalog with OpenCatalogi — scope a catalog, publish with a date rule, expose a DCAT-AP-NL feed.

This capstone is the Woo & DCAT overlay on that pipeline. Rather than repeat the mechanics, it points you at each deep tutorial and then layers the open-government specifics on top: the canonical registers you import instead of hand-building, the open-data source you map to a Dataset, and the DCAT-AP-NL feed that national portals harvest. The shape is identical to the Pet Store chain — grab data from a source, and publish it on a catalog — only the domain changes.

In Part 1 you imported a DCAT register for open data. In this tutorial you make its datasets findable: you scope a catalog to the register, set one date field that controls visibility, and expose the catalog as a DCAT-AP-NL feed. National portals like data.overheid.nl harvest that feed.

In part 5 you started Hydra by hand: build the images, run the supervisor, label an issue. That is the right way to learn Hydra, but it is not how it runs day to day. In production nobody runs hydra-supervisor.sh from a terminal. Instead the forge itself triggers the pipeline when an issue is labelled, pulls pre-built images from a registry, and runs each stage as a CI job. This part explains that path, and the three deployment models behind it.

Most teams already write down what they are going to build. They open a ticket: "As a user I want a search box, so that I can find pets quickly." That sentence has served software teams for twenty years. At Conduction we write specs instead. The reason is simple: the developer reading the ticket is now an LLM, not a colleague, and an LLM needs a different kind of brief. This opener explains why, before the rest of the series gets into the how.

A spec tells you what one feature must do. But "build a search box" leaves a hundred questions unanswered that have nothing to do with search. Which data layer? Vue 2 or Vue 3? Where do modals live? Which licence header? Answering those per spec would be madness, and an AI would answer them differently every time. That is what ADRs are for. They are the standing context that every spec is built on top of. This part explains what they are, how they are written, and how Conduction splits them across the fleet.

In Part 1 you learned that a scenario describes behaviour in GIVEN / WHEN / THEN form. In Part 2 you wrote one. This part closes the loop. A scenario is a test you have not run yet, and OpenSpec gives you a mechanical way to prove that every scenario in a spec is exercised by a real browser test. The @e2e annotation and the gate that enforces it are what turn "write a spec" into a safe sandbox for AI. They are also the single biggest thing that separates spec coding from vibe coding.

Let op — dit is een optionele, situationele tutorial. De meeste developers zullen nooit een retrofit hoeven draaien. Het dagelijkse werk in een Conduction-app — changes schrijven, tasks implementeren, PRs openen — raakt geen van de commando's hieronder. Je kunt Deel 1 + 2 afronden en direct doorgaan naar de Hydra-leerlijn of de Claude skills-leerlijn zonder iets te missen.

Dit deel is alleen relevant in één specifiek geval: een oudere Conduction-app moet alsnog onder de huidige OpenSpec-conventie gebracht worden. Een klein aantal van onze apps is gebouwd voordat openspec/specs/ en de @spec-tag-conventie bestonden — ze hebben werkende code, maar geen specs en geen annotaties die vanuit code terug wijzen naar requirements. Als zo'n app ooit in lijn met de conventie gebracht moet worden, is dit de playbook ervoor. We lopen de retrofit-playbook van begin tot eind door.

By Part 6 your PetStore app is shipped and integrated. Along the way the manifest renderer mounted a handful of nc-vue components for you (CnAppRoot, CnPageRenderer, CnIndexPage, CnDetailPage, CnDashboardPage, CnObjectSidebar, CnMarkdownEditor) and Part 5b walked through the dashboard widget vocabulary. The lib ships ~70 Cn* components and a dozen composables. Part 7 is the capability tour: which component to reach for when, what the composable layer does for you, and how the whole library fits together so you stop guessing.

This is a tour, not a reference. The full prop tables live on nextcloud-vue.conduction.nl. Use Part 7 to build the mental map; use the lib docs to look up signatures.

A 45-minute tutorial that gives your PetStore app a documentation site. Hosted from your own Codeberg or GitHub repo via the central documentation workflow, illustrated with abstract screen mocks that compose from design tokens, and brought to life with real screenshots that Playwright captures from your running app. By the end, every push to development rebuilds and republishes.

Een werkend Conduction-workstation heeft een specifieke combinatie aan tools nodig: Claude Code, Docker, een lokaal draaiende Nextcloud, Playwright, een handvol globale Claude-instellingen en hooks, en een werkende gh CLI. Nieuwe developers verliezen vaak hun eerste dag (of twee) aan setup-puzzels die wij intern al opgelost hebben. Deze leerlijn van zes delen brengt je in één avond van een schone laptop naar een werkend workstation. Deel 1 — dit deel — beantwoordt de vraag wat installeer je, en waarom voor je door installers gaat klikken.

Dit is het deel met de meeste installatie-commando's. WSL2, Docker Desktop, VS Code met de juiste extensies, de language-runtimes (Node, PHP, Composer), de CLI's (gh, OpenSpec) en de Playwright Chromium-binary. Aan het einde van Deel 2 heb je een werkend dev-workstation — alleen Claude Code is nog niet aangesloten. Dat is Deel 3.

Met de runtimes uit Deel 2 op zijn plek wordt het tijd voor de AI-pair-programmer waar we daadwerkelijk mee werken: Claude Code. Dit deel behandelt de installatie, het inloggen, en — het stuk dat je niet moet overslaan — de verplichte global settings en safety hooks die voorkomen dat Claude zonder jouw goedkeuring destructieve shell-commando's draait. Kort deel, belangrijk deel.

MCP — Model Context Protocol — is de standaard-interface waarmee Claude Code naar externe tools praat. Binnen een Conduction-project betekent dat in de praktijk twee dingen: een Playwright-browserpool (browser-1 … browser-7) voor de testing-skills, en de OpenRegister MCP-server voor directe toegang tot je lokale Conduction-datalaag. Een workstation is pas echt af als minstens de browserpool via .mcp.json in je project-root is aangesloten. Dit deel behandelt dat; de OpenRegister MCP-server staat in een eigen tutorial — daar linken we onderaan naar.

Een workstation zonder Nextcloud is een halve workstation. Bijna elke andere tutorial in de academy gaat ervan uit dat je er een hebt draaien op localhost:8080. Het goede nieuws: er is al een speciale tutorial die dit van begin tot eind behandelt. Deze module is een korte brug die uitlegt waarom je het nu doet, welke Conduction-apps je installeert zodra het draait, en hoe dit deel aansluit op de rest van de serie.

Je workstation is klaar. WSL2, Docker, VS Code met de juiste extensies, Claude Code met de veiligheidshooks actief, de MCP-browserpool aangesloten, Nextcloud lokaal draaiend met de apps die je nodig hebt. Sta er even bij stil — vroeger verloren de meeste nieuwe Conduction-developers er een of twee dagen aan; jij hebt het in één avond gedaan. Dit laatste deel is een korte kaart van de volgende tutorials, gegroepeerd naar wat voor werk je gaat doen.

This is Part 5 of the nine-part app-building tutorial series. Parts 1–4 got you a working app: scaffold, schemas + manifest, schema-driven Calendar integration, and a custom Care tab. Part 5 is the "now what": the v2.7.0 manifest features Parts 1–4 deliberately skipped so the learning curve stayed gentle. You don't need any of them to ship PetStore, but the moment your app needs a public form, a wiki, an admin-only listing, or a markdown editor inside a form, they save you from another round of hand-rolled Vue.

Three principles run through every feature in this part: schema-driven (no per-page Vue), type-safe (the manifest schema validates every shape before runtime), and fleet-portable (the same JSON works in every Conduction app and gets lib upgrades for free).

This is Part 6 of the nine-part app-building tutorial series. Part 4 packaged the app and put it on the Conduction store; this part makes it talk to the rest of the workspace: three integration patterns layered from least to most invasive. By the end your orders know who their supplier is, every order shows the right care guide from xWiki, and a needs_followup order automatically opens a maintenance page in xWiki that flips the order back to delivered when the page is marked resolved.

The point isn't the specific integrations, it's the pattern. Cross-register reads are how Conduction apps share data without coupling. The OpenConnector source-and-synchronisation pattern is how you absorb data from anywhere into your own register. The webhook endpoint pattern is how external systems push state back. Once you've wired all three, you've covered the integration vocabulary the rest of the catalogue uses.

Part 4 of the nine-part app-building tutorial series. Part 3 made orders appear in NC Calendar with one schema annotation. Part 4 brings external knowledge, category-specific care advice, husbandry notes, feeding tips, from xWiki into the pet detail sidebar via a care_guide OpenRegister schema. Then we package the app and ship it.

External knowledge integration is the canonical case for OpenConnector. Pull data from a system you don't own (xWiki here, but the same applies to Confluence, Notion, SharePoint, Decos, Mendix), surface it inside Nextcloud-native UI without making the user context-switch.

This is Part 3 of the nine-part app-building tutorial series. Part 2 wired the pet and order schemas. Part 3 makes those orders appear in every user's Nextcloud Calendar (without writing a controller, an event listener, or any per-app calendar glue).

The trick: OpenRegister already ships an ICalendarProvider (RegisterCalendarProvider) that exposes any schema with a calendarProvider block as a virtual calendar. You declare the block on the order schema. NC Calendar shows the events. That's the whole story.

Claude Skills zijn het mechanisme waarmee je Claude Code uitbreidt met herbruikbare, gespecialiseerde gedragingen. Denk aan Conductions eigen /review-pr, /opsx-new of de hele hydra-gate-* familie: stuk voor stuk skills. Dit eerste deel legt in tien minuten uit wát een skill is, hoe hij geactiveerd wordt, en wanneer je beter géén skill maakt. Het is deel 1 van een leerlijn van vier; aan het eind sta je klaar om er in deel 2 zelf een te schrijven — en in deel 3 introduceren we het 7-level maturity-framework waarmee je een skill van "voelt goed" naar "gemeten goed" brengt (deel 4 gaat door op L6 en L7).

In deel 1 zag je wát een skill is. In dit deel ga je er zélf eentje schrijven: een werkende git-status-summary skill die een leesbare samenvatting maakt van de huidige working tree. Aan het eind staat hij in je ~/.claude/skills/-folder, kun je hem aanroepen via /git-status-summary, en weet je hoe je hem deelt met je team.

Je hebt nu een werkende skill — maar werkt hij ook écht goed? En blijft hij goed werken als Claude zelf een upgrade krijgt of als je de skill aanpast? Dit derde, optionele deel laat zien hoe je een skill systematisch evalueert: test-scenario's, trigger-tests, een baseline-meting, en de eval-runner die /skill-creator voor je inricht. Dit is de stap van Maturity Level 4 ("voelt goed") naar Level 5 ("gemeten goed").

In deel 3 bracht je een skill van "voelt goed" naar "gemeten goed" — Maturity Level 5. Voor de meeste skills is dat genoeg. Maar voor een handvol skills die je dagelijks gebruikt of die andere skills aansturen, wil je verder: een skill die leert van zijn eigen executies (L6), en een skill die andere agents aanstuurt in een grotere workflow (L7). Dit vierde deel laat zien hoe je daar komt — én hoe je met het Hydra-dashboard je hele skill-library tegelijk op maturity bewaakt.

This is Part 2 of the nine-part app-building tutorial series. Part 1 left you with an empty app shell, a chassis, no data. Part 2 fills the chassis: three schemas (modelled on the OpenAPI Pet Store), a manifest, and the same five Cn* pages drive every list, every detail view, every dashboard with the schema as the single source of truth.

The shape we keep saying "this saves you code" finally has numbers behind it: ~200 lines of hand-rolled Vue collapse to three.

Hydra is Conductions interne agentic CI/CD-platform: een fabriek die OpenSpec-voorstellen omzet in gereviewde, geteste code op een feature branch. Deze module legt in tien minuten uit wát Hydra is, waaróm het bestaat, en hoe het past binnen onze app-fabriek. Het is het eerste deel van een leerlijn van zes; aan het eind sta je klaar voor deel 2 over de drie pipelines.

In deel 1 zag je dat Hydra vier personas heeft. In dit deel kijken we naar de pipeline: hoe die personas na elkaar werken aan één issue, welke labels de overgangen markeren, en wanneer de pijplijn afslaat naar needs-input. Aan het eind weet je het label-state-machine van Hydra van buiten en kun je een issue terugleiden naar de juiste fase als hij ergens vastloopt.

In deel 2 zag je dat de drie personas worden aangevuld door mechanische quality gates — checks die deterministisch slagen of falen, zonder AI in de loop. Dit deel legt uit welke gates we hebben, waarom ze mechanisch zijn, en hoe je omgaat met de uitzondering: de fout positief.

In de vorige delen ging het over wat Hydra doet. Dit deel gaat over hoe: de skills die de personas hun werk laten doen. Aan het eind weet je welke skills de automatische pipeline (de "Hydra-fabriek") draait en welke je als mens zelf aanroept, ken je de vijf families, en kun je inschatten wanneer een nieuwe skill de moeite waard is.

In de eerste vier delen ging het om concept, pipelines, gates en skills. Tijd om te draaien. In dit deel start je een complete Hydra-run op een doel-app, met aandacht voor de praktische valkuilen: tokens, images, en — als je met meerdere devs aan dezelfde repo's werkt — de HYDRA_LABEL_PREFIX-truc.

In deel 5 stond de pijplijn. Nu het laatste deel: wat doe je als hij niet groen wordt? Dit deel geeft je de keuzeboom — geordend van goedkoopste interventie naar duurste — en de patronen waarmee je needs-input-issues weer in beweging krijgt.

OpenSpec is een lichtgewicht framework voor spec-driven development: eerst opschrijven wat een feature moet doen, dan pas code schrijven. In deze module van twaalf minuten leer je wat OpenSpec is, welke begrippen erin zitten, en waarom we het bij Conduction onder vrijwel elk project gebruiken. Aan het eind sta je klaar voor deel 2, waarin je je eerste change daadwerkelijk schrijft.

Tijd om OpenSpec aan het werk te zien. In dit deel maak je in een Conduction-project je eerste echte change — van leeg mapje, via een spec-delta met requirement en scenario, naar een gevalideerd voorstel klaar voor implementatie. We doen dat met de Claude Code-skills /opsx-new en /opsx-ff.

This is Part 1 of the app-building tutorial series, the hands-on chassis lap. If you haven't read Part 0: Three paths, one curriculum yet, that's the orientation that explains why we build on this stack rather than raw Nextcloud, and how the manifest and @conduction/nextcloud-vue work as two intertwined surfaces. Part 1 picks up after that decision is made.

You'll build PetStore, a Nextcloud app on top of the OpenAPI Pet Store domain (pets, orders, categories, tags) on the full Conduction Nextcloud stack. The end product: add pets to the store, place orders, see order ship-dates in your Nextcloud Calendar, and surface category-specific care guides from xWiki right next to each pet. Every piece reuses what @conduction/nextcloud-vue and OpenRegister already give you for free.

In Part 1 you scaffold the app, rename it, build it, and see the canonical app chassis on screen. No data, no integrations yet. We get the bones right first.

Een Woo-publicatie zonder bestanden is metadata zonder bewijs. In deze tutorial koppel je documenten aan een Woo-publicatie via vier upload-modes: één bestand, meerdere bestanden tegelijk, en grote bestanden in chunks. Plus publiceren, depubliceren en opruimen.

De Wet open overheid (Woo) verplicht overheden om documenten openbaar te maken in elf informatiecategorieën. OpenRegister levert het opslagmodel daarvoor. In deze tutorial importeer je het canonieke Woo-register, met alle TOOI-categorieën, in een paar minuten.

This is Part 0 of the nine-part app-building tutorial series, the orientation lap. Before scaffolds, schemas, or manifests, the most useful thing we can hand a new developer is an honest map of the three ways Conduction apps actually get built, what each one costs, and what each one gives back. The rest of the series picks one path and shows the receipts. Part 0 explains why.

A second thing matters from minute one: the manifest system and the @conduction/nextcloud-vue component library are two different surfaces. The manifest is the declarative what, a single manifest.json that describes navigation, pages, configuration. nextcloud-vue is the rendering how, the Cn* components the manifest dispatches to (CnAppRoot, CnPageRenderer, CnIndexPage, CnDetailPage, CnDashboardPage, and the rest). They are technically separable. They are also so intertwined in practice that the rest of this series teaches them together, and every lesson names which surface it is touching.

The series uses the OpenAPI Pet Store as the running example: pets, orders, categories, the same entities every API developer has met before. It's the canonical sample domain across the Conduction academy. By the end of the series you have a working PetStore app on the Conduction stack and the mental model to build your own real app on the same patterns.