Skip to main content

​
Propose a Patch

​
Sources

Docs: Patch Web App: Open the active Patch in Publish and use Propose when the readiness control is enabled. Propose marks a Patch as ready for a person with Primary or Publishing to review. It preserves the exact changes being reviewed so later edits cannot silently alter the proposal. It does not publish, push, deploy, or widen the audience.

​
Before proposing

Confirm that:
  • the Patch contains the intended changes and no unrelated work;
  • the affected Pages and Panes render in supported states and viewports;
  • Plots and data meaning have been previewed;
  • the audience and participations are correct;
  • important failures and recovery paths are documented; and
  • people with Primary or Publishing can find what you checked in the Patch’s Problem. The Proofs that the Patch must pass come from the Proofs Platform Parable.

​
Read the readiness explanation

The first publication can use the content already built in Personal mode. You do not need to make an extra edit after enabling Versions: Propose preserves that existing definition for review. A Patch can change only the source of an inherited Page, Pane, or Plot. Propose retains that source edit without copying the unchanged upstream Page, Pane, or Plot into your Workspace. When editing a Patch based on a published Workspace Version, the preview includes that Version’s inherited Pieces and your saved changes. A later upstream update does not replace the Patch’s recorded starting point. Propose keeps the inherited Pieces in the Patch. On a Workspace’s copy, the proposed Patch and its Warnings & Errors read the upstream Release under your changes. So an upstream Palette that you did not change stays in the Patch, and its classes stay known. A proposed Patch reads the Release that the copy holds now, not the recorded starting point. Publish lays your changes over that same Release. If the copy takes a later Release after you propose, the proposed Patch shows that later Release under your changes. A Pull preview includes the exact incoming definition and your saved changes. Propose freezes that preview; a later Delivery does not replace it. The current Workspace definition stays active until publication, and current permissions still govern access to the preview. Proposing changes nothing readers see: their Pages keep reading the published definition while the Patch waits. Before its first Prepare, a proposed Pull shows the conflicts that Prepare will record. This includes a Workspace’s first Delivery of a Parable, before the Workspace has published a Version of it. After a published baseline exists, an empty Patch has nothing to propose. An edit to a Report or to one of its schedules counts as a change, so a Patch that only reschedules a Report can be proposed and published on its own. The control also remains disabled when the Patch is stale, conflicted, already closed, or otherwise not ready. Use the visible explanation to repair the actual condition. Do not recreate the Patch merely to turn the button on. The Propose control runs Prepare after proposing: it checks the Patch against the published line and records what it found. A Prepare holds only while the Patch and the line stay as they were when it ran. Proposing the Patch again runs Prepare again. If Prepare did not finish, Publish stays off until Prepare runs again. If another Patch publishes afterward, the Prepare is out of date. If you may run Prepare, Publish in the web app runs Prepare again first, and publishes when nothing stops Publish. Warnings still stop it. If Prepare now finds something, Publish stops and says so. Ponder and other API callers get a refusal instead, for example “Another Patch published v1.4 after this Prepare. Prepare again.” When no Release came after the Prepare, the refusal says “This Prepare is out of date. Prepare again.” A stale Prepare holds back only its own Patch. Only a conflict or a Prepare finding nobody has resolved marks the Parable Breaking and stops every Patch on it from publishing. An unrelated Proposed Patch does not hold another Patch’s Publish. A separate read returns live check verdicts for a Proposed Patch at its current revision. An explicit Prepare request can ask for the same verdicts. Propose, ordinary saves, and background Prepare do not run these checks. The read uses the Patch’s complete effective content, including inherited Pieces and saved conflict choices on the source Deployment or a Workspace copy. The person’s selected Page, focused Piece, and Refresh reading do not change that input. The observed Patch revision and the retained address of its Changes keep their existing meanings. After another Patch publishes cleanly, the read uses the new current content with this Patch’s retained Changes. Reading checks does not require another Prepare. Current unresolved findings and stale merge choices still refuse the read. A successful read does not refresh Prepare or let Publish use stale Prepare evidence. The read evaluates every Visible composed Platform Parable in the Patch’s Workspace that declares checks in the Release its copy runs. It uses the Primary participation on the check’s composed Platform Parable copy and the Primary participation on the Patch’s composed Parable. The execution identity is the Workspace, not a person holding either participation. It never uses the requesting person’s participation to compute a verdict. The requesting person must still be able to read the Patch. Titles and review counts are part of the shared verdict. Every permitted Patch reader receives them, even without a participation on the check’s composed Platform Parable copy. The underlying Preferences and other check details keep their normal access rules. The verdict is met, pending, unmet, or not applicable. A missing answer, invalid answer, refusal, error, or five-second timeout is unmet with a no-answer reason. An unreadable Release or titles Pane returns a no-answer verdict for the composed Platform Parable instead of omitting it. Checks from independent composed Platform Parables run concurrently. A composed Platform Parable does not check its own Patch. An unchanged Pull skips checks. A hand-edited Pull receives them. Nonblocking checks warn. These verdicts write no Prepare findings and do not change the Prepare fingerprint or Patch revision. They do not mark a composed Parable Breaking, hold another Patch, or enforce Publish. The Publishing panel and Publish enforcement are separate work. Prepare checks that no two live Pieces share a handle. A true conflict names the handle and both Pieces. A deleted Piece does not hold its handle in the new Release, so a new Piece of another kind can take it in the same Patch (Move a handle between Piece kinds). A Parable in Publishing mode publishes only with a description and a preview, the screenshot or illustration on its sidebar card. When a Workspace prepares a Patch to a Parable it built and either is missing, Prepare lists a finding that stops Publish. The finding uses the words of the Publish refusal, for example “This Parable needs a description and a preview to publish. Ask Ponder to write the description and make the preview. Then publish again.” A Workspace preparing a Delivery, or a Parable published to it, gets no such finding, because it does not set that Parable’s description or preview. A Parable Pro’s Prepare still lists only a missing preview, as a warning, and Publish & Deploy refuses the Patch until both are there. Prepare also lists, as findings that stop Publish, a Pane type that changes in a way its saved rows cannot follow, and a Patch after which nobody could edit the Policies of a Page or Pane. Fix the Patch, then Prepare again. While one Proposed Patch has a finding that stops Publish, Publish is off for every Patch of that Parable. Ponder can also Prepare a Patch for Publish & Deploy. That Prepare counts as the Propose control’s Prepare, so the Publish panel shows the Patch as Prepared and either Publish accepts it. A Pull is the exception: only the Workspace Prepare checks it against its Delivery, so after a Prepare for Publish & Deploy the Publish panel still asks to Prepare it. If the Patch is already published, Prepare and Publish in the Publish panel refuse it and say so. Start a new Problem for your next change. To prepare Changes still being edited, Propose them first. A Pane can propose too. A Pane’s code that changes the Parable, such as an ontology editor or a Pipeline builder, calls propose.change or propose.piece. The reader confirms the change in a dialog that the host draws outside the Pane, and the change goes into the reader’s open set of Changes. With no open set, the first proposal opens the Start Changes flow in a Problem. A Pane data edit by a reader who holds Publishing or Primary needs no dialog. It goes into the reader’s own Pending Patch at once (Changes that apply at once). A proposal needs what the same edit needs in the editor, held by both the reader and the Pane’s author. The set of Changes records each proposal with its Pane, the author of the Pane’s code, the reader who proposed it and the items it changed. The Unpublished Changes banner above the Page counts what the Patch holds, lists each change with Undo, and offers Propose Changes, then Publish. A proposal reaches readers when the set publishes. A reader who may not open a set of Changes is refused (PA-AU-072). After proposing, anyone who holds Publishing or Primary on the Parable can Prepare the Patch, then Publish it or reopen it for more work. No separate reviewer participation exists, and Publish does not require the Patch’s author. Any participant in the Parable may open the Patch, before and after it is proposed; once it is pocketed, only its author may. A Patch that a Problem holds is shared: anyone in Publishing or Primary who can see that Problem may propose, prepare, patch, pocket, restore and delete it, as its author may. A pocketed Patch in a Problem that Parable started for it, such as a Pull or a Patch saved outside Ponder, stays its author’s: only its author restores, deletes, or exports it. Someone in the Workspace who holds no participation on the Parable gets Not found when they read, Save, Patch, Propose, Prepare, re-check, Publish, Pocket, Restore or Delete one of its Patches, the same answer as for a Patch that does not exist, so they cannot tell which Patches exist. Opening a Patch never shows anyone more than the Parable’s current Policies allow: if the Patch removes or loosens a filter Policy, its readers stay filtered until it is published. A Plot the Patch adds reads for its author and for every Publishing or Primary participant whom its Pane’s Policies allow to create Plots and view its settings, so the people who may publish it can check its rows first. If more work is needed, return through the supported Patch flow so the review history remains understandable.