ingest: CMS Developer Agent Personality (engineering-cms-developer.md)

- Source: sources/engineering-cms-developer.md
- Entities: WordPress, Drupal
- Concepts: ContentModel-first, CodeOverConfiguration
- Updated: index.md (Sources/Entities/Concepts), overview.md, log.md

wiki/concepts/CodeOverConfiguration.md

@@ -0,0 +1,70 @@
+---
+title: "CodeOverConfiguration"
+type: concept
+tags: [cms, development, best-practices]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+CodeOverConfiguration is a CMS development principle requiring that all structural changes — custom post types, taxonomies, fields, blocks, and behavioral settings — be registered in code rather than created through the admin UI. Configuration that affects behavior is also stored in code (not the database).
+
+## Core Principle
+
+> "Custom post types, taxonomies, fields, and blocks are registered in code — never created through the admin UI alone."
+
+## WordPress Application
+
+| What | Where to register |
+|------|-------------------|
+| Custom post types | `functions.php` → `register_post_type()` |
+| Custom taxonomies | `functions.php` → `register_taxonomy()` |
+| ACF field groups | `acf-json/` directory (synced) |
+| ACF blocks | `functions.php` → `acf_register_block_type()` |
+| Gutenberg blocks | `block.json` + JS registration |
+| Theme settings | `wp-config.php` or `functions.php` |
+
+### Example: Post type in code
+
+```php
+add_action( 'init', function () {
+    register_post_type( 'case_study', [
+        'public'        => true,
+        'show_in_rest'  => true,
+        'supports'      => [ 'title', 'editor', 'thumbnail', 'excerpt' ],
+    ] );
+} );
+```
+
+## Drupal Application
+
+| What | Where to store |
+|------|---------------|
+| Content types | YAML config export (`drush cex`) |
+| Field definitions | YAML config in `config/install/` |
+| Custom modules | PHP code + YAML routing/permissions |
+| Blocks | PHP attribute-based plugins (Drupal 10+) |
+| Views | YAML config export |
+
+## Why It Matters
+
+- **Version control**: All structural changes are tracked in Git
+- **Reproducibility**: A fresh environment gets the same structure from a deploy script
+- **Team consistency**: No one accidentally changes a field label in production
+- **Deployment safety**: Config changes go through CI/CD, not manual admin actions
+
+## Anti-patterns
+
+- ❌ Creating post types via the WordPress admin UI without code equivalent
+- ❌ Storing CMS settings that affect behavior in the database instead of code
+- ❌ Modifying contrib module/theme files directly instead of using hooks/overrides
+
+## Related Concepts
+
+- [[ContentModel-first]] — the companion principle: define the model first, then implement
+- [[GitWorkflow]] — version control makes code-as-config viable
+- [[WordPress]] — WordPress-specific code registration patterns
+- [[Drupal]] — Drupal-specific YAML configuration export workflow
+
+## Sources
+- [[engineering-cms-developer]]

wiki/concepts/ContentModel-first.md

@@ -0,0 +1,48 @@
+---
+title: "ContentModel-first"
+type: concept
+tags: [cms, development, methodology]
+last_updated: 2026-05-01
+---
+
+## Definition
+
+ContentModel-first is a CMS development principle that mandates: **before writing any theme or template code, the fields, content types, and editorial workflow must be fully defined and locked**. This applies to both WordPress and Drupal development.
+
+## Core Principle
+
+> "Content model first. Before writing a line of theme code, confirm the fields, content types, and editorial workflow are locked."
+
+## Application
+
+### WordPress
+- Define custom post types, taxonomies, and ACF field groups before building templates
+- Lock down field names, types, validation rules
+- Plan display variants (teaser, full, card, hero)
+
+### Drupal
+- Define content types, paragraph types, vocabulary terms, and entity references first
+- Use Paragraphs or Layout Builder for flexible editorial content
+- Export all configuration to YAML before writing custom modules
+
+## Why It Matters
+
+- **Prevents rework**: Template code rarely needs to change when the data model is stable
+- **Reduces editor confusion**: When fields are well-named and organized, editorial UX improves
+- **Enables parallel work**: Front-end developers and content strategists can work simultaneously once the model is agreed
+- **Improves maintainability**: Adding a new field is a data modeling decision, not a template hotfix
+
+## Anti-patterns
+
+- ❌ Building templates for undefined fields
+- ❌ Creating post types through the admin UI without documenting the schema
+- ❌ Changing field names after templates reference them
+
+## Related Concepts
+
+- [[CodeOverConfiguration]] — the companion principle: register everything in code
+- [[LayoutBuilder]] — Drupal's tool for implementing flexible content models
+- [[GutenbergBlockEditor]] — WordPress's tool for flexible content editing
+
+## Sources
+- [[engineering-cms-developer]]