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

package/CHANGELOG.md

@@ -1,5 +1,666 @@
 # 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