docs: post-#294 cleanup — update stale paths to migrated docs

PR #294 migrated 5 root-level docs into docs/en/. This sweeps the
stale path references that lived outside the moved files:

- README.md, CONTRIBUTING.md, SECURITY.md: link/cite paths updated
  from docs/architecture-*.md, docs/plugin-compatibility.md,
  docs/testing-strategy.md to their new docs/en/ locations.
- README.md: "pre-1.0" status block replaced with the current
  "1.0 released, community-store listing pending" framing — aligns
  with the same edit landed in docs/en/index.md.
- plugin/src code-comment references (AdapterManager, SftpDataAdapter,
  main.ts, tests/compat/CompatVault.ts) updated to the new doc paths.
- docs/en/index.md, docs/en/architecture/{index,shadow-vault}.md,
  docs/en/contributing/documentation.md: small text-level catch-up
  edits (path references, status note) that were missed in #294.

CONTRIBUTING.md

@@ -165,8 +165,8 @@ Commit the staged files alongside your code change.
 
 ## Where things live
 
-- **Architecture decisions** → `docs/architecture-*.md`. The shadow-vault rationale (and why the prior `reconcileFile` route was abandoned) is in `docs/architecture-shadow-vault.md`.
-- **Test strategy** → `docs/testing-strategy.md`. Phase A (multi-client convergence), B (multi-OS), C (sync-latency + UI reflect) are codified there.
+- **Architecture decisions** → `docs/en/architecture/*.md`. The shadow-vault rationale (and why the prior `reconcileFile` route was abandoned) is in `docs/en/architecture/shadow-vault.md`.
+- **Test strategy** → `docs/en/contributing/testing-strategy.md`. Phase A (multi-client convergence), B (multi-OS), C (sync-latency + UI reflect) are codified there.
 - **Performance numbers** → the `perf-baseline` orphan branch's `baseline.ndjson`, refreshed nightly by `bench.yml`.
 - **Issue tracker** → for bug reports, feature requests, design questions.
 - **Security issues** → see [SECURITY.md](SECURITY.md), **not** the public issue tracker.

README.md

@@ -24,8 +24,10 @@
 > attachments, search, and live updates — all served from the remote,
 > transparently.
 >
