### DAP Request Message Example

Source: https://microsoft.github.io/debug-adapter-protocol/overview

This example demonstrates the structure of a DAP 'next' request, including the Content-Length header and the JSON payload. Ensure the Content-Length accurately reflects the byte size of the JSON content.

```json
Content-Length: 119\r\n\r\n{\n    "seq": 153,\n    "type": "request",\n    "command": "next",\n    "arguments": {\n        "threadId": 3\n    }\n}
```

--------------------------------

### StartDebuggingRequest

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

Request to start a new debug session of the same type as the caller.

```APIDOC
## StartDebuggingRequest

### Description
This request is sent from the debug adapter to the client to start a new debug session of the same type as the caller.
This request should only be sent if the corresponding client capability `supportsStartDebuggingRequest` is true.
A client implementation of `startDebugging` should start a new debug session (of the same type as the caller) in the same way that the caller's session was started. If the client supports hierarchical debug sessions, the newly created session can be treated as a child of the caller session.

### Command
- startDebugging

### Arguments
Refer to `StartDebuggingRequestArguments`.
```

--------------------------------

### startDebugging Request

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

This request is sent from the debug adapter to the client to start a new debug session of the same type as the caller. This request should only be sent if the corresponding client capability `supportsStartDebuggingRequest` is true.

```APIDOC
## POST /startDebugging

### Description
Initiates a new debug session of the same type as the current one.

### Method
POST

### Endpoint
/startDebugging

### Request Body
- **configuration** (object) - Required - Arguments for the new debug session, understood by the `launch` or `attach` requests.
- **request** (string) - Required - Specifies whether to start the session with a 'launch' or 'attach' request.
```

--------------------------------

### Initialized Event

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Sent by the debug adapter after the 'initialize' request has finished to indicate readiness for configuration requests. No setup is required beyond the initial 'initialize' request.

```typescript
interface InitializedEvent extends Event {
  event: 'initialized';
}
```

--------------------------------

### ProgressStartEvent

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

Signals the start of a long-running operation, allowing the client to set up UI for progress and cancellation. This event should only be sent if the `supportsProgressReporting` capability is true.

```APIDOC
## ProgressStartEvent

### Description
The event signals that a long running operation is about to start and provides additional information for the client to set up a corresponding progress and cancellation UI. The client is free to delay the showing of the UI in order to reduce flicker. This event should only be sent if the corresponding capability `supportsProgressReporting` is true.

### Event
`progressStart`

### Body Properties
- **progressId** (string) - Required - An ID that can be used in subsequent `progressUpdate` and `progressEnd` events to make them refer to the same progress reporting. IDs must be unique within a debug session.
- **title** (string) - Required - Short title of the progress reporting. Shown in the UI to describe the long running operation.
- **requestId** (integer) - Optional - The request ID that this progress report is related to. If specified a debug adapter is expected to emit progress events for the long running request until the request has been either completed or cancelled. If the request ID is omitted, the progress report is assumed to be related to some general activity of the debug adapter.
- **cancellable** (boolean) - Optional - If true, the request that reports progress may be cancelled with a `cancel` request. So this property basically controls whether the client should use UX that supports cancellation. Clients that don't support cancellation are allowed to ignore the setting.
- **message** (string) - Optional - More detailed progress message.
- **percentage** (number) - Optional - Progress percentage to display. If omitted no percentage is shown. Must be between 0 and 100.
```

--------------------------------

### Launch Request

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

The `launch` request is used by the client to start the debuggee process. It can be used to launch with or without debugging enabled (by setting `noDebug` to true). The specific arguments for launching are implementation-dependent and not defined in this protocol.

```APIDOC
## Launch Request

### Description
This launch request is sent from the client to the debug adapter to start the debuggee with or without debugging (if `noDebug` is true). Since launching is debugger/runtime specific, the arguments for this request are not part of this specification.

### Method
POST (Implied, as it's a request with arguments)

### Endpoint
(Not specified, typically handled by the debug adapter's communication channel)

### Parameters
#### Request Body
- **command** (string) - Required - Must be 'launch'.
- **arguments** (LaunchRequestArguments) - Required - Contains arguments for launching the debuggee. Additional attributes are implementation specific.
  - **noDebug** (boolean) - Optional - If true, launch the program without enabling debugging.
  - **__restart** (any) - Optional - Arbitrary data from the previous, restarted session. The data is sent as the `restart` attribute of the `terminated` event. The client should leave the data intact.

### Request Example
```json
{
  "seq": 5,
  "type": "request",
  "command": "launch",
  "arguments": {
    "program": "/path/to/your/program.py",
    "console": "integratedTerminal",
    "noDebug": false
  }
}
```

### Response
#### Success Response (200)
- No body field is required as this is just an acknowledgement.

### Response Example
```json
{
  "seq": 6,
  "type": "response",
  "request_seq": 5,
  "success": true,
  "command": "launch"
}
```
```

