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

package/README.md

@@ -1,50 +1,302 @@
 # MNSTRY Atelier
 
-A methodology that creates real transformation cannot scale through static
-content, generic AI, or manual labor. The Atelier is a local-first toolkit for
-authoring that body of work as structured documents machines can validate —
-in plain files, on your machine, under your control.
-
-It is built for methodology holders and the studios that serve them: you
-author primitives, sources, and offers in your own repositories; the Atelier
-builds a knowledge graph over them, projects a local review surface, checks
-readiness against published protocols, and validates exports against public
-contracts. The MNSTRY runtime remains the authority for identity, consent,
-visibility, provisioning, bookings, commerce, sessions, audit, and
-client-grade sharing — using it is optional, and everything here works
-without it.
-
-## Status
-
-- Version: `0.2.0-alpha.1`
-- Stability: alpha — contracts are under a compatibility gate from the
-  `v0.2.0-alpha.0` epoch tag onward; everything else may still move
-- Runtime: Node.js `>=22.18.0 <23`
-- Dependencies: ajv, ajv-formats (JSON Schema validation); nothing else at
-  runtime
-- Distribution: `@mnstry/atelier@0.2.0-alpha.1` on npm, published from the
-  `v0.2.0-alpha.1` tag. The older `v0.2.0-alpha.0` tag is the contract
-  epoch marker, not an install target — it predates the current tree.
-- Telemetry: none. Network egress: none, with one documented exception —
-  see "Nothing leaves your machine" below.
-
-## Claims you can check
+**Turn a repository into a living, governed system.**
+
+Important bodies of work often begin as files: methods, research, programs,
+policies, editorial systems, product knowledge, or something no existing app
+quite understands. A folder can hold that work, but it cannot explain what each
+file is, how the pieces relate, who may see them, or whether the whole is ready
+to use.
+
+The Atelier adds that missing layer without taking the work away from you. It
+turns a repository into an ontology-governed knowledge graph, gives rules the
+power to refuse invalid states, and produces bounded views for people, teams,
+agents, and tools. Git remains the source of record. Your files remain readable.
+The authoring runtime remains local; optional vault adapters run in an explicitly configured host.
+
+That makes the same repository useful at several levels:
+
+- A **steward** can shape a coherent system without surrendering it to a
+  proprietary database.
+- A **team** can collaborate through explicit roles, handoffs, and disclosure
+  boundaries.
+- A **person or agent** can receive the right context and capabilities for the
+  task, without receiving the entire repository.
+- A **toolmaker** can build a specialized or commercial product on the graph,
+  contracts, validators, and projections instead of inventing a new source of
+  truth.
+
+MNSTRY built the Atelier for a demanding case: a living body of methodology
+that must stay legible, internally connected, privacy-aware, and usable across
+many interfaces. Methodology authoring is one application of the system, not
+its definition or ceiling.
+
+## From files to a working system
+
+For local-harness authoring, see [durable coauthor sessions](docs/coauthor-session.md)
+and [skill stewardship and managed installation](docs/skill-steward.md).
+[Immutable intake and guide contracts](docs/intake-and-guides.md) extend existing
+processing and hosted-tool adapters without adding remote execution or publication
+authority. These alpha capabilities require explicit consumer integration.
+
+```text
+files you own
+    ↓ declare identity, type, audience, and relationships
+ontology-governed graph
+    ↓ apply contracts, policies, and readiness rules
+governed projections
+    ├── local review
+    ├── bounded agent context
+    ├── collaboration and disclosure
+    └── specialized tools and commercial distributions
+```
+
+You can see the complete loop in a disposable sample workspace:
+
+```bash
+npm install --save-dev @mnstry/atelier@0.2.0-alpha.11
+npx mnstry-atelier init --fixture=sample-workspace --target ./sample
+npx mnstry-atelier graph --project ./sample/atelier.project.json
+npx mnstry-atelier project --project ./sample/atelier.project.json
+npx mnstry-atelier dev --project ./sample/atelier.project.json
+```
+
+Open the loopback URL printed by `dev`. The browser page is generated from
+the same graph and rules that the CLI and library expose.
+
+`npx` here runs the binary installed in `./node_modules/.bin`, so install the
+scoped package first. Keep the `@mnstry/` scope: the unscoped npm package
+`atelier` is unrelated. The branded `npx mnstry-atelier` command avoids that
+collision; inside an installed workspace, the shorter `atelier` command is
+also available.
+
+## What authoring looks like
+
+Enrollment is deliberately small. A source file declares its identity, type,
+audience, and relationships in front matter:
+
+```markdown
+---
+title: Breath practice
+summary: A simple preparation practice.
+tags: []
+kg:
+  id: example:breath-practice
+  type: document
+  status: active
+  audience: public
+  relations:
+    belongs_to: example:flagship-program
+---
+
+# Breath practice
+
+Let the exhale become slightly longer than the inhale.
+```
+
+The file is still Markdown. Git still records its history. The declarations
+let the Atelier resolve one canonical identity, validate its declared shape,
+connect it to neighboring work, and decide where it may
+travel.
+
+When a source format cannot carry front matter, a sidecar can provide the same
+declarations. The graph does not require every source to become Markdown.
+
+From there, one source can inform a human-readable review page, a session-bound
+context envelope for an agent, or structured input to another tool. These are
+interfaces to the same governed repository, not copies that quietly drift apart.
+
+## Rules travel with the work
+
+The ontology is not only a vocabulary. It is an enforcement surface. Contracts
+define valid shapes, policies govern movement and disclosure, readiness rules
+make completion testable, and validators fail closed when a boundary cannot be
+proven.
+
+<!-- atelier:block:audience-visibility:start -->
+The `audience` field in the header is the load-bearing word. It declares who
+a source is written for — `public`, `team`, `operator`, `staff`, `private`,
+or `sensitive` — and the machinery downstream refuses to let material travel
+further than its audience allows. Runtime and export `visibility` is a
+separate vocabulary (`private`, `shared`, `platform`, `public`) describing
+runtime exposure, and the validators reject every crossing between the two.
+Above all: a public export that references a source whose audience is not
+public is refused. That check is fixture-pinned and mutation-tested —
+deleting its enforcement fails tests, not documentation.
+<!-- atelier:block:audience-visibility:end -->
+
+That distinction matters whenever several interfaces share one body of work.
+A public site, an internal review tool, and an agent session can all use the
+same graph while receiving different, mechanically checked projections.
+
+## The system beneath it
+
+### 1. The repository becomes an ontology
+
+The project manifest tells the Atelier where sources live and which boundaries
+govern the workspace. Source declarations establish typed nodes and relationships. The
+graph command resolves those declarations into a deterministic index that can
+be queried, validated, rendered, and extended.
+
+This is what makes a collection of files behave like a system while remaining
+portable. The repository contains both the knowledge and the terms needed to
+interpret it.
+
+### 2. Rules can refuse
+
+A useful rule must do more than advise. The Atelier checks schema validity,
+relationship integrity, audience boundaries, readiness protocols, and export
+contracts. Invalid or ambiguous states produce a failing command instead of a
+best-effort publication.
+
+Because the checks are local and versioned with the work, the repository can
+prove its state in CI, on a laptop, or inside a larger toolchain.
+
+Repositories that may contribute to a public or shared surface can add a
+private, ignored disclosure denylist and scan either the tracked tree or the
+exact staged index:
+
+```bash
+npx mnstry-atelier disclosure check --staged
+```
+
+The built-in structural pass catches machine-local paths, key material, and
+secret-shaped assignments. A client-aware verdict additionally requires the
+private denylist; the command fails closed when it is absent unless
+`--structural-only` is chosen explicitly. Denylist patterns and matched text
+never belong in the shared repository.
+
+### 3. Collaboration becomes governed disclosure
+
+Collaboration is not equivalent to giving every participant every file. The
+Atelier models audience, runtime visibility, roles, and capability envelopes
+as separate concerns. A projection can therefore disclose the material needed
+for a task while withholding material outside that boundary.
+
+This creates a shared language for human handoffs, agent sessions, reviews,
+and eventual managed delivery. The open package validates the declared
+boundary; it does not silently make access decisions on your behalf.
+
+### 4. The local runtime serves people and agents
+
+`atelier dev` exposes a loopback-only review surface backed by the compiled
+graph. The library exposes the same project, graph, validation, and projection
+primitives to code.
+
+Consumer-owned authoring or review services that need a separate durable
+lifecycle follow [the managed local-service contract](./docs/local-services.md).
+That contract standardizes process ownership, private local state, and browser
+recovery without putting a tenant's service details into Atelier.
+
+The shipped agent model is intentionally bounded: the Atelier can assemble
+session context, capability envelopes, and proposed changes, but it does not
+apply those proposals or grant direct write access. It is a local context and
+control layer that another interface can build on, not an autonomous editor.
+
+The separate headless repository supervisor can observe one explicitly
+enrolled Git repository, fetch and fast-forward it, and prepare a bounded
+commit plan. A commit still requires an exact user confirmation and an
+unchanged re-observation; the loopback browser receives no apply endpoint.
+See [Atelier Sync: Deliverable Zero](docs/atelier-sync.md).
+
+### 5. The repository can power another product
 