-> _Status: pre-1.0. End-to-end against Linux + macOS remotes with the bundled
-> Go daemon. Install only into a dev vault for now; production use after v1.0._
+> _Status: 1.0 released — daemon binaries cosign-signed, end-to-end tested
+> against Linux + macOS remotes. Community-store listing pending review
+> ([obsidianmd/obsidian-releases#12390](https://github.com/obsidianmd/obsidian-releases/pull/12390));
+> install via BRAT or manual release until it lands._
 
 > 📦 **Installing?** Grab the latest from the
 > [**Releases page**](https://github.com/sotashimozono/obsidian-remote-ssh/releases)
@@ -48,7 +50,7 @@
 - **Use the plugins you already love.** Dataview, Templater, Excalidraw,
   Tasks, and most plugins that go through Obsidian's vault API work
   unchanged. (Compatibility matrix:
-  [docs/plugin-compatibility.md](docs/plugin-compatibility.md).)
+  [docs/en/user-guide/plugin-compatibility.md](docs/en/user-guide/plugin-compatibility.md).)
 - **Edit from multiple machines.** Live updates push between connected
   clients via `fs.watch`; conflicting saves trigger a 3-way merge UI
   with ancestor / mine / theirs panes.
@@ -149,10 +151,9 @@ BRAT only handles the plugin itself.
 > manifests in lockstep, so BRAT's `--beta` mode (which fetches
 > `manifest-beta.json` from the repo's default branch) gives testers
 > early access to in-flight changes. Stable releases happen via
-> periodic promotion PRs that fast-forward `main` to `next`. Pre-1.0
-> the two channels carry the same builds in practice; once `next`
-> starts landing experimental work that should not auto-ship to stable
-> users, the channels will diverge.
+> periodic promotion PRs that fast-forward `main` to `next`. The
+> stable channel currently leads on `1.0.x`; the `next` channel runs
+> a small lead of patch / pre-release versions ahead of stable.
 
 ### Option B — Manual install
 
@@ -264,7 +265,7 @@ intercept — read or write the local empty shadow directory instead and
 effectively don't see your remote vault.
 
 The full matrix is in
-[docs/plugin-compatibility.md](docs/plugin-compatibility.md). Short summary:
+[docs/en/user-guide/plugin-compatibility.md](docs/en/user-guide/plugin-compatibility.md). Short summary:
 
 - ✅ **Most read-side plugins** — Dataview, Tasks, Calendar, Outliner, …
 - ✅ **Most write-side plugins** — Templater, Daily Notes, Quick Switcher++, …
@@ -397,13 +398,13 @@ the vault model from a different adapter mid-session." The shadow window's
 vault is constructed from the remote tree at startup, so every plugin in
 that window sees a normal-looking vault from frame zero. The full design
 and the smoke evidence behind it are in
-[docs/architecture-shadow-vault.md](docs/architecture-shadow-vault.md).
+[docs/en/architecture/shadow-vault.md](docs/en/architecture/shadow-vault.md).
 
 The performance machinery (`BulkWalker`, `fs.thumbnail` cache) is
-documented in [docs/architecture-perf.md](docs/architecture-perf.md);
+documented in [docs/en/architecture/perf.md](docs/en/architecture/perf.md);
 the conflict + offline-queue design is in
-[docs/architecture-collab.md](docs/architecture-collab.md); the test
-strategy is in [docs/testing-strategy.md](docs/testing-strategy.md).
+[docs/en/architecture/collab.md](docs/en/architecture/collab.md); the test
+strategy is in [docs/en/contributing/testing-strategy.md](docs/en/contributing/testing-strategy.md).
 
 ---
 

SECURITY.md

@@ -46,8 +46,8 @@ To report a vulnerability:
   unless the plugin actively encourages or facilitates the misuse.
 - Social-engineering scenarios where the user explicitly accepts a
   prompt that surfaces the risk (e.g. trusting a host-key change
-  in the upcoming `HostKeyMismatchModal` — we surface the diff and
-  the security implication; the user's choice to trust is theirs).
+  in `HostKeyMismatchModal` (#132) — we surface the diff and the
+  security implication; the user's choice to trust is theirs).
 
 ## Verifying release artefacts
 

docs/en/architecture/index.md

@@ -31,7 +31,7 @@ Obsidian's plugin API is opinionated about vault paths. Rather than forking Obsi
 
 The cost: storage on your local machine grows with what you have opened. The plugin keeps a hot cache of recently-touched files; LRU eviction frees space for files not opened in N days.
 
-### "Pre-1.0 stability promises"
+### v1.x stability promises
 
 The wire protocol is **frozen at version 1**. Method additions are non-breaking (capabilities-gated — see [[en/api/overview|API overview]]). Breaking changes ship as new methods, never modifications of existing ones. This means an old plugin can talk to a new daemon (and vice versa) for the lifetime of v1.
 

docs/en/architecture/shadow-vault.md

@@ -1,6 +1,6 @@
 # Architecture: Shadow Vault Approach
 
-**Status:** Phases 0–6A shipped end-to-end (v0.4.14). Phase 6B (this docs polish) in flight; Phase 6C (plugin compatibility re-verification) pending.
+**Status:** Shipped. The shadow-vault model has been the production architecture since v0.4.14 (Phases 0–6A) and is the basis for the v1.0 release line.
 **Decided:** 2026-04-27
 **Supersedes:** the monkey-patch-and-reconcile approach used through v0.4.3
 
@@ -379,7 +379,7 @@ reader, etc.). User-driven; ~30–60 min.
 
 ## 6. Backwards compatibility
 
-Pre-1.0, so we don't promise stability across this pivot.
+The pre-1.0 cut-overs below were one-time migrations completed before v1.0 shipped; v1.x preserves the shadow-vault shape and `data.json` schema described elsewhere on this page.
 
 - **Removed (PR #69)**: `data.json:autoPatchAdapter` setting
   (Tier 1-A). The shadow vault always-on model replaces it. On

docs/en/contributing/documentation.md

@@ -58,7 +58,7 @@ status: accepted
 | Security reviewer / auditor | Threat model, crypto choices, TOFU & host-key flow, audit log | **P0** |
 | Protocol implementer (alternate daemon) | RPC method spec, wire format, capability negotiation, version compatibility | **P0** |
 | Plugin extension developer | Public API, event hooks, extension points | **P1** |
-| Contributor (engineer) | Architecture, build, test strategy, release process | **P1** (existing assets in `docs/architecture-*.md`) |
+| Contributor (engineer) | Architecture, build, test strategy, release process | **P1** (existing assets in `docs/en/architecture/*.md`) |
 | LLM / agent consumer | Pre-flattened doc dumps optimised for context windows | **P2** |
 
 ---
@@ -150,7 +150,7 @@ The root `index.md` should be a thin landing page with a language picker plus an
 | Hosting | GitHub Pages | Same repo, no separate deploy account |
 | Build CI | GitHub Actions | Reuses repo's existing workflow infra |
 | Search | flexsearch (Quartz built-in) | Client-side, no service to host |
-| Diagrams | Mermaid (Quartz built-in) | Already used heavily in existing `docs/architecture-*.md` |
+| Diagrams | Mermaid (Quartz built-in) | Already used heavily in existing `docs/en/architecture/*.md` |
 | Maths | KaTeX (Quartz built-in) | Reserved for protocol notation if needed |
 | Spell-check | `crate-ci/typos` (CI-only) | Project name allowlist in `_typos.toml` |
 | Link-check | `lycheeverse/lychee` (CI-only) | Both internal `[[wikilinks]]` and external HTTP |
@@ -350,11 +350,11 @@ Each generator script is a standalone `node scripts/gen-*.mjs` runnable locally.
 
 ### Phase 1 — Migrate existing assets
 
-- [ ] Move `docs/architecture-shadow-vault.md` → `docs/en/architecture/shadow-vault.md`
-- [ ] Move `docs/architecture-perf.md` → `docs/en/architecture/perf.md`
-- [ ] Move `docs/architecture-collab.md` → `docs/en/architecture/collab.md`
-- [ ] Move `docs/testing-strategy.md` → `docs/en/contributing/testing-strategy.md`
-- [ ] Move `docs/plugin-compatibility.md` → `docs/en/contributing/plugin-compatibility.md`
+- [x] Move `docs/architecture-shadow-vault.md` → `docs/en/architecture/shadow-vault.md`
+- [x] Move `docs/architecture-perf.md` → `docs/en/architecture/perf.md`
+- [x] Move `docs/architecture-collab.md` → `docs/en/architecture/collab.md`
+- [x] Move `docs/testing-strategy.md` → `docs/en/contributing/testing-strategy.md`
+- [x] Move `docs/plugin-compatibility.md` → `docs/en/user-guide/plugin-compatibility.md` *(landed under `user-guide/` rather than `contributing/`)*
 - [ ] Rewrite root `README.md` and `CONTRIBUTING.md` so they cross-link into the new site
 - [ ] Replace ad-hoc Markdown links with `[[wikilinks]]`
 

docs/en/index.md

@@ -49,7 +49,7 @@ The version shape is the truth: `1.0.43` is stable, `1.0.44-beta.N` is a prerele
 
 ## Project status
 
-Pre-1.0. The shadow-vault architecture is operational, BRAT users are running it daily. The major remaining work is mobile support (iOS/Android) and the multi-client conflict resolver. See the [GitHub issues](https://github.com/sotashimozono/obsidian-remote-ssh/issues) for the live roadmap.
+1.0 released. The shadow-vault architecture is operational; BRAT users are running it daily. Community-store listing is pending Obsidian-team review ([obsidianmd/obsidian-releases#12390](https://github.com/obsidianmd/obsidian-releases/pull/12390)). Mobile support (iOS/Android) is parked as a v2.0 milestone ([#151](https://github.com/sotashimozono/obsidian-remote-ssh/issues/151)). See the [GitHub issues](https://github.com/sotashimozono/obsidian-remote-ssh/issues) for the live roadmap.
 
 ## License
 

manifest-beta.json

@@ -1,7 +1,7 @@
 {
   "id": "remote-ssh",
   "name": "Remote SSH",
-  "version": "1.0.44-beta.3",
+  "version": "1.0.44-beta.4",
   "minAppVersion": "1.5.0",
   "description": "Edit remote vaults over SSH/SFTP — VS Code Remote-SSH style.",
   "author": "souta shimozono",

plugin/manifest.json

@@ -1,7 +1,7 @@
 {
   "id": "remote-ssh",
   "name": "Remote SSH",
-  "version": "1.0.44-beta.3",
+  "version": "1.0.44-beta.4",
   "minAppVersion": "1.5.0",
   "description": "Edit remote vaults over SSH/SFTP — VS Code Remote-SSH style.",
   "author": "souta shimozono",

plugin/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "obsidian-remote-ssh",
-  "version": "1.0.44-beta.3",
+  "version": "1.0.44-beta.4",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "obsidian-remote-ssh",
-      "version": "1.0.44-beta.3",
+      "version": "1.0.44-beta.4",
       "license": "MIT",
       "dependencies": {
         "@xterm/addon-fit": "^0.11.0",

plugin/package.json

@@ -1,6 +1,6 @@
 {
   "name": "obsidian-remote-ssh",
-  "version": "1.0.44-beta.3",
+  "version": "1.0.44-beta.4",
   "description": "VS Code Remote SSH-like experience for Obsidian",
   "main": "main.js",
   "scripts": {

plugin/src/adapter/AdapterManager.ts

@@ -41,7 +41,7 @@ export const PATCHED_METHODS = [
   'getResourcePath',
   // basePath surface — patched so plugins that join paths against
   // it (Templater's tp.file.path, Kanban clipboard paste, Importer,
-  // Copilot — see docs/plugin-compatibility.md "basePath compat
+  // Copilot — see docs/en/user-guide/plugin-compatibility.md "basePath compat
   // survey") get the shadow-vault local root explicitly. The natural
   // FileSystemAdapter getter already returns this value, but routing
   // through the replacement makes the contract explicit and gives

plugin/src/adapter/SftpDataAdapter.ts

@@ -116,7 +116,7 @@ export class SftpDataAdapter {
      * patched onto `app.vault.adapter`, the `basePath` getter and
      * `getBasePath()` method return this value, so plugins that read
      * `adapter.basePath` (Templater's `tp.file.path`, Kanban's clipboard
-     * paste, Importer, Copilot — see `docs/plugin-compatibility.md`)
+     * paste, Importer, Copilot — see `docs/en/user-guide/plugin-compatibility.md`)
      * receive a path on the shadow vault. Reads against that path
      * succeed against files mirrored locally by the file watcher;
      * writes land in the shadow dir and propagate to the remote.
@@ -126,7 +126,7 @@ export class SftpDataAdapter {
      * vault root via `(adapter as FileSystemAdapter).getBasePath()`
      * captured before the patch is applied.
      *
-     * Survey: PR #165 / docs/plugin-compatibility.md "basePath compat
+     * Survey: PR #165 / docs/en/user-guide/plugin-compatibility.md "basePath compat
      * survey". Implementation: #170.
      */
     private shadowBasePath: string = '',
@@ -153,7 +153,7 @@ export class SftpDataAdapter {
   /**
    * Mirror of `FileSystemAdapter.getBasePath()`. Equivalent to the
    * `basePath` getter; both are surveyed-as-used by community plugins
-   * (#133, see `docs/plugin-compatibility.md`).
+   * (#133, see `docs/en/user-guide/plugin-compatibility.md`).
    */
   getBasePath(): string {
     return this.shadowBasePath;

plugin/src/main.ts

@@ -645,7 +645,7 @@ export default class RemoteSshPlugin extends Plugin {
 
   /**
    * POC for the shadow-vault architecture (see
-   * docs/architecture-shadow-vault.md, Phase 1): walk the patched
+   * docs/en/architecture/shadow-vault.md, Phase 1): walk the patched
    * adapter, then hand the resulting entry list to `VaultModelBuilder`
    * which materialises TFile/TFolder objects in `app.vault.fileMap`
    * and fires `vault.trigger('create', file)` for each new file. File

plugin/tests/compat/CompatVault.ts

@@ -16,7 +16,7 @@ import type {
  * Excalidraw / Tasks) can drive without a real Obsidian process.
  *
  * Scope: the **hot read/write APIs** identified in the
- * `docs/plugin-compatibility.md` survey for the top-20 plugins,
+ * `docs/en/user-guide/plugin-compatibility.md` survey for the top-20 plugins,
  * narrowed to what plugins actually call (not the full obsidian.d.ts
  * surface). Adds-as-needed when a new plugin scenario hits an unmocked
  * method.