Publish an App

Publish the Folder list frontend from Build an App. Use the same Inkcap source fork, App ID and captured build recipe. Folder list is the example’s name. Its directory label still comes from the fork’s App metadata.

You need to own the Team, have its source fork available, and choose a Computer with enough funded capacity to build it. Editing source, building a Release and selecting that Release for your Team are separate actions.

Commit the source

Finish the frontend change in the fork’s apps/inkcap/src/main.tsx and push it to that repository’s main branch through your authorized Team Git workflow. Keep the captured dependencies and recipe. The builder uses the recorded recipe, not arbitrary package scripts you add to the fork.

Illustrative: an instruction to your authorized Agent is, “Commit the Folder list change in this Team’s Inkcap fork and push it to main. Do not accept a Release.” Check its returned commit and repository before building.

Build a candidate

1. Open App releases in Team settings.
2. Choose the same fork under Team App. The page shows its repository.
3. Choose Build Computer, then Build current revision.
4. Wait for a successful candidate. Inspect its source revision, artifact digest and Release ID. Confirm the source is your pushed commit.

The owner captures the current main revision and binds the build to the chosen Computer, App and recipe. A successful build stores immutable artifacts and creates a Release candidate. It does not change the Team’s selected App. Another push or build does not rewrite that candidate.

Recent successful builds have an Inspect button. Use it to reopen a candidate after leaving or refreshing the page. A failed build remains failed, with no candidate accepted and the previous live selection unchanged.

Preview, then accept

Preview candidate opens the candidate without Team resource permissions. Use it to inspect the page and controls. Folder list cannot prove file access there. An empty Computer context or a refused permission request is expected in this preview.

To use this candidate in the Team:

1. Choose Inkcap under App to replace. This replaces that Team’s Inkcap selection with your fork. Other Teams keep their selections.
2. Check the candidate ID again, then click Accept release.
3. Wait for Release accepted. The Team’s selection now uses the candidate.
4. Before testing consent, open the installed App’s settings and its permissions. In Permissions, set Computer access to No Computer access, click Save permissions and confirm the saved setting. If revocation is pending, wait for it to finish.
5. Open or refresh the selected App from the Team dashboard. Click List files and approve listing through the host’s consent UI.
6. If the App asks for a Computer, use Choose Computer in its host controls, refresh the App and click List files again.

Check that it shows your Computer’s file names and leaves file contents alone. Before testing decline, clear Computer access through App settings and refresh the App again. Declining consent must prevent the listing request.

Replacing Inkcap keeps the installation’s existing grants, including Computer, Agent and model permissions. Acceptance does not add permissions or clear them. An existing listing grant can satisfy the request without showing consent, so clear Computer access before each consent or decline test. Review all retained permissions separately when replacing any App.

Update and recover

Situation	What to do
Build failed	Read the reported failure, check the source and Computer, then build again. The live selection stays unchanged.
Source changed while building	Refresh the source and confirm which pushed revision you want. Build that revision rather than assuming the older candidate contains new edits.
Acceptance conflicts	Refresh the App directory and review its current selection before trying again. Another accepted change may have advanced its authority.
Request status is uncertain	Inspect build history or the current selection before issuing a different operation. A lost response does not mean nothing happened.
Files refused after acceptance	Check the selected Computer and the App’s approved listing permission. A Release is not a grant.
Release revoked	It cannot be newly selected or served as an eligible Release. Choose another verified, non-revoked Release through App settings.

To ship another change, edit and push the same source fork, build a new candidate, inspect it and accept it explicitly. Keep the previous Release ID if you need to restore a known version. Advanced App settings let the owner change the selected App and Release IDs or reset an override. Restoring a version changes selection, not its immutable bytes or an App backend’s data.

This workflow publishes a Team selection. It does not list the App for sale in Bazaar or create an anonymous public website. Those have separate ownership, publication and access decisions. There is no fungi publish command in this workflow.