@orkestrel/scaffold 0.0.78 → 0.0.80
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/dist/bin/main.js +54 -4
- package/dist/bin/main.js.map +1 -1
- package/dist/host/claude/agents/orkestrel.md +4 -4
- package/dist/host/claude/rules/workspace.md +2 -0
- package/dist/host/guides/probe.md +9 -5
- package/dist/host/guides/scaffold.md +30 -12
- package/dist/host/guides/test.md +443 -149
- package/dist/host/manifest.json +7 -7
- package/dist/host/tests/config.test.ts +18 -9
- package/dist/src/core/index.cjs +16 -12
- package/dist/src/core/index.cjs.map +1 -1
- package/dist/src/core/index.d.cts +1 -1
- package/dist/src/core/index.d.ts +1 -1
- package/dist/src/core/index.js +16 -12
- package/dist/src/core/index.js.map +1 -1
- package/package.json +8 -8
|
@@ -52,7 +52,7 @@ so network-controlled descriptions never enter agent instruction context.
|
|
|
52
52
|
| `@orkestrel/budget` | `0.0.11` | L1 | `@orkestrel/contract` `^0.0.17` | |
|
|
53
53
|
| `@orkestrel/codec` | `0.0.4` | L1 | `@orkestrel/contract` `^0.0.17` | |
|
|
54
54
|
| `@orkestrel/console` | `0.0.14` | L2 | `@orkestrel/emitter` `^0.0.10`, `@orkestrel/contract` `^0.0.17` | |
|
|
55
|
-
| `@orkestrel/contract` | `0.0.
|
|
55
|
+
| `@orkestrel/contract` | `0.0.18` | L0 | | |
|
|
56
56
|
| `@orkestrel/csv` | `0.0.8` | L1 | `@orkestrel/contract` `^0.0.17` | |
|
|
57
57
|
| `@orkestrel/database` | `0.0.15` | L2 | `@orkestrel/sqlite` `^0.0.12`, `@orkestrel/emitter` `^0.0.10`, `@orkestrel/contract` `^0.0.17`, `@orkestrel/indexeddb` `^0.0.12` | |
|
|
58
58
|
| `@orkestrel/emitter` | `0.0.10` | L1 | `@orkestrel/contract` `^0.0.17` | |
|
|
@@ -69,7 +69,7 @@ so network-controlled descriptions never enter agent instruction context.
|
|
|
69
69
|
| `@orkestrel/ndjson` | `0.0.10` | L1 | `@orkestrel/contract` `^0.0.17` | |
|
|
70
70
|
| `@orkestrel/ollama` | `0.0.18` | L6 | `@orkestrel/tool` `^0.0.16`, `@orkestrel/agent` `^0.0.24`, `@orkestrel/budget` `^0.0.11`, `@orkestrel/ndjson` `^0.0.10`, `@orkestrel/contract` `^0.0.17` | |
|
|
71
71
|
| `@orkestrel/pool` | `0.0.12` | L2 | `@orkestrel/emitter` `^0.0.10`, `@orkestrel/contract` `^0.0.17` | |
|
|
72
|
-
| `@orkestrel/probe` | `0.0.
|
|
72
|
+
| `@orkestrel/probe` | `0.0.17` | L5 | `@orkestrel/lsp` `^0.0.9`, `@orkestrel/mcp` `^0.0.32`, `@orkestrel/tool` `^0.0.16`, `@orkestrel/queue` `^0.0.14`, `@orkestrel/emitter` `^0.0.10`, `@orkestrel/timeout` `^0.0.11`, `@orkestrel/contract` `^0.0.18` | `oxlint` `^1.86.0`, `vitest` `^4.1.11`, `typescript` `^6.0.3` |
|
|
73
73
|
| `@orkestrel/process` | `0.0.13` | L2 | `@orkestrel/contract` `^0.0.17`, `@orkestrel/emitter` `^0.0.10` | |
|
|
74
74
|
| `@orkestrel/program` | `0.0.14` | L4 | `@orkestrel/contract` `^0.0.17`, `@orkestrel/emitter` `^0.0.10`, `@orkestrel/qualifier` `^0.0.15`, `@orkestrel/rater` `^0.0.15`, `@orkestrel/reason` `^0.0.11` | |
|
|
75
75
|
| `@orkestrel/qualifier` | `0.0.15` | L3 | `@orkestrel/reason` `^0.0.11`, `@orkestrel/emitter` `^0.0.10`, `@orkestrel/contract` `^0.0.17` | |
|
|
@@ -78,7 +78,7 @@ so network-controlled descriptions never enter agent instruction context.
|
|
|
78
78
|
| `@orkestrel/reason` | `0.0.11` | L2 | `@orkestrel/contract` `^0.0.17`, `@orkestrel/emitter` `^0.0.10` | |
|
|
79
79
|
| `@orkestrel/relation` | `0.0.13` | L3 | `@orkestrel/emitter` `^0.0.10`, `@orkestrel/contract` `^0.0.17`, `@orkestrel/database` `^0.0.15` | |
|
|
80
80
|
| `@orkestrel/router` | `0.0.15` | L2 | `@orkestrel/abort` `^0.0.11`, `@orkestrel/emitter` `^0.0.10`, `@orkestrel/contract` `^0.0.17` | |
|
|
81
|
-
| `@orkestrel/scaffold` | `0.0.
|
|
81
|
+
| `@orkestrel/scaffold` | `0.0.78` | L3 | `@orkestrel/console` `^0.0.14`, `@orkestrel/emitter` `^0.0.10`, `@orkestrel/process` `^0.0.13`, `@orkestrel/contract` `^0.0.18`, `@orkestrel/markdown` `^0.0.15`, `@orkestrel/template` `^0.0.8` | |
|
|
82
82
|
| `@orkestrel/sea` | `0.0.17` | L3 | `@orkestrel/contract` `^0.0.17`, `@orkestrel/emitter` `^0.0.10`, `@orkestrel/process` `^0.0.13` | |
|
|
83
83
|
| `@orkestrel/server` | `0.0.20` | L3 | `@orkestrel/abort` `^0.0.11`, `@orkestrel/codec` `^0.0.4`, `@orkestrel/router` `^0.0.15`, `@orkestrel/emitter` `^0.0.10`, `@orkestrel/timeout` `^0.0.11`, `@orkestrel/contract` `^0.0.17` | |
|
|
84
84
|
| `@orkestrel/sqlite` | `0.0.12` | L1 | `@orkestrel/contract` `^0.0.17` | |
|
|
@@ -87,7 +87,7 @@ so network-controlled descriptions never enter agent instruction context.
|
|
|
87
87
|
| `@orkestrel/table` | `0.0.6` | L2 | `@orkestrel/emitter` `^0.0.10`, `@orkestrel/contract` `^0.0.17` | |
|
|
88
88
|
| `@orkestrel/template` | `0.0.8` | L2 | `@orkestrel/emitter` `^0.0.10`, `@orkestrel/contract` `^0.0.17` | |
|
|
89
89
|
| `@orkestrel/terminal` | `0.0.16` | L3 | `@orkestrel/sse` `^0.0.8`, `@orkestrel/form` `^0.0.7`, `@orkestrel/console` `^0.0.14`, `@orkestrel/emitter` `^0.0.10`, `@orkestrel/contract` `^0.0.17`, `@orkestrel/database` `^0.0.15` | |
|
|
90
|
-
| `@orkestrel/test` | `0.0.
|
|
90
|
+
| `@orkestrel/test` | `0.0.24` | L1 | `@orkestrel/contract` `^0.0.18` | `vitest` `^4.1.11` |
|
|
91
91
|
| `@orkestrel/timeout` | `0.0.11` | L1 | `@orkestrel/contract` `^0.0.17` | |
|
|
92
92
|
| `@orkestrel/tool` | `0.0.16` | L2 | `@orkestrel/emitter` `^0.0.10`, `@orkestrel/contract` `^0.0.17` | |
|
|
93
93
|
| `@orkestrel/toolbox` | `0.0.15` | L6 | `@orkestrel/form` `^0.0.7`, `@orkestrel/tool` `^0.0.16`, `@orkestrel/agent` `^0.0.24`, `@orkestrel/server` `^0.0.20`, `@orkestrel/contract` `^0.0.17`, `@orkestrel/database` `^0.0.15`, `@orkestrel/relation` `^0.0.13`, `@orkestrel/terminal` `^0.0.16`, `@orkestrel/workflow` `^0.0.19`, `@orkestrel/workspace` `^0.0.9` | |
|
|
@@ -149,6 +149,8 @@ one environment, so each is its own project:
|
|
|
149
149
|
exists, and collect that path alone. For each registered project, emit its `test:setup` or
|
|
150
150
|
`test:setup:browser` script and run it from `test`; otherwise emit neither its project nor its
|
|
151
151
|
script.
|
|
152
|
+
- When `tests/setupGlobal.ts` exists, give `src:browser`, `setup:browser`, and `integration` that
|
|
153
|
+
module as their `globalSetup` option, and give no other project a global setup.
|
|
152
154
|
- When a browser application selects the journey axis, register `journey:<variant>` projects
|
|
153
155
|
through the birth-owned `configs/app/vite.journey.config.ts` wrapper. Keep the adopter's variant
|
|
154
156
|
list there and compose each project through the root `appJourney` factory. Exclude
|
|
@@ -514,9 +514,13 @@ constructs the real probe.
|
|
|
514
514
|
own dependencies, and reports the resolved versions on `Verdict.toolchain`. A verdict predicts
|
|
515
515
|
the gate only while probe and the gate read one installed copy of each tool.
|
|
516
516
|
|
|
517
|
-
Declare `@orkestrel/probe` as a development dependency of the workspace it inspects. Its
|
|
518
|
-
|
|
519
|
-
a `prove` call.
|
|
517
|
+
Declare `@orkestrel/probe` as a development dependency of the workspace it inspects. Its
|
|
518
|
+
`typescript` and `vitest` tools are optional peers; probe resolves them and `oxlint` from that
|
|
519
|
+
workspace when a direct probe is constructed or a server admits a `prove` call. The `oxlint`
|
|
520
|
+
package carries no peer range because npm also resolves the peers of an optional peer: `oxlint`
|
|
521
|
+
declares an optional `vite-plus` peer, `vite-plus` 1.0.0 depends on `vitest` 5, and npm 11.19.0
|
|
522
|
+
refuses that conflict with the `vitest` peer range when it installs probe into an empty project
|
|
523
|
+
(measured 2026-09-29).
|
|
520
524
|
|
|
521
525
|
## Registering the server
|
|
522
526
|
|
|
@@ -678,8 +682,8 @@ const claim: Claim = {
|
|
|
678
682
|
|
|
679
683
|
const probe = new Probe({ workspace: process.cwd() })
|
|
680
684
|
const verdict = await probe.prove(claim)
|
|
681
|
-
verdict.digest // '
|
|
682
|
-
verdict.receipt // 'probe:
|
|
685
|
+
verdict.digest // 'bdf03e5dfd6bd413ead671c7a2940fcf'
|
|
686
|
+
verdict.receipt // 'probe:bdf03e5dfd6bd413ead671c7a2940fcf:type:typescript@6.0.3:oxlint@1.86.0:vitest@4.1.11:configs/src/tsconfig.core.json@434f59254d58cf2683d453a26bd0d837'
|
|
683
687
|
await probe.destroy()
|
|
684
688
|
```
|
|
685
689
|
|
|
@@ -683,9 +683,9 @@ path. Its remedy asks you to add the configuration, or remove the script that na
|
|
|
683
683
|
invocation from the `test` chain. When the plan emits `test:journey` and no chain from `test` reaches
|
|
684
684
|
`npm run test:journey` through literal `npm run` calls, that question asks you to insert the invocation
|
|
685
685
|
after `npm run test:app`. These advisories belong to `configs`
|
|
686
|
-
and remain report-only during `repair`: the command preserves
|
|
687
|
-
script. A configuration emitted by the plan or present in the target does not raise
|
|
688
|
-
configuration advisory.
|
|
686
|
+
and remain report-only during `repair`: the command preserves a `test` chain the package owns and
|
|
687
|
+
an unplanned script. A configuration emitted by the plan or present in the target does not raise
|
|
688
|
+
the absent configuration advisory.
|
|
689
689
|
|
|
690
690
|
`audit` still completes the comparison and reports one non-blocking `projects` question when its
|
|
691
691
|
selection includes `configs`. It reports the earliest of the facts it finds; settling that fact and
|
|
@@ -698,7 +698,8 @@ region still leaves the project ungated. Its remedy reads the manifest on disk r
|
|
|
698
698
|
projection, so it states what the developer's own file holds: a script the manifest declares leaves
|
|
699
699
|
the gate as the only repair, and a script only the projection supplies is named as missing beside
|
|
700
700
|
the gate. When `configs` is selected, `repair` and `overwrite` refuse
|
|
701
|
-
an unregistered or ungated project before writing
|
|
701
|
+
an unregistered or ungated project before writing, and a project the planned `test` chain they
|
|
702
|
+
write reaches is not ungated. Their refusal names the `configs` group, the
|
|
702
703
|
manifest and planned `vite.config.ts` conflict, and the option to exclude `configs` from `--groups`.
|
|
703
704
|
A selection that excludes `configs` proceeds. An advisory alone does not make an aligned target
|
|
704
705
|
drift.
|
|
@@ -706,9 +707,18 @@ drift.
|
|
|
706
707
|
Scaffold writes one part of the manifest rather than advising on it: the writable script region.
|
|
707
708
|
`repair` and `overwrite` write every direct `test:<project>` script the blueprint computes,
|
|
708
709
|
`test:probe`, and `test:bench`. A publishing workspace also receives `test:distribution`, `prepack`,
|
|
709
|
-
and `prepublishOnly`. The `test
|
|
710
|
-
|
|
711
|
-
|
|
710
|
+
and `prepublishOnly`. The `test` chain joins the region only as a generated predecessor: when it
|
|
711
|
+
runs fewer steps than the planned chain and every step it runs is a planned step in the planned
|
|
712
|
+
order, `repair` and `overwrite` write the planned chain in its place. That write lands only when
|
|
713
|
+
every step the planned chain adds runs a script the manifest declares or the region writes. The
|
|
714
|
+
`test:src` and `test:app` aggregates sit outside the region, so a chain whose planned form adds an
|
|
715
|
+
aggregate the manifest lacks stays with the package, and the `projects` question keeps its remedy.
|
|
716
|
+
`audit` reports this chain write only through the `projects` question, so a planned step that
|
|
717
|
+
registers no Vitest project, such as `npm run test:guides`, lands on the next `repair` without an
|
|
718
|
+
earlier advisory. A `test` chain running any other step or order stays maintainer-owned, as do the
|
|
719
|
+
`check`, `build`, `dev`, `serve`, `show`, `format`, `lint`, `clean`, and `copy` gate chains. A
|
|
720
|
+
declared value is overwritten only when it is already the value being written or is a recognized
|
|
721
|
+
generated predecessor. The overwrite happens in place,
|
|
712
722
|
so every byte outside the replaced ranges survives. A target's descriptions, keywords, extra
|
|
713
723
|
scripts, and manifest key order survive byte-for-byte. A script the manifest does not declare is
|
|
714
724
|
appended after the last declared script of its own key family, copying that section's indentation:
|
|
@@ -935,6 +945,11 @@ only that browser proof and loads `tests/setup.ts` and `tests/setupBrowser.ts` t
|
|
|
935
945
|
Chromium. The generated manifest emits the selected `test:setup` and `test:setup:browser` scripts
|
|
936
946
|
and invokes them from `test`. Scaffold generates no setup proof for an empty setup seed.
|
|
937
947
|
|
|
948
|
+
A `global` workspace gives `setup:browser` the `tests/setupGlobal.ts` module as its Vitest global
|
|
949
|
+
setup, as it gives `src:browser` and `integration`. A browser proof cannot start a Node fixture from
|
|
950
|
+
inside the browser, so it reads what that module provides through the Vitest `inject` function.
|
|
951
|
+
The Node `setup` project takes no global setup.
|
|
952
|
+
|
|
938
953
|
When the `app` axis selects `browser`, the browser setup project also applies the Vue
|
|
939
954
|
single-file-component transform. Your `tests/setupBrowser.ts` module and its paired proof can
|
|
940
955
|
import and render application Vue components. A browser setup proof without `app/browser` keeps
|
|
@@ -946,12 +961,15 @@ generated before that file existed and still registers no `integration` project,
|
|
|
946
961
|
fails with `integration has no project factory or configuration` until a plan-writing verb
|
|
947
962
|
regenerates it.
|
|
948
963
|
|
|
949
|
-
`repair` closes the direct-script half through the writable manifest region.
|
|
950
|
-
|
|
964
|
+
`repair` closes the direct-script half through the writable manifest region. Over a generated
|
|
965
|
+
predecessor `test` chain it writes the planned chain too, so it registers the project in one run. It
|
|
966
|
+
still refuses to register a project that a maintainer-owned gate chain does not reach.
|
|
951
967
|
|
|
952
|
-
When you add a structural proof
|
|
953
|
-
a gate chain. Then run `repair`; it appends the
|
|
954
|
-
|
|
968
|
+
When you add a structural proof to a workspace whose `test` chain the package owns, write the file
|
|
969
|
+
and invoke its planned `test:<project>` script from a gate chain. Then run `repair`; it appends the
|
|
970
|
+
direct script, regenerates the root configuration, and registers the project. Over a generated
|
|
971
|
+
predecessor `test` chain, write the file and run `repair`. `audit` reports whichever piece is still
|
|
972
|
+
outstanding at each step.
|
|
955
973
|
|
|
956
974
|
`distribution` is not a field at all. A published `src` environment is its whole condition, read
|
|
957
975
|
from the `src` axis the blueprint already carries. The proof packs and installs the published
|