--------------------------------

### Attach Request

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

Attaches to an already running debuggee to start a debug session. Arguments are implementation-specific.

```APIDOC
## POST /attach

### Description
The `attach` request is sent from the client to the debug adapter to attach to a debuggee that is already running.
Since attaching is debugger/runtime specific, the arguments for this request are not part of this specification.

### Method
POST

### Endpoint
/attach

### Request Body
- **command** (string) - Required - Must be "attach"
- **arguments** (object) - Required - Arguments for the attach request, specific to the debugger/runtime.

### Request Example
```json
{
  "command": "attach",
  "arguments": { ... }
}
```

### Response
#### Success Response (200)
- **body** (object) - Optional - Response to `attach` request. This is just an acknowledgement, so no body field is required.

#### Response Example
```json
{
  "success": true,
  "message": "",
  "request_seq": 1,
  "seq": 2,
  "type": "response"
}
```
```

--------------------------------

### Progress Start Event Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Defines the structure for the 'progressStart' event, signaling the beginning of a long-running operation. This event is used in conjunction with `progressUpdate` and `progressEnd` to manage progress reporting UI.

```typescript
interface ProgressStartEvent extends Event {
  event: 'progressStart';

  body: {
    /**
     * An ID that can be used in subsequent `progressUpdate` and `progressEnd`
     * events to make them refer to the same progress reporting.
     * IDs must be unique within a debug session.
     */
    progressId: string;

    /**
     * Short title of the progress reporting. Shown in the UI to describe the
     * long running operation.
     */
    title: string;

    /**
     * The request ID that this progress report is related to. If specified a
     * debug adapter is expected to emit progress events for the long running
     * request until the request has been either completed or cancelled.
     * If the request ID is omitted, the progress report is assumed to be
     * related to some general activity of the debug adapter.
     */
    requestId?: number;

    /**
     * If true, the request that reports progress may be cancelled with a
     * `cancel` request.
     * So this property basically controls whether the client should use UX that
     * supports cancellation.
     * Clients that don't support cancellation are allowed to ignore the
     * setting.
     */
    cancellable?: boolean;

    /**
     * More detailed progress message.
     */
    message?: string;

    /**
     * Progress percentage to display (value range: 0 to 100). If omitted no
     * percentage is shown.
     */
    percentage?: number;
  };
}
```

--------------------------------

### Launch Request Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Defines the 'launch' request, used by the client to start the debuggee. The `noDebug` argument can be used to launch the program without enabling debugging.

```typescript
interface LaunchRequest extends Request {
  command: 'launch';

  arguments: LaunchRequestArguments;
}
```

--------------------------------

### Modules Arguments Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Specifies arguments for the 'modules' request, including 'startModule' for the starting index and 'moduleCount' for the number of modules to retrieve, supporting paging.

```typescript
interface ModulesArguments {
  /**
   * The index of the first module to return; if omitted modules start at 0.
   */
  startModule?: number;

  /**
   * The number of modules to return. If `moduleCount` is not specified or 0,
   * all modules are returned.
   */
  moduleCount?: number;
}
```

--------------------------------

### InitializeRequestArguments

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

Arguments for the `initialize` request, specifying client and adapter capabilities.

```APIDOC
## InitializeRequestArguments

### Description
Arguments for `initialize` request.

### Properties
- **clientID** (string) - The ID of the client using this adapter.
- **clientName** (string) - The human-readable name of the client using this adapter.
- **adapterID** (string) - The ID of the debug adapter.
- **locale** (string) - The ISO-639 locale of the client using this adapter, e.g. en-US or de-CH.
- **linesStartAt1** (boolean) - If true all line numbers are 1-based (default).
- **columnsStart1** (boolean) - If true all column numbers are 1-based (default).
- **pathFormat** (string) - Determines in what format paths are specified. The default is `path`, which is the native format. Possible values: `path`, `uri`.
- **supportsVariableType** (boolean) - Client supports the `type` attribute for variables.
- **supportsVariablePaging** (boolean) - Client supports the paging of variables.
- **supportsRunInTerminalRequest** (boolean) - Client supports the `runInTerminal` request.
- **supportsMemoryReferences** (boolean) - Client supports memory references.
- **supportsProgressReporting** (boolean) - Client supports progress reporting.
- **supportsInvalidatedEvent** (boolean) - Client supports the `invalidated` event.
- **supportsMemoryEvent** (boolean) - Client supports the `memory` event.
- **supportsArgsCanBeInterpretedByShell** (boolean) - Client supports the `argsCanBeInterpretedByShell` attribute on the `runInTerminal` request.
- **supportsStartDebuggingRequest** (boolean) - Client supports the `startDebugging` request.
- **supportsANSIStyling** (boolean) - The client will interpret ANSI escape sequences in the display of `OutputEvent.output` and `Variable.value` fields when `Capabilities.supportsANSIStyling` is also enabled.

### Required
- **adapterID**
```

