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

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (6) hide show
  1. package/CHANGELOG.md +25 -0
  2. package/README.md +173 -94
  3. package/docs/design.md +154 -0
  4. package/docs/install.md +3 -3
  5. package/docs/upgrade.md +13 -3
  6. package/package.json +1 -1
package/CHANGELOG.md CHANGED
@@ -1,5 +1,30 @@
1
1
  # Changelog
2
2
 
3
+ ## 0.2.0-alpha.2
4
+
5
+ Documentation and release-lane release. No contract changes and no runtime
6
+ behaviour changes: documents valid against `0.2.0-alpha.0` remain valid.
7
+
8
+ - **The README is rebuilt around the system rather than its first
9
+ application.** New `docs/design.md` states the design in five movements —
10
+ a repository with an ontology, rules that refuse, collaboration as governed
11
+ disclosure, a local runtime for humans and for agents, and a platform for
12
+ your own tool — each ending with the command that proves it. Methodology
13
+ authoring is stated as the first application, not the ceiling.
14
+ - **Publishing is automated on tag push** via npm trusted publishing (OIDC),
15
+ so releases carry a provenance attestation and no registry token is stored
16
+ anywhere. Two fail-closed guards: the tagged commit must be an ancestor of
17
+ `main`, and the tag must equal `package.json`'s version.
18
+ - **The disclosure scanner no longer flags the OIDC permission key.**
19
+ `id-token` is a GitHub Actions permission, not a credential; the exemption
20
+ is the literal `id-` prefix only, and every other compound still matches.
21
+ - **`0.2.0` was published in error and unpublished the same day.** A
22
+ `npm version patch` against an alpha resolves the prerelease to `0.2.0`
23
+ rather than advancing it, and `git push --follow-tags` delivered the tag
24
+ even though branch protection rejected the commit, so a release published
25
+ from a commit that never landed on `main`. That number is permanently
26
+ retired on npm. The ancestry guard above exists so this cannot recur.
27
+
3
28
  ## 0.2.0-alpha.1
4
29
 
5
30
  First release published to the npm registry, under `@mnstry/atelier` with
package/README.md CHANGED
@@ -1,30 +1,165 @@
1
1
  # MNSTRY Atelier
2
2
 
3
+ **Author your methodology once, in files you own, in a form machines can
4
+ validate and runtimes can honor.**
5
+
3
6
  A methodology that creates real transformation cannot scale through static
