Risks and Technical Debts
Risks for v4 differ significantly from v3. Some v3 risks are resolved (Gradle coupling, jBake maintenance), while new risks arise from the migration.
This chapter separates Risks (uncertain future events) from Technical Debt (known compromises already in the code). Risks carry stable IDs (R-NNN) referenced from the ADR Consequences in [section-design-decisions].
11.1 Risks
Probability and Impact are rated Low / Medium / High. Priority is derived from the two (High×High ⇒ HIGH, etc.) and matches the original assessment. Rows are ordered by Priority, highest first. Each Mitigation references a Chapter 8 concept or a quality scenario.
| R-ID | Risk | Probability | Impact | Priority | Mitigation |
|---|---|---|---|---|---|
R-001 |
Custom site generator maturity. Replacing jBake with the custom Groovy SSG ( |
High |
High |
HIGH |
Ch8 Test concept — integration tests for |
R-002 |
v3 migration path. Users upgrading from v3 lose Gradle-based workflows. Projects using |
High |
High |
HIGH |
Ch8 Error Handling concept — deprecation warnings via |
R-003 |
Script loading and classpath conflicts. Without Gradle’s dependency resolution, scripts depending on external libraries (POI, jsoup, HttpClient) need a reliable classpath; class conflicts between scripts are possible (QS-1, QS-4). |
Medium |
High |
MEDIUM |
|
R-004 |
Residual inconsistent error handling. The |
Medium |
Low |
LOW |
Ch8 Error Handling concept (ADR-8) — |
R-006 |
publishToConfluence port regression. Porting the 823-LOC |
Medium |
Medium |
MEDIUM |
Service-level tests around the new script before the core module is dropped (ADR-12). |
R-007 |
Diagram-privacy control not implemented. ADR-9’s |
Medium |
Medium |
MEDIUM |
Implement ADR-9 ( |
R-005 |
Release-time dependency resolution. AsciiDoctor is embedded (ADR-6, revised); 177 JARs (~126 MB) ship in |
Low |
Medium |
LOW |
Ch8 Security concept — Trivy CVE scan of |
R-008 |
Incomplete secret redaction in output. |
Low |
Medium |
LOW |
Ch8 Security concept — |
11.2 Technical Debt
Each item names the specific Chapter 5 building block it burdens.
| Technical Debt | Affected Building Block (Ch5) | Description |
|---|---|---|
Confluence API dual client |
Atlassian Integration scripts ( |
Two parallel client implementations (V1 Server, V2 Cloud) must be maintained. Atlassian is deprecating v1 for Cloud. Decision deferred to ADR-TBD-1. |
No Jira Cloud client |
Atlassian Integration scripts ( |
Only |
Windows-only export features |
External Tool Export scripts ( |
EA, PowerPoint, and Visio export remain Windows-only (VBScript COM automation). No fallback on Linux/macOS, burdening cross-platform portability (QS-2). |
|
Wrapper Layer / |
Embedding AsciidoctorJ + JRuby (ADR-6, revised) makes |
No v4 Windows wrapper path |
Wrapper Layer ( |
The v4 |
Hand-synchronised Bausteinsicht model and inline PlantUML |
Building Block View (Ch5) — Level-1 container view ( |
The Level-1 view exists twice: as a Bausteinsicht JSONC model (source of truth) and as inline C4-PlantUML (rendered artifact). Because Bausteinsicht has no PlantUML exporter (ADR-15), the two are kept in sync by hand and can drift. Explicitly accepted as low-cost (one view, changed rarely); retires when a text-based export path is wired (ADR-15). |
Resolved v3 Risks
| Former Risk | How v4 Resolves It |
|---|---|
Incomplete core module migration |
Resolved. The |
Dual config file confusion |
Clarified. |
jBake unmaintained / Apple Silicon |
Resolved by ADR-4. Custom Groovy SSG replaces jBake. No OrientDB, no JNI issues. |
Gradle startup overhead |
Resolved by ADR-3. No Gradle at all. Startup under 3 seconds. |
Heavy dependency footprint (60-80 JARs) |
Not resolved — reversed. The plan to externalize AsciiDoctor (ADR-6) was dropped; v4 embeds AsciidoctorJ + JRuby, so |
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.