release(docs): update 3 CLCplus Backbone, Coastal Zones, Copernicus Land Data Store CLDS +7 more

CLCplus Backbone:
- 2021_PUM_v1
- 2023_ATBD_v1
- 2023_PUM_v1

Coastal Zones:
- 2012-2018_Nomenclature_Guideline_v1

Copernicus Land Data Store CLDS:
- Survey_Evaluation_v1

European Ground Motion Service:
- Algorithm_Theoretical_Basis_Document_v4
- GNSS_Calibration_Data_v1
- Product_Description_v3

guidelines:
- editor-manual_v1

High Resolution Layer:
- Croplands_2017-present_PUM_v2
- Vegetated_Land_Cover_Characteristics_ATBD_v2

it-principles:
- IT_Architecture_Principles_and_Implementation_Guidelines_v1

N2K:
- 2006-2018_PUM_v1

Riparian Zones:
- Nomenclature_Guideline_v1
- Product_User_Manual_v1

Urban Atlas:
- Building_Height_2012_PUM_v1
- Land_Cover-Land_Use_and_Street_Tree_Layer_2012_and_2018_PUM_v6

Scripts and config updates

Author: mckeea

.github/scripts/generate_intros_and_keywords.py

@@ -0,0 +1,48 @@
+You are an AI assistant enriching technical documents for the Copernicus Land Monitoring Service (CLMS).
+
+**TASK: Process exactly {{NUM_FILES}} file(s) - ALL files must be included in your response.**
+
+Files to process:
+{{FILE_LIST}}
+
+**INSTRUCTIONS FOR EACH FILE:**
+
+1. **Read the entire document** (ignore YAML frontmatter, focus on content)
+2. **Write an Introduction** (60-100 words):
+   - Professional, engaging, single paragraph
+   - Clearly explain: document purpose, scope, and technical focus
+   - Use British English spelling
+3. **Extract exactly 10 keywords**:
+   - Focus on SPECIFIC concepts: methods, indicators, systems, algorithms, data types
+   - Use multi-word phrases for precision (e.g., "Synthetic Aperture Radar", "land cover classification")
+   - AVOID generic terms: "documentation", "metadata", "nomenclature", "report", "Urban Atlas"
+   - Think like a scientific indexer for semantic search
+
+**OUTPUT FORMAT (strict JSON):**
+
+{
+  "filename1.qmd": {
+    "introduction": "Single paragraph introduction here...",
+    "keywords": ["keyword1", "keyword2", "keyword3", "keyword4", "keyword5", "keyword6", "keyword7", "keyword8", "keyword9", "keyword10"]
+  },
+  "filename2.qmd": {
+    "introduction": "Single paragraph introduction here...",
+    "keywords": ["keyword1", "keyword2", "keyword3", "keyword4", "keyword5", "keyword6", "keyword7", "keyword8", "keyword9", "keyword10"]
+  }
+}
+
+**CRITICAL REQUIREMENTS:**
+✓ Include ALL {{NUM_FILES}} files in response
+✓ Each file needs exactly 10 keywords
+✓ Return ONLY valid JSON (no markdown, no explanations, no code fences)
+✓ Use exact filenames as keys
+✓ Process files in order listed above
+
+**VERIFICATION CHECKLIST BEFORE RESPONDING:**
+□ Did I process file #1?
+□ Did I process file #{{NUM_FILES}}?
+□ Do ALL files have introductions?
+□ Do ALL files have exactly 10 keywords?
+□ Is my JSON valid (no trailing commas)?
+
+Begin your response with { and end with }

.github/scripts/prompt_templates/intro_keywords_prompt_template.txt