--------------------------------

### ThreadEvent

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

The event indicates that a thread has started or exited.

```APIDOC
## ThreadEvent

### Description
The event indicates that a thread has started or exited.

### Event
`thread`

### Body
- **reason** (string) - Required - The reason for the event. Possible values: `started`, `exited`.
- **threadId** (integer) - Required - The identifier of the thread.
```

--------------------------------

### StartDebuggingRequestArguments

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

Arguments for the `startDebugging` request.

```APIDOC
## StartDebuggingRequestArguments

### Description
Arguments for `startDebugging` request.

### Properties
- **configuration** (object, required) - Arguments passed to the new debug session. The arguments must only contain properties understood by the `launch` or `attach` requests of the debug adapter and they must not contain any client-specific properties (e.g. `type`) or client-specific features (e.g. substitutable 'variables').
- **outputPresentation** (string, optional) - Hints whether output of the child sessions should be presented separately or merged with that of the parent session's. Possible values: `separate`, `mergeWithParent`.
- **request** (string, required) - Indicates whether the new debug session should be started with a `launch` or `attach` request. Possible values: `launch`, `attach`.

### Required Properties
- configuration
- request
```

--------------------------------

### StartDebuggingRequestArguments Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Specifies the arguments for the `startDebugging` request. The `configuration` object must contain only properties understood by `launch` or `attach` requests and no client-specific properties.

```typescript
interface StartDebuggingRequestArguments {
  /**
   * Arguments passed to the new debug session. The arguments must only contain
   * properties understood by the `launch` or `attach` requests of the debug
   * adapter and they must not contain any client-specific properties (e.g.
   * `type`) or client-specific features (e.g. substitutable 'variables').
   */
  configuration: { [key: string]: any; };

  /**
   * Indicates whether the new debug session should be started with a `launch`
   * or `attach` request.
   * Values: 'launch', 'attach'
   */
  request: 'launch' | 'attach';
}
```

--------------------------------

### Disassemble Request

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

Requests disassembly of code starting from a given memory reference and offset.

```APIDOC
## Disassemble Request

### Description
Requests disassembly of code starting from a given memory reference and offset.

### Method
POST

### Endpoint
/disassemble

### Parameters
#### Request Body
- **memoryReference** (string) - Required - Memory reference to the base location containing the instructions to disassemble.
- **offset** (integer) - Optional - Offset (in bytes) to be applied to the reference location before disassembling. Can be negative.
- **instructionOffset** (integer) - Optional - Offset (in instructions) to be applied after the byte offset (if any) before disassembling. Can be negative.
- **instructionCount** (integer) - Required - Number of instructions to disassemble starting at the specified location and offset.
- **resolveSymbols** (boolean) - Optional - If true, the adapter should attempt to resolve memory addresses and other values to symbolic names.

### Response
#### Success Response (200)
- **instructions** (array) - The list of disassembled instructions.
```

--------------------------------

### InitializeResponse

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

The response to the `initialize` request, containing the debug adapter's capabilities.

```APIDOC
## InitializeResponse

### Description
Response to `initialize` request.

### Properties
- **body** (Capabilities) - The capabilities of this debug adapter.
```

--------------------------------

### BreakpointLocation Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Specifies the properties of a breakpoint location, including start and end lines and columns.

```typescript
interface BreakpointLocation {
  /**
   * Start line of breakpoint location.
   */
  line: number;

  /**
   * The start position of a breakpoint location. Position is measured in UTF-16
   * code units and the client capability `columnsStartAt1` determines whether
   * it is 0- or 1-based.
   */
  column?: number;

  /**
   * The end line of breakpoint location if the location covers a range.
   */
  endLine?: number;

  /**
   * The end position of a breakpoint location (if the location covers a range).
   * Position is measured in UTF-16 code units and the client capability
   * `columnsStartAt1` determines whether it is 0- or 1-based.
   */
  endColumn?: number;
}
```

--------------------------------

### StartDebuggingResponse

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

Response to the `startDebugging` request.

```APIDOC
## StartDebuggingResponse

### Description
Response to `startDebugging` request. This is just an acknowledgement, so no body field is required.
```

--------------------------------

### StackTrace Arguments Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Arguments for the stackTrace request, including thread ID, frame starting index, number of levels, and formatting options.

```typescript
interface StackTraceArguments {
  /**
   * Retrieve the stacktrace for this thread.
   */
  threadId: number;

  /**
   * The index of the first frame to return; if omitted frames start at 0.
   */
  startFrame?: number;

  /**
   * The maximum number of frames to return. If levels is not specified or 0,
   * all frames are returned.
   */
  levels?: number;

  /**
   * Specifies details on how to format the returned `StackFrame.name`. The
   * debug adapter may format requested details in any way that would make sense
   * to a developer.
   * The attribute is only honored by a debug adapter if the corresponding
   * capability `supportsValueFormattingOptions` is true.
   */
  format?: StackFrameFormat;
}
```

