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.
The shipped bundles keep ctx.sessionQuery mounted but set the new
session-query-sqlite `openAt: never` phase: searchSessions/searchEvents
fail with the typed SESSION_QUERY_SEARCH_DISABLED code before any request
normalization, node:sqlite is never imported or opened, and no source
observation or reconciliation runs. Every inherited exact read, filter,
and trace — session export descendants, subagent-fork Workspace
inheritance, title reads — keeps working, and the Web sidebar search
degrades to its designed local title/workspace matching. Enabling content
search is a one-line openAt override in a later patch layer; the web e2e
scaffold keeps it enabled as the assembled opt-in coverage.
t4we fan