+The CLI is one interface. The package is also a library, and its contracts are
+published artifacts. A tool can use the repository as its durable source of
+truth, compile the graph, select an audience-safe projection, and present a
+purpose-built experience without reimplementing the governance model.
+
+That tool may be private, open source, or commercial. Apache-2.0 permits all
+three. Conformance to the public Atelier contracts does not require a MNSTRY
+account or service.
+
+Read [the design document](./docs/design.md) for the five-part architecture and
+[the ontology](./docs/ontology.md) and
+[contract-stability policy](./docs/contract-stability.md) for the stable
+boundaries.
+
+## Build your own tool on it
+
+Use the CLI when a shell command or CI gate is enough. Use the library when the
+Atelier is the substrate beneath a custom interface:
+
+```js
+import {
+  buildGraph,
+  resolveProjectConfig,
+} from '@mnstry/atelier'
+
+const project = resolveProjectConfig({
+  cwd: process.cwd(),
+  argv: ['--project=./atelier.project.json'],
+})
+const graph = buildGraph(project)
+
+if (graph.errors.length > 0) throw new Error(graph.errors.join('\n'))
+console.log(graph.nodes)
+```
+
+The package exports change over the alpha series, so pin the exact prerelease
+version and treat the package export map and shipped source modules as the
+executable API reference. [Distribution contracts](./docs/distributions.md) explain
+how a governed subset can be packaged for another surface without widening its
+audience.
+
+The [advisory decision contract](./docs/decisions.md) gives hosts bounded
+choice, score and boolean questions with evidence references and recorded
+uncertainty. `@mnstry/atelier/decisions` validates these records offline.
+The host supplies optional provider execution and retains authorization;
+an assessment carries proposal-only authority.
+
+## Where the Atelier stops
+
+The open package owns repository-side structure and proof. A managed runtime
+may consume a conformant export, but that is a separate system with a separate
+trust boundary.
+
+| The local Atelier does | A managed runtime may do |
+| --- | --- |
+| Parse sources and sidecars | Authenticate participants |
+| Compile and query the graph | Resolve live authorization |
+| Validate contracts and relationships | Persist runtime state |
+| Enforce export audience boundaries | Deliver governed experiences |
+| Generate local review and agent context | Record consent and operational events |
+| Check offline conformance | Decide optional admission |
+
+### Claims you can verify
+
+<!-- atelier:block:claims:start -->
 This package makes three promises. None of them asks for your trust — each
 one names the command that proves it.
 