--------------------------------

### Initialize Request

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

The `initialize` request is the first communication from the client to the debug adapter. It's used to configure the adapter with client capabilities and retrieve the adapter's capabilities. No other requests or events should be sent by either party until this request is responded to. It can only be sent once.

```APIDOC
## Initialize Request

### Description
Sent as the first request from the client to the debug adapter to configure it with client capabilities and to retrieve capabilities from the debug adapter. Until the debug adapter has responded with an `initialize` response, the client must not send any additional requests or events to the debug adapter. In addition the debug adapter is not allowed to send any requests or events to the client until it has responded with an `initialize` response. The `initialize` request may only be sent once.

### Command
`initialize`

### Arguments
Refer to `InitializeRequestArguments` definition.

### Response
Refer to `InitializeResponse` definition.
```

--------------------------------

### Initialize Request

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

The `initialize` request is the first communication from the client to the debug adapter. It's used to configure the adapter with client capabilities and retrieve capabilities from the adapter. No other requests or events should be exchanged until this request is responded to.

```APIDOC
## Initialize Request

### Description
Sent as the first request from the client to the debug adapter to configure it with client capabilities and to retrieve capabilities from the debug adapter. Until the debug adapter has responded with an `initialize` response, the client must not send any additional requests or events to the debug adapter. The debug adapter is not allowed to send any requests or events to the client until it has responded with an `initialize` response. The `initialize` request may only be sent once.

### Method
POST (Implied, as it's a request with arguments)

### Endpoint
(Not specified, typically handled by the debug adapter's communication channel)

### Parameters
#### Request Body
- **command** (string) - Required - Must be 'initialize'.
- **arguments** (InitializeRequestArguments) - Required - Contains client capabilities and configuration.

### Request Example
```json
{
  "seq": 1,
  "type": "request",
  "command": "initialize",
  "arguments": {
    "clientID": "vscode",
    "clientName": "Visual Studio Code",
    "adapterID": "python",
    "locale": "en-us",
    "linesStartAt1": true,
    "columnsStartAt1": true,
    "pathFormat": "path",
    "supportsVariableType": true,
    "supportsVariablePaging": true,
    "supportsRunInTerminalRequest": true,
    "supportsMemoryReferences": true,
    "supportsProgressReporting": true,
    "supportsInvalidatedEvent": true,
    "supportsMemoryEvent": true,
    "supportsArgsCanBeInterpretedByShell": true,
    "supportsStartDebuggingRequest": true,
    "supportsANSIStyling": true
  }
}
```

### Response
#### Success Response (200)
- **body** (Capabilities) - Optional - Contains the capabilities of the debug adapter.

### Response Example
```json
{
  "seq": 2,
  "type": "response",
  "request_seq": 1,
  "success": true,
  "command": "initialize",
  "body": {
    "supportsConfigurationDoneRequest": true,
    "supportsFunctionBreakpoints": true,
    "supportsConditionalBreakpoints": true,
    "supportsEvaluateForHovers": true,
    "exceptionBreakpointFilters": [
      {
        "filter": "uncaughtExceptions",
        "label": "Uncaught Exceptions",
        "defaultValue": false
      }
    ],
    "supportsStepBack": false,
    "supportsSetVariable": false,
    "supportsRestartFrameId": false,
    "supportsGotoTargetsRequest": false,
    "supportsLogPoints": false,
    "supportsHitCondition": false,
    "supportsCompletionsRequest": false,
    "completionTriggerCharacters": [
      ".",
      "(",
      "["
    ],
    "supportsModulesRequest": false,
    "additionalModuleColumns": [],
    "supportedSortAlgorithms": [
      "none",
      "ascending",
      "descending"
    ],
    "supportsSearchSnippetsRequest": false
  }
}
```
```

--------------------------------

### Launch Request

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

Initiates a new debug session by launching the program. The arguments are specific to the debugger and runtime.

```APIDOC
## POST /launch

### Description
This launch request is sent from the client to the debug adapter to start the debuggee with or without debugging (if `noDebug` is true).
Since launching is debugger/runtime specific, the arguments for this request are not part of this specification.

### Method
POST

### Endpoint
/launch

### Request Body
- **command** (string) - Required - Must be "launch"
- **arguments** (object) - Required - Arguments for the launch request, specific to the debugger/runtime.

### Request Example
```json
{
  "command": "launch",
  "arguments": { ... }
}
```

### Response
#### Success Response (200)
- **body** (object) - Optional - Response to `launch` request. This is just an acknowledgement, so no body field is required.

#### Response Example
```json
{
  "success": true,
  "message": "",
  "request_seq": 1,
  "seq": 2,
  "type": "response"
}
```
```

--------------------------------

