Project Baseline Reference
This reference describes the structure and format of project baselines, including the k5-baseline.yaml configuration file, ZIP archive structure, and API operations.
Baseline ZIP Archive Structure
A project baseline is distributed as a ZIP archive with the following structure:
baseline-name-VERSION.zip
├── k5-baseline.yaml # Baseline metadata and configuration (required)
├── k5-oml.yaml # OML configuration (required)
├── recipes/ # Recipes folder (optional)
│ ├── skills/ # Skills for implementation generation
│ │ └── *.md # Markdown files
│ ├── commands/ # Commands for prompt window
│ │ └── *.md # Markdown files
│ └── rules/ # Validation and enforcement rules
│ └── *.md # Markdown files
└── README.md # Documentation (optional)
The recipes tree may be named recipes/ or .recipes/; path mapping and baseFolder sync treat both the same.
File Requirements
- Required files:
k5-baseline.yaml,k5-oml.yaml - Optional files:
README.md, a recipes tree folder (recipes/or.recipes/) with any structure - Allowed extensions (root level):
.yaml,.yml,.txt,.md - Recipes folder: Any file types allowed under
recipes/or.recipes/ - Maximum size: 16 MB
Excluded Files
The following files are automatically excluded during processing:
- MacOS resource fork files (
._ *) __MACOSX/folders and their contents
k5-baseline.yaml Format
The k5-baseline.yaml file defines the baseline metadata and configuration.
Required Fields
id: "baseline-identifier" # Unique baseline identifier
version: "1.0.0" # Semantic version
name: "Baseline Display Name" # Human-readable name
Optional Fields
description: "Detailed description of the baseline"
tags:
- "domain-driven-design"
- "microservices"
icon: "Application" # Icon identifier
color: "#0f62fe" # Hex color code
Coding Assistant Preferences
codingAssistantPreferences maps each coding assistant id (for example cursor, bob, github) to an entry that controls how files from the baseline ZIP are copied into the project Git repository when the workbench syncs baseline content.
For each assistant, you must define one of the following (validation fails if both are missing):
| Mode | When to use |
|---|---|
baseFolder (string) | Copy only files that sit under a recipes or .recipes path segment in the archive; mirror the path below that segment into this repository-relative folder. |
mapping (non-empty array) | Fine-grained rules: select arbitrary paths in the archive and place them under specific target folders. When mapping is present, it is used exclusively and baseFolder is ignored for that assistant. |
Optional per-assistant field: label — display name for the assistant.
baseFolder example
codingAssistantPreferences:
bob:
baseFolder: "./.bob"
cursor:
baseFolder: "./.cursor"
github:
baseFolder: "./.github"
mapping rules
Each element of mapping is an object with:
| Field | Type | Description |
|---|---|---|
source | string (required) | Non-empty. Selects files in the baseline archive. Patterns match path suffixes relative to the ZIP root (a leading bundle folder in the archive does not need to appear in the pattern). recipes/... and .recipes/... are treated as equivalent for matching. |
target | string (required) | Non-empty. Repository-relative directory; matched files are written under it, preserving subpaths after the static part of the source pattern. Must not use .. to escape the repository root. |
overwrite | boolean (required) | If false, this rule does not replace a file already written to the same path by an earlier rule. If true, it can. |
source may use directory prefixes, glob patterns, extension filters (for example dir/*.yml, dir/**/*.yml), trailing dir/* for all files under a directory, and regular expressions written in slash form: /regex/.
mapping example
codingAssistantPreferences:
cursor:
label: "Cursor"
mapping:
- source: "recipes/skills/*"
target: ".cursor/skills"
overwrite: true
- source: ".recipes/common.rules/**/*.yml"
target: ".cursor/rules"
overwrite: true
For a narrative explanation of behavior, see Recipes — Coding assistant support.
Complete Example
id: "ddd-quarkus-baseline"
version: "1.3.2"
name: "Domain Service based on Quarkus"
description: "A baseline configuration for implementing a domain service based on Quarkus with domain-driven-design principles"
tags:
- "ddd"
- "quarkus"
- "domain-driven-design"
icon: "Application"
color: "#ca3131"
codingAssistantPreferences:
bob:
baseFolder: "./.bob"
k5-oml.yaml Format
The k5-oml.yaml file defines the OML configuration. See OML Configuration Reference for complete details.
Required Structure
id: "modeling-configuration-id"
version: "1.0.0"
name: "Configuration Name"
description: "Configuration description"
layers:
- id: "layer-id"
name: "Layer Name"
description: "Layer description"
systemDefinitions:
- id: "k5-oml-system"
version: "1.0.0"
profiles:
- id: "profile-id"
version: "1.0.0"
Design Recipe References
Optionally, k5-oml.yaml can list design recipes that extend the Design Assistant for projects created from this baseline. Each entry references a recipe uploaded in Admin Settings → Design recipes by id and version, in the same way as profile references.
designRecipes:
- id: "default-recipe"
version: "1.0.0"
- id: "archimate-design-recipe"
version: "1.0.1"
When a project uses this baseline, the linked design recipes load automatically in the Design Assistant. Upload the recipe bundles first, then add the references to k5-oml.yaml. For bundle structure and authoring, see the Design recipe reference.
Baseline Lifecycle States
| Status | Description | Allowed Operations |
|---|---|---|
DRAFT | Under development, can be modified | Upload new file, Download, Publish, Deprecate, Delete |
PUBLISHED | Released for use, immutable | Download, Deprecate |
DEPRECATED | No longer recommended | Download, Re-publish |
State Transitions
DRAFT ──────────> PUBLISHED ──────────> DEPRECATED
│ │ │
│ │ │
└───────────────────┴──────────────────────┘
(Delete only from DRAFT)
API Operations
Upload Baseline
Endpoint: POST /api/project-baselines
Request:
- Content-Type:
multipart/form-data - Field:
baselineFile(ZIP file, max 16 MB) - Allowed extensions:
.zip - Allowed MIME types:
application/zip,application/x-zip-compressed,application/octet-stream
Validation:
- ZIP must contain
k5-baseline.yamlandk5-oml.yaml - All referenced OML profiles must exist
- All referenced design recipes must exist
- Baseline ID + version combination must be unique (for new baselines)
- For updates: baseline must be in DRAFT status
Response: 201 Created
{
"baselineId": "ddd-quarkus-baseline",
"baselineVersion": "1.3.2",
"name": "Domain Service based on Quarkus",
"status": "DRAFT",
"description": "...",
"tags": ["ddd", "quarkus"],
"icon": "Application",
"color": "#ca3131"
}
List Baselines
Endpoint: GET /api/project-baselines
Query Parameters:
publishedBaselineOnly:true|false(filter for published baselines only)latestVersionOnly:true|false(show only latest version of each baseline)
Response: 200 OK
[
{
"baselineId": "ddd-quarkus-baseline",
"baselineVersion": "1.3.2",
"name": "Domain Service based on Quarkus",
"status": "PUBLISHED",
"k5Oml": { ... }
}
]
Get Baseline Metadata
Endpoint: GET /api/project-baselines/:baselineId/:version
Response: 200 OK
{
"baselineId": "ddd-quarkus-baseline",
"baselineVersion": "1.3.2",
"name": "Domain Service based on Quarkus",
"status": "PUBLISHED",
"k5Oml": {
"id": "ddd-quarkus-config",
"version": "1.0.0",
"layers": [...],
"profiles": [...]
}
}
Download Baseline
Endpoint: GET /api/project-baselines/:baselineId/:version/download
Authorization: Requires admin privileges
Response: 200 OK
- Content-Type:
application/zip - Content-Disposition:
attachment; filename="baseline-id-version.zip" - Body: ZIP file buffer
Update Baseline Status
Endpoint: PUT /api/project-baselines/:baselineId/:version/status
Authorization: Requires admin privileges
Request Body:
{
"status": "PUBLISHED"
}
Allowed Transitions:
DRAFT→PUBLISHEDDRAFT→DEPRECATEDPUBLISHED→DEPRECATEDDEPRECATED→PUBLISHED
Validation for Publishing:
- Baseline ZIP file must be valid
- All referenced OML profiles must exist and be published
- All referenced design recipes must exist
Response: 204 No Content
Delete Baseline
Endpoint: DELETE /api/project-baselines/:baselineId/:version
Authorization: Requires admin privileges
Restrictions:
- Only baselines in
DRAFTstatus can be deleted - Published and deprecated baselines cannot be deleted
Response: 204 No Content
Validation Rules
ZIP Archive Validation
- Required files present:
k5-baseline.yaml,k5-oml.yaml - File extensions (root level): Only
.yaml,.yml,.txt,.mdallowed - Recipes folder: Any file types allowed under
recipes/or.recipes/ - Size limit: Maximum 16 MB
- System files: MacOS resource forks and
__MACOSXfolders excluded
k5-baseline.yaml Validation
- Required fields:
id,version,namemust be present - Version format: Must follow semantic versioning
- Coding assistant preferences: If present, each assistant must define either a non-empty
mappingarray or a non-emptybaseFolderstring; eachmappingentry must include non-emptysourceandtargetstrings and a booleanoverwrite
k5-oml.yaml Validation
- Required fields:
id,version,name,layersmust be present - Profile references: All referenced profiles must exist in the system
- Design recipe references: All referenced design recipes must exist in the system
- System definitions: Must reference valid system definition IDs
Status Change Validation
- Publishing: All referenced profiles and design recipes must be available for use
- Deletion: Only
DRAFTbaselines can be deleted - Re-upload: Only
DRAFTbaselines can be re-uploaded
Error Codes
| Error | Description |
|---|---|
ProjectBaselineValidationError | ZIP structure or YAML content is invalid |
ProjectBaselineAlreadyExistsError | Baseline with same ID and version already exists |
ProjectBaselineNotFoundError | Baseline with specified ID and version not found |
ProjectBaselineStatusUpdateNotAllowedError | Status transition not allowed |
ProjectBaselineDeleteNotAllowedError | Deletion not allowed (not in DRAFT status) |
ProjectBaselineReferenceNotPublishedError | Referenced profile not published |
ProjectBaselineVersionIsLowerThanLatestError | New version is lower than existing latest version |
Best Practices
- Versioning: Use semantic versioning (MAJOR.MINOR.PATCH)
- Testing: Thoroughly test baselines in DRAFT before publishing
- Profile dependencies: Ensure all referenced profiles are published first
- Design recipe dependencies: Upload design recipes in Admin Settings before referencing them in
k5-oml.yaml - Documentation: Include comprehensive README.md in the ZIP
- Recipes organization: Structure recipes logically in subdirectories
- File naming: Use
k5-prefix for workbench-managed files - Size optimization: Keep ZIP archives under 16 MB
- Backward compatibility: Consider compatibility when creating new versions