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

package/CHANGELOG.md

@@ -1,5 +1,288 @@
 # Changelog
 
+## 0.2.0-alpha.15
+
+- Patch the fast-uri dependency and override from 3.1.8 to 3.1.9, the patched 3.x release for GHSA-w74x-v6f9-j3xg, GHSA-xhq7-xmqj-769h, GHSA-wjr9-j795-jxcr and GHSA-333x-w4r6-6crp (3.1.8 is in each affected range; whether Atelier's use was exploitable is not established). Ajv's own `^3.0.1` range resolves to the same copy, so a bare consumer installs 3.1.9 only, and `npm audit` reports no runtime advisory.
+- Add the graph workspace (`@mnstry/atelier/graph-workspace` and `/graph-workspace/browser`): one graph in three rooms, a constellation of every readable record on a night-sky canvas with folder zones and collision-free labels, a workbench of sparse cards beside a focused authoring sheet, and a review that shows before and proposed and leaves the decision to a person. Work recipes choose the room, lens and primary action, and compose across Atelier, coach and owner layers with per-field provenance; themes compose the same way and refuse unsafe values and low contrast. Scale helpers show the whole as zones beyond 12,000 records and open one zone at a time with every omission counted. Drafts live behind a storage port (this browser by default, and the interface says so). A shareable-content gate finds fingerprints of private graphs in shareable text. Renderer packages are injected by the host; Atelier adds no runtime dependency. See the [graph workspace guide](docs/guides/graph-workspace.md).
+- Add renderer-neutral graph views (`atelier.graph-view@v1`), a reader-bound graph access port, repository-qualified Markdown source contributions, a source-bound edge eligibility policy and adapters that bind source contributions through edge policy to graph access. Hosts still own authentication, grants, revalidation and keys.
+- Add a structured graph explorer with a provenance inspector, an optional Babylon graph-view consumer, source-bound ontology guidance drafts, and an authorized projection refresh lifecycle with scoped impact comparison.
+- Refuse aliases of Git metadata, a root Git metadata entry that disappears before capture, and impossible UTF-16 or UTF-8 locator offsets in repository contributions, and resolve outgoing links from uppercase `.MD` sources. Knowledge Health pins the bytes of the knowledge-graph file, so its rule identity is regenerated for it: the `check` each assessment carries names a new `version` and `sourceTree`, and the rule it applies is unchanged.
+
+- Accept a longer personal-selection history without a fresh confirmation only when it still holds the accepted record at its position. After a confirmed shortening, a divergent history at or above the earlier maximum refuses until it is confirmed again; ordinary appends and exact restoration are unchanged.
+
+- Check the private-state location before a first use writes the workspace pointer, and check the persisted identity again before any further write. A refused location now leaves no pointer and no local state behind.
+
+- Write no refusal bookkeeping for a private-state location refusal (a lock held or just taken is still released or withdrawn), and none unless the state root is still outside every root declared now, for a cached store as well as a newly located one. A configured locator that refuses leaves current roots unknown, so nothing is written. Retained selection-continuity writes, freshness writes and every engine phase that writes after a cooperative wait (vault-edit preservation, pending edits, automatic apply, preparation and publication) prove the location again against the roots declared now, as do engine-lock acquisition after its inspection, vault allocation after reading the app's list, and the publisher after each wait for the app, its list of vaults, its comparison of kept notes or its quiet period. Neither a location refusal nor a failure that leaves the location unproven (a wait for the app that gave up) writes a publication failure entry. A service started by a login item no longer falls back to the workspace the unit names when locating its workspace refuses, and prints a location refusal instead of logging or recording it there; a tick the engine refuses outright for the location of private state leaves the service's error record as it was. A refusal of the private state's own location found in one view (`managed-root-unproven`) stops the whole tick, so no later view goes on under roots that can no longer be trusted; a view whose own vault is in a bad place is still refused alone. These proofs are made at named points in the engine and the publisher, not at every write. Roots "declared now" are a personal home's manifest read again at each proof; an ordinary project's are those of the project as last loaded, until it is loaded again. The service process's own records, its plugin state and the built-in proposal store are not proven against the roots declared now; Known limits in the Obsidian guide lists them.
+
+- Never let an unpersisted selection acceptance replace a newer durable one: a retained observation keeps its maximum and identities, but the checkpoint's accepted head wins once another writer has changed it.
+
+- Refuse `obsidian uninstall` when the workspace location or identity cannot be established, instead of reporting that nothing was installed. No login-item or service action is taken.
+
+- Create every workshop directory and file exclusively when initializing a new workshop, so a directory or file that arrives meanwhile refuses instead of being merged, and refuse before Git initialization if an unknown entry appears inside a directory the initialization created. Nothing is overwritten and nothing unknown is removed.
+
+- Order journey runs by their validated creation instant, with run identity as the deterministic tie-break. Latest-per-protocol summaries and tenant packets share that rule; malformed times refuse rather than inherit hash-filename order. Clarify that a review-workspace decision concerns its run claims and source linkage alone does not establish logical support.
+
+- Refuse a view as mixed-read when a previously observed source becomes a directory or changes during its pinned read, or a graph-declared sidecar disappears during the build. Other views can proceed; never-observed and unreadable sources retain their own errors.
+- Cover the Astro presentation example in weekly dependency updates. Update Astro to 7.3.8 and refresh its locked sharp and HTTP cache-semantics dependencies to their patched releases.
+
+- Event-loop benchmark results record the host logical CPU count and the one-, five- and fifteen-minute load averages at the start and end, including failed runs, so responsiveness evidence can be read with its host conditions.
+- Keep all enrolled repository roots outside private service state when locating a personal workspace. Locating an existing home now requires its readable authored manifest, including an explicitly empty enrollment; the lower-level service API refuses a bare home instead of assuming no repository exclusions. Login-item removal and uninstall can retain their off choice before any generation is confirmed, and report the actual kept workspace pointer. Clarify which generation reads and assembly still run on the caller thread.
+
+- Persist personal-selection continuity across service starts. A shortened history stays refused until its removed records return or a fresh confirmation accepts it; previously observed records cannot stand in for a new confirmation. A missing checkpoint with retained private ownership evidence refuses instead of becoming a first start.
+- Initialize an undecided personal vault audience as owner only in machine settings. Explicit choices and clears keep their meaning; personal bindings permit `audience set me` and `audience clear`, and refuse custom audience lists. Initialization rereads under the same lock as setting writes so a concurrent clear stays empty.
+- Keep blocking boundary diagnostics visible before warnings, report one aggregate evidence limit, and pin path quoting in Git evidence. Staged acquisition refuses missing or incomplete repository evidence and covers type changes without rename collapse. Conservative semantic assignment detection and runner-error handling preserve classified-document deletion review. Boundary checks flush complete JSON diagnostics through pipes before returning their refusal exit code.
+
+- Allow projects to deselect the bundled MNSTRY readiness pack with tracked `ext["mnstry.atelier"].readiness.includeBundled: false`. Generic graph, project and readiness checks and selected custom protocols remain available; bundled journey, packet and readiness export commands refuse. Selection changes require an explicit lock write. Absent or `true` preserves the existing default, IDs and APIs.
+
+- Name the practical-judgment responsibility Phronesis, with practical judgment as its plain-language description. Existing catalog identity, English lookup alias, judgment API and skill identities remain compatible. Keep Knowledge Stewardship distinct from the shared Knowledge Graph representation; move the current guide to `docs/reference/phronesis.md`.
+
+- The boundary push check names its reason when a push's refs together exceed the evidence budget (`push-evidence-too-large`, with `limitBytes`, as when one ref's commits do), where before that refusal carried no reason. The text output of `atelier boundary check` and `atelier boundary push-check` lists a scan that could not finish (`content-scan-incomplete`, `semantic-field-scan-incomplete`, `repo-unscannable`) before the content findings and says how many findings past the first 50 it leaves out, so a long list no longer hides why a commit or push was refused. The guard documentation says the 1000-commit limit applies to each ref update and what to do with a single commit over the budget on its own.
+
+- Add the optional native Convex backend adapter and TypeScript starter through the existing extension init/seal/validate/bundle workflow. HTTP admission and private native mutations reuse the delegation contract; indexed operation results commit with custom writes. Native provider qualification remains separate from reactive lifecycle and complete host/customer acceptance.
+
+- Add native Drizzle DB-first/code-first and Prisma 7 project profiles, prepared scoped transactions and provider receipt recovery. Optional provider dependencies stay in the generated app; Root and supported-host acceptance remain separate gates.
+
+
+- Organize current documentation into start, guides, reference and maintainer folders with one index. Remove superseded planning/review and event walkthrough files. Remove the retired Obsidian publication experiment, retaining its active isolated-app test fixture in the maintained harness with read-only inspection and refusal coverage. Required packed-document and inbound references follow the new paths.
+
+- Repository cleanup groups vault test helpers under `test/support/vault/` and imports consumer-closure diagnostics directly from their existing source module. CLI help describes `mnstry-atelier` as a supported npm alias. The repository-local reconsideration tool now measures only the explicitly marked Maintained implementation decisions section of the architecture reference; definition revision four retains predicate v3 and all original measurement records.
+
+- Add portable typed extension contracts, authenticated host clients, signed server admission and native Postgres transaction/receipt helpers under the existing package.
+- Add `atelier extension init|validate|seal` for a customer-owned Postgres TypeScript project. Generation and sealing do not deploy or authorize an installation. Provider and supported-host qualification carry separate evidence.
+
+## 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