### Disconnect Request

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Asks the debug adapter to disconnect from the debuggee and shut down itself. The debuggee is terminated if it was started with `launch`, but not if `attach` was used, unless overridden by `terminateDebuggee`.

```APIDOC
## Disconnect Request

### Description
Disconnects from the debuggee and shuts down the debug adapter. The debuggee is terminated if launched, but not if attached, unless `terminateDebuggee` is specified.

### Command
`disconnect`

### Arguments
#### Request Body
- **restart** (boolean) - Optional - A value of true indicates this `disconnect` request is part of a restart sequence.
- **terminateDebuggee** (boolean) - Optional - Indicates whether the debuggee should be terminated. Only honored if `supportTerminateDebuggee` is true.
- **suspendDebuggee** (boolean) - Optional - Indicates whether the debuggee should stay suspended. Only honored if `supportSuspendDebuggee` is true.

### Response
#### Success Response (200)
- No body field is required.
```

--------------------------------

### Thread Event Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Defines the structure for thread-related events, indicating whether a thread has started or exited. Use this to track thread lifecycle changes.

```typescript
interface ThreadEvent extends Event {
  event: 'thread';

  body: {
    /**
     * The reason for the event.
     * Values: 'started', 'exited', etc.
     */
    reason: 'started' | 'exited' | string;

    /**
     * The identifier of the thread.
     */
    threadId: number;
  };
}
```

--------------------------------

### StartDebuggingRequest Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Defines the structure for the `startDebugging` request, used to initiate a new debug session of the same type. This should only be sent if the client capability `supportsStartDebuggingRequest` is true.

```typescript
interface StartDebuggingRequest extends Request {
  command: 'startDebugging';

  arguments: StartDebuggingRequestArguments;
}
```

--------------------------------

### Initialize Request Arguments Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Specifies the arguments for the 'initialize' request. These include client identification, locale, path format preferences, and support for various client capabilities like variable paging and progress reporting.

```typescript
interface InitializeRequestArguments {
  /**
   * The ID of the client using this adapter.
   */
  clientID?: string;

  /**
   * The human-readable name of the client using this adapter.
   */
  clientName?: string;

  /**
   * The ID of the debug adapter.
   */
  adapterID: string;

  /**
   * The ISO-639 locale of the client using this adapter, e.g. en-US or de-CH.
   */
  locale?: string;

  /**
   * If true all line numbers are 1-based (default).
   */
  linesStartAt1?: boolean;

  /**
   * If true all column numbers are 1-based (default).
   */
  columnsStartAt1?: boolean;

  /**
   * Determines in what format paths are specified. The default is `path`, which
   * is the native format.
   * Values: 'path', 'uri', etc.
   */
  pathFormat?: 'path' | 'uri' | string;

  /**
   * Client supports the `type` attribute for variables.
   */
  supportsVariableType?: boolean;

  /**
   * Client supports the paging of variables.
   */
  supportsVariablePaging?: boolean;

  /**
   * Client supports the `runInTerminal` request.
   */
  supportsRunInTerminalRequest?: boolean;

  /**
   * Client supports memory references.
   */
  supportsMemoryReferences?: boolean;

  /**
   * Client supports progress reporting.
   */
  supportsProgressReporting?: boolean;

  /**
   * Client supports the `invalidated` event.
   */
  supportsInvalidatedEvent?: boolean;

  /**
   * Client supports the `memory` event.
   */
  supportsMemoryEvent?: boolean;

  /**
   * Client supports the `argsCanBeInterpretedByShell` attribute on the
   * `runInTerminal` request.
   */
  supportsArgsCanBeInterpretedByShell?: boolean;

  /**
   * Client supports the `startDebugging` request.
   */
  supportsStartDebuggingRequest?: boolean;

  /**
   * The client will interpret ANSI escape sequences in the display of
   * `OutputEvent.output` and `Variable.value` fields when
   * `Capabilities.supportsANSIStyling` is also enabled.
   */
  supportsANSIStyling?: boolean;
}
```

--------------------------------

### StepInTarget Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Represents a potential target for a 'stepIn' operation, including its ID, label, and source location. This is used to guide the debugger into specific functions or code blocks.

```typescript
interface StepInTarget {
  /**
   * Unique identifier for a step-in target.
   */
  id: number;

  /**
   * The name of the step-in target (shown in the UI).
   */
  label: string;

  /**
   * The line of the step-in target.
   */
  line?: number;

  /**
   * Start position of the range covered by the step in target. It is measured
   * in UTF-16 code units and the client capability `columnsStartAt1` determines
   * whether it is 0- or 1-based.
   */
  column?: number;

  /**
   * The end line of the range covered by the step-in target.
   */
  endLine?: number;

  /**
   * End position of the range covered by the step in target. It is measured in
   * UTF-16 code units and the client capability `columnsStartAt1` determines
   * whether it is 0- or 1-based.
   */
  endColumn?: number;
}
```

--------------------------------

