@yanlinglabs/winter-agent-runtime 0.0.41 → 0.0.43

package/dist/permissions/grammar.d.ts

@@ -100,6 +100,12 @@ export declare function extractRedirectWrites(rawCommand: string): RedirectWrite
 /** `extractRedirectWrites`, target paths only (quotes removed). */
 export declare function extractRedirectTargets(command: string): string[];
 export declare function isRecognizedReadOnly(command: string): boolean;
+/**
+ * `s` with a backslash put before every character a JavaScript regular expression gives a meaning
+ * to -- `. * + ? ^ $ { } ( ) | [ ] \` -- so it can be embedded as literal text in a `RegExp` built at
+ * run time. Every other character is left as it is. Shared with `commands/resolver.ts`,
+ * `skills/permission-rules.ts` and `settings/env-filter.ts`.
+ */
 export declare function escapeRegExpLiteral(s: string): string;
 /** The call's `url` as a parsed `URL`, or `undefined` when it is absent, not a string, or unparseable. NEVER throws. */
 export declare function webFetchUrlOf(input: Record<string, unknown>): URL | undefined;
@@ -136,4 +142,56 @@ export interface PermissionRuleValidation {
     error?: string;
     suggestion?: string;
 }
+/**
+ * Validates one raw rule string for `direction`. Every count and position below is taken on the RAW
+ * text as given, except where the split text is named. The checks, in order -- the first that fails
+ * decides:
+ *
+ *  1. Empty, or only whitespace: `{valid:false, error:"Permission rule cannot be empty"}`.
+ *  2. The number of unescaped `(` differs from the number of unescaped `)`:
+ *     error `"Mismatched parentheses"`, suggestion `"Ensure all opening parentheses have matching
+ *     closing parentheses"`.
+ *  3. Somewhere an unescaped `(` is immediately followed by `)`. Let `prefix` be the text before the
+ *     FIRST `(` character of the raw rule, escaped or not. If `prefix` is empty: error
+ *     `"Empty parentheses with no tool name"`, suggestion `"Specify a tool name before the
+ *     parentheses"`; otherwise error `"Empty parentheses"`, suggestion
+ *     `` `Either specify a pattern or use just "${prefix}" without parentheses` ``.
+ *  4. Split the trimmed text (`splitRuleText`). If it is not `Tool(content)`, the tool name is the
+ *     whole trimmed text and there is no content; if the raw content is `""` or `"*"`, there is no
+ *     content; otherwise the content is the unescaped raw content.
+ *  5. MCP names: split the tool name on `__`; when the first part is `mcp` and the second part is not
+ *     empty, the second part is the server name and the rule is an MCP rule:
+ *       - with content, or with any unescaped `(` in the raw text: error `"MCP rules do not support
+ *         patterns in parentheses"`, suggestion
+ *         `` `Use "${toolName}" without parentheses, or use "mcp__${server}__*" for all tools` ``;
+ *       - for `allow`, a `*` in the server name is refused as in check 7 (a `*` only after a literal
+ *         `mcp__<server>__` is fine);
+ *       - otherwise valid. No further check applies to an MCP rule.
+ *  6. An empty tool name: error `"Tool name cannot be empty"`.
+ *  7. For `allow`, a tool name containing `*`: error
+ *     `` `Wildcard tool name "${toolName}" is not supported in allow rules` ``, suggestion
+ *     `"An allow pattern must name the scope it widens \u2014 globs are permitted only in the tool
+ *     position after a literal mcp__<server>__ prefix. Deny and ask rules accept wildcards anywhere"`
+ *     (with a real em dash, U+2014).
+ *  8. A tool name with no `_` whose first UTF-16 code unit differs from its upper-case form: error
+ *     `"Tool names must start with uppercase"`, suggestion `` `Use "${first upper-cased}${rest}"` ``.
+ *  9. With content:
+ *       - `WebSearch` content containing `*` or `?`: error `"WebSearch does not support wildcards"`,
+ *         suggestion `"Use exact search terms without * or ?"`;
+ *       - `WebFetch` content containing `://` or starting with `http`: error `"WebFetch permissions use
+ *         domain format, not URLs"`, suggestion `'Use "domain:hostname" format'`; else content not
+ *         starting with `domain:`: error `'WebFetch permissions must use "domain:" prefix'`, same
+ *         suggestion.
+ * 10. `Bash` with content: content that contains `:*` but does not END with `:*` (an earlier `:*` is
+ *     accepted when the content also ends with one, e.g. `a:*b:*`): error `"The :* pattern
+ *     must be at the end"`, suggestion `"Move :* to the end for prefix matching, or use * for wildcard
+ *     matching"`; content exactly `:*`: error `"Prefix cannot be empty before :*"`, suggestion
+ *     `"Specify a command prefix before :*"`.
+ * 11. A file-pattern tool -- `Read`, `Write`, `Edit`, `Glob`, `NotebookRead`, `NotebookEdit`, `Cd`
+ *     (this load-time list, not `FILE_RULE_TOOLS`: it has `NotebookRead` and `Cd` and not `Grep`) --
+ *     with content containing `:*`: error `'The ":*" syntax is only for Bash prefix rules'`,
+ *     suggestion `'Use glob patterns like "*" or "**" for file matching'`.
+ * 12. Otherwise `{valid:true}`.
+ * A result carries `suggestion` only where one is named above.
+ */
 export declare function validatePermissionRuleString(raw: string, direction: "allow" | "deny" | "ask"): PermissionRuleValidation;

