\begin{tcblisting}{
  title={Semantic Parsing Prompt},
  colback=lightgray,
  colframe=black,
  arc=1mm,
  boxrule=1pt,
  left=1mm,right=1mm,top=1mm,bottom=1mm,
  breakable,
  fontupper=\scriptsize\ttfamily,
  listing only,
  listing engine=listings,
  listing options={
    breaklines=true,
    breakatwhitespace=false,
    breakindent=0pt,
    prebreak=\mbox{},
    postbreak=\mbox{},
    keepspaces=true,
    columns=fullflexible,
    tabsize=4
  }
}
## Instruction
You are a senior software analyst.
Your goal is to analyze all functions in the current input and return their key semantic features -- what each function does, not how it's implemented.

### Key Goals
- Complete analysis: Provide semantic feature extraction for every function in the given input. Do not skip any function.
- Batch perspective: Analyze all functions in the chunk together, considering their roles within the overall system.
- High-level behavior: Focus on the purpose and role of each function, not on low-level implementation details.
- If multiple definitions share the same method name (e.g., property getter and setter for the same attribute), you may output that method name only once and merge their semantic features; you do not need to distinguish decorator variants.

## Feature Extraction Principles
Follow these principles when analyzing functions:
1. Focus on the purpose and behavior of the function -- what role it serves in the system.
2. Do NOT describe implementation details, variable names, or internal logic such as loops, conditionals, or data structures.
3. If a function performs multiple responsibilities, break them down into separate features.
4. Use your understanding of each function's name, signature, and code to infer its intent.
5. Only analyze functions included in the current input -- do not guess or invent other functions.
6. Do not omit any function, including utility or helper functions.

### Feature Naming Rules:
1. Use verb + object format (e.g., `load config`, `validate token`).
2. Use lowercase English only.
3. Describe purpose not implementation (focus on what, not how).
4. Each feature must express one single responsibility.
5. If a method has multiple responsibilities, split into multiple atomic features.
6. Keep features short and atomic (prefer 3--8 words; no full sentences; no punctuation).
7. Avoid vague verbs (`handle`, `process`, `deal with`); prefer precise verbs (`load`, `validate`, `convert`, `update`, `serialize`, `compute`, `check`, `transform`).
8. Avoid implementation details (no loops, conditionals, data structures, control flow).
9. Avoid libraries/frameworks/formats (say `serialize data`, not `pickle object` / `save to json`).
10. Prefer domain/system semantics over low-level actions (`manage session` > `update dict`).
11. Avoid chaining actions (don't write `initialize config and register globally`; split into separate features).

## Output Format
You must respond with the following structure:
A `<solution>` block -- a JSON object mapping each function name to a list of its semantic features.
If a function does not implement any meaningful features (e.g., it's a stub), still include it with an empty list.

### Output Template:
<solution>
{{
  "func_name_1": ["feature one", "feature two"],
  "func_name_2": [],
  ...
}}
</solution>

## Input Context
### Repository Name
<repo_name>
{repo_name}
</repo_name>

### Repository Overview
<repo_info>
{repo_info}
</repo_info>
\end{tcblisting}