PONSRepository & fork folders
Where every candidate, run and reproducible patch lives in the public workbench.
One workbench, separate candidate folders
The public workbench is Sixtytwocaptial/forkd. The repository includes an individual prepared folder for each of the 345 catalogue candidates. A stable candidate ID connects the web detail page, research record and source folder.
These folders contain preparation material and source references. They are not hundreds of completed deployments or mirrors of every upstream repository. New sources outside the index receive a deterministic custom candidate ID when the publisher maps a run.
A published run has its own namespace
The trusted publisher creates a forkd/<job UUID> branch from the destination’s default branch. It writes only inside the run path for the selected candidate. Multiple jobs for one candidate stay associated with the same candidate folder and have distinct run directories.
forks/<candidate-id>/runs/<job-id>/
FORKD_JOB.json
README.md
changes/<modified-source-path>
changes.patch
REVIEW.md
upstream-notices/<notice-file>Read each artifact for its purpose
- FORKD_JOB.json identifies the source repository, upstream commit, request, job, target chain, model and review state.
- changes/ contains file snapshots committed during the run; it is not necessarily the full upstream source tree.
- changes.patch captures the final supported text changes against the pinned upstream revision, including changes made by commands.
- REVIEW.md contains the returned implementation summary and review notes.
- upstream-notices/ preserves recognized top-level notices; dependency and nested notices still require review in the full source tree.
Reconstruct a review checkout
After checking out the published job branch, run the included materializer against the run directory. It fetches the pinned upstream source and applies the final patch. It does not install project dependencies or execute project code.
Treat the resulting checkout as untrusted source. Read the diff and dependency changes before running installation, compilation or tests inside an appropriate isolated environment.
node runner/materialize.mjs forks/<candidate-id>/runs/<job-id>Publication can be withheld
The publisher validates paths and content before creating public blobs. It rejects restricted files, secret patterns, configured private terms and unsupported patch content. Binary changes, a truncated patch or a failed privacy check need separate operator review.
The default branch is not updated by the runtime publisher. A job branch or artifact link does not merge the changes, deploy the project or create a token.