> ## Documentation Index
> Fetch the complete documentation index at: https://gugu.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Developer policies and permissions

> Develop under the rules that exist today, explain data and program behavior, and wait for official code review.

There is currently no separately published, complete developer policy for gugu Apps, and no separate CONTRIBUTING guide, review time limit, or appeal process. The existing requirements are spread across product API constraints, the market repository's README, the validation scripts, and official code review. Below, rules enforced today are separated from what you are advised to explain when submitting.

## Rules enforced today

* Market records are packaged from a pinned source commit. The source must be available for review; you cannot submit only an archive of unknown origin.
* Published versions cannot be changed, deleted, or reused. Withdrawals, end of maintenance, and removal from the market are handled through index fields.
* Pages are bound by isolation and network rules. Request extra capabilities in the manifest; the user agrees on gugu's confirmation sheet and can later revoke them one by one.
* An App that ships a local program or skill needs `agents:tools`. The program runs with the user's local permissions, and the install details show the actual command.
* firstRun is only allowed for Apps in the official index repository itself. Ordinary Apps cannot ask to be silently installed on first launch.
* The official team reviews and merges every version's record. Passing CI does not automatically qualify an App for listing.

## What to explain when submitting

To help users decide and maintainers review, the README should cover: the main purpose, the reason for each requested permission, the services accessed, what data is stored and where, what uninstalling cleans up, and the supported devices and client versions. If the App connects to accounts, explain where users configure them, and do not build account secrets into the package.

When using third-party libraries or copying examples, check and keep the corresponding licenses. The license in the current manifest is text; it does not mean the platform has verified the author's rights.

Agent control consumes the user's quota. Explain clearly when the App starts or contacts an Agent, and avoid endless mutual wake-ups. Read multi-user data only within what the calling identity can access; the interface should not guess at hidden content.

## Data and interaction boundaries

All participants in a shared file may be able to read its contents. Identity documents, secrets, or content meant for one person cannot rely on the page hiding them; design data boundaries following the `apps-together` guide.

When displaying text written by others, use textContent or a rendering method that escapes it. When a file call fails, show the reason; a failed read must not be shown as having no data. Revoked permissions and being offline also need actionable explanations.

These implementation suggestions come from the in-product App guide and help you build usable Apps. There is currently no separate content policy, commercial terms, or review commitment, and none should be carried over from other plugin platforms.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.