Fixing broken links and relative paths.

Author: hemang1729

docs/explorer/api/annotations.md

@@ -16,7 +16,7 @@ Annotations provide additional context, facilitating collaboration and agent err
 
 ## Annotation Format
 
-You can add annotations to traces at upload time. For this, both during [file upload](../uploading-traces/file-uploads) and via the [Push API](../uploading-traces/push-api), you can include an `annotations` field in the trace data. This field should be an array of objects, each representing an annotation. Each annotation object should have the following fields:
+You can add annotations to traces at upload time. For this, both during [file upload](uploading-traces/file-uploads.md) and via the [Push API](uploading-traces/push-api.md), you can include an `annotations` field in the trace data. This field should be an array of objects, each representing an annotation. Each annotation object should have the following fields:
 
 ##### `content` <span class='type'>string</span> <span class='required'/>
 

docs/explorer/api/uploading-traces/file-uploads.md

@@ -20,7 +20,7 @@ The explorer supports two types of trace formats: _raw event lists_ and _annotat
 
 #### Raw Event Lists
 
-Raw event lists are `jsonl` files where each line is a JSON array of events. Each event is a dictionary with at least a `role` and `content` field according to the trace format described [in this chapter](../../trace-format).
+Raw event lists are `jsonl` files where each line is a JSON array of events. Each event is a dictionary with at least a `role` and `content` field according to the trace format described [in this chapter](../trace-format.md).
 
 ```json
 [{ "role": "user", "content": "Hello, world!" }, { "role": "assistant", "content": "Hi!" }]
@@ -36,7 +36,7 @@ To include trace-level metadata in raw event lists, include a metadata JSON obje
 
 #### Annotated Event Lists
 
-Annotated event lists support the same format as raw event lists, but also include [annotations](../../annotations). 
+Annotated event lists support the same format as raw event lists, but also include [annotations](../annotations.md). 
 
 For this, each line is a JSON object with the fields `messages`, `annotations` (optional) and `metadata` (optional, for trace-level metadata).
 

docs/explorer/api/uploading-traces/push-api.md

@@ -24,7 +24,7 @@ The `PushTracesRequest` class holds the request data for a trace upload request.
 
 This represents the traces in a dataset. Each `List[Dict]` is a single trace within the dataset. Each `dict` is a single message within a trace - these can represet a user prompt, a tool call, a tool output, etc.
 
-Must be in the [required trace format](../../trace-format). Must not be empty.
+Must be in the [required trace format](../trace-format.md). Must not be empty.
 
 ##### `annotations` <span class='type'>Optional[List[List[AnnotationCreate]]</span> <span class='optional'/>
 
@@ -48,13 +48,13 @@ Must be a list of dictionaries if provided and must be the same length as messag
 
 Each metadata dictionary can have arbitrary keys and values for storing additional information about the trace.
 
-See [File Uploads](../file-uploads) for more information on metadata.
+See [File Uploads](file-uploads.md) for more information on metadata.
 
 ### `AnnotationCreate`
 
 The `AnnotationCreate` class holds the data for an annotation to be created.
 
-See [Annotations](../../annotations) for more information on annotations.
+See [Annotations](../annotations.md) for more information on annotations.
 
 ##### `content` <span class='type'>str</span> <span class='required'/>
 

docs/explorer/self-hosted.md

@@ -40,15 +40,15 @@ This will pull and launch the required Explorer Docker containers on your machin
 
 ## Using the Self-Hosted Explorer
 
-The self-hosted version of Explorer is configured to run on `http://localhost`. You can access it in your browser at this address. The local instance provides the same API as the managed cloud instance, so you can use the [Invariant SDK](./api/client-setup) to connect to it.
+The self-hosted version of Explorer is configured to run on `http://localhost`. You can access it in your browser at this address. The local instance provides the same API as the managed cloud instance, so you can use the [Invariant SDK](api/client-setup.md) to connect to it.
 
 ### Storage
 
 The self-hosted version of Explorer will create a `data/` directory in the current working directory to store traces and other data.
 
 ### Usage and Access
 
-You can access the self-hosted version of Explorer at `http://localhost`. To use it with the [Invariant SDK](./api/client-setup) you can set the `INVARIANT_API_ENDPOINT` environment variable to `http://localhost/`. For security reasons, you'll still need to create and provide an API key to access the self-hosted version of Explorer.
+You can access the self-hosted version of Explorer at `http://localhost`. To use it with the [Invariant SDK](api/client-setup.md) you can set the `INVARIANT_API_ENDPOINT` environment variable to `http://localhost/`. For security reasons, you'll still need to create and provide an API key to access the self-hosted version of Explorer.
 
 ### Updates
 `invariant explorer` will automatically check for updates and pull the latest stable version of the Explorer Docker images. If you want to try the latest development version, you can use the `--version=main` flag. Note however, that database migrations may be required when switching between versions, which may not always be backwards compatible.

docs/testing/index.md

@@ -6,7 +6,7 @@ title: Overview
 
 Invariant `testing` is a lightweight library to write and run AI agent tests. It provides helpers and assertions that enable you to write robust tests for your agentic applications.
 
-Using [**localized assertions**](Writing_Tests/1_Traces.ipynb), `testing` always points you to the exact part of the agent's behavior that caused a test to fail, making it easy to debug and resolve issues (_think: stacktraces for agents_).
+Using [**localized assertions**](writing/traces.ipynb), `testing` always points you to the exact part of the agent's behavior that caused a test to fail, making it easy to debug and resolve issues (_think: stacktraces for agents_).
 
 
 <br/>
