@mnstry/atelier 0.2.0-alpha.11 → 0.2.0-alpha.13

package/CHANGELOG.md

@@ -1,5 +1,1010 @@
 # Changelog
 
+## 0.2.0-alpha.13
+
+- Add the public Knowledge Health workshop on the existing local Knowledge
+  host: original wording, separate interpretation and four distinct responses;
+  optional Review in a separate session; a selected-draft copy-only handoff
+  retained with its original receipt. Exact retries do not append duplicates,
+  and reopening after restart reads the same proposal. The source owner edits
+  through ordinary repository tooling and reassesses; no browser source-apply
+  endpoint is added. Include the installed workshop kit and receiving guidance.
+- `atelier knowledge semantic` exposes the internal semantic operation runner
+  (`docs/semantic-operation.md`) as eleven operations: `begin`, `status`,
+  `reconcile`, `complete`, `proposals`, `contribution`, `relation`, `record`,
+  `cascade`, `context` and `project`. Each reads one JSON object
+  `{workspaceId, run, request}` from stdin, at most 256 KiB, in the workspace
+  `atelier ingest` uses. Each operation accepts exactly its documented request
+  fields, each of a declared kind; an unknown or missing field, a null
+  required field or a value of the wrong kind refuses as
+  `SEMANTIC_OPERATION_INVALID` before any store is opened, so nothing is
+  written. Formats such as timestamps are checked by the runner. Atelier calls no model: the host supplies its raw output, candidates
+  and usage (`null` when unknown), and interpretations stay pending until
+  receiver records, which are caller assertions, accept them. Failures print
+  `{ok:false, code, error}` with the runner's own `SEMANTIC_*` code,
+  `SEMANTIC_OPERATION_INTERRUPTED` for an uncoded error, or
+  `SEMANTIC_OPERATION_REFUSED` for Atelier's other refusals; `recorded` or
+  `captured` details are included whenever the runner attached them. No package export
+  or schema changes.
+
+## Unreleased
+
+- Patch the fast-uri dependency and override from 3.1.7 to 3.1.8, the patched
+  3.x release for GHSA-hrr3-gc8f-f4qj (3.1.7 is in the affected range; whether
+  Atelier's use was exploitable is not established). The direct dependency
+  keeps packed consumers on one deduplicated copy: Ajv's own `^3.0.1` range
+  resolves to it, so a bare consumer installs 3.1.8 only.
+- Personal workspaces gain an explicit selection record, a read-only inventory of
+  the private home, and a restore of authored inputs from an earlier generation:
+  `selectPersonalGeneration`, `selectionConfirmDigest`, `readPersonalSelection`,
+  `inventoryPersonalHome`, `planPersonalRestore` and `restorePersonalInputs`. A
+  selection is a confirmed, hash-chained choice of the eligible generation. A
+  restore accepts only a plan from `planPersonalRestore`, re-checks the exact
+  current bytes, keeps them, and never widens enrollment or bindings:
+  re-admitting a withdrawn repository, a changed repository identity, or a
+  re-added binding refuses before any write. Each file is replaced by
+  compare-and-swap, so a write that replaces or recreates the file by path
+  during the restore is kept and the restore refuses; an interrupted swap
+  refuses `restore-interrupted` until the listed moved copy is put back.
+  Authored inputs, generations and records are never deleted; only temporary
+  files are removed.
+- A private-domain repository owner can let one named operator pass the local
+  boundary actor check by signing a delegation
+  (`docs/repo-boundary-guard.md`). It covers only `atelier boundary check` and
+  the `pre-commit` path, for listed repositories, for at most 90 days. It never
+  changes ownership, audiences, paths, content rules, promotion, push-content
+  checks or publication. It applies only when all of these hold:
+  - its ed25519 signature verifies against the owner's key in the host file
+    `/etc/atelier/boundary-owner-keys.json`, owned by root in root-owned
+    directories (Windows is not supported yet);
+  - it is current and not revoked in that file;
+  - the whole boundary policy, the managed repository set and each repository's
+    root commit match what the owner signed.
+
+  It records consent for a cooperating operator; the actor check stays
+  attribution, not authentication. Delegations live in
+  `boundary-delegations.v1.json` beside the policy, under the new
+  `atelier-boundary-delegations@v1` and `atelier-boundary-owner-keys@v1`
+  contracts; the boundary policy contract is unchanged.
+  `atelier boundary delegation draft|sign|verify` prepares, signs (after
+  recomputing the bindings) and inspects them. The policy validator now accepts
+  the `contractVersion` and `ext` members its schema already declared; `ext` is
+  ignored.
+- A capability operation that has committed no longer reports `EEXIST` ("not
+  entered") when its lock is removed or replaced while cleanup inspects it.
+  Cleanup preserves the other file and returns the operation's result. Lock
+  races in reclamation, readback and cleanup are each covered by a test.
+- `src/judgment/practice.mjs` and `src/judgment/practice-evaluation.mjs` keep a
+  reusable decision practice inside an ordinary Knowledge contribution
+  (`docs/decision-practices.md`). They are internal: the
+  `atelier.decision-practice/v0` format is experimental, not a registered public
+  contract, and has no package export, CLI command, adoption store, scheduler or
+  model route. A definition is prepared as a captured contribution for the
+  existing Knowledge review path, and is read as adopted only from an exact
+  contribution digest with a current accepted review and activation in the
+  supplied history. `evaluateDecisionPractice` returns `proceed`, `stop`,
+  `escalate` or `refuse` with a typed reason from declared prerequisites, count
+  budgets, exact current evidence and an existing decision request and result.
+  It calls no provider, and an abstention escalates. A proceeding outcome
+  prepares an unaccepted reconsideration draft; nothing is appended, accepted or
+  activated by the module. Inputs are bounded to a portable profile, and a
+  larger history refuses `practice-input-exceeds-bounds`. The instruction
+  adoption command `atelier practice` is a separate concept.
+  `atelier architecture entry practical-judgment` lists both modules.
+- `src/ingestion/semantic.mjs` prepares source-bound entity and assertion
+  proposals from a host's extractor output, one source per input
+  (`docs/semantic-ingestion.md`). It is an internal module: its `v0` formats are
+  not public contracts, and it has no package export or CLI command. The host
+  must already hold whole-plan read permission, which the module does not grant,
+  and chooses and runs its extractor. The module makes no provider call, durable
+  write or graph change, and claims no extraction quality. `readSemanticProposals`
+  gives a search view that rereads the cited evidence. Proposals and identity
+  mappings stay pending and carry no authority: identity, semantic acceptance and
+  activation remain separate decisions of the existing knowledge review owner, and
+  this release maps nothing into knowledge review or activation records.
+  `atelier architecture entry knowledge-stewardship` lists the module.
+- A personal workspace bound to the Obsidian projection is served from the
+  canonical build, with the composition's link-target rule and the engine's file
+  cache. A graph is used only under a validity key the composition confirmed.
+  Its inputs are read before the composition runs. The engine, and the
+  proposal adapter it runs, compose in a worker with a two-minute deadline: at
+  load (`loadBoundProjectOffThread`), after a change, and at every full
+  reconciliation, which prepares nothing again when nothing changed. A bound
+  project is loaded once. Authored and generation files the key reads are
+  opened without following links or waiting on them. The adapter builds only
+  when it looks at a newly observed edit. The proposal adapter answers a vault edit to a private
+  note with `personal-overlay-not-proposed`, and `personal-binding-lost` now
+  names the reserved settings key.
+
+- Evidence navigation is exported as `@mnstry/atelier/evidence-navigation`
+  (the pure contract checks and currency assessments) and
+  `@mnstry/atelier/evidence-navigation/local` (the Node local reader, kept
+  separate), with its schema at
+  `@mnstry/atelier/contracts/atelier-evidence-navigation.v1.schema.json`. The
+  schema and its fixtures join the contract corpus. There is no CLI command:
+  search and get need a host to construct the reader with its exact plan,
+  workspace and current whole-plan admission, and Atelier ships no issuer of that
+  authority.
+- The Obsidian projection has one route for a personal workspace. A binding
+  names a private home and a generation explicitly. Every caller that builds
+  the graph (the engine, view counts, source apply, the proposal adapter and the
+  selection operation) then reads the composed graph, which composition checks
+  again at every build. The overlay's saved views become scopes, plus an
+  `everything` view. Composition refusals keep their codes, at load and at
+  every build, and no view is current under one. The engine observes the
+  person's manifest and overlay, so a generation that stops holding is refused
+  at the next tick. A copy of a bound project that lost its binding is refused.
+  `view add`, `audience` and `location` refuse on a bound project and write
+  nothing, and a vault edit to a private note is refused, never applied. A
+  theme is never written, and coverage is passed through unread. No command or
+  service binds a personal workspace yet.
+
+- The knowledge workspace states its supported interfaces
+  (`docs/knowledge-workspace.md`).
+  - Two outputs are versioned contracts: the context packet
+    (`atelier-knowledge-context@v1`) and the evaluation report
+    (`atelier-knowledge-evaluation@v1`).
+  - The other CLI outputs, the browser routes and the sidecar's `knowledgeProject`
+    option are experimental.
+  - The workspace modules have no library export. `@mnstry/atelier/knowledge`
+    keeps its existing exports.
+  - `atelier architecture entry knowledge-stewardship` lists the workspace modules
+    and the `knowledge` command.
+  - `npm run knowledge:consumer-proof` installs a packed tarball into a clean
+    consumer and checks the documented CLI paths, writing a receipt bound to the
+    tarball SHA-256.
+- Personal workspaces are exported as `@mnstry/atelier/personal-workspace`,
+  with their manifest and overlay schemas under `@mnstry/atelier/contracts/`. The
+  public API is these nine exports: `MANIFEST_SCHEMA`, `OVERLAY_SCHEMA`,
+  `PersonalWorkspaceRefusal`, `loadPersonalManifest`, `loadPersonalOverlay`,
+  `resolvePersonalWorkspace`, `planPersonalGeneration`,
+  `materializePersonalGeneration` and `composePersonalWorkspace`. The composition
+  is manifest-only, with enforcement `none`: filesystem access, disclosure,
+  effects and the host sandbox are reported as uncovered, and no consent or
+  effect enforcement is claimed. The manifest and overlay schemas join the
+  contract corpus.
+
+- The ingestion store adds `getEvidence`, which returns one exact evidence span
+  after rechecking only that source and its stored attempt. Query and
+  `getEvidence` both report `readScope: "all-plan"`: they read at the scope of
+  the whole plan and grant or narrow no permission.
+- Preserve workspace template lineage during profile adoption and updates.
+  Keep profile identity in its typed adoption manifest, and refuse saved plans
+  that replace the workspace lineage before installing any managed content.
+- Verify exact upgrades from a real 0.2.0-alpha.12 lock as well as the
+  alpha.10 lock, and check that the upgraded lock records the installed version.
+- A long-lived reader of verified history (learning and ingestion stores) no
+  longer wedges after one refused read; it replays from a clean copy.
+- Ingestion reads take no lock and bind no workspace identity; only `plan`
+  binds it, so reads work during a run and a mistyped id is not recorded.
+- Inquiry graph proposals label each file, and the proposal, with the most
+  restrictive audience of the sources whose material they carry.
+- Coordination reports every dependency cycle regardless of record order, and a
+  superseded directive stays superseded when its replacement goes stale.
+- Reflective and coaching acts require Reflection, an assessment and a request
+  whatever their origin.
+- The responsibility commands print only their own refusals; Node, git and
+  parser errors go through the typed-code rule and never show paths or input.
+
+- Preserve the bundled readiness pack's immutable v1 content and digest so
+  previous release locks can use both exact upgrade participants without a
+  separate lock rewrite. Keep Discovery Harness naming in the architecture
+  catalog; retain Discovery Engine in the persisted readiness pack. Add a
+  real alpha.10 lock fixture, plan/application regressions and digest refusal
+  controls.
+
+- Add portable template profiles, digest-bound project bindings, staged structural
+  validation and canonical read-only presentation through installed package APIs.
+- Add explicit local template adoption and updates through the existing exact-plan
+  upgrade engine, preserving source, local customization and adoption history.
+- Reuse Git placement checks within synchronous ingestion read operations;
+  recheck at operation boundaries and around writes without caching source bytes
+  or integrity verdicts.
+
+- Preserve recorded Trackable calendar resolutions across host timezone-data changes; retain verified-chain export when legacy replay cannot reconstruct state.
+
+- Correct unchanged instruction re-adoption and preserve literal replacement text during revisions; add recovery and neighboring-slot regressions.
+- Recover recognized dead capability operation locks without requiring an adoption journal; preserve live, uncertain and replacement owners.
+- Add portable Trackable definitions, shared preview/runtime rules, durable scoped reference storage and correction.
+- Add evidence-qualified Reflection, one-authority Interaction delivery, and bounded cross-repository Coordination views.
+
+- Reconcile eight responsibility names and typed consumer bindings; preserve historical aliases.
+- Connect durable ingestion to source-current knowledge context and graph proposals.
+- Add situated judgment and native ADR adapters, capability feedback, and recoverable scoped instruction adoption.
+- Include a provider-agnostic research starter and Practical Judgment operating skill.
+
+- Add Knowledge Harness, Fabric-derived Build Harness and shared typed handoffs, with immutable local history, intake and inquiry bridges, graph activation, correction propagation and version-bound skill feedback.
+
+- Add local Discovery and Research Harnesses with versioned inquiry records,
+  portable research handoffs, reproducible basic belief calculations, evidence
+  dependence and withdrawal checks, and reviewable graph proposals. Add separate
+  capability packages and version-bound Skill Steward feedback. Rename the
+  discovery workflow through the architecture catalog while retaining the
+  bundled readiness pack's persisted title, identifiers and digest.
+- Add an experimental progressive local ingestion runner with exact plans,
+  bounded deterministic text/CSV/JSON extraction, immutable intake reuse,
+  resumable attempt accounting and source-verified lexical queries. Add a
+  JSON stdin CLI and structural evaluation that retains missing cases and
+  unknown costs. No model dispatch, automatic semantic acceptance or native
+  desktop admission is provided by the portable runner.
+
+- Add a portable local learning lifecycle: Evidence, proposals, exact decisions,
+  explicit harness activation, withdrawal and retained history. Include a JSON
+  stdin CLI, private graph/export projections, bounded proposal-assistance
+  adapters and compatibility with existing skill observations. Local actor
+  assertions do not authenticate users; check artifacts remain inert and hosts
+  retain execution and access authority.
+
+- Recompile cached JSON Schema validators when caller-owned schemas change; preserve unchanged-schema reuse and fresh compilation for non-JSON schemas.
+
+### Added
+
+- Add opt-in knowledge dashboards and source-bound coauthor flows, sharing private drafts between the local browser and CLI, with evidence comparison and restart recovery.
+
+- A `knowledge-workspace` starter, mirrored `atelier-knowledge-setup` agent
+  skills, and `atelier knowledge check|context|evaluate`: question-led ontology
+  coverage, complete source context within an exact byte budget, and a lexical
+  versus graph comparison with source-digest and directed-relation checks.
+  Local operator output carries no expression or execution permission. Token
+  estimates remain distinct from measured usage and accepted work.
+
+- `atelier enroll documents [--audience private] [--dry-run] [--json]` writes
+  a minimal `<file>.kg.json` sidecar next to every `.html`, `.pdf` and
+  `.docx` document the knowledge graph reads that has none, so an adopted
+  vault with attachments, a static website or a folder of documents can pass
+  `atelier graph` without hand-written sidecars. Each sidecar carries the
+  document's title, the domain, lifecycle and status the graph infers, the id
+  `<repo>:asset:<path>` (with a short digest when two paths fold to one id)
+  and the audience `private`. `--audience` picks another, which the
+  repository's boundary policy must allow; a refusal is typed
+  (`enroll-audience-not-allowed`) and names the allowed audiences before
+  anything is written. An existing sidecar, including one Git ignores or a
+  link with the sidecar's name, is never changed, and sources are never
+  changed. See `docs/install.md`.
+- `atelier adopt --enroll-documents [--audience AUDIENCE]` adopts and enrolls
+  in one step, checking the audience against the policy before adoption
+  writes anything.
+- A login item keeps a workspace's vaults fresh after you log in:
+  `atelier obsidian service unit --install [--consent-actor ID]
+  [--adapter=obsidian-cli]` installs a launchd agent on macOS
+  (`~/Library/LaunchAgents/ai.mnstry.atelier.<project>.<workspace-id>.plist`)
+  or a systemd user unit on Linux
+  (`~/.config/systemd/user/atelier-obsidian-<workspace-id>.service`), after
+  recording a consent that covers startup (`--consent-actor ID`; at a
+  terminal, the actor already recorded or else the account's name). A
+  service of an earlier release still running is stopped just before the
+  unit is loaded, so the unit's first start runs the installed release.
+  `service unit --remove` lowers the consent to the service alone, removes
+  the item and starts the service again at once for this session only;
+  `service unit --print` shows what `--install` writes. The answer is
+  remembered as the machine settings' `loginItem` decision (`on`, `off`), and
+  `atelier obsidian settings` names these commands as the way to change it. The unit runs the package installed in the project,
+  by its path, with the Node that installed it (its real path), the search
+  path you had (absolute, non-temporary entries), in `/`, and names the data
+  root the workspace was resolved under and the workspace
+  (`--data-root`, `--workspace-id`), so the service at login finds that
+  workspace whatever its manager's environment carries, and records a refusal
+  there when the project no longer leads to it. launchd: `Standard`
+  process type, `RunAtLoad`, `KeepAlive` `SuccessfulExit` false,
+  `ThrottleInterval` 60, `ExitTimeOut` 60, output to
+  `state/service/login-item.log`. From `npx` without a package installed in
+  the project it refuses (`login-item-needs-installed-package`); Windows is not
+  offered (`startup-platform-unqualified`); without a user systemd the answer
+  is `login-item-unavailable`. The installed item is recorded in
+  `state/service/login-item.json` (`atelier-obsidian-login-item/v1`).
+- Once a login item is installed, `service start`, `open` and the replacement
+  of an outdated service start the service through launchd or systemd
+  (`kickstart -p`, `systemctl --user start`) instead of as a child, and accept
+  the service that proves itself with the entry the item runs. A unit that
+  differs from what would be written now is written again and reloaded, and
+  `open` says `login item refreshed`. An item switched off in System Settings
+  or with `systemctl --user disable` is not forced: it is neither written
+  again nor started through its manager, and the service is started for that
+  command only.
+- A service started by a login item (`--startup`) keeps its own bounded
+  `service.log`, exits 0 on a refusal as well, so it is not restarted every
+  minute, and records how its start ended in `state/service/last-startup.json`
+  (`atelier-obsidian-last-startup/v1`); `status` shows the login item and
+  `the login item did not start the service: <code>` with the next step. After
+  each tick it compares its package on disk with the release it started with
+  (file status first, then a digest of `src/`, `contracts/` and `plugins/`
+  and the version) and exits 75 after the tick when it changed, which its
+  manager restarts on the new release.
+- `atelier obsidian uninstall` removes the login item and stops the proven
+  service, and starts nothing. Vaults, private state, the project file and
+  Obsidian's vault list are kept, and it prints where each is.
+- `readReleaseIdentity({ root })` reads a package's release identity now,
+  uncached; `releaseIdentity()` stays its cached form.
+- The production service manager refuses under the Node test runner
+  (`real-login-item-under-test`) and when HOME is not the account's own home
+  directory (`login-item-home-mismatch`), since launchd and systemd register a
+  unit in the account's real session whatever HOME says.
+- `atelier obsidian open` gets through the Obsidian states it used to stop
+  at. For an Obsidian that is installed and never started (no
+  `obsidian.json`), and only while the process table shows that no Obsidian
+  runs, it creates the settings file with the view's vault flagged open and
+  the command line on, exclusively (a file the app wrote first is kept), in a
+  settings folder made private to you when it is missing; Obsidian then opens
+  the vault at a plain start (`registration.how: created-settings`). Whenever
+  it writes Obsidian's vault list with the app quit, it also turns the
+  command line on (`cli: true`) in the same guarded write, with the backup of
+  the file as it was; a listed vault whose switch is off is written for the
+  switch alone. With `--restart-obsidian`, a running Obsidian that cannot be
+  reached (its command line off, or no vault open and the view's vault not in
+  its list) is quit with SIGTERM to its proven main process only, the vault
+  and the switch are written once it has gone, and it is started again
+  plainly, reopening the vaults it had open (macOS only). Without the flag,
+  those states answer `app-cli-unavailable` / `cli-turned-off` and
+  `app-version-unsupported` / `no-vault-open`, naming it. The flag is never
+  implied and every other operation refuses it. Every write and the restart
+  are shown in the answer (`obsidianSettings`, `restart`). Before any signal,
+  `open` checks, reading only, that the write can succeed (otherwise it
+  answers that refusal and leaves Obsidian running; an Obsidian at its
+  starter window with no `obsidian.json` yet is the create case) and, right
+  before the first signal, keeps a copy of `obsidian.json` that the same
+  run's write does not prune. On macOS the main process can stay after the first
+  SIGTERM, with its windows closed; Electron handles only the first SIGTERM as
+  a quit, and a second one ends the process at once, without its quit
+  handlers. `open` sends that second one only when the same process has
+  stayed alone, with no window or helper, at two readings at least 5 seconds
+  apart; never a third, and never another kind. `atelier obsidian --help` names every option of the
+  command, `--wait-ms` included. See "What `open` does in each state of
+  Obsidian" in `docs/obsidian.md` and "Obsidian's vault list" in
+  `docs/obsidian-contract.md`.
+- Views can be declared without editing JSON:
+  `atelier obsidian view add ID (--all | --folder PATH [--folder PATH ...] [--repo R] | --tag T) [--expand DEPTH:MAX] [--default]`
+  adds a view to `atelier.project.json` (and `.atelier-local/` to
+  `.gitignore` when that folder is not ignored), and never commits. It shows
+  the change as a diff and how many notes the view would show on this machine,
+  with how many of the notes it selects are withheld for carrying no
+  classification or an audience that is not admitted. A view that would show
+  no note is refused with `view-would-be-empty` unless `--allow-empty`. A
+  person at a terminal is asked before anything is written (`--yes` answers
+  beforehand; no answer within 10 minutes writes nothing); for anyone else the
+  command is the consent. The file is rewritten only when it is in the form
+  Atelier writes JSON in, so the change is the view and nothing else
+  (`project-config-format-unknown` names the member to add by hand
+  otherwise), atomically, keeping its mode, and only over the bytes it read
+  (`project-config-changed`). A file that is not UTF-8 is never rewritten
+  (`gitignore-not-utf8`, or `project-config-format-unknown`). Every new text
+  is written and synced to disk before any file is replaced; a failure after
+  that says which files changed (`project-files-partly-written`), and no
+  temporary file is left beside them. The first view is the default. `view list` and
+  `view show ID` are `scope list` and `scope show ID`.
+
+### Changed
+
+- Where a workspace's vaults live can be decided, and a visible folder can
+  hold them: `atelier obsidian location set DIR` (`~/Atelier`, say) records
+  the `location` decision. Each view not published yet is then given its own
+  folder there at its first publication, `<project> (<view>)`, which is also
+  the vault's name in Obsidian (`harbor-notes (everything)`; a number inside the
+  parentheses when that name is taken on the disk or by a vault the app lists).
+  The folder is created exclusively and private to this user, and its
+  allocation is recorded once in the workspace's private state
+  (`atelier-obsidian-vault-allocation/v1`, `state/allocations/<view>.json`,
+  with the folder's real path, device and inode, which the maintenance service
+  checks at every tick and the publisher before it writes, before each note
+  and before its commit: another folder put
+  where the one made was is not published into, `vault-allocation-replaced`,
+  nor is the same folder reached through a link put on the way since,
+  `vault-allocation-moved`; on Linux a folder made after the original was
+  removed can be given its inode number, see Known limits in
+  `docs/obsidian.md`. A folder that has gone is made again by the next tick,
+  only where its recorded real path leads and only where a location would be
+  accepted: never inside a repository, the project, the private state, a vault
+  Atelier publishes or one the app lists; a vault removed, moved or replaced
+  while it was being published stops that publication (`vault-root-moved` for
+  a vault under the data root), and the running service, without a restart,
+  publishes into it again once it is put back or made again: at once, or, for
+  a folder made again after a publication stopped just before its commit, at
+  the next change at its sources (`vault-note-missing` until then). A published view whose vault cannot
+  be found (its record was lost, or a view published under the data root lost
+  its `vaults/<view>` folder, which was made again before) is refused,
+  `vault-allocation-lost`, never published again into a new, empty vault;
+  `status` and `open` name the way back),
+  which the recovery store reads: the engine, source apply, the proposal
+  adapter, `open` and the plugin's service paths (its hello, the person's
+  choice to turn it off, drift) all find the same vault. So does
+  `viewVaultRoot` of `@mnstry/atelier/obsidian`, which answers the allocated
+  folder now, and may refuse, typed (a record that cannot be read, or was
+  lost); pass the workspace id as its third argument: without it the name of
+  the workspace's private-state folder is taken as the id, as before, and a
+  record that does not match it is refused. A vault published before stays
+  under the data root, and a workspace that decides nothing publishes there as
+  before. A folder inside a repository or the project, inside a vault Atelier
+  publishes or one the app lists, or on another volume than the data root is
+  refused, through links and in any letter case; a synced one needs
+  `--allow-synced-location`; a macOS-protected one is warned about. The app's
+  list is read through the app when it answers, else from its settings file;
+  while it cannot be read, no folder is allocated (`app-vault-list-unreadable`,
+  tried again at the next tick). A view whose folder cannot be allocated is not published
+  and its freshness says why, while the other views go on: a folder that
+  cannot be made (`vault-location-unusable`: a file in the way, no
+  permission), one inside Atelier's private state
+  (`vault-location-inside-private-state`, refused by `location set` too), an
+  allocation record that cannot be read or names a folder inside a
+  repository, each stops its own view only. `location show`
+  and `status` (`scopes[].vault`) say where each view's vault is, or why it
+  cannot be read. Consent to a synced folder is not recorded, so it is not
+  checked again when a folder is allocated or made again; a link on the way is
+  followed only at a view's first allocation (Known limits).
+- A vault that is only yours shows the notes that carry no classification:
+  `atelier obsidian audience set me` now records `unclassified: shown` with
+  "only you", and every path that builds a view (the engine, source apply,
+  the proposal adapter, `selection`) admits them through one rule,
+  `eligibilityFor`. A list of audiences never shows them, even one that names
+  every audience "only you" stands for. Such a note is shown only when its
+  bytes read as a note the way the emitter reads every note, so a file that
+  cannot be published stays withheld instead of stopping the vault. Deciding
+  it changes the eligibility revision, so every view is rebuilt at the next
+  tick. A decision recorded as "only you" with them withheld keeps them
+  withheld until `audience set me` is run again. `view add` counts what a
+  view would show the same way, as "only you" while nobody decided. Since
+  the maintenance service publishes no note until someone decides who may
+  see, `view add` then names `atelier obsidian audience set me` as the next
+  step, before `open`; and a view refused as empty because no audience is
+  admitted (`audience clear`) is told to decide who may see, not to classify
+  notes. A note whose labels cannot be known is never shown: front matter
+  Atelier cannot read, or a top-level `kg` key that is not a block, may say
+  `sensitive`.
+- A view's first publication into its allocated folder no longer waits for an
+  Obsidian that runs and cannot be coordinated with (a vault open, its command
+  line off, no vault open, or a version below the floor). While the app's own
+  settings file names neither the folder, a folder above it nor one inside it
+  (read, not guessed: a missing or unreadable file, an entry with a `..`
+  segment, or a Flatpak or snap build, gives no such evidence), the publisher fills the vault in its own process by
+  creating files only (journal `mode: 'direct-unheld'`). Anything that would
+  replace or remove a file, or write a settings file over one that is there,
+  refuses as `editor-uncoordinated` and writes nothing. The evidence is read
+  again before the first file and every two seconds, and once it is gone
+  nothing more is written or committed. A run that completes is committed
+  before `open` adds the vault to Obsidian and opens it. A run that stops
+  partway commits nothing: the list names the folder meanwhile, a settings
+  file with other bytes is already there, or an interrupted run left a
+  replacement or a removal. The view then falls back to the coordinated path,
+  so `open` may add the vault to Obsidian and open it before it is complete,
+  and the rest, every replacement and removal included, is published through
+  the app with its usual checks. While the app does not qualify, a run stopped
+  that way reports the app's own refusal (`app-cli-unavailable`, say), and
+  `open` answers it without adding the vault unless asked to restart
+  Obsidian; with the app running and no vault open, a vault the app already
+  lists is still opened by its path, as before. The plugin's entry written this way counts as offered until the
+  plugin says hello. A later generation, a vault under the data root, and
+  every other case publish and refuse as before.
+- The Obsidian machine settings of a workspace remember what a person decided
+  once, so no later run has to ask again or be told again: who may see the
+  vaults, where they live, whether maintenance starts at login, and that the
+  installed app may be reached. The document is now
+  `atelier-obsidian-machine-settings/v2`, with a closed `decisions` member,
+  one entry per decision (`audience`, `location`, `loginItem`, `adapter`),
+  each null until decided and otherwise stamped with when, by whom when known,
+  and how (`question`, `command`, `defaults`, `v1`). The audience decision
+  also says whether notes that carry no classification are `shown` or
+  `withheld`: only an "only you" decision may show them, and every decision
+  made today withholds them. A v1 document is read as the v2 document it
+  stands for and stays v1 on disk until the next write, which writes v2; an
+  audience list set before is carried over as that person's decision, with
+  unclassified notes withheld as they were. A release up to 0.2.0-alpha.12 refuses a v2 document
+  (`invalid-machine-settings`), so after an upgrade a maintenance service
+  still running the earlier release fails its ticks until it is replaced:
+  `atelier obsidian open` and `service start` replace it. `atelier obsidian settings` shows what is remembered and
+  how each answer is changed; `status` carries the decisions and a one-line
+  summary.
+- `--adapter=obsidian-cli` is needed once per workspace. Given to `open` or
+  `service start` of an enabled project, it is remembered before anything
+  starts, and later runs of the real command-line entry reach the app without
+  it (`service unit --print` too). A remembered adapter is never used under
+  the Node test runner (`remembered-adapter-under-test`), and never by a
+  caller that passes its own seams; the decision is one pure rule,
+  `selectAdapter`.
+- The first start of the maintenance service records who allowed it: still
+  `--consent-actor ID`, or now, for a person at a terminal, the name of the
+  account the command runs as, which the command says it recorded. A person
+  is at a terminal when standard input and output are both terminals and
+  nothing says otherwise: `--json`, the new `--no-input`, a `CI` environment
+  or `ATELIER_NONINTERACTIVE=1` mean nobody is (`isInteractive`). A consent
+  recorded already is never replaced by a derived one, and a program still
+  names its actor.
+- `atelier obsidian audience set me` admits "only you": every audience of a
+  note (`public`, `team`, `operator`, `staff`, `private`) except `sensitive`,
+  which a vault takes only when it is named (`audience set me,sensitive`).
+  Any other list is the person's own; either is remembered as their decision.
+  Notes without a classification are still withheld from every vault,
+  "only you" included; a later change lets an "only you" vault show them.
+
+- `setup.include` and `setup.exclude` in `atelier.project.json` now scope
+  what the knowledge graph reads. `adopt --include` and `--exclude` recorded
+  them, and the `monorepo` profile required `--include`, but nothing read
+  them, so a tracked build folder could not be left out and every tracked
+  page needed a sidecar. Each is a path pattern relative to the project
+  config's folder, in the boundary policy's `forbiddenPaths` dialect; a path
+  outside the scope is treated exactly like a Git-ignored one, and a sidecar
+  follows its source. A project that already sets either field gets a graph
+  over that scope from this release: run `atelier graph` and commit the
+  result. Both values must now be relative (the contract's `pathString`), and
+  `adopt` no longer writes them as `null`. The decision is recorded in
+  `docs/install.md`.
+- `atelier graph` ends its error list with a `Next:` line naming
+  `atelier enroll documents` when a document has no sidecar.
+- `service unit --print` prints the unit `--install` writes: on macOS under
+  the label `ai.mnstry.atelier.<project>.<workspace-id>`, with process type
+  `Standard` instead of `Background`, the search path, `WorkingDirectory` `/`
+  and output to `login-item.log` instead of `service.log`; on Linux with
+  `Environment="PATH=…"`, `WorkingDirectory=/` and `TimeoutStopSec=60`.
+  `buildStartupAdapter` takes `searchPath`, and its working directory is `/`
+  unless one is given. A service records the path it was started by beside its
+  real path (`executable.ext.invokedAs`), and the busy proof accepts a process
+  table that names the entry through it.
+- Whether a running maintenance service is of an earlier, the same or a
+  later release is measured against the entry that would be started: its
+  digest and the release of the package that entry's path names, read now.
+  With a login item that is the project's own package, whatever package the
+  command runs from, and a re-pointed link or `file:` install is read where
+  it leads.
+
+### Fixed
+
+- `atelier obsidian open` with a view the maintenance service did not publish
+  because Obsidian's command line is off now answers `app-cli-unavailable` /
+  `cli-turned-off` with its next step, instead of the view's own
+  `not-prepared` or `stale-readable`: such a view counts as one the app kept
+  from publication, which `open` publishes once the app holds the vault.
+- `atelier obsidian service start` replaces a maintenance service of an
+  earlier release still running after an upgrade, as `open` does (stopped
+  through its own listener, the installed release started under the consent
+  already recorded, `replaced: 'outdated'`), instead of answering that it is
+  already running while that service fails every tick on the new machine
+  settings. A service of a later release is left running (`release:
+  'later'`).
+- `atelier obsidian open` no longer answers `app-cli-unavailable` /
+  `vault-open-cli-silent` on the first silent round after it launched the
+  vault. A version only Atelier's plugin gave, with no answer for the vault,
+  now has to be seen in two rounds in a row: one version call that timed out
+  while Obsidian was busy opening its window made `open` report a command
+  line that was only slow as switched off. A wait that ends right after one
+  such round still gives that answer, not `launch-failed`.
+- A view kept `current` while a plugin file it pins waits for Obsidian (a
+  drifted `data.json`, say, while the app cannot be coordinated with) now
+  says so. Its reason is `verified-by-read-back-plugin-waits-for-app`
+  instead of the `verified-by-read-back` of a view whose plugin files are all
+  there, and `status` and `open` add `plugin files wait for the app` to the
+  plugin line, with a next step (`files: "waits-for-app"` and `next` on
+  `plugin` in `--json`). A drift that publishing would only leave for the
+  person again (the data file of a vault root that is a link or not private,
+  a folder where a file goes) is no longer a reason to publish a committed
+  generation again, so it never waits for the app and never gets that
+  reason; the path is left as it is (nothing names it in `status` yet, and
+  the plugin shows as not present).
+- A view held because a plugin file (`plugin-file-changed`) or a settings
+  file (`settings-changed`) changed while it was published, by another
+  program or by the person, is still `publisher-conflict`, but its next step
+  no longer tells the person to close another publisher: it names the file
+  that stopped the publication and says that the view is retried
+  automatically.
+- A plugin-file drift that publishing cannot repair (the data file of a vault
+  root that is a link, say) was published twice whenever the maintenance
+  service started: once by the start's own tick and once more when the
+  service first compared the plugin files with the disk, or when that tick's
+  publication changed the pinned files. What that publication could not
+  change (a file as pinned, or one that holds what it held before the tick
+  under the same pin and vault root) is now taken as seen, and such a drift
+  is no longer a reason to publish a committed generation again, so asking
+  about it at most once more writes no vault file. A plugin file another
+  writer removes or changes after the publication, even during the same tick
+  (brought back to its old bytes after a publication that changed its pin,
+  say), unless it holds again what it held before the tick under the same
+  pin and vault root, and a path the person repairs before the tick ends,
+  are still written at the next tick.
+- `atelier obsidian open` with Obsidian quit and the view's vault already in
+  Obsidian's list but closed: Obsidian started plainly does not reopen such a
+  vault, so a link it refused just after starting left `open` to wait and
+  answer `launch-failed` / `app-did-not-answer-for-this-vault`. `open` now
+  hands the link once more to the Obsidian that now runs, through its
+  command-line tool only (never the operating system, since this `open`
+  started it), before it answers that. A vault the list flags open is not
+  asked twice.
+- `atelier obsidian --help` lists `plugin show | on` and `policy digest`, which
+  0.2.0-alpha.12 ships but left out of that help (the operations themselves
+  worked, and `atelier obsidian help` showed them). A test now fails when a
+  built-in obsidian operation is missing from it.
+- The project readiness artifact (`atelier-output/atelier-readiness.json` by
+  default) records `graph.path`, `projection.outputRoot` and
+  `projection.entry` relative to the project configuration directory, in POSIX
+  form, instead of as absolute paths. `atelier readiness --check` and
+  `atelier generated check` now accept an artifact written in another checkout
+  of the same project, and the artifact no longer names the machine's
+  directories (which could include the account name). An exact upgrade
+  candidate's readiness bytes now match what `atelier readiness` regenerates
+  there; before, when the path to the candidate passed through a symlink (as
+  macOS temporary directories do), the check reported the new candidate
+  stale. `atelier upgrade explain` no longer warns that readiness bytes can
+  contain absolute host paths. An artifact written by an earlier version is
+  reported stale once; run `atelier readiness` to rewrite it and review the
+  difference.
+- `atelier dev` run before `atelier build` (straight after `atelier init`,
+  for example) printed Node's raw `[ENOENT] ... lstat '<absolute path>'`
+  with no next step, and after `atelier graph` alone a redacted
+  `[internal-error]`. Both are now `projection-output-missing`, naming the
+  output folder relative to the project config (never as an absolute path)
+  and the next step: run `atelier graph`, then `atelier build`, with the same
+  `--project` path. `atelier dev --help` (and `server --help`) now documents
+  `--port=PORT`, the `PORT` variable, the 8137 default, and `--review`.
+- The CLI printed any error that carried a string code verbatim, so Node's own
+  errors (`ENOENT`, `EACCES`, `ERR_*`) reached the terminal with the absolute
+  path Node puts in their message, no next step, and exit 2. Only Atelier's
+  typed codes (lowercase words joined by hyphens) are now printed verbatim.
+  Any other error is `[internal-error]` with exit 1, naming only Node's code
+  and system call, for example `(ENOENT from lstat)`. `ATELIER_DEBUG=1` still
+  prints the full error.
+- Obsidian source apply could reject with an untyped `ELEAFCHANGED` error. This
+  happened when another program renamed a new file over the source while the
+  published note was being prepared again, between the look at the path and its
+  open. That is a source being written: the apply now refuses `stale-source`
+  (cause `changed-while-reading`) and writes nothing. A preparation that fails
+  for any tolerated reason is no longer kept for its scope and generation; only
+  one that succeeded is reused.
+- Obsidian source apply answers three more races with another program typed.
+  An enrolled source removed while apply builds the graph used to reject with
+  an untyped `ENOENT`; it now refuses `corpus-unreadable`, with the system code
+  as the cause, and writes nothing. When a publication replaced the pointer to
+  the current manifest during an apply, the read used to reject with an untyped
+  `ELEAFCHANGED`. The pointer is now read again, up to five times, and one that
+  keeps changing refuses `manifest-unavailable` (cause `changed-while-reading`).
+  A source replaced while the published note is prepared again now leads to a
+  fresh preparation, up to three in all. If the source was saved with the same
+  bytes, or another source of the scope was replaced, the edit applies instead
+  of refusing `published-note-unavailable`. Observation of pending edits on a
+  tick had the same gap: a source replaced while its note was prepared again
+  raised an untyped `ELEAFCHANGED` from the tick. It now refuses that edit
+  `stale-source` when its own source bytes changed, and otherwise refuses
+  `published-note-unavailable`. The failed preparation is no longer kept, so the
+  other edits of that generation in the tick are still observed.
+
+## 0.2.0-alpha.12
+
+### Added
+
+- Atelier's own Obsidian plugin (phase 1: presence and status). Every vault
+  the maintenance service publishes now carries it under
+  `.obsidian/plugins/atelier-projection/` with its entry in
+  `.obsidian/community-plugins.json`; the person never installs anything, and
+  Obsidian asks once per vault whether to trust the vault's plugins. Once
+  trusted, a status bar item says whether the view is current, updating, held
+  for an edit, stale or out of reach of the service, and "Atelier: show
+  status" says why. The plugin writes nothing, runs nothing it is sent and
+  reaches only the workspace's maintenance service on its literal loopback
+  address. Without it (restricted mode, an app older than 1.13.7, before the
+  prompt is answered, or turned off in the vault) everything works as before.
+  See `docs/obsidian-plugin.md`.
+- A person who turns Atelier's plugin off in a vault, or uninstalls it there,
+  is followed. Once the app has the plugin's entry in
+  `community-plugins.json` (it was in place before an app opened the vault,
+  or the plugin ran there), a list without it is recorded as the person's
+  decision (private state, `state/plugin/choices/`): the entry is not added
+  back, a deleted plugin folder is not made again, and the plugin files still
+  there are kept current. An entry published while an app held the vault is
+  only offered until then, since that app may write back the list it read
+  before, and a list without it is no decision of the person's. `status`, `open` and the new
+  `atelier obsidian plugin show` report `turned-off-in-this-vault`. Turning the
+  plugin on again in Obsidian's settings is followed the same way;
+  `atelier obsidian plugin on --scope ID` brings the entry and the files back
+  (the way back after an uninstall): at once, on a tick that names the view,
+  while the maintenance service runs (with `--adapter=obsidian-cli`, one of
+  an earlier release is replaced by the installed one first, as `open` does),
+  and otherwise at the view's next publication.
+- The maintenance service answers five plugin commands (`/plugin/challenge`,
+  `/plugin/hello`, `/plugin/lease`, `/plugin/release`, `/plugin/status`,
+  protocol `atelier-obsidian-plugin-channel/v2`) and grants presence and
+  read-only status of one view to a plugin that proves it holds that vault's
+  key. The key is random per vault, kept owner-only in private state and in
+  that vault's plugin data file, and never crosses the wire: the service
+  proves it holds the key over its own exact address before the plugin sends
+  anything that names the vault, and every later request and answer is sealed
+  with a key for that session and a counter that only goes up. A program that
+  takes the service's port while the service is down learns nothing it can
+  use: an answer the session's key does not seal ends the session in the
+  plugin, so such a program receives one command of a session at most; a
+  challenge is answered once and only within thirty seconds of the time it
+  names, and at most four handshakes wait per view. `status` reports which
+  views a plugin holds open, and so do `atelier obsidian status` and `open`.
+- While one launch of the plugin holds a view open and the command-line
+  tool gives no version (no vault open yet, or no answer in time), the app
+  version the plugin reports counts as checked (reason `plugin-reported`), in
+  the service's adapter factory and in `open`, unless the process table shows
+  no app running (a lease outlives a crashed app by a few seconds, and then
+  vouches for no version). A version the tool does give
+  decides, since the tool may reach another app holding the same vault, and
+  whether the app and its tool are installed is still the probe's answer.
+
+### Changed
+
+- Node.js 24 is supported alongside Node.js 22. The engines range is now
+  `>=22.18.0 <23 || >=24.13.1 <25`, so an install on Node 24 no longer warns.
+  Graph and projection files come out byte-identical on either major: CI runs
+  the complete suite on 24.13.1 and on the newest 24, and a new
+  `cross-node-bytes` job builds one workspace on 22 and on 24 and compares
+  every file written. The byte-determinism test names the supported majors
+  and checks them against `package.json`. The floor is 24.13.1, not the
+  first 24 LTS, because earlier 24 releases have an `fs.rmSync` defect
+  (nodejs/node#61020): removing a symbolic link to a directory throws
+  `EISDIR`, and a broken symbolic link is silently left in place. The
+  complete suite fails on 24.11.0 for that reason.
+- **Breaking:** Obsidian generation manifests of the new vault layout are
+  `atelier-obsidian-generation-manifest/v2`, a new contract major that records
+  `layoutVersion: 2` and each note's identity region, and a vault an earlier
+  release published is laid out again once (below). The v1 contract is
+  unchanged and still validates every generation an earlier release wrote; a
+  reader of generation manifests must accept both majors.
+- Obsidian views are laid out in vault layout 2, so a file name reads as the
+  note's title and the vault reads as the repositories. Folders mirror each
+  repository under a folder named after it, so a view's folders show the
+  repository identity and source directory chain of its notes, as its notes'
+  `atelier-repo` and `atelier-source` properties do; this is acceptable for
+  every vault, scoped ones included. A note's file name is its title (the
+  front-matter `title`, else its first H1, else the file stem as written),
+  with a trailing source extension dropped and made safe for macOS, Linux,
+  Windows and Obsidian links. Two notes of a view that would share a name in
+  one folder, compared case- and normalization-insensitively, are told apart
+  by the source file stem and then by a short stable id; a name that collides
+  with nothing carries no hash. A wrapped file keeps its own name beside its
+  note (`<file name>.md`), and an embedded file is copied to its mirrored
+  path. Links name their target by its full vault path. A repository folder
+  that would be `notes` or `attachments` spelled another way is told apart by
+  a short id, since an upgraded vault keeps those two folders of the earlier
+  layout.
+- Each view allocates its paths among its own notes, seeded from what its
+  prior generation published: a path does not change on retitle or when
+  other files come and go, a note that leaves the view releases its path
+  there (a renamed source takes its name back), a note of another view never
+  causes a qualifier, and a lost path registry costs no view its paths. One
+  identity may have different paths in different views. The registry keeps
+  each view's allocation in a section of its own, and drops the sections of
+  views the engine no longer maintains. `@mnstry/atelier/obsidian/materialize`
+  adds `allocateViewPaths`; `allocateWorkspacePaths` is deprecated: it still
+  allocates the earlier layout's paths for a whole workspace, exactly as
+  before, and Atelier no longer calls it.
+- A source that does not fit is laid out anyway and reported, never a reason
+  to refuse the workspace: a folder chain too long for the path budget keeps a
+  readable prefix and a short stable id, or, when not even that fits, the note
+  sits directly in its repository's folder; a source folder that meets a file
+  of the same name is qualified with an id. Only a name that does not fit even
+  in its repository's folder refuses the view. What is worth a look (these, an
+  author's own identity keys shadowing the generated ones, generated text that
+  names a note outside the view without refusing it) is recorded in the
+  manifest and the view's freshness entry, and shown by
+  `atelier obsidian status`, naming the note.
+- Every note names its identity in three generated front-matter properties,
+  `atelier-id`, `atelier-repo` and `atelier-source`, or, when its own front
+  matter could not take them unchanged in meaning, in a generated block at
+  its end. An edit to them is never applied to a source.
+- A vault published by an earlier release is laid out again once. Every
+  earlier path is retired through the publisher's remove units: moved to the
+  recovery area, or kept where it is when somebody edited it. The app's
+  bookmarks, open tabs and graph positions of the earlier paths are lost once.
+  A view that holds a note for an open edit keeps its earlier layout until the
+  edit is applied or withdrawn, and such an edit still applies; an edit that
+  closes on a tick (automatic mode applies on the tick it observes) keeps it
+  for that tick, so the file the person edited becomes the published note and
+  is retired like any other. See "Vault layout" in `docs/obsidian-contract.md`.
+- The redaction guard is re-based on the readable layout. Atelier never
+  generates a reference to a note outside a view: every path the emitter
+  writes must be one allocated to the view, and every identity block names
+  its own note. Generated prose repeats author text (the titles, summaries
+  and tags of in-view notes), which is carried as authored; the deny-list over
+  it, read as a reader sees it with the emitter's escapes removed and in NFC,
+  follows the audience, as defence in depth. For a note the audience may not
+  see it refuses an unambiguous identifier (an identity qualified by any
+  repository, a repository-qualified path, a repository-relative path with a
+  folder, a vault path) and reports a bare-word identity or a file name at a
+  repository's root (`README.md`); for a note the audience may see but the
+  view does not select it only reports. A view may newly refuse with
+  `redaction-failure`; the refusal names the rule and the in-view note, never
+  the value. Both rules run over every note, cached ones included. The deny
+  matcher is one automaton: building it takes time and memory linear in the
+  values it holds, on every preparation, and it reads each text once, however
+  many there are.
+- A focus query names each note by an anchored regular-expression path term
+  (`path:/^…$/`, query version `obsidian-graph-search-paths/v2`), so it matches
+  exactly the selected notes; a focus persisted with the earlier version is
+  still read.
+- `atelier obsidian open` makes the first open of a view automatic: Obsidian
+  no longer has to be quit, and no vault folder has to be opened by hand. It
+  makes the app know the view's vault as one of its vaults before it opens
+  it. With Obsidian running and
+  answering its command line, the vault is added through the app itself
+  (`vault-open` through `obsidian-cli eval`, a constant script with the folder
+  as a base64 JSON payload), verified in the app's own vault list by real
+  path, and opened; `open` waits until the app answers for exactly that vault
+  and then asks for the view again, so the first publication runs through the
+  app with every editor check. Quitting Obsidian is no longer needed. With
+  Obsidian not running, the view is published on the path with no app, and
+  the vault is added to the app's `obsidian.json` before the app is started
+  on it: only while the process table shows, positively, that no Obsidian
+  runs (read again immediately before the rename), only a file Obsidian
+  created, owned by this user and not a link, atomically (a temporary file in
+  the same directory, fsynced, renamed), keeping every other key and entry,
+  and with a timestamped backup beside it; a write that fails at any step
+  leaves the file as it was and nothing beside it; an Obsidian that never ran
+  on the account (no such file) is asked to be started once. With Obsidian running
+  and no vault open, a vault the app already lists is opened by path; one it
+  does not list is answered as `app-version-unsupported` / `no-vault-open`
+  (open any vault, or quit Obsidian, then open again) and nothing is
+  written. Every failure is typed and names its next step. See "What `open`
+  does in each state of Obsidian" in docs/obsidian.md and "Obsidian's vault
+  list" in docs/obsidian-contract.md.
+- A tick requested over the service's listener may name one view
+  (`POST /tick` with `scopeId`; `requestServiceTick({ scopeId })`), which the
+  engine then prepares and publishes once more, whatever its state
+  (`engine.requestPreparation(scopeId)`, a one-shot request consumed at the
+  next tick), with the app's qualification asked again. `open` names its view
+  on both ticks it requests. A view whose last publication did not settle is
+  also tried again without a request: as soon as the app looks different (it
+  quit or started, or opened or closed a vault in its list), and otherwise
+  after a delay that starts at 30 seconds (`DEFAULT_PUBLICATION_RETRY_MS`) and
+  doubles, up to the full reconciliation interval. Before, it waited for a
+  change or the five-minute reconciliation. What the app looks like is read
+  from the process table and its vault list alone (`appStateSignature({
+  processes, settings })`), so nothing runs in Obsidian to find out; the app
+  is asked for its version only when a view is about to be published, and
+  the service's adapter factory asks it without blocking
+  (`createQualifiedAdapterFactory` answers a promise for an app probe with
+  `inspect()`). `engine.requestPreparation` takes a request only for a view
+  the project declared at the last tick (at most 64 before the first), and
+  answers whether it did. The service listener answers a POST member it does
+  not know, or a view on a stop, with 400 `request-member-unknown` instead of
+  409, and checks a view against the scope contract's own identifier.
+- Command-line calls to the app reach only the vault they are about. A call
+  about a vault names it first (`vault=<id>`), so it reaches that vault's
+  window whichever window has focus; only when that id would name another
+  vault first does it run in the vault's folder, and not at all when a vault
+  the app lists before it at a folder above it (a home folder, say) would take
+  a call run there. The vault root, the settings entry, the vault check and
+  the publication bridge's check that the app holds this vault use the path as
+  the file system stores it, so on macOS a data root given in another letter
+  case neither hides a vault listed above it nor routes a call there, and a
+  store written before, or an app that holds the vault under another spelling
+  or through a link, keeps working: publication through the app, and `open`'s
+  check that the app answers for the vault. Publication calls do so only while the app's list
+  shows the view's vault open; every other call runs in a directory that is
+  no vault. Maintenance never reopens a vault window that was closed and never
+  reaches another vault, and the directory a command or service was started
+  in no longer picks, or opens, a vault. `open` never adds a view's vault
+  inside a folder Obsidian already lists as a vault, which would show the
+  view's notes too: it answers `launch-failed` / `vault-inside-another-vault`.
+  A listed folder is compared as written first; its real path is read only
+  when its last component is the vault root's, so a vault on a mount that
+  does not answer is never waited on. The maintenance service is started in
+  the root directory.
+- A view's vault that Obsidian has open in more than one window, one per
+  entry of its vault list that names the folder (under another letter case,
+  or through a link), is not published: a publication would coordinate with
+  one window only. The view reports `publisher-conflict` /
+  `vault-open-in-several-windows` (removing the extra entries from Obsidian's
+  vault list clears it; closing a window may not, since Obsidian keeps the last
+  window it closed marked open), and `open` answers the same, names the entries (`open in Obsidian
+  as: …`, `duplicates` in JSON) and launches nothing. While one entry of the
+  folder has a window, calls and `open` reach only that entry, so a closed
+  entry of the same folder is never opened beside it.
+- Obsidian's settings file is not written larger than 4 MiB
+  (`obsidian-settings-too-large`), nor through a second name (a hard link,
+  `obsidian-settings-unsafe`). Of Atelier's backups beside it, the first (the
+  list as it was before Atelier wrote it) and the latest are kept. A write
+  that cannot be read back is `registration-not-read-back`, no longer
+  `app-started-during-registration`. A Flatpak or snap build of Obsidian on
+  Linux, which never reads that file, is recognised (the build whose vault
+  list was written last; its installation only when no build wrote one), and
+  the file is neither read nor written for it (`obsidian-sandboxed`); the
+  vault is added through the running app. An addition the running app did not answer is looked up in
+  its list, and is `addition-not-answered` when it is not there, no longer
+  `app-did-not-list-its-vaults`. Adding a vault through the app also puts its
+  folder in the operating system's recent documents (Recent Items on macOS),
+  as Obsidian's own "open folder as vault" does.
+- A maintenance service still running an earlier release after an upgrade
+  is replaced by `open`. Every service records the release it runs, the
+  package version and a digest of every runtime module it ships (`src/`,
+  `contracts/`), in its record's `executable.ext.release`
+  (`releaseIdentity()`). A service of the workspace that proves itself ours
+  but runs an earlier version than the installed one, the same version with
+  another entry module or other modules, records no release, or refuses a
+  tick that names a view (as 0.2.0-alpha.11 and earlier do), is stopped
+  through its own listener and the installed release is started under the
+  consent already recorded; `open` shows `service: restarted (outdated)`
+  (`service.restarted` in JSON). A service of a later version (versions
+  ordered as semantic versions, 0.2.0-alpha.11 < 0.2.0-alpha.12 < 0.2.0), or
+  of one that cannot be ordered, is never replaced by an earlier release, so
+  two installations used on one workspace do not replace each other's service
+  on every open: `open` answers `service-unavailable` /
+  `service-other-release`, whose next step is `atelier obsidian service stop`,
+  then open again. The same version string on both sides is compared by
+  content even when it cannot be ordered (a fork's `dev`), so that next step
+  cannot loop. A tick refused because a concurrent command replaced the
+  runtime just before is asked of the runtime that took its place, and
+  nothing is restarted. A busy service is not stopped, and nothing that does
+  not prove itself ours is touched. `requestServiceTick` takes the start
+  options of the installed entry as `service` for this (`runtimeRelease`,
+  `releaseStanding`).
+- The `status` next step for `publisher-conflict` / `editor-uncoordinated`
+  names `atelier obsidian open` (which adds the vault to Obsidian and
+  publishes through it) or quitting Obsidian; after `open` itself tried, it
+  names quitting Obsidian. `launch-failed` no longer asks for a vault folder
+  to be opened by hand.
+- The settings unit owns two more things in a vault: the `atelier-projection`
+  entry of `community-plugins.json` (appended while the person wants the
+  plugin there; every other entry kept in order; written only over the exact
+  bytes the decision was made on, so a change the person makes meanwhile
+  stops that unit as `settings-changed` and the view is tried again) and the
+  plugin's four files, whose digests are pinned in the generation manifest
+  under `ext["mnstry.atelier.obsidian"].settings`.
+  Whatever occupies a plugin path is displaced to recovery, never lost; a
+  plugin path a person has to repair (a link, a folder where a file goes, a
+  file nobody may read, a folder nobody may write) never holds a view back; a
+  generation whose plugin files the person repaired, changed or removed is
+  published again as it is at the maintenance service's next tick; and
+  another writer racing a plugin file makes the view try again.
+  `isUserOwnedSettingsPath` answers `false` for these paths.
+- Vault roots that Atelier places under its data root are created private
+  (`0700`), and an existing one is made private before the plugin's key is
+  written into it. A vault root Atelier did not place never receives the key
+  unless it is already private, and a vault path under the data root that is
+  a link to another folder never receives it, and its mode is never changed.
+- A settings file nobody may read (`core-plugins.json`, say) is reported as
+  `path-unsafe` and left for the person instead of failing the publication.
+- `plugins/` is part of the egress scan, and the release audit requires the
+  plugin's three files in the package.
+
+### Fixed
+
+- A publication no longer stops with an untyped `state leaf changed while
+  opening` when another program replaces a note by rename at the instant the
+  publisher opens it (an editor or sync tool saving the note). The note is
+  read again, since every rename leaves a complete file; a note that keeps
+  being replaced is reported as `disk-changed` for that note only, and the
+  other notes are published. No bytes were ever lost: the publication threw
+  before writing.
+- `open` no longer makes Obsidian forget which of your vaults to reopen. A
+  quit Obsidian started with an `obsidian://` link opens only that vault and
+  drops the reopen flag of every other one; `open` now starts it plainly on
+  macOS (it reopens every vault it had open, and the view's vault, which `open`
+  added flagged to reopen) and hands it the vault's link through its command
+  line once the app itself answers there, never through the operating system.
+  On Linux a quit Obsidian is still started with the link (a known limit).
+- `open` names the vault by its id (`obsidian://open?vault=<id>`) where the id
+  reaches it first, instead of its path, which Obsidian matches against its
+  vault list by string prefix.
+- Obsidian with its command line turned off (the default of a new
+  installation) answers every command with "Command line interface is not
+  enabled"; that answer was read as an unreadable version. It is now
+  `app-cli-unavailable` / `cli-turned-off`, whose next step names the setting
+  (Settings > General > Advanced > Command line interface).
+- A view whose prepared generation was already the committed one (on the
+  first tick of a service, or prepared again on request) was marked `stale`
+  when the app could not be qualified, for example while it ran with no vault
+  open: the editor adapter was built before the publisher found nothing to
+  publish. That adapter is now built only when the publisher needs one.
+- After a refused publication, the tick `open` asked for did not try the view
+  again (the engine attempted only views with changes), so `open` reported the
+  old conflict until the five-minute reconciliation.
+- `open` launched `obsidian://open?path=` for a vault the app did not know,
+  and Obsidian showed "Vault not found. Unable to find a vault for the URL";
+  `open` then answered `launch-failed` / `app-did-not-answer-for-this-vault`.
+- The production check that the app answers for a vault parsed the app's
+  answer twice and so never saw an answer; it now reads it once (twice only
+  for a quoted string), compares real paths, and asks from inside the vault
+  folder.
+- An app whose vault window is still loading answers a command with `Error:
+  Command "version" not found`; that was read as an unreadable version and
+  ended `open` as `app-version-unsupported`. It is now read as not up yet.
+- `atelier dev` on a port that was already taken (8137 by default) printed
+  only `[internal-error] command failed without a safe diagnostic`, and the
+  message that says what to do appeared only with `ATELIER_DEBUG=1`. It is now
+  `port-in-use`, naming the port, with `--port=<free port>` as the next step.
+  A port the operating system refuses (EACCES, usually one below 1024) is
+  `port-permission-denied` with the same remedy, and a `--port` or `PORT`
+  value that is not a port from 0 to 65535 is `port-invalid`, naming which
+  one, instead of Node's `ERR_SOCKET_BAD_PORT`. Other failures without a
+  typed code are still redacted.
+
 ## 0.2.0-alpha.11
 
 ### Fixed