kopi 0.2.3

Kopi is a JDK version management tool
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154

# AN-<id> Topic | Feature Title

## Metadata

- Type: Analysis
- Status: Draft | Complete | Cancelled | Archived
  <!-- Draft: Initial exploration | Complete: Ready for requirements | Cancelled: Work intentionally halted | Archived: Analysis concluded -->

## Links

<!-- Internal project artifacts only. Replace or remove bullets as appropriate. -->

- Related Analyses:
  - [AN-<id>-<topic>](../analysis/AN-<id>-<topic>.md)
- Related Requirements:
  - [FR-<id>-<name>](../requirements/FR-<id>-<name>.md)
  - [NFR-<id>-<name>](../requirements/NFR-<id>-<name>.md)
- Related ADRs:
  - [ADR-<id>-<title>](../adr/ADR-<id>-<title>.md)
- Related Tasks:
  - [T-<id>-<task>](../tasks/T-<id>-<task>/README.md)

## Executive Summary

`[1-2 paragraph summary of the analysis scope, key findings, and recommendations]`

## Problem Space

### Current State

`[What exists today? What are the pain points?]`

### Desired State

`[What do we want to achieve? What would success look like?]`

### Gap Analysis

`[What's the delta between current and desired state?]`

## Stakeholder Analysis

| Stakeholder    | Interest/Need      | Impact          | Priority |
| -------------- | ------------------ | --------------- | -------- |
| `[User group]` | `[What they need]` | High/Medium/Low | P0/P1/P2 |

## Research & Discovery

### User Feedback

`[Surveys, interviews, support tickets, forum discussions]`

### Competitive Analysis

`[How do similar tools handle this?]`

### Technical Investigation

`[POCs, benchmarks, API exploration, feasibility studies]`

### Data Analysis

`[Metrics, logs, usage patterns if available]`

## Discovered Requirements

> Capture potential requirements as solution-agnostic problem statements focused on the problem to solve rather than any specific implementation.

### Functional Requirements (Potential)

- [ ] **FR-DRAFT-1**: `[Requirement description]` → Will become FR-<id>
  - Rationale: `[Why this is needed]`
  - Acceptance Criteria: `[Measurable criteria]`

- [ ] **FR-DRAFT-2**: `[Requirement description]` → Will become FR-<id>
  - Rationale: `[Why this is needed]`
  - Acceptance Criteria: `[Measurable criteria]`

### Non-Functional Requirements (Potential)

- [ ] **NFR-DRAFT-1**: `[Constraint/quality attribute]` → Will become NFR-<id>
  - Category: Performance | Security | Usability | Reliability
  - Rationale: `[Why this constraint matters]`
  - Target: `[Specific measurable target]`

## Design Considerations

### Technical Constraints

`[Known limitations, platform requirements, dependencies]`

### Potential Approaches

1. **Option A**: `[Description]`
   - Pros: `[Benefits]`
   - Cons: `[Drawbacks]`
   - Effort: High/Medium/Low

2. **Option B**: `[Description]`
   - Pros: `[Benefits]`
   - Cons: `[Drawbacks]`
   - Effort: High/Medium/Low

### Architecture Impact

`[Will this require new ADRs? What decisions need to be made?]`

## Risk Assessment

| Risk                 | Probability     | Impact          | Mitigation Strategy |
| -------------------- | --------------- | --------------- | ------------------- |
| `[Risk description]` | High/Medium/Low | High/Medium/Low | `[How to address]`  |

## Open Questions

- [ ] `[Question that needs investigation]`
- [ ] `[Decision that needs to be made]` → Next step: `[Where to resolve (e.g., draft ADR via docs/adr/ADR-<id>-<title>.md, create requirements docs/requirements/FR-<id>-<capability>.md per TDL)]`
- [ ] `[Information that needs gathering]` → Method: `[How to obtain insight]`

<!-- Complex investigations should spin out into their own ADR or analysis document -->

## Recommendations

### Immediate Actions

1. `[What should be done right away]`
2. `[Quick wins or critical fixes]`

### Next Steps

1. [ ] Create formal requirements: FR-<id>, NFR-<id>
2. [ ] Draft ADR for: `[Architectural decision needed]`
3. [ ] Create task for: `[Implementation work]`
4. [ ] Further investigation: `[What needs more analysis]`

### Out of Scope

`[What we explicitly decided NOT to do and why]`

## Appendix

### References

`[External documents, standards, articles that informed this analysis]`

### Raw Data

`[Survey results, benchmark outputs, logs - anything that supports the analysis]`

---

## Template Usage

For detailed instructions and key principles, see [Template Usage Instructions](README.md#analysis-template-analysismd) in the templates README.