@@ -82,11 +82,11 @@ ________________________________________________________________________________
 #     },
 #  ]
 ```
-The test result provides information about which assertion failed but also [localizes the assertion failure precisely](writing/tests) in the provided list of agent messages.
+The test result provides information about which assertion failed but also [localizes the assertion failure precisely](writing/tests.md) in the provided list of agent messages.
 
 **Visual Test Viewer (Explorer):**
 
-As an alternative to the command line, you can also [visualize test results](running/visual-debugging) on the [Invariant Explorer](https://explorer.invariantlabs.ai/):
+As an alternative to the command line, you can also [visualize test results](running/visual-debugging.md) on the [Invariant Explorer](https://explorer.invariantlabs.ai/):
 
 ```py
 $ invariant test --push
@@ -98,12 +98,12 @@ Like the terminal output, the Explorer highlights the relevant ranges, but does
 
 ## Features
 
-* Comprehensive [`Trace` API](writing/traces) for easily navigating and checking agent traces.
-* [Assertions library](writing/matchers) to check agent behavior, including fuzzy checkers such as _Levenshtein distance_, _semantic similarity_ and _LLM-as-a-judge_ pipelines.
-* Full [`pytest` compatibility](running/pytest-compatibility) for easy integration with existing test and CI/CD pipelines.
-* Parameterized tests for [testing multiple scenarios](writing/parameterized-tests) with a single test function.
-* [Visual test viewer](running/visual-debugging) for exploring large traces and debugging test failures.
+* Comprehensive [`Trace` API](writing/traces.ipynb) for easily navigating and checking agent traces.
+* [Assertions library](writing/matchers.md) to check agent behavior, including fuzzy checkers such as _Levenshtein distance_, _semantic similarity_ and _LLM-as-a-judge_ pipelines.
+* Full [`pytest` compatibility](running/pytest-compatibility.md) for easy integration with existing test and CI/CD pipelines.
+* Parameterized tests for [testing multiple scenarios](writing/parameterized-tests.md) with a single test function.
+* [Visual test viewer](running/visual-debugging.md) for exploring large traces and debugging test failures.
 
 ## Next Steps
 
-* [Quickstart Guide](./quickstart.md)
+* [Quickstart Guide](quickstart.md)

docs/testing/running/pytest-compatibility.md

@@ -8,7 +8,7 @@
 
 `invariant test` is a lightweight wrapper of the original `pytest` CLI. It is designed to be a drop-in replacement for `pytest` in your existing test suite.
 
-On top of the standard `pytest` arguments, `invariant test` supports the following extra arguments to enable [pushing to Explorer](./Visual_Debugger.md).
+On top of the standard `pytest` arguments, `invariant test` supports the following extra arguments to enable [pushing to Explorer](./visual-debugging.md).
 
 **Extra Arguments**
 

docs/testing/writing/integrate.md

@@ -36,44 +36,28 @@ Each message has a `role` key that specifies the role of the speaker (e.g., `use
 
 Based on this simple format, it is easy to integrate your agent with Invariant `testing`.
 
-> **Extended Format Support** `testing` also supports additional custom properties in the trace format, e.g. for metadata. Note, however, that convenience methods like `Trace.tool_calls()` assume the standard format. Similarly, if you are planning to visualize the trace in [Explorer](/explorer/), we advise you to stick to the standard format.
+> **Extended Format Support** `testing` also supports additional custom properties in the trace format, e.g. for metadata. Note, however, that convenience methods like `Trace.tool_calls()` assume the standard format. Similarly, if you are planning to visualize the trace in [Explorer](explorer/index.md), we advise you to stick to the standard format.
 
 To learn about how to do this, follow one of the example guides below:
 
 <div class='tiles'>
 
-<<<<<<< HEAD
-<a href="/docs/testing/Examples/computer-use/" class='tile primary'>
-=======
 <a href="/testing/examples/computer-use/" class='tile primary'>
->>>>>>> 068f461 (Add redirects so that we continue to support the older URLs till we move them to the new URLs.)
     <span class='tile-title'>Computer Use Agents →</span>
     <span class='tile-description'>Integrate your computer use agent with Invariant <code>testing</code></span>
 </a>
 
-<<<<<<< HEAD
-<a href="/docs/testing/Examples/langgraph/" class='tile primary'>
-=======
 <a href="/testing/examples/langgraph/" class='tile primary'>
->>>>>>> 068f461 (Add redirects so that we continue to support the older URLs till we move them to the new URLs.)
     <span class='tile-title'>LangGraph Agents →</span>
     <span class='tile-description'>Test your LangGraph agent with <code>testing</code></span>
 </a>
 
-<<<<<<< HEAD
-<a href="/docs/testing/Examples/openai-python-agent/" class='tile'>
-=======
 <a href="/testing/examples/openai-python-agent/" class='tile'>
->>>>>>> 068f461 (Add redirects so that we continue to support the older URLs till we move them to the new URLs.)
     <span class='tile-title'>Function Calling Agents →</span>
     <span class='tile-description'>Integrate your agent with Invariant <code>testing</code> using function calls</span>
 </a>
 
-<<<<<<< HEAD
-<a href="/docs/testing/Examples/swarm/" class='tile'>
-=======
 <a href="/testing/examples/swarm/" class='tile'>
->>>>>>> 068f461 (Add redirects so that we continue to support the older URLs till we move them to the new URLs.)
     <span class='tile-title'>Swarm Agents →</span>
     <span class='tile-description'>Test your swarm agent with Invariant <code>testing</code></span>
 </a>