Turtle
8c146d978f
* feat(tool-cordis): inspect live plugin Config schemas Replace the Host `Builtin` inspect provider, which described a dynamic Host half the model can no longer define, with a `Config` provider that lists every live Loader entry with its Config status and projects one entry's native Schemastery Config into a self-contained JSON Schema document. app-boot exports its projector, native-schema check, and the shared `loaderExpression` definition for the live walk; the CLI dump keeps its profile-composition path. * fix(tool-cordis): refresh config catalog pointer and presets e2e provider list * fix(tool-cordis): resolve the Loader at Config query time A Host composed programmatically without a Loader keeps registering the inspect providers; `Config.listConfigs` reports the missing Loader when queried. Refresh the advanced-toolchain recordings whose provider list now carries `Config` in place of `Builtin`. * docs: regenerate module graph for the tool-cordis app-boot dependency * docs: regenerate event graph pointer for app-boot exports * fix(tool-cordis): address review on the Config inspect provider Report the Loader entry id (unique across include trees) beside the tree-local patch id, classify group and include carriers as `tree`, treat disabled and disposed fibers as `inactive`, and drop the unreachable boolean-schema branch by narrowing the projector's root type. The presets e2e now queries `Config.listConfigs` over the booted Web profile and projects the shipped `tools` row; the advanced-toolchain recordings carry the updated manifest. * fix(tool-cordis): page the Config directory and filter it by plugin name A full directory of a shipped Web profile exceeds the 50000-byte spill cap once rows carry more fields, and the spilled preview is no longer JSON. `Config.listConfigs` now returns pages (`offset`, `limit` up to 100, default 25) with `total` and `nextOffset`, and an exact plugin `name` filter; the presets e2e reads the shipped rows through the filter.
description, kind
| description | kind |
|---|---|
| The boot package group: how dsh app bins start — environment loading, profile and patch layers, clear startup failures, and app-owned command lines. | package-group |
boot/ — shared app-bin boot glue
English | 中文
Summary
The boot group launches profile applications and manages their installed composition. app-boot resolves configuration and starts the Loader, cmdline supplies application arguments, and plugin-manager exposes current-profile operations shared with the CLI. Each package README owns its details.
Table of Contents
Packages
| Package | Role | ctx key |
|---|---|---|
app-boot |
Boots a dsh app from a cordis.yml: loads .env, applies profile and patch layers, and reports startup failures clearly |
(library for the bins) |
cmdline |
Lets the app own its flags, --help, and exit code; passes everything after the launcher's flags through verbatim |
cmdlineArgs, appExit |
hmr |
Coordinates module and configuration reloads with package mutations | hmr |
config-editor |
Persists active profile configuration through Loader reconciliation | configEditor |
plugin-manager |
Manages current-profile plugins and bundle packages through shared CLI operations | pluginManager |
Related documentation
-
dsh app — the
dshbin that consumes these helpers for its boot sequence. -
Profile bundles — installable patch layers that
dsh --profilecompositions mount. -
dsh-home-paths — the harness-home resolver both packages build on.
-
dsh-cmdline — how an app owns its flag family instead of the launcher.
-
Profile management — service methods and result records.
Dev Note
None.