@chatcode/cco-market 1.45.1

package/lib/types/order.d.ts

@@ -0,0 +1,100 @@
+/**
+ * Community bundle ordering — issue #98 (phase 2): let the user reorder the
+ * community bundles of the profile's layer stack, with author-declared
+ * before/after rules enforced before anything is written.
+ *
+ * Official in-box bundles (@deepseek-ai/dsh-base, @deepseek-ai/dsh-web-app,
+ * @deepseek-ai/dsh-headless) are fixed: they keep their exact positions in
+ * the stack, are never part of a user-supplied order, and are never added,
+ * removed or duplicated by a reorder (#98 boundary). The profile's own
+ * cordis.patch.yml and --patch overlays are not part of the bundle stack and
+ * are never touched here.
+ *
+ * Pure functions plus one manifest write-back; no processes, no network.
+ */
+/** Profile bundles that ship with the dsh host and must stay put (#98). */
+export declare const INBOX_BUNDLES: Set<string>;
+/** The bundle stack as it appears in the profile manifest. */
+export interface BundleStack {
+    /** Full ordered list from dsh.profile.bundles. */
+    bundles: string[];
+    /** The subset that may be reordered (community bundles). */
+    community: string[];
+}
+/** Author-declared ordering constraints of one bundle. */
+export interface BundleRule {
+    name: string;
+    /** This bundle must load after every name in this list. */
+    after: string[];
+    /** This bundle must load before every name in this list. */
+    before: string[];
+}
+/** A violated before/after rule in the current or proposed order. */
+export interface OrderConflict {
+    name: string;
+    reason: string;
+}
+/** Read the profile's bundle stack (empty when the manifest is unreadable). */
+export declare function readBundleStack(profileDir: string): BundleStack;
+/**
+ * Read each bundle's declared ordering rules from its package manifest
+ * (`dsh.bundle.order.{before,after}` — a list of bundle package names).
+ * Unresolvable packages and missing declarations contribute nothing.
+ */
+export declare function readBundleRules(profileDir: string): BundleRule[];
+/**
+ * Check a bundle order against the declared before/after rules. Rules naming
+ * bundles outside `order` are ignored (a rule for a not-yet-installed bundle
+ * must not block the current stack).
+ * @returns every violated rule with a readable reason; [] when all hold.
+ */
+export declare function validateOrder(bundleNames: string[], rules: BundleRule[]): OrderConflict[];
+/**
+ * Merge a community-bundle permutation into the full stack. Official in-box
+ * bundles keep their EXACT positions (never moved); community bundles are
+ * replaced by `newOrder` in order of appearance. Pure — nothing is written.
+ * @returns the merged full stack, or the rejection reason when `newOrder` is
+ * not a permutation of the community bundles (duplicates, additions,
+ * omissions, official names).
+ */
+export declare function mergeOrder(bundles: string[], newOrder: string[]): {
+    ok: true;
+    bundles: string[];
+} | {
+    ok: false;
+    error: string;
+};
+/**
+ * Topologically sort the community bundles by their before/after rules — the
+ * "auto-fix" counterpart to validateOrder. Returns null when no declared rule
+ * applies to the current stack (nothing to suggest). With rules, Kahn's
+ * algorithm breaks ties by the CURRENT order: unconstrained bundles keep
+ * their current relative order and constrained bundles move only as far as
+ * the rules require — the suggestion is the minimal change that satisfies
+ * every rule, never an arbitrary canonical rewrite of a hand-picked order
+ * (issue #125 review).
+ * @returns the suggested community order, null when there are no rules, or a
+ * cycle report when the constraints cannot be satisfied (references to
+ * unlisted bundles ignored).
+ */
+export declare function suggestOrder(bundleNames: string[], rules: BundleRule[]): {
+    ok: true;
+    order: string[];
+} | {
+    ok: false;
+    cycle: string[];
+} | null;
+/**
+ * Apply a new community-bundle order to the profile manifest. The official
+ * in-box bundles keep their exact positions; `newOrder` must be a permutation
+ * of the current community bundles (no duplicates, no additions, no
+ * omissions). On any failure the manifest is left untouched.
+ * @returns the new full stack on success, or an error description.
+ */
+export declare function applyBundleOrder(profileDir: string, newOrder: string[]): {
+    ok: true;
+    bundles: string[];
+} | {
+    ok: false;
+    error: string;
+};

