Moderation & guidelines
What may be published on Denofy, how reports are handled and what moderators can do.
Diese Seite ist noch nicht übersetzt und wird auf Englisch angezeigt.
Automated checks catch most problems, but not intent. Denofy's moderators review flagged versions, handle reports and can hide packages or suspend accounts. Every moderator action is recorded with a reason in an audit log.
Content guidelines#
Packages on Denofy must:
- Do what they say. The title, summary and description describe what the package actually makes the agent do. No hidden behaviour, no instructions that are only visible to the model.
- Respect the user. No collection or upload of data the task does not need, no access to credentials, keys or browser data, no persistence (cron jobs, shell profiles) without telling the user, no disabling of the agent's safeguards.
- Be reviewable. No obfuscated code, no large encoded payloads, no executables that cannot be inspected. Download external tools from their official source with a pinned version.
- Respect licenses. Only publish content you are allowed to redistribute and state the license.
- Be honest about the scan. Exceptions in
denofy.ymlneed a truthful reason. Trying to evade the scanner (splitting commands, unusual encodings) is treated like malware.
Not allowed: malware and data theft, prompt-injection attacks against users, spam and name-squatting, content that harasses or discriminates, and illegal content.
Reporting#
Signed-in users can report a package (Report package on the package page) or a single review. Choose a reason:
- Malware or data theft (
malware) - Security problem (
security) - Spam or misleading (
spam) - Abusive or offensive content (
abuse) - Copyright or license violation (
copyright) - Something else (
other)
Each user can have one open report per package or review. Reports go to the moderation queue; you do not get a public reply, but the result is visible on the package (for example a blocked version or a hidden package).
Security problems in Denofy itself (not in a package) should be reported privately via GitHub security advisories instead.
What moderators can do#
| Action | Effect |
|---|---|
| Approve a version | Status becomes Verified and the version is marked "reviewed by Denofy moderators". The automated report stays visible. |
| Block a version | The version disappears from the site and ranges, the API answers 403, latest moves back. Installed copies are not touched; the CLI refuses to reinstall it. |
| Reset a decision | The automated result applies again. |
| Hide a package | Removed from search, listings and the API (404); still visible to the owner with the reason. |
| Delete a package | Removed permanently. |
| Hide a review | Not shown and not counted in the rating. |
| Suspend a user | No sign-in, no publishing or syncing; reviews are hidden; optionally all packages are hidden. |
Approvals survive re-verifications. Every action requires a reason and is stored in the audit log (who, what, when, target, reason).
Review queue#
Versions with Warning or Failed status land in the moderators' queue. Most are fine and stay as they are — a warning is information for users, not an accusation. Moderators look for intent: a package that hides what it does is blocked; a package with a reasonable but risky step is left as Warning, or approved if the risk is clearly explained.
Appeals#
If you think a decision about your package or account is wrong, open an issue on GitHub with the package name and what changed. For false positives of the scanner, see False positives.