Render ZIPs prior to first ZIP Editor review/attention (suggested labels: `ZIP process`, `S-waiting-on-author`)

[shielded-nate]

Quick Status: I'm currently (2026-06-24) prototyping a technical fix that doesn't rely on changes to this repository (described in comments below). Consider this a low priority to read/consider until I report back with that result.

Intro

I wanted to share some of the friction I'm encountering in work on Crosslink ZIPs which arise as a combination of ZIP 0 expectaions, Github UX decisions, and agent use (copilot). I'm not certain the best way to improve this situation, and I'm interested in brainstorming discussions if editors are available.

Process Goals

My current goals for my process are as follows

1. I want to do many messy edits and changes to a set of related draft zips for the Shielded Labs' version of Crosslink.
2. The number of ZIPs and their relations and scope will be shifting early in this process.
3. Because there's already been a fair amount of discussion in many venues, including on the forum, where we post updates, my current focus is in drafting ZIPs with the aspiring precision and clarity of good ZIPs.
4. I want to enable anyone to review this work as it develops in a rendered form, and I want the contents to be able to use all rendering facilities as the main zips.z.cash site (in particular math markup), and I want "early reviewers" (not ZIP editors!) to review the rendered form.
5. I want to do this kind of process iteratively, all prior to requesting editorial effort or review from ZIP editors.
6. Once this process iterates enough that the ZIPs are relatively baked then I want to request formal attention and feedback from ZIP editors.

Frictions

There are multiple interacting frictions I'm grappling with in achieving my goals. Some of these are more obviously due to Github product constraints, while others are around the "human-layer" of ZIP 0 or the actual practical process ZIP editors impose in their expectation or use of Github (whether implicit or explicit).

1. Order of Operations. ZIP 0 suggests that "Once the Owners are convinced that an idea has some chance of acceptance, a ZIP draft should be presented to the Zcash Community Forum." The problem here is that simply pasting the source of the ZIPs to the Forum is just unworkable: there are multiple ZIPs, they make heavy use of intradoc links, they use katex math markup, etc... So what I really want is to render the draft ZIPs. But in order to have them rendered on zips.z.cash, I need to submit a PR, but to submit a PR I need to have them posted on the forum? There's a bootstrapping problem. So, I have attempted to render them on my own github pages site, bringing me to friction 2:
2. Github Product Constraints: forks and CI/CD policies. rendering my own fork is thorny because Github has borked the UX of forks in a couple of ways. First, because CI is defined in-repository source, the same policy is present in a fork, by default, unless it is altered in the fork, which then conflates any "content" PR coming from the fork repository back to upstream with an incidental policy change, which must then be filtered back out. For example, I am working on multiple branches in my ZIPs fork repository, so I need a rendering policy that can support those branches (if I want each rendered for the public), which is different than the upstream publication policy.
3. Github Product Constraints: forks, PRs, and sub-PRs. by default any newly created PR in a fork targets the main branch of the upstream repo. However, my goal is to iterate on changes in my fork grouped into PRs within my fork whose end result is a clean "official" PR against upstream. Each time I do this, or requrest an agent to do this, it targets upstream, and I must manually rebase the PR target.
4. AGENTS.md problem. Furthermore, copilot interprets AGENTS.md as applying to every PR regardless of if it is introducing a new ZIP or changing a pre-existing ZIP and regardless of if it is targeting upstream or my local fork. Therefore, for every new agent request, I am forced to write "This satisfies ZIP 0 and here's a " (where the link is somewhat arbitrary with opaque constraints enforced by copilot). This improves nothing for any humans and it makes my life significantly worse.

Brainstormed Solutions

I believe a lot of these issues could be side-stepped with a tweak to the ZIP 0 process: unbundle PR merging from editorial review. The way I imagine this going is something like this in ZIP 0, replacing the part about posting a ZIP the the forum:

When an Owner has an idea they believe could be one or more ZIPs, they submit a new draft PR to the ZIPs repo (note, this "draft" is a Github PR status, not the ZIP status of the same name). That causes the public site to render these un-merged ZIP drafts (modulo security/safety checks) to the zips.z.cash/preview/<pr number> URL. The Owner should then start discussions on appropriate fora referencing that rendering. The Owner can update that rendering by pushing new git commits to their PR. Once they assert they have had sufficient community discussion and buy in, they flag the ZIP editors for more formal editorial review by .

Can we move in that direction? Would anything about that ideal (technical feasibility aside) interfere with the broader ZIP 0 goals, benefits, or constraints?

[linear]

COR-1386

[shielded-nate]

I'm prototyping an out-of-repo (out-of-band) effort to give me what I want without disrupting this repo's maintainers or the ZIP Editors until the concept is more proven out: zip-previews - Render ZIPs from multiple repositories / branches / revisions to see in-progress drafts