RFC: LoopX × LayerFS demo and outcome/cost evaluation for multi-agent engineering exploration #461

Proposal

I'd like to explore LayerFS as the execution-workspace substrate for LoopX's multi-agent engineering exploration and publish a reproducible demo plus outcome/cost evaluation.

LoopX is a runtime-neutral control plane for durable goals, work ownership, evidence, budgets and replanning. LayerFS would own branchable filesystem state; LoopX would own which hypotheses to investigate, how results affect subsequent work, and whether a candidate is accepted. The agent host keeps sessions/tools, and Git keeps reviewed source delivery.

Bilingual RFC proposal: loopx-project/loopx#7405 — English design · 中文.
LoopX implementation/evaluation tracker: loopx-project/loopx#7406.

This is an integration/evaluation discussion, not a request for a new generic orchestrator, production durability or an upstream implementation commitment.

Smallest useful demo

Three agents investigate a public multi-file repair from one prepared environment:

1. Fork exact candidate states with dependencies and generated outputs already present.
2. Run different probes and retain both useful and negative results.
3. A receiver verifies one candidate's exact identity, consumes a relevant finding and performs the next repair/test.
4. Export the selected source patch and verify it independently in a fresh checkout.
5. Show failed approaches, actual receiver work, final correctness and complete time/cost, not only the history tree.

The initial candidate is a public historical LoopX quota-readback defect; the RFC requires reproducing its pinned base and preparing an independent oracle first. Broader efficacy evaluation adds unseen TypeScript monorepo and Rust workspace tasks with real lockfiles, symlinks, ignored dependencies and build artifacts. The historical demo alone cannot establish general performance or avoid model contamination.

Integration boundary inspected

Source reviewed at ad78914e36b258b360daf13aec164b5655814689:

• Use the public @layerfs/agent / @layerfs/backend / @layerfs/runtime packages at one exact revision; avoid @layerfs/agent/internal.
• Shell execution uses explicit mount → exec → commit/readback → unmount. Direct file mutations use the Store path. Verify actual routing and avoid a double commit wrapper.
• Keep LoopX's authoritative state, model histories and evaluator secrets outside imported trees. File snapshots do not capture process state, native sessions or external side effects.
• First qualify one Linux kernel/local filesystem (or one VM). Use the current Disposable contract without changing durability policy; preserve independent source/results outside the Store.
• Freeze branch heads for evidence and merge inputs; keep conflict/unknown distinct from success. No blind replay after a lost reply.
• Use a fixed empty .lww for the initial study. Discard is not GC; count all retained failed branches and bound the study Store.
• DSH looks like a practical initial composition host because both integrations exist. Co-installation, version compatibility, session/worker inheritance and control-call routing are still unverified.

Evaluation we propose

First: a deterministic matched build/test workload measures complete cold and warm lifecycle costs, state fidelity, contention and recovery at several branch/concurrency levels. Warm Git worktrees with realistic dependency caches are the main control; add Btrfs/reflink when available. Do not compare only warm LayerFS against repeated cold installation.

Then: a paired agent pilot compares governed LoopX on worktrees vs LayerFS, with one aggregate coordinator+worker budget. A full native/passive/governed × worktree/LayerFS matrix is required before claiming a joint interaction. Primary outcomes are independently accepted repairs and best valid retained results at fixed total budget. Include model/control/evaluation/recovery/human costs, Store+WAL+overlay+container-scratch+export storage and all failed attempts; report missing cost coverage explicitly.

The published v1.0 dedup/fio studies motivate the hypothesis but are not task-level evidence or a reproduction on this source revision. A storage-only gain or an I/O regression is a valid result.

Focused upstream feedback

1. Is this public-package composition the preferred route for an optional integration, while keeping the adapter outside LayerFS core?
2. For evidence tied to a published Layer or a merged result, is Commit/root plus the documented get_comparable / exact-root checks the intended route? Which current public readback is recommended when publication succeeded but the response was lost?
3. For the worker route, can we align the preflight with macos: agents need LAYERFS_STORE_PATH but the docs say it's linux only #456 rather than inventing separate environment conventions?
4. Would portable matched substrate cases and measurements be useful in layerfs-benchmark, linked to the end-to-end LoopX study?

This complements #446, especially G4's worktree comparison, with task-level outcomes and governance attribution. It reuses #411 for history reclamation and #456 for worker configuration instead of duplicating them. Their resolution need not block fixture/oracle preparation or a bounded experiment using current interfaces.

Status: source-inspected design proposal; no LayerFS build, live integration, model experiment or performance claim has been produced for this RFC.

中文摘要：希望验证“LoopX 的探索决策/证据接续 + LayerFS 的完整环境分叉”能否提升复杂工程任务的有效探索效率。先完成分叉、负结果保留、接手、干净 checkout 独立验收，再与预热 worktree 做等总预算比较；文件快照、任务成功率和联合收益分别取证。本 issue 请求集成接口与评测合作意见，不替上游承诺实现，也不要求改变持久性或共享存储边界。