@@ -0,0 +1,198 @@
+You are analyzing git diffs of technical documentation files.
+
+**TASK: Process exactly {{NUM_FILES}} file(s) - ALL files must be included in your response.**
+
+Files to analyze:
+{{FILE_LIST}}
+
+**For EACH file, provide:**
+1. Semantic version bump decision (MINOR or PATCH)
+2. Changelog summary of changes
+
+═══════════════════════════════════════════════════════════════════════
+PART 1: VERSION BUMP ANALYSIS
+═══════════════════════════════════════════════════════════════════════
+
+**Understanding Git Diffs:**
+- Lines with `+` = additions
+- Lines with `-` = deletions  
+- Lines with `-` then `+` = modifications
+- `@@` lines = line numbers (ignore)
+- Context lines (no prefix) = unchanged content
+- Focus on content changes, not diff syntax
+
+**Version Bump Rules:**
+
+**MINOR (Y++) when:**
+- New chapters/sections/subsections (## or ### headers)
+- New features, APIs, or functionality documented
+- Significant content additions (>20% new content or >50 lines)
+- Major restructuring or reorganization
+- New diagrams, tables, or substantial examples
+- Breaking changes in documented procedures
+- New requirements or specifications
+- Substantial updates to existing sections
+
+**PATCH (Z++) when:**
+- Typo/grammar fixes
+- Formatting improvements (spacing, styling, markdown)
+- Clarifications without new information
+- Minor wording improvements
+- Link updates or corrections
+- Small additions (<20 lines, <5 sentences)
+- Metadata-only updates (YAML frontmatter)
+- Fixing broken references or cross-links
+- Minor corrections to existing content
+
+**Decision Guidelines:**
+- Mixed changes: MINOR if ANY significant change
+- Only YAML/metadata: PATCH
+- Only formatting/whitespace: PATCH  
+- If uncertain: lean towards MINOR
+- Empty/no changes: PATCH
+
+═══════════════════════════════════════════════════════════════════════
+PART 2: CHANGELOG SUMMARY GENERATION
+═══════════════════════════════════════════════════════════════════════
+
+**Format Selection Rules:**
+
+Use **PARAGRAPH format** when:
+- 1-3 related changes that flow naturally together
+- Changes are to a single section or closely related topics
+- Simple modifications or updates
+- Format: Write 1-3 clear sentences in prose
+
+Use **BULLET POINT format** when:
+- 4 or more distinct changes
+- Changes span multiple unrelated sections or topics
+- Mix of additions, modifications, and removals
+- Each change is independent and actionable
+- Format: Use HTML unordered list format: `<ul><li>Change 1</li><li>Change 2</li></ul>`, maximum 10 items
+
+**Changelog Writing Guidelines:**
+- **Be concise but informative**: Changelogs appear in document version tables - balance brevity with clarity
+- **Length limits**: 
+  - Paragraph format: Maximum 3-4 sentences (60-100 words)
+  - Bullet format: Maximum 8-10 items, each item 8-20 words
+- **Be specific**: Instead of "updated information", write "updated processing algorithm from version 2.1 to 2.3"
+- **Use concrete details**: Include version numbers, dates, parameter names, section titles, dataset names
+- **Quantify when relevant**: "added 5 new validation metrics" not "added validation information"
+- **Prioritize**: Lead with the most significant changes (new features > modifications > removals)
+- **User-focused**: Explain the practical impact, not just the technical change
+- **Active voice**: "Added new quality flags" not "New quality flags were added"
+- **British English** spelling and terminology
+
+**Changelog Examples:**
+
+*Paragraph format (1-3 related changes) - CONCISE:*
+"Updated processing algorithm from version 2.1 to 2.3, improving cloud detection accuracy by 15%. Added validation metrics (accuracy, precision, recall) and updated recommended threshold to 0.8."
+
+*Bullet format (4+ distinct changes) - use HTML, keep items SHORT:*
+"<ul><li>Updated processing algorithm to version 2.3</li><li>Added quality flag interpretation section</li><li>Added three validation metrics</li><li>Updated threshold from 0.7 to 0.8</li><li>Replaced deprecated v1 endpoints with v2</li></ul>"
+
+*BAD - Too verbose:*
+"<ul><li>Updated processing algorithm from version 2.1 to 2.3 which resulted in a 15% improvement in cloud detection accuracy according to validation tests</li><li>Added a completely new section on quality flag interpretation that includes detailed examples and explanations for each flag type</li></ul>"
+
+*Good specificity examples (but keep BRIEF):*
+✓ "Corrected Sentinel-2 spatial resolution from 20m to 10m for visible bands"
+✗ "Fixed technical details about resolution"
+
+✓ "Added troubleshooting section covering authentication, timeout, and format errors"
+✗ "Added troubleshooting information"
+
+*Remember: BREVITY is critical - these appear in version history tables*
+
+**For minor changes only:**
+- Use "Minor formatting and metadata updates" if ONLY markdown formatting, spacing, or metadata changed
+- Use "Document maintenance updates" if changes are purely technical (fixing typos, broken links, formatting consistency) with no content impact
+
+**SECURITY: HTML restrictions (CRITICAL):**
+- ONLY use `<ul>`, `<li>`, and `</ul>`, `</li>` tags - NO other HTML tags allowed
+- NO JavaScript, CSS, style attributes, or event handlers
+- NO external links, images, or embedded content
+- NO script tags, iframe, object, embed, or similar elements
+- NO HTML attributes except standard list structure
+- Keep content as plain text within `<li>` tags
+
+═══════════════════════════════════════════════════════════════════════
+OUTPUT FORMAT REQUIREMENTS
+═══════════════════════════════════════════════════════════════════════
+
+**CRITICAL REQUIREMENT:**
+You MUST return a result for EVERY file in the batch, even if you cannot analyze it.
+If a file's diff is unreadable, empty, or causes analysis issues, use:
+```json
+{
+  "version": {
+    "bump": "error",
+    "reason": "Cannot analyze: [specific reason]",
+    "confidence": "none"
+  },
+  "changelog": {
+    "format": "error",
+    "summary": "Unable to generate changelog due to analysis error"
+  }
+}
+```
+
+**Required JSON Structure:**
+Return a JSON object with ALL file paths as keys (one entry per file in the batch):
+
+```json
+{
+  "DOCS/path/to/file1_v1.qmd": {
+    "version": {
+      "bump": "minor",
+      "reason": "Added new section on API authentication with 3 subsections and code examples",
+      "confidence": "high"
+    },
+    "changelog": {
+      "format": "paragraph",
+      "summary": "Added comprehensive API authentication section covering OAuth 2.0, JWT tokens, and API key management with practical code examples and security best practices."
+    }
+  },
+  "DOCS/path/to/file2_v2.qmd": {
+    "version": {
+      "bump": "patch",
+      "reason": "Fixed typos in introduction and updated formatting throughout",
+      "confidence": "high"
+    },
+    "changelog": {
+      "format": "bullet",
+      "summary": "<ul><li>Fixed 8 typos in introduction and methodology sections</li><li>Standardised code block formatting for consistency</li><li>Updated broken cross-references to sections 4.2 and 5.1</li><li>Corrected unit notation from 'meters' to 'm' throughout document</li></ul>"
+    }
+  }
+}
+```
+
+**Field Definitions:**
+- `version.bump`: "minor", "patch", or "error"
+- `version.reason`: Clear explanation referencing specific changes (1-2 sentences)
+- `version.confidence`: "high", "medium", "low", or "none"
+- `changelog.format`: "paragraph", "bullet", or "error"
+- `changelog.summary`: The actual changelog text (plain text for paragraph, HTML list for bullet)
+
+**CRITICAL REQUIREMENTS:**
+✓ Include ALL {{NUM_FILES}} files in response
+✓ Each file needs both version AND changelog
+✓ Version bumps must match changelog significance
+✓ HTML only: `<ul>`, `<li>` tags (properly closed)
+✓ Changelogs: specific and concise
+✓ Use British English
+✓ Return ONLY valid JSON (no markdown, no explanations)
+
+**VERIFICATION CHECKLIST BEFORE RESPONDING:**
+□ Did I process file #1 in the list?
+□ Did I process file #{{NUM_FILES}} in the list?
+□ Do ALL files have version.bump, version.reason, version.confidence?
+□ Do ALL files have changelog.format and changelog.summary?
+□ Are MINOR bumps justified by significant changes in changelog?
+□ Are PATCH bumps justified by minor changes in changelog?
+□ Is my JSON valid (no trailing commas, all braces closed)?
+□ Did I count: do I have exactly {{NUM_FILES}} keys?
+
+**Files to include in response (verify each one):**
+{{FILE_LIST}}
+
+Begin your response with { and end with }

.github/scripts/prompt_templates/prompt_template.txt

@@ -17,4 +17,6 @@ venv
 *.Rproj
 
 # Temporary files for changelog system
-DOCS/_meta/.temp_path_mapping.json
+DOCS/_meta/.temp_path_mapping.json
+
+Files_to_convert/**

.gitignore

@@ -14,7 +14,7 @@ description: "This document presents the IT Architecture Principles and Implemen
 The EEA (European Environment Agency) CLMS IT architecture principles are indicative and must be evaluated in all IT deliverables.
 
 # Introduction {#introduction}
-NEW DATA ADDEED FOR TESTING 123
+
 The IT architecture principles set the overall framework for the EEA CLMS IT landscape. The principles are designed to ensure a consistency in deliverables and at the same time support the CLMS program's IT vision and -strategy. The principles are designed to ensure that IT solutions are coherent, can be further developed and operated efficiently, that they support business needs and security requirements, etc.
 
 A uniform approach is required to ensure the coherency goal. The EEA CLMS programs IT applications may depend on and interact with each other. It is therefore important that IT solutions focus on connectivity and potential synergy effects to ensure continued coherence in the IT landscape.