snag report on improved superchain-ops flow

[geoknee]

Context: I was running through the signing flow for this task https://github.com/ethereum-optimism/superchain-ops/tree/main/src/tasks/sep/030-zora-sep-u13-to-u16a

Here are some things that confused me / tripped me up:

1. When simulating the task, I get output like the folllowing:

**<TODO: Slot was not automatically decoded. Please provide a summary with thorough detail then remove this line.>**
  
**<TODO: Insert links for this state change then remove this line.>**
  
- **Key:**          `0x0000000000000000000000000000000000000000000000000000000000000005`
  - **Before:** `0x0000000000000000000000000000000000000000000000000000000000000000`
  - **After:** `0x0000000000000000000000000000000000000000000000000000000001cc7a2b`
  - **Summary:** 
  - **Detail:** 
  
**<TODO: Slot was not automatically decoded. Please provide a summary with thorough detail then remove this line.>**
  
**<TODO: Insert links for this state change then remove this line.>**
  
- **Key:**          `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`
  - **Decoded Kind:** `address`
  - **Before:** `0x0000000000000000000000000000000000000000`
  - **After:** `0x7b465370BB7A333f99edd19599EB7Fb1c2D3F8D2`
  - **Summary:** ERC-1967 implementation slot
  - **Detail:** Standard slot for storing the implementation address in a proxy contract that follows the ERC-1967 standard.
  
**<TODO: Insert links for this state change then remove this line.>**
  
- **Key:**          `0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103`
  - **Decoded Kind:** `address`
  - **Before:** `0x0000000000000000000000000000000000000000`
  - **After:** `0xE17071F4C216Eb189437fbDBCc16Bb79c4efD9c2`
  - **Summary:** Proxy owner address
  - **Detail:** Standard slot for storing the owner address in a Proxy contract.
  
**<TODO: Insert links for this state change then remove this line.>**

I don't think we want to be printing all these TODOs?

2. Readme and output stress the importance of checking a normalized state diff against an audit report, but I gather we don't have these any more.

3. User is encouraged to use op-txverify, but I'm not clear that is a necessary step or not?

4. How to use HD_PATH env variable does not seem to be documented.

5. These links in the validation.md

3. [Verifying the transaction input](#understanding-task-calldata)
4. [Verifying the state changes](#task-state-changes)

are broken.

6. I get a tenderly link to follow, but I don't know what to do with the simulation output since we don't validate the state diff any more.

[geoknee]

7. I couldn't find an explanation of what the "normalized state diff hash" is. Be nice to include that.

[blmalone]

Thanks for the feedback @geoknee. I've raised a PR here that addresses some of the snags you raised above: #1230

I'd like to step through each item to provide more colour:

1. During task simulation we intentionally print the markdown with 'TODOs'. During signing this is not printed. The reason we print the markdown is so that the task developer, if required, can easily create the VALIDATION.md files state diff section. I think there are some conversations about only adding state diffs for non-OPCM upgrades. I'd suggest until we have a clear decision here, we should keep printing this markdown during the simulation step. The 'TODOs' are meant to guide the task developer to insert missing details that the signer will want to see when reviewing VALIDATION.md.

2. True, the addition of audit reports to our workflow was experimental and not something we've fully committed to. The language here should be changed. I've added a fix in the PR mentioned above.

3. op-txverify is required for some signers but not for others, I still think we need to land on a solid decision here. cc: @smartcontracts

4. Good call out, added this in the PR above.

5. This is due to the task developer not writing the correct markdown. I've made some helpful changes to the boilerplate markdown file in the PR above.

6. Again, we still do validate state diffs for non-opcm upgrades. I think for the time being we should keep the tenderly link.

7. Added in the PR.

[geoknee]

1. You say the TODOs are only printing during signing, but don't we ask signers to perform the task simulation? If so, then it is part of the UX for signers?

Thanks for the clarification on the other points and fixing some things on that PR.

[blmalone]

@geoknee true, we do expect the signers to simulate too. In practice I think most signers run the sign command and check the tenderly link before actually signing on their ledger. Not ideal. So on second thoughts, this is a valid point and we should look to clean up the simulation command for when signers are running it.