slotlock 0.1.0 → 0.1.1
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.
- package/CHANGELOG.md +13 -0
- package/CONTRIBUTING.md +25 -8
- package/README.md +3 -5
- package/package.json +1 -1
- package/slotlock.manifest.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -3,6 +3,19 @@
|
|
|
3
3
|
All notable changes follow [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and semantic
|
|
4
4
|
versioning.
|
|
5
5
|
|
|
6
|
+
## 0.1.1 - 2026-10-22
|
|
7
|
+
|
|
8
|
+
### Changed
|
|
9
|
+
|
|
10
|
+
- The README and the site install Slotlock from npm (`npm install slotlock`), now that 0.1.0 is
|
|
11
|
+
published there, instead of building it from a clone.
|
|
12
|
+
|
|
13
|
+
### Added
|
|
14
|
+
|
|
15
|
+
- Releases are cut from GitHub Actions: "Release a version" prepares the version on a branch, merges
|
|
16
|
+
it once CI passes, and tags it; the tag stages the package on npm for a maintainer's approval and
|
|
17
|
+
publishes the image and the MCP Registry entry.
|
|
18
|
+
|
|
6
19
|
## 0.1.0 - 2026-10-22
|
|
7
20
|
|
|
8
21
|
First public release. Nothing was published before it; the entries below describe the release as
|
package/CONTRIBUTING.md
CHANGED
|
@@ -66,11 +66,28 @@ one maintainer, GOVERNANCE.md's single-maintainer rule applies.
|
|
|
66
66
|
|
|
67
67
|
## Releases
|
|
68
68
|
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
`
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
69
|
+
Add each change's entry under `## Unreleased` in `CHANGELOG.md`, in the pull request that makes it:
|
|
70
|
+
that section becomes the release notes.
|
|
71
|
+
|
|
72
|
+
To release, run **Actions > Release a version** with the version (for example `0.1.1`). It sets the
|
|
73
|
+
version in `package.json`, `package-lock.json`, `server.json` and `slotlock.manifest.json` and dates
|
|
74
|
+
the `## Unreleased` heading (`scripts/prepare-release.sh`) and opens the pull request. GitHub holds
|
|
75
|
+
the checks of a pull request a workflow opens until someone with write access approves them: open it
|
|
76
|
+
and click **Approve workflows to run**. The run then merges it once CI and DCO pass on it, and starts
|
|
77
|
+
`tag-release.yml`, which tags the release commit. The tag starts
|
|
78
|
+
`release.yml` (the suite, then npm and the GitHub release) and `image.yml` (the image, then the MCP
|
|
79
|
+
Registry). npm holds each staged version until a maintainer approves it with two-factor
|
|
80
|
+
authentication (GOVERNANCE.md); the Release run's summary gives the command. A version merged to
|
|
81
|
+
`main` by hand, with its heading dated, is released the same way. After a failed run, run it again
|
|
82
|
+
with the same version: it keeps the release branch the failed run left when that already holds this
|
|
83
|
+
release, so checks approved there still count, replaces it otherwise, and reuses its pull request
|
|
84
|
+
(`scripts/open-release-pr.sh`).
|
|
85
|
+
|
|
86
|
+
GitHub lets a workflow open pull requests only once an admin allows it (Settings > Actions >
|
|
87
|
+
General > Workflow permissions); `scripts/configure-github.sh` sets it, and the run says so when it
|
|
88
|
+
is off.
|
|
89
|
+
|
|
90
|
+
When a run needs a step npm or GitHub keeps for a person (the first npm version, the npm trusted
|
|
91
|
+
publisher, the image's visibility, and the deploy key `tag-release.yml` pushes tags with), the
|
|
92
|
+
failing job names `scripts/bootstrap-release.sh`. One run of it does that step, re-runs the failed
|
|
93
|
+
jobs and waits for them.
|
package/README.md
CHANGED
|
@@ -5,9 +5,6 @@ reservable, answers "when is this free?" from weekly availability rules, and let
|
|
|
5
5
|
double bookings, however many writers race. Agents call it over MCP or A2A; your code calls it as a
|
|
6
6
|
TypeScript library.
|
|
7
7
|
|
|
8
|
-
> **Status: pre-release.** 0.1.0 is not on npm yet. Build it from this repository:
|
|
9
|
-
> `npm ci && npm run build`, then `npm install <path-to>/dist` in your project.
|
|
10
|
-
|
|
11
8
|
## Why it is built for agents
|
|
12
9
|
|
|
13
10
|
- Resources own calendars, not users, and the tenant comes only from the authenticated caller.
|
|
@@ -58,8 +55,9 @@ slotlock hours clear --all # back to SLOTLOCK_AVAILABILITY
|
|
|
58
55
|
|
|
59
56
|
### Without Docker
|
|
60
57
|
|
|
61
|
-
|
|
62
|
-
`node dist/cli.js` (a clone does not
|
|
58
|
+
With Node.js 22.12+ and PostgreSQL 16, run each command as `npx slotlock` after
|
|
59
|
+
`npm install slotlock postgres`, or from a clone, built once, as `node dist/cli.js` (a clone does not
|
|
60
|
+
put `slotlock` on your `PATH`). Use two roles, as Compose does:
|
|
63
61
|
the server connects as a role that owns nothing and cannot bypass row-level security, and `migrate`
|
|
64
62
|
connects as the database owner and grants that role what it needs. `serve` refuses to start as a
|
|
65
63
|
superuser or a `BYPASSRLS` role, which row-level security does not confine.
|
package/package.json
CHANGED
package/slotlock.manifest.json
CHANGED