docs: cleanup documents

benchmarks/README.md

@@ -29,7 +29,7 @@ lint or use rust-analyzer on the crate while in the workspace, so the recommende
 
 ### Adding the Benchmark
 
-Our proving benchmarks are written as standalone rust binaries. Add one by making a new file in [bin](./src/bin) by following the [fibonacci example](./bin/fibonacci.rs). We currently only run aggregation proofs when feature "aggregation" is on (off by default). Any general benchmarking utility functions can be added to the library in [`src`](./src). There are utility functions `build_bench_program` which compiles the guest program crate with target set to `openvm` and reads the output RISC-V ELF file.
+Our proving benchmarks are written as standalone rust binaries. Add one by making a new file in [bin](./src/bin) by following the [fibonacci example](./src/bin/fibonacci.rs). We currently only run aggregation proofs when feature "aggregation" is on (off by default). Any general benchmarking utility functions can be added to the library in [`src`](./src). There are utility functions `build_bench_program` which compiles the guest program crate with target set to `openvm` and reads the output RISC-V ELF file.
 This can then be fed into `bench_from_exe` which will generate a proof of the execution of the ELF (any other `VmExe`) from a given `VmConfig`.
 
 #### Providing Inputs

book/src/advanced-usage/sdk.md

@@ -2,7 +2,7 @@
 
 While the CLI provides a convenient way to build, prove, and verify programs, you may want more fine-grained control over the process. The OpenVM Rust SDK allows you to customize various aspects of the workflow programmatically.
 
-For more information on the basic CLI flow, see [Overview of Basic Usage](./overview.md). Writing a guest program is the same as in the CLI.
+For more information on the basic CLI flow, see [Overview of Basic Usage](../writing-apps/overview.md). Writing a guest program is the same as in the CLI.
 
 ## Imports and Setup
 

crates/toolchain/tests/README.md

@@ -6,7 +6,7 @@ This crate includes tests for OpenVM toolchain that involve starting from a Rust
 
 1. Add a new guest program file to [programs/examples](./programs/examples).
 
-See [Writing the Guest Program](../../benchmarks/README.md#writing-the-guest-program) for more detailed instructions.
+See [Writing the Guest Program](../../../benchmarks/README.md#writing-the-guest-program) for more detailed instructions.
 
 The `programs` directory is a single crate to make it easier to add small test programs. The crate is **not** part of the main workspace.
 Your IDE will likely not lint or use rust-analyzer on the crate while in the workspace, so you should open a separate IDE workspace from `programs` while writing your guest program.

docs/crates/benchmarks.md

@@ -3,7 +3,7 @@
 ### Latest Benchmark Results
 
 Latest benchmark results can be found [here](https://github.com/openvm-org/openvm/blob/benchmark-results/index.md).
-These are run via [github workflows](./.github/workflows/benchmark-call.yml) and should always be up to date with the latest `main` branch.
+These are run via [github workflows](../../.github/workflows/benchmark-call.yml) and should always be up to date with the latest `main` branch.
 
 ### Adding a Benchmark
 

docs/specs/ISA.md

@@ -21,7 +21,7 @@ The program code is committed as a cached trace. The validity of the program cod
 Memory is comprised of addressable cells, each cell containing a single field element.
 Instructions of the VM may access (read or write) memory
 as single cells or as a contiguous list of cells. Such a contiguous list is called a _block_, and
-an memory access (read/write) to a block is a _block access_.
+a memory access (read/write) to a block is a _block access_.
 The architecture distinguishes between block accesses of different sizes as this has significant performance implications.
 The number of cells in a block access is restricted to powers of two, of which the following are supported: 1, 2, 4, 8, 16, 32, 64. Block accesses must be
 aligned, meaning that in a block access of size $N$, the starting pointer must be divisible by $N$ (as an integer).

extensions/keccak256/circuit/README.md

@@ -25,7 +25,7 @@ It seems to handle padding in a single AIR row there is no alternate to having `
 The absorb step must correctly constrain that the input bytes are XORed with the end-state in the last round and equals the next permutation's `preimage`. The end-state is accessed via `a_prime_prime_prime()`. Note that both `preimage` and `a_prime_prime_prime()` are represented as `u16`s. However we can only XOR at most 8-bit limbs. Without changing the `keccak-f` AIR itself, we can use a trick:
 if we already have a 16-bit limb `x` and we also provide a 8-bit limb `hi = x >> 8`, assuming `x` and `hi` have been range checked, we can use the expression `lo = x - hi * 256` for the low byte. If `lo` is range checked to `8`-bits, this constrains a valid byte decomposition of `x` into `hi, lo`. This means in terms of trace cells, it is equivalent to provide `x, hi` versus `hi, lo`.
 
-The constraints are in [air.rs](./air.rs). Notably we use an XOR lookup table for byte XORs in the absorb step.
+The constraints are in [air.rs](./src/air.rs). Notably we use an XOR lookup table for byte XORs in the absorb step.
 
 ## Future Improvement