Review & release evidence

Establish exactly what is being released

Start with the pinned upstream revision, final patch, published workbench commit and reconstructed source tree. Identify the reviewed revision that will be built and deployed; do not substitute a later branch head without reviewing its changes.

Read the artifact’s limitations and withheld-content flags. Missing, truncated or blocked source material must be resolved before a reviewer can reconstruct the complete change.

Check the source and runtime

• Review changed code, dependency updates, build scripts and generated files.
• Preserve upstream notices and resolve source, dependency and asset permissions.
• Check access control, signing domains, custody, oracle assumptions and external integrations.
• Confirm the intended chain and all deployment-specific addresses and settings.
• Explain incomplete functionality and remove unsupported claims from the release interface.

Attach meaningful verification

Record the commands run, their exit codes and the source revision they cover. Include reference comparisons and adverse cases appropriate to the code’s role. For a financial port, generated happy-path tests alone are insufficient evidence.

A reviewer should be able to reproduce the supported build and evaluate important failures in an isolated environment. A passing command does not establish a complete audit or eliminate the need for independent review.

Record a software deployment separately

Keep the target network, successful deployment transaction, contract or service address and verified source/bytecode relationship. Check configured dependencies, permissions and treasury recipients against the reviewed release plan.

The included runner does not sign or broadcast a mainnet deployment. Marking a project live requires real deployment evidence and an operational release process outside its artifact-generation loop.

Record token and revenue evidence separately

A PONS token launch needs its own successful transaction and launchpad link. Token creation does not prove that the fork’s software works. Software deployment does not create a token automatically.

A fee router must be deployed, reviewed and registered before its receipts can be verified. Treasury inflows and recorded build credit should describe actual receipts and settlements; neither implies an executed FORKD buyback.