package/lib/types/patch.d.ts

@@ -0,0 +1,129 @@
+/**
+ * Patch-layer plugin toggles — hot disable/enable through the profile's
+ * user patch layer (cordis.patch.yml), the mechanism ported from
+ * Noob-stupid/dsh-plugin-hub's plugin console.
+ *
+ * DSH composes a web profile from the bundle layers + the user patch layer
+ * (`$CHATCODE_CLI_HOME/profiles/<name>/cordis.patch.yml`), with per-key override
+ * semantics: a patch row `- id: X` + `disabled: true` stops that loader
+ * entry, and `disabled: false` force-enables one a lower layer disabled.
+ * The profile's config-file watcher (HMR) re-composes within ~1s of the
+ * save — no restart — and the loader re-applies the same file on every
+ * boot, so the choice survives restarts through the official mechanism.
+ *
+ * The market ALSO keeps its own in-memory/state.json bookkeeping (hot-mount
+ * shims have no bundle row to patch, and the client's disable list drives
+ * the switches); this module is the durable, HMR-driven layer on top.
+ *
+ * Safety (borrowed from the plugin-hub implementation):
+ * - writes are serialized so concurrent toggles cannot interleave a
+ *   read-modify-write;
+ * - an append is REFUSED when the patch file is not a valid entry list —
+ *   a malformed file (e.g. a stray `[]` followed by items) is never made
+ *   worse, the market reports it instead;
+ * - host infrastructure rows (transport / hot-reload / storage / settings
+ *   chains) are protected and refuse to toggle.
+ */
+/** The slice of the loader tree this module needs. */
+export interface PatchHost {
+    loader: {
+        entries(): Iterable<{
+            options?: {
+                id?: string;
+                name?: string;
+                config?: {
+                    path?: string;
+                };
+            };
+        }>;
+    };
+}
+/** True when the module name sits on the host infrastructure chain. */
+export declare function isProtectedModule(moduleName: string | undefined): boolean;
+/**
+ * Resolve the profile's user patch layer. Prefers the path the loader's
+ * cordis:include entry actually read (authoritative under hosts that own
+ * the profile directory, like DSH Desktop); falls back to the conventional
+ * `<profile>/cordis.patch.yml`.
+ */
+export declare function findUserPatchPath(host: PatchHost, profileDir: string): string;
+/** What the user patch layer currently says about rows. */
+export interface PatchState {
+    /** Row ids the user patch disables (`disabled: true`). */
+    disables: string[];
+    /** Row ids the user patch force-enables (`disabled: false`). */
+    forced: string[];
+    /** Row ids the user patch inserts. */
+    inserts: string[];
+}
+/**
+ * Line-wise scan of one patch file — the plugin-hub shapes. Deliberately
+ * not a YAML parse: the file may hold structures the market's dialect
+ * rejects, but a plain `- id: X` + `disabled: true|false` pair is enough
+ * to know what the user patch layer says.
+ */
+export declare function readUserPatchState(patchPath: string): PatchState;
+/**
+ * User-authored insert rows that still load `packageName` (or one of its
+ * exported subpaths). This evidence deliberately stays separate from the
+ * package's own bundle declaration: uninstall may clean market-owned rows,
+ * but it must never rewrite an insert the user owns.
+ *
+ * A missing patch is the ordinary empty-profile shape. `null` means the
+ * existing file could not be read as DSH's patch dialect; callers must treat
+ * that as indeterminate and refuse the destructive step.
+ */
+export declare function userPatchPackageReferences(patchPath: string, packageName: string): string[] | null;
+/**
+ * The user-patch row ids one installed package owns: its bundle patch's
+ * insert rows, plus the loader entries currently carrying its name.
+ * Empty for client-only packages (no bundle rows) — the market's own
+ * state.json mechanism covers those, and there is nothing to patch.
+ * Market-owned namespaces (hot-mount `mkt-*`, shim `client-*`) are
+ * excluded: their rows live in the market's own include subtree, and a
+ * permanent patch row targeting them would be a boot-time orphan.
+ */
+export declare function rowIdsForPackage(host: PatchHost, profileDirectory: string, packageName: string): string[];
+/**
+ * The ids of OTHER plugins a package's bundle patch DISABLES — top-level
+ * `- id: X` + `disabled: true` rows targeting plugins it does not own. This is
+ * the precise marker of a bundle whose toggle-off can brick the boot (#224):
+ * dsh-postgres-backends disables session-persistence-jsonl, so once the market
+ * also disables the postgres backends nothing provides sessionPersistence.
+ *
+ * A bundle that merely RECONFIGURES a neighbour is deliberately NOT counted:
+ * the e2e fixture-cross tweaks dshm-fixture-b's config, and #147 requires
+ * disabling it to leave that neighbour live — dropping such a bundle from the
+ * stack broke its re-enable. Config-only side effects stay on the normal #147
+ * path; only a foreign `disabled: true` triggers the bundle removal. Removing
+ * the bundle still neutralizes any config side effects it carries, since its
+ * whole patch stops applying.
+ *
+ * Reads both patch sources like rowIdsForPackage — the declared dsh.bundle.patch
+ * and the conventional root cordis.patch.yml — so either form is detected.
+ */
+export declare function carrierDisableIds(profileDirectory: string, packageName: string): string[];
+/**
+ * Per-package patch-layer flags for the installed list: names whose rows the
+ * user patch layer disables / force-enables. These cover toggles made
+ * OUTSIDE the market (hand-edited cordis.patch.yml, dsh-web-plugin-manager,
+ * the dsh CLI), which the market's own state.json never sees.
+ */
+export declare function packagePatchFlags(host: PatchHost, profileDirectory: string, names: readonly string[], state: PatchState): {
+    disabled: string[];
+    forced: string[];
+};
+/** Disable one row: append `- id: X` + `disabled: true` (idempotent). */
+export declare function disableRow(patchPath: string, rowId: string): Promise<{
+    ok: boolean;
+    reason: string | null;
+}>;
+/** Enable one row: remove the `disabled: true` block; force-enable with
+ * `disabled: false` when a lower layer (bundle/home patch) holds it down. */
+export declare function enableRow(patchPath: string, rowId: string): Promise<{
+    ok: boolean;
+    reason: string | null;
+}>;
+/** Remove every disable/force block the market (or the user) wrote for a
+ * row — the uninstall cleanup, so a removed plugin leaves no orphan rows. */
+export declare function removeRowBlocks(patchPath: string, rowIds: readonly string[]): void;

