nextcloud/documentation

developer_manual/app_publishing_maintenance/release_automation.rst recommends a third-party action, while the org has its own workflow template for this. Mention https://github.com/nextcloud/.github/blob/master/workflow-templates/appstore-build-publish.yml as the default option, with how to add it to a repo. Keep the third-party action as an alternative, or drop it if the template covers everything.

The app guidelines ask authors to respond to security reports in good time, but developer_manual/app_publishing_maintenance/publishing.rst doesn't say how to tell people where to report. Recommend a SECURITY.md in the app repository, saying how security issues are reported to the app's developers. Link the org's file as an example: https://github.com/nextcloud/.github/blob/master/SECURITY.md

developer_manual/digging_deeper/repair.rst explains the uninstall repair step, but not what an app should actually clean up, and the app guidelines require it. Add a short checklist of what to remove on uninstall: app config values, user preferences, background jobs, appdata files, and (if wanted) database tables. Add a note on downgrades: what happens to migrations and data when an older app version is installed.

The coding standards pages link to nextcloud/coding-standard and the ESLint config, but there are no steps to copy. getting_started/coding_standards/php.rst: add composer require --dev nextcloud/coding-standard, a minimal .php-cs-fixer.dist.php, and cs:check / cs:fix composer scripts. getting_started/coding_standards/javascript.rst: add a minimal current ESLint config using @nextcloud/eslint-config. digging_deeper/npm.rst (around line 93) uses eslint --ext; check it against the current flat config and update.

developer_manual/digging_deeper/email.rst shows how to send mail, but nothing about abuse: an app can easily turn an instance into a spam relay. Validate recipients with IMailer::validateMailAddress(). Rate-limit endpoints that send mail (#[UserRateLimit], #[AnonRateLimit], or ILimiter, see digging_deeper/security.rst). Add a note: anonymous / public users must not be able to make the instance send mail to an address they typed in, or only with a strict rate limit.