-**Nothing leaves your machine, with one exception you can see.** There is no
-telemetry, no update check, no crash reporting, and no send path anywhere in
-the package. The exception: when no actor is configured, `boundary check` and
-`doctor` fall back to the `gh` CLI to resolve your GitHub login, which is an
-authenticated request to GitHub made with your own credentials. Set
-`MNSTRY_ATELIER_ACTOR` and that path is never taken. The only network client
-refuses non-loopback URLs, the served pages carry a policy that authorizes no
-external origin, and a fail-closed gate scans the executable and markup files
-under `src/`, `bin/`, `scripts/`, and `examples/` for egress primitives. Two
-limits worth stating plainly: the gate does not read the `.json` and `.md`
-files under `templates/` and `skills/`, and it does not model
-`child_process`, which is why the `gh` fallback above does not trip it:
+**There is no silent egress; every network path is named.** There is no
+telemetry, update check, crash reporting, or model provider path in the package.
+The optional vault API adds explicit host-bound artifact uploads and reads; it
+is never activated by local authoring commands. Its injected storage, database
+and identity SDKs may use the network and require separate hosted qualification. The exceptions are explicit: `boundary check` and
+`upgrade` (including `--dry-run` and `--apply`) may invoke `gh api user` only when
+an operated private-domain repository needs owner attribution, no explicit selector or `GITHUB_ACTOR` was supplied, and no
+configured Git email maps to an actor. Shared-only boundary checks skip derived
+identity lookup. Invalid explicit selectors are refused without fallback;
+platform logins must uniquely match declared login mappings. Repository identity
+checks may invoke `gh api repos/...` to resolve a canonical GitHub identity.
+Those authenticated requests use your own `gh` credentials. Recorded repository
+identities let identity checks keep working when the provider is unavailable.
+See `docs/install.md` for the full attribution precedence and mode semantics.
+Explicitly enrolled Atelier Sync may also run bounded Git fetches
+for observation/reconciliation and one non-force push only when the exact
+reviewed commit plan requested and confirmed it, no earlier local commit is
+waiting to be published, and HEAD still names the verified commit object. Sync
+never uses the network actor fallback, follows tags, or recursively publishes
+submodule refs. The local authoring HTTP client
+refuses non-loopback URLs, the served pages authorize no external origin, and
+release audit scans every executable or markup file in the exact `npm pack`
+inventory for egress primitives. The standalone gate also scans executable and
+markup files under `src/`, `bin/`, `scripts/`, `templates/`, `examples/`, and
+`skills/`. Two limits worth stating plainly: the egress control does not
+interpret data-only `.json` or `.md` files, and it does not model
+`child_process`; the reviewed `gh` and enrolled Git paths above are documented
+subprocess exceptions rather than scanner detections:
 
 ```bash
 npm run egress:check
@@ -75,188 +327,133 @@ atelier dry-run ./atelier-export.json
 `docs/continuity.md` records the distribution commitments behind these
 claims, including the perpetual Apache-2.0 grant on every tagged release you
 receive.
+<!-- atelier:block:claims:end -->
 
-## Quickstart
-
-```bash
-npm install --save-dev @mnstry/atelier@0.2.0-alpha.1
-
-npx atelier init --fixture=sample-workspace --target ./sample
-npx atelier graph --project ./sample/atelier.project.json
-npx atelier project --project ./sample/atelier.project.json
-npx atelier readiness --project ./sample/atelier.project.json
-MNSTRY_ATELIER_ACTOR=owner npx atelier boundary check --project ./sample/atelier.project.json
-npx atelier dev --project ./sample/atelier.project.json
-```
-
-`npx` here runs the binary already installed in `./node_modules/.bin`. Always
-install first, and keep the `@mnstry/` scope — the unscoped name `atelier`
-belongs to an unrelated third-party package.
-
-`init` scaffolds a fictional sample workspace, `graph` builds the knowledge
-graph from front matter and sidecars, `project` generates the local review
-surface, `dev` serves it on loopback only. From there:
-
-```js
-import { validateAtelierExportDryRun } from '@mnstry/atelier'
-
-const report = validateAtelierExportDryRun(exportDocument)
-console.log(report.accepted, report.importable, report.errors)
-```
-
-Real projects start from the `private-domain`, `shared-project`, or
-`distribution` templates instead of the sample fixture.
-
-## What this package does
-
-- Initializes neutral local Atelier projects.
-- Builds a front-matter and sidecar-led knowledge graph; a `.kg.json` sidecar
-  enrolls any file — Markdown, JSON, YAML, CSV, media — without the kit ever
-  parsing the foreign format.
-- Generates and serves a local GUI projection over a loopback-only sidecar.
-- Produces agent-harness context and capability envelopes, and ships neutral
-  Codex and Claude skill wrappers for readiness review work.
-- Records proposal metadata without browser apply/write endpoints.
-- Enforces the local source `audience` and runtime `visibility` boundary, and
-  rejects unresolved, disguised, or non-public-projectable source references.
-- Enforces Repo Boundary Guard V1 for private domain and shared project
-  repos: strict policies fail closed when private or sensitive source is
-  placed in a shared repo, when protected local files are staged, or when
-  private-domain material appears in shared work without a `git.promote`
-  disclosure record.
-- Validates `atelier-export@v1` JSON against the published schema and
-  produces deterministic dry-run reports with `accepted`, `importable`, and
-  `worstOperationStatus`.
-- Ships the bundled `mnstry-readiness-pack@v1` with twelve claim-first
-  readiness protocols, extensible through validated extension packs.
-- Writes and checks `atelier.lock.json`, and applies branch-based,
-  review-first upgrades that refuse dirty repos and never silently overwrite
-  authored content.
-- Checks first-party source, templates, and examples for forbidden
-  non-localhost egress — a fail-closed discipline gate over this repo's own
-  code, not a runtime sandbox.
-
-## What this package does not do
+### What it will not do
 
+<!-- atelier:block:will-not-do:start -->
 - It does not write to a MNSTRY runtime database.
-- It does not import, provision, publish, or send anything.
-- It does not contact external services.
+- It does not import, provision, publish, or send project content to a MNSTRY
+  managed runtime.
+- Conformance remains offline. Local CLI network access is limited to the documented
+  `gh` actor-resolution fallback and explicitly enrolled Atelier Sync Git
+  operations: bounded fetch for observation/reconciliation, and non-force push
+  only when the exact reviewed commit plan requested and confirmed it, no
+  earlier local commit remains unpublished, and HEAD still names the verified
+  commit object; Sync does not use network actor fallback, follow tags, or
+  recursively publish submodule refs.
+- Optional vault adapters use explicitly injected host SDKs and transports. The
+  host owns their network access, authentication and infrastructure; importing
+  the kit does not create a service or make a network request.
 - It does not execute model-assisted analysis or any model provider.
 - It does not include client project content.
 
 These limits are the design. An authoring tool for private material earns
 trust by what it refuses to be able to do.
+<!-- atelier:block:will-not-do:end -->
 
-## Your documents and the boundary
-
-What you author is yours. Documents live in your repositories, in formats you
-chose, readable without this tool. The one vocabulary the contracts enforce:
-`audience` describes local source readership (`public`, `team`, `operator`,
-`staff`, `private`, `sensitive`); runtime/export `visibility` describes
-runtime exposure and accepts only `private`, `shared`, `platform`, or
-`public`. A public export referencing a source whose audience is not public
-is refused — that check is fixture-pinned and mutation-tested.
-
-## Build a branded distribution
-
-The Atelier is designed to be white-labeled. A distribution wraps the CLI
-under its own name, contributes a validated extension pack (branded
-protocols, terms, templates), and themes the projection — while the root
-contracts, guards, and conformance stay canonical underneath. Start by
-copying the worked example:
-
-- `examples/loomworks-studio` — a complete fictional distribution: branded
-  bin, extension pack, themed workspace template.
-- `docs/distributions.md` — the contract a distribution must honor.
-- `TRADEMARKS.md` — naming rules; Apache-2.0 grants code rights, not brand
-  rights. Every distribution carries "powered by MNSTRY Atelier" attribution,
-  checked by `atelier distribution check`.
-
-## The MNSTRY relationship
-
-The Atelier is the front porch, not the house. Conformance — is this document
-valid against the published contracts? — is public, offline, and free,
-forever. Admission — will MNSTRY's governed runtime accept it for delivery to
-clients? — is a separate, opt-in step: a signed attestation issued by MNSTRY
-against criteria this package publishes (`docs/attestation.md`). You can
-build on the Atelier without ever talking to MNSTRY. If you want your work to
-run on MNSTRY runtimes, the path is admission, and the rejection message is
-part of the contract.
-
-## Feedback and announcements
-
-Both channels respect consent by construction. `atelier feedback` writes a
-scanned, redaction-checked report to a local file — there is no send path;
-you choose whether and where to share it. `announcements list` verifies
-project-shipped announcements against a committed public key — pull-only,
-nothing phones home to ask.
-
-## Running the test suite from a fresh clone
-
-`npm test` includes one fail-closed check that expects a private denylist
-file (`release-denylist.local.json`, gitignored) used by MNSTRY's release
-lane. On a fresh clone that file is absent, so the check **fails** — it never
-passes silently on missing protection. Expect this, after `npm install`:
+### Conformance and admission
 
-```bash
-npm install
-npm test     # 509 tests: 508 pass, 1 fail — the denylist check, by design
-```
+<!-- atelier:block:conformance-admission:start -->
+The Atelier export format is MNSTRY's format, offered openly.
 
-To acknowledge the missing file and run the rest, which turns that failure
-into a recorded skip:
+**Anyone can check a document against the published contracts, forever,
+offline.** The contracts, fixtures, and dry-run validator all ship in the
+package, so conformance needs no account, no network, and no MNSTRY
+involvement.
 
-```bash
-ATELIER_ALLOW_MISSING_DENYLIST=1 npm test     # 508 pass, 0 fail, 1 skipped
-```
+Admission is a narrower, opt-in decision: whether a MNSTRY governed runtime
+accepts a document for delivery to the people it serves. That is what
+admission buys — delivery through a runtime that enforces consent and
+visibility at serve time — and it takes the form of a signed MNSTRY
+attestation against criteria this package publishes (`docs/attestation.md`).
+The criteria are public, the checker is private, and the rejection message
+is part of the contract. You can build on the Atelier without ever talking
+to MNSTRY, and a document MNSTRY declines can still be fully conformant.
+<!-- atelier:block:conformance-admission:end -->
 
-## Command reference
+## Install and go deeper
+
+Node.js `>=22.18.0 <23` is required. Pin the prerelease while the package
+remains in alpha:
 
 ```bash