4
- content, generic AI, or manual labor. The Atelier is a local-first toolkit for
5
- authoring that body of work as structured documents machines can validate —
6
- in plain files, on your machine, under your control.
7
-
8
- It is built for methodology holders and the studios that serve them: you
9
- author primitives, sources, and offers in your own repositories; the Atelier
10
- builds a knowledge graph over them, projects a local review surface, checks
11
- readiness against published protocols, and validates exports against public
12
- contracts. The MNSTRY runtime remains the authority for identity, consent,
13
- visibility, provisioning, bookings, commerce, sessions, audit, and
14
- client-grade sharing — using it is optional, and everything here works
15
- without it.
7
+ content, generic AI, or manual labor. Scaling it means giving it a form
8
+ machines can carry — and most tools do that by taking the work into their
9
+ platform, their format, their database, where it stops being fully yours.
10
+ The Atelier answers the same problem the other way around.
11
+
12
+ The Atelier is a local-first toolkit for authoring a body of work as
13
+ structured documents machines can validate — plain files, in your own Git
14
+ repositories, on your machine, under your control. You author primitives,
15
+ sources, and offers; the Atelier builds a knowledge graph over them,
16
+ projects a local review surface, checks readiness against published
17
+ protocols, and validates exports against public contracts. There is no
18
+ telemetry and no send path, and the commands that prove the package's
19
+ promises are further down this page.
20
+
21
+ It is built for methodology holders and the studios that serve them. The
22
+ MNSTRY runtime — the governed platform for identity, consent, visibility,
23
+ provisioning, bookings, commerce, sessions, audit, and client-grade
24
+ sharing — is a separate, optional destination. The Atelier is the front
25
+ porch, not the house: everything here works without ever talking to MNSTRY.
26
+
27
+ ## What authoring looks like
28
+
29
+ A source document is a plain file with a small structured header. This is a
30
+ complete, working example — fictional, like every fixture in this package:
31
+
32
+ ```markdown
33
+ ---
34
+ title: "Grounding practice"
35
+ summary: "The opening practice every offer in this catalog builds on."
36
+ kg:
37
+ id: "my-studio:grounding-practice"
38
+ type: "document"
39
+ status: "active"
40
+ audience: "team"
41
+ relations:
42
+ supports: "my-studio:flagship-offer"
43
+ ---
44
+
45
+ # Grounding practice
46
+
47
+ The practice itself, in your words, in your file, in your repository.
48
+ ```
49
+
50
+ That header is the entire enrollment. The graph builder reads front matter
51
+ like this, and `.kg.json` sidecars for files that are not Markdown — JSON,
52
+ YAML, CSV, media, anything — without ever parsing the foreign format. From
53
+ there the working loop is four commands:
54
+
55
+ ```bash
56
+ atelier graph --project ./atelier.project.json # build the knowledge graph
57
+ atelier project --project ./atelier.project.json # generate the local review surface
58
+ atelier readiness --project ./atelier.project.json # check against published protocols
59
+ atelier dry-run ./atelier-export.json # validate against the public contracts
60
+ ```
61
+
62
+ Each one reads local files and writes local files. The `audience` field in
63
+ the header is the load-bearing word: it declares who a source is written
64
+ for (`public`, `team`, `operator`, `staff`, `private`, `sensitive`), and
65
+ the machinery downstream refuses to let material travel further than its
66
+ audience allows. A public export that references a non-public source is
67
+ rejected — that check is fixture-pinned and mutation-tested.
68
+
69
+ ## The system
70
+
71
+ Git is the database. The ontology is the schema. The validators are the
72
+ constraints. The runtime is local. The design is five movements, each
73
+ grounded in shipped machinery — [docs/design.md](docs/design.md) states
74
+ them in full, ending each one with the command that proves it:
75
+
76
+ **A repository with an ontology.** Front matter — or a `.kg.json` sidecar
77
+ beside any format the kit never parses — declares a file's identity, type,
78
+ audience, and relations. The graph builder compiles the repository into a
79
+ deterministic knowledge graph. No import step, no database: the repository
80
+ is the store, and Git is the history, the review process, and the read
81
+ boundary.
82
+
83
+ **Rules that refuse.** Eighteen contracts under a compatibility epoch
84
+ define the vocabulary; fail-closed validators enforce it. A public export
85
+ that references a non-public source is rejected — fixture-pinned and
86
+ mutation-tested — and dry-run reports are deterministic: `accepted`,
87
+ `importable`, `worstOperationStatus`. Twelve bundled claim-first readiness
88
+ protocols check the work against published criteria and produce proposed
89
+ claims, never runtime mutations.
90
+
91
+ **Collaboration as governed disclosure.** Private-domain and shared-project
92
+ repos have enforced roles: the boundary guard fails closed when private or
93
+ sensitive material lands in shared space, when protected local files are
94
+ staged, or when private-domain material appears in shared work without a
95
+ recorded `git.promote` disclosure event. Disclosure is a commit, not an
96
+ accident. Change to the machinery itself is governed the same way — the
97
+ lockfile records exactly what a workspace runs, and upgrades are
98
+ branch-based, review-first, and refuse dirty repos.
99
+
100
+ **A local runtime for humans and for agents.** The workspace projects two
101
+ ways: a generated review surface over a loopback-only sidecar for humans,
102
+ and session-bound context and capability envelopes for agent harnesses — a
103
+ governed view with proposals recorded as metadata and no apply endpoints.
104
+ Context without authority. Neutral Claude and Codex skill wrappers ship in
105
+ the package.
106
+
107
+ **A platform for your own tool.** A distribution wraps the CLI under your
108
+ own name, contributes a validated extension pack, and themes the
109
+ projection, while the root contracts, guards, and conformance stay
110
+ canonical underneath — commercially if you want. See "Build your own tool
111
+ on it" below.
112
+
113
+ Methodology authoring is the first application, not the ceiling. MNSTRY
114
+ built the Atelier to carry its own most demanding case — private
115
+ transformational work, where a leaked document is a betrayal — and a
116
+ system trustworthy enough for that is trustworthy enough for whatever you
117
+ govern with it.
118
+
119
+ ## Quickstart
120
+
121
+ ```bash
122
+ npm install --save-dev @mnstry/atelier@0.2.0-alpha.2
123
+
124
+ npx atelier init --fixture=sample-workspace --target ./sample
125
+ npx atelier graph --project ./sample/atelier.project.json
126
+ npx atelier project --project ./sample/atelier.project.json
127
+ npx atelier readiness --project ./sample/atelier.project.json
128
+ MNSTRY_ATELIER_ACTOR=owner npx atelier boundary check --project ./sample/atelier.project.json
129
+ npx atelier dev --project ./sample/atelier.project.json
130
+ ```
131
+
132
+ `npx` here runs the binary already installed in `./node_modules/.bin`. Always
133
+ install first, and keep the `@mnstry/` scope — the unscoped name `atelier`
134
+ belongs to an unrelated third-party package.
135
+
136
+ `init` scaffolds a fictional sample workspace, `graph` builds the knowledge
137
+ graph from front matter and sidecars, `project` generates the local review
138
+ surface, `dev` serves it on loopback only. From there:
139
+
140
+ ```js
141
+ import { validateAtelierExportDryRun } from '@mnstry/atelier'
142
+
143
+ const report = validateAtelierExportDryRun(exportDocument)
144
+ console.log(report.accepted, report.importable, report.errors)
145
+ ```
146
+
147
+ Real projects start from the `private-domain`, `shared-project`, or
148
+ `distribution` templates instead of the sample fixture.
16
149
 
