Session-log ZIP entries always used DEFLATE level 6 even though compression level is a deployment tradeoff: CPU-constrained hosts may prefer low latency while bandwidth-constrained hosts may prefer smaller archives. A hardcoded level also violated the repository rule that deployment-varying plugin choices live in validated Config.
Add sessionExportCompressionLevel to ApiProxyService.Config as an integer 0-9 with default 6, resolve the same default once for direct createApiProxy callers, and pass the required level into the streaming module. Tests prove schema defaulting and rejection as well as a level-0 versus level-9 archive-size difference with identical extracted content. The generated config catalog, bilingual gateway README, and feature note document the knob and its tradeoff.
The ZIP loop checked desiredSize only after a push and responded to an overfull queue with setTimeout(0). A timer turn does not mean the consumer drained anything, so a slow or disconnected client still allowed the producer to enqueue the complete compressed archive while later artifact and attachment reads ran eagerly.
Give the ReadableStream a 64 KiB byte queuing strategy and block the single producer on a pull-released capacity gate whenever desiredSize is non-positive. Cancellation wakes that gate through the existing producer signal; synchronous fflate output is therefore bounded to the queue high-water mark plus one input push. A regression test exhausts timer turns without consuming and proves the next media entry remains unread until response pulling begins, and the bilingual contracts now describe the real bound.
Only the root raw-artifact read received the request signal. Lineage discovery and descendant reads could continue after disconnect, response-body cancellation did not stop the producer, and the root error boundary converted an abort rejection into an ordinary HTTP 500.
Combine request and response-consumer cancellation into the ZIP producer signal, forward it through every cancellable read, check it around the attachment seam, and terminate fflate exactly once when production stops. The pre-stream boundary now rethrows the original abort instead of translating it. Regression tests cover signal propagation, exact cancellation identity at the HTTP boundary, and a reader cancellation interrupting an in-flight descendant read; the bilingual host contract records these lifecycle semantics.
The exporter read persistence artifacts directly even when the requested root or a descendant was still live. Buffered session events could therefore be omitted from a successful download, so the advertised verbatim-artifact guarantee described storage accurately but captured an arbitrarily stale durability boundary.
Resolve each id against SessionStore and cross its authoritative flush barrier immediately before readRaw. Cold sessions remain a no-op, while live roots and descendants are made durable independently; this intentionally yields a per-session read-boundary snapshot rather than claiming an atomic lineage snapshot. A host-path regression test proves both artifacts change from stale to durable only through flush, and the bilingual host contract and Agent Note document the boundary.
Regenerating docs/module-graph.md and docs/config-catalog.md during the
master merge added code-runtime-python entries to the English sides only,
leaving both pairs out of sync with their recorded consistent state. Add the
matching Chinese entries and re-record the pairing.
Resolve three conflicts:
- packages/bundle/base/tests/base.spec.ts: keep both assertion sets — this
branch's telemetry-otel mode expression and master's subagent rows plus
manifest dependencies.
- packages/session/session-telemetry-otel/tests/otel.spec.ts: keep master's
per-mode sharing disclosure test, but select FULL explicitly instead of
relying on an omitted mode, because the default is now DISABLED; the
default-construction test keeps asserting disabled delivery and gains a
case pinning that an omitted mode reports 'disabled' sharing.
- scripts/snapshots/translation-prompt-v4/request-response.expected.json:
re-recorded from the merged READMEs rather than hand-merging the embedded
document text.
Resolutions:
- docs/module-graph.md, docs/config-catalog.md: both are generated files.
Regenerated with gen-module-graph and gen-config-catalog on the merged
tree instead of hand-merging the conflict hunks.
- scripts/verify-package-readme-model-experience.ts: both sides appended
registry entries; kept all four.
Adapted this package to conventions master introduced while the branch was
open: version 0.0.1-rc.1 with publishConfig and repository metadata, the
workspace: protocol for peer dependencies, and the @deepseek-ai/cordis
rescope in package.json and src/invariant.ts.
A CONFLICTING PR gets no pull_request workflow runs, so `gh pr checks`
reports "no checks reported" and the runs API returns total_count 0. That
looks like a dropped GitHub event, and the reflex fixes for one — empty
commits, draft/ready toggles, revert-and-restore bounces — all leave the
count at zero while adding junk history to the branch.
Record the mergeability check as the first diagnostic step, name the
conflict as the cause, and point at `git merge-tree` for the conflicting
paths.
_Kerman