I have also updated the cue file. Please let me know if the spec is wrong @Gerg-L @eclairevoyant (I used the test manifest.json on smfh as the specification).

Side-thought, we should have a specification for linkers, as we'd want every linker that works with hjem to implement the same API (e.g. so we can just assume in the service that the linker will have a diff command). This is orthogonal to this PR however

Side-thought, we should have a specification for linkers, as we'd want every linker that works with hjem to implement the same API (e.g. so we can just assume in the service that the linker will have a diff command)

I think the least alternative linkers could do is to understand what the current spec is, but it might be a good idea to document and version the linker spec somewhere. I'll try to catch this in my upcoming documentation PR. Currently preparing a NDG stylesheet for Hjem, we can probably prepare a markdown document alongside the new README.

I restored the old manifest, so we might take a look at it later to ensure that we implement the full specification correctly.

Additionally, I came up with way better manifest validation: instead of checking inside of the service, we now check for it during the checkPhase or our manifest. This allows for validation at build-time, and is infinitely more solid than what I used to do before (i.e. check it during the activation service, which is inherently brittle). We migh still want service validation though, to ensure that the OLD manifests are not corrupted in any way. If this happens, we can error out and prompt the user to:

1. Run a rebuild
2. Re-run the service

So that they may re-link their files.

Made a few readability changes (inverted the condition in mapFiles, added a comment for it, renamed linker to linkerExe and declared it in the script let..in binding)

ty nezia, seems to work great with my minimal testing