17
150
  ## Status
18
151
 
19
- - Version: `0.2.0-alpha.1`
152
+ - Version: `0.2.0-alpha.2`
20
153
  - Stability: alpha — contracts are under a compatibility gate from the
21
154
  `v0.2.0-alpha.0` epoch tag onward; everything else may still move
22
155
  - Runtime: Node.js `>=22.18.0 <23`
23
156
  - Dependencies: ajv, ajv-formats (JSON Schema validation); nothing else at
24
157
  runtime
25
- - Distribution: `@mnstry/atelier@0.2.0-alpha.1` on npm, published from the
26
- `v0.2.0-alpha.1` tag. The older `v0.2.0-alpha.0` tag is the contract
27
- epoch marker, not an install target — it predates the current tree.
158
+ - Distribution: `@mnstry/atelier@0.2.0-alpha.2` on npm, published from the
159
+ `v0.2.0-alpha.2` tag. The `v0.2.0-alpha.0` tag is the contract epoch
160
+ marker, not an install target — it predates the current tree. The version
161
+ `0.2.0` was published in error and unpublished the same day; that number
162
+ is permanently retired on npm and will never be reused.
28
163
  - Telemetry: none. Network egress: none, with one documented exception —
29
164
  see "Nothing leaves your machine" below.
30
165
 
@@ -76,67 +211,7 @@ atelier dry-run ./atelier-export.json
76
211
  claims, including the perpetual Apache-2.0 grant on every tagged release you
77
212
  receive.
78
213
 
