feat(analysis): add DomainLanguageParser emitting cc.json 2.0 domain …

.github/workflows/scripts/version-manager.ts

@@ -241,7 +241,6 @@ class VersionManager {
 }
 
 // CLI interface
-// @ts-ignore
 if (import.meta.main) {
     const [command, ...args] = process.argv.slice(2)
     const manager = new VersionManager()

.github/workflows/test_visualization.yml

@@ -55,6 +55,12 @@ jobs:
         npm run lint:architecture || (echo "❌ Architecture violations detected! Check the output above for details." && exit 1)
       working-directory: ${{env.working-directory}}
 
+    - name: Check component styles
+      run: |
+        echo "Checking for component style files (no-component-scss-files)..."
+        npm run lint:styles || (echo "❌ Component style files detected! Use Tailwind utility classes instead." && exit 1)
+      working-directory: ${{env.working-directory}}
+
     - name: Check dead code
       run: |
         echo "Checking for unused exports/files (knip)..."

.gitignore

@@ -2,8 +2,17 @@
 codecharta-analyse.sonargraph
 auth.txt
 .cache
+# brand reference — internal corporate palette, must not be committed
+Ideas/brand.png
 # call-graph exports (e.g. analysis.cg.json) — large, generated
 *.cg.json
+# analyser output written at the analysis root (e.g. dlc.cc.json.gz) — generated, not a tracked fixture
+/analysis/*.cc.json
+/analysis/*.cc.json.gz
+# analyser output dropped at the repo root (e.g. maibornwolff-domain.cc.json) — generated, and biome
+# would otherwise try to format the minified map. Tracked fixtures all live in subdirectories.
+/*.cc.json
+/*.cc.json.gz
 **/node-wrapper/public
 .scannerwork
 

CLAUDE.md

@@ -291,14 +291,18 @@ Example: `feat(visualization): add dark mode toggle (#123)`
 - Based on official Kotlin Coding Conventions
 - Auto-formatted via `./gradlew ktlintFormat`
 - Rules defined in `.editorconfig`
-- **Function syntax**: Use block-body style with braces `{ }` consistently, not expression-body style with `=`
+- **Function syntax**: Follow ktlint (`ktlint_code_style = ktlint_official`), which requires an
+  expression body (`=`) for a function whose body is a single expression, and a block body `{ }` for
+  everything else. `./gradlew ktlintFormat` rewrites this for you — do not hand-write the other form,
+  `ktlintCheck` fails it.
 - **Guard clauses**: Use early returns for error conditions and edge cases to reduce nesting
 - **If expressions**: Prefer concise single-line style when possible:
   - ✅ `val x = if (condition) valueA else valueB`
   - ❌ `val x = if (condition) { valueA } else { valueB }`
   - Use multi-line only when branches contain multiple statements or complex logic
 - **Magic strings/numbers**: Extract repeated literals to constants in `companion object`
-- **Function organization**: Group related functions with section comments
+- **Function organization**: Keep related functions next to each other; order them top-down (callers
+  before callees) instead of labelling groups with section comments
 - **Parameter naming**: Use consistent, descriptive names across related functions
 
 **Visualization (TypeScript)**:
@@ -322,7 +326,12 @@ Example: `feat(visualization): add dark mode toggle (#123)`
 - **Expressive Naming**: Descriptive names that reveal intent (>2 chars, avoid abbreviations)
 - **Fix Warnings**: Never suppress, always resolve
 - **Consistent Style**: Match existing patterns; follow language conventions
-- **Comments**: Use sparingly; explain *why* not *what*. Prefer clear function names over comments.
+- **Comments**: Default to **no comment**. Write one only when the code cannot be made to explain
+  itself and a reader would otherwise draw a wrong conclusion — a non-obvious constraint, a
+  workaround (reference the issue), a deliberate trade-off. Never restate what the code does.
+  Naming is the tool: rename the method, extract a named helper, introduce a named constant or
+  intermediate variable instead of writing a sentence. Prose blocks that narrate a class, a
+  template section, or a sequence of steps do not belong in the code — delete them.
 - **Method Size**: Keep methods <25 lines; split complex logic into focused helpers
 - **Parameter Lists**: Max 3-4 parameters; use data classes for related groups
 - **Metric Accuracy**: All metrics must be deterministic and reproducible across runs

CODE_QUALITY.md

@@ -93,7 +93,10 @@ private fun writeOutput(data: TransformedData): Result { ... }
 
 ### 4. Comments
 
-**RULE:** Comments explain *why*, never *what*. Code should be so clear that *what* is obvious.
+**RULE:** The default is **no comment**. Make the code explain itself through naming — rename the
+method, extract a named helper, introduce a named constant or intermediate variable. Write a comment
+only when that is impossible and a reader would otherwise draw a wrong conclusion; then it explains
+*why*, never *what*.
 
 **❌ BAD:**
 ```kotlin
@@ -119,6 +122,8 @@ val compatible = projects.filter { Project.isAPIVersionCompatible(it.apiVersion)
 - ✅ Performance trade-offs
 - ❌ Explaining obvious code
 - ❌ Commented-out code (delete it)
+- ❌ Prose that narrates a class, a template section, or a sequence of steps — rename and extract instead
+- ❌ Doc comments (KDoc/JSDoc) that only repeat the signature
 
 ### 5. Function Parameters