### Install and Configure Ollama Models

Source: https://chunkhound.github.io/quickstart

Installs Ollama, pulls specific embedding and reranker models, and starts the Ollama server. This is for local/offline embedding.

```shell
# Install Ollama (see https://ollama.ai/)
# Pull the best embedding and reranker models
ollama pull dengcao/Qwen3-Embedding-8B:Q5_K_M
ollama pull dengcao/Qwen3-Reranker-4B:Q5_K_M
ollama serve  # Keep this running
```

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

### Verify ChunkHound Installation

Source: https://chunkhound.github.io/quickstart

Checks if ChunkHound has been installed correctly by displaying its version number.

```shell
chunkhound --version
# Should show: chunkhound x.x.x
```

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

### Install ChunkHound

Source: https://chunkhound.github.io/quickstart

Installs the ChunkHound tool using the uv package manager. This command makes ChunkHound available globally.

```shell
uv tool install chunkhound
```

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

### Install uv Package Manager (Windows)

Source: https://chunkhound.github.io/quickstart

Installs the uv package manager on Windows using PowerShell. This is a prerequisite for installing ChunkHound.

```powershell
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
```

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

### Install uv Package Manager (macOS/Linux)

Source: https://chunkhound.github.io/quickstart

Installs the uv package manager using a curl command. This is a prerequisite for installing ChunkHound.

```shell
curl -LsSf https://astral.sh/uv/install.sh | sh
```

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

### Configure ChunkHound with OpenAI (JSON)

Source: https://chunkhound.github.io/quickstart

Manual JSON configuration for ChunkHound to use OpenAI as the embedding provider. Requires an API key.

```json
{
  "embedding": {
    "provider": "openai",
    "api_key": "sk-your-openai-key"
  }
}
```

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

### Index Your Codebase with ChunkHound

Source: https://chunkhound.github.io/quickstart

Command to initiate the indexing process for your project's codebase using ChunkHound. It automatically respects .gitignore and supports incremental updates.

```shell
cd /path/to/your/project
chunkhound index
```

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

### Configure ChunkHound with VoyageAI (JSON)

Source: https://chunkhound.github.io/quickstart

Manual JSON configuration for ChunkHound to use VoyageAI as the embedding provider. Requires an API key.

```json
{
  "embedding": {
    "provider": "voyageai",
    "api_key": "pa-your-voyage-key"
  }
}
```

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

### Add ChunkHound MCP Server via Claude CLI

Source: https://chunkhound.github.io/quickstart

Command to add ChunkHound as an MCP server using the Claude CLI, simplifying AI assistant integration.

```shell
# Run this in your project directory
claude mcp add ChunkHound chunkhound mcp
```

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

### Configure ChunkHound with Ollama (JSON)

Source: https://chunkhound.github.io/quickstart

Manual JSON configuration for ChunkHound to use Ollama for embedding and reranking. Includes model and URL details.

```json
{
  "embedding": {
    "provider": "openai",
    "base_url": "http://localhost:11434/v1",
    "model": "dengcao/Qwen3-Embedding-8B:Q5_K_M",
    "api_key": "dummy-key",
    "rerank_model": "dengcao/Qwen3-Reranker-4B:Q5_K_M",
    "rerank_url": "http://localhost:8000/rerank"
  }
}
```

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

### Starting ChunkHound MCP stdio Mode

Source: https://chunkhound.github.io/how-to

This command starts the ChunkHound Multi-Client Process (MCP) server in stdio mode. This mode is ideal for personal development where the IDE handles server startup and shutdown, keeping the index in memory for instant searches.

```bash
chunkhound mcp /path/to/project

```

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

### Add ChunkHound MCP Server for Cursor

Source: https://chunkhound.github.io/quickstart

Configuration to add ChunkHound as a Multi-Codebase Plugin (MCP) server within Cursor's settings.

```json
{
  "mcpServers": {
    "chunkhound": {
      "command": "chunkhound",
      "args": ["mcp", "/path/to/your/project"]
    }
  }
}
```

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

### Add ChunkHound MCP Server for VS Code

Source: https://chunkhound.github.io/quickstart

Configuration to add ChunkHound as a Multi-Codebase Plugin (MCP) server within VS Code's settings.