79
- ## Quickstart
80
-
81
- ```bash
82
- npm install --save-dev @mnstry/atelier@0.2.0-alpha.1
83
-
84
- npx atelier init --fixture=sample-workspace --target ./sample
85
- npx atelier graph --project ./sample/atelier.project.json
86
- npx atelier project --project ./sample/atelier.project.json
87
- npx atelier readiness --project ./sample/atelier.project.json
88
- MNSTRY_ATELIER_ACTOR=owner npx atelier boundary check --project ./sample/atelier.project.json
89
- npx atelier dev --project ./sample/atelier.project.json
90
- ```
91
-
92
- `npx` here runs the binary already installed in `./node_modules/.bin`. Always
93
- install first, and keep the `@mnstry/` scope — the unscoped name `atelier`
94
- belongs to an unrelated third-party package.
95
-
96
- `init` scaffolds a fictional sample workspace, `graph` builds the knowledge
97
- graph from front matter and sidecars, `project` generates the local review
98
- surface, `dev` serves it on loopback only. From there:
99
-
100
- ```js
101
- import { validateAtelierExportDryRun } from '@mnstry/atelier'
102
-
103
- const report = validateAtelierExportDryRun(exportDocument)
104
- console.log(report.accepted, report.importable, report.errors)
105
- ```
106
-
107
- Real projects start from the `private-domain`, `shared-project`, or
108
- `distribution` templates instead of the sample fixture.
109
-
110
- ## What this package does
111
-
112
- - Initializes neutral local Atelier projects.
113
- - Builds a front-matter and sidecar-led knowledge graph; a `.kg.json` sidecar
114
- enrolls any file — Markdown, JSON, YAML, CSV, media — without the kit ever
115
- parsing the foreign format.
116
- - Generates and serves a local GUI projection over a loopback-only sidecar.
117
- - Produces agent-harness context and capability envelopes, and ships neutral
118
- Codex and Claude skill wrappers for readiness review work.
119
- - Records proposal metadata without browser apply/write endpoints.
120
- - Enforces the local source `audience` and runtime `visibility` boundary, and
121
- rejects unresolved, disguised, or non-public-projectable source references.
122
- - Enforces Repo Boundary Guard V1 for private domain and shared project
123
- repos: strict policies fail closed when private or sensitive source is
124
- placed in a shared repo, when protected local files are staged, or when
125
- private-domain material appears in shared work without a `git.promote`
126
- disclosure record.
127
- - Validates `atelier-export@v1` JSON against the published schema and
128
- produces deterministic dry-run reports with `accepted`, `importable`, and
129
- `worstOperationStatus`.
130
- - Ships the bundled `mnstry-readiness-pack@v1` with twelve claim-first
131
- readiness protocols, extensible through validated extension packs.
132
- - Writes and checks `atelier.lock.json`, and applies branch-based,
133
- review-first upgrades that refuse dirty repos and never silently overwrite
134
- authored content.
135
- - Checks first-party source, templates, and examples for forbidden
136
- non-localhost egress — a fail-closed discipline gate over this repo's own
137
- code, not a runtime sandbox.
138
-
139
- ## What this package does not do
214
+ ## What this package will not do
140
215
 
141
216
  - It does not write to a MNSTRY runtime database.
142
217
  - It does not import, provision, publish, or send anything.
@@ -157,16 +232,19 @@ runtime exposure and accepts only `private`, `shared`, `platform`, or
157
232
  `public`. A public export referencing a source whose audience is not public
158
233
  is refused — that check is fixture-pinned and mutation-tested.
159
234
 
160
- ## Build a branded distribution
235
+ ## Build your own tool on it
161
236
 
162
- The Atelier is designed to be white-labeled. A distribution wraps the CLI
163
- under its own name, contributes a validated extension pack (branded
164
- protocols, terms, templates), and themes the projection — while the root
165
- contracts, guards, and conformance stay canonical underneath. Start by
166
- copying the worked example:
237
+ The Atelier is designed to be built on, under your name — including
238
+ commercially. A distribution wraps the CLI under its own command,
239
+ contributes a validated extension pack (branded protocols, terms,
240
+ templates), and themes the projection, while the root contracts, guards,
241
+ and conformance stay canonical underneath. Apache-2.0 makes commercial use
242
+ a right, not a favor; the trademark policy keeps the name ours and the
243
+ code yours. Start by copying the worked example:
167
244
 
168
245
  - `examples/loomworks-studio` — a complete fictional distribution: branded
169
- bin, extension pack, themed workspace template.
246
+ bin, extension pack, themed workspace template. It lives in this
247
+ repository and deliberately never ships in the npm tarball.
170
248
  - `docs/distributions.md` — the contract a distribution must honor.
171
249
  - `TRADEMARKS.md` — naming rules; Apache-2.0 grants code rights, not brand
172
250
  rights. Every distribution carries "powered by MNSTRY Atelier" attribution,
@@ -174,14 +252,15 @@ copying the worked example:
174
252
 
175
253
  ## The MNSTRY relationship
176
254
 
177
- The Atelier is the front porch, not the house. Conformance — is this document
178
- valid against the published contracts? — is public, offline, and free,
179
- forever. Admission — will MNSTRY's governed runtime accept it for delivery to
180
- clients? — is a separate, opt-in step: a signed attestation issued by MNSTRY
181
- against criteria this package publishes (`docs/attestation.md`). You can
182
- build on the Atelier without ever talking to MNSTRY. If you want your work to
183
- run on MNSTRY runtimes, the path is admission, and the rejection message is
184
- part of the contract.
255
+ The Atelier export format is MNSTRY's format, offered openly. Conformance —
256
+ is this document valid against the published contracts? — is public,
257
+ offline, and free, forever. Admission — will MNSTRY's governed runtime
258
+ accept it for delivery to clients? — is a separate, opt-in step: a signed
259
+ attestation issued by MNSTRY against criteria this package publishes
260
+ (`docs/attestation.md`). The criteria are public; the checker is private;
261
+ the rejection message is part of the contract. You can build on the Atelier
262
+ without ever talking to MNSTRY, and a document MNSTRY declines can still be
263
+ fully conformant.
185
264
 
