Issue #427 calls for plugin-author guidance that matches the current
Desktop public contract instead of ambient profile guesses or unmanaged
package-manager lifetimes. The guide now keeps the Desktop adapter in one
nested injection, describes the external `dsh web` mirror recipe, and
records the bilingual pair through the repository hash gate.
Constraint: Public plugin-author guidance must stay within desktopProfiles and desktopPnpm
Rejected: Document guessed `profiles/web` and ambient `pnpm` flows | they bypass the Desktop-selected profile and managed lifecycle
Directive: Keep this recipe scoped to external `dsh web` mirrors; native Electron verification still belongs in real Desktop runs
Confidence: high
Scope-risk: narrow
Tested: corepack yarn test:bilingual-docs
Tested: corepack yarn check:bilingual-docs
Tested: corepack yarn check
Lead with a concrete desktop-client description, supported platforms, bundled-runtime behavior, and direct downloads. Add bilingual FAQs with concise, source-linked answers for common installation, product-boundary, profile, plugin, data, and update questions.
CONTRIBUTING(.en).md describes three contribution paths: regular users
(reporting, community, docs, links), plugin authors (following the
plugin-development guide and ecosystem manifesto), and developers
(environment, repository boundaries such as the read-only upstream
submodule, commit style, and the yarn check gate). Linked from the root
README development section and the documentation index.
Create docs/plugin-ecosystem(.en).md as the ecosystem manifesto: an open,
composable, sustainable vision with composition-first, declare-clearly,
and compatibility-first principles, the desktop shell as the first
example, living-document community governance, and the marketplace as
the trust signal.
The root README intro now ends with the co-progress vision and links the
manifesto; the docs index and root README tables list it; the
plugin-development ecosystem-vision section points to it as the full
statement.
User side: the root README and user guide now say in plain language that
every plugin is built against the same rules so plugins can be installed
and used together, like a phone app store. Developer content in the
plugin-ecosystem section moves under a 'For developers' subsection.
Developer side: plugin-development ends with the ecosystem vision —
composition-first, clear declarations, compatibility-first conventions,
adopted through community use, with the marketplace as the discovery and
trust signal. No internal criticism or product comparison is voiced.
Users following the install/use path could previously land in developer
and maintainer content: the root README documentation table mixed both
audiences, the plugin-ecosystem section named desktopProfiles/desktopPnpm
inline, the user guide ended by pointing at the package README, and
why-desktop carried contract details.
Split the root README and docs index into user vs developer tables, add a
user-level plugin intro to the user guide, remove the developer-jargon
patch wording, and soften why-desktop's developer-contract detail. The
plugin-ecosystem narrative and differentiation copy stay for a follow-up
pass.
The README.i18n.yaml record was not re-recorded after the recent README
edits. The user guide also still described the pre-b9568562be health
commit, which now waits for the browser Loader to settle instead of the
window mount alone.