```json
{
  "servers": {
    "chunkhound": {
      "type": "stdio",
      "command": "chunkhound",
      "args": ["mcp", "/path/to/your/project"]
    }
  }
}
```

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

### Starting ChunkHound MCP HTTP Mode

Source: https://chunkhound.github.io/how-to

This command starts the ChunkHound MCP server in HTTP mode, allowing multiple IDEs to connect to a shared server. It is suitable for team use or when switching between multiple git worktrees. The --port flag specifies the port for the HTTP server.

```bash
chunkhound mcp /path/to/project --http --port 8000
# Connect IDEs to http://localhost:8000

```

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

### Example Rate Limiting Implementation (TypeScript)

Source: https://chunkhound.github.io/code-research

A TypeScript code snippet demonstrating how to reuse the rate limiting middleware. This example shows the configuration parameters for `windowMs` and `max` requests.

```typescript
app.use('/api/new-endpoint', rateLimiter({
  windowMs: 15 * 60 * 1000,
  max: 100
}));
```

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

### Initial ChunkHound Indexing Command

Source: https://chunkhound.github.io/how-to

This command initiates the indexing process for a large codebase. It scans files, processes them based on language, and generates chunks and embeddings. The output shows the number of files processed, chunks indexed, embeddings generated, and the total time taken.

```bash
$ chunkhound index /path/to/large-codebase
Scanning 10,000 files...
Processing 8,234 Python files, 1,766 TypeScript files...
✓ 45,000 chunks indexed
✓ Embeddings: 45,000 generated
⏱️  Time: 7m 30s

```

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

### Example Rate Limiting Research Output (Markdown)

Source: https://chunkhound.github.io/code-research

This is an example of the structured markdown report generated by Code Research. It includes an overview, core components with file citations, usage patterns, and implementation recommendations for rate limiting.

