Omg, can we replace it with types? Because it is even worse than jobs.

I agree that we should decode the body into a typed structure. I'd rather not doing it here to keep the changes to the minimum.

Then I propose to make it first.

I don't think making the env typed should block this PR. I think it should be a separated discussion. It touches more areas than just these two commands and we should be careful.

I think it was unclear in the issue that removing jobs involved getting ride of everything in /engine including env. Env is the worst part of the framework and actually the primary goal of the removal.

Isn't the primary purpose of this to get rid of env in the first place

I understand that the purpose of all this is to get rid of everything under /engine. I feel like it's better to do it in phases, that's what I though was the idea/plan:

1. Get rid of all references to Job.
2. Replace env and dynamic lookups with type safe decoding.

I rather follow that script than this other one:

1. Get rid of some job references.
2. Replace env and dynamic lookups with type safe decoding.
3. Replace env references in the remaining jobs with the new type safe decoding.
4. Get rid of remaining jobs references.

@calavera I don't know where you seeing second script.
Current state of PR makes no sense. It makes nothing better, you replaced job with env, which will be deleted anyway and have same problems and even worse. It is possible to replace job with typed structs and your PR became smaller than now.

@LK4D4 I didn't replace anything, job calls env internally, I removed the layer on top of the env. It's not worse, we're removing the references to job, that's good.

Replacing the job with typed structs requires to go through all the project's code base to remove the reference to env before merging this. That's the second script.