What still overlaps with core-cpp after the migration

[christianparpart]

The core-cpp migration (#805, #806) moved TimeoutScheduler, base64, the wakeup pipe and the per-model strands onto core-cpp, and added coroutines on core::async. This issue lists where morph and core-cpp still overlap, and what moving each would take against the code as it is now. Each item is a candidate for its own change, and none of them is required by the migration.

morph	core-cpp	What moving would take
morph::exec leaf executors: IExecutor, ThreadPoolExecutor, MainThreadExecutor, InlineExecutor, and qt::QtExecutor	core::async::IExecutor, ThreadPoolExecutor, ResumeOn; core::net::EventLoop as an executor	Blocked on contour-terminal/core-cpp#56. The per-model strands have already moved (exec::detail::ModelStrands over core::async::KeyedStrands; morph keeps the adapters CoreExecutorOver, TaskResumer, ExecutorResumer). What remains is the leaf executors, which post std::function<void()> (28 post() sites in include/morph, plus every Completion callback). core::async::IExecutor accepts only submit(coroutine_handle<>) and submit(ParkedWork) and has no way to run a closure. Replacing them therefore needs either a closure submit in core-cpp, or every closure wrapped in a coroutine frame (one allocation per post). MainThreadExecutor::runFor/drain and QtExecutor have no core-cpp counterpart. It is a public API change and needs docs/spec/core/executor.md first.
morph::log	core::log	Proposed: keep. morph::log::logError is the sink for orphaned errors and for exceptions posted tasks throw, and tests silence it through --log-level. The two filter differently: morph gates on one ordered threshold (debug < info < warn < error < off); core::log enables or disables named Category objects individually and has no severity order. Moving needs a decision on how the threshold maps onto categories. morph does not link core::log today, and core-cpp's async, net and platform modules don't log through it. So no core-cpp output currently bypasses morph's sink, and moving would only gain a shared sink for applications that already use core::log.
morph::core::FileIoOps (the injectable file-I/O seam for the journal and both offline queues)	core::platform::FileSystem	Blocked on contour-terminal/core-cpp#57. FileIoOps injects fopen, fwrite, fflush, fsync(FILE*), resizeFile and directory syncPath, and the torn-tail repair works on a FILE* (ftell, seek to end, truncate). FileSystem (v0.5.0) is path- and stream-based and has none of these: no file or directory sync, no truncate, no handle to sync. Moving needs a file-handle abstraction with write/flush/sync/truncate/tell and directory sync landed in core-cpp first, and a morph adapter until then. core::platform is also not linked under WebAssembly.
Four independent wall-clock sources (below)	core::platform::IWallClock, injected (header already reachable: timeout_scheduler.hpp includes core/platform/Clock.hpp on every platform)	Actionable now; the two raw sites are in #842. Reconciling them into one injected IWallClock: • DateTime::now() / Timestamp::now() with a process-global override. No caller in include/morph or src; used by examples/ledger and tests. • session::Clock (std::function<int64_t()>, default systemClockMs) for token issue/verify. Already injected, per call. • Model::recordIfAttached stamps action-log entries (LogEntry::timestampMs) from system_clock::now() directly. Not injectable. • SqliteOfflineQueue::nowMillis() stamps enqueue and update times from system_clock::now() directly. Not injectable. The last two are the ones a test cannot pin today, and they are the smallest step: give Model and SqliteOfflineQueue an IWallClock defaulting to SystemWallClock.
morph::net (POSIX sockets only; MORPH_BUILD_NET warns and builds nothing on Windows)	core::net sockets, listeners and TLS on every platform, IOCP on Windows	Valid, not scheduled. SocketServer runs one accept thread and one thread per client; SocketBackend uses raw POSIX sockets (~1550 lines together). Porting onto core::net (IListener, TcpClient, EventLoop) would give the raw-socket transport Windows support, at the cost of rewriting thread-per-connection as event-loop flows. TLS would also need CORE_CPP_WITH_TLS, which morph builds OFF.

Constraints any of these must keep

• morph's public surface stays header-only. core-cpp's static modules are built alongside it, as they are now, but nothing may require a consumer to link a morph library of its own.
• Single-threaded WebAssembly (Qt wasm_singlethread, emsdk 3.1.56, no -pthread) must keep building and working. No thread, no blocking wait, and nothing newer than libc++ 17 without a feature-test macro. Of core-cpp, only its WebAssembly subset is available there.
• The wire protocol and the remote backends stay unchanged.

Verification status. Read from source, not built, measured or prototyped: morph at master 2cfbdd4 (core-cpp pinned at v0.5.0), and a checkout of core-cpp's v0.5.0 tag (async/IExecutor.hpp, async/ThreadPoolExecutor.hpp, platform/FileSystem.hpp, platform/Clock.hpp, platform/CMakeLists.txt, log/, net/). The clock sites come from grepping include/morph and src for system_clock::now, DateTime::now and Timestamp::now; a clock read through another spelling would be missed. That Clock.hpp compiles under WebAssembly is inferred from its unconditional include, not from a wasm build.

What would close this: each row either moved (with its own issue), or recorded here as deliberately kept, with the reason.

[Yaraslaut]

Triage

Shape. This is a five-row survey, not a bug+fix claim ("each item is a
candidate for its own change, and none of them is required by the
migration"). None of the six verdict labels describes a survey cleanly — a
survey isn't well-framed or mis-framed as a whole, its rows are. Per-row
verdicts below; issue-level label at the end is the closest single fit, not a
claim that the whole thing is one thing.

What I checked. The migration this issue describes (#805/#806) is not on
master — PR #806 is still an open draft. So "after the migration" means the
state on origin/build/core-cpp, not master. I fetched that branch (tip
d65f0d59, core-cpp v0.4.3) into a scratch worktree and read the actual
headers, CHANGELOG.md, and docs/spec/core/executor.md there, and cross-
checked the core-cpp symbols this issue names against the real core-cpp
v0.4.3 tree via gh api repos/contour-terminal/core-cpp/git/trees/v0.4.3.
Not built or run; this is a source-reading + git log -S check, same
verification tier the issue itself claims ("reading both codebases", not
measurement).

---

Row 1 — morph::exec vs core::async executors

Verdict: rescope. The row is stale about its own branch. It lists "the
per-model StrandExecutor" as still overlapping and says "StrandCoroExecutor
already bridges the two for Task handlers" — but neither class exists on
build/core-cpp. CHANGELOG.md on that branch, under Unreleased, says so
explicitly:

morph::exec::detail::StrandExecutor is gone: a backend's strands are
morph::exec::detail::ModelStrands, over core-cpp 0.4.0's
core::async::KeyedStrands<ModelId>, and morph keeps only the adapter to
its IExecutor [CoreExecutorOver], the log of a throwing task and a Task
handler's session [TaskResumer].

docs/spec/core/executor.md names the same three classes
(ModelStrands/CoreExecutorOver/TaskResumer), never "StrandExecutor" or
"StrandCoroExecutor". So the per-model-strand overlap this row lists as a
remaining candidate is not remaining — it was closed by the very branch #807
is describing "after." What's left in this row is narrower than stated: the
top-level IExecutor/ThreadPoolExecutor/MainThreadExecutor/
InlineExecutor family (confirmed still posting std::function<void()> in
include/morph/core/executor.hpp) against core::async::IExecutor/
ThreadPoolExecutor/ResumeOn (all confirmed present in core-cpp v0.4.3),
plus core::net::EventLoop as an executor. That narrower claim holds up.
Fix: drop the "StrandExecutor"/"StrandCoroExecutor" names and the implied
open work on the per-model strand; state that the strand layer already
migrated, and scope this row to the leaf executors only.

Row 2 — morph::log vs core::log

Verdict: valid, but "without losing the level gate" understates the work.
Both sides are real: morph::log gates on a single global ordered
LogLevel (debug<info<warn<error<off>, include/morph/core/logger.hpp,
minLevel compared with <). core-cpp's core::log (confirmed via its
docs/modules/log.md and LogStore.hpp/LogSink.hpp at v0.4.3) is a
different filtering model: named Category objects individually enabled
or disabled by a filter string, with error hard-wired always-on and no
severity ordering across categories. Routing morph's sink through core::log
isn't "wire it through and keep the gate" — the two sides don't share a
concept of "level" at all, so whoever picks this up first has to decide
whether morph's ordered threshold becomes one core-cpp category, several, or
a level-to-category mapping layered on top. Fix: replace "without losing
the level gate" with a sentence naming that reconciliation as the actual
work.

Row 3 — morph::core::FileIoOps vs core::platform::FileSystem

Verdict: valid, and the caution undersells the gap. FileIoOps
(include/morph/core/file_io_ops.hpp) injects fault points at fsync (file
and directory) and other POSIX durability primitives. I read core-cpp
v0.4.3's src/core/platform/FileSystem.hpp in full: it has no fsync-shaped
member at all — no file sync, no directory sync, nothing durability-related
in its ~25 virtuals (existence, read/write/open streams, create/remove/copy/
rename, listing, size, times, permissions). So this isn't "FileSystem must
offer the same fault points" as a wiring detail — the operation category
itself is absent upstream today. Moving this row means either landing fsync
support in core-cpp first (a core-cpp issue, matching #805's own stated
policy of fixing core-cpp gaps there, not working around them here) or
keeping a morph-side adapter indefinitely, not "or."

Row 4 — process-global DateTime::now() vs injected core::platform::IWallClock

Verdict: rescope. core::platform::IWallClock is real (confirmed in
core-cpp v0.4.3's Clock.hpp, alongside IClock/SteadyClock/
ManualWallClock). But the row's list of call sites is wrong: I grepped
include/morph and src for every plausible spelling and none of "sessions,
journal entries and token issue/verify" currently goes through
DateTime::now().

• Token issue/verify (include/morph/session/session_auth.hpp) already
  has its own, separate, already-injectable clock:
  using Clock = std::function<int64_t()>; defaulting to systemClockMs()
  — independent of DateTime's global override.
• Journal (include/morph/journal/{journal,outbox,action_log*}.hpp)
  stamps no wall-clock time anywhere in those files; I found zero matches for
  now()/Clock/Timestamp/DateTime.
• A site the row doesn't mention does need this work and has no seam at
  all: include/morph/offline/sqlite_offline_queue.hpp's nowMillis() calls
  std::chrono::system_clock::now() directly, uninjected, unrelated to
  either DateTime::now() or session::Clock.

So today there are (at least) three independent time sources — the global
DateTime override (used by forms' date/time field rendering), the
per-session injected Clock, and the offline queue's raw uninjected call —
not the one override the row describes threading through three call sites.
The real scope is reconciling three mechanisms into one IWallClock seam,
and the offline queue is the one place that's genuinely untestable against a
fixed clock today. Fix: rewrite the row's second and third columns
against these three actual sites.

Row 5 — morph::net vs core::net

Verdict: valid, as stated. Checked both halves directly:
CMakeLists.txt line ~832: MORPH_BUILD_NET is ignored on Windows: morph::net is POSIX-only — verbatim match. core-cpp v0.4.3's tree has
src/core/net/{windows/IocpBackend.*, Tls.hpp, ITlsContext.hpp, linux/Epoll..., bsd/Kqueue...} — sockets, listeners, TLS and IOCP genuinely present across
platforms. This row needs no correction.

Constraints section

Checked against the branch: header-only + linking core-cpp's static
libraries is already true today (target_link_libraries(morph INTERFACE glaze::glaze core::base core::async core::net), morph stays an INTERFACE
target). The WASM pin (wasm_singlethread, emsdk 3.1.56) matches
.github/workflows/wasm-{ladder,demo}.yml exactly. Both hold.

---

Overall

The issue's framing — "candidates, none required, file each as it's picked
up" — is the right shape for this kind of list, and rows 3 and 5 are solid as
written. But two rows (2, 4) would mis-scope whatever gets filed against them
if taken at face value, and row 1 asks someone to migrate something this
same branch already migrated under different names. That's enough
inaccuracy in a 5-row table that I'd want it corrected before anyone spins a
row off into its own issue, which is this survey's own stated exit
condition ("each row either moved ... or recorded here as deliberately
kept").

What would change this verdict: the four corrected rows (1, 2, 4, and
3's "or" softened to "and, until then") edited into the issue body, at which
point rows 3 and 5's triage: valid reasoning extends to the whole table
and it can carry triage: valid outright.

Labelling triage: rescope (closest fit for "real tracking issue, several
rows need re-scoping before they're actionable") and area: core (4 of 5
rows are core; net's row needed no change).

---

Re-check on master (2026-09-28)

#806 has since landed. master 2cfbdd4 pins core-cpp v0.5.0, not the v0.4.3 read above. I re-read both sides from source at those revisions. Nothing was built or prototyped.

• Row 1 (executors): the rescope above holds. StrandExecutor/StrandCoroExecutor no longer exist, and the strands are ModelStrands over KeyedStrands. New finding: core::async::IExecutor (v0.5.0) accepts only submit(coroutine_handle<>) and submit(ParkedWork), with no closure path, so the leaf executors can't move yet. Blocked, filed upstream as async: let IExecutor run a posted callable, not only a coroutine handle contour-terminal/core-cpp#56.
• Row 2 (log): the category-vs-level analysis holds at v0.5.0. Added: morph doesn't link core::log, and core-cpp's async/net/platform don't log through it, so no core-cpp output bypasses morph's sink today. Proposed: keep deliberately.
• Row 3 (FileIoOps): holds at v0.5.0. FileSystem still has no sync, directory sync, truncate or file handle. Blocked, filed upstream as platform: FileSystem has no durability primitives (file sync, directory sync, truncate) contour-terminal/core-cpp#57.
• Row 4 (clocks): correction to the analysis above. It said the journal stamps no wall-clock time. That's wrong: Model::recordIfAttached (include/morph/core/model.hpp:246) sets LogEntry::timestampMs from std::chrono::system_clock::now() directly. It also said the DateTime::now() override is used by forms' date/time rendering, but no file in include/morph or src calls DateTime::now() or Timestamp::now(); only examples/ledger and tests do. So there are four sources, not three: the DateTime override, session::Clock (injected), Model::recordIfAttached (raw) and SqliteOfflineQueue::nowMillis() (raw). Actionable now: injecting core::platform::IWallClock into the two raw sites.
• Row 5 (net): holds at v0.5.0. Added: TLS would also need CORE_CPP_WITH_TLS, which morph builds OFF.

The issue body has been rewritten with these corrections, per the exit condition above. The triage: label is unchanged here; re-running triage-issue against the new body is what should move it.