Software Development Skills

Test fixture skill for E2E plugin tests. Should be discovered, copied, and removable by the plugin.

Before hand-building any reusable building block in a Jardis project — caching, scheduling, HTTP clients, queues or messaging, validation, logging, secrets, persistence, or DDD scaffolding such as a context registry or workflow engine — consult this catalog to check whether an installable Jardis package already provides it and recommend composer require instead of writing it yourself, never for project-specific business logic.

Driving a Jardis workspace headless through jardis mcp — Tools as actions vs Resources as read-only, the Workspace to Schema to Aggregate to Process to Build to Code-read workflow, the strategic-design surface (glossary, Steckbrief, planned BCs, Context-Map edges with the eight canonical DDD patterns, and the read-only drift check declared-vs-real coupling), the Sorte-A GUI-replacement pattern (OutputDir via updatedomainmanifest, code via code-file/code-tree resources, a new workspace means a new process), documented workspace-registry limits, and structured error envelopes (confirm flags, BUILDRUNNING/DRAFTEXISTS). Use when an AI must design, build, or inspect a Jardis domain without a browser.

Starting or orienting in a Jardis project — the master entry point that walks a developer or AI through the four lifecycle phases (package discovery, Schema.yaml authoring, strategic + Aggregate/Process design incl. Glossar/Steckbrief/Context Map, implementing generated code), names the concrete jardis ui/jardis build commands, and routes to every other skill in this bundle plus the two Builder-repo skills via a complete lookup table.

Phase-3 recipes and troubleshooting for Designer-generated code — Event transport via EventRouter.php (Kafka/RabbitMQ/Redis/HTTP-webhook/in-process), six recipes (VO in Hydrate, Domain Service, new Command/Query, Event to Kafka, Flow-DTO input.extends, Response shapes per operation), troubleshooting table (ClassVersion misses, lost overrides, R5 routing-safety, V6 cross-BC, listener exceptions).

Extending Jardis Designer-generated code with fachlogik — one Extensions/ directory per aggregate holds all developer-owned code (VOs, services, overrides, custom API fragments). Everything outside Extensions/ is regenerated every build. ClassVersion v{N} override mechanism, V1–V12 prohibitions, decision tree, seven implementation levels, event transport, DomainResponse construction, Phase-3 cookbook, troubleshooting.

Wiring Designer-generated Commands/Queries into a transport layer — bootstrap lifetime, 4-hop Api-Registry call chain, DomainResponse→transport mapping, error handling for HTTP / CLI / queue / worker.

ClassVersion resolution and Versionierungs-Modell for Designer-generated code — 7-stage lookup chain via LoadClassFromExtensions with segmentNames: ['', 'Platform'], baseline vs. versioned (v1, v2, ...) overrides, ClassVersionConfig setup, five Leitsätze (additiv vor Version, Version ändert Verhalten nie API, Datenbruch = neues Aggregat, Code-Rettung über Service-Schicht, one API surface per aggregate).

Workflow-Engine API used by FlowDesigner-generated Use-Case orchestrators — six routing statuses (ONSUCCESS / ONFAIL / ONTIMEOUT / ONSKIP / ONCANCEL / ONEVENT), WorkflowBuilder graph construction, handlerFactory Closure conventions, three opaque WorkflowContext slots (reference, response, exception), R5 routing-safety rules.

Non-negotiable Jardis architecture rules — five constitutional pillars, hexagonal dependency direction, Closure-Orchestrator pattern. Consult before authoring any new class or reviewing existing code.

Non-negotiable, stack-agnostic Jardis frontend review rules — component boundaries, state discipline, an e2e-heavy test pyramid, an accessibility minimum bar, and type-safety at the data boundary; the measuring stick a frontend architect or reviewer holds a UI plan or component against. Consult before reviewing any frontend plan or authoring a frontend component. The concrete UI framework arrives via the assignment, never from this constitution.

Reference catalogue of the ten design patterns used in Jardis (Facade, Strategy, Adapter, Value Object, Factory, Repository, Decorator, Priority-Based Layers, Chain of Responsibility, Lazy Initialization). Consult before introducing a pattern.

Jardis testing rules — Integration over Unit, mock only at port boundaries, mandatory process for failing tests (no assertion weakening), Phase-3 test patterns for generated Domain code.

Author a Schema.yaml from scratch for the Jardis Designer — from a plain-text domain idea, draft tables (snakecase plural), columns with realistic types, primary keys, indexes (primary/unique/index), optional foreign keys. Output matches the DB-export format the Designer's importer parses.