```markdown
## Rate Limiting Architecture


### Overview
The application implements token bucket rate limiting using Redis for distributed state.
Rate limiting is applied at the middleware layer with per-endpoint configuration.


### Core Components


**RateLimitMiddleware** (`src/middleware/ratelimit.ts:45-120`)
- Token bucket algorithm with sliding window
- Redis-based distributed counters
- Custom headers for limit status
- Applied to 12 API endpoints

**Configuration** (`config/limits.yaml:1-30`)
- Per-endpoint rate definitions
- Default: 100 requests per 15-minute window
- Environment-based overrides supported


### Usage Pattern


Found across these endpoints:
- `POST /api/auth/login` - 5 requests/min (src/routes/auth.ts:23)
- `POST /api/users/create` - 10 requests/min (src/routes/users.ts:45)
- `GET /api/data/*` - 100 requests/min (src/routes/data.ts:67)


### Implementation Recommendation


Reuse existing middleware for new endpoints:


```typescript
app.use('/api/new-endpoint', rateLimiter({
  windowMs: 15 * 60 * 1000,
  max: 100
}));
```


### Key Files
- `src/middleware/ratelimit.ts` - Core implementation
- `src/services/redis.ts:89-145` - Redis client
- `config/limits.yaml` - Configuration
- `tests/middleware/ratelimit.test.ts` - Test examples

```

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

### iptables Examples for Service Load Balancing and DNAT

Source: https://chunkhound.github.io/benchmark-responses/test4-chunkhound

Provides concrete examples of iptables rules generated by kube-proxy for service load balancing and Destination Network Address Translation (DNAT). These rules demonstrate how incoming service traffic is directed to specific endpoints.

```iptables
# Service load balancing
-A KUBE-SERVICES -m comment --comment "ns1/svc1:p80 cluster IP" \
  -m tcp -p tcp -d 10.20.30.41 --dport 80 -j KUBE-SVC-XPGD46QRK7WJZT7O


# DNAT to endpoint
-A KUBE-SEP-SXIVWICOYRO3J4NJ -m comment --comment ns1/svc1:p80 \
  -m tcp -p tcp -j DNAT --to-destination 10.180.0.1:80
```

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

### Multi-Hop BFS Traversal Query Example

Source: https://chunkhound.github.io/code-research

Demonstrates the multi-hop breadth-first search traversal algorithm used by ChunkHound's Code Research system. Starting from an initial query about authentication error handling, the system explores semantic relationships across three levels: direct matches, connected components, and architectural relationships. Each level discovers new code entities through semantic similarity and architectural connections.

```text
Query: "authentication error handling"


Level 0: Direct matches
  → auth_error_handler()
  → validate_credentials()


Level 1: Connected components (semantic neighbors)
  → error_logger() (shares error handling patterns)
  → token_validator() (shares auth validation logic)


Level 2: Architectural relationships
  → database_retry() (error logger uses it)
  → session_cleanup() (token validator calls it)
```

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

### Naive Fixed-Size Chunking Example (Python)

Source: https://chunkhound.github.io/under-the-hood

Demonstrates a basic approach to code chunking where code is split at fixed character intervals. This method can lead to breaking logical code structures, as shown by the function being cut mid-definition.

```python
def authenticate_user(username, password):
    if not username or not password:
        return False


    hashed = hash_password(password)
    user = database.get_u
# CHUNK BOUNDARY CUTS HERE ❌
ser(username)
    return user and user.password_hash == hashed
```

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

### Naive AST Chunking Example (Python)

Source: https://chunkhound.github.io/under-the-hood

Illustrates splitting code only at function or class boundaries. This approach can result in chunks that are either too small (e.g., tiny functions) or excessively large, potentially exceeding context window limits.

```python
# Chunk 1: Tiny function (50 characters)
def get_name(self):
    return self.name


# Chunk 2: Massive function (5000 characters)
def process_entire_request(self, request):
    # ... 200 lines of complex logic ...
```

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

### Dataplane Rule Examples for NetworkPolicy Enforcement

Source: https://chunkhound.github.io/benchmark-responses/test4-standard

Provides examples of how NetworkPolicies are translated into actual dataplane rules. The Calico example shows generated iptables rules for accepting specific traffic and then dropping all other traffic. The Cilium example illustrates a simplified eBPF program logic for allowing or dropping packets based on policy lookups.

```shell
# Generated iptables rules
-A cali-fw-cali1234567890 -m set --match-set cali40s:label-app=frontend src -p tcp --dport 8080 -j ACCEPT
-A cali-fw-cali1234567890 -j DROP

```

```c
// eBPF program (simplified)
if (policy_lookup(src_identity, dst_identity, protocol, port) == ALLOW) {
    return TC_ACT_OK;
}
return TC_ACT_SHOT;

```

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

### Calico iptables Rule Generation Example

Source: https://chunkhound.github.io/benchmark-responses/test4-standard

This example demonstrates how Calico generates iptables rules for NetworkPolicy enforcement. It includes rules for allowing established connections, permitting traffic from specific labeled sources to a destination port, and finally dropping all other traffic. This rule set is applied to the `cali-fw-*` chains managed by Calico.

```iptables
# Generated for NetworkPolicy allowing port 80 from specific labels
-A cali-fw-cali1234567890 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A cali-fw-cali1234567890 -m set --match-set cali40s:label-app=frontend src -p tcp --dport 80 -j ACCEPT
-A cali-fw-cali1234567890 -j DROP
```

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

### Smart cAST Algorithm Chunking Example (Python)

Source: https://chunkhound.github.io/under-the-hood

Presents the cAST algorithm's approach to code chunking, which respects both code boundaries and enforces size limits. This method aims to create meaningful, right-sized chunks by intelligently splitting or merging code elements.

```python
# Right-sized chunks that preserve meaning
def authenticate_user(username, password):    # ✅ Complete function
    if not username or not password:          #    fits in one chunk
        return False
    hashed = hash_password(password)
    user = database.get_user(username)
    return user and user.password_hash == hashed


def hash_password(password):                  # ✅ Small adjacent functions
def validate_email(email):                   #    merged together
def sanitize_input(data):
    # All fit together in one chunk
```

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

### Configure OpenAI LLM Provider with API Key

Source: https://chunkhound.github.io/code-research

Configures ChunkHound to use OpenAI as the LLM provider with direct API authentication. This setup is recommended for users without CLI subscriptions. Requires a valid OpenAI API key to be provided in the configuration.

```json
{
  "llm": {
    "provider": "openai",
    "api_key": "sk-your-key"
  }
}
```

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

### OpenAI Embedding Configuration

Source: https://chunkhound.github.io/configuration

Configuration example for using OpenAI as the embedding provider. This includes the provider, API key, and desired model. Suitable for broad compatibility and ecosystem support.

```json
{
  "embedding": {
    "provider": "openai",
    "api_key": "sk-your-openai-key",
    "model": "text-embedding-3-small"
  }
}
```

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

### Controller Reference Manager Adoption Check (Go)

Source: https://chunkhound.github.io/benchmark-responses/test2-standard

The CanAdopt function from the BaseControllerRefManager ensures that a controller is capable of adopting a resource. It uses `sync.Once` to perform the check only once and calls a provided `CanAdoptFunc` for specific adoption logic. Returns an error if adoption is not permitted.

```go
func (m *BaseControllerRefManager) CanAdopt(ctx context.Context) error {
    m.canAdoptOnce.Do(func() {
        if m.CanAdoptFunc != nil {
            m.canAdoptErr = m.CanAdoptFunc(ctx)
        }
    })
    return m.canAdoptErr
}
```

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

### Kubernetes Deployment Controller Reconcile Loop (Go)

Source: https://chunkhound.github.io/benchmark-responses/test2-standard

Details the main reconcile loop (`syncDeployment`) for the Deployment controller. It outlines the steps involved: fetching the deployment, performing a deep copy, reconciling ReplicaSets, handling deletion and paused states, and executing strategy-specific rollout logic (Recreate and RollingUpdate).

```Go
func (dc *DeploymentController) syncDeployment(ctx context.Context, key string) error {
    // 1. Get deployment from cache
    deployment, err := dc.dLister.Deployments(namespace).Get(name)


    // 2. Deep copy to avoid cache mutation
    d := deployment.DeepCopy()


    // 3. Get and reconcile ReplicaSets
    rsList, err := dc.getReplicaSetsForDeployment(ctx, d)


    // 4. Handle different scenarios:
    if d.DeletionTimestamp != nil {
        return dc.syncStatusOnly(ctx, d, rsList)
    }


    if d.Spec.Paused {
        return dc.sync(ctx, d, rsList)
    }


    if getRollbackTo(d) != nil {
        return dc.rollback(ctx, d, rsList)
    }


    // 5. Execute strategy-specific logic
    switch d.Spec.Strategy.Type {
    case apps.RecreateDeploymentStrategyType:
        return dc.rolloutRecreate(ctx, d, rsList, podMap)
    case apps.RollingUpdateDeploymentStrategyType:
        return dc.rolloutRolling(ctx, d, rsList)
    }
}
```

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

### Kubernetes Deployment Controller Core Structure (Go)

Source: https://chunkhound.github.io/benchmark-responses/test2-standard

Defines the core structure of the Deployment controller, including its dependencies on ReplicaSet control, Kubernetes clients, event broadcasting, caching mechanisms (listers), and the work queue for event processing. This structure is fundamental to how the controller manages deployments.

```Go
type DeploymentController struct {
    rsControl controller.RSControlInterface
    client    clientset.Interface


    eventBroadcaster record.EventBroadcaster
    eventRecorder    record.EventRecorder


    syncHandler func(ctx context.Context, dKey string) error


    // Listers for cached reads
    dLister appslisters.DeploymentLister
    rsLister appslisters.ReplicaSetLister
    podLister corelisters.PodLister


    // Sync status tracking
    dListerSynced cache.InformerSynced
    rsListerSynced cache.InformerSynced
    podListerSynced cache.InformerSynced


    // Work queue for processing events
    queue workqueue.TypedRateLimitingInterface[string]
}
```

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

### ReplicaSet Controller Reconcile Loop (Go)

Source: https://chunkhound.github.io/benchmark-responses/test2-standard

The main entry point for the ReplicaSet controller's synchronization loop. It fetches the ReplicaSet, checks if its expectations are met, claims existing pods, manages the replica count if necessary, and updates the ReplicaSet's status. Dependencies include Kubernetes client and cache access.

```go
func (rsc *ReplicaSetController) syncReplicaSet(ctx context.Context, key string) error {
    // 1. Get ReplicaSet from cache
    rs, err := rsc.rsLister.ReplicaSets(namespace).Get(name)


    // 2. Check if expectations are satisfied
    rsNeedsSync := rsc.expectations.SatisfiedExpectations(logger, key)


    // 3. Get pods controlled by this ReplicaSet
    activePods, err := rsc.claimPods(ctx, rs, selector, allActivePods)


    // 4. Manage replica count if needed
    if rsNeedsSync && rs.DeletionTimestamp == nil {
        manageReplicasErr = rsc.manageReplicas(ctx, activePods, rs)
    }


    // 5. Update status
    newStatus := calculateStatus(rs, activePods, terminatingPods, manageReplicasErr, rsc.controllerFeatures, now)
    updatedRS, err := updateReplicaSetStatus(logger, rsc.kubeClient.AppsV1().ReplicaSets(rs.Namespace), rs, newStatus, rsc.controllerFeatures)


    return nil
}
```

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

### Configure OpenAI LLM

Source: https://chunkhound.github.io/configuration

Sets up the LLM provider to use OpenAI's API. This configuration requires an API key and allows specifying different models for utility ('gpt-5-nano') and synthesis ('gpt-5') operations to optimize for cost and performance. It is suitable for users without Claude Code or Codex CLI subscriptions.

```json
{
  "llm": {
    "provider": "openai",
    "api_key": "sk-your-openai-key",
    "utility_model": "gpt-5-nano",
    "synthesis_model": "gpt-5"
  }
}
```

```bash
export CHUNKHOUND_LLM_PROVIDER=openai
export CHUNKHOUND_LLM_API_KEY=sk-your-key
export CHUNKHOUND_LLM_UTILITY_MODEL=gpt-5-nano
export CHUNKHOUND_LLM_SYNTHESIS_MODEL=gpt-5
```

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

### VoyageAI Embedding Configuration

Source: https://chunkhound.github.io/configuration

Configuration example for using VoyageAI as the embedding provider. This specifies the provider, API key, model, and reranking model. It's optimized for accuracy and code understanding.

```json
{
  "embedding": {
    "provider": "voyageai",
    "api_key": "pa-your-voyage-key",
    "model": "voyage-3.5",
    "rerank_model": "rerank-lite-1"
  }
}
```

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

### Rolling Update Reconciliation Logic (Go)

Source: https://chunkhound.github.io/benchmark-responses/test2-chunkhound

Illustrates the key steps in the rolling update reconciliation process for Deployments. It shows how the controller scales up new ReplicaSets and scales down old ones, considering various parameters like availability constraints, maxUnavailable, and maxSurge. This logic is crucial for achieving zero-downtime deployments.

```go
// Scale up, if we can.
scaledUp, err := dc.reconcileNewReplicaSet(ctx, allRSs, newRS, d)
// Scale down, if we can.
scaledDown, err := dc.reconcileOldReplicaSets(ctx, allRSs,
    controller.FilterActiveReplicaSets(oldRSs), newRS, d)
```

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

### Configure Ollama LLM

Source: https://chunkhound.github.io/configuration

Configures the LLM provider to use Ollama for local model deployment. This setup is ideal for privacy-conscious users or those preferring offline usage. It requires setting the base URL for the Ollama service and can specify different models for utility and synthesis, such as 'llama3.2'.

```json
{
  "llm": {
    "provider": "ollama",
    "base_url": "http://localhost:11434/v1",
    "utility_model": "llama3.2",
    "synthesis_model": "llama3.2"
  }
}
```

```bash
export CHUNKHOUND_LLM_PROVIDER=ollama
export CHUNKHOUND_LLM_BASE_URL=http://localhost:11434/v1
```

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

### Kubernetes Deployment Controller Worker Pattern (Go)

Source: https://chunkhound.github.io/benchmark-responses/test2-standard

Implements the worker and processNextWorkItem functions for the Deployment controller. The worker continuously processes items from the queue, and processNextWorkItem retrieves an item, executes the syncHandler, and handles any resulting errors. This pattern ensures efficient and resilient event processing.

```Go
func (dc *DeploymentController) worker(ctx context.Context) {
    for dc.processNextWorkItem(ctx) {
    }
}


func (dc *DeploymentController) processNextWorkItem(ctx context.Context) bool {
    key, quit := dc.queue.Get()
    if quit {
        return false
    }
    defer dc.queue.Done(key)


    err := dc.syncHandler(ctx, key)
    dc.handleErr(ctx, err, key)


    return true
}
```

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

### Calico Node DaemonSet Configuration (YAML)

Source: https://chunkhound.github.io/benchmark-responses/test4-chunkhound

Example YAML configuration for the Calico Node DaemonSet, illustrating how CNI plugins are deployed to manage network policy enforcement. It shows environment variables for CNI management and datastore type.

```yaml
containers:
- name: calico-node
  image: gcr.io/projectcalico-org/node:v3.19.1
  env:
    - name: CALICO_MANAGE_CNI
      value: "true"
    - name: DATASTORE_TYPE
      value: "kubernetes"
```

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

### Get Deployments for ReplicaSet in Go

Source: https://chunkhound.github.io/benchmark-responses/test2-standard

This Go method retrieves associated Deployments for a given ReplicaSet. It utilizes a Deployment lister and returns a slice of Deployments. The function logs a warning if more than one Deployment is found selecting the same ReplicaSet, as this indicates a user error.

```go
func (dc *DeploymentController) getDeploymentsForReplicaSet(logger klog.Logger, rs *apps.ReplicaSet) []*apps.Deployment {
    deployments, err := util.GetDeploymentsForReplicaSet(dc.dLister, rs)
    if err != nil || len(deployments) == 0 {
        return nil
    }
    // Because all ReplicaSet's belonging to a deployment should have a unique label key,
    // there should never be more than one deployment returned by the above method.
    if len(deployments) > 1 {
        logger.V(4).Info("user error! more than one deployment is selecting replica set")
    }
    return deployments
}
```

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

### Configure LLM for Code Research (JSON)

Source: https://chunkhound.github.io/code-research

This configuration snippet is required for Code Research to perform synthesis and analysis. It specifies the LLM provider to be used. Ensure this JSON is correctly placed within your `.chunkhound.json` file.

```json
{
  "llm": {
    "provider": "claude-code-cli"
  }
}
```

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

### Configure Mixed LLM Providers

Source: https://chunkhound.github.io/configuration

Enables advanced users to optimize cost and performance by combining different LLM providers for utility and synthesis operations. Examples include using Claude Code CLI for fast utility tasks and Codex CLI for high-effort synthesis, or OpenAI for utility and Codex CLI for synthesis.

```json
{
  "llm": {
    "utility_provider": "claude-code-cli",
    "synthesis_provider": "codex-cli",
    "codex_reasoning_effort_synthesis": "high"
  }
}
```

```json
{
  "llm": {
    "utility_provider": "openai",
    "synthesis_provider": "codex-cli",
    "utility_model": "gpt-5-nano",
    "api_key": "sk-your-openai-key",
    "codex_reasoning_effort_synthesis": "high"
  }
}
```

```bash
export CHUNKHOUND_LLM_UTILITY_PROVIDER=claude-code-cli
export CHUNKHOUND_LLM_SYNTHESIS_PROVIDER=codex-cli
export CHUNKHOUND_LLM_CODEX_REASONING_EFFORT_SYNTHESIS=high
```

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

### Perform Rollback to Target Revision in Go

Source: https://chunkhound.github.io/benchmark-responses/test2-standard

This Go function initiates a rollback process for a Deployment to a specified revision. It iterates through a list of ReplicaSets to find the one matching the target revision, then calls a helper function to perform the template and annotation restoration.

```go
func (dc *DeploymentController) rollback(ctx context.Context, d *apps.Deployment, rsList []*apps.ReplicaSet) error {
    // Find the target revision ReplicaSet
    for _, rs := range allRSs {
        v, err := deploymentutil.Revision(rs)
        if v == rollbackTo.Revision {
            // Copy template and annotations from target RS
            performedRollback, err := dc.rollbackToTemplate(ctx, d, rs)
            return err
        }
    }
    // If target revision not found, give up rollback
    return dc.updateDeploymentAndClearRollbackTo(ctx, d)
}
```