@synapsor/runner 0.1.0-alpha.15 → 0.1.0-alpha.17
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 +56 -6
- package/README.md +126 -3
- package/dist/cli.d.ts.map +1 -1
- package/dist/runner.mjs +787 -51
- package/docs/README.md +3 -3
- package/docs/app-owned-executors.md +7 -0
- package/docs/current-scope.md +6 -0
- package/docs/getting-started-own-database.md +42 -14
- package/docs/handler-helper.md +13 -6
- package/docs/local-mode.md +6 -0
- package/docs/release-notes.md +90 -7
- package/docs/release-policy.md +53 -13
- package/docs/result-envelope-v2.md +5 -2
- package/docs/rfcs/002-app-owned-handler-helper.md +1 -1
- package/docs/rfcs/003-integrator-feedback-teardown.md +1 -1
- package/docs/writeback-executors.md +13 -0
- package/examples/app-owned-writeback/README.md +7 -0
- package/examples/app-owned-writeback/command-handler.mjs +9 -0
- package/examples/app-owned-writeback/node-fastify-handler.mjs +9 -0
- package/examples/app-owned-writeback/python-fastapi-handler.py +9 -0
- package/examples/mcp-postgres-billing-app-handler/README.md +7 -0
- package/examples/mcp-postgres-billing-app-handler/app-handler.mjs +7 -9
- package/package.json +1 -1
- package/schemas/onboarding-selection.v1.schema.json +7 -0
- package/schemas/synapsor.runner.schema.json +3 -0
package/CHANGELOG.md
CHANGED
|
@@ -2,13 +2,56 @@
|
|
|
2
2
|
|
|
3
3
|
## Unreleased
|
|
4
4
|
|
|
5
|
+
No unreleased changes yet.
|
|
6
|
+
|
|
7
|
+
## 0.1.0-alpha.17
|
|
8
|
+
|
|
9
|
+
### Added
|
|
10
|
+
|
|
11
|
+
- Prompt-free onboarding for `onboard db` / `init` through `--yes`,
|
|
12
|
+
`--non-interactive`, and `--answers <file.json>`.
|
|
13
|
+
- Friendly scripted onboarding flags: `--tenant-column`, `--id-arg`, `--patch
|
|
14
|
+
column=fixed:value|arg:name`, `--patch-bounds`, `--status-guards`,
|
|
15
|
+
`--read-description`, `--read-returns-hint`, `--handler-output`, and
|
|
16
|
+
`--emit-handler`.
|
|
17
|
+
- Answers-file onboarding can emit the same artifacts as the wizard: reviewed
|
|
18
|
+
config, `.env.example`, MCP snippets, and optional handler template.
|
|
19
|
+
- Guided onboarding now shows a final "what I am about to write" preview where
|
|
20
|
+
users can revise visible fields or capability names before files are written.
|
|
21
|
+
- README and runner README now include a short "How An External Handler Works"
|
|
22
|
+
explanation directly after the writeback rule.
|
|
23
|
+
- `events webhook` / `events push` can POST local proposal/writeback lifecycle
|
|
24
|
+
events to a local/dev/staging HTTP endpoint for review UIs or notifications.
|
|
25
|
+
|
|
26
|
+
### Changed
|
|
27
|
+
|
|
28
|
+
- When `--namespace` is omitted, generated capability names derive a namespace
|
|
29
|
+
from the selected table instead of defaulting to `source.*`.
|
|
30
|
+
- App-owned `http_handler` and `command_handler` generated configs mark the
|
|
31
|
+
Runner source as `read_only: true` when no writer env is supplied. These
|
|
32
|
+
configs now validate without a `WRITEBACK_DISABLED` warning.
|
|
33
|
+
- Direct SQL review-mode proposal capabilities still require `write_url_env`
|
|
34
|
+
readiness; missing writer env remains visible as `WRITEBACK_DISABLED`.
|
|
35
|
+
- Published docs/examples no longer contain install-looking
|
|
36
|
+
`@synapsor/handler` imports. The app-owned example uses the bundled
|
|
37
|
+
`synapsor-handler.mjs` shim directly.
|
|
38
|
+
|
|
39
|
+
## 0.1.0-alpha.16
|
|
40
|
+
|
|
5
41
|
### Added
|
|
6
42
|
|
|
7
|
-
- `
|
|
8
|
-
|
|
9
|
-
|
|
43
|
+
- `synapsor-runner up` for first-session review-mode bring-up. It validates
|
|
44
|
+
the local config/store, checks active store leases, summarizes model-facing
|
|
45
|
+
tools, explains direct SQL versus app-owned executor writeback, and prints
|
|
46
|
+
the next smoke, approval, apply, replay, UI, and doctor commands.
|
|
47
|
+
- Guided app-owned executor setup can now write a starter handler template
|
|
48
|
+
during `init --wizard` / `start --from-env ... --mode review`.
|
|
49
|
+
- `result_format: 2` for a stable MCP result envelope with `ok`, `summary`,
|
|
50
|
+
`data`, `proposal`, `error`, `evidence`, `source_database_changed`, and
|
|
51
|
+
`_meta.canonical_capability`.
|
|
10
52
|
- `--result-format v1|v2` for `mcp serve`, `mcp serve --transport
|
|
11
|
-
streamable-http`, `mcp serve-streamable-http`, and the legacy JSON-RPC
|
|
53
|
+
streamable-http`, `mcp serve-streamable-http`, and the legacy JSON-RPC
|
|
54
|
+
bridge.
|
|
12
55
|
- Capability config fields `description`, per-argument `description`, and
|
|
13
56
|
`returns_hint`; these are surfaced in MCP tool metadata.
|
|
14
57
|
- `tools list` as a first-class alias for `tools preview`, including
|
|
@@ -16,16 +59,23 @@
|
|
|
16
59
|
- `mcp client-config --include-instructions` for Claude/Cursor/OpenAI-style
|
|
17
60
|
client snippets with propose-first agent guidance.
|
|
18
61
|
- `schemas/synapsor.runner.schema.json` for editor validation.
|
|
19
|
-
- `docs/capability-authoring.md
|
|
20
|
-
|
|
62
|
+
- `docs/capability-authoring.md`, `docs/result-envelope-v2.md`, and RFC source
|
|
63
|
+
docs under `docs/rfcs/`.
|
|
21
64
|
|
|
22
65
|
### Changed
|
|
23
66
|
|
|
67
|
+
- Handler templates, template CLI output, app-owned writeback docs, and
|
|
68
|
+
examples now carry the explicit handler security warning: app handlers own the
|
|
69
|
+
final business write and must re-check tenant/scope, conflict guards,
|
|
70
|
+
idempotency, business action, transactions, and safe receipts.
|
|
24
71
|
- OpenAI-safe aliases include the canonical Synapsor capability name in
|
|
25
72
|
descriptions/metadata so model-visible aliases can still be audited against
|
|
26
73
|
dotted capability names.
|
|
27
74
|
- v2 MCP errors redact raw driver/infra strings and map failures to a small
|
|
28
75
|
safe error-code enum.
|
|
76
|
+
- Release policy now keeps the stable channel gated on `up`, review-mode wizard
|
|
77
|
+
verification, handler warning coverage, clean npm install checks, and at
|
|
78
|
+
least one external developer following the README without source reading.
|
|
29
79
|
|
|
30
80
|
### Compatibility
|
|
31
81
|
|
package/README.md
CHANGED
|
@@ -44,6 +44,25 @@ One-row update to an existing row: Runner can do guarded direct writeback.
|
|
|
44
44
|
Anything else, such as inserting a row, touching two tables, or emitting an
|
|
45
45
|
event: your app-owned executor does it after approval.
|
|
46
46
|
|
|
47
|
+
## How An External Handler Works
|
|
48
|
+
|
|
49
|
+
Some changes are too rich for Runner's one-row writeback: insert a credit row,
|
|
50
|
+
touch two tables, or emit an event. For those, you run a small endpoint. The
|
|
51
|
+
flow is:
|
|
52
|
+
|
|
53
|
+
```text
|
|
54
|
+
agent proposes
|
|
55
|
+
-> human approves outside MCP
|
|
56
|
+
-> Runner POSTs the approved change to your endpoint
|
|
57
|
+
-> your code writes it in its own transaction and returns a receipt
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
The model never touches this code. You are the last line of defense: Runner
|
|
61
|
+
hands you the tenant, expected row version, and idempotency key, and your
|
|
62
|
+
handler must re-check all three. Skipping those checks reintroduces
|
|
63
|
+
cross-tenant writes, lost updates, or duplicate writes. Start from
|
|
64
|
+
`synapsor-runner handler template ...` instead of hand-rolling the safety checks.
|
|
65
|
+
|
|
47
66
|
## Deliberate Limits
|
|
48
67
|
|
|
49
68
|
Runner does not expose raw SQL, write credentials, approval tools, or commit
|
|
@@ -129,6 +148,16 @@ Your own staging DB -> export DATABASE_URL=... then run the inspect command b
|
|
|
129
148
|
MCP risk review -> npx -y -p @synapsor/runner@alpha synapsor-runner audit --example dangerous-db-mcp
|
|
130
149
|
```
|
|
131
150
|
|
|
151
|
+
For your own database, do this before wiring Claude, Cursor, OpenAI Agents SDK,
|
|
152
|
+
or another MCP client:
|
|
153
|
+
|
|
154
|
+
```text
|
|
155
|
+
1. Generate the config with start/init/onboard.
|
|
156
|
+
2. Run tools preview to confirm no raw SQL or write credentials are exposed.
|
|
157
|
+
3. Run smoke call against one generated inspect tool.
|
|
158
|
+
4. Only then run up --serve or mcp serve.
|
|
159
|
+
```
|
|
160
|
+
|
|
132
161
|
`synapsor-runner` is the public command for this OSS runner. `synapsor` is
|
|
133
162
|
reserved for the Synapsor Cloud CLI.
|
|
134
163
|
|
|
@@ -223,10 +252,60 @@ The end-to-end shape is:
|
|
|
223
252
|
The generated config is just the safety contract. A small reviewed version
|
|
224
253
|
looks like this:
|
|
225
254
|
|
|
255
|
+
Bring the generated review-mode workspace up with one command:
|
|
256
|
+
|
|
257
|
+
```bash
|
|
258
|
+
npx -y -p @synapsor/runner@alpha synapsor-runner up \
|
|
259
|
+
--serve \
|
|
260
|
+
--config ./synapsor.runner.json \
|
|
261
|
+
--store ./.synapsor/local.db
|
|
262
|
+
```
|
|
263
|
+
|
|
264
|
+
`up` validates the config/store, summarizes model-facing tools, shows whether
|
|
265
|
+
proposal tools use direct SQL writeback or app-owned executors, checks active
|
|
266
|
+
store leases, and prints the next smoke, approve, apply, replay, UI, and doctor
|
|
267
|
+
commands. By default, `up` is guidance-only. Use `up --serve` to start the
|
|
268
|
+
standard Streamable HTTP MCP server after the checklist; use `--dry-run` to
|
|
269
|
+
rehearse without starting it. For app-owned executor configs, add
|
|
270
|
+
`--with-handler` to run the handler doctor before serving.
|
|
271
|
+
|
|
272
|
+
For CI, shell scripts, or an LLM driving the setup, use the prompt-free path:
|
|
273
|
+
|
|
274
|
+
```bash
|
|
275
|
+
npx -y -p @synapsor/runner@alpha synapsor-runner onboard db \
|
|
276
|
+
--from-env DATABASE_URL \
|
|
277
|
+
--schema public \
|
|
278
|
+
--table invoices \
|
|
279
|
+
--mode review \
|
|
280
|
+
--tenant-column tenant_id \
|
|
281
|
+
--primary-key id \
|
|
282
|
+
--conflict-column updated_at \
|
|
283
|
+
--namespace billing \
|
|
284
|
+
--object-name invoice \
|
|
285
|
+
--id-arg invoice_id \
|
|
286
|
+
--visible-columns id,tenant_id,late_fee_cents,waiver_reason,updated_at \
|
|
287
|
+
--patch late_fee_cents=fixed:0,waiver_reason=arg:reason \
|
|
288
|
+
--patch-bounds late_fee_cents=0:5500 \
|
|
289
|
+
--write-url-env SYNAPSOR_DATABASE_WRITE_URL \
|
|
290
|
+
--yes
|
|
291
|
+
```
|
|
292
|
+
|
|
293
|
+
If `--namespace` is omitted, Runner derives a namespace from the table name
|
|
294
|
+
instead of creating `source.*` tools. Use `--read-tool` and `--proposal-tool`
|
|
295
|
+
when you need exact model-facing names.
|
|
296
|
+
|
|
297
|
+
For app-owned writeback, replace `--write-url-env ...` with
|
|
298
|
+
`--writeback http_handler --handler-url-env APP_WRITEBACK_URL --emit-handler`.
|
|
299
|
+
Runner marks that source as read-only unless you explicitly pass a writer env,
|
|
300
|
+
so `config validate` does not warn that direct SQL writeback is disabled.
|
|
301
|
+
You can also pass `--answers ./answers.json --yes` for a fully declarative
|
|
302
|
+
setup file.
|
|
303
|
+
|
|
226
304
|
```json
|
|
227
305
|
{
|
|
228
306
|
"version": 1,
|
|
229
307
|
"mode": "review",
|
|
308
|
+
"result_format": 2,
|
|
230
309
|
"sources": {
|
|
231
310
|
"app_postgres": {
|
|
232
311
|
"engine": "postgres",
|
|
@@ -300,7 +379,8 @@ trusted context -> capability -> MCP tool
|
|
|
300
379
|
|
|
301
380
|
It asks which table/view backs the context, which tenant/scope column and
|
|
302
381
|
backend session env vars are trusted, which fields are visible, and what
|
|
303
|
-
semantic capability name to expose.
|
|
382
|
+
semantic capability name to expose. Before writing files, it shows a final
|
|
383
|
+
preview and lets you revise visible fields or capability names.
|
|
304
384
|
|
|
305
385
|
```bash
|
|
306
386
|
npx -y -p @synapsor/runner@alpha synapsor-runner init \
|
|
@@ -369,6 +449,17 @@ synapsor-runner mcp serve-streamable-http \
|
|
|
369
449
|
--alias-mode openai
|
|
370
450
|
```
|
|
371
451
|
|
|
452
|
+
You can also start the same review-mode server through the safer startup
|
|
453
|
+
checklist:
|
|
454
|
+
|
|
455
|
+
```bash
|
|
456
|
+
synapsor-runner up --serve \
|
|
457
|
+
--config ./synapsor.runner.json \
|
|
458
|
+
--store ./.synapsor/local.db \
|
|
459
|
+
--auth-token-env SYNAPSOR_RUNNER_HTTP_TOKEN \
|
|
460
|
+
--alias-mode openai
|
|
461
|
+
```
|
|
462
|
+
|
|
372
463
|
Equivalent unified command:
|
|
373
464
|
|
|
374
465
|
```bash
|
|
@@ -457,6 +548,22 @@ For a longer local session, you can install the alpha package explicitly:
|
|
|
457
548
|
npm install -g @synapsor/runner@alpha
|
|
458
549
|
```
|
|
459
550
|
|
|
551
|
+
## Stable Compatibility Promise
|
|
552
|
+
|
|
553
|
+
Until the first stable `0.1.0` tag is published, install with `@alpha` or an
|
|
554
|
+
exact alpha version. Do not treat the untagged `latest` dist-tag as stable yet.
|
|
555
|
+
|
|
556
|
+
After `0.1.0` is promoted to `latest`, Synapsor Runner will keep the documented
|
|
557
|
+
`synapsor-runner` binary, `synapsor.runner.json` schema version `1`, result
|
|
558
|
+
envelope v2, stdio MCP, Streamable HTTP MCP, MCP client snippets, proposal/
|
|
559
|
+
approval/writeback inspection commands, direct SQL writeback contract, and
|
|
560
|
+
app-owned executor contract compatible through the `0.1.x` line unless a
|
|
561
|
+
release note marks a deprecation first.
|
|
562
|
+
|
|
563
|
+
Stable does not mean production SLA, hosted Cloud features, compliance
|
|
564
|
+
certification, physical Postgres/MySQL branching, generic SQL writeback, or
|
|
565
|
+
support for undocumented local SQLite internals.
|
|
566
|
+
|
|
460
567
|
## Runtime Flow
|
|
461
568
|
|
|
462
569
|
The local runner keeps the model-facing tool call separate from approval and
|
|
@@ -541,6 +648,8 @@ relying on `latest`:
|
|
|
541
648
|
|
|
542
649
|
```bash
|
|
543
650
|
synapsor-runner activity search --tenant acme --object invoice:INV-3001
|
|
651
|
+
synapsor-runner events tail --store ./.synapsor/local.db
|
|
652
|
+
synapsor-runner events webhook --url http://127.0.0.1:8788/synapsor/events --kind proposal_created --store ./.synapsor/local.db
|
|
544
653
|
synapsor-runner proposals list --tenant acme --object invoice:INV-3001 --status approved
|
|
545
654
|
synapsor-runner evidence show ev_...
|
|
546
655
|
synapsor-runner query-audit list --evidence ev_...
|
|
@@ -573,11 +682,17 @@ Inspect or compact the local ledger:
|
|
|
573
682
|
|
|
574
683
|
```bash
|
|
575
684
|
synapsor-runner store stats --store ./.synapsor/local.db
|
|
685
|
+
synapsor-runner events tail --store ./.synapsor/local.db --follow
|
|
686
|
+
synapsor-runner events webhook --url-env SYNAPSOR_EVENT_WEBHOOK_URL --auth-token-env SYNAPSOR_EVENT_WEBHOOK_TOKEN --follow --store ./.synapsor/local.db
|
|
576
687
|
synapsor-runner store vacuum --store ./.synapsor/local.db
|
|
577
688
|
synapsor-runner store prune --store ./.synapsor/local.db --older-than 30d --dry-run
|
|
578
689
|
synapsor-runner store reset --store ./.synapsor/local.db --yes
|
|
579
690
|
```
|
|
580
691
|
|
|
692
|
+
`events webhook` is a local/dev/staging convenience for review UIs, Slack
|
|
693
|
+
bridges, or app-local notifications. It POSTs one redacted local event envelope
|
|
694
|
+
per lifecycle event; it is not a hosted central ledger.
|
|
695
|
+
|
|
581
696
|
This is local indexed search for local/dev/staging usage. It is not external
|
|
582
697
|
database time travel, not cross-runner search, and not hosted compliance
|
|
583
698
|
retention.
|
|
@@ -588,10 +703,18 @@ Use direct guarded DB writeback for simple local/staging single-row updates. If
|
|
|
588
703
|
your application service already owns business writes, configure an
|
|
589
704
|
`http_handler` or `command_handler` executor. Approval still happens outside
|
|
590
705
|
MCP, and the handler returns an applied/conflict/failed receipt for replay.
|
|
706
|
+
|
|
707
|
+
> **Important:** your app handler owns the final business write. Runner creates
|
|
708
|
+
> the proposal and calls your handler only after approval, but your handler must
|
|
709
|
+
> still enforce tenant/scope checks, expected-version or conflict guards,
|
|
710
|
+
> idempotency keys, allowed business actions, transaction/rollback, and safe
|
|
711
|
+
> error receipts. If you skip those checks, you can reintroduce cross-tenant
|
|
712
|
+
> writes, lost updates, or duplicate writes. Keep handler credentials out of MCP.
|
|
713
|
+
|
|
591
714
|
Starter handlers are included under `examples/app-owned-writeback`.
|
|
592
715
|
The packaged app-owned billing example also includes a bundled
|
|
593
|
-
`synapsor-handler.mjs` helper shim
|
|
594
|
-
|
|
716
|
+
`synapsor-handler.mjs` helper shim. There is no separate handler package to
|
|
717
|
+
install.
|
|
595
718
|
You can also generate a starter handler directly:
|
|
596
719
|
|
|
597
720
|
```bash
|
package/dist/cli.d.ts.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":";AAYA,OAAO,EAAqG,KAAK,WAAW,EAA2F,MAAM,6BAA6B,CAAC;AAmB3P,OAAO,EAA6G,KAAK,YAAY,EAAwB,MAAM,2BAA2B,CAAC;AAC/L,OAAO,EAOL,KAAK,gBAAgB,EAEtB,MAAM,mCAAmC,CAAC;
|
|
1
|
+
{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":";AAYA,OAAO,EAAqG,KAAK,WAAW,EAA2F,MAAM,6BAA6B,CAAC;AAmB3P,OAAO,EAA6G,KAAK,YAAY,EAAwB,MAAM,2BAA2B,CAAC;AAC/L,OAAO,EAOL,KAAK,gBAAgB,EAEtB,MAAM,mCAAmC,CAAC;AA4U3C,wBAAsB,IAAI,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,MAAM,CAAC,CAmD1D;AA+DD,KAAK,SAAS,GAAG,CAAC,QAAQ,EAAE,MAAM,EAAE,YAAY,CAAC,EAAE,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC,CAAC;AAE9E,wBAAsB,aAAa,CACjC,IAAI,EAAE,MAAM,EAAE,EACd,OAAO,GAAE;IACP,GAAG,CAAC,EAAE,SAAS,CAAC;IAChB,GAAG,CAAC,EAAE,MAAM,CAAC,UAAU,CAAC;IACxB,UAAU,CAAC,EAAE,gBAAgB,CAAC;IAC9B,OAAO,CAAC,EAAE,WAAW,CAAC;IACtB,MAAM,CAAC,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;CACvC,GACL,OAAO,CAAC,MAAM,CAAC,CA2TjB;AAo7DD,wBAAsB,0BAA0B,CAAC,GAAG,EAAE,YAAY,EAAE,UAAU,EAAE,MAAM,EAAE,GAAG,EAAE,MAAM,CAAC,UAAU,GAAG,OAAO,CAAC,MAAM,CAAC,CAM/H"}
|