package/lib/types/pnpm-compat.d.ts

@@ -0,0 +1,93 @@
+/**
+ * pnpm compatibility layer — everything the market needs to know about how
+ * different pnpm majors behave inside a dsh profile directory, kept pure and
+ * separately testable (test/unit + test/integration exercise this module
+ * against real pnpm 9/10/11).
+ *
+ * Verified behavior matrix (2026-08, pnpm 9.15.9 / 10.28.2 / 11.21.0):
+ * - workspace root, `add` without -w:  pnpm 9 fails ERR_PNPM_ADDING_TO_ROOT;
+ *   pnpm 10/11 succeed.
+ * - `add -w` where NO pnpm-workspace.yaml exists: ALL majors fail with
+ *   "--workspace-root may only be used inside a workspace".
+ * - modules dir built by pnpm 9, then pnpm 10/11 mutate it: a modules-layout
+ *   compatibility error (public-hoist-pattern on Unix; virtual-store path
+ *   length can be the first mismatch pnpm reports on Windows).
+ */
+/**
+ * Decide the argv for a `dsh plugin <add|remove> …` call in the given profile.
+ *
+ * pnpm 9 refuses to add at a workspace root without -w (#17, #20); every
+ * pnpm major refuses -w when the directory is NOT a workspace. So the flag
+ * is injected exactly when the profile has a pnpm-workspace.yaml.
+ * @param profileDir - resolved profile directory (owns pnpm-workspace.yaml, or not).
+ * @param pluginArgs - the raw args, e.g. ['add', 'dshmarket@latest'].
+ * @returns args with -w injected when — and only when — the profile is a workspace root.
+ */
+export declare function pluginArgsFor(profileDir: string, pluginArgs: string[]): string[];
+/** One recognized pnpm failure, with a bilingual explanation for the UI. */
+/**
+ * The namespace whose packages the dsh runtime provides rather than npm.
+ *
+ * A peer dependency on one of these is a statement about the host, not a
+ * package to download — and several of them are never published at all.
+ */
+export declare const HOST_NAMESPACE_RE: RegExp;
+export interface PnpmFailure {
+    code: 'adding-to-root' | 'not-a-workspace' | 'hoist-pattern-diff' | 'pnpm-missing' | 'release-age-violation' | 'ignored-builds' | 'git-prepare-not-allowed' | 'git-prepare-failed' | 'tarball-url-mismatch' | 'fetch-404' | 'transient-network' | 'fetch-timeout' | 'unexpected-store' | 'patch-failed' | 'missing-tarball-integrity' | 'windows-file-locked' | 'pnpm-unusable' | 'missing-local-dependency';
+    /** Bilingual, actionable message shown to the user instead of the raw wall of text. */
+    message: string;
+    /** True when re-running `pnpm install` in the profile is the documented recovery. */
+    recoverable: boolean;
+    /**
+     * Show this message INSTEAD of the captured output, not after it.
+     *
+     * Normally the raw text is worth keeping: it is pnpm's own account of what
+     * happened, and the explanation sits under it. Set only where the captured
+     * bytes carry nothing a user can read — cmd.exe writes its errors in the
+     * OEM code page, which arrives here as replacement characters, so pasting
+     * them under an explanation adds noise and hides the explanation (#502).
+     */
+    replaceOutput?: boolean;
+    /**
+     * The package pnpm could not resolve, when the failure names one.
+     *
+     * Exposed because the NAME alone does not say what went wrong: the same
+     * 404 is a ghost entry the user must delete when the package is a direct
+     * dependency of the profile, and an unpublished host peer the market can
+     * retry around when it is not (#289). Only a caller holding the profile
+     * manifest can tell those apart, so the classifier reports the fact and
+     * leaves the judgement to it.
+     */
+    pkg?: string;
+}
+/**
+ * Momentary network failures — worth exactly one automatic retry (#83).
+ * pnpm 5xx fetch codes, its meta-fetch give-up, and the raw socket errors
+ * that surface through dsh's wrapper. Permanent shapes (404, auth) are
+ * deliberately absent: retrying those just doubles the wait for bad news.
+ */
+export declare function isTransientPnpmFailure(output: string): boolean;
+/**
+ * pnpm's per-request fetch timeout: the abort surfaces as a DOMException
+ * ("The operation was aborted due to timeout", code 23) through undici —
+ * pnpm logs it as `GET … error (23)` before giving up. This is the failure
+ * shape for large tarballs (github: sources download the WHOLE repo, even
+ * for a `#path:` subdirectory plugin) on slow networks: pnpm's default
+ * 60-second limit is simply not enough, so a plain retry fails again at the
+ * same limit. The market's recovery re-runs once with a longer
+ * fetchTimeout (see withHoistRecovery).
+ */
+export declare function isFetchTimeoutFailure(output: string): boolean;
+/**
+ * Map a failed pnpm run's combined output to a known failure mode.
+ *
+ * dsh's own wrapper line ("dsh: pnpm failed in profile directory …") names no
+ * cause, so the market must recognize pnpm's real diagnostics itself (#20).
+ * @param output - stdout+stderr of the failed run.
+ * @param exitCode - the run's exit status, when the caller has it (null when
+ *   the process was signalled). Only a
+ *   failure whose whole signal IS the status reads it (#502); everything else
+ *   is recognized from what pnpm said.
+ * @returns the classified failure, or null when unrecognized (raw output is then shown as-is).
+ */
+export declare function classifyPnpmFailure(output: string, exitCode?: number | null): PnpmFailure | null;