package/dist/permissions/policy-state.d.ts

@@ -14,7 +14,7 @@ export declare class WinterPermissionError extends Error {
 export declare const PERMISSION_MODES: ReadonlySet<PermissionMode>;
 export declare function isPermissionMode(value: string): value is PermissionMode;
 /**
- * SDK 0.0.16 (P16-7): claude's fork agent (`Ex`) carries `permissionMode: "bubble"` -- NOT a member
+ * SDK 0.0.16 (P16-7): Claude Code's fork agent carries `permissionMode: "bubble"` -- NOT a member
  * of `PERMISSION_MODES` and never widened into one (`PermissionMode` is a closed 6-value union read
  * exhaustively elsewhere -- `classifyPermissionMode` in particular). "bubble" is an explicit ALIAS
  * for "no override": the child keeps whatever mode the parent session is CURRENTLY running (never a

package/dist/permissions/ruleset.d.ts

@@ -6,7 +6,7 @@ export interface SourcedRuleEntry {
     source: RuleSource;
     ruleValue: PermissionRuleValue;
     /**
-     * Fix round 11 ("important" item, claude's own `TFt`/`bl`, dump byte 15441060): the settings
+     * Fix round 11 ("important" item): the settings
      * SOURCE's own directory, for a SINGLE-`/`-anchored pattern's root (`resolveFileRuleAnchor`'s own
      * `/`-branch, file-rules.ts -- already fully wired to consume this, INERT_ANCHOR when absent, a
      * pre-existing disclosed gap this field closes). Populated ONLY by `buildSettingsRuleSeed`

package/dist/permissions/shell-structure.d.ts

@@ -9,7 +9,7 @@ export interface HeredocExtraction {
  * bodies bash will still expand. Bodies are removed BEFORE line continuations are joined: a QUOTED
  * here-document's body is literal (`\<newline>` is not a continuation there), and joining first could
  * shift its delimiter so that a later line -- `> /etc/passwd` -- was swallowed into the body and never
- * seen (claude's `extractOutputRedirections` documents that exact attack).
+ * seen.
  *
  * This is the one scanner that DROPS text, so it follows bash's contexts closely enough never to drop
  * a command bash runs: `<<` is a here-document only in a command context (not inside `((…))`,

package/dist/plugins/bundle.d.ts

@@ -68,12 +68,10 @@ export interface PluginBundle {
      * WS-21 fix round 4 (minors, M-3's last bullet): the manifest's own `workflows` key (`string |
      * string[]`, `manifest.ts`'s own citation), resolved to absolute paths that exist and do not
      * escape the plugin root -- present iff the manifest declares the key AND at least one entry
-     * resolved (the pinned binary's own `if(qn.length>0)ve.workflowsPaths=qn`, manifest.ts's
-     * citation). REPLACES `workflowsPath` rather than adding to it, and the replacement fires on the
-     * key's mere PRESENCE, not on whether anything resolved (the pinned binary's `Lt` gate is
-     * `!j.workflows&&...`, checked independently of `qn.length`): a plugin whose every declared entry
-     * is invalid ends up with NEITHER field set, exactly as claude leaves it with no workflows source
-     * at all rather than silently falling back to the shadowed default directory. Each entry may be a
+     * resolved. REPLACES `workflowsPath` rather than adding to it, and the replacement fires on the
+     * key's mere PRESENCE, not on whether anything resolved: a plugin whose every declared entry is
+     * invalid ends up with NEITHER field set, exactly as claude leaves it with no workflows source at
+     * all rather than silently falling back to the shadowed default directory. Each entry may be a
      * directory or a single workflow file.
      */
     workflowsPaths?: string[];

package/dist/plugins/loader.corpus-fixture.d.ts

@@ -0,0 +1,26 @@
+import { loadPlugins } from "./loader.js";
+export interface PluginLayout {
+    dirs?: string[];
+    files?: Record<string, string>;
+    links?: Record<string, string>;
+    manifest?: unknown;
+}
+export type LoadPluginsFn = typeof loadPlugins;
+/** Expands a content shorthand (see the header) into the file text it stands for; anything else is literal. */
+export declare function expandContent(content: string): string;
+export declare function materializeLayout(layout: PluginLayout): {
+    base: string;
+    root: string;
+};
+/** Runs `load` (defaults to the real `loadPlugins`) on a materialised layout; the result is JSON with `<tmp>` in place of the temp dir. */
+export declare function runLayout(layout: PluginLayout, load?: LoadPluginsFn): unknown;
+/**
+ * Whether a layout's result can depend on the file system folding case: some two distinct names it
+ * involves -- a path segment of a created directory, file or link, a link target, any string (or key)
+ * of the manifest, or a name the loader looks for -- differ only in case (`Skill.MD` beside the
+ * loader's `SKILL.md`, a manifest's `./Commands` beside `commands/`). On a case-insensitive volume
+ * (macOS, where the corpus was recorded) such names find each other; on a case-sensitive one they do
+ * not. Deliberately coarse: it compares single segments, so it may flag a layout whose answer would
+ * not in fact change, never miss one that would.
+ */
+export declare function dependsOnCaseFolding(layout: PluginLayout): boolean;

package/dist/plugins/loader.d.ts

@@ -23,9 +23,8 @@ export interface LoadPluginsResult {
     agentFileRejections: AgentDefinitionRejection[];
     /**
      * Fix round 3 (M-5): a `hooks/hooks.json` that exists, parses as an object, but carries no
-     * top-level `"hooks"` key -- claude's own `hook-load-failed` diagnostic (`hooks.json must have
-     * \`hooks\` (the hook matchers) or \`modules\` (hooks modules), or both`, dump-confirmed). The
-     * plugin itself still loads (a malformed hooks file is not a whole-plugin rejection, matching
+     * top-level `"hooks"` key -- claude reports the same file as a hook-load failure (`hooks.json must
+     * have \`hooks\` (the hook matchers) or \`modules\` (hooks modules), or both`). The plugin itself still loads (a malformed hooks file is not a whole-plugin rejection, matching
      * `agentFileRejections`'s own precedent immediately above), so this is the one channel that ever
      * names it. `production-wiring.ts` folds these into the same `warnings` list.
      */
@@ -35,7 +34,7 @@ export interface LoadPluginsResult {
      * `workflowsPathWarnings` -- ONE fold site, one channel, for every manifest custom-path override
      * this loader resolves, not a parallel field per component): a manifest `workflows`/`agents`/
      * `output-styles`/`commands`/`skills` entry that could not be used -- not a string, escapes the
-     * plugin directory (lexically OR through a symlink -- fix round 5's own Aoe/KGe port), does not
+     * plugin directory (lexically OR through a symlink -- fix round 5's realpath fence), does not
      * exist, or (skills only) is a file where a directory is required -- plus a
      * `folder-shadowed-by-manifest` notice when an override silently drops an existing default
      * directory. Named per-plugin, per-entry, on the SAME "recoverable, not a whole-plugin rejection"

package/dist/plugins/manifest.d.ts

@@ -27,70 +27,47 @@ export interface PluginManifest {
     mcpServers?: Record<string, unknown>;
     /**
      * WS-21 fix round 4 (minors, M-3's last bullet): custom workflow source path(s), REPLACING the
-     * default `workflows/` directory rather than adding to it -- confirmed by content search against
-     * the installed claude CLI binary (`opt/homebrew/Caskroom/claude-code@latest`, 2.1.280; the pinned
-     * 2.1.250 was unavailable locally, so this is the closest available build, cited by content, not
-     * by offset): `if(j.workflows){let jn=Array.isArray(j.workflows)?j.workflows:[j.workflows],
-     * qn=await Tb(jn,e,j.name,n,"workflows","Workflow","specified in manifest but",M,B,!1,h);if
-     * (qn.length>0)ve.workflowsPaths=qn}`, and the default directory is populated only through a
-     * SEPARATE `Lt=!j.workflows&&Be` gate a few lines above -- `Lt` is false whenever `j.workflows` is
-     * present at all, regardless of whether any entry resolves. Each entry may name a DIRECTORY
-     * (scanned the same way as the default one) or a single FILE (the SAME `Tb` call site passes
-     * `requireDirectory:!1` for `workflows`, unlike the `!0` it passes for `skills`, which is the
-     * fourth-from-last argument and the one place the two calls differ). `plugins/loader.ts`'s
-     * `resolveManifestComponentOverride` (fix round 5's own generalisation) is where this is resolved
-     * into `PluginBundle.workflowsPaths`.
+     * default `workflows/` directory rather than adding to it, as claude does: the default directory is
+     * not read whenever the key is present at all, regardless of whether any entry resolves. Each entry
+     * may name a DIRECTORY (scanned the same way as the default one) or a single FILE.
+     * `plugins/loader.ts`'s `resolveManifestComponentOverride` (fix round 5's own generalisation) is
+     * where this is resolved into `PluginBundle.workflowsPaths`.
      */
     workflows?: string | string[];
     /**
      * WS-21 fix round 5: the same custom-path-override shape as `workflows` above, for the built-in
-     * `agents/` component -- content-search confirmed against the installed claude CLI binary
-     * (2.1.280): `if(pt)ve.agentsPath=$t;if(j.agents){let jn=Array.isArray(j.agents)?j.agents:
-     * [j.agents],qn=await Tb(jn,e,j.name,n,"agents","Agent","specified in manifest but",M,B,!1,h);if
-     * (qn.length>0)ve.agentsPaths=qn}` -- `pt=!j.agents&&Fe` shadows the default directory on the
-     * key's mere presence, the identical `!j.X&&Y` shape `workflows`' own `Lt` gate has. The CONSUMER
-     * side (dump-confirmed separately, a different chunk of the same binary) stat()s each entry and
-     * branches directory-vs-file: `M.agentsPaths.map(async(he)=>{let ve=await stat(he);if(ve.
-     * isDirectory()){...scan the dir...}else if(...){...one file...}})` -- ported as
-     * `scanPluginAgentsOverride`.
+     * `agents/` component -- the key's mere presence shadows the default directory, and each entry is a
+     * directory (scanned like the default one) or a single agent file. `plugins/loader.ts`'s
+     * `scanPluginAgentsOverride` reads the entries.
      */
     agents?: string | string[];
     /**
      * WS-21 fix round 5: the same custom-path-override shape as `workflows`/`agents`, for `commands`
-     * -- PLUS an inline `{<name>: {source?: string; content?: string}}` object-map form claude's own
-     * `eqt` also accepts (content-search confirmed against the installed claude CLI binary, 2.1.280),
-     * letting a manifest embed a command's text directly instead of pointing at a file. Winter does
-     * NOT port the inline form this round (`plugins/loader.ts`'s `resolveCommandsManifestOverride` has
-     * the full disclosed-scope note); it is typed here only so a manifest using it is not silently
-     * miscast, and so the shadow-on-presence check still fires for it.
+     * -- PLUS an inline `{<name>: {source?: string; content?: string}}` object-map form claude also
+     * accepts, letting a manifest embed a command's text directly instead of pointing at a file. Winter
+     * does NOT support the inline form yet (`plugins/loader.ts`'s `resolveCommandsManifestOverride`
+     * warns about it); it is typed here only so a manifest using it is not silently miscast, and so the
+     * shadow-on-presence check still fires for it.
      */
     commands?: string | string[] | Record<string, {
         source?: string;
         content?: string;
     }>;
     /**
-     * WS-21 fix round 5: `skills` is a manifest custom-path override too, but content-search confirmed
-     * against the installed claude CLI binary (2.1.280) shows a DIFFERENT precedence than every other
-     * component here -- ADDITIVE, not shadow-on-presence. The builder's own gate (`_t=Le`, no `!j.
-     * skills` negation, unlike `commands`' `ht=!j.commands&&Me`/`agents`' `pt=!j.agents&&Fe`/
-     * `workflows`' `Lt=!j.workflows&&Be`) sets the default `ve.skillsPath` REGARDLESS of whether
-     * `j.skills` is also present; the CONSUMER (a separate chunk of the same binary) confirms it:
-     * `if(h.skillsPath){...load the default...}if(h.skillsPaths){...ALSO load every override entry...}`
-     * -- both run, never either/or. Consistent with this: `skills` is ABSENT from the
-     * `folder-shadowed-by-manifest` tuple list (`["commands",...],["agents",...],["outputStyles",...],
-     * ["themes",...]` -- no `"skills"` entry), so no shadow warning is possible for it.
-     * `plugins/loader.ts`'s `scanPluginSkillsOverride` is where this is resolved and merged.
+     * WS-21 fix round 5: `skills` is a manifest custom-path override too, but with a DIFFERENT
+     * precedence than every other component here -- ADDITIVE, not shadow-on-presence: claude loads the
+     * default `skills/` directory AND every override entry, never either/or, and never reports the
+     * default skills folder as shadowed. Each entry must be a directory (a parent of skill
+     * directories). `plugins/loader.ts`'s `resolvePluginSkills` is where this is resolved and merged.
      */
     skills?: string | string[];
     /**
      * WS-21 fix round 5: the same custom-path-override shape as `agents`/`workflows` (shadow-on-
-     * presence, `requireDirectory:false`) for `output-styles` -- content-search confirmed against the
-     * installed claude CLI binary (2.1.280): `gt=j.outputStyles` (note the CAMEL-CASE manifest key,
-     * unlike the kebab-case default DIRECTORY name `output-styles/`), `Rt=!gt&&He` shadows the default
-     * on presence, and `if(gt){...Tb(...,"output-styles","Output style",...,!1,...);if(qn.length>0)
-     * ve.outputStylesPaths=qn}`. Resolved LAZILY (unlike commands/agents/skills, which are eagerly
-     * scanned at load time): `context/output-styles.ts`'s `PluginOutputStyleSource.outputStylesPaths`
-     * is where a `<plugin>:<style>` lookup actually reads it.
+     * presence, a bare file allowed) for `output-styles` -- note the CAMEL-CASE manifest key, unlike
+     * the kebab-case default DIRECTORY name `output-styles/`. Resolved LAZILY (unlike
+     * commands/agents/skills, which are eagerly scanned at load time):
+     * `context/output-styles.ts`'s `PluginOutputStyleSource.outputStylesPaths` is where a
+     * `<plugin>:<style>` lookup actually reads it.
      */
     outputStyles?: string | string[];
     [key: string]: unknown;

package/dist/production-wiring.d.ts

@@ -275,7 +275,7 @@ export interface ProductionWiring {
      * WS-21 §3.4.4 step 4 / §6.3 item 6: every settings tier's `env` block, claude's per-tier filters
      * applied (`settings/env-filter.ts`), merged HIGHEST-PRECEDENCE-WINS. APPLIED by this function
      * (fix round 1, item 5): `Object.assign(env, settingsEnv)` after every settings read, which reaches a
-     * tool spawn's process env the way claude's own `Object.assign(process.env, filtered)` does -- in
+     * tool spawn's process env, as claude applies each tier's filtered env to its own process env -- in
      * production `env` IS `process.env`, and each test passes its own isolated object. Also exposed here
      * so a caller (and this file's tests) can see exactly which variables were applied.
      */

package/dist/provider/lean-prompt.d.ts

@@ -1,7 +1,2 @@
-/**
- * `modelKey` is a provider-qualified key (`anthropic/claude-opus-5`) or a bare id. claude compares a
- * NORMALIZED id, so the Opus match tolerates the two spellings a catalog row really uses for the same
- * build: a trailing `-YYYYMMDD` snapshot date, and a dotted minor (`claude-opus-4.1`). The original
- * Opus 4 has no minor in its dated id (`claude-opus-4-20250514`); it is `claude-opus-4-0`.
- */
+/** Whether a model key takes the full interface texts. */
 export declare function claudeModelTakesFullPrompt(modelKey: string): boolean;

package/dist/sandbox/profile.d.ts

@@ -12,11 +12,11 @@ export interface SandboxFilesystemSettings {
     allowRead?: string[];
     denyRead?: string[];
     /**
-     * Fix round 16, item 2 (claude's own `ag()`, dump-verified: `function ag(){return
-     * pe?.filesystem?.allowGitConfig??!1}`): `sandbox.filesystem.allowGitConfig` in settings.json --
-     * the ONE settings-facing door for `SeatbeltProfileInput.allowGitConfigWrites`/
-     * `RunCommandOptions.allowGitConfigWrites`, which this module and spawn.ts already had (round 15)
-     * but nothing set. Wired through `tools/impl/{bash,monitor}.ts`'s own options-builders (each reads
+     * Fix round 16, item 2: `sandbox.filesystem.allowGitConfig` in settings.json (default false) -- when
+     * true, a sandboxed command may write `.git/config`. The ONE settings-facing door for
+     * `SeatbeltProfileInput.allowGitConfigWrites`/`RunCommandOptions.allowGitConfigWrites`, which this
+     * module and spawn.ts already had (round 15) but nothing set. Wired through
+     * `tools/impl/{bash,monitor}.ts`'s own options-builders (each reads
      * `ctx.sandboxSettings.filesystem?.allowGitConfig` directly) -- `buildSeatbeltProfile` itself never
      * reads this field; it is CONSUMED at the caller boundary (spawn.ts's own `allowGitConfigWrites`
      * param), matching every other filesystem key's own "settings shape carries it, a caller resolves
@@ -43,41 +43,6 @@ export declare class SandboxConfigError extends Error {
 }
 export declare function resolveNetworkPosture(network: SandboxNetworkSettings | undefined): boolean;
 export declare function canonicalizePath(p: string): string;
-/**
- * Fix round 14 (Winter-specific hardening, NOT itself a claude port -- empirically discovered and
- * verified while implementing `buildReadDenyWritePermitBlock` above, disclosed prominently rather
- * than smoothed over): `pR`'s own trailing re-permit is a BLANKET, UNCONDITIONAL
- * `(allow file-write-unlink file-write-create (subpath <every write root>))`, ported faithfully per
- * the controller's own explicit instruction. Real `sandbox-exec` runs proved this is not merely
- * "narrower than a later wildcard deny wins" (round 13's own finding, about an EARLIER explicit deny
- * surviving a LATER broad `file-write*` allow) -- it runs the OTHER direction too: an EARLIER
- * EXPLICIT `file-write-unlink`/`file-write-create` ALLOW is not overridden by a LATER, broader
- * `(deny file-write* ...)` for the SAME target either. Seatbelt appears to give a clause naming
- * `file-write-unlink`/`file-write-create` explicitly priority over one that only reaches those
- * operations via the `file-write*` wildcard, independent of which clause is textually first or last.
- *
- * Every OTHER Winter-owned write-protection floor in this module that used only the `file-write*`
- * wildcard was therefore silently punched through for CREATE and UNLINK/RENAME specifically (never
- * for `file-write-data`, `file-write-mode`, etc., which this re-permit never names) by this ONE new
- * block: the control-plane carve-outs (WS-12 §5.2's own "the seatbelt is the only enforcement point
- * left" floor -- verified empirically: `mkdir -p .winter && echo '{}' > .winter/permissions.local.json`
- * and `rm .winter/settings.json` both SUCCEEDED against the unpatched fix), the checkpoint/backup
- * store write-deny (T8 rider 25's own identical floor), and a GLOB-shaped `denyWrite` entry (a plain
- * `denyWritePaths` entry was already safe -- `Ch`'s own write-side ancestor-rename block, round 12,
- * already emits an explicit `(subpath <path>)` deny for it; `Ch`'s own GLOB branch, by contrast, only
- * ever emits a `(literal <fixedPrefix>)` -- protecting the prefix DIRECTORY's own identity against a
- * rename-shuffle, never the glob-matched files themselves).
- *
- * The fix, verified against real `sandbox-exec` (a `(deny file-write* file-write-unlink
- * file-write-create (regex ...))` clause DOES win back the CREATE it needs to, confirmed by a direct
- * before/after run rather than assumed): every one of those floors now names
- * `file-write-unlink`/`file-write-create` EXPLICITLY, alongside the `file-write*` wildcard it already
- * carried (for the OTHER write operations the wildcard alone still covers correctly) -- this constant
- * is that shared operation-name list, applied wherever `file-write*` ALONE previously appeared on a
- * deny this round's own re-permit could otherwise reach. `fR` (`buildReadDenyKeepInPlaceBlock`) is
- * deliberately NOT touched here: it already names `file-write-unlink` explicitly (never `create`, by
- * claude's own design -- see that function's own header), so it was never in the affected set.
- */
 /** The runtime's image working directory under the winter/store home (tools/image-prep.ts) -- write-denied to the shell. */
 export declare const IMAGE_PREP_DIRNAME = "image-prep";
 /**
@@ -94,7 +59,7 @@ export declare const IMAGE_PREP_DIRNAME = "image-prep";
  * ESCAPE FIRST, FOLD SECOND, per character: a letter becomes `[Xx]`, and everything else is escaped
  * exactly as `sbplRegexLiteral` escapes it (the brand grammar admits `-` and, for a dot-dir, the
  * leading `.` -- which MUST be escaped or it matches any character). Applied to Winter's own dot-dir
- * it renders `\.[Ww][Ii][Nn][Tt][Ee][Rr]`, byte for byte what the constant it replaces spelled, so
+ * it renders `\.[Ww][Ii][Nn][Tt][Ee][Rr]`, exactly what the constant it replaces spelled, so
  * the rendered profile is unchanged under `WINTER_BRAND` (a test diffs the whole profile text).
  *
  * Exported so the deny suite can assert the rendering directly rather than by reading the profile.
@@ -110,46 +75,42 @@ export interface SeatbeltProfileInput {
     /** WS-12 §5.3: filesystem.denyRead, layered AFTER the read-allow block (last-match-wins). */
     denyReadPaths?: string[];
     /**
-     * Fix round 11 (claude's `Li`/`Rt`, dump byte 15365905/15282610, pinned 2.1.250): glob-shaped
-     * deny entries, PRE-CONVERTED by the caller to SBPL regex SOURCE TEXT (`permissions/file-rules.ts`'s
-     * `globToSbplRegexSource`/`recursiveGlobToSbplRegexSource`/`splitDenyPathsByGlobShape`) -- this
-     * module has no glob grammar of its own (mirrors `denyWritePaths`/`denyReadPaths`'s own "already
-     * resolved by the caller" posture) and only quotes/renders. Claude's own macOS sandbox profile
-     * builder renders a glob-shaped deny as `(regex ...)` and a plain one as `(subpath ...)` (`Li`); a
-     * `subpath` deny alone -- Winter's pre-round-11 posture -- silently drops a glob-shaped Edit deny
-     * (e.g. a globstar-anchored `.env` pattern) or `denyWrite` entry from the sandbox layer entirely
-     * (the PERMISSION-RULE layer still enforced it for a recognized tool call; a bash-invoked
-     * `tee`/`cp` bypassing that layer did not).
+     * Fix round 11: glob-shaped deny entries, PRE-CONVERTED by the caller to SBPL regex SOURCE TEXT
+     * (`permissions/file-rules.ts`'s `globToSbplRegexSource`/`recursiveGlobToSbplRegexSource`/
+     * `splitDenyPathsByGlobShape`) -- this module has no glob grammar of its own (mirrors
+     * `denyWritePaths`/`denyReadPaths`'s own "already resolved by the caller" posture) and only
+     * quotes/renders. A glob-shaped deny renders as `(regex ...)` and a plain one as `(subpath ...)`, as
+     * claude's macOS sandbox does; a `subpath` deny alone -- Winter's pre-round-11 posture -- silently
+     * dropped a glob-shaped Edit deny (e.g. a globstar-anchored `.env` pattern) or `denyWrite` entry from
+     * the sandbox layer entirely (the PERMISSION-RULE layer still enforced it for a recognized tool call;
+     * a bash-invoked `tee`/`cp` bypassing that layer did not).
      */
     denyWriteRegexes?: string[];
     denyReadRegexes?: string[];
     /**
-     * Fix round 12 ("Important" item, claude's own `Ch`/`ed`/`mR`/`pR`, dump byte 15368116/15367994/
-     * 15369065/15368380, pinned 2.1.250): the ancestor-rename-bypass fix. `denyWriteGlobFixedPrefixes`/
-     * `denyReadGlobFixedPrefixes` are the CANONICALIZED fixed-prefix directory of each glob-shaped
-     * denyWrite/denyRead entry (`permissions/file-rules.ts`'s `splitDenyPathsByGlobShape`, its own
-     * `globFixedPrefixes` output) -- this module has no glob grammar of its own, mirrors the other
-     * caller-pre-resolved fields above. Combined with `denyWritePaths`/`denyReadPaths` (the PLAIN
-     * entries, reused directly -- no new field needed for those), `buildAncestorRenameBypassBlock`
-     * below builds a `(deny file-write-unlink file-write-create ...)` clause naming every ANCESTOR of
-     * each denied path/glob-fixed-prefix, PLUS the fixed prefix itself, so a sandboxed `mv <ancestor>
-     * <elsewhere> && <write inside where it used to be> && mv <elsewhere> <ancestor>` cannot rename an
-     * ancestor of a denied path out of the way (and back) to slip a write past the deny.
+     * Fix round 12: the ancestor-rename fence. `denyWriteGlobFixedPrefixes`/`denyReadGlobFixedPrefixes`
+     * are the CANONICALIZED fixed-prefix directory of each glob-shaped denyWrite/denyRead entry
+     * (`permissions/file-rules.ts`'s `splitDenyPathsByGlobShape`, its own `globFixedPrefixes` output) --
+     * this module has no glob grammar of its own, mirrors the other caller-pre-resolved fields above.
+     * Combined with `denyWritePaths`/`denyReadPaths` (the PLAIN entries, reused directly),
+     * `buildAncestorRenameBypassBlock` builds a `(deny file-write-unlink file-write-create ...)` clause
+     * naming every ANCESTOR of each denied path/glob-fixed-prefix, PLUS the fixed prefix itself, so a
+     * sandboxed `mv <ancestor> <elsewhere> && <write inside where it used to be> && mv <elsewhere>
+     * <ancestor>` cannot rename an ancestor of a denied path out of the way (and back) to slip a write
+     * past the deny.
      */
     denyWriteGlobFixedPrefixes?: string[];
     denyReadGlobFixedPrefixes?: string[];
     /**
-     * Fix round 13 ("Important" item 1, claude's own `fR`, dump byte 15367091): "keep read-denied
-     * paths inside write roots in place." Winter's read-deny/write-allow sections previously composed
-     * exactly the way claude's OWN `mR`/`pR` alone would -- last-match-wins, and the write-allow
-     * (`(allow file-write* (subpath <root>))`) is emitted AFTER the read-deny section, so it silently
-     * overrides any read-deny's own implicit protection against being UNLINKED (renamed away): with
-     * `Read(.env)` denied and cwd writable, a sandboxed `mv .env x && cat x` renamed the read-denied
-     * file to a new, non-denied name and read the secret through it. claude closes this with a THIRD
-     * section, `fR`, emitted AFTER the write-allow block: for each read-denied path (or glob-shaped
-     * entry, `denyReadGlobEntries` below) that sits inside a write root, denies `file-write-unlink` on
-     * its own recursive clause (minus any write root nested INSIDE it, carved back out) and on every
-     * one of its ancestor directories that is ALSO inside a write root.
+     * Fix round 13: "keep read-denied paths inside write roots in place." The write-allow block
+     * (`(allow file-write* (subpath <root>))`) is emitted AFTER the read-deny section and, last match
+     * winning, overrode a read-deny's implicit protection against being UNLINKED (renamed away): with
+     * `Read(.env)` denied and cwd writable, a sandboxed `mv .env x && cat x` renamed the read-denied file
+     * to a new, non-denied name and read the secret through it. claude closes this too. A third section,
+     * emitted AFTER the write-allow block (`buildReadDenyKeepInPlaceBlock`), denies `file-write-unlink`
+     * for each read-denied path (or glob-shaped entry, this field) that sits inside a write root -- minus
+     * any write root nested INSIDE it, carved back out -- and for each of its ancestor directories that is
+     * ALSO inside a write root. Each entry pairs the glob's regex with its own fixed prefix.
      */
     denyReadGlobEntries?: GlobDenyEntry[];
     /** Resolved network posture -- see resolveNetworkPosture's own header for why this is a plain boolean here. */
@@ -210,12 +171,11 @@ export interface SeatbeltProfileInput {
      */
     brand?: SandboxBrand;
     /**
-     * Fix round 15 (claude's own `cR(e=false)` / `mR`'s own `r=false` default parameter): when true,
-     * `.git/config` is NOT added to the default write-protected entries (`buildDefaultWriteProtectionBlock`
-     * above) -- every OTHER default protection (shell/tool config files, editor/agent dot-dirs,
-     * `.git/hooks`) is unaffected; this flag only ever gates `.git/config`, matching `cR`'s own `!e`
-     * guard exactly. Omitted = `false` = protected, matching claude's own default. No caller sets this
-     * true yet -- kept for parity since claude's own signature carries the knob.
+     * Fix round 15: when true, `.git/config` is NOT among the default write-protected entries
+     * (`buildDefaultWriteProtectionBlock`) -- every OTHER default protection (shell/tool config files,
+     * editor/agent dot-dirs, `.git/hooks`) is unaffected; this flag only ever gates `.git/config`.
+     * Omitted = `false` = protected, claude's default too. Set from `sandbox.filesystem.allowGitConfig`
+     * (round 16).
      */
     allowGitConfigWrites?: boolean;
 }

package/dist/sandbox/spawn.d.ts

@@ -84,7 +84,7 @@ export interface RunCommandOptions {
     denyWritePaths?: string[];
     denyReadPaths?: string[];
     /**
-     * Fix round 11 (claude's `Li`/`Rt`, dump byte 15365905/15282610): glob-shaped `denyWritePaths`/
+     * Fix round 11: glob-shaped `denyWritePaths`/
      * `denyReadPaths` entries, PRE-CONVERTED to SBPL regex source by the caller (`permissions/
      * file-rules.ts`'s `splitDenyPathsByGlobShape`) -- this module stays glob-grammar-free, exactly
      * like `denyWritePaths`/`denyReadPaths` themselves are already resolved, absolute paths by the
@@ -93,7 +93,7 @@ export interface RunCommandOptions {
     denyWriteRegexes?: string[];
     denyReadRegexes?: string[];
     /**
-     * Fix round 12 ("Important" item, claude's own `Ch`/`ed`): the ancestor-rename-bypass fix -- each
+     * Fix round 12: the ancestor-rename-bypass fix -- each
      * glob-shaped `denyWritePaths`/`denyReadPaths` entry's OWN canonicalized fixed-prefix directory
      * (see `SeatbeltProfileInput.denyWriteGlobFixedPrefixes`'s own header). Same "caller pre-resolves,
      * this module stays glob-grammar-free" posture as `denyWriteRegexes`/`denyReadRegexes` above.
@@ -101,10 +101,9 @@ export interface RunCommandOptions {
     denyWriteGlobFixedPrefixes?: string[];
     denyReadGlobFixedPrefixes?: string[];
     /**
-     * Fix round 13 ("Important" item 1, claude's own `fR`): the read-deny-keep-in-place fix -- each
-     * glob-shaped `denyReadPaths` entry, PAIRED with its own fixed prefix (see
-     * `SeatbeltProfileInput.denyReadGlobEntries`'s own header). Read-only -- claude's own `fR` is a
-     * read-deny-specific concern.
+     * Fix round 13: the read-deny-keep-in-place fix -- each glob-shaped `denyReadPaths` entry, PAIRED
+     * with its own fixed prefix (see `SeatbeltProfileInput.denyReadGlobEntries`'s own header).
+     * Read-side only -- keeping read-denied paths in place is a read-deny-specific concern.
      */
     denyReadGlobEntries?: GlobDenyEntry[];
     /**

package/dist/skills/listing.d.ts

@@ -41,49 +41,31 @@ export interface BuildSkillListingOptions {
 export declare function isModelVisible(overrides: SkillOverrides | undefined, skill: SkillMeta | string): boolean;
 /** True when a USER `/name` may still reach this skill. Only `off` closes that door. */
 export declare function isUserInvocable(overrides: SkillOverrides | undefined, skill: SkillMeta | string): boolean;
-/**
- * claude's `Ckn`: the context window a budget is sized against when the session reports none.
- */
+/** The context window (tokens) a budget is sized against when the session reports none. */
 export declare const DEFAULT_SKILL_LISTING_CONTEXT_WINDOW_TOKENS = 200000;
-/**
- * The whole-listing character budget -- claude's `Ige`: `floor(window x chars-per-token x fraction)`,
- * with claude's 200k-token default window when the session reports none (or a non-finite one).
- * An explicit `budgetChars` wins (claude's `SLASH_COMMAND_TOOL_CHAR_BUDGET` analog), and there `0`
- * means "no budget" -- a Winter extension, never "no listing".
- */
+/** The whole-listing character budget: an explicit `budgetChars` (`0` = no budget), or a share of the context window in characters. */
 export declare function skillListingBudgetChars(opts: {
     contextWindowTokens?: number | undefined;
     budgetFraction?: number | undefined;
     budgetChars?: number | undefined;
 }): number;
 /**
- * claude's `xkn`: a description longer than the cap keeps `cap - 1` characters and gains the
- * ellipsis, so the result is exactly `cap` characters long.
+ * A description longer than the cap keeps `cap - 1` characters and gains the ellipsis, so the result
+ * is exactly `cap` characters long (the same shape claude's listing uses).
  */
 export declare function truncateSkillDescription(description: string, maxDescChars: number): string;
 /**
- * claude's per-skill line (`Mkn`): `- <name>: <description>`, or `- <name>` for an entry whose
- * description is empty (a `name-only` override, or one the budget reduced to its name).
+ * One listing line: `- <name>: <description>`, or `- <name>` for an entry whose description is
+ * empty (a `name-only` override, or one the budget reduced to its name).
  */
 export declare function renderSkillListingLine(entry: {
     name: string;
     description: string;
 }): string;
-/** The `skill_listing` attachment's `content`: one line per entry, newline-joined (claude's `Rot` output). */
+/** The `skill_listing` attachment's `content`: one line per entry, newline-joined. */
 export declare function renderSkillListingContent(entries: readonly {
     name: string;
     description: string;
 }[]): string;
-/**
- * Build the model-facing listing -- claude 0.3.250's `Rot`, applied here once so every consumer sees
- * the budgeted result.
- *
- * ORDER IS PRECEDENCE ORDER (the index's own): project first, builtin last. Every visible skill is
- * listed; the budget decides only which ones keep their DESCRIPTION:
- *   - everything fits -> every line is full;
- *   - over budget -> `name-only` entries and Winter's builtin (claude: bundled) skills stay full,
- *     every other entry starts as its bare name, and descriptions are restored in priority order
- *     while the remaining budget holds them. claude orders that priority by its per-skill usage
- *     score; Winter keeps no usage history, so every score ties and precedence order decides.
- */
+/** The model-facing listing: every visible skill, with the budget deciding which keep their description. */
 export declare function buildSkillListing(skills: readonly SkillMeta[], opts?: BuildSkillListingOptions): SkillListing;

package/dist/skills/store.d.ts

@@ -88,9 +88,8 @@ export interface SkillIndexOptions {
     bodyBytes?: number | undefined;
     /**
      * Fix round 4 (I-E, the router same-view test): a workflow, registered as a SYNTHETIC skill so
-     * `Skill("<name>")` and the slash-command surface both run it -- claude's own `m()` turns every
-     * discovered workflow into exactly this shape (dump-confirmed: `{type:"prompt", kind:"workflow",
-     * ...}`). Unlike every other entry `discover()` finds, a synthetic entry carries its own BODY
+     * `Skill("<name>")` and the slash-command surface both run it -- claude likewise offers every
+     * discovered workflow as a prompt-type command under the workflow's name. Unlike every other entry `discover()` finds, a synthetic entry carries its own BODY
      * directly (`load()` returns it as-is, never reading `path` from disk -- there is no SKILL.md a
      * workflow script's own identity could point `load()` at). `path` is still required on the
      * resulting `SkillMeta` (a synthetic, non-filesystem marker -- `workflows/store.ts`'s own

package/dist/store/dialect.d.ts

@@ -478,7 +478,7 @@ export declare class TranscriptWriter implements SessionPersistence {
     private dialectRecord;
     static readBack(store: SessionStore, key: SessionKey): Promise<SessionStoreEntry[]>;
 }
-export declare const RUNTIME_ENGINE_VERSION = "0.0.41";
+export declare const RUNTIME_ENGINE_VERSION = "0.0.43";
 export interface ResolvedEngineSession {
     config: RuntimeConfig;
     store: SessionPersistence | undefined;