### StartDebuggingResponse Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Defines the response for the `startDebugging` request, which is an acknowledgement and does not require a body.

```typescript
interface StartDebuggingResponse extends Response {
}
```

--------------------------------

### Get Data Breakpoint Information

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Use this request to obtain information on a possible data breakpoint that could be set on an expression or variable. Clients should only call this if `supportsDataBreakpoints` capability is true.

```typescript
interface DataBreakpointInfoRequest extends Request {
  command: 'dataBreakpointInfo';

  arguments: DataBreakpointInfoArguments;
}

interface DataBreakpointInfoArguments {
  /**
   * Reference to the variable container if the data breakpoint is requested for
   * a child of the container. The `variablesReference` must have been obtained
   * in the current suspended state. See 'Lifetime of Object References' in the
   * Overview section for details.
   */
  variablesReference?: number;

  /**
   * The name of the variable's child to obtain data breakpoint information for.
   * If `variablesReference` isn't specified, this can be an expression, or an
   * address if `asAddress` is also true.
   */
  name: string;

  /**
   * When `name` is an expression, evaluate it in the scope of this stack frame.
   * If not specified, the expression is evaluated in the global scope. When
   * `variablesReference` is specified, this property has no effect.
   */
  frameId?: number;

  /**
   * If specified, a debug adapter should return information for the range of
   * memory extending `bytes` number of bytes from the address or variable
   * specified by `name`. Breakpoints set using the resulting data ID should
   * pause on data access anywhere within that range.
   * 
   * Clients may set this property only if the `supportsDataBreakpointBytes`
   * capability is true.
   */
  bytes?: number;

  /**
   * If `true`, the `name` is a memory address and the debugger should interpret
   * it as a decimal value, or hex value if it is prefixed with `0x`.
   * 
   * Clients may set this property only if the `supportsDataBreakpointBytes`
   * capability is true.
   */
  asAddress?: boolean;

  /**
   * The mode of the desired breakpoint. If defined, this must be one of the
   * `breakpointModes` the debug adapter advertised in its `Capabilities`.
   */
  mode?: string;
}

interface DataBreakpointInfoResponse extends Response {
  body: {
    /**
     * An identifier for the data on which a data breakpoint can be registered
     * with the `setDataBreakpoints` request or null if no data breakpoint is
     * available. If a `variablesReference` or `frameId` is passed, the `dataId`
     * is valid in the current suspended state, otherwise it's valid
     * indefinitely. See 'Lifetime of Object References' in the Overview section
     * for details. Breakpoints set using the `dataId` in the
     * `setDataBreakpoints` request may outlive the lifetime of the associated
     * `dataId`.
     */
    dataId: string | null;

    /**
     * UI string that describes on what data the breakpoint is set on or why a
     * data breakpoint is not available.
     */
    description: string;

    /**
     * Attribute lists the available access types for a potential data
     * breakpoint. A UI client could surface this information.
     */
    accessTypes?: DataBreakpointAccessType[];

    /**
     * Attribute indicates that a potential data breakpoint could be persisted
     * across sessions.
     */
    canPersist?: boolean;
  };
}
```

--------------------------------

### Goto

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Sets the location where the debuggee will continue to run. The code between the current location and the goto target is skipped.

```APIDOC
## goto

### Description
Sets the location where the debuggee will continue to run. This makes it possible to skip the execution of code or to execute code again. The code between the current location and the goto target is not executed but skipped. The debug adapter first sends the response and then a `stopped` event with reason `goto`. Clients should only call this request if the corresponding capability `supportsGotoTargetsRequest` is true.

### Method
POST

### Endpoint
/goto

### Arguments
#### Path Parameters
- None

#### Query Parameters
- None

#### Request Body
- **threadId** (number) - Required - Set the goto target for this thread.
- **targetId** (number) - Required - The location where the debuggee will continue to run.

### Request Example
```json
{
  "command": "goto",
  "arguments": {
    "threadId": 1,
    "targetId": 5
  }
}
```

### Response
#### Success Response (200)
- None (acknowledgement only)

#### Response Example
```json
{
  "success": true
}
```
```

--------------------------------

### Process Event Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Defines the structure for the 'process' event, which is sent when the debugger starts debugging a new process. It includes details like the process name, system ID, and launch method.

```typescript
interface ProcessEvent extends Event {
  event: 'process';

  body: {
    /**
     * The logical name of the process. This is usually the full path to
     * process's executable file. Example: /home/example/myproj/program.js.
     */
    name: string;

    /**
     * The process ID of the debugged process, as assigned by the operating
     * system. This property should be omitted for logical processes that do not
     * map to operating system processes on the machine.
     */
    systemProcessId?: number;

    /**
     * If true, the process is running on the same computer as the debug
     * adapter.
     */
    isLocalProcess?: boolean;

    /**
     * Describes how the debug engine started debugging this process.
     * Values:
     * 'launch': Process was launched under the debugger.
     * 'attach': Debugger attached to an existing process.
     * 'attachForSuspendedLaunch': A project launcher component has launched a
     * new process in a suspended state and then asked the debugger to attach.
     */
    startMethod?: 'launch' | 'attach' | 'attachForSuspendedLaunch';

    /**
     * The size of a pointer or address for this process, in bits. This value
     * may be used by clients when formatting addresses for display.
     */
    pointerSize?: number;
  };
}
```

