@mnstry/atelier 0.2.0-alpha.12 → 0.2.0-alpha.14

package/CHANGELOG.md

@@ -1,5 +1,899 @@
 # Changelog
 
+## 0.2.0-alpha.14
+
+- The Obsidian maintenance service's log no longer gets a `status-project-loaded` line for every failure and recovery, or every slow load, of the plugin's status read while its loads come less than a minute apart and fail, or are slow, every other load or every third. Before, any load that answered ended a row of failures, and any load in time a row of slow loads. Now a row of failures ends only at a load that answers a minute or more after its last failure, with a line that names how many failures it held, and a row of slow loads only at a load in time a minute or more after the last slow one. Such a loader writes one row, less and less often. While a project is kept, it is loaded again every two and a half minutes, so there a row of failures ends at the next reload that answers. A loader that answers at least one reload between two failures still writes each failure and the load that ends its row, and one that fails at every reload and answers only at its retry keeps one row. Each slow load is still written there. A load at every request is now written too, when each load names the files it started over. That happens while a file that decides the views vouches for nothing, or while loads never agree, and before it showed only as a growing count. A load after which nothing is kept, though it named the files it started over, is written from the second in a row, on the same doubling row (`notKept`, with `vouched`); a load that named other files, as after a new confirmed selection, neither counts nor ends that row. `statusLoads` in the status document counts these loads as `notKept`, one at a start and one after each change on a healthy service.
+- An Obsidian maintenance service started by a login item asks its project loader once (under `--personal-home`, its locator), and now hands its first answer on faithfully. A thenable that is no promise is adopted once as a native promise that settles as it does, so its `then` is called once in all. Before, it was called twice: once where the process let the answer go, and again at the service's own start. A promise whose `constructor` reads as this realm's `Promise` is let go without calling a `then` of its own, which may throw; any other, as a rule another realm's promise or a subclass's, is adopted as any other thenable is. A service started any other way that is handed a promise with a `then` of its own that throws now refuses it typed as well. Before, that start ended untyped. Anything thrown, `undefined` included, and a project whose `then` cannot be read, ends the start as a failure of the loader does. Before, `undefined` was taken as an answer of nothing: the start went on to resolve a workspace from it, and for a locator it was refused as `service-locator-invalid`. An unreadable `then` ended the process with an error the service never logged. The service also logs what was thrown when it has no prototype, or a `code` or `message` that cannot be read, where before that logging itself threw. A start ended by an error without a code is still a crash that the service manager restarts.
+- A view the Obsidian maintenance service refuses for a file-system error is now named in its private log. The view's freshness names only the refusal's code, and such a tick is no failure, so nothing recorded the error before. Examples are `vault-location-unusable` for a vault folder that could not be allocated or placed, `mixed-read` for a configuration file that could not be read again during the tick or a source removed while it was read, and `staging-failed` for candidates that could not be staged. The service now writes a `view-refused` line for each such view whose refusal carries a file-system error's code, at most 64 a tick. The line names the view, the refusal's code and the error's code (`EACCES`, `EIO`, `ENOENT`, `ENOSPC`), and `cleanupCause` when a cleanup after it failed too. Only codes shaped as a file-system error's are written, never a message. A view the next tick names for the same reason is not written again, so a vault folder that stays unwritable, tried at every tick, is written once. The engine's tick report carries the same entries as `refusalCauses`, only when there are any.
+- A failure while the publisher cleans up the candidates of a staging that did not complete no longer replaces what ended the staging. Before, a removal or a read that failed (`EBUSY`, `EPERM`, `EIO`, a volume gone) was thrown in place of the refusal or stop, and the tick failed without a typed reason. Now each candidate is cleaned up on its own, so one that cannot be removed leaves the others removed. What ended the staging is handed on unchanged: a caller's stop, a refusal such as `vault-root-moved`, or `staging-failed`. The code of the first such failure is added to a copy of its detail as `cleanupCause`. A candidate that could not be removed stays where it was, as before. That is in staging, or at its exchange path once the publication's journal is written, where the restart recovery of the next publication removes it.
+- A selected source removed while the Obsidian maintenance service prepares or publishes a view, after the tick observed it and before the preparation, or the look again at the sources before the commit, read it, now refuses that view as `mixed-read`, as a source removed during the graph build does: no generation is committed for the view, the tick goes on to its other views, and the next tick reads everything again and publishes without the source. A generation already committed and prepared again is not reported current. Before, the tick failed without a typed reason: the view read `publisher-error`, the views after it were not prepared in that tick, and the service read degraded and recorded the error until the next tick. The rule is the build's: only a source the tick observed and that is gone when it is read (or its folder) is refused this way, and a file that cannot be read for another reason, or a path still there, still stops the tick. The engine primitive that decides it is now named `sourceRemovedSinceObserved`.
+- A running Obsidian maintenance service whose loaded project is pinned to a selection record below the highest record any part of the service has read the selection history ending at loads the project again at its next tick, with no read of its own to trigger it. A confirmation read by another part of the service (the plugin's status read) and removed before the engine looked therefore refuses `selection-history-shortened` at that tick. Before, the engine went on publishing under its record until its next recheck, at the latest the next full reconciliation. Views that a change stops one after another have the history's end read once, not once a view, and it is read also when a file that decides the views could not be read.
+- A source removed while the Obsidian maintenance service builds the canonical graph, after the build listed it and before it read it, now refuses the views of that tick as `mixed-read`, as a source changed during the build is: nothing is prepared from the build, and the next tick reads everything again and publishes without it. Before, the tick failed without a typed reason, and the service read degraded and recorded the error until the next tick. Only a source this tick observed, gone when the build reads it (or its folder), is refused this way. Anything else still stops the tick: a file that cannot be read for another reason, a path still there, one the walk over the sources listed and could not read, or one it never observed, so a path that can never be read fails every tick as before.
+- AP-03 cleanup joins owned child handles even when the runtime status record is missing or malformed, and retains disposable roots when cleanup cannot be proven.
+- The Obsidian maintenance service goes on answering health and status while a tick observes and routes pending edits. Observation gives the event loop a turn between two edits, and proposal routing gives it one before each repository and between two operations. Each edit and each operation is still handled in one stretch, and what is observed, recorded and proposed is unchanged. Before, a tick with a burst of edits held the listener for the whole observation. An observation asked for while another is under way now waits for it.
+- The event-loop benchmark (`scripts/obsidian/benchmark-event-loop.mjs`) waits for the health request in flight at the end of the first tick, and of a transition, before it judges the window. A stretch at the end that holds the listener is then measured by that request's latency, under the same five-second rule as any other, instead of being read as a gap in the sampling; the 250 ms edge rule is about whether the sampling reached the edge, as it already was at the start of a tick. A request in flight at the end that is never answered now fails the run, where before it was left out. The rules a request is judged by are unchanged. The result's `health` and `transitionHealth` say whether such a request was waited for (`awaitedProbeInFlightAtEnd`; `false` also when it was answered at once). `--timeout-ms` may now be up to four hours, so a first publication of ten thousand notes in six views can be run; the window is judged without a limit on how many requests it holds.
+- A running Obsidian maintenance service no longer follows a selection history back when it is cut short. It notes the highest record number at every read of the history's end, and a history that ends earlier refuses `selection-history-shortened`: nothing is loaded from it, a project already loaded is refused at its next recheck, the views say why and the vault keeps what it last published, until the removed records are back or the history is as long again. Before, the service loaded whatever record the history then ended with, so a history cut after a restore nobody confirmed published that restore. The number is kept in the process only: a service started after the cut, by the person or at login, after an upgrade or a failure, reads the history as it then stands and follows what it ends with, as each command run once does. Keeping it across a start is not part of this change.
+- The Obsidian maintenance service goes on answering health and status while a published view is read back. The read-back after a commit gives the event loop a turn between notes, as preparation and publication do. It ran through before: for one view of 10,000 notes it held the listener for 1.9 s on a quiet host and 16.8 s on a loaded one, long enough for three health requests in a row to time out. Each note of the committed generation is still read once, and a view is reported current only after its read-back. `reconcileCooperatively` beside `reconcile` in `src/runtime/obsidian/observation.mjs` is the walk that waits.
+- The event-loop benchmark (`scripts/obsidian/benchmark-event-loop.mjs`) has two more scenarios, which ask the service for one more tick after the first publication, with nothing changed, and judge that tick: by what it did, by how long it held the event loop, and by the health requests across it. `--scenario=next-tick` keeps the watcher a service runs with, so that tick is told of the notes the publication wrote, as the tick after a publication is; when the publication took five minutes or more it is also a full reconciliation, as it is in a service. `--scenario=full-reconciliation` makes it a full reconciliation whatever the publication took. The result records the tick, whether it was full, its longest event-loop delay, and what the watcher had reported before it. Until now no stage ran a tick that a watcher had told of anything, and the one full reconciliation a stage ran (in `observe-16`) was over the small corpus that stage is run with.
+- The Obsidian maintenance service goes on answering health and status while a tick looks at the vault and at the sources. Before a view is prepared, the walk over every view's notes and the walk over the sources give the event loop a turn between files, as the read-back does. They ran through before: on one view of 10,000 notes the tick after a publication (told by the watcher of every note it wrote, and a full reconciliation as well after a long publication) held the listener for 5.5 s on a loaded host, and a health request timed out; at every full reconciliation, every five minutes, each walk reads every file. The pending edits are still read, compared and written in one stretch, after the walk over the vault. A file changed after its turn in a walk is seen by the next tick, by its stat hint or the watcher, or at the latest by the next full reconciliation. The tick reports two more phases to a caller that asks for them, `vault-observation` and `late-writer-recheck`. In the event-loop benchmark, a second-tick stage's ending is one tested function, and its delay test samples the stretch it means to leave out.
+- A note removed from a vault is no longer lost when the tick that saw it fails without a typed reason (a source or a note it cannot read, a full disk while an edit is kept). The removal is a change once, and such a tick had recorded it without acting on it, so the view stayed `current` with the note gone, through every later full reconciliation. The tick after a failure without a typed reason now starts as the first tick of a process does: it loads the project again and looks at every view, and the view reads `vault-note-missing`. A source changed in such a tick, or a view added to the configuration in a tick whose project loader failed, is published by the next one for the same reason. The phase `late-writer-recheck` is reported when the look again at displaced files fails too.
+- An Obsidian maintenance service whose engine lock could not be given back at the end of a tick (its released ticket could not be written: a full disk, an I/O error) goes on maintaining once the write succeeds. Before, every later tick found the service's own unreleased ticket and answered `busy`, which the service counts as a success: health read healthy, the views stayed `current`, and nothing was maintained until the service was started again. The tick whose release failed still fails; the lock stays held, and the next tick gives it back before it takes it again. A release of a private generation lock that throws now settles nothing, so calling it again tries again.
+- A private generation lock whose acquisition fails after its ticket was put in place (the directory sync or the read-back of the ticket, or the listing that confirms it) removes that ticket again, while it still holds its own bytes, before the failure is reported; a removal that fails too is made at that process's next acquisition in the same directory. Before, the ticket stayed on disk unreleased and nobody held it to release it: every later acquisition by the same process found it held by that process, so an Obsidian maintenance service answered `busy` at every tick until it was started again, with health reading healthy. The engine lock, the start lock of `service start` and the proposal adapter's lock all take this path.
+- The Obsidian maintenance service goes on answering health and status while a tick builds the canonical graph. The census (each Markdown source read, hashed and parsed, or reused from the graph file cache) gives the event loop a turn between sources; a first tick reads every source, and on a heavily loaded host the build for one view of 10,000 invented notes held the listener for 8 s in one stretch. The settings that select the views are checked at each wait, as during a preparation. `buildKnowledgeGraphSteps` and `buildCanonicalGraphSteps` are the builds as steps; `buildKnowledgeGraph` and `buildCanonicalGraph` run them through, unchanged for their callers. A project bound to a personal workspace is built by its own route in one stretch, as before, and the other sources (HTML files, the sidecars of PDF and Word documents) are read without a turn between them. Walking the directories, resolving links and assembling the graph still run through. `createProductionSeams()` has one more member, `buildGraphCooperatively`, which the engine uses for every project not bound to a personal workspace; a caller that replaces `buildGraph` and leaves `buildGraphCooperatively` as it ships builds every graph through its own `buildGraph`, as a replaced `prepareView` already prepares every view. Knowledge Health pins the bytes of the two graph files, so its rule identity is regenerated for them: the `check` each assessment carries names a new `version`, `sourceTree` and `graphBlob`, and the rule it applies is unchanged.
+- Pages that still called shipped commands unreleased now say they shipped in 0.2.0-alpha.13: `atelier knowledge semantic`, `atelier ingest` (with the `./ingestion` export), `atelier inquiry`, `atelier harness` and `atelier capability`. Each was checked against the published 0.2.0-alpha.12 and 0.2.0-alpha.13 packages.
+- A staged or pushed deletion of a tracked binary file no longer blocks the boundary check. A deleted path has nothing to read at the revision being scanned, yet the check tried to read it and reported `content-scan-incomplete` ("binary content could not be read within the 8388608-byte per-file limit"), which refused the commit or the push. A binary added or changed in the same change is still read and scanned, and only the extended header of the diff can say a path was deleted, so a content line cannot skip a file. A binary rename that git shows as a deletion and an addition is unblocked the same way.
+- The optional Graphify supplier loads again. `graphify_supplier.py` reads `native-pins.json` and `native-closure-pins.json` beside it when it is imported, and neither file was in the package, so importing it (and the JSON bridge, query and composition receivers that import it) failed with a missing file in 0.2.0-alpha.13. Both pin files ship now, admitted by the release tarball audit, pinning Graphify 0.9.72 at upstream commit `1cd9a36c`: 30 operations and 67 closure modules. Of the 30, `extract-semantic` is pinned but cannot run, because its `graphify.llm` module is outside the admitted closure, so 29 are usable. `extract-structure` now refuses `parallel: true` with `NATIVE_WORKERS_UNATTESTED`: parallel extraction starts worker processes that import Graphify outside the pinned source loader, so only in-process extraction is admitted.
+- `atelier upgrade closure` says what to do in two more cases and refuses one more flag. A refused linked `--npm-root` prints the directory's `realPath`, and the docs say why macOS `/tmp` and `$TMPDIR` are refused until it is given. A tarball URL with no readable host no longer suggests `--registry-host`, which cannot clear it. The `prefix-mismatch` message no longer claims npm would use another root, since the plan refuses any parent that declares workspaces. `--__proto__`, which the shared argument parser dropped, is refused as an unsupported flag. The upgrade guide now matches the code on an empty `--npm-root=` (`npm-root-required`), on `http` and `https` (counted separately in `registrySchemes`) and on when Atelier's own `package.json` is read.
+- The practice-consumer reconsideration tool (`scripts/practice-consumer/reconsider.mjs measure`) can keep the full context of one measurement with `--capture NEWFILE`: the records and definition the evaluator was given, each evaluation's input and outcome as received, the citations that were not evaluated and why, and the decisions with no citation. It is written once, to a file that must not exist yet and must not be the measurements file under another name (checked by real path before measuring and by the file itself after writing), only when the measurement line can be appended, and before that line, so a refused capture appends nothing and the run removes the capture it wrote; only a run interrupted between writing the capture and appending its line can leave one standing. Without `--capture` nothing changes.
+- The boundary content scan reads every changed file under its own name. Its diffs now pin their format (`--no-ext-diff --no-textconv --no-color --src-prefix=a/ --dst-prefix=b/ --no-relative --inter-hunk-context=0 --submodule=short --full-index`), so `diff.noprefix`, `diff.mnemonicPrefix`, changed prefixes, forced colour, an external diff or a textconv driver no longer leave a staged or pushed change unscanned, and fused hunks or submodule summaries do not stop clean work. Quoted paths (non-ASCII, quotes, tabs) and paths containing ` b/` are read correctly instead of being skipped or read as another file; a name holding a backslash is reported as it is, never inherits a sibling path's exception, and is in scope of every path-scoped rule. Changed binaries are read by object id, so a name shaped like an index stage (`0:name`) is read as itself. Added lines are taken from each hunk by its own line counts, so an added line that itself begins with `+`, such as a Markdown bullet, is scanned. Text that the repository's attributes declare binary (UTF-8 without a NUL byte in its first 8 KiB) was not scanned at all; it is now judged by its added lines like any other text, with renames and copies paired as in the main diff, and other content declared binary is scanned as a binary, as before. A changed file the scan cannot read from the diff is reported as `content-scan-incomplete` and blocks, where before it was skipped; a Git setting not pinned here can therefore stop a commit but cannot hide content.
+- The boundary pre-commit check judges what is being committed. `git commit -a` and `git commit <paths>` hand the hook a temporary index, and a commit from a linked worktree its own index; the check dropped it with the rest of the Git environment, read the configured checkout's index and saw nothing staged. It now reads the index and work tree Git names, for the managed repository being committed, found by Git even from a hook chained into a subdirectory, and blocks when no single declared repository is being committed (`pre-commit-repo-unresolved`), as the push check does. Staged paths are listed NUL-separated, so a quoted name (non-ASCII, quotes) is matched against forbidden-path patterns, and a repository whose staged paths cannot be listed blocks. The semantic-field review reads the staged diff with the same pinned format and parser as the content scan, reads a document Git would call binary as text, blocks on a diff it cannot read, and takes only an added review marker as approval: a removed marker, or one in a file name, approves nothing; `atelier upgrade` applies the same marker rule. A forbidden-path pattern's `**` now also matches across a newline in a name.
+- In the boundary content scan, a file that takes the name of a directory, or moves into a directory of its own name, in text that Git reports as binary, is judged as the main diff pairs it instead of blocking the commit. When such text is still unreadable the message says Git reports it as binary, which also covers text replacing binary content.
+- The boundary push check judges the commits a push carries that the remote's tracking refs do not hold, each against its parent, binaries included, so a key added in one commit and removed in the next is no longer published unscanned; such a finding names its commit, and a key that reaches the pushed tip is reported once, listing the commits that carry it. A merge is judged only for what is new against all its parents, so a pull merge into the branch you push is not refused for what the remote already holds. The pre-push hook now passes the remote Git names (a configured remote, or a URL matched to one); reinstall hooks (`atelier boundary install-hooks`) so history held only by another remote is judged on its way to a new one. A push carrying more than 1000 such commits or more than the evidence budget is refused with `content-scan-incomplete`; push it in smaller parts. The content scan's diffs omit a deleted file's removed lines, which it never judges (the semantic-field review still reads them), so deleting a large file no longer exhausts the output limit. A new branch in a SHA-256 repository is diffed against that format's empty tree instead of failing.
+
+- `atelier upgrade closure --npm-root ABSOLUTE_NPM_ROOT` plans a check of a staged
+  candidate's own dependency closure, and `planConsumerClosure` is exported from
+  `@mnstry/atelier/upgrade`. The plan reads the candidate's `package.json` and
+  `package-lock.json`, the installed manifest of every lockfile copy of the
+  selected package, `package.json` in each directory above the npm root (to
+  refuse a parent that declares workspaces) and, for the default package name,
+  Atelier's own `package.json`. It runs no npm command, uses no network, reads
+  no npm configuration and writes nothing. It reports the lockfile's sources,
+  registry hosts and schemes, and platform exclusions. It checks the selected
+  package's exact `overrides` against every installed copy, only after binding
+  each installed manifest to the name and version of its lockfile entry, and
+  lists selector, nested and non-exact overrides, and overrides for packages a
+  link provides, as unchecked. The npm root must be the directory's real path.
+  Refusals reuse `usage`, `consumer-closure-incomplete` and
+  `override-not-inherited`, each with one bounded reason. Every run prints one
+  JSON document, including a run whose arguments are refused. A completed plan
+  exits 3 with `"proof": "not-run"` and a refusal exits 2; the command never
+  exits 0 and does not prove an offline reinstall. The consumer-closure
+  classifiers moved to `src/upgrade/closure-diagnostics.mjs`, and
+  `scripts/consumer-closure-diagnostics.mjs` re-exports them. Two of them
+  changed: a project folder entry in a lockfile is never counted as an
+  installed copy, and a lockfile entry that is not an object is reported as
+  missing by `capturedClosure` instead of raising a `TypeError`.
+
+- Add a tenant-neutral HTML control system at `@mnstry/atelier/ui`. The shared
+  geometry, variants, focus treatment, motion, action-group layouts, and safe
+  renderers are used by Atelier's generated project UI and are available to
+  downstream publication kits without importing publication semantics into
+  Atelier.
+- The Obsidian service test suites reserve the loopback ports they choose, so
+  another test cannot take a port between its selection and its use.
+- The Obsidian plugin (1.1.2) keeps the last authenticated status in view
+  through a transport interruption. After a connection refusal or timeout on
+  the same channel, the status window shows the last observed state, reason,
+  generation and check under "Last observed" labels. Those rows are historical
+  and never establish current freshness, service health or permission. The
+  history stays in memory and is cleared on a channel change, an
+  authentication refusal, an untrusted or malformed answer, a report for
+  another scope, or unload. A republish that names a different channel resets
+  the display to `connecting` without repeating an unchanged notice, and the
+  plugin opens no channel before startup admits it or after unload.
+- The Obsidian maintenance service tells a plugin a view's stored freshness
+  and pending-edit count only while the project allows that view at the moment
+  of the request: its Obsidian settings are enabled and declare the view, and
+  its workspace pointer still names the workspace the service runs for.
+  Before, a view that was turned off or taken out of the settings was still
+  told what the service had stored, until the next tick and, for its
+  generations and counts, after it. The answer is now sealed as before with
+  `view` and `pendingEdits` null, so the plugin shows `Atelier: stale`, keeps
+  its session and asks again; anything that cannot be established (settings
+  that refuse, a project that does not load) is answered the same way. The
+  project is loaded again only when a file that decides it changed, compared
+  by content at every request. A loader that answers a promise is never
+  waited for: its view is told nothing until the load has answered.
+- The real-app acceptance run of the small-fixture desktop procedure
+  (`scripts/obsidian/desktop-receipts.mjs`, maintainer tooling that is not
+  shipped) ends the processes it started, removes the temporary directories it
+  created, and bounds the receipt and console output it keeps. It signals only
+  a process it spawned or a recorded child of one, and removes a directory only
+  while the path still names the one it created; otherwise it keeps the
+  directories and names them.
+- A project configuration file that is a link (one kept in a dotfiles
+  repository, say) no longer makes the Obsidian maintenance service load the
+  project, and run Git, at every status request a plugin makes. The service
+  compares what the loader reads through the link: the file it leads to and
+  that file's bytes, so a link pointed elsewhere is a change. A folder in a
+  file's place, or a link that leads nowhere or to a folder, still vouches for
+  nothing. The project the service keeps for those requests is taken only from
+  two loads in a row that agree over the same bytes, is loaded again every two
+  and a half minutes and never used past five. A loader that answers a promise
+  is given up after two and a half minutes, and a load that fails is asked for
+  again after two seconds, then four, up to thirty, unless a file changed.
+- The Obsidian maintenance service refuses to start on a project loader that
+  answers a promise (or any other thenable), with
+  `service-loader-not-synchronous`, before it reads anything from it, listens
+  or records anything. Before, it handed the promise to its workspace
+  resolution, which then read the workspace pointer of the working directory
+  and protected no repository. For the status read of a plugin: a load whose
+  answer comes after its deadline is given up even when no request saw the
+  deadline pass; a link is resolved as the system resolves it, a `..` after a
+  link included, and a link to a folder above a configuration file pointed
+  elsewhere is a change; two loads agree when what the decision reads of the
+  project is the same, so a field that differs between loads (a time, a
+  binding under a symbol key) no longer stops a project from being kept; and
+  a load that fails, is given up or holds the event loop is logged with how
+  long it took.
+- The Obsidian maintenance service stays responsive while it prepares and
+  publishes a view. The engine prepares each view cooperatively and the
+  publisher yields between complete units, so the loopback listener answers
+  health and status while notes are emitted, staged and published, instead of
+  being `busy` for the length of a large first publication. `open` and
+  `service stop` therefore reach a service in the middle of a publication:
+  `open` waits for a tick that starts after the one in flight, and `service
+  stop` ends the service after the tick in flight or its shutdown grace,
+  leaving a publication cut short to the publisher's restart recovery.
+  Walking the directories, resolving links and assembling the canonical
+  graph, capturing the source snapshot, the
+  publisher's restart recovery, validating a prepared view and planning its
+  units, the exchange probe, writing and syncing the journal before the
+  candidates move and the look again at displaced files after the units
+  still run without yielding. So did reading the sources into the canonical
+  graph, observing the source and vault files and the read-back after a
+  commit, until later changes made them wait between files (for the graph,
+  between Markdown sources, outside a personal workspace).
+  `prepareView` stays synchronous
+  and returns the same bytes. Across each wait of preparation and publication
+  the configuration files, the machine settings and the eligibility revision
+  are checked again, and after
+  a view is prepared and before its generation commits every selected source
+  is checked as observation checks it: by its stat hint, and by digest where
+  the hint moved. A change during the tick refuses the generation as
+  `mixed-read`; neither that tick nor a later restart recovery commits it,
+  and the next tick prepares the view again. A source that drifts under an
+  unchanged stat hint is still seen by the next full reconciliation, and a
+  note reused from the preparation cache is still not read. A cancelled
+  preparation leaves the preparation cache as it was, and publication keeps
+  its locks, journal and conditional writes.
+- Started by a login item, the Obsidian maintenance service asks its project
+  loader once, and a loader that answers a promise there is refused and
+  recorded as at any other start, ending with 0. Before, the promise reached
+  the workspace resolution, and a refused one ended the process with an error
+  that the service manager answered by starting it again. The loads behind a
+  plugin's status requests are counted in the service's status document
+  (`statusLoads`), and the service log gets a `status-project-loaded` line
+  only for a load that failed or was given up (the first in a row, then when
+  the row is 2, 4, 8 and so on long), the first that answered after a failure,
+  and one that held the event loop for a second or more. A regular
+  configuration file the system resolves no path for (some Windows volumes)
+  is compared by its own path and bytes, instead of the project being loaded
+  at every request.
+- A publication of the Obsidian maintenance service that is stopped or refused
+  on the way is recorded and cleaned up as what it was. A caller's stop after
+  the journal was opened (a setting that changed during the tick,
+  `mixed-read`, or a cancellation) is recorded in the journal's last entry
+  under that stop's own code instead of `publisher-error`; restart recovery
+  reads such a journal as before. A configuration file that cannot be read
+  again at a wait (no permission, an I/O error, no descriptor left) refuses
+  that view as `mixed-read` and has the next tick read everything again;
+  before, the raw error ended the tick, and the views after that one were not
+  prepared. A refusal raised while candidates are being staged (the vault's
+  folder replaced or gone) is still reported under its own code, now after
+  the candidates it staged are removed; before, those staged ahead of the
+  journal stayed in private staging, where restart recovery never looks. And
+  the service reads an explicit `prepareViewCooperatively: null` among its
+  engine seams as the engine does: there is no cooperative preparation, so a
+  replaced `prepareView` prepares the view.
+- The desktop acceptance procedures (`scripts/obsidian/desktop-receipts.mjs`,
+  maintainer tooling that is not shipped) no longer signal the isolated app
+  by its process number outside the small-fixture run: quitting signals it
+  through the handle spawn returned and waits on that handle, a launch that
+  gives up signals the app's process group only while that handle still
+  holds the app, and a launch under the user's own HOME is refused before the
+  stale command-line socket there is removed. In the small-fixture run, a
+  process first recorded from a process table passes lineage on only from the
+  next read; a process the table shows, unrecorded, under a parent that
+  exited or changed during the read is remembered until it is seen gone, and
+  the directories are kept while it is there; and the app log copy's credit
+  is charged back when a directory is kept after all, with the excess over
+  the output bound's allowance reported.
+- `atelier obsidian`, the Obsidian maintenance service and its login item take
+  `--personal-home DIR` instead of `--project`, and then follow the generation
+  last confirmed in that private home of a personal workspace. The head of the
+  selection history is read, that generation is loaded (composed in a worker
+  for the service), and the head is read again; a head that moved refuses
+  `personal-selection-changed`. Nothing confirmed publishes nothing, each with
+  its own code (`nothing-selected`, `stale-generation`,
+  `selection-history-corrupt`, `personal-home-unavailable`, or the module's own
+  code for a home that is gone), and nothing falls back to another project.
+  The service locates its workspace from the home alone through a new
+  `locateProject` option, so it starts whatever the selection; a service given
+  only a loader that answers a promise is still refused at start. The engine
+  observes the selection's record and the next one, so a confirmation or a
+  history cut short is loaded at the next tick, and reads the history again at
+  every full reconciliation. `status` reports the confirmed generation, and
+  nothing here confirms one. Who may see a bound vault is not decided: it stays
+  the machine's audience setting, none by default. `readPersonalSelectionHead`
+  is added to `@mnstry/atelier/personal-workspace`, and the selection history is
+  read without waiting on a record that is not a regular file. Without
+  `--personal-home` nothing changes.
+- The desktop acceptance procedures (`scripts/obsidian/desktop-receipts.mjs`,
+  maintainer tooling that is not shipped) interrupt AP-03's service only
+  after a healthy status, and only through the handle of the service process
+  the run started; any other number is refused and the step fails. A launch
+  is refused unless the instance's HOME lies inside a layout root the run
+  made and is not the user's own home, however it is reached. In the
+  small-fixture run, cleanup reads the process table until a read records
+  nothing new before its first signal, and the run records how many
+  processes one command-line call becomes. The event-loop benchmark
+  (`scripts/obsidian/benchmark-event-loop.mjs`) signals its child's process
+  group only while it still holds the child.
+
+- AP-03 reports a refused interruption without losing its failure evidence.
+  Separately, small-fixture cleanup remembers a child observed under a run-owned
+  process that exited or changed during the process-table read, then remembers
+  descendants of those children. It retains its temporary roots while those
+  remembered processes remain. It also reserves estimated time for SIGTERM
+  grace after reading the process tree.
+- AP-03 test cleanup runs before temporary-workspace removal. It joins children
+  through retained handles even when the service record is missing or malformed
+  or graceful stop fails. Unheld launcher services use the existing forced-stop
+  fallback, which rechecks healthy runtime identity before signalling the PID.
+  A held child that does not exit within the cleanup bound fails the test.
+
+## 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