package/lib/types/presets.d.ts

@@ -0,0 +1,90 @@
+/**
+ * Named plugin presets — issue #98 (phase 3), the "save different plugin
+ * combinations" product shape. A preset captures the community-bundle order
+ * and the disabled-plugin list of the profile at save time; applying one
+ * replays the composition under the candidate order (trialValidate), refuses
+ * on failure, auto-snapshots the profile (createProfileSnapshot), and only
+ * then writes the bundle order and disable list.
+ *
+ * Presets persist in `<profile>/.dsh-market/presets.json` (market-owned
+ * state, like snapshots) — deliberately separate from state.json, whose
+ * shape routes.ts owns.
+ */
+import { type TrialDiff, type TrialIssue } from './trial.ts';
+/** Maximum presets stored per profile (quota — issue #98 analysis). */
+export declare const MAX_PRESETS = 50;
+export interface Preset {
+    name: string;
+    /** Community-bundle order this preset restores. */
+    bundleOrder: string[];
+    /** Disabled plugin names this preset restores. */
+    disabled: string[];
+    createdAt: number;
+}
+export interface PresetResult {
+    ok: boolean;
+    error?: string;
+    /** Set when applyPreset auto-created a pre-change snapshot. */
+    snapshot?: string;
+}
+/** All saved presets, newest first. */
+export declare function listPresets(profileDir: string): Preset[];
+/**
+ * Save the current composition state as a named preset. The bundle order is
+ * validated against the current community bundles so a stale snapshot can
+ * never be stored.
+ */
+export declare function savePreset(profileDir: string, name: unknown, bundleOrder: unknown, disabled: unknown): PresetResult;
+/** Delete a named preset. */
+export declare function deletePreset(profileDir: string, name: unknown): PresetResult;
+/** The concrete change a preset apply would make — computed BEFORE writing. */
+export interface PresetChange {
+    /** Bundles whose position changes under the preset order. */
+    reordered: string[];
+    /** Plugins the preset would ENABLE (currently disabled, enabled by the preset). */
+    enabled: string[];
+    /** Plugins the preset would DISABLE (currently enabled, disabled by the preset). */
+    disabled: string[];
+    /** True when nothing would change. */
+    noop: boolean;
+}
+export interface PresetApplyResult extends PresetResult {
+    changes?: PresetChange;
+    /** Set when the preset order fails trial validation — errors + current-vs-candidate diff (issue #125 review). */
+    trial?: {
+        errors: TrialIssue[];
+        warnings: TrialIssue[];
+        diff: TrialDiff;
+    };
+}
+/**
+ * The preset's bundle set vs the profile's current community bundles —
+ * a stale preset (saved before a plugin was installed/uninstalled) can no
+ * longer be applied as-is, but its intent (enabled/disabled plugins,
+ * relative order) is still previewable.
+ */
+export interface PresetMismatch {
+    /** Bundles in the current profile that the preset does not mention. */
+    missing: string[];
+    /** Bundles the preset mentions that are not installed anymore. */
+    extra: string[];
+    /** True when the preset's bundle set differs from the current one. */
+    stale: boolean;
+}
+/**
+ * Preview what applying a preset would change, WITHOUT writing anything.
+ * A stale preset (bundle set mismatch) is NOT a hard failure: the preview
+ * reports the mismatch alongside the still-computable changes (relative
+ * order + enabled/disabled diffs over the intersection).
+ */
+export declare function previewPreset(profileDir: string, name: unknown): PresetResult & {
+    changes?: PresetChange;
+    mismatch?: PresetMismatch;
+};
+/**
+ * Apply a saved preset: trial-validate the candidate order first (refuse
+ * without writing on any boot-breaking issue), auto-snapshot the profile,
+ * then write the bundle order and the disable list. The response carries the
+ * change preview so the UI can report exactly what moved.
+ */
+export declare function applyPreset(profileDir: string, name: unknown, maxSnapshots?: number): PresetApplyResult;