--------------------------------

### GotoTargetsResponse

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

Response to the `gotoTargets` request, containing an array of possible goto targets.

```APIDOC
## GotoTargetsResponse

### Description
Response to `gotoTargets` request.

### Success Response (200)
- **targets** (array) - The possible goto targets of the specified location.
```

--------------------------------

### gotoTargets

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Retrieves the possible goto targets for the specified source location. Clients should only call this request if the corresponding capability `supportsGotoTargetsRequest` is true.

```APIDOC
## gotoTargets

### Description
This request retrieves the possible goto targets for the specified source location. These targets can be used in the `goto` request. Clients should only call this request if the corresponding capability `supportsGotoTargetsRequest` is true.

### Arguments
- **source** (Source) - Required - The source location for which the goto targets are determined.
- **line** (number) - Required - The line location for which the goto targets are determined.
- **column** (number) - Optional - The position within `line` for which the goto targets are determined. It is measured in UTF-16 code units and the client capability `columnsStartAt1` determines whether it is 0- or 1-based.

### Response
#### Success Response
- **targets** (GotoTarget[]) - The possible goto targets of the specified location.
```

--------------------------------

### GotoTargetsRequest

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

Retrieves the possible goto targets for a specified source location. Clients should only call this request if the corresponding capability `supportsGotoTargetsRequest` is true.

```APIDOC
## GotoTargetsRequest

### Description
This request retrieves the possible goto targets for the specified source location. These targets can be used in the `goto` request. Clients should only call this request if the corresponding capability `supportsGotoTargetsRequest` is true.

### Method
POST

### Endpoint
/gotoTargets

### Parameters
#### Request Body
- **source** (Source) - Required - The source location for which the goto targets are determined.
- **line** (integer) - Required - The line location for which the goto targets are determined.
- **column** (integer) - Optional - The position within `line` for which the goto targets are determined. It is measured in UTF-16 code units and the client capability `columnsStartAt1` determines whether it is 0- or 1-based.
```

--------------------------------

### Arguments for Goto Targets Request

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Specifies the arguments required for the 'gotoTargets' request, including source location details.

```typescript
interface GotoTargetsArguments {
  /**
   * The source location for which the goto targets are determined.
   */
  source: Source;

  /**
   * The line location for which the goto targets are determined.
   */
  line: number;

  /**
   * The position within `line` for which the goto targets are determined. It is
   * measured in UTF-16 code units and the client capability `columnsStartAt1`
   * determines whether it is 0- or 1-based.
   */
  column?: number;
}
```

--------------------------------

### Initialize Request Interface

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Defines the structure for the 'initialize' request, which is the first communication from the client to the debug adapter. It's used to exchange client and adapter capabilities. No other requests or events should be sent until this is acknowledged.

```typescript
interface InitializeRequest extends Request {
  command: 'initialize';

  arguments: InitializeRequestArguments;
}
```

--------------------------------

### ExceptionOptions

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Assigns configuration options to a set of exceptions, including a path and break mode.

```APIDOC
## ExceptionOptions

### Description
An `ExceptionOptions` assigns configuration options to a set of exceptions.

### Interface
```typescript
interface ExceptionOptions {
  /**
   * A path that selects a single or multiple exceptions in a tree. If `path` is
   * missing, the whole tree is selected.
   * By convention the first segment of the path is a category that is used to
   * group exceptions in the UI.
   */
  path?: ExceptionPathSegment[];

  /**
   * Condition when a thrown exception should result in a break.
   */
  breakMode: ExceptionBreakMode;
}
```
```

--------------------------------

### source

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Retrieves the source code for a given source reference.

```APIDOC
## source

### Description
The request retrieves the source code for a given source reference.

### Method
Not specified (typically a command in a protocol)

### Arguments
- **source** (Source) - Optional - Specifies the source content to load. Either `source.path` or `source.sourceReference` must be specified.
- **sourceReference** (number) - Required - The reference to the source. This is the same as `source.sourceReference`. This is provided for backward compatibility since old clients do not understand the `source` attribute.

### Response
#### Success Response
- **content** (string) - Content of the source reference.
- **mimeType** (string) - Optional - Content type (MIME type) of the source.
```

--------------------------------

### ConfigurationDoneArguments

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

Arguments for the `configurationDone` request.

```APIDOC
## ConfigurationDoneArguments

### Description
Arguments for `configurationDone` request.

### Properties
(No specific properties defined in the source)
```