-atelier dry-run ./atelier-export.json
-atelier contract check
-atelier graph --project ./atelier.project.json
-atelier project --project ./atelier.project.json
-atelier readiness --project ./atelier.project.json
-atelier readiness protocols
-atelier readiness journey --project ./atelier.project.json
-atelier readiness run mnstry.readiness:identity-map --project ./atelier.project.json
-atelier readiness packet --project ./atelier.project.json
-atelier readiness export --dry-run --project ./atelier.project.json
-atelier boundary check --project ./atelier.project.json
-atelier boundary check --staged --project ./atelier.project.json
-atelier boundary install-hooks --project ./atelier.project.json
-atelier promote --source-repo tenant-private-domain --target-repo project-alpha --kg-id tenant-private-domain:seed
-atelier lock write --project ./atelier.project.json
-atelier lock check --project ./atelier.project.json
-atelier upgrade --dry-run --project ./atelier.project.json
-atelier upgrade --apply --project ./atelier.project.json --branch codex/atelier-upgrade-YYYYMMDD
-atelier extension-pack validate --project ./atelier.project.json
-atelier attestation verify ./attestation.json
-atelier feedback create --message "what happened"
-atelier announcements list
-atelier distribution check --target ./my-distribution
-atelier dev --project ./atelier.project.json
+npm install --save-dev @mnstry/atelier@0.2.0-alpha.11
 ```
 
-`upgrade --apply` creates or switches to the requested branch, refuses dirty
-authored repos, preserves unrelated user hooks through composed hook files,
-runs only registered migrations, refreshes generated projections, and leaves
-a Git commit for review. It will not weaken boundary policy, introduce
-telemetry, enable non-localhost egress, run model-assisted analysis, or write/import/apply
-runtime state.
+Then choose the path that matches what you are building:
+
+- [Installation and first run](./docs/install.md)
+- [Design and architecture](./docs/design.md)
+- [Knowledge graph and source model](./docs/knowledge-graph.md)
+- [Local runtime and agent boundary](./docs/atelier-runtime.md)
+- [Distribution contracts](./docs/distributions.md)
+- [Conformance and attestation](./docs/attestation.md)
+- [Continuity commitments](./docs/continuity.md)
+- [Assurance controls and evidence map](./docs/assurance-controls.md)
+- [Upgrade notes](./docs/upgrade.md)
+- [Upgrade with your agent](./docs/guided-upgrades.md)
+- [Obsidian projection](./docs/obsidian.md)
+
+## Status and command reference
+
+Current package: `@mnstry/atelier@0.2.0-alpha.11`.
+
+The alpha package is usable and contract-tested, but its library API may still
+change before a stable release. Pin the exact version in production toolchains.
+
+```text
+atelier init
+atelier adopt
+atelier setup
+atelier graph
+atelier project
+atelier build
+atelier dev
+atelier generated check
+atelier config check
+atelier extension-pack
+atelier distribution check
+atelier egress check
+atelier boundary
+atelier readiness
+atelier export
+atelier context flow
+atelier support bundle
+atelier feedback
+atelier announcements
+atelier attestation
+atelier promote
+atelier upgrade
+atelier lock
+```
+
+Run `atelier --help` or `atelier <command> --help` for the current flags. The
+full command behavior is also covered by the package's executable tests.
+
+## Contributing and license
+
+Contributions are welcome through [the contribution guide](./CONTRIBUTING.md).
+MNSTRY Atelier is released under [Apache-2.0](./LICENSE).
 
-## Sample fixtures
+## Experimental hosted vault contract
 
-Fixtures in this package are fictional and generic. Project-specific adapter
-fixtures belong in their project repositories, not in the published Atelier
-package.
+An optional [private artifact vault service](docs/vault-service.md) supplies a
+provider-independent ownership boundary and explicit Vercel/Cloudflare storage
+bindings. It is not enabled by local CLI commands. Hosting adapters can perform
+network I/O only when explicitly installed and invoked by a consuming host.
+Browser identity integration and hosted acceptance remain unqualified.
 
-## License and contributing
+## Experimental Obsidian projection
 
-Apache-2.0. See `LICENSE`, `NOTICE` (attribution obligations that survive
-forks), `TRADEMARKS.md` (naming), and `docs/continuity.md` (distribution
-continuity commitments). Contributions are accepted under inbound-equals-
-outbound Apache-2.0 with a DCO sign-off — `CONTRIBUTING.md` is the working
-agreement, including how to contribute without exposing client material or
-your own private methodology.
+An opt-in projection publishes readable, linked notes of an enrolled workspace
+into a vault outside every repository, keeps them current, and preserves every
+edit made in the editor before anything is republished. A body edit is applied
+to its source manually or under a scoped policy the user installs; anything
+structural stays a copy-only proposal. Atelier never commits to Git for it.
+It is disabled unless a project enables it, and it is proven on one platform
+and one app version. Read [what it does and its known limits](docs/obsidian.md),
+the [contract](docs/obsidian-contract.md) and the
+[maintenance service](docs/local-services.md) before relying on it. The
+package subpaths are `@mnstry/atelier/obsidian` and
+`@mnstry/atelier/obsidian/*`.

package/SECURITY.md

@@ -42,9 +42,14 @@ you have to sign.
 These are the claims the package makes. Defeating any of them is a
 vulnerability, and the more quietly it can be defeated, the more severe:
 
-- **Egress.** Any network send path in first-party code, or any way to make
+- **Egress.** Any undocumented network send path, any vault SDK invocation
+  without explicit host integration, or any way to make
   the local sidecar reachable off loopback or serve a policy that authorizes
   an external origin.
+- **Vault ownership.** Any hosted artifact or asset served without a verified
+  owner identity, cross-vault credential use, or publication that bypasses the
+  atomic owner/revision check. The experimental contract still requires hosted
+  qualification; local conformance tests are not a production safety claim.
 - **Boundary guard.** Any way to get private or sensitive source into a
   shared repo, to stage a protected local file, or to promote private-domain
   material without the required disclosure record — while the guard reports