package/lib/types/profile.d.ts

@@ -0,0 +1,253 @@
+/**
+ * Profile filesystem reads — everything the market learns from a dsh
+ * profile directory (manifest, lockfile, installed package trees). Pure
+ * functions of the directory contents; no processes, no network.
+ */
+/**
+ * Whether a profile name follows DSH's own directory-name contract.
+ *
+ * Keep this aligned with `@deepseek-ai/dsh-app-boot`'s
+ * `resolveProfileDir`: dots, spaces, and Unicode are ordinary name
+ * characters; only empty, traversal-shaped, launcher-owned, or
+ * separator-bearing names are refused.
+ */
+export declare function isDshProfileName(profile: string): boolean;
+/**
+ * Resolve a profile name beneath the canonical ChatCode CLI Home.
+ * An explicit directory is used by hosts, such as DSH Desktop, that own the
+ * active profile location rather than deriving it from process environment.
+ */
+export declare function profileDir(profile: string, explicitDir?: string): string;
+/**
+ * The in-box bundles dsh's profile templates install themselves — the ONLY
+ * names the market hides from the installed list. Community plugins may
+ * legitimately publish under the official scope (#28), so a whole-scope
+ * filter would make them invisible and fail install validation.
+ * (Diagnosis and fix proposed in #28 by @Lograthmic.)
+ */
+export declare const INBOX_BUNDLES: Set<string>;
+/** Community dependencies of the profile (in-box bundles filtered out). */
+export declare function readInstalled(profile: string, explicitDir?: string): Record<string, string>;
+/**
+ * RAW dependency map of the profile manifest — including the in-box bundles
+ * readInstalled() filters out. This is the rollback snapshot (#65): restoring
+ * a filtered view would delete @deepseek-ai/dsh-base and friends.
+ */
+export declare function readManifestDeps(profile: string, explicitDir?: string): Record<string, string>;
+/** Exact rollback state owned by one profile package operation. */
+export interface ProfileManifestSnapshot {
+    dependencies: Record<string, string>;
+    profileBundles: {
+        present: false;
+    } | {
+        present: true;
+        value: unknown;
+    };
+}
+/** Read dependencies and the exact `dsh.profile.bundles` field before a package operation. */
+export declare function readProfileManifestSnapshot(profile: string, explicitDir?: string): ProfileManifestSnapshot;
+/**
+ * Restore the profile manifest fields a package operation may mutate:
+ * `dependencies` and `dsh.profile.bundles`. pnpm and `dsh plugin add` can
+ * write both before a later fetch or build-script failure (#65, #69, #339),
+ * leaving either an unresolvable dependency or a bundle the next boot cannot
+ * activate. Every unrelated manifest field remains untouched. The lockfile is
+ * left as-is; pnpm reconciles it from the manifest on the next run.
+ *
+ * The write is atomic because rollback runs after another operation already
+ * failed; a partial repair must not turn a valid profile into invalid JSON.
+ * @returns names whose entries were dropped or reverted, empty when nothing changed.
+ */
+export declare function restoreProfileManifest(profile: string, snapshot: ProfileManifestSnapshot, explicitDir?: string): string[];
+/**
+ * Remove a package from BOTH manifest lists — dependencies and
+ * dsh.profile.bundles. The uninstall counterpart of restoreProfileManifest:
+ * pnpm can fail a remove after deleting node_modules but before saving
+ * package.json (the #65 write-order's mirror image — a file locked mid-
+ * unlink aborts the run), leaving the manifest pointing at a package that
+ * no longer exists on disk. The next boot then fails to activate the ghost
+ * dependency. When disk truth says the package is gone, this finishes the
+ * removal the CLI could not. Every other manifest field is untouched.
+ *
+ * Written atomically because it runs only after something already went wrong
+ * mid-uninstall, so it is the worst place to leave a half-written manifest.
+ * @returns true when either list still mentioned the package.
+ */
+export declare function dropFromManifest(profile: string, name: string, explicitDir?: string): boolean;
+/** The version actually present in the profile's node_modules, or null. */
+export declare function readInstalledVersion(profile: string, name: string, explicitDir?: string): string | null;
+/** The installed package manifest, or null when absent or malformed. */
+export declare function readInstalledManifest(profile: string, name: string, explicitDir?: string): unknown | null;
+/**
+ * Whether a package or one of its direct dependencies ships a native addon.
+ *
+ * The question behind it: can unloading this plugin actually free its files?
+ * For ordinary JavaScript, yes — and on POSIX it does not even matter,
+ * because replacing an open file leaves the old inode to whoever holds it.
+ * For a native addon it is no on both counts: Node has no dlclose, so once a
+ * `.node` is loaded the process holds it until it exits. On Windows that
+ * turns "uninstall, then install again" into an EPERM on the rename, which
+ * is what @yandidan1 hit with node-hid (#441) — and no amount of disabling,
+ * unmounting or uninstalling from inside the running process can fix it.
+ *
+ * Deliberately a cheap structural check rather than a scan. Walking a
+ * dependency's tree for `*.node` means recursing through packages that can
+ * be tens of thousands of files, on the uninstall path, to answer a question
+ * three `existsSync` calls answer for every native module built or shipped
+ * the conventional way: node-gyp's `build/Release`, prebuild's `prebuilds/`,
+ * and the `binding.gyp` that names the addon in the first place.
+ *
+ * Direct dependencies are included because that is where these live: the
+ * plugin is JavaScript and the addon is a package it depends on, hoisted to
+ * the profile root beside it.
+ * @param profile - profile name.
+ * @param name - the installed package to ask about.
+ * @param explicitDir - resolved profile directory, when the caller has it.
+ * @returns true when a native addon is present in the package or a direct dependency.
+ */
+export declare function holdsNativeAddon(profile: string, name: string, explicitDir?: string): boolean;
+/**
+ * Strong repository identities for a locally linked dependency (#141).
+ * Explicit github: specs already carry this evidence; only link:/file: need
+ * filesystem discovery. This compatibility wrapper returns only declared
+ * package.json identities; Git origins are exposed separately as hints.
+ */
+export declare function readInstalledRepoIdentities(profile: string, name: string, spec: string, explicitDir?: string): string[];
+export interface InstalledRepoEvidence {
+    identities: string[];
+    hints: string[];
+}
+/**
+ * Discover declared repository identities and weaker local-origin hints. A
+ * package.json repository declaration is authoritative; Git origin is only a
+ * disambiguation hint because a checkout may legitimately point at a fork.
+ */
+export declare function readInstalledRepoEvidence(profile: string, name: string, spec: string, explicitDir?: string): InstalledRepoEvidence;
+/** Pinned commit per `owner/repo` from the profile lockfile's codeload tarball URLs. */
+export declare function readLockCommits(profile: string, explicitDir?: string): Map<string, string>;
+/**
+ * Commit recorded for a non-codeload git resolution (`type: git` in pnpm's
+ * lockfile). Matched against the install spec so a Gitea/GitLab URL can
+ * compare HEAD without mistaking a same-named npm package (#525).
+ */
+export declare function readGitResolutionCommit(profile: string, spec: string, explicitDir?: string): string | null;
+/** True when the installed package's manifest declares a dsh plugin surface. */
+export declare function hasDshManifest(dir: string): boolean;
+/**
+ * True when the package's declared entry artifact actually exists — github
+ * source checkouts of build-required plugins ship no lib/, and promoting one
+ * into the bundle layer bricks the next boot (ERR_MODULE_NOT_FOUND kills the
+ * whole profile, #18).
+ */
+export declare function entryArtifactExists(dir: string): boolean;
+/**
+ * Package names a bundle patch mounts — the `name:` rows of the package's
+ * declared `dsh.bundle.patch` file. Line-wise on purpose: the strict
+ * hot-mount parser rejects config/expression rows, but for "what does this
+ * bundle bring in" any name row counts.
+ */
+export declare function bundlePatchTargets(dir: string): string[];
+/**
+ * Loader entry ids a bundle patch inserts. Cordis refuses to boot a tree
+ * with a duplicate entry id ("duplicate loader entry id: storage", #122), so
+ * these are what two bundles can collide on.
+ */
+export declare function bundlePatchEntryIds(dir: string): string[];
+/**
+ * Loader entry ids the patch INSERTS — the rows the package owns, as opposed
+ * to rows of OTHER plugins it merely configures (#147).
+ *
+ * A bundle patch has two kinds of entry:
+ *
+ *     - insert:                     ← rows this package brings into the tree
+ *         - id: vision-router
+ *           name: dsh-vision-router
+ *     - id: attachment-local        ← someone else's row, only reconfigured
+ *       config: { maxImageBytes: … }
+ *
+ * Treating both as "this package's rows" made disabling one plugin write
+ * `disabled: true` onto the official rows it tuned — killing attachments and
+ * the DeepSeek model with it.
+ */
+export declare function bundlePatchInsertedIds(dir: string): string[];
+/**
+ * `name:` and `id:` rows of the package's declared bundle patch. Line-wise
+ * on purpose: the strict hot-mount parser rejects config/expression rows,
+ * but for "what does this bundle bring in" any row counts. `insertedIds` is
+ * the subset nested under an `insert:` key (#147).
+ */
+/**
+ * Rows of one patch file. Exported because a package may ship its patch at
+ * the conventional path INSTEAD of declaring `dsh.bundle.patch`, and the
+ * patch layer has to read that one by the same rules — a second hand-rolled
+ * scan drifted from this one and re-introduced #147 on that path (it closed
+ * the insert block only on `id:` lines, so `- disable:` followed by nested
+ * ids claimed the neighbour's rows).
+ */
+export declare function parsePatchRows(text: string): {
+    names: string[];
+    ids: string[];
+    insertedIds: string[];
+};
+/** The profile manifest's `dsh.profile.bundles` — what the CLI reconciled. */
+export declare function readProfileBundles(profileDirectory: string): string[];
+/**
+ * Drop one bundle from the profile manifest's `dsh.profile.bundles`, leaving
+ * the package installed as a dependency. This is the carrier-bundle half of a
+ * toggle-off (#224): a bundle whose patch reconfigures plugins it does NOT own
+ * (dsh-postgres-backends disables session-persistence-jsonl and reroutes
+ * storage-domain) keeps applying those side-effect rows on every boot while it
+ * stays in the stack, and the #147 ownership rule deliberately never writes
+ * them — so removing the bundle from the stack is the only thing that stops
+ * them all at once. The package itself stays installed; enabling re-adds it.
+ * @returns true when the bundle was present and removed.
+ */
+export declare function removeProfileBundle(profileDirectory: string, name: string): boolean;
+/**
+ * Re-add a bundle to `dsh.profile.bundles` after a carrier toggle-off (#224).
+ * Idempotent: a bundle already present is left untouched. The name is appended
+ * (the install flow appends too); the loader re-validates ordering on the next
+ * composition, so a declared before/after rule surfaces there rather than here.
+ * @returns true when the bundle was added, false when it was already present.
+ */
+export declare function addProfileBundle(profileDirectory: string, name: string): boolean;
+/**
+ * Loader entry ids a newly added package would collide on with bundles the
+ * profile ALREADY loads (#122).
+ *
+ * Cordis hard-fails the whole tree on a duplicate id, so this is not a
+ * cosmetic conflict: installing a TUI bundle into a web profile (both
+ * declare `id: storage`) leaves DSH unable to start at all, with an error
+ * naming neither plugin. Checked against the profile's own bundle list so a
+ * package is never compared with itself.
+ * @returns colliding ids mapped to the already-installed bundle that owns them.
+ */
+export declare function conflictingEntryIds(profileDirectory: string, candidate: string, installedBundles: readonly string[]): {
+    id: string;
+    owner: string;
+}[];
+/**
+ * Whether the loader has anything to load for this package: its own entry
+ * artifact, or — for CARRIER bundles — patch rows naming other packages that
+ * do have one.
+ *
+ * Carriers are why `entryArtifactExists` alone is the wrong test (#103):
+ * `@linxin666/dsh-skins` ships skin assets plus a patch mounting
+ * `@linxin666/dsh-client-ui-skin-center`, and declares no main/exports/
+ * index.js of its own. Judged by its own entry it looks like the
+ * source-only checkout the #18 guard removes — so the market both flagged it
+ * broken AND uninstalled it right after installing.
+ * @param profileDirectory - resolved profile directory (host-authoritative under Desktop).
+ * @param name - installed package name.
+ */
+export declare function hasLoadableEntry(profileDirectory: string, name: string): boolean;
+/** Plugin subdirectories (depth 2) of a collection checkout, as relative paths. */
+export declare function pluginSubdirs(root: string): string[];
+/**
+ * Allow the given packages' build scripts in the profile's
+ * pnpm-workspace.yaml `allowBuilds` block (the key dsh profiles use),
+ * merging with existing entries and leaving the rest of the yaml intact.
+ * (#6 by @qichuang321.)
+ * @returns every package now allowed.
+ */
+export declare function setAllowBuilds(profile: string, packages: string[], explicitDir?: string): string[];