186
265
  ## Feedback and announcements
187
266
 
@@ -200,14 +279,14 @@ passes silently on missing protection. Expect this, after `npm install`:
200
279
 
201
280
  ```bash
202
281
  npm install
203
- npm test # 509 tests: 508 pass, 1 fail — the denylist check, by design
282
+ npm test # 510 tests: 509 pass, 1 fail — the denylist check, by design
204
283
  ```
205
284
 
206
285
  To acknowledge the missing file and run the rest, which turns that failure
207
286
  into a recorded skip:
208
287
 
209
288
  ```bash
210
- ATELIER_ALLOW_MISSING_DENYLIST=1 npm test # 508 pass, 0 fail, 1 skipped
289
+ ATELIER_ALLOW_MISSING_DENYLIST=1 npm test # 509 pass, 0 fail, 1 skipped
211
290
  ```
212
291
 
213
292
  ## Command reference
package/docs/design.md ADDED
@@ -0,0 +1,154 @@
1
+ # The design
2
+
3
+ The Atelier makes a repository mean something. Files declare what they are,
4
+ who they are for, and how they relate — and machinery enforces it.
5
+
6
+ **Git is the database. The ontology is the schema. The validators are the
7
+ constraints. The runtime is local.**
8
+
9
+ This page states the design in five movements. Each one is a general
10
+ primitive, grounded in a shipped mechanism, ending with the command that
11
+ proves it — because a design document that cannot be checked is marketing.
12
+
13
+ ## 1. A repository with an ontology
14
+
15
+ A small structured header turns a file into a node: front matter on
16
+ Markdown, or a `.kg.json` sidecar beside any other format — JSON, YAML,
17
+ CSV, media, anything — which the kit enrolls without ever parsing the
18
+ foreign format. The header declares identity (`kg.id`), type, status,
19
+ audience, and relations to other nodes.
20
+
21
+ The graph builder compiles the repository into a knowledge graph,
22
+ deterministically: same tree in, same graph out, and `--check` mode fails
23
+ when a generated graph has drifted from its sources. There is no import
24
+ step, no database, and no export lock-in. The repository is the store. Git
25
+ is the history, the review process, and the read boundary you already
26
+ trust — an audience label guides projection, but repository access is what
27
+ actually hides a file.
28
+
29
+ ```bash
30
+ atelier graph --project ./atelier.project.json
31
+ atelier graph --check --project ./atelier.project.json
32
+ ```
33
+
34
+ ## 2. Rules that refuse
35
+
36
+ The ontology is not documentation. It is the enforcement mechanism.
37
+
38
+ Eighteen JSON Schema contracts define the vocabulary — exports, project
39
+ configuration, boundary policy, sidecars, locks, migrations, readiness,
40
+ attestation — and fail-closed validators enforce it. The load-bearing
41
+ separation is `audience` versus `visibility`: audience is local readership
42
+ (`public`, `team`, `operator`, `staff`, `private`, `sensitive`), visibility
43
+ is runtime authority (`private`, `shared`, `platform`, `public`), and the
44
+ validators reject every crossing — a local audience word in a visibility
45
+ field, a `visibility` key on a source node, and above all a public export
46
+ that resolves any source reference to a non-public source. That last check
47
+ is fixture-pinned and mutation-tested: deleting its enforcement makes tests
48
+ fail, not documentation drift.
49
+
50
+ The contracts sit under a stability epoch. Every change is checked against
51
+ the baseline tag's validators, schema widening outside namespaced `ext`
52
+ containers is refused by a schema-vs-schema differ, and a breaking change
53
+ requires a new contract version with a recorded migration. Twelve bundled
54
+ claim-first readiness protocols check a workspace against published
55
+ criteria and produce proposed claims — never runtime mutations.
56
+
57
+ ```bash
58
+ atelier dry-run ./atelier-export.json
59
+ atelier contract check
60
+ npm run contract:compat
61
+ ```
62
+
63
+ ## 3. Collaboration as governed disclosure
64
+
65
+ Repositories have roles. A private-domain repo holds one person's source
66
+ material; a shared-project repo holds what a team may read. The boundary
67
+ guard enforces the difference and fails closed: private or sensitive
68
+ source placed in a shared repo blocks, protected local files staged for
69
+ commit block, and private-domain material appearing in shared work without
70
+ a recorded disclosure blocks.
71
+
72
+ Crossing the boundary is an event with a record: `atelier promote` writes a
73
+ `git.promote` disclosure event, reviewable like any other commit.
74
+ Disclosure is a commit, not an accident.
75
+
76
+ Change to the machinery itself is governed the same way. The workspace
77
+ lockfile records exactly which package version, contracts, extension
78
+ packs, and migrations a workspace runs; upgrades are branch-based,
79
+ review-first, refuse dirty repos, and never silently overwrite authored
80
+ content.
81
+
82
+ ```bash
83
+ atelier boundary check --project ./atelier.project.json
84
+ atelier boundary check --staged --project ./atelier.project.json
85
+ atelier promote --source-repo <private-repo> --target-repo <shared-repo> --kg-id <node>
86
+ atelier lock check --project ./atelier.project.json
87
+ ```
88
+
89
+ ## 4. A local runtime for humans and for agents
90
+
91
+ The same governed workspace projects two ways.
92
+
93
+ For humans: a generated review surface, served by a sidecar that binds to
94
+ loopback only. The served pages carry a policy that authorizes no external
95
+ origin, and the only network client in the package refuses non-loopback
96
+ URLs.
97
+
98
+ For agents: session-bound context and capability envelopes that hand an
99
+ agent harness a governed view of the workspace — what exists, what it may
100
+ look at, what it may propose. Proposals are recorded as metadata; there
101
+ are no browser apply endpoints and no write authority to grant. Context
102
+ without authority. Neutral Claude and Codex skill wrappers ship in the
103
+ package, so a harness can do readiness review work against the workspace
104
+ without a single line of custom glue.
105
+
106
+ This is the honest answer to the question every team has right now: how do
107
+ you put an agent inside private material safely? Not by trusting the
108
+ agent — by projecting a bounded view and making writing impossible.
109
+
110
+ ```bash
111
+ atelier dev --project ./atelier.project.json
112
+ atelier context flow --project ./atelier.project.json
113
+ ```
114
+
115
+ ## 5. A platform for your own tool
116
+
117
+ The Atelier is designed to be built on, under your name, including
118
+ commercially.
119
+
120
+ A distribution wraps the CLI under its own command, contributes a
121
+ validated extension pack — branded protocols, terms, templates — and
122
+ themes the projection, while the root contracts, guards, and conformance
123
+ stay canonical underneath. The repository carries a complete fictional
124
+ reference distribution (`examples/loomworks-studio`) small enough to read
125
+ in one sitting: a wrapper bin, a pack, a themed workspace.
126
+
127
+ Apache-2.0 makes commercial use a right, not a favor. The trademark policy
128
+ keeps the name ours and the code yours: every distribution carries
129
+ "powered by MNSTRY Atelier" attribution, and the check is a command, not a
130
+ request. Contributions run inbound-equals-outbound with a DCO sign-off and
131
+ no CLA — nobody, including MNSTRY, holds rights over your contribution
132
+ that you do not also hold.
133
+
134
+ ```bash
135
+ atelier distribution check --target ./my-distribution
136
+ atelier extension-pack validate --project ./atelier.project.json
137
+ ```
138
+
139
+ ## The first application
140
+
141
+ Methodology authoring is the Atelier's first application, not its ceiling.
142
+ MNSTRY built this to carry its own most demanding case: private
143
+ transformational work, where a leaked document is not a bug but a
144
+ betrayal. That case set the bar — fail-closed boundaries, no telemetry, no
145
+ send path, agents without authority, disclosure as a recorded event.
146
+
147
+ A system trustworthy enough for that is trustworthy enough for whatever
148
+ you govern with it: a research corpus, a client practice, an editorial
149
+ pipeline, a body of work that must outlive the tools that touch it.
150
+
151
+ The claims behind this page are stated precisely, with their known limits,
152
+ in the README's "Claims you can check" — each with the command that proves
153
+ it. `docs/continuity.md` records the distribution commitments, including
154
+ the perpetual Apache-2.0 grant on every tagged release you receive.
package/docs/install.md CHANGED
@@ -25,19 +25,19 @@ The registry is the distribution channel of record, as `docs/continuity.md`
25
25
  commits:
26
26
 
27
27
  ```bash
28
- npm install --save-dev @mnstry/atelier@0.2.0-alpha.1
28
+ npm install --save-dev @mnstry/atelier@0.2.0-alpha.2
29
29
  ```
30
30
 
31
31
  Installing from the matching Git tag resolves to the same reviewed commit:
32
32
 
33
33
  ```bash
34
- npm install --save-dev "git+https://github.com/MNSTRY/atelier.git#v0.2.0-alpha.1"
34
+ npm install --save-dev "git+https://github.com/MNSTRY/atelier.git#v0.2.0-alpha.2"
35
35
  ```
36
36
 
37
37
  Or over SSH:
38
38
 
39
39
  ```bash
40
- npm install --save-dev "git+ssh://git@github.com/MNSTRY/atelier.git#v0.2.0-alpha.1"
40
+ npm install --save-dev "git+ssh://git@github.com/MNSTRY/atelier.git#v0.2.0-alpha.2"
41
41
  ```
42
42
 
43
43
  Keep the `@mnstry/` scope. The unscoped name `atelier` on npm belongs to an
package/docs/upgrade.md CHANGED
@@ -5,6 +5,16 @@ workspace between Atelier package releases. The flow is local-only: it does not
5
5
  provision repositories, contact a Git host, mutate the MNSTRY runtime, or write
