Trust and operations
Rules for listed Builds and Project Rooms
The Registry depends on accurate listings, bounded claims, clear rights, and rooms that preserve the context of setup and adaptation.
Principles
- Do not list software that violates law, platform terms, privacy obligations, or third-party rights.
- Do not describe checks as broader than they are.
- Keep Build-originated setup, delivery, and acceptance context in the Project Room.
Section 1
Claims and reports
The Registry needs precise language because Users may rely on it during review.
Report only what was checked
If a demo was reachable, say that. If a scan reported no findings at scan time, say that. Do not turn a narrow check into a broad claim.
Mark missing checks
Declared-only listings are allowed in a prototype, but missing reports should be visible.
Update stale records
A BuildVersion change should trigger a new report status instead of inheriting old confidence.
Section 2
Rights and secrets
A Build listing should not create legal or operational surprises.
Do not include private credentials
Listings, screenshots, source packs, and setup notes must not expose API keys, tokens, passwords, customer data, or private files.
Declare license boundaries
State what the User can use commercially, whether redistribution is allowed, and what support is included.
Respect third-party code and assets
Do not list work that depends on code, data, media, or templates you do not have rights to publish.
Section 3
Project Room conduct
Rooms are part of the Build handoff, not just chat.
Keep scope visible
Requirements, estimate scope, delivery notes, acceptance comments, and additional work should stay in the room.
Separate new work
Provider setup, extra checks, and feature changes should be scoped clearly before work begins.
Write useful reviews
Reviews should describe what was delivered and what was learned without exposing confidential information.
Guides
Product note
These guides are product copy, not legal terms. Source access, refund, access-control, and delivery policies should be separated before production implementation.