@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.
@@ -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.17` | L0 | | |
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.16` | 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.17` | `oxlint` `^1.82.0`, `vitest` `^4.1.11`, `typescript` `^6.0.3` |
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.73` | L3 | `@orkestrel/console` `^0.0.14`, `@orkestrel/contract` `^0.0.17`, `@orkestrel/emitter` `^0.0.10`, `@orkestrel/markdown` `^0.0.15`, `@orkestrel/process` `^0.0.13`, `@orkestrel/template` `^0.0.8` | |
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.17` | L1 | `@orkestrel/contract` `^0.0.17` | `vitest` `^4.1.11` |
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 tools are
518
- optional peers, resolved from that workspace when a direct probe is constructed or a server admits
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 // 'fcb88a2dee987b8673c1fc7107979470'
682
- verdict.receipt // 'probe:fcb88a2dee987b8673c1fc7107979470:type:typescript@6.0.3:oxlint@1.83.0:vitest@4.1.11:configs/src/tsconfig.core.json@434f59254d58cf2683d453a26bd0d837'
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 the `test` chain and an unplanned
687
- script. A configuration emitted by the plan or present in the target does not raise the absent
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. Their refusal names the `configs` group, the
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`, `check`, `build`, `dev`, `serve`, `show`, `format`, `lint`, `clean`,
710
- and `copy` gate chains stay maintainer-owned. A declared value is overwritten only when it is already
711
- the value being written or is a recognized generated predecessor. The overwrite happens in place,
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. It still refuses to
950
- register a project that the maintainer-owned gate chains do not reach.
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, write the file and invoke its planned `test:<project>` script from
953
- a gate chain. Then run `repair`; it appends the direct script, regenerates the root configuration,
954
- and registers the project. `audit` reports whichever piece is still outstanding at each step.
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