fix: TODOs in documentation files

docs/core/AllocationManager.md

@@ -731,7 +731,7 @@ AVSs use slashing as a punitive disincentive for misbehavior. For details and ex
 
 In order to slash an eligible operator, the AVS specifies which operator set the operator belongs to, the `strategies` the operator should be slashed for, and for each strategy, the _proportion of the operator's allocated magnitude_ that should be slashed (given by `wadsToSlash`). An optional `description` string allows the AVS to add context to the slash.
 
-Once triggered in the `AllocationManager`, slashing is instant and irreversible. For each slashed strategy, the operator's `maxMagnitude` and `encumberedMagnitude` are decreased, and the allocation made to the given operator set has its `currentMagnitude` reduced. See [TODO - Accounting Doc]() for details on how slashed amounts are calculated.
+Once triggered in the `AllocationManager`, slashing is instant and irreversible. For each slashed strategy, the operator's `maxMagnitude` and `encumberedMagnitude` are decreased, and the allocation made to the given operator set has its `currentMagnitude` reduced. See [Slashing Calculations and Accounting](./accounting/DualSlashingEdgeCase.md) for details on how slashed amounts are calculated. The `SlashingLib` implements the math for these calculations, particularly in the `calcSlashedAmount` function.
 
 There are two edge cases to note for this method:
 1. In the process of slashing an `operator` for a given `strategy`, if the `Allocation` being slashed has a `currentMagnitude` of 0, the call will NOT revert. Instead, the `strategy` is skipped and slashing continues with the next `strategy` listed. This is to prevent an edge case where slashing occurs on or around a deallocation's `effectBlock` -- if the call reverted, the entire slash would fail. Skipping allows any valid slashes to be processed without requiring resubmission.

script/releases/README.md

@@ -20,8 +20,13 @@ At this point, you should be able to view an environment's config (try `zeus env
 
 ### Writing a Script
 
-Scripts are broken up into multiple steps TODO
+Scripts are broken up into multiple steps. Each step is implemented as a separate script file and follows a specific naming convention:
 
+1. Each script file is named with a numeric prefix to indicate execution order (e.g., `1-eoa.s.sol`, `2-multisig.s.sol`).
+2. The suffix indicates the executor type - either EOA (Externally Owned Account) or multisig.
+3. Scripts are executed sequentially, with each step potentially depending on the results of previous steps.
+
+Zeus provides an environment for these scripts via environment variables and ensures steps are run in the correct order exactly once per environment.
 
 ### EOADeployer
 
@@ -204,4 +209,4 @@ contract ExecuteEigenPodManager is MultisigBuilder {
 }
 ```
 
-After reusing the previous script's `queue()` function to recreate the calldata, we wrap it up in an `executeTransaction` encoded data blob and return the `MultisigCall`, which will then be crafted as a `SafeTx` by the parent contract.
+After reusing the previous script's `queue()` function to recreate the calldata, we wrap it up in an `executeTransaction` encoded data blob and return the `MultisigCall`, which will then be crafted as a `SafeTx` by the parent contract.