6
6
  through a browser view.
7
7
 
8
+ ## Upgrading to 0.2.0-alpha.2
9
+
10
+ No contract changes and no runtime behaviour changes: documents valid against
11
+ `0.2.0-alpha.0` remain valid, and `npm run contract:compat` is clean against
12
+ the same epoch baseline. Upgrading is a dependency bump.
13
+
14
+ Note on version numbering: `0.2.0` was published in error and unpublished the
15
+ same day. If a lockfile anywhere pins `0.2.0`, repin it to `0.2.0-alpha.2` —
16
+ that number is permanently retired on npm and will not resolve.
17
+
8
18
  ## Upgrading to 0.2.0-alpha.1
9
19
 
10
20
  No contract changes and no authored-content changes: documents valid against
@@ -12,7 +22,7 @@ No contract changes and no authored-content changes: documents valid against
12
22
  the same epoch baseline. Upgrading is a dependency bump.
13
23
 
14
24
  Two things worth knowing. The package is now on the npm registry, so the
15
- install command changes from a Git reference to `@mnstry/atelier@0.2.0-alpha.1`
25
+ install command changes from a Git reference to `@mnstry/atelier@0.2.0-alpha.2`
16
26
  — keep the `@mnstry/` scope, since the unscoped name belongs to an unrelated
17
27
  package. And a local sidecar that previously exited on a malformed request now
18
28
  answers it, so anything that supervised `atelier dev` through restarts can stop
@@ -62,7 +72,7 @@ For registry installs, pin the exact version and record the resolved version
62
72
  in the lockfile:
63
73
 
64
74
  ```bash
65
- npm install --save-dev @mnstry/atelier@0.2.0-alpha.1
75
+ npm install --save-dev @mnstry/atelier@0.2.0-alpha.2
66
76
  npx atelier lock write --project ./atelier.project.json
67
77
  ```
68
78
 
@@ -70,7 +80,7 @@ For Git installs, pin the release tag rather than a branch, so the lock file
70
80
  records exactly what was reviewed:
71
81
 
72
82
  ```bash
73
- npm install --save-dev "git+https://github.com/MNSTRY/atelier.git#v0.2.0-alpha.1"
83
+ npm install --save-dev "git+https://github.com/MNSTRY/atelier.git#v0.2.0-alpha.2"
74
84
  npx atelier lock write --project ./atelier.project.json
75
85
  ```
76
86
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@mnstry/atelier",
3
- "version": "0.2.0-alpha.1",
3
+ "version": "0.2.0-alpha.2",
4
4
  "private": false,
5
5
  "description": "Local-first MNSTRY Atelier workspace for agentic authoring, graph projection, and dry-run runtime readiness.",
6
6
  "type": "module",