Won't this break the poker?

break it how?

Ahh I missed the environment: sensitive. Then it will break the autovoter loader. Let's just take a minute and do an inventory of everywhere this is used (ask everyone), make a checklist, and make sure it is all handled before rolling it out in prod.

In the end we probably want a different key for voting/delegation. Maybe getting that established is part of this.

how will it break the autovoter loader?

No one has the current key. It's only in github. So in order to move the currently named secret to the org, a new key will have to be generated. Now that I understand this better after our call last week.

Here are the issues I am concerned about.

1: If we change the production key, we have to ensure that the upkeeps it is poking have it as the keeper, and we have to ensure that this address is delegated to load transactions on the omnichain safe on mainnet (which now has 6 figures of BAL in it).

2: If we have production keys in a test environment, it becomes as important to audit/review everything that runs here before it runs/have good branch protection/etc. That makes it harder to work with.

So 2 suggestions:

1: Create an org level secret of the same name with a different key and not export it to msig ops.
2: create a set of TEST_ org level secrets and expose those to dev/test environments. This could even include permissions to load on a test safe/etc.