$ bausteinsicht init
Initialized Bausteinsicht project:
- architecture.jsonc
- template.drawio
- architecture.drawio
- .bausteinsicht-sync
$ bausteinsicht init --format json
{"files":["architecture.jsonc","template.drawio","architecture.drawio",".bausteinsicht-sync"],"success":true}
CLI Specification
See Use Cases for the functional overview of all CLI commands.
Command Overview
| Command | Description | Status |
|---|---|---|
|
Initialize a new architecture model with default specification, sample model, and template |
Implemented |
|
Bidirectional synchronization between model and draw.io diagrams |
Implemented |
|
Validate the architecture model for consistency and report errors/warnings |
Implemented |
|
Watch mode — continuously sync on file changes |
Implemented |
|
Add a new element to the model (LLM-friendly) |
Implemented |
|
Add a new relationship to the model (LLM-friendly) |
Implemented |
|
Create a new view or modify a view’s include list (LLM-friendly) |
Implemented |
|
Add element or relationship types to the specification (LLM-friendly) |
Implemented |
|
Export diagram views to PNG or SVG using the draw.io CLI |
Implemented |
|
Export element attributes as AsciiDoc or Markdown table per view |
Implemented |
|
Export views as PlantUML C4 or Mermaid C4 text diagrams |
Implemented |
|
Export dynamic views as PlantUML or Mermaid sequence diagrams |
Implemented |
|
Check the model against the architectural constraints defined in it |
Implemented |
|
Compute an architecture health score (completeness, conformance, complexity) |
Implemented |
|
Analyze the relationship graph: cycles, centrality, dependency depth |
Implemented |
|
Flag elements that are old (beyond a threshold) and carry neither a lifecycle status nor an ADR link |
Implemented |
|
List elements by lifecycle status |
Implemented |
|
Full-text search over elements, relationships, and views |
Implemented |
|
Show all details of a single element |
Implemented |
|
Save, list, diff, restore, and delete versioned model snapshots |
Implemented |
|
Compare the model’s as-is and to-be sections |
Implemented |
|
Generate an architecture changelog between two versions |
Implemented |
|
Import a model from Structurizr DSL or LikeC4 |
Implemented |
|
Generate a draw.io template from the specification |
Implemented |
|
Compute hierarchical layout and write positions back to draw.io |
Implemented |
|
Apply/list/remove metric heatmap overlays on the diagram |
Implemented |
|
Interactive shell for editing the model |
Implemented |
|
List and show Architecture Decision Records linked to elements |
Implemented |
|
List, merge, and validate multi-model workspaces |
Implemented |
|
Generate the JSON Schema from the Go model types |
Implemented |
|
Display version number |
Implemented |
Global Flags
These flags are available on all subcommands via persistent flags on the root command.
| Flag | Description | Default |
|---|---|---|
|
Output format. |
|
|
Path to the model file ( |
auto-detect |
|
Path to a custom draw.io template file. Must have a |
built-in template |
|
Enable verbose output. Verbose messages are written to stderr so they do not interfere with JSON output on stdout. |
|
|
Note
|
--version is a root-level flag only, not a global flag. It is used as bausteinsicht --version and prints the version string.
|
Auto-Detection Behavior
When --model is not specified, all commands that require a model file invoke auto-detection:
-
The current working directory is scanned for files matching
*.jsonc. -
If exactly one
.jsoncfile is found, it is used. -
If more than one
.jsoncfile is found, the command aborts with exit code 2 and the messagemultiple .jsonc files in <dir> — use --model to select one. It does not silently pick one, because the tool mutates files and synchronizes — operating on the wrong model must never happen by accident. -
If no
.jsoncfile is found, the command exits with code 2 and an error message.
Exit Codes
| Code | Meaning |
|---|---|
0 |
Success |
1 |
Validation error, sync conflict, duplicate element/relationship, or partial export failure |
2 |
File not found, I/O error, invalid arguments, or missing prerequisites |
Detailed Command Specifications
bausteinsicht init
Initializes a new Bausteinsicht project in the current directory by creating a sample model, a default template, an initial draw.io diagram, and the sync state file.
Flags:
-
--generate-template— Generate the template from the model’s specification instead of writing the built-in default template.
Created files:
-
architecture.jsonc— sample architecture model -
template.drawio— default draw.io template -
architecture.drawio— initial diagram generated via forward sync -
.bausteinsicht-sync— sync state file
Behavior:
-
If any of the four files already exist, the command aborts with exit code 2.
-
After writing the model and template, an initial forward sync is performed to generate the draw.io diagram.
-
A page is created for each view defined in the sample model.
Exit codes:
-
0— project initialized successfully -
2— file already exists, or I/O error
Example:
bausteinsicht validate
Validates the architecture model file for consistency. Reports both errors and warnings.
Flags: No command-specific flags. Uses global flags only.
Behavior:
-
Loads the model (via
--modelor auto-detection). -
Runs validation checks including referential integrity and model consistency.
-
In
--verbosemode, prints element/relationship/view counts to stderr before validation. -
Warnings are printed with
WARNING:prefix; errors withERROR:prefix.
JSON output structure:
{
"valid": true,
"errors": [],
"warnings": [
{"path": "relationships[0]", "message": "..."}
]
}
Exit codes:
-
0— model is valid (may include warnings) -
1— validation errors found -
2— model file not found or cannot be loaded
Example:
$ bausteinsicht validate
Model is valid.
$ bausteinsicht validate --model my-arch.jsonc --verbose
Validating model: my-arch.jsonc
5 elements, 3 relationships, 2 views
Model is valid.
$ bausteinsicht validate --format json
{
"valid": true,
"errors": [],
"warnings": []
}
bausteinsicht sync
Runs one bidirectional synchronization cycle between the architecture model and the draw.io diagram.
Flags:
-
--relayout— Re-apply auto-layout to all view pages, resetting element positions to the layout engine’s computed positions. Without this flag, existing element positions are preserved. -
--mermaid— Also write Mermaid diagrams of the views to a Markdown file after syncing. -
--mermaid-output <path>— Output file for the Mermaid diagrams (defaultarchitecture.md). Implies--mermaid.
Behavior:
-
Loads the model, draw.io document, sync state, and template.
-
Validates the model before syncing. If validation fails, the sync is aborted with exit code 1.
-
If the draw.io file is missing or has no diagram pages, it is recreated from the template and sync state is reset.
-
Pages are created for new views and orphaned pages (views removed from model) are deleted.
-
Forward sync propagates model changes to draw.io; reverse sync propagates draw.io changes back to the model.
-
Conflicts are resolved with model wins strategy.
-
Model saves preserve JSONC comments and key ordering when possible (patch save), falling back to full save for structural changes.
Derived file paths: The draw.io file and sync state file paths are derived from the model file location:
-
<model-dir>/architecture.drawio -
<model-dir>/.bausteinsicht-sync
JSON output structure:
{
"forward_added": 2,
"forward_updated": 1,
"forward_deleted": 0,
"reverse_added": 0,
"reverse_updated": 0,
"reverse_deleted": 0,
"conflicts": 0
}
Exit codes:
-
0— sync completed without conflicts -
1— sync completed but conflicts were detected (resolved with model wins), or model validation failed -
2— file not found or I/O error
Example:
$ bausteinsicht sync
Forward (model -> draw.io): 3 added, 0 updated, 0 deleted
$ bausteinsicht sync --verbose
Syncing model: architecture.jsonc
5 elements, 3 relationships, 2 views
Forward sync: 2 elements created, 1 updated, 0 deleted; 1 connectors created, 0 updated, 0 deleted
Already in sync. No changes.
$ bausteinsicht sync --format json
{
"forward_added": 0,
"forward_updated": 0,
"forward_deleted": 0,
"reverse_added": 0,
"reverse_updated": 0,
"reverse_deleted": 0,
"conflicts": 0
}
bausteinsicht watch
Watches the model and draw.io files for changes and automatically runs a sync cycle on each detected change.
Flags:
-
--mermaid— Also write Mermaid diagrams of the views to a Markdown file after each sync. -
--mermaid-output <path>— Output file for the Mermaid diagrams (defaultarchitecture.md). Implies--mermaid.
Behavior:
-
Loads the model path (via
--modelor auto-detection) and derives the draw.io path. -
Both files must exist before the watcher starts (exit code 2 otherwise).
-
Uses file system notifications with debouncing to detect changes.
-
On each change, runs a full sync cycle (same logic as
bausteinsicht sync). -
Blocks until
SIGINTorSIGTERMis received, then stops gracefully. -
The watcher suppresses sync-triggered file events to avoid infinite loops.
Exit codes:
-
0— watcher stopped gracefully via signal -
2— model or draw.io file not found, or watcher creation failed
Example:
$ bausteinsicht watch
Watching architecture.jsonc and architecture.drawio...
[14:32:05] Sync triggered by architecture.jsonc
Forward (model -> draw.io): 1 added, 0 updated, 0 deleted
^CStopped watching.
$ bausteinsicht watch --model path/to/model.jsonc
Watching path/to/model.jsonc and path/to/architecture.drawio...
bausteinsicht add element
Adds a new element to the architecture model. Designed for LLM-driven workflows.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Unique identifier for the element. Must match |
Yes |
— |
|
Element kind as defined in the model’s specification section. |
Yes |
— |
|
Display title for the element. Must not be empty. |
Yes |
— |
|
Parent element ID in dot notation (e.g., |
No |
(top-level) |
|
Technology description for the element. |
No |
(empty) |
|
Element description. |
No |
(empty) |
Behavior:
-
Validates the ID format, kind against the model specification, and parent existence.
-
Checks for duplicate elements at the target level.
-
Uses comment-preserving insertion to update the JSONC file, falling back to full save if patching fails.
-
The full element ID is
<parent>.<id>when a parent is specified, or just<id>at the top level.
Exit codes:
-
0— element added successfully -
1— invalid ID, unknown kind, parent not found, parent is not a container, or duplicate element -
2— model file not found or I/O error
Example:
$ bausteinsicht add element --id api --kind component --title "REST API" \
--parent webshop --technology "Go/Gin"
Added element 'webshop.api' (kind: component) to model.
$ bausteinsicht add element --id customer-portal --kind system --title "Customer Portal" \
--format json
{"id":"customer-portal","kind":"system","title":"Customer Portal"}
bausteinsicht add relationship
Adds a new relationship between two existing elements. Designed for LLM-driven workflows.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Source element in dot notation (e.g., |
Yes |
— |
|
Target element in dot notation (e.g., |
Yes |
— |
|
Relationship label displayed on the connector. |
No |
(empty) |
|
Relationship kind as defined in the model’s specification section. |
No |
(empty) |
|
Relationship description. |
No |
(empty) |
Behavior:
-
Validates that both
--fromand--toelements exist in the model. -
If
--kindis specified, validates it against the model’s specification. -
Checks for duplicate relationships (same from, to, and kind combination).
-
Uses comment-preserving array append to update the JSONC file, falling back to full save if patching fails.
Exit codes:
-
0— relationship added successfully -
1— element not found, unknown kind, or duplicate relationship -
2— model file not found or I/O error
Example:
$ bausteinsicht add relationship --from webshop.api --to webshop.db \
--label "reads/writes" --kind uses
Added relationship: webshop.api -> webshop.db (reads/writes)
$ bausteinsicht add relationship --from webshop.api --to webshop.db --format json
{
"from": "webshop.api",
"to": "webshop.db"
}
bausteinsicht add view
Creates a new view or modifies an existing view’s include list. Designed for LLM-driven workflows to dynamically filter architecture diagrams.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Parent element ID to set the view’s scope (drill-down level). |
No |
(none) |
|
Element to include in the view (repeatable, e.g., |
No |
(empty) |
|
View title (display name) (required for new views). |
No |
(empty) |
|
View description. |
No |
(empty) |
Behavior:
-
For new views: requires
--title; creates view with all specified fields. -
For existing views: merges fields:
-
--title,--scope,--descriptionupdate respective fields (if specified) -
--includeelements are added to existing include list (deduplicated)
-
-
Validates that scope element exists (if specified).
-
Validates that all include elements exist (if specified, excluding wildcard patterns).
-
Uses comment-preserving insertion to update the JSONC file.
Exit codes:
-
0— view added or updated successfully -
1— scope or include element not found, or missing title for new view -
2— model file not found or I/O error
Example:
# Create a new system context view
$ bausteinsicht add view context \
--include system external_system user \
--title "System Context"
View 'context' added to model
Title: System Context
Includes: [system external_system user]
# Create a nested container view
$ bausteinsicht add view containers \
--scope system \
--include "system.*" \
--title "Containers"
View 'containers' added to model
Title: Containers
Scope: system
Includes: [system.*]
# Merge: add element to existing view's include list
$ bausteinsicht add view containers --include system.logging
View 'containers' added to model
Includes: [system.* system.logging]
# Merge: update title without changing include
$ bausteinsicht add view containers --title "Updated Containers"
View 'containers' added to model
Title: Updated Containers
# JSON output
$ bausteinsicht add view context --title "System Context" --format json
{
"view_key": "context",
"title": "System Context",
"scope": "",
"include": ["system", "external_system", "user"]
}
bausteinsicht add specification
Adds new element or relationship types to the model’s specification. Enables definition of custom architecture notations.
Add Element Type
Adds a new element kind to the specification.
Command: bausteinsicht add specification element <key>
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Display notation/name for this element type (e.g., "Custom Component"). |
Yes |
— |
|
Description of this element type. |
No |
(empty) |
|
Whether this element can contain child elements. |
No |
false |
Exit codes:
-
0— element type added successfully -
1— invalid key format or duplicate element type -
2— model file not found or I/O error
Example:
$ bausteinsicht add specification element custom_box \
--notation "Custom Component" \
--description "A custom element type" \
--container
Element type 'custom_box' added to specification
Notation: Custom Component
Description: A custom element type
Container: yes
$ bausteinsicht add specification element data_store \
--notation "Data Store" --container --format json
{
"key": "data_store",
"notation": "Data Store",
"container": true
}
Add Relationship Type
Adds a new relationship kind to the specification.
Command: bausteinsicht add specification relationship <key>
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Display notation/label for this relationship type (e.g., "calls"). |
Yes |
— |
|
Description of this relationship type. |
No |
(empty) |
|
Whether this relationship is displayed as a dashed line. |
No |
false |
Exit codes:
-
0— relationship type added successfully -
1— invalid key format or duplicate relationship type -
2— model file not found or I/O error
Example:
$ bausteinsicht add specification relationship depends_on \
--notation "depends on" \
--dashed
Relationship type 'depends_on' added to specification
Notation: depends on
Style: dashed
$ bausteinsicht add specification relationship async_call \
--notation "calls (async)" --format json
{
"key": "async_call",
"notation": "calls (async)",
"dashed": false
}
bausteinsicht export
Exports draw.io diagram views to image files (PNG or SVG) using the draw.io CLI.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Image format for export: |
No |
|
|
Export only a specific view by its key. When omitted, all views are exported. |
No |
(all views) |
|
Output directory for exported files. |
No |
|
|
Export scale factor (e.g. |
No |
|
|
Embed the draw.io XML source in the exported image file. |
No |
|
Behavior:
-
Loads the model and draw.io document to determine which pages to export.
-
Detects the draw.io CLI binary automatically. Exits with code 2 if not found.
-
Creates the output directory if it does not exist.
-
Output files are named
architecture-<view-key>.<format>(e.g.,architecture-context.png). -
Each view page is exported individually; partial failures are reported.
JSON output structure (the errors array is present only on partial failure):
{
"files": ["architecture-context.png", "architecture-container.png"],
"success": true
}
Exit codes:
-
0— all views exported successfully -
1— one or more exports failed (partial failure) -
2— unsupported format, model/diagram not found, draw.io CLI not available, or no views to export
Example:
$ bausteinsicht export
Exported: ./context.png
Exported: ./container.png
$ bausteinsicht export --image-format svg --output docs/images --view context
Exported: docs/images/context.svg
$ bausteinsicht export --format json --embed-diagram
{
"files": ["./context.png"],
"errors": [],
"success": true
}
bausteinsicht export-table
Exports element attributes as an AsciiDoc or Markdown table per view or as a combined table across all views.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Export only a specific view by its key. When omitted, all views are exported. |
No |
(all views) |
|
Table output format: |
No |
|
|
Output directory for exported files. When omitted, the table is written to stdout. |
No |
(stdout) |
|
Export a single combined table with elements from all views, deduplicated. |
No |
|
Behavior:
-
Loads the model and resolves view elements.
-
For each view, generates a table with columns: ID, Kind, Title, Technology, Description.
-
Elements are sorted alphabetically by ID within each table.
-
Without
--output, the table(s) are written to stdout. With--output <dir>, files are written there and the output filenames depend on the selection:-
A single view (
--view <key>) →<view-key>-elements.adoc(or.md). -
All views, no
--combined→ one fileall-views-elements.adoc(or.md) covering every view. -
--combined→ one deduplicated fileelements.adoc(or.md).
-
-
Creates the output directory if it does not exist.
JSON output structure — --format json emits an array of element rows (not a file list):
[
{ "id": "customer", "title": "Customer", "kind": "actor", "description": "..." },
{ "id": "webshop.api", "title": "REST API", "kind": "container", "technology": "Go", "description": "..." }
]
Exit codes:
-
0— table(s) exported successfully -
1— one or more exports failed (partial failure) -
2— model file not found, invalid format, or no views to export
Example:
$ bausteinsicht export-table --view context # writes to stdout
=== System Context
...
$ bausteinsicht export-table --table-format md --output docs/tables --view context
Exported: docs/tables/context-elements.md
$ bausteinsicht export-table --combined --output docs/tables
Exported: docs/tables/elements.adoc
$ bausteinsicht export-table --view context --format json
[
{ "id": "customer", "title": "Customer", "kind": "actor", "description": "..." }
]
bausteinsicht export-diagram
Exports views as text diagrams in one of several formats (C4-PlantUML, Mermaid, Graphviz DOT, D2, standalone HTML, or Structurizr DSL).
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Export only a specific view by its key. When omitted, all views are exported. Not supported with |
No |
(all views) |
|
Diagram output format: |
No |
|
|
Output directory for exported files. When omitted, the diagram is written to stdout. |
No |
(stdout) |
Behavior:
-
Loads the model and resolves view elements and relationships.
-
Auto-detects the C4 level (Context, Container, or Component) from the view content.
-
Generates diagram source in the requested format. C4-PlantUML uses the stdlib include syntax (
!include <C4/C4_Context>, etc.). -
Relationships are filtered to those visible in the view. Endpoints are lifted to visible ancestor elements when the original endpoints are not included in the view.
-
Without
--output, the diagram(s) are written to stdout. With--output <dir>, per-view files are named<view-key>.<ext>, where<ext>ispuml,mmd,dot,d2, orhtml. -
--diagram-format structurizris special: it exports the entire workspace as a singleworkspace.dslfile and rejects--view(exit code 1). -
Creates the output directory if it does not exist.
JSON output structure — --format json emits an array of one object per exported view (not a file list):
[
{ "view": "context", "format": "plantuml", "source": "@startuml\n!include <C4/C4_Context>\n..." }
]
Exit codes:
-
0— all diagrams exported successfully -
1— one or more exports failed, or--viewused withstructurizr -
2— model file not found, invalid format, or no views to export
Example:
$ bausteinsicht export-diagram --view context # writes to stdout
@startuml
!include <C4/C4_Context>
...
$ bausteinsicht export-diagram --diagram-format mermaid --output docs/diagrams --view context
Exported: docs/diagrams/context.mmd
$ bausteinsicht export-diagram --diagram-format structurizr --output docs
Exported: docs/workspace.dsl
$ bausteinsicht export-diagram --view context --format json
[
{ "view": "context", "format": "plantuml", "source": "@startuml\n..." }
]
bausteinsicht export-sequence
Exports dynamic views from the model as PlantUML or Mermaid sequence diagram source files. Dynamic views describe the runtime behaviour of the system as ordered message sequences between elements.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Path to the model file. |
No |
Auto-detected |
|
Export only the dynamic view with this key. |
No |
All dynamic views |
|
Diagram format: |
No |
|
|
Output directory for exported files. When omitted, output is written to stdout. |
No |
stdout |
|
Output format: |
No |
|
Behavior:
-
Loads the model and reads
dynamicViewsentries. -
Steps are sorted by
indexand rendered in order. -
Participants are listed in first-appearance order.
-
Participant display names are resolved from the element
title; falls back to element ID if the element is not in the model. -
If
--outputis given, files are namedsequence-<view-key>.puml(PlantUML) orsequence-<view-key>.md(Mermaid). -
If no dynamic views are defined in the model, a warning is written to stderr and the command exits with
0.
Arrow type mapping:
| Step type | PlantUML | Mermaid |
|---|---|---|
|
|
|
|
|
|
|
|
|
JSON output structure:
[
{
"view": "checkout-flow",
"format": "plantuml",
"source": "@startuml checkout_flow\n..."
}
]
Exit codes:
-
0— all sequence diagrams exported successfully (or no dynamic views defined) -
1— specified--viewkey not found -
2— model file not found, invalid--diagram-format, or I/O error
Example:
$ bausteinsicht export-sequence
@startuml checkout_flow
title Checkout Flow
...
@enduml
$ bausteinsicht export-sequence --output docs/sequences
Exported: docs/sequences/sequence-checkout-flow.puml
$ bausteinsicht export-sequence --diagram-format mermaid --view checkout-flow
sequenceDiagram
title Checkout Flow
...
$ bausteinsicht export-sequence --format json
[
{
"view": "checkout-flow",
"format": "plantuml",
"source": "@startuml checkout_flow\n..."
}
]
bausteinsicht lint
Evaluates the architectural constraints defined in the model and reports violations.
Flags: none beyond the global flags.
Behavior: loads the model and evaluates each constraint. Prints All constraints passed. when constraints exist with no violations, No constraints defined. when the model declares none, or the list of violations otherwise. Use in CI as an architecture gate.
bausteinsicht health
Computes an architecture health score (0–100, with a letter grade) across weighted categories such as completeness, conformance, and complexity.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Print only the overall score and grade. |
No |
|
|
Write the report to a file instead of stdout. |
No |
(stdout) |
Behavior: requires an explicit --model. Emits a human-readable report (or JSON with --format json) of the overall score, per-category scores, and model statistics.
bausteinsicht graph
Analyzes the relationship graph: cycle detection, dependency depth, and centrality metrics.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Show centrality metrics per element. |
No |
|
|
Show only detected cycles. |
No |
|
|
Write the report to a file instead of stdout. |
No |
(stdout) |
Behavior: requires an explicit --model. Reports element/relationship counts, max dependency depth, graph type (DAG / has cycles), and strongly connected components.
bausteinsicht stale
Flags elements that look forgotten. An element is reported only when all three hold: its last modification is older than the threshold, it has no lifecycle status, and it links no ADR (decisions is empty). Archived elements are skipped.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Consider an element stale if unmodified for this many days. |
No |
|
|
Model file path. |
No |
|
|
draw.io diagram path (auto-detected if empty). |
No |
(auto-detect) |
|
Highlight stale elements in the diagram. |
No |
|
|
Remove stale markers from the diagram (restores original styles). |
No |
|
|
Output format: |
No |
|
Behavior: the last-modified date comes from per-element git history, or from the element’s explicit lastModified field if set. Outside a git repository, elements without an explicit lastModified have no known date and are therefore not flagged by age. Output is deterministically ordered (by risk, then ID).
bausteinsicht status
Lists elements by lifecycle status (proposed, design, implementation, deployed, deprecated, archived).
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Show only elements with this status. |
No |
(all) |
Behavior: requires an explicit --model. Groups elements under their status.
bausteinsicht find
Full-text search over the model.
Arguments: <query> (required) — the search string.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Limit results to |
No |
|
Behavior: returns ranked matches grouped by object type, with the matched fields. --format json emits a structured result.
bausteinsicht show
Displays all fields, relationships, and views for a single element.
Arguments: <element-id> (required) — the dot-path ID.
Behavior: prints the element’s kind, title, description, technology, relationships, and the views it appears in. --format json emits the element as structured data.
bausteinsicht snapshot
Manages versioned model snapshots stored in .bausteinsicht-snapshots/.
Subcommands:
| Subcommand | Description |
|---|---|
|
Capture the current model as a snapshot ( |
|
List saved snapshots ( |
|
Diff snapshot |
|
Restore a snapshot to a file ( |
|
Delete a snapshot. |
Behavior: diff reports a structured architecture delta (added/removed elements and relationships), not a text diff.
bausteinsicht diff
Reports the gap between the model’s asIs and toBe sections.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Model file path. |
No |
|
|
Accepted for forward compatibility but currently has no effect (per-view diff is not yet implemented). |
No |
(all) |
|
Output format: |
No |
|
Behavior: exits with an error if the model has no asIs/toBe sections.
bausteinsicht changelog
Generates a human-readable changelog between two versions of the model.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Starting git ref (commit SHA or tag). Must be provided — there is no implemented default. |
Yes (in practice) |
(none) |
|
Ending git ref. |
No |
|
|
Model file path. |
No |
|
|
Output format: |
No |
|
|
Write to a file instead of stdout. |
No |
(stdout) |
Behavior: loads the model at each git ref (via git rev-parse / git show) and reports the architecture changes between them. Only git refs are supported — snapshot IDs are not (yet) resolved, and an empty --since fails to resolve. (Note: changelog uses --changelog-format, not the global --format.)
bausteinsicht import
Imports an architecture model from an external DSL and writes a Bausteinsicht .jsonc file.
Arguments: <input-file> (required) — the source DSL file.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Source format: |
Yes |
(none) |
|
Output model file path. |
No |
|
|
Print the generated model to stdout instead of writing the file. |
No |
|
|
Overwrite the output file if it already exists. |
No |
|
Behavior: parses the source DSL, maps people/systems/containers and relationships, and generates a matching specification. Exit 2 if the output file already exists and neither --force nor --dry-run is set — --dry-run prints to stdout and skips the existence check, so it never fails on an existing output. Exit 1 on any other import failure (unknown --from, unreadable input, parse/encoding error).
bausteinsicht generate-template
Generates a draw.io template with a styled shape for each element kind in the specification.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Visual preset: |
No |
|
|
Output template file. |
No |
|
|
Model file (auto-detected if omitted). |
No |
(auto-detect) |
Behavior: the generated file carries the bausteinsicht_template attributes the sync engine needs, so it works directly as a --template.
bausteinsicht layout
Computes a hierarchical layout for the diagram and writes the element positions back to the draw.io file.
Flags:
| Flag | Description | Required | Default |
|---|---|---|---|
|
Layout algorithm (currently only |
No |
|
|
Ranking direction: |
No |
|
|
Do not move elements marked |
No |
|
bausteinsicht overlay
Loads external metrics (error rate, coverage, …) from a JSON file and overlays them as a heatmap on draw.io elements; original styles are preserved.
Subcommands:
| Subcommand | Description |
|---|---|
|
Apply a metric heatmap ( |
|
List the metrics available in the file. |
|
Remove the overlay and restore original colors ( |
apply and remove load the model directly and do not auto-detect — pass --model (there is no default). When --output is omitted it resolves relative to the model file’s directory, not the current directory. Any overlay failure (missing model/metrics file, unreadable diagram, unknown metric) exits with code 2.
bausteinsicht repl
Starts an interactive shell for editing the model.
Flags: none beyond the global flags.
Behavior: keeps the model in memory; supports add/remove/list/show/validate/undo/save (plus help and exit). Validates before every save; pure additions are patched comment-preserving, modifications/deletions fall back to a full rewrite (with a warning). exit with unsaved changes prompts for confirmation before quitting; Ctrl-D (EOF) warns about unsaved changes and exits cleanly.
bausteinsicht adr
Lists and shows Architecture Decision Records linked to model elements (the decisions field).
Subcommands:
| Subcommand | Description |
|---|---|
|
List all ADRs, or only those linked to one element ( |
|
Show details of a specific ADR. |
Flags: --model, -m (default architecture.jsonc). adr list supports --format text|json and --element <id> to filter; adr show prints text only.
bausteinsicht workspace
Works with multi-model workspaces that combine several architecture models.
Subcommands:
| Subcommand | Description |
|---|---|
|
List the models in a workspace configuration. |
|
Merge the configured models into one unified model. |
|
Validate a workspace configuration. |
bausteinsicht schema
Manages the JSON Schema for Bausteinsicht models.
Subcommands:
| Subcommand | Description |
|---|---|
|
Generate the JSON Schema from the Go model types ( |
Behavior: the schema is generated from internal/model types, so it stays in sync with the model definitions.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.