ADR-001: Risk Classification - dacli CLI
Date: 2026-02-11
Status: Accepted
Deciders: Development Team + Claude Code
Technical Story: Risk Radar Assessment via /risk-assess
Context
Risk assessment using vibe-coding Risk Radar framework for the dacli CLI module (command-line interface for documentation access):
| Dimension |
Score |
Level |
Reasoning |
| Code Type |
2 |
Business Logic |
Click commands, service layer orchestration handling file I/O and content manipulation (src/dacli/cli.py, src/dacli/services/) |
| Language |
2 |
Dynamically typed |
Python 3.12+ — 100% .py files (no static type checking) |
| Deployment |
1 |
Internal tool |
Command-line tool used by documentation teams, not public-facing |
| Data Sensitivity |
1 |
Internal business data |
Operates on internal documentation files (AsciiDoc/Markdown) |
| Blast Radius |
2 |
Data loss (recoverable) |
Could corrupt documentation files, but recoverable from git version control |
Calculated Tier: max(2, 2, 1, 1, 2) = Tier 2 — Extended Assurance
Decision
Classify dacli CLI as Tier 2 — Extended Assurance.
This tier requires:
- Tier 1: Automated Gates (linter, pre-commit, dependency check, CI/tests)
- Tier 2: Extended Assurance (SAST, AI review, property-based tests, quality gate, sampling review)
See ADR-003 for mitigation implementation details.
Consequences
Positive
- Clear security baseline established for CLI module
- Appropriate protection level for business logic handling file operations
- Comprehensive testing strategy (713 tests including property-based)
Negative
- Additional CI pipeline duration (~2-3 minutes for extended checks)
- Developer onboarding overhead (pre-commit hooks, Hypothesis tests)
Neutral
- Most mitigations are repository-wide and apply to both CLI and MCP modules
- Shares implementation with dacli-mcp module (same codebase, different entry point)
Alternatives Considered
Tier 1: Basic Gates Only
- Would mean: No SAST, no property-based tests, no code quality gate
- Rejected because:
- Code Type (Business Logic, score 2) requires extended assurance
- Language (Dynamically typed Python, score 2) benefits from additional testing
- Blast Radius (Data loss, score 2) justifies comprehensive quality measures
Tier 3: Mandatory Measures
- Would mean: Mandatory human review on all PRs, sandbox/isolation, fuzzing, pen testing
- Rejected because:
- Deployment is internal tool (score 1), not public-facing or regulated
- Data sensitivity is internal business data (score 1), not PII/PHI
- Overkill for current risk profile
Note: Language dimension (Python) is a factual constraint, not a choice. No alternatives exist for this dimension.
Related
This ADR documents a decision already implemented. Status set to "Accepted" as mitigations are in place (100% Tier 2 completion as of 2026-02-11).
ADR-001: Risk Classification - dacli CLI
Date: 2026-02-11
Status: Accepted
Deciders: Development Team + Claude Code
Technical Story: Risk Radar Assessment via
/risk-assessContext
Risk assessment using vibe-coding Risk Radar framework for the dacli CLI module (command-line interface for documentation access):
src/dacli/cli.py,src/dacli/services/).pyfiles (no static type checking)Calculated Tier: max(2, 2, 1, 1, 2) = Tier 2 — Extended Assurance
Decision
Classify dacli CLI as Tier 2 — Extended Assurance.
This tier requires:
See ADR-003 for mitigation implementation details.
Consequences
Positive
Negative
Neutral
Alternatives Considered
Tier 1: Basic Gates Only
Tier 3: Mandatory Measures
Note: Language dimension (Python) is a factual constraint, not a choice. No alternatives exist for this dimension.
Related
This ADR documents a decision already implemented. Status set to "Accepted" as mitigations are in place (100% Tier 2 completion as of 2026-02-11).