--------------------------------

### Request

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

Represents a request initiated by either the client or the debug adapter. It includes a command and optional arguments.

```APIDOC
## Request

### Description
A client or debug adapter initiated request.

### Properties
- **type** (string) - Required - Must be `request`.
- **command** (string) - Required - The command to execute.
- **arguments** (any) - Optional - Object containing arguments for the command.
```

--------------------------------

### goto Request

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

The 'goto' request sets the location where the debuggee will continue to run, allowing for skipping or re-executing code. The debug adapter responds with a 'stopped' event with reason 'goto'. This request should only be called if the 'supportsGotoTargetsRequest' capability is true.

```APIDOC
## goto Request

### Description
Sets the location where the debuggee will continue to run. This makes it possible to skip the execution of code or to execute code again. The code between the current location and the goto target is not executed but skipped. The debug adapter first sends the response and then a `stopped` event with reason `goto`.

### Method
POST (implied, as it's a command request)

### Endpoint
(Not specified, typically sent over a communication channel)

### Parameters
#### Request Body
- **command** (string) - Required - Must be "goto"
- **arguments** (object) - Required - Arguments for the goto request.
  - **threadId** (integer) - Required - Set the goto target for this thread.
  - **targetId** (integer) - Required - The location where the debuggee will continue to run.

### Response
#### Success Response
- (No specific body required, acknowledgement)

### Notes
Clients should only call this request if the corresponding capability `supportsGotoTargetsRequest` is true.
```

--------------------------------

### StepIn Command

Source: https://microsoft.github.io/debug-adapter-protocol/debugAdapterProtocol.json

The `stepIn` request resumes the given thread to step into a function/method. It allows all other threads to run freely. If the debug adapter supports single thread execution, setting `singleThread` to true prevents other suspended threads from resuming. If the request cannot step into a target, `stepIn` behaves like the `next` request. The debug adapter first sends the response and then a `stopped` event after the step has completed. The `targetId` argument can be used to control into which target the `stepIn` should occur.

```APIDOC
## POST /stepIn

### Description
Resumes the given thread to step into a function or method.

### Method
POST

### Endpoint
/stepIn

### Parameters
#### Request Body
- **command** (string) - Required - The command to execute, must be "stepIn".
- **arguments** (object) - Required - Arguments for the stepIn request.
  - **threadId** (integer) - Required - Specifies the thread for which to resume execution for one step-into.
  - **singleThread** (boolean) - Optional - If true, all other suspended threads are not resumed.
  - **targetId** (integer) - Optional - Id of the target to step into.
  - **granularity** (SteppingGranularity) - Optional - Stepping granularity. Defaults to `statement` if not specified.

### Request Example
```json
{
  "seq": 0,
  "type": "request",
  "command": "stepIn",
  "arguments": {
    "threadId": 1,
    "targetId": 10
  }
}
```

### Response
#### Success Response (200)
- **success** (boolean) - Indicates if the request was successful.
- **message** (string) - Optional - Contains an error message if the request failed.

#### Response Example
```json
{
  "seq": 1,
  "type": "response",
  "request_seq": 0,
  "success": true
}
```
```

--------------------------------

### completions

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Returns a list of possible completions for a given caret position and text. Clients should only call this request if the corresponding capability `supportsCompletionsRequest` is true.

```APIDOC
## completions

### Description
Returns a list of possible completions for a given caret position and text. Clients should only call this request if the corresponding capability `supportsCompletionsRequest` is true.

### Arguments
- **frameId** (number) - Optional - Returns completions in the scope of this stack frame. If not specified, the completions are returned for the global scope.
- **text** (string) - Required - One or more source lines. Typically this is the text users have typed into the debug console before they asked for completion.
- **column** (number) - Required - The position within `text` for which to determine the completion proposals. It is measured in UTF-16 code units and the client capability `columnsStartAt1` determines whether it is 0- or 1-based.
- **line** (number) - Optional - A line for which to determine the completion proposals. If missing the first line of the text is assumed.

### Response
#### Success Response
- **targets** (CompletionItem[]) - The possible completions for .
```

--------------------------------

### modules

Source: https://microsoft.github.io/debug-adapter-protocol/specification.html

Retrieves modules from the debug adapter. This can return all modules or a range of modules to support paging. Clients should only call this request if the `supportsModulesRequest` capability is true.

```APIDOC
## modules

### Description
Retrieves modules from the debug adapter, supporting retrieval of all modules or a range for paging.

### Command
`modules`

### Arguments
#### Query Parameters
- **startModule** (number) - Optional - The index of the first module to return; if omitted modules start at 0.
- **moduleCount** (number) - Optional - The number of modules to return. If `moduleCount` is not specified or 0, all modules are returned.

### Response
#### Success Response (200)
- **modules** (Module[]) - All modules or range of modules.
- **totalModules** (number) - The total number of modules available.
```