diff --git a/apps/presentation/site/public/blog/context-delivery/example.py b/apps/presentation/site/public/blog/context-delivery/example.py
new file mode 100644
index 0000000000..f8bb013320
--- /dev/null
+++ b/apps/presentation/site/public/blog/context-delivery/example.py
@@ -0,0 +1,229 @@
+"""Reproduce a synthetic context-delivery lesson with the existing owners.
+
+Run with a LoopX source checkout's Python environment. This never registers a
+Goal, admits/spends a Turn, contacts a model/provider or changes live state.
+"""
+import argparse
+import copy
+import hashlib
+import json
+import os
+from pathlib import Path
+import shlex
+import subprocess
+import sys
+
+p = argparse.ArgumentParser(description=__doc__)
+p.add_argument('--loopx-root', type=Path, required=True)
+p.add_argument('--output', type=Path, required=True, help='Empty directory for generated synthetic outputs.')
+p.add_argument('--private-receipts', type=Path)
+a = p.parse_args()
+repo = a.loopx_root.resolve()
+out = a.output.resolve()
+if out.exists() and any(out.iterdir()):
+    p.error('Use an empty output directory; existing material will not be overwritten.')
+out.mkdir(parents=True, exist_ok=True)
+sys.path.insert(0, str(repo))
+from loopx.control_plane.quota.turn_envelope import prepare_context_delivery, restore_context_delivery
+import loopx
+assert Path(loopx.__file__).resolve().parent == repo / 'loopx'
+
+def raw(value):
+    return (json.dumps(value, ensure_ascii=False, separators=(',', ':')) + '\n').encode()
+
+def save(name, value):
+    content = raw(value)
+    (out / name).write_bytes(content)
+    return {'fixture': name, 'sha256': hashlib.sha256(content).hexdigest(), 'bytes': len(content)}
+
+goal = {
+    'objective': '让管家理解语音消息，并在原对话返回结果 / Understand a voice note and reply in its original chat',
+    'constraints': {
+        'provider': '优先已有语音服务 / Prefer the already configured speech service',
+        'privacy': '音频不能公开；外部处理仍需已有授权 / Do not publish audio; external processing still needs authorization',
+    },
+    'acceptance': '转写正确，结果回到原对话；服务不可用时明确告知 / Correct transcript and same-chat reply; state service unavailability explicitly',
+}
+providers = {
+    'configured': {'formats': ['m4a', 'mp3'], 'authorization': 'must_check_current_grant'},
+    'alternative': {'formats': ['wav'], 'authorization': 'not_established'},
+}
+evidence = {
+    'sample-1': {'conditions': {'reply_chat': 'original-chat', 'format': 'm4a'}, 'result': '正确回到原对话 / Replied in the original chat'},
+    'sample-2': {'conditions': {'reply_chat': 'another-chat', 'format': 'm4a'}, 'result': '转写正确，但回复到了另一对话 / Correct transcript, wrong reply chat', 'reviewer': None},
+}
+history = [
+    {'entry': i, 'topic': ['formats', 'privacy', 'failure-recovery', 'same-chat-return'][i % 4],
+     'discussion': f'教学历史记录 {i}。接入方案要分别检查输入格式、当前服务授权、原对话身份和结果来源。'
+       '转写文本正确并不足以通过验收，还需要返回同一条原始工作流。网络失败、响应丢失、格式不支持和用户撤回都保留为独立事实。'
+       '比较候选服务时，原目标、隐私约束和接受条件继续有效；引用资料可以深入读取，不能用一段新摘要替换原要求。'
+       '这是合成材料中的讨论，不记录任何真实用户、语音、账号、对话或服务调用。',
+     'related_sample': 'sample-1' if i % 2 == 0 else 'sample-2'}
+    for i in range(80)
+]
+lesson = {'goal': goal, 'providers': providers, 'evidence': evidence, 'history': history}
+captures = {'capture': save('capture.json', lesson)}
+
+env = {**os.environ, 'PYTHONPATH': str(repo), 'LOOPX_CONTEXT_DELIVERY': 'off'}
+cli = [sys.executable, '-c', 'from loopx.cli import main; main()', '--format', 'json', 'quota', 'context-read']
+all_receipts = {}
+
+def read(label, capture, args):
+    """Count complete actual CLI responses, following its verified byte cursors."""
+    pages, bodies, offset, selection_digest = [], [], 0, None
+    while True:
+        cmd = cli + ['--capture-file', capture['fixture'], '--capture-sha256', capture['sha256'],
+            '--offset', str(offset), '--page-bytes', '16000', '--max-page-output-bytes', '20000'] + args
+        if selection_digest:
+            cmd += ['--selection-sha256', selection_digest]
+        r = subprocess.run(cmd, cwd=out, env=env, capture_output=True)
+        page = json.loads(r.stdout)
+        pages.append({'exit_code': r.returncode, 'stdout': r.stdout.decode(), 'stderr': r.stderr.decode()})
+        if not page.get('ok'):
+            assert 'content' not in page
+            all_receipts[label] = pages
+            return {'calls': len(pages), 'output_bytes': sum(len(x['stdout'].encode()) for x in pages), 'error': page}
+        assert page['sha256'] == capture['sha256'] and page['offset'] == offset
+        b = page['content'].encode()
+        bodies.append(b)
+        offset += len(b)
+        if 'selection_sha256' in page:
+            selection_digest = selection_digest or page['selection_sha256']
+            assert selection_digest == page['selection_sha256']
+        if page['eof']:
+            assert page['next_offset'] is None and offset == page['total_bytes']
+            break
+        assert page['next_offset'] == offset and page.get('next_command')
+    joined = b''.join(bodies)
+    assert hashlib.sha256(joined).hexdigest() == (selection_digest or capture['sha256'])
+    all_receipts[label] = pages
+    return {'calls': len(pages), 'body_bytes': len(joined),
+        'output_bytes': sum(len(x['stdout'].encode()) for x in pages), 'body': json.loads(joined)}
+
+paths = ['/goal/objective', '/goal/constraints', '/goal/acceptance']
+full = read('full', captures['capture'], [])
+separate = [read('goal-' + str(i), captures['capture'], ['--select', path]) for i, path in enumerate(paths)]
+batch = read('batch', captures['capture'], [arg for path in paths for arg in ['--select', path]])
+assert {s['pointer']: s['value'] for r in separate for s in r['body']['selections']} == {s['pointer']: s['value'] for s in batch['body']['selections']}
+assert full['body'] == lesson
+indexes = [read('index-' + pointer, captures['capture'], ['--select', pointer, '--list'])
+    for pointer in ['/providers', '/providers/configured', '/providers/alternative']]
+deep_index = read('index-depth-2', captures['capture'], ['--select', '/providers', '--list', '--list-depth', '2'])
+fields = lambda r: r['body']['selections'][0]['fields']
+assert {f['pointer'] for r in indexes for f in fields(r)} == {f['pointer'] for f in fields(deep_index)}
+sample = read('sample-result', captures['capture'], ['--select', '/evidence/sample-2/result'])
+conditions = read('sample-conditions', captures['capture'], ['--select', '/evidence/sample-1/conditions', '--select', '/evidence/sample-2/conditions'])
+missing = read('missing', captures['capture'], ['--select', '/goal/objective', '--select', '/providers/missing'])
+assert missing['error']['diagnostic_code'] == 'context_selection_missing_pointer'
+null = read('null', captures['capture'], ['--select', '/evidence/sample-2/reviewer'])
+assert null['body']['selections'][0]['value'] is None
+
+# Registered native acceptance shape: exercise the actual typed progressive owner.
+clauses = [
+    '优先复用已配置的语音服务；模型或工具配置不是一次外部发送授权。',
+    '原始音频不可公开；外部处理、受众与保存边界沿当前授权核验。',
+    '转写结果回到原对话，保留消息来源、顺序及原始音频引用。',
+    '明确支持的格式；不支持或过大的输入返回可理解的失败结果。',
+    '服务不可用和未获授权分别告知，不伪造已转写或已发送。',
+    '响应丢失后核对原请求结果，同一次输入不重复计费或回传。',
+    '取消与撤回保留真实边界，无法取消的外部操作不伪装已停止。',
+    '识别不确定时说明来源和不确定性；原始证据继续可查。',
+    '刷新和继续工作后仍保留全部原要求、当前状态及失败理由。',
+    '验收区分组件自测、实际原会话采用与独立核验，不从配置推断完成。',
+]
+requirements = [{'id': 'voice-' + str(i), 'description': c, 'status': 'unverified', 'planning_satisfied': False}
+    for i, c in enumerate(clauses)]
+requirements[2]['agent_review'] = {'id': 'voice-2', 'conclusion': 'unmet', 'basis_current': False,
+    'independently_verified': False, 'note': evidence['sample-2']['result'], 'evidence_refs': ['fixture:sample-2']}
+outcome = {'id': 'voice-output', 'owner_agent_id': 'demo-agent', 'objective': goal['objective'], 'revision': 1,
+    'requirements': requirements, 'todo_ids': ['todo_voice'],
+    'sources': [{'ref': 'fixture:voice-brief', 'summary': json.dumps(history, ensure_ascii=False)}]}
+row = {'schema_version': 'todo_item_v0', 'todo_id': 'todo_voice', 'text': '在原对话接入语音读取并核验完整返回。',
+    'note': '\n'.join(clauses), 'content_revision': 'fixture:revision-1', 'claimed_by': 'demo-agent'}
+native = {'ok': True, 'planning_horizon': {'core_goal': {'objective': goal['objective'],
+    'acceptance_contract': {'outcome_requirements': {'schema_version': 'loopx_goal_outcomes_v0', 'outcomes': [outcome]}}}},
+    'agent_todo_summary': {'schema_version': 'todo_summary_v0', 'first_open_items': [row], 'backlog_items': [copy.deepcopy(row)]},
+    'work_state': {'phase': 'verify-original-chat', 'samples': ['sample-1', 'sample-2']}}
+captures['original'] = save('projection.json', native)
+scope = {'goal_id': 'voice-demo', 'agent_id': 'demo-agent', 'session_id': 'demo-session', 'context_epoch': 'epoch-1'}
+
+def project(payload, capture, capture_id, **kwargs):
+    return prepare_context_delivery(payload, scope=scope, capture_id=capture_id, surface='quota_packet',
+        native_projection={'path': capture['fixture'], 'sha256': capture['sha256'],
+            'command_template': 'loopx --format json quota context-read --capture-file ' + capture['fixture']
+                + ' --capture-sha256 ' + capture['sha256'] + " --select '<pointer>'"}, **kwargs)
+
+cold = project(native, captures['original'], 'fixture-capture-1')
+assert cold['projected'] is True
+required = cold['context']
+captures['required'] = save('required-context.json', required)
+current_outcome = required['planning_horizon']['core_goal']['acceptance_contract']['outcome_requirements']['outcomes'][0]
+assert len(current_outcome['requirements']) == 10 and 'sources' not in current_outcome
+assert all(x['description'] == y['description'] for x, y in zip(current_outcome['requirements'], requirements))
+review = current_outcome['requirements'][2]['agent_review']
+assert review == {'id': 'voice-2', 'conclusion': 'unmet', 'basis_current': False, 'independently_verified': False}
+assert required['agent_todo_summary']['backlog_items'][0] == {'todo_id': 'todo_voice', 'context_ref': '/agent_todo_summary/first_open_items/0'}
+parent = current_outcome['supporting_material_pointer']
+detail = read('native-reason', captures['original'], ['--select', parent + '/requirements/2/agent_review/note'])
+assert detail['body']['selections'][0]['value'] == evidence['sample-2']['result']
+
+changed = copy.deepcopy(native)
+changed['work_state']['samples'].append('sample-3')
+changed['work_state']['phase'] = 'verify-repaired-return'
+changed['planning_horizon']['core_goal']['acceptance_contract']['outcome_requirements']['outcomes'][0]['requirements'][2]['agent_review']['basis_current'] = True
+captures['original_next'] = save('projection-next.json', changed)
+current_full = project(changed, captures['original_next'], 'fixture-capture-2')
+warm = project(changed, captures['original_next'], 'fixture-capture-2', baseline=cold['delivery'],
+    continuity={'basis': 'captured_file', 'capture_bytes_verified': True, 'target': cold['delivery']['target']})
+assert warm['delivery']['mode'] == 'delta'
+restored = restore_context_delivery(warm['delivery'], baseline=cold['delivery'], current=current_full['delivery'])
+assert restored['context'] == current_full['context']
+save('cycle-base.json', cold['delivery']); save('cycle-delta.json', warm['delivery'])
+new_epoch = prepare_context_delivery(current_full['context'], scope={**scope, 'context_epoch': 'epoch-2'},
+    capture_id='fixture-capture-3', surface='quota_packet', baseline=cold['delivery'],
+    continuity={'basis': 'captured_file', 'capture_bytes_verified': True, 'target': cold['delivery']['target']})
+assert new_epoch['mode'] == 'full'
+broken = copy.deepcopy(warm['delivery']); broken['changes'] = {'value': {'invented': True}}
+recovery = restore_context_delivery(broken, baseline=cold['delivery'], current=current_full['delivery'])
+assert recovery['mode'] == 'full' and recovery['context'] == current_full['context']
+tiny = {'ok': True, 'state': 'a'}
+tiny_base = prepare_context_delivery(tiny, scope=scope, capture_id='tiny-1', surface='quota_packet')
+tiny_next = prepare_context_delivery({'ok': True, 'state': 'b'}, scope=scope, capture_id='tiny-2', surface='quota_packet',
+    baseline=tiny_base, continuity={'basis':'captured_file', 'capture_bytes_verified': True, 'target': tiny_base['target']})
+assert tiny_next['mode'] == 'full'
+
+summary = lambda r: {k: r[k] for k in ['calls', 'body_bytes', 'output_bytes']}
+rows = [
+    {'case': 'complete_capture', **summary(full)},
+    {'case': 'three_separate_selects', 'calls': sum(r['calls'] for r in separate), 'body_bytes': sum(r['body_bytes'] for r in separate), 'output_bytes': sum(r['output_bytes'] for r in separate)},
+    {'case': 'one_batched_select', **summary(batch)},
+    {'case': 'three_single_level_indexes', 'calls': sum(r['calls'] for r in indexes), 'body_bytes': sum(r['body_bytes'] for r in indexes), 'output_bytes': sum(r['output_bytes'] for r in indexes)},
+    {'case': 'one_depth_two_index', **summary(deep_index)},
+]
+measurements = {'fixture':'synthetic voice-assistant task, 80 history entries; no model/provider call',
+    'source_revision': subprocess.check_output(['git','-C',str(repo),'rev-parse','HEAD'],text=True).strip(),
+    'reader_page_bytes':16000,'reader_output_limit':20000,'reader_rows':rows,
+    'output_bytes_include_cli_page_metadata':True,'page_envelope_size_can_vary_with_local_path':True,
+    'native_projection':{'original_bytes':captures['original']['bytes'],'required_bytes':captures['required']['bytes'],
+        'requirements_retained':10,'original_unchanged':hashlib.sha256((out/'projection.json').read_bytes()).hexdigest()==captures['original']['sha256'],
+        'shared_row_before_bytes':len(raw(row)),'shared_row_reference_bytes':len(raw(required['agent_todo_summary']['backlog_items'][0]))},
+    'cycle_codec':{'current_full_bytes':len(raw(current_full['delivery'])),'delta_bytes':len(raw(warm['delivery'])),
+        'same_epoch_mode':warm['delivery']['mode'],'new_epoch_mode':new_epoch['mode'],
+        'damaged_delta_recovery':recovery['mode'],'tiny_mode':tiny_next['mode'],'reconstructed_exactly':True},
+    'not_measured':['model tokens','prompt cache effects','paid cost','long-horizon effectiveness','native host integration'],
+    'live_goal_or_authority_state_changed':False}
+save('measurements.json', measurements)
+save('manifest.json', {**captures['capture'], 'captures':captures, 'boundary':'Synthetic teaching fixture. Source-based owner and real CLI reader exercised; no native host or model qualification.'})
+questions=[
+ ('requirement',batch,{'zh':'先读齐目标、约束与验收','en':'Read the goal, constraints and acceptance together'},[arg for path in paths for arg in ['--select',path]]),
+ ('index',deep_index,{'zh':'一次看清服务目录的两层结构','en':'Inspect two levels of the provider directory'},['--select','/providers','--list','--list-depth','2']),
+ ('result',sample,{'zh':'转写正确，为什么仍没通过？','en':'The transcript is correct. Why did acceptance fail?'},['--select','/evidence/sample-2/result']),
+ ('conditions',conditions,{'zh':'并排读两次回传条件','en':'Read both return conditions side by side'},['--select','/evidence/sample-1/conditions','--select','/evidence/sample-2/conditions']),
+ ('missing',missing,{'zh':'路径不存在时，整个批次拒绝','en':'A missing path rejects the whole batch'},['--select','/goal/objective','--select','/providers/missing']),
+]
+save('display-cases.json',{'fixture':'capture.json','capture_sha256':captures['capture']['sha256'],'source':{'goal':goal,'providers':providers,'evidence':evidence,'history':'80 complete entries are retained in the downloadable capture.json'},
+    'source_preview_is_complete':False,'cases':[{'id':i,'body':r.get('body',r.get('error')),'questions':q,'args':args} for i,r,q,args in questions]})
+if a.private_receipts:
+    a.private_receipts.mkdir(parents=True,exist_ok=True)
+    (a.private_receipts/'reader-responses.json').write_text(json.dumps(all_receipts,ensure_ascii=False,indent=2)+'\n')
+print(json.dumps(measurements,ensure_ascii=False))
diff --git a/apps/presentation/site/public/blog/context-delivery/index.html b/apps/presentation/site/public/blog/context-delivery/index.html
new file mode 100644
index 0000000000..7f5396eb8b
--- /dev/null
+++ b/apps/presentation/site/public/blog/context-delivery/index.html
@@ -0,0 +1,213 @@
+<!doctype html>
+<html lang="en"><head>
+<meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><meta name="theme-color" content="#fafafa">
+<title>An Agent needs a way to look things up, too · LoopX</title><meta name="description" content="Follow one voice task through progressive reads, JSON Pointers, exact sharing, compaction-cycle deltas, and complete recovery.">
+<link rel="canonical" href="https://loopx-project.github.io/loopx/blog/context-delivery/"><link rel="alternate" hreflang="en" href="https://loopx-project.github.io/loopx/blog/context-delivery/"><link rel="alternate" hreflang="zh-CN" href="https://loopx-project.github.io/loopx/blog/zh/context-delivery/"><link rel="alternate" hreflang="x-default" href="https://loopx-project.github.io/loopx/blog/context-delivery/">
+<meta property="og:type" content="article"><meta property="og:site_name" content="LoopX"><meta property="og:locale" content="en_US"><meta property="og:title" content="An Agent needs a way to look things up, too"><meta property="og:description" content="Follow one voice task through progressive reads, JSON Pointers, exact sharing, compaction-cycle deltas, and complete recovery."><meta property="og:url" content="https://loopx-project.github.io/loopx/blog/context-delivery/"><meta name="twitter:card" content="summary"><link rel="icon" href="data:,"><link rel="stylesheet" href="../blog.css">
+</head><body><a class="skip-link" href="#main">Skip to content</a>
+<header class="site-header"><a class="brand" href="../../"><span class="product-mark" aria-hidden="true"><i></i><i></i></span>LoopX</a><nav aria-label="Main navigation"><a href="../">Blog</a><a href="../../docs/book/">Docs</a></nav><div class="header-actions"><a class="language" href="../zh/context-delivery/" lang="zh-CN" hreflang="zh-CN">中文</a><a class="github" href="https://github.com/loopx-project/loopx">GitHub ↗</a></div></header>
+<main id="main"><div class="article-heading"><a class="back" href="../">← All articles</a><p class="eyebrow">Context delivery</p><h1>An Agent needs a way to look things up, too</h1><p class="lead">Follow one voice task through progressive reads, JSON Pointers, exact sharing, compaction-cycle deltas, and complete recovery.</p><div class="byline"><a href="https://github.com/loopx-project/loopx">LoopX</a><span>·</span><time datetime="2026-11-01">November 1, 2026</time></div></div>
+<div class="article-layout"><aside class="toc"><details><summary>On this page</summary><nav aria-label="On this page"><a href="#example">Follow one task: give an assistant voice input</a><a href="#known-paths">When you know the locations, read them together</a><a href="#discover">When the structure is unfamiliar, index the relevant subtree</a><a href="#requirements">See requirements first, then open their evidence</a><a href="#sharing">Share exact records within one delivery</a><a href="#cycle">On the next continuation, deliver what changed</a><a href="#native-path">When enabled, the default output is a reading entrypoint</a><a href="#recovery">Recover missing context while preserving the original work</a><a href="#evidence">What the measurements establish</a><a href="#reproduce">Read the same material yourself</a></nav></details></aside><article class="prose"><p>Long-running work accumulates material: the original goal, later constraints, attempted routes, failed experiments and current progress. Sending everything again on each continuation repeats more and more content; keeping only a summary can make the original basis of a decision difficult to recover.</p>
+<p>LoopX's context delivery separates these jobs: <strong>preserve complete sources, read the facts needed for the current decision, expand supporting material around questions, and reuse unchanged structures exactly within a valid compaction cycle.</strong></p>
+<p>This article checks the native Codex path at <a href="https://github.com/loopx-project/loopx/tree/73cf83edd6d80275d0c8f44c5289837eebe8ab0d"><code>73cf83ed</code></a>, a 2.2 candidate source. Consult <a href="https://github.com/loopx-project/loopx/releases">Releases</a> for publication status. In that implementation, supported POSIX Codex App/SSH sessions and new benchmark heartbeat trials default to context delivery; saved off remains effective and explicit off is available. When enabled, complete content is saved first and the Agent receives an entrypoint for current facts.</p>
+<p>Think of a capture as a complete book. An index locates its chapters; a JSON Pointer addresses a place inside it. Progressive reading determines how deeply to open the material now. Differential delivery determines what can be reused on the next continuation.</p>
+<h2 id="example">Follow one task: give an assistant voice input</h2>
+<p>Suppose an assistant needs to understand a voice note and reply in its original chat. Its complete material contains the goal, provider constraints, privacy requirements, acceptance and a long discussion of alternatives. This is a teaching example; the example program below generates the complete data in an isolated directory.</p>
+<pre><code class="language-text">capture.json
+├── goal
+│   ├── objective: understand a voice note and reply in its original chat
+│   ├── constraints
+│   │   ├── provider: prefer the already configured speech service
+│   │   └── privacy: no public audio; external processing needs authorization
+│   └── acceptance: correct transcript, same-chat reply, explicit unavailability
+├── providers
+│   ├── configured
+│   │   ├── formats
+│   │   └── authorization
+│   └── alternative
+│       ├── formats
+│       └── authorization
+├── evidence: trial results, input formats and reply destinations
+└── history: 80 complete discussion entries
+</code></pre>
+<p>First, the Agent needs to understand the integration boundary. It must see both the preference for an existing service and the authorization requirement. A provider preference does not authorize sending audio. The historical discussions remain available when comparing alternatives or checking their basis.</p>
+<p>Complete sources are assembled from existing typed owners, with Goal material, full tasks, cumulative acceptance and revisions. Marked generated regions are supplied by canonical tasks; other original narrative, comments and stops remain complete. Headings do not determine which prose may be deleted. This example places its current integration requirements in <code>goal</code>; any additional source-owned mandatory reads still apply.</p>
+<p>The figures below are <strong>actual reader and codec measurements on this synthetic material</strong>. They make no model or speech-service calls. The <a href="example.py">example program</a> generates the complete sources; the <a href="measurements.json">original measurement record</a> preserves the reported figures.</p>
+<h2 id="known-paths">When you know the locations, read them together</h2>
+<p><code>/goal/constraints</code> is a JSON Pointer: enter <code>goal</code> from the JSON root, then <code>constraints</code>. It resembles a file path but addresses <strong>a value inside JSON</strong>.</p>
+<p>The file, Pointer and digest answer different questions. <code>capture.json</code> identifies the complete file; the Pointer identifies a location; SHA-256 pins its version. <code>/requirements/0</code> addresses the first array item. Reordering can change what that index addresses, so use a Pointer with its capture version.</p>
+<p>After running the example, <code>$CAPTURE</code> denotes the output directory’s <code>capture.json</code>; <code>$SHA</code> comes from its <code>manifest.json</code>. Select the three known locations in one request:</p>
+<pre><code class="language-sh">loopx --format json quota context-read \
+  --capture-file &quot;$CAPTURE&quot; --capture-sha256 &quot;$SHA&quot; \
+  --select /goal/objective \
+  --select /goal/constraints \
+  --select /goal/acceptance
+</code></pre>
+<p>This retrieves the objective, complete constraints and acceptance together, including both provider preference and privacy. Repeated <code>--select</code> arguments combine the read request; each value retains its own Pointer.</p>
+<p>The complete capture is <strong>51,547 bytes</strong>. Using the same file, 16,000-byte pages and a 20,000-byte CLI output limit:</p>
+<div class="table-scroll" role="region" tabindex="0" aria-label="Scrollable data table"><table>
+<thead>
+<tr>
+<th>Read</th>
+<th style="text-align:right">CLI calls</th>
+<th style="text-align:right">Returned body</th>
+<th style="text-align:right">Complete CLI responses</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>Page through the complete capture</td>
+<td style="text-align:right">4</td>
+<td style="text-align:right">51,547 B</td>
+<td style="text-align:right">55,607 B</td>
+</tr>
+<tr>
+<td>Select the three locations separately</td>
+<td style="text-align:right">3</td>
+<td style="text-align:right">804 B</td>
+<td style="text-align:right">2,694 B</td>
+</tr>
+<tr>
+<td>Select all three in one batch</td>
+<td style="text-align:right">1</td>
+<td style="text-align:right">674 B</td>
+<td style="text-align:right">1,362 B</td>
+</tr>
+</tbody>
+</table></div>
+<p>The last two rows retrieve identical Pointer/value pairs; repeated requests and framing account for the difference. The first also retrieves the complete history, so its information scope is larger. This table compares the step of reading those three facts now. Capture generation, storage and the initial reference are shared prerequisites.</p>
+<h2 id="discover">When the structure is unfamiliar, index the relevant subtree</h2>
+<p>If the Agent does not know the provider record's fields, it can expand <code>/providers</code> locally. <code>--list</code> returns metadata: Pointers, types, sizes, and member counts for objects and arrays.</p>
+<pre><code class="language-sh">loopx --format json quota context-read \
+  --capture-file &quot;$CAPTURE&quot; --capture-sha256 &quot;$SHA&quot; \
+  --select /providers --list --list-depth 2
+</code></pre>
+<p>Depth two exposes the provider entries and their fields together:</p>
+<pre><code class="language-text">/providers/configured                 object
+/providers/configured/formats         array
+/providers/configured/authorization   string
+/providers/alternative                object
+/providers/alternative/formats        array
+/providers/alternative/authorization  string
+</code></pre>
+<p>Next, batch the format and authorization fields. The index locates them; their values must actually be read before dependent decisions.</p>
+<p>Listing <code>/providers</code> and each of its two children separately takes <strong>3 calls and 2,784 bytes of CLI responses</strong> here. Depth two returns the same set of field addresses in <strong>1 call and 1,283 bytes</strong>.</p>
+<p><strong>Read known addresses directly; index relevant structure when you need discovery.</strong> A small reference may already include the top-level index when it fits. Progressive reading follows the question rather than prescribing a fixed index–single-field–next-level sequence.</p>
+<h2 id="requirements">See requirements first, then open their evidence</h2>
+<p>A correct transcript alone does not establish successful integration. The result must return to the original chat.</p>
+<p>The two example records say:</p>
+<pre><code class="language-text">sample-1: correct transcript, returned to the original chat
+sample-2: correct transcript, replied in another chat
+</code></pre>
+<p>A summary saying “transcription succeeded” can hide the second failure. The implemented native acceptance projection preserves complete requirements and current review state so the Agent first sees the relevant fields:</p>
+<pre><code class="language-json">{
+  &quot;description&quot;: &quot;Return the transcript to its original chat, preserving source, order and audio reference.&quot;,
+  &quot;status&quot;: &quot;unverified&quot;,
+  &quot;agent_review&quot;: {
+    &quot;conclusion&quot;: &quot;unmet&quot;,
+    &quot;basis_current&quot;: false,
+    &quot;independently_verified&quot;: false
+  }
+}
+</code></pre>
+<p>Unmet acceptance and a stale basis stay in the decision layer. Follow the original-material entrypoint to inspect why it failed and which evidence supports the judgment. Agent review and independent verification remain separate facts.</p>
+<p>The implementation returns <code>supporting_material_pointer</code>, locating the outcome in the original capture. Call that returned prefix <code>$P</code>: append <code>/requirements/2/agent_review/note</code> for the explanation, or <code>/requirements/2/agent_review/evidence_refs</code> for evidence references. Use this capture's prefix rather than copying an array position from another file.</p>
+<p>After assembling the voice task into the existing typed acceptance structure, its complete original capture is <strong>57,014 bytes</strong> and necessary view <strong>5,107 bytes</strong>. <strong>All 10 requirement descriptions remain complete, together with unmet/stale/independent-verification facts. The original 57,014 bytes also remain intact.</strong> Supporting history and long explanations have exact expansion addresses.</p>
+<p>Relationship navigation can suggest which outcomes to inspect first using task dependencies, shared acceptance, sources and evidence. Incomplete relationships widen scope, and contrary evidence from other routes stays accessible. Navigation helps order reading; the Agent still determines what affects this decision.</p>
+<h2 id="sharing">Share exact records within one delivery</h2>
+<p>A task can appear in both current work and a queue summary. Repeating an identical complete record adds no fact.</p>
+<p>The native necessary view can retain one complete task and reference it elsewhere:</p>
+<pre><code class="language-json">{
+  &quot;todo_id&quot;: &quot;todo_voice&quot;,
+  &quot;context_ref&quot;: &quot;/agent_todo_summary/first_open_items/0&quot;
+}
+</code></pre>
+<p>The Pointer addresses the complete record in <strong>this same current view</strong>. Serialized separately with a trailing newline, the task record is <strong>1,052 bytes</strong>, versus <strong>80 bytes</strong> for its reference. Complete constraints remain at the original location, and every queue retains its membership and order.</p>
+<p>This is exact sharing. Different revisions, owners, evidence or constraints remain separate even when titles match. Unknown fields and unsupported structures retain their original content. Response-local sharing needs no old session baseline; cross-Turn deltas are a separate mechanism.</p>
+<h2 id="cycle">On the next continuation, deliver what changed</h2>
+<p>The voice task progresses: a third sample is added, work moves from checking the original-chat return to checking a repaired return, and the review basis changes. The objective and most requirements remain unchanged.</p>
+<p>This is where <strong>structured context deltas within a compaction cycle</strong> apply.</p>
+<p>Within a valid cycle, a verified saved baseline supports exact reuse of unchanged text, arrays and objects. Additions, edits, removals and array reordering are explicit. A relocated subtree can reference its original position with current edits overlaid. Reconstruction must match the complete current source.</p>
+<pre><code class="language-text">One valid cycle
+Previous: complete objective + all requirements + samples 1, 2 + old work state
+Current:  add sample 3; update work state and review basis
+Restore:  the complete current context
+</code></pre>
+<p>For the same synthetic task and scope, the codec produces:</p>
+<div class="table-scroll" role="region" tabindex="0" aria-label="Scrollable data table"><table>
+<thead>
+<tr>
+<th>Condition</th>
+<th>Result</th>
+<th>Size or readback</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>Encode the complete current view</td>
+<td>full</td>
+<td>5,543 B</td>
+</tr>
+<tr>
+<td>Reuse a verified baseline within the cycle</td>
+<td>delta</td>
+<td>2,164 B; exact value-by-value reconstruction</td>
+</tr>
+<tr>
+<td>Change context epoch</td>
+<td>full</td>
+<td>No reuse of the old cycle's baseline</td>
+</tr>
+<tr>
+<td>Damage the delta</td>
+<td>Recover current full</td>
+<td>Exact match with the complete current view</td>
+</tr>
+<tr>
+<td>Change a tiny two-field input</td>
+<td>full</td>
+<td>Keep complete delivery when delta overhead is unsuitable</td>
+</tr>
+</tbody>
+</table></div>
+<p>This table measures codec output. The native adapter also compares actual delivery bytes including references, page framing and reading instructions, selecting full when preferable. Size comparisons serve efficient delivery without replacing completeness.</p>
+<h2 id="native-path">When enabled, the default output is a reading entrypoint</h2>
+<p>Connect these operations back to the currently supported native Codex quota path:</p>
+
+<figure class="diagram"><p class="diagram-label">The enabled delivery path</p><ol><li><strong>Complete source</strong>: projection.json preserves current facts.</li><li><strong>Necessary view</strong>: required-context.json keeps complete requirements and points back to supporting originals.</li><li><strong>Cycle delivery</strong>: verify baseline and scope; choose full or delta.</li><li><strong>Current reader</strong>: first read admission, stops, the original task and accumulated requirements; include an index and short overview when they fit. Follow Pointers for supporting detail.</li></ol><figcaption>Saved files are verifiable sources. Model input still depends on the reads actually completed.</figcaption></figure>
+<p>One useful property is that <strong>even with <code>mode: &quot;delta&quot;</code>, the Agent can select facts directly through current <code>recovery</code>.</strong> It does not first need to read an old baseline or replay every delta. Delta's <code>path</code> may address <code>delivery.json</code>; <code>recovery</code> and <code>select_command</code> address the complete current view. <code>context_details</code> then connects supporting material to the original capture.</p>
+<p>Native navigation also stores complete capture/selection digests in immutable private reader references. The Agent copies the returned reference; the CLI still verifies the complete digests, selection and cursor on every page. SHA256 itself is not shortened. A <code>first_read_command</code> starts a selection; it does not establish that all required sources were read.</p>
+<pre><code class="language-bash"># Copy the original recovery.reference_file from current returned navigation.
+loopx --format json quota context-read \
+  --reference-file &quot;$RECOVERY_READER_REFERENCE&quot; \
+  --select &quot;$POINTER_A&quot; --select &quot;$POINTER_B&quot;
+</code></pre>
+<p>A continuation reference pins its selection: follow its <code>next_command</code> to EOF and return to the original recovery reference to change Pointers. Very small budgets may retain the explicit file/digest interface. The teaching measurements above use that compatible interface and retain their original conditions.</p>
+<p>Saved-file continuity and what the model currently retains are separate facts. Verifiable files do not establish that the model remembers every original passage.</p>
+<h2 id="recovery">Recover missing context while preserving the original work</h2>
+<p>After host compaction, a subsequent work Turn builds a new complete baseline. Original goals, requirements and sources remain available for necessary reads.</p>
+<p>If compaction, missing pages or truncated output interrupt an unfinished Turn, recover missing facts from its original capture while retaining task, effect and settlement identity. If a voice result was already sent but its receipt was lost, recovering context must not become sending the result again.</p>
+<p>Reading has explicit failure boundaries:</p>
+<ul>
+<li><strong>Changed bytes with an unchanged digest:</strong> reject the read and verify the version.</li>
+<li><strong>A missing Pointer:</strong> reject the whole batch; index a known parent to recover. A present JSON <code>null</code> returns normally.</li>
+<li><strong>Paged content:</strong> follow <code>next_command</code> with capture digest, selection digest and byte cursor; combine contiguous content in order. Selection EOF covers only that selection.</li>
+<li><strong>Unknown or inapplicable structures:</strong> retain complete content and original read obligations rather than guessing which prose can be hidden.</li>
+</ul>
+<figure class="diagram"><p class="diagram-label">Continuity and recovery</p><p><strong>One valid cycle</strong>: complete baseline → changed facts and delta → exact reconstruction.</p><p><strong>New cycle or known continuity loss</strong>: complete current source → read necessary facts again.</p><figcaption>An unfinished Turn retains its original capture, work and settlement identity. Reading recovery does not repeat external effects.</figcaption></figure>
+<h2 id="evidence">What the measurements establish</h2>
+<p>The example separates three mechanisms: <strong>avoid repeatedly moving history not currently needed, combine reads that belong together, and avoid retransmitting unchanged verified structures.</strong> Complete sources, requirements and recovery connect them.</p>
+<p>Reader figures include actual CLI page metadata; local path length affects a small amount of framing. Projection figures compare capture bodies; the cycle table compares codec output. The reproduction script checks these distinct measurements and exact reconstruction.</p>
+<p>Real long-running tasks must also count necessary later reads, recovery, cache hits, model input/output, tool calls, waiting and human attention. Effectiveness depends on constraints understood, decisions made and accepted outcomes. This synthetic example measures the mechanical path; real model benefit still needs comparable-task evidence.</p>
+<p>Implemented scope includes complete sources, file entrypoints, batch selection, index depth, applicable acceptance layering, exact sharing, cycle deltas and recovery. Broader decision-stage candidate, preference and Explore delivery and C1's universal input convergence remain unfinished. Supported Codex sessions default on without a saved preference. Disable in Settings → This machine → Capabilities → Differential context → Codex; saved off survives upgrade. A command or new benchmark trial can use <code>--context-delivery off</code>. Trials do not inherit the machine switch, and existing frozen trials are not rewritten. Saving settings, exact hook/configuration setup and actual adoption remain separate checks; unavailable hooks retain full delivery. Ordinary CLI, unsupported hosts and non-heartbeat benchmarks retain their existing full paths. Final 2.2 release qualification follows the exact release version.</p>
+<h2 id="reproduce">Read the same material yourself</h2>
+<p><a href="example.py">example.py</a> generates this complete synthetic voice task and invokes the existing reader, progressive projection and delta owners. It checks selected values, directory addresses, all ten requirements, shared references and complete recovery. It registers no Goal, admits or settles no Turn, and calls no model or speech service.</p>
+<p>Prepare the original measurement checkout, <code>a4a0fad889d91cba0d945ce658788bdb76ba351e</code>, and its compatible dependencies. Run from that checkout’s root, substituting the downloaded program path. The output directory must be empty.</p>
+<pre><code class="language-sh">uv run --extra test python /path/to/example.py \
+  --loopx-root &quot;$PWD&quot; --output .local/context-delivery-example
+</code></pre>
+<p>Generated <code>capture.json</code> retains all 80 history entries. <code>projection.json</code> and <code>required-context.json</code> hold the complete/necessary views; <code>cycle-base.json</code> and <code>cycle-delta.json</code> hold cycle encodings; <code>manifest.json</code> pins files and digests. Production reads use currently returned paths, never copied teaching fields or another capture’s array indexes.</p>
+<p>The <a href="measurements.json">original measurement record</a> pins this article’s figures. Running on other source can check its mechanisms but cannot rewrite the original observation. Local path length also affects page framing bytes. Understanding this example requires no new research run.</p>
+<p>Sources: <a href="https://github.com/loopx-project/loopx/blob/0e78a19c277f4ca3d44313787162bc0444065172/docs/reference/required-work-context.md">complete-delivery contract</a>, <a href="https://github.com/loopx-project/loopx/blob/0e78a19c277f4ca3d44313787162bc0444065172/loopx/control_plane/quota/progressive_context.ts">progressive projection</a>, <a href="https://github.com/loopx-project/loopx/blob/0e78a19c277f4ca3d44313787162bc0444065172/loopx/control_plane/quota/context_selection.ts">selection/index</a>, <a href="https://github.com/loopx-project/loopx/blob/0e78a19c277f4ca3d44313787162bc0444065172/loopx/control_plane/quota/context_delivery.ts">delta/recovery</a>. The example ran on <code>a4a0fad</code>; those three core owners are byte-identical in <code>0e78a19</code>. Native final delivery also accounts for references and later reads, beyond codec output.</p>
+<nav class="article-route" aria-label="Continue reading"><p><a href="../typescript-control-plane-refactor/">TypeScript: repairing semantics</a> · <a href="../edgebench-feedback-and-memory/">EdgeBench: did mechanisms improve outcomes?</a></p></nav></article></div></main>
+<footer class="site-footer"><a class="brand" href="../../">LoopX</a><p>Keep work moving. Keep people in control.</p><a href="#main" aria-label="Back to top">↑</a></footer></body></html>
diff --git a/apps/presentation/site/public/blog/context-delivery/measurements.json b/apps/presentation/site/public/blog/context-delivery/measurements.json
new file mode 100644
index 0000000000..f60fefc92c
--- /dev/null
+++ b/apps/presentation/site/public/blog/context-delivery/measurements.json
@@ -0,0 +1 @@
+{"fixture":"synthetic voice-assistant task, 80 history entries; no model/provider call","source_revision":"a4a0fad889d91cba0d945ce658788bdb76ba351e","reader_page_bytes":16000,"reader_output_limit":20000,"reader_rows":[{"case":"complete_capture","calls":4,"body_bytes":51547,"output_bytes":55607},{"case":"three_separate_selects","calls":3,"body_bytes":804,"output_bytes":2694},{"case":"one_batched_select","calls":1,"body_bytes":674,"output_bytes":1362},{"case":"three_single_level_indexes","calls":3,"body_bytes":776,"output_bytes":2784},{"case":"one_depth_two_index","calls":1,"body_bytes":574,"output_bytes":1283}],"output_bytes_include_cli_page_metadata":true,"page_envelope_size_can_vary_with_local_path":true,"native_projection":{"original_bytes":57014,"required_bytes":5107,"requirements_retained":10,"original_unchanged":true,"shared_row_before_bytes":1052,"shared_row_reference_bytes":80},"cycle_codec":{"current_full_bytes":5543,"delta_bytes":2164,"same_epoch_mode":"delta","new_epoch_mode":"full","damaged_delta_recovery":"full","tiny_mode":"full","reconstructed_exactly":true},"not_measured":["model tokens","prompt cache effects","paid cost","long-horizon effectiveness","native host integration"],"live_goal_or_authority_state_changed":false}
diff --git a/apps/presentation/site/public/blog/edgebench-feedback-and-memory/index.html b/apps/presentation/site/public/blog/edgebench-feedback-and-memory/index.html
index 779c14e98e..da79912e08 100644
--- a/apps/presentation/site/public/blog/edgebench-feedback-and-memory/index.html
+++ b/apps/presentation/site/public/blog/edgebench-feedback-and-memory/index.html
@@ -16,7 +16,7 @@
 <link rel="stylesheet" href="../images/edgebench-feedback-and-memory/article.css">
 </head>
 <body><main id="main"><div class="language"><a href="../">← LoopX Blog</a><a href="../zh/edgebench-feedback-and-memory/" lang="zh-CN">中文</a></div>
-<header><p class="muted">Ruiteng Huang · October 29, 2026</p><h1>What does an agent achieve with ten more hours?</h1><p class="subtitle">How EdgeBench reshaped the LoopX control plane</p><p class="lead">A research run can start ahead, then barely improve for ten hours. It can keep changing code and lose its best result. These failures made us revisit goals, feedback, experiment size and recovery.</p><p>The work began with trace diagnosis in early October: repair evaluation and continuation, follow evidence into the next experiment, then charge the control plane for its own cost. This account follows that progression, including results that challenged the approach.</p></header><nav aria-label="Article contents"><a href="#research-history">Timeline</a><a href="#ledger">Reliable feedback</a><a href="#goal-continuity">Goal continuity</a><a href="#experiment-stride">Experiment size</a><a href="#recovery-state">Recovery</a><a href="#later-common-windows">Later outcomes</a><a href="#context">Total cost</a></nav><section id="thesis">
+<header><p class="muted">Ruiteng Huang · October 29, 2026</p><h1>What does an agent achieve with ten more hours?</h1><p class="subtitle">How EdgeBench reshaped the LoopX control plane</p><p class="lead">A research run can start ahead, then barely improve for ten hours. It can keep changing code and lose its best result. These failures made us revisit goals, feedback, experiment size and recovery.</p><p>The work began with trace diagnosis in early October: repair evaluation and continuation, follow evidence into the next experiment, then charge the control plane for its own cost. This account follows that progression, including results that challenged the approach.</p></header><p>This article asks how mechanisms changed real research and where they did not help. For what actually reaches the next decision, begin with <a href="../context-delivery/">progressive and differential context delivery</a>, then return to the outcomes and complete costs below.</p><nav aria-label="Article contents"><a href="#research-history">Timeline</a><a href="#ledger">Reliable feedback</a><a href="#goal-continuity">Goal continuity</a><a href="#experiment-stride">Experiment size</a><a href="#recovery-state">Recovery</a><a href="#later-common-windows">Later outcomes</a><a href="#context">Total cost</a></nav><section id="thesis">
 <p>Here, kernel means LoopX’s shared goal, admission, transaction and recovery rules. LoopX keeps the original goal, acceptance conditions, work ownership and evidence durable across sessions and hosts. Its control plane constrains state transitions and supplies feedback for the model’s next choice. It does not certify that the choice is insightful. A recorded finding, a read receipt and a replan entry are intermediate evidence; the relevant chain ends in actual work and a validated outcome.</p>
 <p>The TypeScript refactor article explains ownership and <a href="../typescript-control-plane-refactor/#model-assisted-semantics">model-assisted semantic repair</a>. Below, we follow how these rules affect actual research work.</p>
 <ol class="flow" aria-label="Evidence-driven work cycle"><li><strong>Goal</strong><span>Acceptance and scope</span></li><li><strong>Evidence</strong><span>Results and limitations</span></li><li><strong>Decision</strong><span>Continue or change course</span></li><li><strong>Work</strong><span>Execute and validate</span></li><li><strong>Retention</strong><span>Keep the best valid result</span></li></ol>
@@ -75,7 +75,7 @@ <h3 id="input-share">Measure structural input separately</h3>
 <details><summary>Earlier byte comparisons and a withdrawn measurement</summary><span id="staged-context"></span><span id="staged-transport"></span>
 <p>Historical offline replay illustrates why totals matter: structured Host and native presentation bytes fell 57.72% and 60.23%, while native entry plus full recovery rose 6.37%. These are historical byte observations, not current-head model-token results. An earlier offline probe also reported a 2.25% increase in CLI bytes, but its qualification as an actual CLI delivery measurement was withdrawn: it omitted final CLI compaction and reformatted entry output. That figure remains only as an invalid historical measurement and supports no complete-delivery or cost conclusion. A 60% smaller view cannot be reported as 60% lower total cost.</p>
 </details>
-<p>Our current efficiency work connects ordinary and staged delivery to the shared transport, reduces repeated reads and rebinding, and removes avoidable settlement round trips. The default with differencing off matters as much as the opt-in path. Enabled delivery also has to recover correctly and remain easy to activate across the product and benchmark. The reference of <strong>15% for all mechanisms combined</strong> remains unqualified; it is neither a separate allowance per mechanism nor a reason to omit failures or reconstruction.</p>
+<p>This efficiency work connects ordinary and staged delivery to the shared transport, reduces repeated reads and rebinding, and removes avoidable settlement round trips. The <a href="../context-delivery/">complete mechanism and voice-task example</a> explains progressive selection, necessary facts, exact sharing and cycle deltas. Actual enabled reads, the explicit-off path and recovery need separate checks; newer implementation cannot retroactively qualify historical experiments. The reference of <strong>15% for all mechanisms combined</strong> remains unqualified; it is neither a separate allowance per mechanism nor a reason to omit failures or reconstruction.</p>
 </section><details><summary>Same-checkpoint continuation: outcomes and complete usage</summary><section id="memory"><h3>Ask whether evidence changed the next work</h3>
 <span id="decision-followthrough"></span><p>A mature checkpoint helps inspect a specific decision boundary. Both receivers inherit the same scientific state and incumbent; we then follow the evidence they read, the experiment they choose, the work they actually perform and the native feedback. A negative local result can be useful if it rules out a branch under stated conditions. Replanning need not force a direction change when continuing is justified.</p>
 <p>Recent work on <a href="https://github.com/loopx-project/loopx/pull/7269">#7269</a> makes the reader first consume the goal, facts and feedback, then the writeback format. It also releases obsolete task-selection preference and preserves the original Turn settlement after a successor is created. This addresses two observed sources of wasted interaction: reading writer instructions before deciding, and needing another round to resolve which work was settled.</p>
@@ -110,6 +110,6 @@ <h3 id="input-share">Measure structural input separately</h3>
 <p>The context study recorded on October 28 starts Grid, Schema and Ad Placement from their original tasks with Sol/max and an 18-hour upper limit per case. Historical Official or older LoopX runs provide descriptive references where usable. Their model/effort, source, scorer, opportunity and clock differences remain visible; they are not strict matched controls. A new baseline is warranted where the old material cannot answer the relevant question. Attempts with different source versions, continuity bases or transports are analyzed separately, rather than pooled as one treatment.</p>
 <p>First verify that actual delivery changes: the initial full read, a subsequent delta with its continuity basis stated, complete fallback after known baseline loss, and a full review-to-work interaction. Then compare useful progress, retained artifacts and the complete usage vector. Requested flags, receipts and smaller local packets cannot substitute for that evidence. If the feature fails its intended behavior, stop the affected attempt, preserve its costs and history, repair it and use a new attempt identity.</p>
 <p>The first Grid and Ad interactions on the new native Hook path have completed full paging, one delta and subsequent task work. Within each same capture, the delta payload was 19.53% and 19.48% smaller than its corresponding full packet. These are single-read payload comparisons: they exclude page envelopes, subsequent model input, hooks, recovery and review costs. They do not establish lower total cost. A complete review-to-native-outcome cycle, sustained benefit and failure recovery remain to be verified.</p><p>Our effectiveness target is useful progress after many hours and reliable retention of it. Our efficiency target is comparable accepted value with less complete cost and human attention. The next result must address both. Current runs retain the original deadline, and failed or replaced attempts retain their costs and history.</p>
-</section><footer><p>Numerical evidence retains each stated historical model, version, window and validity boundary. Public implementation: <a href="https://github.com/loopx-project/loopx">LoopX</a>. Earlier detailed research records remain in the <a href="https://github.com/loopx-project/loopx/blob/a9a720db/apps/presentation/site/public/blog/edgebench-feedback-and-memory/index.html">previous article revision</a>. Raw trajectories, hidden evaluator material, runtime credentials and private operating context are not published here.</p></footer>
+<p>This remains the October 28 research checkpoint. Later reader, default-policy or codec merges do not automatically pass its unresolved checks. The mechanism article’s <a href="../context-delivery/#evidence">synthetic byte measurements</a> and this section’s model trajectories are different evidence layers, not a combined savings result.</p></section><footer><p>Numerical evidence retains each stated historical model, version, window and validity boundary. Public implementation: <a href="https://github.com/loopx-project/loopx">LoopX</a>. Earlier detailed research records remain in the <a href="https://github.com/loopx-project/loopx/blob/a9a720db/apps/presentation/site/public/blog/edgebench-feedback-and-memory/index.html">previous article revision</a>. Raw trajectories, hidden evaluator material, runtime credentials and private operating context are not published here.</p></footer>
 </main></body>
 </html>
diff --git a/apps/presentation/site/public/blog/index.html b/apps/presentation/site/public/blog/index.html
index 8518f51e2a..94151f8d27 100644
--- a/apps/presentation/site/public/blog/index.html
+++ b/apps/presentation/site/public/blog/index.html
@@ -29,11 +29,15 @@
     <a href="../blog/" aria-current="page">Blog</a>
     <a href="../docs/book/en/">Docs</a>
   </nav>
-  <div class="header-actions"><a class="language" href="../blog/zh/" lang="zh-CN" hreflang="zh-CN" aria-label="阅读中文版">中文</a><a class="github" href="https://github.com/huangruiteng/loopx">GitHub <span aria-hidden="true">↗</span></a></div>
+  <div class="header-actions"><a class="language" href="../blog/zh/" lang="zh-CN" hreflang="zh-CN" aria-label="阅读中文版">中文</a><a class="github" href="https://github.com/loopx-project/loopx">GitHub <span aria-hidden="true">↗</span></a></div>
 </header>
 <main id="main" class="blog-index">
   <div class="index-heading"><p class="eyebrow">LoopX · Blog</p><h1>Engineering the long run.</h1><p class="lead">Design, engineering, and field notes on long-horizon agents.</p></div>
-  <nav class="reading-routes" aria-labelledby="reading-routes"><h2 id="reading-routes">Read by question</h2><ul><li><b>Get the overview</b><span>Start with the short introduction, then choose a scenario.</span><p><a href="semantic-software-development/">Introduction</a> <span aria-hidden="true">→</span> <a href="application-scenarios/">Scenarios</a></p></li><li><b>Understand the mechanisms</b><span>Architecture explains responsibilities; Kanban develops collaboration contracts.</span><p><a href="from-one-shot-agents-to-long-horizon-control/">Architecture</a> <span aria-hidden="true">→</span> <a href="agent-facing-kanban/">Native Kanban</a></p></li><li><b>Examine evidence and limits</b><span>Research and postmortems address effectiveness and reliability.</span><p><a href="edgebench-feedback-and-memory/">Research</a> <span aria-hidden="true">→</span> <a href="five-freshness-incidents/">Postmortem</a></p></li><li><b>Explore self-improvement</b><span>Follow the public history of improvements entering subsequent work.</span><p><a href="long-horizon-rsi/">Bootstrapping and RSI</a></p></li></ul></nav>
+  <nav class="reading-routes" aria-labelledby="reading-routes"><h2 id="reading-routes">Read by question</h2><ul><li><b>Understand LoopX</b><span>Which decisions and responsibilities must long-running work retain?</span><p><a href="from-one-shot-agents-to-long-horizon-control/">Architecture</a> <span aria-hidden="true">→</span> <a href="application-scenarios/">Scenarios</a></p></li><li><b>Repair the control rules</b><span>Start with retries, transactions, authority and recovery counterexamples.</span><p><a href="typescript-control-plane-refactor/">TypeScript and semantics</a></p></li><li><b>Choose what to read next</b><span>Follow one task through progressive reads and cycle deltas.</span><p><a href="context-delivery/">Context delivery</a></p></li><li><b>Check whether it helped</b><span>Separate the starting point, later gains, best retention and complete cost.</span><p><a href="edgebench-feedback-and-memory/">EdgeBench study</a> <span aria-hidden="true">→</span> <a href="five-freshness-incidents/">Postmortem</a></p></li></ul></nav>
+  <article class="post-listing">
+    <div><p class="eyebrow">Context delivery · Mechanisms and examples</p><p class="listing-date"><time datetime="2026-11-01">November 1, 2026</time></p></div>
+    <div><h2><a href="context-delivery/">An Agent needs a way to look things up, too</a></h2><p>One voice task explains JSON Pointers, batched selection, index depth, complete requirements, exact sharing and compaction-cycle deltas. Synthetic byte measurements remain distinct from real model benefit.</p><a class="read-post" href="context-delivery/">Read article <span aria-hidden="true">↗</span></a></div>
+  </article>
   <article class="post-listing">
     <div><p class="eyebrow">Research notes · EdgeBench and LHTB</p><p class="listing-date"><time datetime="2026-10-16">October 16, 2026</time></p></div>
     <div><h2><a href="edgebench-long-horizon-repairs/">EdgeBench / LHTB: notes from historical runs</a></h2><p>Exploratory notes by songoow on historical, partly interrupted EdgeBench/LHTB runs. The feedback-first option is withdrawn; these are not official LoopX results or current capability claims.</p><a class="read-post" href="edgebench-long-horizon-repairs/">Read the article <span aria-hidden="true">↗</span></a></div>
@@ -47,8 +51,8 @@
     <div><h2><a href="semantic-software-development/">Agentic Software: Infrastructure for Long-Horizon Development</a></h2><p>Using LoopX to explore infrastructure for agentic software: preserve goals, evidence, and human feedback across sessions, and carry exploration into verifiable delivery.</p><a class="read-post" href="semantic-software-development/">Read article <span aria-hidden="true">↗</span></a></div>
   </article>
   <article class="post-listing">
-    <div><p class="eyebrow">Research notes · EdgeBench</p><p class="listing-date"><time datetime="2026-10-05">October 5, 2026</time></p></div>
-    <div><h2><a href="edgebench-feedback-and-memory/">Giving long-horizon agents a reason for their next step</a></h2><p>Portfolio and Lean traces illuminate LoopX’s semantic control plane: trustworthy feedback, continuation, scoped evidence, progressive context and research choices. Validated repairs are distinct from unproven capability gains.</p><a class="read-post" href="edgebench-feedback-and-memory/">Read article <span aria-hidden="true">↗</span></a></div>
+    <div><p class="eyebrow">Research notes · EdgeBench</p><p class="listing-date"><time datetime="2026-10-05">First published October 5, 2026</time> · <span>Revised October 29</span></p></div>
+    <div><h2><a href="edgebench-feedback-and-memory/">What does an agent achieve with ten more hours?</a></h2><p>Follow the research from early to late October: reliable feedback, goals, experiment size and recovery, tested against Schema’s plateau and complete usage.</p><a class="read-post" href="edgebench-feedback-and-memory/">Read article <span aria-hidden="true">↗</span></a></div>
   </article>
   <article class="post-listing">
     <div><p class="eyebrow">Design perspective · Self-improvement</p><p class="listing-date"><time datetime="2026-10-02">October 2, 2026</time></p></div>
diff --git a/apps/presentation/site/public/blog/typescript-control-plane-refactor/index.html b/apps/presentation/site/public/blog/typescript-control-plane-refactor/index.html
index ad93fa784d..af65cd6eed 100644
--- a/apps/presentation/site/public/blog/typescript-control-plane-refactor/index.html
+++ b/apps/presentation/site/public/blog/typescript-control-plane-refactor/index.html
@@ -13,12 +13,31 @@
 <a class="skip-link" href="#main">Skip to content</a>
 <header class="site-header"><a class="brand" href="../../"><span class="product-mark" aria-hidden="true"><i></i><i></i></span>LoopX</a><nav aria-label="Primary navigation"><a href="../">Blog</a><a href="../../docs/book/en/">Docs</a></nav><div class="header-actions"><a class="language" href="../../blog/zh/typescript-control-plane-refactor/" lang="zh-CN" hreflang="zh-CN">中文</a><a class="github" href="https://github.com/loopx-project/loopx">GitHub ↗</a></div></header>
 <main id="main"><div class="article-heading"><a class="back" href="../">← All articles</a><p class="eyebrow">LoopX 2.0 · Engineering</p><h1>LoopX 2.0: Two Months of TypeScript Control-Plane Engineering</h1><p class="lead">An effect succeeds without a checkpoint. An expired executor returns with a valid receipt. An evidence correction restarts finished work. Two months of refactoring brought these problems under complete transactions and shared semantics.</p><div class="byline"><a href="https://github.com/huangruiteng">Ruiteng Huang</a><span>·</span><time datetime="2026-10-16">October 16, 2026</time><span>·</span><span>LoopX creator</span><span>·</span><time datetime="2026-10-29">Updated October 29, 2026</time></div></div>
-<div class="article-layout"><aside class="toc"><div class="desktop-contents"><p class="toc-caption">Contents</p><nav aria-label="Article contents"><a href="#section-1">1. Reconstruct the history: the migration plan changed too</a><a href="#section-2">2. Core control-plane statistics across the full period</a><a href="#section-3">3. Start with the Effect Program: agree on what happened</a><a href="#section-4">4. Migrate a complete transaction: two calls can be right</a><a href="#section-5">5. Shared authority: separate domain rules from storage primitives</a><a href="#section-6">6. After SQLite: retained history needs a cost model</a><a href="#section-7">7. Song&#39;s Semantics: connect definition, production, and interpretation</a><a href="#model-assisted-semantics">8. How stronger models repair semantics</a><a href="#section-8">9. Callers and defaults determine whether migration reaches users</a><a href="#section-9">10. Recover the original result while protecting current authority</a><a href="#section-10">11. CLI output budgets: protect decision semantics before compression</a><a href="#section-11">12. Final retirement: preserve credit and account for the deletions</a><a href="#section-12">13. Community contributions and the next step</a></nav></div><details class="mobile-contents"><summary>Contents</summary><nav aria-label="Article contents"><a href="#section-1">1. Reconstruct the history: the migration plan changed too</a><a href="#section-2">2. Core control-plane statistics across the full period</a><a href="#section-3">3. Start with the Effect Program: agree on what happened</a><a href="#section-4">4. Migrate a complete transaction: two calls can be right</a><a href="#section-5">5. Shared authority: separate domain rules from storage primitives</a><a href="#section-6">6. After SQLite: retained history needs a cost model</a><a href="#section-7">7. Song&#39;s Semantics: connect definition, production, and interpretation</a><a href="#model-assisted-semantics">8. How stronger models repair semantics</a><a href="#section-8">9. Callers and defaults determine whether migration reaches users</a><a href="#section-9">10. Recover the original result while protecting current authority</a><a href="#section-10">11. CLI output budgets: protect decision semantics before compression</a><a href="#section-11">12. Final retirement: preserve credit and account for the deletions</a><a href="#section-12">13. Community contributions and the next step</a></nav></details></aside><article class="prose">
-<p>LoopX 2.0 is out. This is an account of the history and technical details behind its TypeScript refactor.</p>
+<div class="article-layout"><aside class="toc"><div class="desktop-contents"><p class="toc-caption">Contents</p><nav aria-label="Article contents"><a href="#model-assisted-semantics">1. The semantic questions we put stronger models to work on</a><a href="#section-1">2. Reconstruct the history: the migration plan changed too</a><a href="#section-3">3. Start with the Effect Program: agree on what happened</a><a href="#section-4">4. Migrate a complete transaction: two calls can be right</a><a href="#section-5">5. Shared authority: separate domain rules from storage primitives</a><a href="#section-6">6. After SQLite: retained history needs a cost model</a><a href="#section-7">7. Song&#39;s Semantics: connect definition, production, and interpretation</a><a href="#section-8">8. Callers and defaults determine whether migration reaches users</a><a href="#section-9">9. Recover the original result while protecting current authority</a><a href="#section-10">10. CLI output budgets: protect decision semantics before compression</a><a href="#section-11">11. Final retirement: preserve credit and account for the deletions</a><a href="#section-2">12. Core control-plane statistics across the full period</a><a href="#section-12">13. Community contributions and the next step</a></nav></div><details class="mobile-contents"><summary>Contents</summary><nav aria-label="Article contents"><a href="#model-assisted-semantics">1. The semantic questions we put stronger models to work on</a><a href="#section-1">2. Reconstruct the history: the migration plan changed too</a><a href="#section-3">3. Start with the Effect Program: agree on what happened</a><a href="#section-4">4. Migrate a complete transaction: two calls can be right</a><a href="#section-5">5. Shared authority: separate domain rules from storage primitives</a><a href="#section-6">6. After SQLite: retained history needs a cost model</a><a href="#section-7">7. Song&#39;s Semantics: connect definition, production, and interpretation</a><a href="#section-8">8. Callers and defaults determine whether migration reaches users</a><a href="#section-9">9. Recover the original result while protecting current authority</a><a href="#section-10">10. CLI output budgets: protect decision semantics before compression</a><a href="#section-11">11. Final retirement: preserve credit and account for the deletions</a><a href="#section-2">12. Core control-plane statistics across the full period</a><a href="#section-12">13. Community contributions and the next step</a></nav></details></aside><article class="prose">
+<p>Retrying an operation can execute its effect twice. Reading back a success receipt can revive execution rights that have already expired. These boundaries between execution, storage and recovery are central to LoopX’s TypeScript refactor.</p>
+<h2 id="model-assisted-semantics">1. The semantic questions we put stronger models to work on</h2>
+<p>We use stronger models in design, implementation and review, especially to trace assumptions across files and runtimes. The difficult cases often combine individually reasonable checks into an unsafe execution order. Core PRs in August and September already dealt with these problems; they were part of the migration itself.</p>
+<h3>The effect happened, but its checkpoint did not. Is retry safe?</h3>
+<p>A provider succeeds, then the process crashes before writing the checkpoint. The journal says unfinished; a blind retry may execute twice. Treating every uncertain result as success would instead lose work that never happened. A try/catch cannot settle that distinction.</p>
+<p>On August 22, <a href="https://github.com/loopx-project/loopx/pull/3485">#3485</a> introduced a durable prepared attempt and stable effect identity before execution. Recovery asks the provider: <strong>confirmed committed means checkpoint the original result; confirmed absent permits execution with the same identity; unknown remains pending recovery.</strong> Effect order, receipt prefixes and identity checks remain part of the contract. This is not arbitrary external exactly-once execution: confirming the result depends on provider recovery support.</p>
+<p>This complements the preflight in <a href="https://github.com/loopx-project/loopx/pull/3464">#3464</a>. Before execution, determine whether the effect is allowed; after interruption, determine whether it already happened. Moving Python functions to TS one at a time does not protect both boundaries.</p>
+<p>On September 13, <a href="https://github.com/loopx-project/loopx/pull/4286">#4286</a> converged receipt recovery for seven Todo operations on one owner while retaining a finer distinction. Suppose two agents update a task: A commits first; B receives a definite version-conflict rejection, then loses its connection while reading the receipt. <strong>The later read failure must not erase the earlier rejection.</strong> If the connection drops before the commit response arrives, the result remains uncertain and recovery must use the original operation identity.</p>
+<p>Both paths can encounter a network error, but they require different next steps. The <a href="https://github.com/loopx-project/loopx/blob/c0b572d2d508bb10c32701057dd71ff4f8eb663c/loopx/control_plane/coordination/command_receipt.ts">shared implementation</a> attempts the write once, then reads the original receipt. Its <a href="https://github.com/loopx-project/loopx/blob/c0b572d2d508bb10c32701057dd71ff4f8eb663c/tests/control_plane_ts/command_receipt.test.ts">regressions</a> distinguish conclusive rejection, commit uncertainty and exact-receipt recovery. Shared error handling must retain the phase of failure and facts already established.</p>
+<h3>Claiming work and acquiring execution rights must commit together</h3>
+<p>Two agents see an unclaimed task. If the claim is written before the lease is acquired, who owns the intermediate state? If an earlier claimant returns with a receipt after its lease expires, may it keep writing?</p>
+<p>From the coordination foundations in <a href="https://github.com/loopx-project/loopx/pull/3529">#3529</a> and <a href="https://github.com/loopx-project/loopx/pull/3669">#3669</a> to the September 6 transaction in <a href="https://github.com/loopx-project/loopx/pull/4032">#4032</a>, claim, lease and operation receipt converge on one conditional commit. The <a href="https://github.com/loopx-project/loopx/pull/3798">#3798</a> store owns atomic persistence; the domain owner checks identity, scope and legal transitions. <strong>A receipt proves a past claim succeeded. The current lease and epoch determine permission now.</strong> Replay must recover the original result without reviving expired execution rights. Storage revision, domain revision and lease epoch remain different identities.</p>
+<p>Idempotency therefore requires more than returning an old success. Recovery must remember history and respect present authority. Foundation, shadow and production qualification arrived in stages; the first interface merge did not establish deployment of every backend.</p>
+<h3>Why could correcting evidence restart finished work?</h3>
+<p>A planning update corrects evidence without changing monitor state. Rebuilding the object from defaults can accidentally rearm an already satisfied monitor. Conversely, an explicitly empty list or <code>false</code> cannot be interpreted as an omitted input.</p>
+<p>On September 10, <a href="https://github.com/loopx-project/loopx/pull/4178">#4178</a> converged planning updates on one authority snapshot and a complete TS transaction: omission retains intent, explicit clearing follows field and authority rules, and evidence correction does not rearm a satisfied monitor. It also removed Python’s serialize-to-Markdown-and-parse-back route. This repaired behavior as well as consolidating ownership; describing it as a mechanically equivalent language translation would miss the point.</p>
+<p>Song’s <a href="https://github.com/loopx-project/loopx/pull/4433">#4433</a> and <a href="https://github.com/loopx-project/loopx/pull/4494">#4494</a> extended this discipline to vocabulary definitions, actual producers and consumers. A compiling enum does not establish that all callers mean the same thing. The <code>skip</code> / <code>quota_skip</code> example in the Semantics section and separation of action from decision belong to this same thread.</p>
+<h3>Making a plausible model answer face a counterexample</h3>
+<p>Ask for the mistaken assumption, then an execution sequence that refutes it: disconnect after commit, replay an expired lease, correct only evidence, explicitly clear a value. Check the real owner, provider and caller.</p>
+<p>Stronger models help connect scattered conditions; counterexamples, real storage and refusal paths constrain their answers. There is no per-PR model comparison here, so these examples cannot quantify a particular model’s independent contribution. They show the mechanisms and reasons for changing them. Later runtime routing in <a href="https://github.com/loopx-project/loopx/pull/7145">#7145</a> and original-Turn closeout in <a href="https://github.com/loopx-project/loopx/pull/7269">#7269</a> continue this work rather than defining its whole history.</p>
+<h2 id="section-1">2. Reconstruct the history: the migration plan changed too</h2>
 <p>The formal migration RFC merged on August 15. By the concentrated retirement of ordinary legacy writers in mid-October, the program had spanned roughly two months. Several tracks overlapped: transaction ownership, caller integration, shared authority, storage and history costs, Semantics, compatibility, and retirement.</p>
 <p>The final relay by three developers and their agents in <a href="https://github.com/loopx-project/loopx/pull/6396">#6396</a> depended on that earlier work. Earlier choices determined what could be deleted and what still had to recover afterward.</p>
 <p>Our new maintainer, <strong>Song (<a href="https://github.com/songoow">@songoow</a>)</strong>, has also been advancing the Semantics RFC, vocabulary convergence, production evidence, and checker fixes since mid-September. That track belongs alongside the transaction and storage story.</p>
-<h2 id="section-1">1. Reconstruct the history: the migration plan changed too</h2>
 <p>LoopX retains goals, tasks, evidence, and execution boundaries for long-running agents. Models propose routes. The control plane protects versions, execution authority, and state commits, then finds a valid recovery position after interruption.</p>
 <p>Much of the original implementation was Python. TypeScript hosts, Pi integration, and the dashboard already existed. A Python call to make a decision, followed by a TS host consuming the result, was a natural starting point. As the system grew, defaults, state interpretation, ordering, and persistence could become distributed across both runtimes.</p>
 <p>We wanted clear typed ownership of control-plane rules and contracts shared by the CLI, hosts, and App. The history developed through overlapping stages.</p>
@@ -74,158 +93,6 @@ <h2 id="section-1">1. Reconstruct the history: the migration plan changed too</h
 <figure><div class="figure-scroll" tabindex="0" role="region" aria-label="Migration history: overlapping transaction, authority/storage, and Semantics tracks"><a href="../images/typescript-control-plane-refactor/timeline-en.svg" target="_blank" rel="noopener"><img src="../images/typescript-control-plane-refactor/timeline-en.svg" alt="Migration history: overlapping transaction, authority/storage, and Semantics tracks" width="1100" height="640" loading="lazy"></a></div><figcaption>Migration history: overlapping transaction, authority/storage, and Semantics tracks Scroll on narrow screens; open the image for full size.</figcaption></figure>
 <p>The original August proposal considered a read-first sequence and staged dual reads and writes. The accepted approach evolved toward Effect Programs first, then replacing complete transactions and deleting the old rules, with one production semantic owner. An early proposal&#39;s staging ideas should not be presented as the runtime architecture of 2.0.</p>
 <p>Plans can change usefully. The important record is why the route changed, which slices cut over, and which remained references or candidates. The maintained <a href="https://github.com/loopx-project/loopx/blob/488e4438e0e51eca023ac3f5e690603120851b0c/docs/architecture/rfcs/typescript-control-plane-migration-v0.md">TS RFC</a> retains those checkpoints.</p>
-<h2 id="section-2">2. Core control-plane statistics across the full period</h2>
-<p>The reproducible scope here is <strong><code>loopx/control_plane/**</code></strong>. App, benchmark, documentation, and test-suite directories outside it do not enter the core code counts. Internal testing/support tools inside this directory remain included.</p>
-<p>The baseline is <code>d1fe059</code>, immediately before the formal TS RFC. The endpoint is the October 16 snapshot <code>488e443</code>. The formal RFC to that endpoint spans roughly <strong>62 days</strong>, covering 63 calendar dates; 62 of those dates contain a core mainline commit. The <a href="https://github.com/loopx-project/loopx/compare/d1fe05932ac28690d393a38c78b4738ac12c78c0...488e4438e0e51eca023ac3f5e690603120851b0c">source comparison</a> fixes both versions.</p>
-<h3>Engineering activity over the whole period</h3>
-<div class="table-scroll" role="region" tabindex="0" aria-label="Scrollable technical comparison table"><table>
-<thead>
-<tr>
-<th>Metric</th>
-<th align="right">Core-directory cohort</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>Mainline landing commits touching the directory, first-parent chain</td>
-<td align="right"><strong>1,144</strong></td>
-</tr>
-<tr>
-<td>Verifiably associated merged PRs, deduplicated by PR number</td>
-<td align="right"><strong>1,121</strong></td>
-</tr>
-<tr>
-<td>PR-author accounts in that cohort</td>
-<td align="right"><strong>56</strong></td>
-</tr>
-<tr>
-<td>Review records in the API snapshot</td>
-<td align="right"><strong>2,329</strong></td>
-</tr>
-<tr>
-<td>Conversation comments in the API snapshot, excluding inline review comments</td>
-<td align="right"><strong>1,631</strong></td>
-</tr>
-<tr>
-<td>Associated PRs with review records</td>
-<td align="right"><strong>1,031 / 1,121</strong></td>
-</tr>
-<tr>
-<td>Median PR creation-to-merge elapsed time</td>
-<td align="right"><strong>5.0 hours</strong></td>
-</tr>
-<tr>
-<td>P90 / P95 creation-to-merge elapsed time</td>
-<td align="right"><strong>25.4 / 45.0 hours</strong></td>
-</tr>
-</tbody></table></div>
-<p>The scope includes migration, new capabilities, fixes, and maintenance during the period. The 56 accounts include automation and shared accounts; they do not establish 56 people or agents. Review totals can include self-review, repeated reviews, and post-merge discussion. Merge elapsed time includes waiting and is not active engineering time.</p>
-<p>New maintainer Song is associated with <strong>53 PRs</strong> in this narrow directory cohort. His work in <code>loopx/semantics/</code> and other directories is not fully counted here. Concrete attribution still follows the contribution explanations and original PRs.</p>
-<h3>Source structure and cumulative churn</h3>
-<p>Physical line counts include comments and blank lines. File counts below include source files in the named language.</p>
-<div class="table-scroll" role="region" tabindex="0" aria-label="Scrollable technical comparison table"><table>
-<thead>
-<tr>
-<th>Core-directory source</th>
-<th align="right">Baseline</th>
-<th align="right">Evidence snapshot</th>
-<th align="right">Cumulative additions / deletions</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>Python</td>
-<td align="right">256 files; 80,473 lines</td>
-<td align="right">471 files; 142,371 lines</td>
-<td align="right">+120,899 / −59,001 lines</td>
-</tr>
-<tr>
-<td>TypeScript</td>
-<td align="right">0 files; 0 lines</td>
-<td align="right">323 files; 87,268 lines</td>
-<td align="right">+104,769 / −17,501 lines</td>
-</tr>
-<tr>
-<td>Python + TypeScript</td>
-<td align="right">80,473 lines</td>
-<td align="right">229,639 lines</td>
-<td align="right"><strong>+225,668 / −76,502 lines</strong></td>
-</tr>
-</tbody></table></div>
-<p>TS represents <strong>38.0%</strong> of the endpoint&#39;s Python-plus-TS physical lines. That describes the directory&#39;s language structure. It does not establish that 38% of migration is complete: some old entrypoints were outside this directory, and the period includes code moving in, new capabilities, and testing support.</p>
-<figure><div class="figure-scroll" tabindex="0" role="region" aria-label="Python and TypeScript source stocks in the core control-plane directory"><a href="../images/typescript-control-plane-refactor/core-source-stock.svg" target="_blank" rel="noopener"><img src="../images/typescript-control-plane-refactor/core-source-stock.svg" alt="Python and TypeScript source stocks in the core control-plane directory" width="1100" height="640" loading="lazy"></a></div><figcaption>Python and TypeScript source stocks in the core control-plane directory Scroll on narrow screens; open the image for full size.</figcaption></figure>
-<p>Cumulative churn sums each mainline landing diff, so repeatedly editing a line counts repeatedly. Endpoint stocks describe only the two snapshots. The cumulative net, endpoint diff, and source-stock change were reconciled by language. The roughly <strong>302,000 line edits</strong> record engineering activity; they do not measure unique output, quality, or model productivity.</p>
-<h3>How the work continued over time</h3>
-<div class="table-scroll" role="region" tabindex="0" aria-label="Scrollable technical comparison table"><table>
-<thead>
-<tr>
-<th>Beijing dates, weekly buckets</th>
-<th align="right">Core mainline commits</th>
-<th align="right">Associated merged PRs</th>
-<th align="right">PR-author accounts that week</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>08-15—08-21</td>
-<td align="right">52</td>
-<td align="right">48</td>
-<td align="right">10</td>
-</tr>
-<tr>
-<td>08-22—08-28</td>
-<td align="right">87</td>
-<td align="right">86</td>
-<td align="right">14</td>
-</tr>
-<tr>
-<td>08-29—09-04</td>
-<td align="right">61</td>
-<td align="right">61</td>
-<td align="right">16</td>
-</tr>
-<tr>
-<td>09-05—09-11</td>
-<td align="right">92</td>
-<td align="right">92</td>
-<td align="right">14</td>
-</tr>
-<tr>
-<td>09-12—09-18</td>
-<td align="right">133</td>
-<td align="right">133</td>
-<td align="right">14</td>
-</tr>
-<tr>
-<td>09-19—09-25</td>
-<td align="right">150</td>
-<td align="right">147</td>
-<td align="right">10</td>
-</tr>
-<tr>
-<td>09-26—10-02</td>
-<td align="right">161</td>
-<td align="right">161</td>
-<td align="right">17</td>
-</tr>
-<tr>
-<td>10-03—10-09</td>
-<td align="right">216</td>
-<td align="right">214</td>
-<td align="right">12</td>
-</tr>
-<tr>
-<td>10-10—10-16</td>
-<td align="right">192</td>
-<td align="right">179</td>
-<td align="right">14</td>
-</tr>
-</tbody></table></div>
-<figure><div class="figure-scroll" tabindex="0" role="region" aria-label="Weekly associated merged PRs touching the core directory throughout the refactor period"><a href="../images/typescript-control-plane-refactor/core-weekly-prs.svg" target="_blank" rel="noopener"><img src="../images/typescript-control-plane-refactor/core-weekly-prs.svg" alt="Weekly associated merged PRs touching the core directory throughout the refactor period" width="1100" height="640" loading="lazy"></a></div><figcaption>Weekly associated merged PRs touching the core directory throughout the refactor period Scroll on narrow screens; open the image for full size.</figcaption></figure>
-<p>The first and last weeks cover only time inside the selected endpoints. PRs use merge time; mainline commits use commit time. These can differ, so the two columns need not correspond one-for-one within a week.</p>
-<p>By title prefix, the cohort contains <strong>658 <code>fix</code>, 208 <code>feat</code>, 137 <code>refactor</code>, and 28 <code>perf</code> PRs</strong>. The rest include validation, documentation, and titles without those prefixes. These are title categories, not a partition of pure migration effort.</p>
-<figure><div class="figure-scroll" tabindex="0" role="region" aria-label="PR title categories in the same core-directory cohort"><a href="../images/typescript-control-plane-refactor/core-work-types.svg" target="_blank" rel="noopener"><img src="../images/typescript-control-plane-refactor/core-work-types.svg" alt="PR title categories in the same core-directory cohort" width="1100" height="640" loading="lazy"></a></div><figcaption>PR title categories in the same core-directory cohort Scroll on narrow screens; open the image for full size.</figcaption></figure>
-<p>These numbers support explaining the mechanisms by stage. Moving a rule was followed by caller integration, semantic fixes, recovery validation, and retirement. The final #6396 is one concentrated slice within that process.</p>
-<h3>Reproduce the inventory</h3>
-<p>Public-safe <a href="../images/typescript-control-plane-refactor/core-pr-cohort.csv">PR records</a>, <a href="../images/typescript-control-plane-refactor/core-mainline-commits.csv">core mainline commits</a>, and <a href="../images/typescript-control-plane-refactor/core-statistics.json">metric JSON</a> accompany the draft. The PR cohort joins mainline commits touching the directory to GitHub merge metadata, counting each PR once. Two mainline commits have no verifiable merged-PR association; their commits and churn remain included.</p>
-<p>The research enumerated public PRs, then checked against mainline Git history. Direct reads supplemented 14 PR metadata records missed by search indexing. Source snapshots and processing scripts remain in the research materials. This inventory does not estimate tokens, model cost, CI compute, engineer-hours, or benchmark gains.</p>
 <h2 id="section-3">3. Start with the Effect Program: agree on what happened</h2>
 <p>The first bounded cutover was <a href="https://github.com/loopx-project/loopx/pull/3416">#3416</a> on August 21. TypeScript took ownership of the Effect Program, settlement algebra, Turn-journal interpretation, and a durable checkpoint effect.</p>
 <p>These boundaries fit together because recovery asks one connected question: which effects belong to this operation, which have committed, and what may happen next?</p>
@@ -324,26 +191,7 @@ <h3>Counterexamples for the checker itself</h3>
 <p>False alarms and missed values have different consequences. A conservative candidate set may report an extra problem. Missing a real produced value can let an unregistered output through. Unsupported dynamic forms must preserve an unknown.</p>
 <p>The checks also need scan-coverage floors, so scanning fewer files cannot make the result green. Retiring an expanding committed inventory in favor of on-demand full-tree computation did not remove that obligation. Gaps outside supported forms remain explicit, and the <a href="https://github.com/loopx-project/loopx/issues/4447">tracking issue</a> remains part of the work.</p>
 <p>Generation and checking reduce synchronization mistakes. Their assumptions, coverage, and error direction still require review.</p>
-<h2 id="model-assisted-semantics">8. The semantic questions we put stronger models to work on</h2>
-<p>We use stronger models in design, implementation and review, especially to trace assumptions across files and runtimes. The difficult cases often combine individually reasonable checks into an unsafe execution order. Core PRs in August and September already dealt with these problems; they were part of the migration itself.</p>
-<h3>The effect happened, but its checkpoint did not. Is retry safe?</h3>
-<p>A provider succeeds, then the process crashes before writing the checkpoint. The journal says unfinished; a blind retry may execute twice. Treating every uncertain result as success would instead lose work that never happened. A try/catch cannot settle that distinction.</p>
-<p>On August 22, <a href="https://github.com/loopx-project/loopx/pull/3485">#3485</a> introduced a durable prepared attempt and stable effect identity before execution. Recovery asks the provider: <strong>confirmed committed means checkpoint the original result; confirmed absent permits execution with the same identity; unknown remains pending recovery.</strong> Effect order, receipt prefixes and identity checks remain part of the contract. This is not arbitrary external exactly-once execution: confirming the result depends on provider recovery support.</p>
-<p>This complements the preflight in <a href="https://github.com/loopx-project/loopx/pull/3464">#3464</a>. Before execution, determine whether the effect is allowed; after interruption, determine whether it already happened. Moving Python functions to TS one at a time does not protect both boundaries.</p>
-<p>On September 13, <a href="https://github.com/loopx-project/loopx/pull/4286">#4286</a> converged receipt recovery for seven Todo operations on one owner while retaining a finer distinction. Suppose two agents update a task: A commits first; B receives a definite version-conflict rejection, then loses its connection while reading the receipt. <strong>The later read failure must not erase the earlier rejection.</strong> If the connection drops before the commit response arrives, the result remains uncertain and recovery must use the original operation identity.</p>
-<p>Both paths can encounter a network error, but they require different next steps. The <a href="https://github.com/loopx-project/loopx/blob/c0b572d2d508bb10c32701057dd71ff4f8eb663c/loopx/control_plane/coordination/command_receipt.ts">shared implementation</a> attempts the write once, then reads the original receipt. Its <a href="https://github.com/loopx-project/loopx/blob/c0b572d2d508bb10c32701057dd71ff4f8eb663c/tests/control_plane_ts/command_receipt.test.ts">regressions</a> distinguish conclusive rejection, commit uncertainty and exact-receipt recovery. Shared error handling must retain the phase of failure and facts already established.</p>
-<h3>Claiming work and acquiring execution rights must commit together</h3>
-<p>Two agents see an unclaimed task. If the claim is written before the lease is acquired, who owns the intermediate state? If an earlier claimant returns with a receipt after its lease expires, may it keep writing?</p>
-<p>From the coordination foundations in <a href="https://github.com/loopx-project/loopx/pull/3529">#3529</a> and <a href="https://github.com/loopx-project/loopx/pull/3669">#3669</a> to the September 6 transaction in <a href="https://github.com/loopx-project/loopx/pull/4032">#4032</a>, claim, lease and operation receipt converge on one conditional commit. The <a href="https://github.com/loopx-project/loopx/pull/3798">#3798</a> store owns atomic persistence; the domain owner checks identity, scope and legal transitions. <strong>A receipt proves a past claim succeeded. The current lease and epoch determine permission now.</strong> Replay must recover the original result without reviving expired execution rights. Storage revision, domain revision and lease epoch remain different identities.</p>
-<p>Idempotency therefore requires more than returning an old success. Recovery must remember history and respect present authority. Foundation, shadow and production qualification arrived in stages; the first interface merge did not establish deployment of every backend.</p>
-<h3>Why could correcting evidence restart finished work?</h3>
-<p>A planning update corrects evidence without changing monitor state. Rebuilding the object from defaults can accidentally rearm an already satisfied monitor. Conversely, an explicitly empty list or <code>false</code> cannot be interpreted as an omitted input.</p>
-<p>On September 10, <a href="https://github.com/loopx-project/loopx/pull/4178">#4178</a> converged planning updates on one authority snapshot and a complete TS transaction: omission retains intent, explicit clearing follows field and authority rules, and evidence correction does not rearm a satisfied monitor. It also removed Python’s serialize-to-Markdown-and-parse-back route. This repaired behavior as well as consolidating ownership; describing it as a mechanically equivalent language translation would miss the point.</p>
-<p>Song’s <a href="https://github.com/loopx-project/loopx/pull/4433">#4433</a> and <a href="https://github.com/loopx-project/loopx/pull/4494">#4494</a> extended this discipline to vocabulary definitions, actual producers and consumers. A compiling enum does not establish that all callers mean the same thing. The earlier <code>skip</code> / <code>quota_skip</code> example and separation of action from decision belong to this same thread.</p>
-<h3>Making a plausible model answer face a counterexample</h3>
-<p>Ask for the mistaken assumption, then an execution sequence that refutes it: disconnect after commit, replay an expired lease, correct only evidence, explicitly clear a value. Check the real owner, provider and caller.</p>
-<p>Stronger models help connect scattered conditions; counterexamples, real storage and refusal paths constrain their answers. There is no per-PR model comparison here, so these examples cannot quantify a particular model’s independent contribution. They show the mechanisms and reasons for changing them. Later runtime routing in <a href="https://github.com/loopx-project/loopx/pull/7145">#7145</a> and original-Turn closeout in <a href="https://github.com/loopx-project/loopx/pull/7269">#7269</a> continue this work rather than defining its whole history.</p>
-<h2 id="section-8">9. Callers and defaults determine whether migration reaches users</h2>
+<h2 id="section-8">8. Callers and defaults determine whether migration reaches users</h2>
 <p>Complete transactions also need callers to express intent accurately. In <a href="https://github.com/loopx-project/loopx/pull/4178">#4178</a>, a blank note means no update; an explicit empty list or <code>false</code> is interpreted by its field’s contract. These values cannot all be discarded as absent, or all treated as clearing. Dry-run must model that intent accurately. An unavailable selected provider must not trigger fallback elsewhere. <a href="https://github.com/loopx-project/loopx/pull/4279">#4279</a> later converged read classification and projection-delivery semantics. Some Python read ownership was deliberately retained. Clear ownership matters more than creating a second interpretation to pursue language purity.</p>
 <p>Defaults expose similar distinctions. Current priority regressions protect these cases:</p>
 <div class="table-scroll" role="region" tabindex="0" aria-label="Scrollable technical comparison table"><table>
@@ -381,7 +229,7 @@ <h2 id="section-8">9. Callers and defaults determine whether migration reaches u
 <p>The <a href="https://github.com/loopx-project/loopx/blob/488e4438e0e51eca023ac3f5e690603120851b0c/tests/control_plane_ts/todo_priority.test.ts">File and SQLite regressions</a> protect these cases. Applying new defaults after original-receipt recovery prevents an upgrade from making new decisions for history.</p>
 <p>The closing review found another caller gap. The TS core passed direct tests for metadata-only completion repair. The normal Python producer automatically attached defaults such as completion policy and auto-acquire. The core interpreted them as fresh work mixed into a historical repair. The actual File and SQLite entrypoints failed in both dry-run and execution. The <a href="https://github.com/loopx-project/loopx/pull/6396#pullrequestreview-5516847052">public counterexample</a> records this.</p>
 <p>That recovery gap also existed in the baseline, so it cannot all be attributed to the final contributor. The repair had to reach the normal producer while continuing to reject real changes to text, continuation, ownership, or validation. A correctly constructed typed request proves only that the inner boundary can handle it.</p>
-<h2 id="section-9">10. Recover the original result while protecting current authority</h2>
+<h2 id="section-9">9. Recover the original result while protecting current authority</h2>
 <p>Recovery can confuse two points in time: whether the original operation was valid, and whether today&#39;s executor may continue changing state.</p>
 <p>Suppose a team-plan committed but its response was lost. After an upgrade, the caller retries the same operation ID under stricter admission rules. Rejecting it as fresh work first can hide the original success. A closing <a href="https://github.com/loopx-project/loopx/pull/6396#pullrequestreview-5514510958">recovery review</a> caught that problem.</p>
 <figure><div class="figure-scroll" tabindex="0" role="region" aria-label="Separating original-receipt recovery from current execution authority"><a href="../images/typescript-control-plane-refactor/replay-en.svg" target="_blank" rel="noopener"><img src="../images/typescript-control-plane-refactor/replay-en.svg" alt="Separating original-receipt recovery from current execution authority" width="1100" height="640" loading="lazy"></a></div><figcaption>Separating original-receipt recovery from current execution authority Scroll on narrow screens; open the image for full size.</figcaption></figure>
@@ -389,7 +237,7 @@ <h2 id="section-9">10. Recover the original result while protecting current auth
 <p>Returning the original result does not renew a lease, overwrite later commits, or revive a retired writer. Lease transfers, epoch changes, and subsequent state have their own protections.</p>
 <p>Types express the distinction too. Historical decoding still recognizes <code>legacy</code>; current fresh-execution handoff configuration accepts <code>soft_claim</code> and <code>hard_lease</code>. Reading an old record, recovering an original operation, and authorizing current execution each have independent conditions.</p>
 <p>An internal receipt also has a limited scope. If a remote external effect lacks a verifiable idempotent identity and readback, settling once in the control plane cannot establish that the remote effect executed exactly once. Uncertainty belongs at the boundary where it actually occurs.</p>
-<h2 id="section-10">11. CLI output budgets: protect decision semantics before compression</h2>
+<h2 id="section-10">10. CLI output budgets: protect decision semantics before compression</h2>
 <p>CLI language participates in an agent&#39;s decisions. This engineering constraint predates the final writer retirement and remained a validation boundary during migration.</p>
 <p>The <a href="https://github.com/loopx-project/loopx/blob/488e4438e0e51eca023ac3f5e690603120851b0c/docs/reference/contracts/interface-budget-contract.md">interface budget contract</a> examines:</p>
 <ul>
@@ -402,7 +250,7 @@ <h2 id="section-10">11. CLI output budgets: protect decision semantics before co
 <p>Natural language requires clause-level review: obligations, ordering, evidence provenance, authority qualifiers, scope, continuation, and stop conditions. Removing a phrase such as “only when the original proof is valid” can change behavior even when every field remains.</p>
 <p>One bounded example removed JSON indentation and separator whitespace. On the same historical fixture of 36 Todos and 12 runs, output fell from 48,418 to 39,726 characters, about 18%, with the complete decoded payload unchanged. This establishes a presentation-size change. Tokens, cost, and agent outcomes need separate measurements.</p>
 <p>The budget protects an interface the consumer can use. Valuable guidance may justify increasing it with matched evidence. Dropping decision conditions to make a size test green damages the interface.</p>
-<h2 id="section-11">12. Final retirement: preserve credit and account for the deletions</h2>
+<h2 id="section-11">11. Final retirement: preserve credit and account for the deletions</h2>
 <p>Late-September work had already removed an unused authority prototype and the experimental Todo event overlay, dual-writer, and backfill. Old sources containing data received explicit preservation or refusal handling. This did not remove all event logging or the new authority&#39;s atomic events and receipts.</p>
 <p>October work further isolated ordinary Markdown writers and validated real subsequent writes without the old modules. Concentrated deletion became possible after consumer routes and replacement paths were connected.</p>
 <p><strong>Duang777</strong> led <a href="https://github.com/loopx-project/loopx/pull/6396">#6396</a>. <strong>Song</strong> and maintainer-side agents continued recovery, producer, and integration work along the original branch, preserving contribution history. This three-developer-and-agent relay was the closing phase of the two-month program.</p>
@@ -442,6 +290,158 @@ <h2 id="section-11">12. Final retirement: preserve credit and account for the de
 </tr>
 </tbody></table></div>
 <p>Many removed lines were old tests. Deleted test lines do not establish product capability; the important question is whether current entrypoints and independent counterexamples still protect the intended invariants. These counts describe the closing scope. They do not validate the whole migration.</p>
+<h2 id="section-2">12. Core control-plane statistics across the full period</h2>
+<p>The reproducible scope here is <strong><code>loopx/control_plane/**</code></strong>. App, benchmark, documentation, and test-suite directories outside it do not enter the core code counts. Internal testing/support tools inside this directory remain included.</p>
+<p>The baseline is <code>d1fe059</code>, immediately before the formal TS RFC. The endpoint is the October 16 snapshot <code>488e443</code>. The formal RFC to that endpoint spans roughly <strong>62 days</strong>, covering 63 calendar dates; 62 of those dates contain a core mainline commit. The <a href="https://github.com/loopx-project/loopx/compare/d1fe05932ac28690d393a38c78b4738ac12c78c0...488e4438e0e51eca023ac3f5e690603120851b0c">source comparison</a> fixes both versions.</p>
+<h3>Engineering activity over the whole period</h3>
+<div class="table-scroll" role="region" tabindex="0" aria-label="Scrollable technical comparison table"><table>
+<thead>
+<tr>
+<th>Metric</th>
+<th align="right">Core-directory cohort</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>Mainline landing commits touching the directory, first-parent chain</td>
+<td align="right"><strong>1,144</strong></td>
+</tr>
+<tr>
+<td>Verifiably associated merged PRs, deduplicated by PR number</td>
+<td align="right"><strong>1,121</strong></td>
+</tr>
+<tr>
+<td>PR-author accounts in that cohort</td>
+<td align="right"><strong>56</strong></td>
+</tr>
+<tr>
+<td>Review records in the API snapshot</td>
+<td align="right"><strong>2,329</strong></td>
+</tr>
+<tr>
+<td>Conversation comments in the API snapshot, excluding inline review comments</td>
+<td align="right"><strong>1,631</strong></td>
+</tr>
+<tr>
+<td>Associated PRs with review records</td>
+<td align="right"><strong>1,031 / 1,121</strong></td>
+</tr>
+<tr>
+<td>Median PR creation-to-merge elapsed time</td>
+<td align="right"><strong>5.0 hours</strong></td>
+</tr>
+<tr>
+<td>P90 / P95 creation-to-merge elapsed time</td>
+<td align="right"><strong>25.4 / 45.0 hours</strong></td>
+</tr>
+</tbody></table></div>
+<p>The scope includes migration, new capabilities, fixes, and maintenance during the period. The 56 accounts include automation and shared accounts; they do not establish 56 people or agents. Review totals can include self-review, repeated reviews, and post-merge discussion. Merge elapsed time includes waiting and is not active engineering time.</p>
+<p>New maintainer Song is associated with <strong>53 PRs</strong> in this narrow directory cohort. His work in <code>loopx/semantics/</code> and other directories is not fully counted here. Concrete attribution still follows the contribution explanations and original PRs.</p>
+<h3>Source structure and cumulative churn</h3>
+<p>Physical line counts include comments and blank lines. File counts below include source files in the named language.</p>
+<div class="table-scroll" role="region" tabindex="0" aria-label="Scrollable technical comparison table"><table>
+<thead>
+<tr>
+<th>Core-directory source</th>
+<th align="right">Baseline</th>
+<th align="right">Evidence snapshot</th>
+<th align="right">Cumulative additions / deletions</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>Python</td>
+<td align="right">256 files; 80,473 lines</td>
+<td align="right">471 files; 142,371 lines</td>
+<td align="right">+120,899 / −59,001 lines</td>
+</tr>
+<tr>
+<td>TypeScript</td>
+<td align="right">0 files; 0 lines</td>
+<td align="right">323 files; 87,268 lines</td>
+<td align="right">+104,769 / −17,501 lines</td>
+</tr>
+<tr>
+<td>Python + TypeScript</td>
+<td align="right">80,473 lines</td>
+<td align="right">229,639 lines</td>
+<td align="right"><strong>+225,668 / −76,502 lines</strong></td>
+</tr>
+</tbody></table></div>
+<p>TS represents <strong>38.0%</strong> of the endpoint&#39;s Python-plus-TS physical lines. That describes the directory&#39;s language structure. It does not establish that 38% of migration is complete: some old entrypoints were outside this directory, and the period includes code moving in, new capabilities, and testing support.</p>
+<figure><div class="figure-scroll" tabindex="0" role="region" aria-label="Python and TypeScript source stocks in the core control-plane directory"><a href="../images/typescript-control-plane-refactor/core-source-stock.svg" target="_blank" rel="noopener"><img src="../images/typescript-control-plane-refactor/core-source-stock.svg" alt="Python and TypeScript source stocks in the core control-plane directory" width="1100" height="640" loading="lazy"></a></div><figcaption>Python and TypeScript source stocks in the core control-plane directory Scroll on narrow screens; open the image for full size.</figcaption></figure>
+<p>Cumulative churn sums each mainline landing diff, so repeatedly editing a line counts repeatedly. Endpoint stocks describe only the two snapshots. The cumulative net, endpoint diff, and source-stock change were reconciled by language. The roughly <strong>302,000 line edits</strong> record engineering activity; they do not measure unique output, quality, or model productivity.</p>
+<h3>How the work continued over time</h3>
+<div class="table-scroll" role="region" tabindex="0" aria-label="Scrollable technical comparison table"><table>
+<thead>
+<tr>
+<th>Beijing dates, weekly buckets</th>
+<th align="right">Core mainline commits</th>
+<th align="right">Associated merged PRs</th>
+<th align="right">PR-author accounts that week</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>08-15—08-21</td>
+<td align="right">52</td>
+<td align="right">48</td>
+<td align="right">10</td>
+</tr>
+<tr>
+<td>08-22—08-28</td>
+<td align="right">87</td>
+<td align="right">86</td>
+<td align="right">14</td>
+</tr>
+<tr>
+<td>08-29—09-04</td>
+<td align="right">61</td>
+<td align="right">61</td>
+<td align="right">16</td>
+</tr>
+<tr>
+<td>09-05—09-11</td>
+<td align="right">92</td>
+<td align="right">92</td>
+<td align="right">14</td>
+</tr>
+<tr>
+<td>09-12—09-18</td>
+<td align="right">133</td>
+<td align="right">133</td>
+<td align="right">14</td>
+</tr>
+<tr>
+<td>09-19—09-25</td>
+<td align="right">150</td>
+<td align="right">147</td>
+<td align="right">10</td>
+</tr>
+<tr>
+<td>09-26—10-02</td>
+<td align="right">161</td>
+<td align="right">161</td>
+<td align="right">17</td>
+</tr>
+<tr>
+<td>10-03—10-09</td>
+<td align="right">216</td>
+<td align="right">214</td>
+<td align="right">12</td>
+</tr>
+<tr>
+<td>10-10—10-16</td>
+<td align="right">192</td>
+<td align="right">179</td>
+<td align="right">14</td>
+</tr>
+</tbody></table></div>
+<figure><div class="figure-scroll" tabindex="0" role="region" aria-label="Weekly associated merged PRs touching the core directory throughout the refactor period"><a href="../images/typescript-control-plane-refactor/core-weekly-prs.svg" target="_blank" rel="noopener"><img src="../images/typescript-control-plane-refactor/core-weekly-prs.svg" alt="Weekly associated merged PRs touching the core directory throughout the refactor period" width="1100" height="640" loading="lazy"></a></div><figcaption>Weekly associated merged PRs touching the core directory throughout the refactor period Scroll on narrow screens; open the image for full size.</figcaption></figure>
+<p>The first and last weeks cover only time inside the selected endpoints. PRs use merge time; mainline commits use commit time. These can differ, so the two columns need not correspond one-for-one within a week.</p>
+<p>By title prefix, the cohort contains <strong>658 <code>fix</code>, 208 <code>feat</code>, 137 <code>refactor</code>, and 28 <code>perf</code> PRs</strong>. The rest include validation, documentation, and titles without those prefixes. These are title categories, not a partition of pure migration effort.</p>
+<figure><div class="figure-scroll" tabindex="0" role="region" aria-label="PR title categories in the same core-directory cohort"><a href="../images/typescript-control-plane-refactor/core-work-types.svg" target="_blank" rel="noopener"><img src="../images/typescript-control-plane-refactor/core-work-types.svg" alt="PR title categories in the same core-directory cohort" width="1100" height="640" loading="lazy"></a></div><figcaption>PR title categories in the same core-directory cohort Scroll on narrow screens; open the image for full size.</figcaption></figure>
+<p>These numbers support explaining the mechanisms by stage. Moving a rule was followed by caller integration, semantic fixes, recovery validation, and retirement. The final #6396 is one concentrated slice within that process.</p>
+<h3>Reproduce the inventory</h3>
+<p>Public-safe <a href="../images/typescript-control-plane-refactor/core-pr-cohort.csv">PR records</a>, <a href="../images/typescript-control-plane-refactor/core-mainline-commits.csv">core mainline commits</a>, and <a href="../images/typescript-control-plane-refactor/core-statistics.json">metric JSON</a> accompany the draft. The PR cohort joins mainline commits touching the directory to GitHub merge metadata, counting each PR once. Two mainline commits have no verifiable merged-PR association; their commits and churn remain included.</p>
+<p>The research enumerated public PRs, then checked against mainline Git history. Direct reads supplemented 14 PR metadata records missed by search indexing. Source snapshots and processing scripts remain in the research materials. This inventory does not estimate tokens, model cost, CI compute, engineer-hours, or benchmark gains.</p>
 <h2 id="section-12">13. Community contributions and the next step</h2>
 <p>Multiple contributors advanced this program. Representative work is listed by its concrete boundary so readers can follow the history.</p>
 <div class="table-scroll" role="region" tabindex="0" aria-label="Scrollable technical comparison table"><table>
@@ -489,6 +489,6 @@ <h2 id="section-12">13. Community contributions and the next step</h2>
 <p>2.0 does not close every RFC goal. Retained Python transports and specialized providers have specific purposes. Broader native CLI coverage and sustained-operation qualification continue along their own validation paths. We also want capability and efficiency comparisons on harder general long-horizon benchmarks such as EdgeBench and LHTB, especially in a single session.</p>
 <p>I hope this refactor leaves a system that is easier to change, validate, and revert—and a working practice that keeps responding to counterexamples.</p>
 
-</article></div></main>
+<nav class="article-route" aria-label="Continue reading"><p>How do these rules reach the next decision? Read <a href="../context-delivery/">progressive and differential context delivery</a>. For observed outcomes and counterevidence, continue to <a href="../edgebench-feedback-and-memory/">the EdgeBench study</a>.</p></nav></article></div></main>
 <footer class="site-footer"><a class="brand" href="../../">LoopX</a><p>Keep work moving. Keep people in control.</p><a href="#main" aria-label="Back to top">↑</a></footer>
 </body></html>
diff --git a/apps/presentation/site/public/blog/zh/context-delivery/index.html b/apps/presentation/site/public/blog/zh/context-delivery/index.html
new file mode 100644
index 0000000000..df2abac8a4
--- /dev/null
+++ b/apps/presentation/site/public/blog/zh/context-delivery/index.html
@@ -0,0 +1,213 @@
+<!doctype html>
+<html lang="zh-CN"><head>
+<meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><meta name="theme-color" content="#fafafa">
+<title>Agent 读上下文，也需要一套“查书”的方法 · LoopX</title><meta name="description" content="从一个语音任务理解渐进式读取、JSON Pointer、精确共享、compaction 周期内的结构化差分，以及失效后的完整恢复。">
+<link rel="canonical" href="https://loopx-project.github.io/loopx/blog/zh/context-delivery/"><link rel="alternate" hreflang="en" href="https://loopx-project.github.io/loopx/blog/context-delivery/"><link rel="alternate" hreflang="zh-CN" href="https://loopx-project.github.io/loopx/blog/zh/context-delivery/"><link rel="alternate" hreflang="x-default" href="https://loopx-project.github.io/loopx/blog/context-delivery/">
+<meta property="og:type" content="article"><meta property="og:site_name" content="LoopX"><meta property="og:locale" content="zh_CN"><meta property="og:title" content="Agent 读上下文，也需要一套“查书”的方法"><meta property="og:description" content="从一个语音任务理解渐进式读取、JSON Pointer、精确共享、compaction 周期内的结构化差分，以及失效后的完整恢复。"><meta property="og:url" content="https://loopx-project.github.io/loopx/blog/zh/context-delivery/"><meta name="twitter:card" content="summary"><link rel="icon" href="data:,"><link rel="stylesheet" href="../../blog.css">
+</head><body><a class="skip-link" href="#main">跳至正文</a>
+<header class="site-header"><a class="brand" href="../../../?lang=zh"><span class="product-mark" aria-hidden="true"><i></i><i></i></span>LoopX</a><nav aria-label="主导航"><a href="../">Blog</a><a href="../../../docs/book/">文档</a></nav><div class="header-actions"><a class="language" href="../../context-delivery/" lang="en" hreflang="en">EN</a><a class="github" href="https://github.com/loopx-project/loopx">GitHub ↗</a></div></header>
+<main id="main"><div class="article-heading"><a class="back" href="../">← 全部文章</a><p class="eyebrow">Context delivery</p><h1>Agent 读上下文，也需要一套“查书”的方法</h1><p class="lead">从一个语音任务理解渐进式读取、JSON Pointer、精确共享、compaction 周期内的结构化差分，以及失效后的完整恢复。</p><div class="byline"><a href="https://github.com/loopx-project/loopx">LoopX</a><span>·</span><time datetime="2026-11-01">2026 年 11 月 1 日</time></div></div>
+<div class="article-layout"><aside class="toc"><details><summary>本文目录</summary><nav aria-label="本文目录"><a href="#example">用“管家读语音”串起一次工作</a><a href="#known-paths">知道位置，直接一次读齐</a><a href="#discover">不知道结构，查相关目录，再往下读</a><a href="#requirements">要求先看见，证明它的材料再展开</a><a href="#sharing">同一份交付里的相同记录，保留一个完整位置</a><a href="#cycle">下一轮继续，交付这次改变了什么</a><a href="#native-path">开启后，默认交付的是一个读取入口</a><a href="#recovery">压缩或读取失败，恢复上下文，也保留原工作</a><a href="#evidence">这些数据说明了什么</a><a href="#reproduce">用同一份材料动手读一遍</a></nav></details></aside><article class="prose"><p>Agent 做长任务，资料会越来越多：原目标、后来追加的约束、试过的方案、失败的实验、当前做到哪里。每次继续都把整份材料再塞一遍，重复会不断累积；只留一段摘要，又可能找不回决定所依赖的原话。</p>
+<p>LoopX 的 context delivery 把这件事拆开做：<strong>完整资料保存下来，当前决定需要的事实先读，支持材料沿问题展开；同一个有效 compaction 周期内，再精确复用没有变化的结构。</strong></p>
+<p>本文核对源码 <a href="https://github.com/loopx-project/loopx/tree/73cf83edd6d80275d0c8f44c5289837eebe8ab0d"><code>73cf83ed</code></a> 的 Codex 原生路径；它是 2.2 候选源码，最终发布状态以 <a href="https://github.com/loopx-project/loopx/releases">Releases</a> 为准。该实现的默认策略是：受支持的 POSIX Codex App／SSH 会话与新的 benchmark heartbeat 开启 context delivery；已有关闭设置继续生效，也可以显式关闭。开启后完整内容先保存，Agent 收到当前读取入口。</p>
+<p>可以把它想成查一本厚书：capture 是完整保存的那本书，目录告诉我们章节在哪，JSON Pointer 是书内地址。渐进式读取决定这一刻翻到多深；差分决定下一轮哪些内容可以沿用。</p>
+<h2 id="example">用“管家读语音”串起一次工作</h2>
+<p>假设要让管家理解语音消息，并在原对话返回结果。完整资料里保留了目标、服务约束、隐私要求、验收，以及很长的方案讨论。下面是教学示意，后文的示例程序会生成完整数据，可在隔离目录复现。</p>
+<pre><code class="language-text">capture.json
+├── goal
+│   ├── objective：理解语音，并在原对话返回结果
+│   ├── constraints
+│   │   ├── provider：优先已有语音服务
+│   │   └── privacy：音频不能公开，外部处理仍需已有授权
+│   └── acceptance：转写正确、回到原对话、不可用时明确告知
+├── providers
+│   ├── configured
+│   │   ├── formats
+│   │   └── authorization
+│   └── alternative
+│       ├── formats
+│       └── authorization
+├── evidence：试验结果、输入格式、回传位置
+└── history：80 条完整历史讨论
+</code></pre>
+<p>Agent 此时先要弄清接入边界。它必须同时知道“优先已有服务”和“外部处理仍需授权”；服务偏好本身并不授权发送音频。历史讨论仍然保存着，可以在比较方案、核对依据时继续读。</p>
+<p>完整来源从已有 typed owner 装配，带着 Goal、完整任务、累计验收和来源修订。已标记的机器生成区域由 canonical 任务接续，其余原叙事、注释和停止条件完整保留，不能按标题猜哪些文字可以删。这个例子将当前接入边界完整放在 <code>goal</code>；来源另有必读要求时，仍按它的读取约定执行。</p>
+<p>为了把机制讲具体，下面的数据来自这份<strong>合成材料上的实际 reader／编码器测量</strong>。它没有调用模型或语音服务。文末提供<a href="../../context-delivery/example.py">生成完整案例的程序</a>和<a href="../../context-delivery/measurements.json">原测量记录</a>。</p>
+<h2 id="known-paths">知道位置，直接一次读齐</h2>
+<p><code>/goal/constraints</code> 是 JSON Pointer：从 JSON 根进入 <code>goal</code>，再进入 <code>constraints</code>。它类似文件路径，但定位的是 <strong>JSON 内部的值</strong>。</p>
+<p>文件名、Pointer 和摘要各管一件事：<code>capture.json</code> 找到完整文件，Pointer 找到里面的位置，SHA-256 确认是哪一版。数组的 <code>/requirements/0</code> 表示第 1 项；数组重排后，同一位置可能变成另一项，所以地址必须和捕获版本一起使用。</p>
+<p>运行文末的示例程序后，<code>$CAPTURE</code> 指向输出目录的 <code>capture.json</code>，<code>$SHA</code> 取自同目录的 <code>manifest.json</code>。一次选择三个已知位置：</p>
+<pre><code class="language-sh">loopx --format json quota context-read \
+  --capture-file &quot;$CAPTURE&quot; --capture-sha256 &quot;$SHA&quot; \
+  --select /goal/objective \
+  --select /goal/constraints \
+  --select /goal/acceptance
+</code></pre>
+<p>一次拿到目标、完整约束和验收，就能同时看到服务偏好与隐私边界。多次 <code>--select</code> 合并的是读取请求；三个值仍分别带着自己的 Pointer，便于核对出处。</p>
+<p>这份完整 capture 为 <strong>51,547 字节</strong>。在相同文件、每页 16,000 字节、CLI 输出上限 20,000 字节的设置下：</p>
+<div class="table-scroll" role="region" tabindex="0" aria-label="可横向滚动的数据表"><table>
+<thead>
+<tr>
+<th>读取方式</th>
+<th style="text-align:right">CLI 调用次数</th>
+<th style="text-align:right">返回正文</th>
+<th style="text-align:right">CLI 完整返回</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>分页读完整 capture</td>
+<td style="text-align:right">4</td>
+<td style="text-align:right">51,547 B</td>
+<td style="text-align:right">55,607 B</td>
+</tr>
+<tr>
+<td>三个位置分别读取</td>
+<td style="text-align:right">3</td>
+<td style="text-align:right">804 B</td>
+<td style="text-align:right">2,694 B</td>
+</tr>
+<tr>
+<td>三个位置一次批量读取</td>
+<td style="text-align:right">1</td>
+<td style="text-align:right">674 B</td>
+<td style="text-align:right">1,362 B</td>
+</tr>
+</tbody>
+</table></div>
+<p>后两行取到的 Pointer／值完全相同，差别在重复请求和响应封装。第一行还读出了全部历史，信息范围更大。这里比较的是“当前先读三处事实”这一步；完整 capture 的生成、保存与首次引用是共同前置成本。</p>
+<h2 id="discover">不知道结构，查相关目录，再往下读</h2>
+<p>如果 Agent 不知道服务记录里有哪些字段，可以只展开 <code>/providers</code>。<code>--list</code> 返回目录元数据：Pointer、类型、大小，以及对象或数组的成员数量。</p>
+<pre><code class="language-sh">loopx --format json quota context-read \
+  --capture-file &quot;$CAPTURE&quot; --capture-sha256 &quot;$SHA&quot; \
+  --select /providers --list --list-depth 2
+</code></pre>
+<p><code>--list-depth 2</code> 一次看到服务项和它们下面的字段：</p>
+<pre><code class="language-text">/providers/configured                 object
+/providers/configured/formats         array
+/providers/configured/authorization   string
+/providers/alternative                object
+/providers/alternative/formats        array
+/providers/alternative/authorization  string
+</code></pre>
+<p>随后可以批量读格式和授权状态。目录告诉 Agent 去哪里找；值要通过 <code>--select</code> 真正读到，才能支撑后续决定。</p>
+<p>同一份目录，本例逐层列出 <code>/providers</code> 和它的两个服务子树，需要 <strong>3 次调用、2,784 字节 CLI 返回</strong>；两层一次展开，得到相同的一组字段地址，需要 <strong>1 次调用、1,283 字节返回</strong>。</p>
+<p><strong>知道地址就直接读，不知道才查相关目录。</strong> 小引用能放下时已经附有顶层目录，也不需要再从头查一遍。渐进式读取围绕当前问题展开，并不固定要求“先目录、再单字段、再下一层”的调用顺序。</p>
+<h2 id="requirements">要求先看见，证明它的材料再展开</h2>
+<p>“接入成功”不只意味着转写文本正确。这个任务还要求结果回到原对话。</p>
+<p>示例里的两次记录是：</p>
+<pre><code class="language-text">sample-1：转写正确，回到了原对话
+sample-2：转写正确，却回复到了另一对话
+</code></pre>
+<p>验收时，如果只看“转写成功”的摘要，就可能放过第二个问题。LoopX 已实现的原生验收分层会保留完整要求和当前评审状态，让 Agent 先看到关键字段：</p>
+<pre><code class="language-json">{
+  &quot;description&quot;: &quot;转写结果回到原对话，保留消息来源、顺序及原始音频引用。&quot;,
+  &quot;status&quot;: &quot;unverified&quot;,
+  &quot;agent_review&quot;: {
+    &quot;conclusion&quot;: &quot;unmet&quot;,
+    &quot;basis_current&quot;: false,
+    &quot;independently_verified&quot;: false
+  }
+}
+</code></pre>
+<p>要求没有通过、已有依据过期，这些事实先出现在决策层。为什么失败、哪些证据支持这个判断，再沿原文入口读深。Agent 自评与独立核验也保留为不同事实。</p>
+<p>实际实现中的 <code>supporting_material_pointer</code> 给出原始 outcome 的位置。假设把这个返回前缀记为 <code>$P</code>，需要评审解释时，就沿它接上 <code>/requirements/2/agent_review/note</code>；需要证据引用时，接上 <code>/requirements/2/agent_review/evidence_refs</code>。前缀来自当前捕获，不能照抄另一份文件的数组序号。</p>
+<p>本例将语音任务装配成现有 typed owner 支持的验收结构后，完整原始捕获是 <strong>57,014 字节</strong>，必要视图为 <strong>5,107 字节</strong>。<strong>10 条要求的原文全部保留，未通过、依据过期和独立核验标记仍在；原始 57,014 字节也完整保存。</strong> 支持历史与长解释有了可展开的地址。</p>
+<p>关系导航还可以沿任务依赖、共享验收、来源和证据，建议先看哪些 outcome。关系不完整时扩大范围；其他路线的反证仍然可达。它帮助安排阅读顺序，最终哪些事实影响当前判断，仍需要 Agent 理解。</p>
+<h2 id="sharing">同一份交付里的相同记录，保留一个完整位置</h2>
+<p>同一个任务可能同时出现在“当前工作”和“队列摘要”里。完全相同的正文重复两遍，并没有增加事实。</p>
+<p>原生必要视图可以保留一份完整任务，让另一处准确引用它：</p>
+<pre><code class="language-json">{
+  &quot;todo_id&quot;: &quot;todo_voice&quot;,
+  &quot;context_ref&quot;: &quot;/agent_todo_summary/first_open_items/0&quot;
+}
+</code></pre>
+<p>这条引用指向<strong>同一份当前视图</strong>中的完整记录。本例将任务记录与引用各自单独序列化（含结尾换行），分别为 <strong>1,052 字节</strong>和 <strong>80 字节</strong>；完整约束仍在原位置，每个队列的成员和顺序也保留。</p>
+<p>这是精确共享。标题相同、版本不同，或者 owner、证据、约束不同的记录，要继续分别保留。陌生字段和不支持的结构也保留原内容。这样的共享不依赖旧会话基线，和下一节跨轮次的差分是两件事。</p>
+<h2 id="cycle">下一轮继续，交付这次改变了什么</h2>
+<p>现在语音任务继续推进：新增了第三个样本，工作从“核验原对话返回”进入“核验修复后的返回”，评审依据也更新了。原目标和大部分要求没有变化。</p>
+<p>这时可以做 <strong>compaction 周期内的结构化上下文差分</strong>。</p>
+<p>在同一有效周期内，保存的完整基线经过核验，不变的文字、数组和对象可以精确复用；新增、修改、删除与数组重排则明确表示。对象换了位置时，也可以引用原子树，再叠加这次修改。还原后必须与完整当前来源一致。</p>
+<pre><code class="language-text">同一周期
+上一份：完整目标 + 全部要求 + 样本 1、2 + 旧工作状态
+这一份：新增样本 3；更新工作状态与评审依据
+还原后：仍是完整的当前上下文
+</code></pre>
+<p>同一合成任务、同一 scope 下，本例编码层得到：</p>
+<div class="table-scroll" role="region" tabindex="0" aria-label="可横向滚动的数据表"><table>
+<thead>
+<tr>
+<th>情况</th>
+<th>编码结果</th>
+<th>大小或读回结果</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>当前视图完整编码</td>
+<td>full</td>
+<td>5,543 B</td>
+</tr>
+<tr>
+<td>有效周期内复用已核验基线</td>
+<td>delta</td>
+<td>2,164 B；完整还原逐值一致</td>
+</tr>
+<tr>
+<td>切换 context epoch</td>
+<td>full</td>
+<td>不沿用旧周期基线</td>
+</tr>
+<tr>
+<td>差分内容损坏</td>
+<td>恢复当前 full</td>
+<td>与完整当前视图逐值一致</td>
+</tr>
+<tr>
+<td>很小的两字段输入发生变化</td>
+<td>full</td>
+<td>差分开销不合适，保留完整交付</td>
+</tr>
+</tbody>
+</table></div>
+<p>这张表测的是编码结果。原生适配层还会比较文件引用、分页封装和读取指令等实际交付字节；完整交付更合适时使用 full。大小比较服务于交付效率，不能替代事实完整性。</p>
+<h2 id="native-path">开启后，默认交付的是一个读取入口</h2>
+<p>把前面的动作接回产品，当前支持的 Codex 原生 quota 路径是：</p>
+
+<figure class="diagram"><p class="diagram-label">Context delivery 开启后的路径</p><ol><li><strong>完整来源</strong>：projection.json 保存当前事实。</li><li><strong>必要视图</strong>：required-context.json 保留完整要求，支持材料指回原文。</li><li><strong>周期交付</strong>：核对基线与 scope，选择 full 或 delta。</li><li><strong>当前读取入口</strong>：首读当前准入、停止条件、原任务与累计要求；目录和短概览在放得下时附上。需要解释时，沿 Pointer 展开。</li></ol><figcaption>文件是可核验的来源；进入模型的内容，还取决于实际完成了哪些读取。</figcaption></figure>
+<p>这里有一个很有用的设计：<strong>即使返回 <code>mode: &quot;delta&quot;</code>，Agent 也能从当前 <code>recovery</code> 直接选读事实。</strong> 它不必为了开始判断，先通读旧基线或重放全部差分。差分的 <code>path</code> 可以指向 <code>delivery.json</code>，而 <code>recovery</code>、<code>select_command</code> 指向当前完整视图；<code>context_details</code> 再把支持材料接回原始捕获。</p>
+<p>原生导航还把完整 capture／selection 摘要保存在不可变的私有 reader 引用中。Agent 复制返回的引用读内容，CLI 仍在每页校验完整摘要、选择与游标；并没有把 SHA256 截短。<code>first_read_command</code> 是起始选读，不代表全部必读来源已经读完。</p>
+<pre><code class="language-bash"># 从当前返回的 recovery.reference_file 复制原 recovery 引用。
+loopx --format json quota context-read \
+  --reference-file &quot;$RECOVERY_READER_REFERENCE&quot; \
+  --select &quot;$POINTER_A&quot; --select &quot;$POINTER_B&quot;
+</code></pre>
+<p>续页引用固定当前选择，沿它返回的 <code>next_command</code> 读至 EOF；更换 Pointer 时，回到原 recovery 引用。极小预算可能保留原显式文件／摘要接口。上面的教学测量也使用这个兼容接口，数字仍对应原实验条件。</p>
+<p>文件基线和模型此刻保留了什么，需要分别判断。保存文件可核验，不能据此假定模型记住了全部原文。</p>
+<h2 id="recovery">压缩或读取失败，恢复上下文，也保留原工作</h2>
+<p>宿主发生 compaction，后续新工作轮次建立新的完整基线。原目标、要求和来源仍然存在，必要事实可以重新读到。</p>
+<p>如果压缩、缺页或输出截断发生在尚未结束的 Turn 内，就沿原捕获补回缺失事实，保留原任务、执行和结算身份。假设语音结果已经发送，只是回执没有读到，恢复上下文不能变成再发一次结果。</p>
+<p>读取本身也有明确的失败边界：</p>
+<ul>
+<li><strong>来源变了，摘要没变：</strong> 拒绝这次读取，先核对版本。</li>
+<li><strong>路径不存在：</strong> 整个批次拒绝；先从已知父节点查目录。存在但值为 <code>null</code>，则正常返回 <code>null</code>。</li>
+<li><strong>长内容跨页：</strong> 按 <code>next_command</code> 接读，保留捕获摘要、选择摘要和字节游标，按连续偏移组合正文。某组选读的 EOF 只覆盖该选择。</li>
+<li><strong>遇到未知结构或不适用的来源：</strong> 保留完整内容及原有读取义务，不猜哪些文字可以隐藏。</li>
+</ul>
+<figure class="diagram"><p class="diagram-label">连续性与恢复</p><p><strong>同一有效周期</strong>：完整基线 → 新事实与差分 → 完整还原。</p><p><strong>新周期或已知连续性丢失</strong>：当前完整来源 → 必要事实重新读取。</p><figcaption>未结束的 Turn 保留原捕获、原工作与结算身份。恢复读取不重新执行外部副作用。</figcaption></figure>
+<h2 id="evidence">这些数据说明了什么</h2>
+<p>这组例子把三个收益来源分开了：<strong>少重复搬当前用不上的历史，少发本可合并的读取请求，少重复交付已经核验的不变结构。</strong> 完整来源、要求与恢复路径贯穿其中。</p>
+<p>上面的 reader 数字包含实际 CLI 响应中的分页元数据；本机路径长度会影响少量封装字节。原生投影数字比较捕获正文，周期表比较编码层，三种口径分别列出。示例脚本可复算这些值与完整还原结果。</p>
+<p>放回真实长程任务，还要把必要补读、恢复、缓存命中、模型输入输出、工具调用、等待与人工介入一起算进去；效果则看是否漏掉约束、做错决定，最后交付了什么。这个合成例子测清了机械路径，真实模型收益仍需可比任务验证。</p>
+<p>当前实现已覆盖完整来源、文件入口、批量选择、目录深度、适用验收分层、精确共享、周期差分与恢复。更广的候选、偏好、Explore 按决策阶段统一交付及 C1 全入口收敛仍有未完成部分。受支持的 Codex 会话未保存偏好时默认开启；在「设置 → 本机 → 能力 → 差分上下文 → Codex」关闭，已有 off 会保留。单次命令或新 benchmark trial 可用 <code>--context-delivery off</code>；trial 不继承本机开关，已有冻结 trial 也不被重写。设置、准确 hooks／配置、实际采用分别核验；hooks 不可用时完整交付。普通 CLI、不支持的宿主和非 heartbeat benchmark 保留原完整路径。具体 2.2 发布资格沿最终版本确认。</p>
+<h2 id="reproduce">用同一份材料动手读一遍</h2>
+<p><a href="../../context-delivery/example.py">example.py</a> 完整生成这个合成语音任务，调用现有 reader、渐进投影与差分 owner，逐项核对选择值、目录地址、全部 10 条要求、共享引用与完整恢复。程序不注册 Goal，不做准入或结算，也不调用模型或语音服务。</p>
+<p>先准备原测量的源码 <code>a4a0fad889d91cba0d945ce658788bdb76ba351e</code> 及其兼容依赖，在该 checkout 根目录运行。将下载的程序路径填入下方；输出目录必须为空。</p>
+<pre><code class="language-sh">uv run --extra test python /path/to/example.py \
+  --loopx-root &quot;$PWD&quot; --output .local/context-delivery-example
+</code></pre>
+<p>生成的 <code>capture.json</code> 保留全部 80 条历史；<code>projection.json</code>、<code>required-context.json</code> 对应完整／必要视图；<code>cycle-base.json</code>、<code>cycle-delta.json</code> 对应周期编码；<code>manifest.json</code> 固定文件与摘要。生产中使用当前返回的真实路径，不能照抄教学树或另一份捕获的数组位置。</p>
+<p><a href="../../context-delivery/measurements.json">原测量记录</a>固定本文数据。程序在其他源码上可以检查机制，但新结果不能改写原观察；页面封装字节还受本机路径长度影响。无需启动一次新研究来理解这个例子。</p>
+<p>来源：<a href="https://github.com/loopx-project/loopx/blob/0e78a19c277f4ca3d44313787162bc0444065172/docs/reference/required-work-context.md">完整交付契约</a> · <a href="https://github.com/loopx-project/loopx/blob/0e78a19c277f4ca3d44313787162bc0444065172/loopx/control_plane/quota/progressive_context.ts">渐进投影</a> · <a href="https://github.com/loopx-project/loopx/blob/0e78a19c277f4ca3d44313787162bc0444065172/loopx/control_plane/quota/context_selection.ts">选择与目录</a> · <a href="https://github.com/loopx-project/loopx/blob/0e78a19c277f4ca3d44313787162bc0444065172/loopx/control_plane/quota/context_delivery.ts">差分与恢复</a>。例子运行源为 <code>a4a0fad</code>；上述三项核心 owner 与 <code>0e78a19</code> 逐字一致。原生最终交付还会核算引用和后续读取，不能由编码层数字替代。</p>
+<nav class="article-route" aria-label="继续阅读"><p><a href="../typescript-control-plane-refactor/">TypeScript：语义怎样被修复</a> · <a href="../edgebench-feedback-and-memory/">EdgeBench：机制有没有换来成果</a></p></nav></article></div></main>
+<footer class="site-footer"><a class="brand" href="../../../?lang=zh">LoopX</a><p>让工作持续推进，让判断由人掌握。</p><a href="#main" aria-label="返回开头">↑</a></footer></body></html>
diff --git a/apps/presentation/site/public/blog/zh/edgebench-feedback-and-memory/index.html b/apps/presentation/site/public/blog/zh/edgebench-feedback-and-memory/index.html
index b939f4df97..88961448c7 100644
--- a/apps/presentation/site/public/blog/zh/edgebench-feedback-and-memory/index.html
+++ b/apps/presentation/site/public/blog/zh/edgebench-feedback-and-memory/index.html
@@ -16,7 +16,7 @@
 <link rel="stylesheet" href="../../images/edgebench-feedback-and-memory/article.css">
 </head>
 <body><main id="main"><div class="language"><a href="../">← LoopX 博客</a><a href="../../edgebench-feedback-and-memory/" lang="en">English</a></div>
-<header><p class="muted">黄睿腾 · 2026 年 10 月 29 日</p><h1>让 Agent 多做十小时，究竟多做出了什么？</h1><p class="subtitle">EdgeBench 如何反过来改造 LoopX 的长程控制面</p><p class="lead">一项研究可以起步更好，却在接下来的十小时里几乎没有增长。也可以不断改代码，最后丢掉最好结果。我们用这两种失败，重新审视目标、反馈、实验步长与恢复。</p><p>这条研究从 10 月初的轨迹诊断开始，先修评测与续跑，再追踪证据怎样进入下一次实验，最后把控制面自己的成本算进来。下面按这个过程展开：哪些机制改了，哪些结果支持它，哪些结果迫使我们改方向。</p></header><nav aria-label="文章目录"><a href="#research-history">研究时间线</a><a href="#ledger">可信反馈</a><a href="#goal-continuity">目标不丢</a><a href="#experiment-stride">实验步长</a><a href="#recovery-state">完整恢复</a><a href="#later-common-windows">后程结果</a><a href="#context">总成本</a></nav><section id="thesis">
+<header><p class="muted">黄睿腾 · 2026 年 10 月 29 日</p><h1>让 Agent 多做十小时，究竟多做出了什么？</h1><p class="subtitle">EdgeBench 如何反过来改造 LoopX 的长程控制面</p><p class="lead">一项研究可以起步更好，却在接下来的十小时里几乎没有增长。也可以不断改代码，最后丢掉最好结果。我们用这两种失败，重新审视目标、反馈、实验步长与恢复。</p><p>这条研究从 10 月初的轨迹诊断开始，先修评测与续跑，再追踪证据怎样进入下一次实验，最后把控制面自己的成本算进来。下面按这个过程展开：哪些机制改了，哪些结果支持它，哪些结果迫使我们改方向。</p></header><p>本文回答机制怎样改变真实研究，以及还没有改善什么。若想先看“下一次决定到底读到了什么”，可从<a href="../context-delivery/">上下文的渐进与差分交付</a>开始，再回到下文的成果与完整成本。</p><nav aria-label="文章目录"><a href="#research-history">研究时间线</a><a href="#ledger">可信反馈</a><a href="#goal-continuity">目标不丢</a><a href="#experiment-stride">实验步长</a><a href="#recovery-state">完整恢复</a><a href="#later-common-windows">后程结果</a><a href="#context">总成本</a></nav><section id="thesis">
 <p>这里的 kernel 指 LoopX 共享的目标、准入、事务和恢复规则。LoopX 让原始目标、验收条件、工作归属和证据跨会话、跨宿主持久化。控制面约束状态转换，为模型的下一步提供反馈，但不能认证这个选择是否高明。一条发现、一次读取回执、一条 replan 记录都只是中间证据；真正需要追踪的链条，要落到实际工作和经过验证的成果。</p>
 <p>这些规则的归属和<a href="../typescript-control-plane-refactor/#model-assisted-semantics">强模型参与的语义修复</a>，见 TypeScript 重构一文。下面从研究过程检查这些规则怎样影响实际工作。</p>
 <ol class="flow" aria-label="基于证据的工作循环"><li><strong>目标</strong><span>验收与范围</span></li><li><strong>证据</strong><span>结果与限制</span></li><li><strong>决策</strong><span>继续或换方向</span></li><li><strong>工作</strong><span>执行与验证</span></li><li><strong>保留</strong><span>保住最佳有效成果</span></li></ol>
@@ -75,7 +75,7 @@ <h3 id="input-share">把结构输入单独计量</h3>
 <details><summary>较早的字节对照与撤回的测量</summary><span id="staged-context"></span><span id="staged-transport"></span>
 <p>历史离线回放说明了为什么必须算总量：结构化 Host 和原生呈现字节下降 57.72%、60.23%，原生入口加完整恢复上升 6.37%。这些是历史字节观察，不是当前提交的模型 token 结果。早期离线探针还曾报告 CLI 字节增加 2.25%，但因漏掉最终 CLI 压缩并重新格式化入口，已撤回其实际 CLI 交付测量资格。该数字仅作为无效历史记录保留，不用于完整交付或成本结论。不能把视图缩小 60% 写成总成本下降 60%。</p>
 </details>
-<p>当前效率工作把普通入口、分段交付接到共享传输，减少重复读取和重新绑定，消掉可避免的结算往返。差分关闭的默认路径同样重要；开启后也必须正确恢复，并让产品和 benchmark 都易于启用。<strong>所有机制合计 15%</strong> 的参考目标尚未完成资格验证；它不是每个机制各有一份额度，也不能用来漏记失败和重建成本。</p>
+<p>这条效率主线把普通入口、分段交付接到共享传输，减少重复读取和重新绑定，消掉可避免的结算往返。当前 context delivery 的渐进选择、必要事实分层、精确共享与周期差分，另见<a href="../context-delivery/">完整机制与语音任务示例</a>。启用后的实际读取、关闭后的原路径和失效恢复都需要分别核验；新实现不能回填历史实验的资格。<strong>所有机制合计 15%</strong> 的参考目标尚未完成资格验证；它不是每个机制各有一份额度，也不能用来漏记失败和重建成本。</p>
 </section><details><summary>同点接续：完整结果与用量</summary><section id="memory"><h3>证据有没有改变下一步工作？</h3>
 <span id="decision-followthrough"></span><p>成熟 checkpoint 可以帮助观察一个具体决策边界。接收者继承相同科学状态和 incumbent，再追踪它读了什么证据、选了什么实验、实际做了什么、原生反馈如何。负向本地结果若能在明确条件下排除一条分支，也有价值。继续原方向有依据时，replan 不必强行改道。</p>
 <p>近期 <a href="https://github.com/loopx-project/loopx/pull/7269">#7269</a> 让 Agent 先读目标、事实和反馈，再读写回格式；释放过时的任务选择偏好，并在创建 successor 后保留原 Turn 的结算身份。它对应两个真实往返来源：决策前先读大段写入指令，以及后续任务创建后还要补一轮确认结算归属。</p>
@@ -110,6 +110,6 @@ <h3 id="input-share">把结构输入单独计量</h3>
 <p>截至 10 月 28 日的上下文研究让 Grid、Schema、Ad Placement 从原始任务开始，使用 Sol/max，每题最多 18h。可用的历史 Official 或旧 LoopX 作为描述性参考，保留模型／effort、源码、评分器、机会和时钟差异，不冒称严格配对；旧材料无法回答相应问题时再补 base。各次尝试按实际源码、连续性依据和传输路径分别分析，不合并成同一处理。</p>
 <p>先核实实际交付确实改变：首次完整读取、声明连续性依据的后续差分、已知基线失效时的完整回退，以及一次从复盘到工作的完整交互。再比较有效进展、成果保留和完整用量。开关、回执、局部小包都不能替代这些证据。Feature 偏离预期时，停止相关尝试，保留其成本和历史，修复后用新的尝试身份重启。</p>
 <p>新原生 Hook 路径的首批 Grid、Ad 交互已完成完整分页、一次差分及后续任务工作。同一次捕获内，差分载荷分别比对应完整包小 19.53%、19.48%；这只是一轮读取的载荷比较，不含分页封装、后续模型输入、Hook、恢复或复盘费用，不能外推为总成本下降。完整复盘到后续原生成果、持续收益和故障恢复仍待验证。</p><p>效果目标是很多小时之后仍能取得有效进展并保住成果；效率目标是用更低完整成本和人工介入取得同等验收价值。下一份结果需要同时回答它们；这些尝试沿用各自原定截止时间，替换尝试的失败和消耗也保留。</p>
-</section><footer><p>数值分别保留各历史模型、版本、窗口与有效性边界。公开实现：<a href="https://github.com/loopx-project/loopx">LoopX</a>。早期详细记录保留在<a href="https://github.com/loopx-project/loopx/blob/a9a720db/apps/presentation/site/public/blog/zh/edgebench-feedback-and-memory/index.html">上一版文章</a>。这里不发布原始轨迹、隐藏评测材料、运行时凭证或私有操作上下文。</p></footer>
+<p>这里保留的是 10 月 28 日的研究检查点。后续 reader、默认策略或编码器合入，不会使这些未验证项自动通过。<a href="../context-delivery/#evidence">机制文章的合成字节测量</a>与本节的模型轨迹属于不同证据层，不能拼成一项节费结论。</p></section><footer><p>数值分别保留各历史模型、版本、窗口与有效性边界。公开实现：<a href="https://github.com/loopx-project/loopx">LoopX</a>。早期详细记录保留在<a href="https://github.com/loopx-project/loopx/blob/a9a720db/apps/presentation/site/public/blog/zh/edgebench-feedback-and-memory/index.html">上一版文章</a>。这里不发布原始轨迹、隐藏评测材料、运行时凭证或私有操作上下文。</p></footer>
 </main></body>
 </html>
diff --git a/apps/presentation/site/public/blog/zh/index.html b/apps/presentation/site/public/blog/zh/index.html
index ac8efafc64..c12680f671 100644
--- a/apps/presentation/site/public/blog/zh/index.html
+++ b/apps/presentation/site/public/blog/zh/index.html
@@ -29,11 +29,15 @@
     <a href="../../blog/zh/" aria-current="page">Blog</a>
     <a href="../../docs/book/">文档</a>
   </nav>
-  <div class="header-actions"><a class="language" href="../../blog/" lang="en" hreflang="en" aria-label="Read in English">EN</a><a class="github" href="https://github.com/huangruiteng/loopx">GitHub <span aria-hidden="true">↗</span></a></div>
+  <div class="header-actions"><a class="language" href="../../blog/" lang="en" hreflang="en" aria-label="Read in English">EN</a><a class="github" href="https://github.com/loopx-project/loopx">GitHub <span aria-hidden="true">↗</span></a></div>
 </header>
 <main id="main" class="blog-index">
   <div class="index-heading"><p class="eyebrow">LoopX · 博客</p><h1>长程工作的工程实践。</h1><p class="lead">关于长程 Agent 的设计、工程与实践。</p></div>
-  <nav class="reading-routes" aria-labelledby="reading-routes"><h2 id="reading-routes">按问题阅读</h2><ul><li><b>快速建立全貌</b><span>先读这篇短分享，再按工作场景选择实践。</span><p><a href="semantic-software-development/">短分享</a> <span aria-hidden="true">→</span> <a href="application-scenarios/">应用场景</a></p></li><li><b>深入机制</b><span>核心架构讲系统分工，Kanban 展开协作契约。</span><p><a href="from-one-shot-agents-to-long-horizon-control/">核心架构</a> <span aria-hidden="true">→</span> <a href="agent-facing-kanban/">原生 Kanban</a></p></li><li><b>核查证据与限制</b><span>研究报告和事故复盘分别回答效果与可靠性。</span><p><a href="edgebench-feedback-and-memory/">阶段研究</a> <span aria-hidden="true">→</span> <a href="five-freshness-incidents/">事故复盘</a></p></li><li><b>理解系统自迭代</b><span>沿公开历史看改进怎样进入下一轮。</span><p><a href="long-horizon-rsi/">自举与 RSI</a></p></li></ul></nav>
+  <nav class="reading-routes" aria-labelledby="reading-routes"><h2 id="reading-routes">按问题阅读</h2><ul><li><b>先了解 LoopX</b><span>长程工作需要保留哪些判断与责任？</span><p><a href="from-one-shot-agents-to-long-horizon-control/">核心架构</a> <span aria-hidden="true">→</span> <a href="application-scenarios/">应用场景</a></p></li><li><b>控制规则怎样修</b><span>从重试、事务、执行权与恢复的反例读起。</span><p><a href="typescript-control-plane-refactor/">TypeScript 语义重构</a></p></li><li><b>下一步读什么</b><span>用一个任务理解渐进式读取与周期差分。</span><p><a href="context-delivery/">Context delivery</a></p></li><li><b>机制是否有用</b><span>把起点、后程增量、成果保留和完整成本分开。</span><p><a href="edgebench-feedback-and-memory/">EdgeBench 研究</a> <span aria-hidden="true">→</span> <a href="five-freshness-incidents/">事故复盘</a></p></li></ul></nav>
+  <article class="post-listing">
+    <div><p class="eyebrow">Context delivery · 机制与实例</p><p class="listing-date"><time datetime="2026-11-01">2026 年 11 月 1 日</time></p></div>
+    <div><h2><a href="context-delivery/">Agent 读上下文，也需要一套“查书”的方法</a></h2><p>从同一个语音任务出发，讲清 JSON Pointer、批量选择、目录深度、完整要求、精确共享与 compaction 周期差分。合成字节测量与真实模型收益分别说明。</p><a class="read-post" href="context-delivery/">阅读全文 <span aria-hidden="true">↗</span></a></div>
+  </article>
   <article class="post-listing">
     <div><p class="eyebrow">研究札记 · EdgeBench 与 LHTB</p><p class="listing-date"><time datetime="2026-10-16">2026 年 10 月 16 日</time></p></div>
     <div><h2><a href="edgebench-long-horizon-repairs/">EdgeBench / LHTB：一轮历史试跑的工程复盘</a></h2><p>songoow 对历史 EdgeBench/LHTB 实验配置的探索性工程记录，包含提前中断、局部修复与待验证假设。feedback-first 开关已撤回；不代表 LoopX 官方或正式评测结论及当前版本能力。</p><a class="read-post" href="edgebench-long-horizon-repairs/">阅读全文 <span aria-hidden="true">↗</span></a></div>
@@ -47,8 +51,8 @@
     <div><h2><a href="semantic-software-development/">Agentic Software：从代码生成到长程自主研发</a></h2><p>以 LoopX 为例，讨论 Agentic Software 的通用基础设施：让目标、证据与人的反馈跨越会话，把探索推进为可验证的交付。</p><a class="read-post" href="semantic-software-development/">阅读全文 <span aria-hidden="true">↗</span></a></div>
   </article>
   <article class="post-listing">
-    <div><p class="eyebrow">研究札记 · EdgeBench</p><p class="listing-date"><time datetime="2026-10-05">2026 年 10 月 5 日</time></p></div>
-    <div><h2><a href="edgebench-feedback-and-memory/">让长程 Agent 的下一步有依据：LoopX 语义控制面的阶段性实验</a></h2><p>从 Portfolio 与 Lean 的真实轨迹，分析可信反馈、目标续行、条件化证据、渐进式上下文与研究选路；区分已验证的修复和未证明的能力增益。</p><a class="read-post" href="edgebench-feedback-and-memory/">阅读全文 <span aria-hidden="true">↗</span></a></div>
+    <div><p class="eyebrow">研究札记 · EdgeBench</p><p class="listing-date"><time datetime="2026-10-05">2026 年 10 月 5 日初稿</time> · <span>10 月 29 日修订</span></p></div>
+    <div><h2><a href="edgebench-feedback-and-memory/">让 Agent 多做十小时，究竟多做出了什么？</a></h2><p>从 10 月初到中下旬的研究过程，看可信反馈、目标、实验步长与恢复怎样被修正；用 Schema 的平台期和完整用量检验后程收益。</p><a class="read-post" href="edgebench-feedback-and-memory/">阅读全文 <span aria-hidden="true">↗</span></a></div>
   </article>
   <article class="post-listing">
     <div><p class="eyebrow">设计观点 · 系统级自迭代</p><p class="listing-date"><time datetime="2026-10-02">2026 年 10 月 2 日</time></p></div>
diff --git a/apps/presentation/site/public/blog/zh/typescript-control-plane-refactor/index.html b/apps/presentation/site/public/blog/zh/typescript-control-plane-refactor/index.html
index b4bb4de776..ee9c54f32d 100644
--- a/apps/presentation/site/public/blog/zh/typescript-control-plane-refactor/index.html
+++ b/apps/presentation/site/public/blog/zh/typescript-control-plane-refactor/index.html
@@ -13,12 +13,31 @@
 <a class="skip-link" href="#main">跳至正文</a>
 <header class="site-header"><a class="brand" href="../../../?lang=zh"><span class="product-mark" aria-hidden="true"><i></i><i></i></span>LoopX</a><nav aria-label="主导航"><a href="../">Blog</a><a href="../../../docs/book/">文档</a></nav><div class="header-actions"><a class="language" href="../../../blog/typescript-control-plane-refactor/" lang="en" hreflang="en">EN</a><a class="github" href="https://github.com/loopx-project/loopx">GitHub ↗</a></div></header>
 <main id="main"><div class="article-heading"><a class="back" href="../">← 全部文章</a><p class="eyebrow">LoopX 2.0 · Engineering</p><h1>LoopX 2.0：两个月的 TypeScript 控制面重构</h1><p class="lead">副作用做完却没记账，旧执行者拿着成功回执回来，修正证据意外重启任务——两个月的重构，逐步把这些问题收敛到完整事务和统一语义。</p><div class="byline"><a href="https://github.com/huangruiteng">Ruiteng Huang</a><span>·</span><time datetime="2026-10-16">2026 年 10 月 16 日</time><span>·</span><span>LoopX creator</span><span>·</span><time datetime="2026-10-29">2026 年 10 月 29 日补记</time></div></div>
-<div class="article-layout"><aside class="toc"><div class="desktop-contents"><p class="toc-caption">本文目录</p><nav aria-label="文章目录"><a href="#section-1">1. 先还原历史：迁移方案本身也在变化</a><a href="#section-2">2. 只统计核心 control plane：研发规模与代码变化</a><a href="#section-3">3. Effect Program 先行：先统一“做过什么”</a><a href="#section-4">4. 迁移完整事务：一次少到两次，也可能是正确答案</a><a href="#section-5">5. 共享权威：领域规则和存储原语分别归属</a><a href="#section-6">6. SQLite 之后：长程历史也要有成本模型</a><a href="#section-7">7. Song 的 Semantics：定义、生产、解释要接起来</a><a href="#model-assisted-semantics">8. 强模型怎样修复语义</a><a href="#section-8">9. 调用方和默认值，决定迁移能否到用户手上</a><a href="#section-9">10. 恢复原结果，同时保护当前执行权</a><a href="#section-10">11. CLI 输出约束：压缩前先保护决策语义</a><a href="#section-11">12. 最后退役：保留贡献，核对删除的究竟是什么</a><a href="#section-12">13. 社区贡献与下一步</a></nav></div><details class="mobile-contents"><summary>本文目录</summary><nav aria-label="文章目录"><a href="#section-1">1. 先还原历史：迁移方案本身也在变化</a><a href="#section-2">2. 只统计核心 control plane：研发规模与代码变化</a><a href="#section-3">3. Effect Program 先行：先统一“做过什么”</a><a href="#section-4">4. 迁移完整事务：一次少到两次，也可能是正确答案</a><a href="#section-5">5. 共享权威：领域规则和存储原语分别归属</a><a href="#section-6">6. SQLite 之后：长程历史也要有成本模型</a><a href="#section-7">7. Song 的 Semantics：定义、生产、解释要接起来</a><a href="#model-assisted-semantics">8. 强模型怎样修复语义</a><a href="#section-8">9. 调用方和默认值，决定迁移能否到用户手上</a><a href="#section-9">10. 恢复原结果，同时保护当前执行权</a><a href="#section-10">11. CLI 输出约束：压缩前先保护决策语义</a><a href="#section-11">12. 最后退役：保留贡献，核对删除的究竟是什么</a><a href="#section-12">13. 社区贡献与下一步</a></nav></details></aside><article class="prose">
-<p>LoopX 2.0 发布了。借这个节点，我想把 TypeScript 重构的历史和技术细节整理出来。</p>
+<div class="article-layout"><aside class="toc"><div class="desktop-contents"><p class="toc-caption">本文目录</p><nav aria-label="文章目录"><a href="#model-assisted-semantics">1. 强模型参与的，是这些跨边界的语义问题</a><a href="#section-1">2. 先还原历史：迁移方案本身也在变化</a><a href="#section-3">3. Effect Program 先行：先统一“做过什么”</a><a href="#section-4">4. 迁移完整事务：一次少到两次，也可能是正确答案</a><a href="#section-5">5. 共享权威：领域规则和存储原语分别归属</a><a href="#section-6">6. SQLite 之后：长程历史也要有成本模型</a><a href="#section-7">7. Song 的 Semantics：定义、生产、解释要接起来</a><a href="#section-8">8. 调用方和默认值，决定迁移能否到用户手上</a><a href="#section-9">9. 恢复原结果，同时保护当前执行权</a><a href="#section-10">10. CLI 输出约束：压缩前先保护决策语义</a><a href="#section-11">11. 最后退役：保留贡献，核对删除的究竟是什么</a><a href="#section-2">12. 只统计核心 control plane：研发规模与代码变化</a><a href="#section-12">13. 社区贡献与下一步</a></nav></div><details class="mobile-contents"><summary>本文目录</summary><nav aria-label="文章目录"><a href="#model-assisted-semantics">1. 强模型参与的，是这些跨边界的语义问题</a><a href="#section-1">2. 先还原历史：迁移方案本身也在变化</a><a href="#section-3">3. Effect Program 先行：先统一“做过什么”</a><a href="#section-4">4. 迁移完整事务：一次少到两次，也可能是正确答案</a><a href="#section-5">5. 共享权威：领域规则和存储原语分别归属</a><a href="#section-6">6. SQLite 之后：长程历史也要有成本模型</a><a href="#section-7">7. Song 的 Semantics：定义、生产、解释要接起来</a><a href="#section-8">8. 调用方和默认值，决定迁移能否到用户手上</a><a href="#section-9">9. 恢复原结果，同时保护当前执行权</a><a href="#section-10">10. CLI 输出约束：压缩前先保护决策语义</a><a href="#section-11">11. 最后退役：保留贡献，核对删除的究竟是什么</a><a href="#section-2">12. 只统计核心 control plane：研发规模与代码变化</a><a href="#section-12">13. 社区贡献与下一步</a></nav></details></aside><article class="prose">
+<p>重试一次操作，可能把副作用做两遍；读回一张成功回执，也可能恢复了早已过期的执行权。LoopX 的 TypeScript 重构，要修的正是这些跨越执行、存储与恢复的语义问题。</p>
+<h2 id="model-assisted-semantics">1. 强模型参与的，是这些跨边界的语义问题</h2>
+<p>我们把强能力模型用在设计、实现和评审里，尤其是跨文件、跨 runtime 的假设检查。真正难的部分往往是：几个局部判断都对，组合起来却允许错误的执行顺序。8、9 月的核心 PR 已经反复遇到这类问题；它们不是迁移收尾后的补丁。</p>
+<h3>副作用已经发生，记录还没写下：重试会不会做两遍？</h3>
+<p>假设 provider 已执行成功，进程却在写 checkpoint 前崩溃。只检查 journal，会看到“未完成”；直接重试可能重复执行。相反，把所有不确定都当作成功，又会吞掉尚未发生的工作。这不是一个 try/catch 能解决的问题。</p>
+<p>8 月 22 日的 <a href="https://github.com/loopx-project/loopx/pull/3485">#3485</a> 在执行前持久化 prepared attempt 和稳定的 effect identity。恢复先询问 provider：<strong>确认已提交，就补记原结果；确认不存在，才按同一身份执行；结果未知，就停在待恢复状态。</strong> 对 effect 顺序、receipt 前缀和身份的检查同时保留。这里没有承诺任意外部系统都能 exactly-once：能否确认原结果，仍取决于 provider 的恢复能力。</p>
+<p>它接续了 <a href="https://github.com/loopx-project/loopx/pull/3464">#3464</a> 的 preflight：执行前判断“能不能做”，中断后判断“是否已经做过”。两者共同保护一次完整操作。只把 Python 函数逐个翻译成 TS，保不住这两个时间边界。</p>
+<p>9 月 13 日的 <a href="https://github.com/loopx-project/loopx/pull/4286">#4286</a> 把七类 Todo 操作的回执恢复收敛到一个 owner，并保留了更细的区别。假设两个 Agent 同时修改任务：A 先提交，B 因版本冲突被明确拒绝；随后 B 查回执时断网。<strong>后一次读取失败，不能抹掉前一次明确拒绝。</strong> 若断连发生在提交响应返回前，结果才需要保持未知，并沿原 operation identity 恢复。</p>
+<p>这两条路径最后都可能遇到网络错误，下一步却不同。<a href="https://github.com/loopx-project/loopx/blob/c0b572d2d508bb10c32701057dd71ff4f8eb663c/loopx/control_plane/coordination/command_receipt.ts">共享实现</a>只尝试一次写入，随后读取原回执；<a href="https://github.com/loopx-project/loopx/blob/c0b572d2d508bb10c32701057dd71ff4f8eb663c/tests/control_plane_ts/command_receipt.test.ts">对应回归</a>分别检查明确拒绝、提交结果未知和准确回执恢复。统一错误处理不能丢掉错误发生的阶段，也不能把已知事实降成未知。</p>
+<h3>领取任务和取得执行权，必须是同一件事</h3>
+<p>两个 Agent 同时看到一个未领取任务。如果 claim 已写入、lease 尚未取得，中间状态究竟归谁？如果旧 Agent 曾成功领取，租约过期后又拿着旧 receipt 回来，它还能继续写吗？</p>
+<p>从 <a href="https://github.com/loopx-project/loopx/pull/3529">#3529</a>、<a href="https://github.com/loopx-project/loopx/pull/3669">#3669</a> 的协调基础，到 9 月 6 日的 <a href="https://github.com/loopx-project/loopx/pull/4032">#4032</a>，领取、租约和操作回执被纳入同一次条件提交。<a href="https://github.com/loopx-project/loopx/pull/3798">#3798</a> 的 store 负责原子持久化，领域 owner 判断身份、作用域和合法转换。<strong>回执证明过去那次领取成功；当前租约与 epoch 才决定现在能否执行。</strong> 操作重放要能找回原结果，却不能复活已失效的执行权。不同存储中的 revision 也不能与领域版本或 lease epoch 混用。</p>
+<p>这解释了为什么“幂等”不是把旧成功结果返回就结束。正确恢复既要记住历史，也要服从现在的权威状态。早期 foundation、shadow 和生产路径的资格是分阶段建立的，不能把第一个接口合入日写成所有后端都已投入使用。</p>
+<h3>修正一条证据，为什么会重新触发已经结束的工作？</h3>
+<p>规划更新尤其容易出现看似无害的默认值错误。用户只修正一条证据，没有改监控状态；如果更新逻辑用缺省值重建整个对象，已经满足的 monitor 可能被重新启用。与此同时，调用方显式传入空列表或 <code>false</code>，也不能被当作“没有提供”。</p>
+<p>9 月 10 日的 <a href="https://github.com/loopx-project/loopx/pull/4178">#4178</a> 将规划更新收敛到同一份权威快照和完整 TS transaction：省略保留原意，显式清空按字段与权限解释，证据修正不重新武装已满足的 monitor。它还删掉了 Python 合成 Markdown 再解析回状态的路径。这既是边界收敛，也是行为修复，不能笼统宣称逐字迁移、行为完全不变。</p>
+<p>Song 后续的 <a href="https://github.com/loopx-project/loopx/pull/4433">#4433</a>、<a href="https://github.com/loopx-project/loopx/pull/4494">#4494</a> 把这种检查延伸到词表的定义、实际生产与消费：一个枚举能编译，不代表所有调用方都在表达同一个含义。前文的 <code>skip</code> / <code>quota_skip</code> 和 action / decision 分离，属于同一条语义主线。</p>
+<h3>怎样约束模型给出的“看起来正确”</h3>
+<p>让模型先指出错误假设，再构造会推翻它的执行序列：提交后断连、旧 lease 重放、只更新证据、显式清空。随后检查真实 owner、provider 和调用入口。</p>
+<p>强模型帮助把散在各处的条件连起来；反例、真实存储与拒绝路径约束它的答案。目前没有逐 PR 的模型型号对照，不能据此量化某个模型的独立收益。我们能展示的是这些机制怎样改变，以及为什么需要改变。后来的 <a href="https://github.com/loopx-project/loopx/pull/7145">#7145</a> 运行时路由、<a href="https://github.com/loopx-project/loopx/pull/7269">#7269</a> 原 Turn 收尾是这条主线的延续，不代替前中期的核心工作。</p>
+<h2 id="section-1">2. 先还原历史：迁移方案本身也在变化</h2>
 <p>正式迁移 RFC 在 8 月 15 日合入。到 10 月中旬集中清理普通旧 writer，这项工程已经跨了差不多两个月。它有多条并行线：事务规则迁移、调用方收敛、共享权威、存储与历史成本、Semantics，以及后续兼容与退役。</p>
 <p>最后 3 位开发者与各自 Agent 接力的 <a href="https://github.com/loopx-project/loopx/pull/6396">#6396</a>，是这些工作累积后的一次集中收尾。前面的选择和转折，决定了最后能删什么，以及删掉以后还能恢复什么。</p>
 <p>其中，新 maintainer <strong>Song（<a href="https://github.com/songoow">@songoow</a>）</strong> 从 9 月中旬持续推进 Semantics RFC、词表收敛、生产证据和检查器修复。这部分也值得与事务、存储放在一起讲。</p>
-<h2 id="section-1">1. 先还原历史：迁移方案本身也在变化</h2>
 <p>LoopX 保存长程 Agent 的目标、任务、证据与执行边界。模型可以提出新路线，控制面要保护版本、执行权和状态提交，并在中断后找到正确的恢复位置。</p>
 <p>最初的大量实现是 Python，TS 的宿主、Pi 集成与 dashboard 已经存在。通过一次 Python 调用来做决策，再把结果接回 TS，是自然的起点。随着规则增多，默认值、状态解释、调用顺序和持久化也可能分散在两边。</p>
 <p>我们希望这些控制面规则有清楚的 typed owner，同时让 CLI、宿主和 App 共享合同。实际过程可以分成以下几个互相重叠的阶段。</p>
@@ -74,158 +93,6 @@ <h2 id="section-1">1. 先还原历史：迁移方案本身也在变化</h2>
 <figure><div class="figure-scroll" tabindex="0" role="region" aria-label="迁移历史：事务、权威与存储、Semantics 三条线交错推进"><a href="../../images/typescript-control-plane-refactor/timeline-zh.svg" target="_blank" rel="noopener"><img src="../../images/typescript-control-plane-refactor/timeline-zh.svg" alt="迁移历史：事务、权威与存储、Semantics 三条线交错推进" width="1100" height="640" loading="lazy"></a></div><figcaption>迁移历史：事务、权威与存储、Semantics 三条线交错推进 窄屏可横向滚动；点击查看原图。</figcaption></figure>
 <p>8 月原始提案考虑过 read-first 和分阶段 dual-read/dual-write。后来接受的方案改为 Effect Program 先行，再按完整事务替换、删除旧规则，生产路径只有一个语义 owner。最初提案中的阶段设想，不能直接当成 2.0 的运行时设计。</p>
 <p>这种变化很正常。重要的是把为什么改路线、已经切到哪里、哪些仍是 reference 或候选写清楚。当前维护中的 <a href="https://github.com/loopx-project/loopx/blob/488e4438e0e51eca023ac3f5e690603120851b0c/docs/architecture/rfcs/typescript-control-plane-migration-v0.zh-CN.md">TS RFC</a> 记录了这些检查点。</p>
-<h2 id="section-2">2. 只统计核心 control plane：研发规模与代码变化</h2>
-<p>为了把整段工程的规模说清楚，这里固定一个可复算的窄范围：<strong><code>loopx/control_plane/**</code></strong>。其他目录的 App、benchmark、文档、测试套件不计入核心代码量。这个目录自身的测试支持工具仍在目录口径内。</p>
-<p>基线是正式 TS RFC 合入前的 <code>d1fe059</code>，终点是 10 月 16 日的 <code>488e443</code>。从正式 RFC 到终点约 <strong>62 天</strong>，跨 63 个日历日期；其中 62 个日期有核心目录的主干提交。<a href="https://github.com/loopx-project/loopx/compare/d1fe05932ac28690d393a38c78b4738ac12c78c0...488e4438e0e51eca023ac3f5e690603120851b0c">起止源码对照</a>可以复查版本。</p>
-<h3>整个周期的研发活动</h3>
-<div class="table-scroll" role="region" tabindex="0" aria-label="可横向滚动的技术对照表"><table>
-<thead>
-<tr>
-<th>指标</th>
-<th align="right">核心目录口径</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>触及核心目录的主干落地提交，按第一父链去重</td>
-<td align="right"><strong>1,144</strong></td>
-</tr>
-<tr>
-<td>可核验关联的已合并 PR，按 PR 编号去重</td>
-<td align="right"><strong>1,121</strong></td>
-</tr>
-<tr>
-<td>这些 PR 的作者账号</td>
-<td align="right"><strong>56</strong></td>
-</tr>
-<tr>
-<td>本次 API 快照中的 review 记录</td>
-<td align="right"><strong>2,329</strong></td>
-</tr>
-<tr>
-<td>本次 API 快照中的会话评论，不含行内 review comments</td>
-<td align="right"><strong>1,631</strong></td>
-</tr>
-<tr>
-<td>有 review 记录的关联 PR</td>
-<td align="right"><strong>1,031 / 1,121</strong></td>
-</tr>
-<tr>
-<td>PR 创建至合并的中位历时</td>
-<td align="right"><strong>5.0 小时</strong></td>
-</tr>
-<tr>
-<td>PR 创建至合并的 P90 / P95 历时</td>
-<td align="right"><strong>25.4 / 45.0 小时</strong></td>
-</tr>
-</tbody></table></div>
-<p>这组范围包含同期的迁移、新能力、修复与维护。56 是 GitHub 账号数，其中有自动化与共享账号；它不等于 56 个人或 56 个 Agent。review 数也包含自审、重复审查等记录，部分讨论发生在合并后。合并历时包含等待，不能换算成有效研发工时。</p>
-<p>新 maintainer Song 在这个窄目录口径下关联 <strong>53 个 PR</strong>。他在 <code>loopx/semantics/</code> 等目录的贡献没有全部进入这个数，具体技术归属仍以本文的贡献说明和原 PR 为准。</p>
-<h3>代码结构与累计变化量</h3>
-<p>下表按物理行统计，包含注释和空行；列出的文件量只计相应语言源码。</p>
-<div class="table-scroll" role="region" tabindex="0" aria-label="可横向滚动的技术对照表"><table>
-<thead>
-<tr>
-<th>核心目录源码</th>
-<th align="right">基线</th>
-<th align="right">取证终点</th>
-<th align="right">期间累计新增 / 删除</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>Python</td>
-<td align="right">256 个文件；80,473 行</td>
-<td align="right">471 个文件；142,371 行</td>
-<td align="right">+120,899 / −59,001 行</td>
-</tr>
-<tr>
-<td>TypeScript</td>
-<td align="right">0 个文件；0 行</td>
-<td align="right">323 个文件；87,268 行</td>
-<td align="right">+104,769 / −17,501 行</td>
-</tr>
-<tr>
-<td>Python + TypeScript</td>
-<td align="right">80,473 行</td>
-<td align="right">229,639 行</td>
-<td align="right"><strong>+225,668 / −76,502 行</strong></td>
-</tr>
-</tbody></table></div>
-<p>TS 占终点这两种语言源码物理行数的 <strong>38.0%</strong>。这是目录里的语言结构，不能当作“38% 的控制面已完成迁移”：一部分旧入口本来就在目录外，迁移中也有模块归位、新能力与测试支持代码进入。</p>
-<figure><div class="figure-scroll" tabindex="0" role="region" aria-label="核心 control plane 的 Python 与 TypeScript 源码存量变化"><a href="../../images/typescript-control-plane-refactor/core-source-stock.svg" target="_blank" rel="noopener"><img src="../../images/typescript-control-plane-refactor/core-source-stock.svg" alt="核心 control plane 的 Python 与 TypeScript 源码存量变化" width="1100" height="640" loading="lazy"></a></div><figcaption>核心 control plane 的 Python 与 TypeScript 源码存量变化 窄屏可横向滚动；点击查看原图。</figcaption></figure>
-<p>累计新增和删除按主干每次落地差分相加，同一行反复修改会重复计数；两端存量只看各自快照。本次将累计净变化与端点差分、源码存量变化逐项对齐。这里能看到约 <strong>30.2 万行次</strong>的 Python/TS 改动，不能据此计算独立产出、质量或模型生产率。</p>
-<h3>节奏：这段工程怎样持续推进</h3>
-<div class="table-scroll" role="region" tabindex="0" aria-label="可横向滚动的技术对照表"><table>
-<thead>
-<tr>
-<th>北京日期，按周分桶</th>
-<th align="right">核心主干提交</th>
-<th align="right">关联合并 PR</th>
-<th align="right">当周 PR 作者账号</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>08-15—08-21</td>
-<td align="right">52</td>
-<td align="right">48</td>
-<td align="right">10</td>
-</tr>
-<tr>
-<td>08-22—08-28</td>
-<td align="right">87</td>
-<td align="right">86</td>
-<td align="right">14</td>
-</tr>
-<tr>
-<td>08-29—09-04</td>
-<td align="right">61</td>
-<td align="right">61</td>
-<td align="right">16</td>
-</tr>
-<tr>
-<td>09-05—09-11</td>
-<td align="right">92</td>
-<td align="right">92</td>
-<td align="right">14</td>
-</tr>
-<tr>
-<td>09-12—09-18</td>
-<td align="right">133</td>
-<td align="right">133</td>
-<td align="right">14</td>
-</tr>
-<tr>
-<td>09-19—09-25</td>
-<td align="right">150</td>
-<td align="right">147</td>
-<td align="right">10</td>
-</tr>
-<tr>
-<td>09-26—10-02</td>
-<td align="right">161</td>
-<td align="right">161</td>
-<td align="right">17</td>
-</tr>
-<tr>
-<td>10-03—10-09</td>
-<td align="right">216</td>
-<td align="right">214</td>
-<td align="right">12</td>
-</tr>
-<tr>
-<td>10-10—10-16</td>
-<td align="right">192</td>
-<td align="right">179</td>
-<td align="right">14</td>
-</tr>
-</tbody></table></div>
-<figure><div class="figure-scroll" tabindex="0" role="region" aria-label="整个重构期间，触及核心目录的关联合并 PR 按周分布"><a href="../../images/typescript-control-plane-refactor/core-weekly-prs.svg" target="_blank" rel="noopener"><img src="../../images/typescript-control-plane-refactor/core-weekly-prs.svg" alt="整个重构期间，触及核心目录的关联合并 PR 按周分布" width="1100" height="640" loading="lazy"></a></div><figcaption>整个重构期间，触及核心目录的关联合并 PR 按周分布 窄屏可横向滚动；点击查看原图。</figcaption></figure>
-<p>首末周只覆盖统计起止时间以内的部分。周内按合并时间计 PR、按提交时间计主干提交，两种时间可能不同，因此不要把两个数逐行当成一一对应。</p>
-<p>再按标题前缀观察，<code>fix</code> 为 <strong>658</strong>，<code>feat</code> 为 <strong>208</strong>，<code>refactor</code> 为 <strong>137</strong>，<code>perf</code> 为 <strong>28</strong>，其他为验证、文档或未按这些前缀命名的工作。它们是标题分类，不能把其中某一类当作全部迁移工作。</p>
-<figure><div class="figure-scroll" tabindex="0" role="region" aria-label="同一核心目录 PR 集合的标题类别分布"><a href="../../images/typescript-control-plane-refactor/core-work-types.svg" target="_blank" rel="noopener"><img src="../../images/typescript-control-plane-refactor/core-work-types.svg" alt="同一核心目录 PR 集合的标题类别分布" width="1100" height="640" loading="lazy"></a></div><figcaption>同一核心目录 PR 集合的标题类别分布 窄屏可横向滚动；点击查看原图。</figcaption></figure>
-<p>这些数据让我更愿意把后面的机制按阶段讲：规则搬迁之后，还有调用方接入、语义修复、恢复验证和旧路径退役。最后的 #6396 是整个过程中的一个集中切片。</p>
-<h3>统计如何复查</h3>
-<p>公开安全的<a href="../../images/typescript-control-plane-refactor/core-pr-cohort.csv">PR 清单</a>、<a href="../../images/typescript-control-plane-refactor/core-mainline-commits.csv">核心主干提交清单</a>和<a href="../../images/typescript-control-plane-refactor/core-statistics.json">指标 JSON</a>随稿提供。PR 集合来自触及该目录的主干提交与 GitHub 合并元数据的对应关系；同一 PR 只计一次。2 次主干提交没有可核验的合并 PR 对应，仍计入提交和代码变化量。</p>
-<p>取证中先枚举公开 PR，再用 Git 主干反查；直接读取补齐了搜索索引漏掉的 14 个 PR 元数据。源数据与处理脚本保留在本次调研材料中。没有从这份盘点推算 token、模型费用、CI 算力、研发工时或 benchmark 收益。</p>
 <h2 id="section-3">3. Effect Program 先行：先统一“做过什么”</h2>
 <p>第一次有界切换发生在 8 月 21 日的 <a href="https://github.com/loopx-project/loopx/pull/3416">#3416</a>。TS 接下 Effect Program、settlement algebra、Turn journal 的解释，以及持久 checkpoint effect。</p>
 <p>这组边界之所以连在一起，是因为恢复要回答同一个问题：这笔工作有哪些 effect，哪些已经发生，下一个合法动作是什么？</p>
@@ -324,26 +191,7 @@ <h3>检查器也需要能推翻自己的反例</h3>
 <p>这里误报与漏报的代价不同。保守扩大候选值可能多报一个问题；漏掉真实生产值，会让未登记输出通过检查。没有把握的动态形式应留下 unknown。</p>
 <p>检查还要有扫描覆盖下限，不能靠少扫文件过线。后来删除持续膨胀的已提交 inventory，改成按需计算全树清单，也没有取消这个义务。当前支持形式之外仍有缺口，<a href="https://github.com/loopx-project/loopx/issues/4447">跟踪 issue</a> 继续保留。</p>
 <p>这项工作让我很认同一个实践：自动生成和自动检查，可以减少同步错误；它们自己的前提、覆盖和错误方向，也需要被审查。</p>
-<h2 id="model-assisted-semantics">8. 强模型参与的，是这些跨边界的语义问题</h2>
-<p>我们把强能力模型用在设计、实现和评审里，尤其是跨文件、跨 runtime 的假设检查。真正难的部分往往是：几个局部判断都对，组合起来却允许错误的执行顺序。8、9 月的核心 PR 已经反复遇到这类问题；它们不是迁移收尾后的补丁。</p>
-<h3>副作用已经发生，记录还没写下：重试会不会做两遍？</h3>
-<p>假设 provider 已执行成功，进程却在写 checkpoint 前崩溃。只检查 journal，会看到“未完成”；直接重试可能重复执行。相反，把所有不确定都当作成功，又会吞掉尚未发生的工作。这不是一个 try/catch 能解决的问题。</p>
-<p>8 月 22 日的 <a href="https://github.com/loopx-project/loopx/pull/3485">#3485</a> 在执行前持久化 prepared attempt 和稳定的 effect identity。恢复先询问 provider：<strong>确认已提交，就补记原结果；确认不存在，才按同一身份执行；结果未知，就停在待恢复状态。</strong> 对 effect 顺序、receipt 前缀和身份的检查同时保留。这里没有承诺任意外部系统都能 exactly-once：能否确认原结果，仍取决于 provider 的恢复能力。</p>
-<p>它接续了 <a href="https://github.com/loopx-project/loopx/pull/3464">#3464</a> 的 preflight：执行前判断“能不能做”，中断后判断“是否已经做过”。两者共同保护一次完整操作。只把 Python 函数逐个翻译成 TS，保不住这两个时间边界。</p>
-<p>9 月 13 日的 <a href="https://github.com/loopx-project/loopx/pull/4286">#4286</a> 把七类 Todo 操作的回执恢复收敛到一个 owner，并保留了更细的区别。假设两个 Agent 同时修改任务：A 先提交，B 因版本冲突被明确拒绝；随后 B 查回执时断网。<strong>后一次读取失败，不能抹掉前一次明确拒绝。</strong> 若断连发生在提交响应返回前，结果才需要保持未知，并沿原 operation identity 恢复。</p>
-<p>这两条路径最后都可能遇到网络错误，下一步却不同。<a href="https://github.com/loopx-project/loopx/blob/c0b572d2d508bb10c32701057dd71ff4f8eb663c/loopx/control_plane/coordination/command_receipt.ts">共享实现</a>只尝试一次写入，随后读取原回执；<a href="https://github.com/loopx-project/loopx/blob/c0b572d2d508bb10c32701057dd71ff4f8eb663c/tests/control_plane_ts/command_receipt.test.ts">对应回归</a>分别检查明确拒绝、提交结果未知和准确回执恢复。统一错误处理不能丢掉错误发生的阶段，也不能把已知事实降成未知。</p>
-<h3>领取任务和取得执行权，必须是同一件事</h3>
-<p>两个 Agent 同时看到一个未领取任务。如果 claim 已写入、lease 尚未取得，中间状态究竟归谁？如果旧 Agent 曾成功领取，租约过期后又拿着旧 receipt 回来，它还能继续写吗？</p>
-<p>从 <a href="https://github.com/loopx-project/loopx/pull/3529">#3529</a>、<a href="https://github.com/loopx-project/loopx/pull/3669">#3669</a> 的协调基础，到 9 月 6 日的 <a href="https://github.com/loopx-project/loopx/pull/4032">#4032</a>，领取、租约和操作回执被纳入同一次条件提交。<a href="https://github.com/loopx-project/loopx/pull/3798">#3798</a> 的 store 负责原子持久化，领域 owner 判断身份、作用域和合法转换。<strong>回执证明过去那次领取成功；当前租约与 epoch 才决定现在能否执行。</strong> 操作重放要能找回原结果，却不能复活已失效的执行权。不同存储中的 revision 也不能与领域版本或 lease epoch 混用。</p>
-<p>这解释了为什么“幂等”不是把旧成功结果返回就结束。正确恢复既要记住历史，也要服从现在的权威状态。早期 foundation、shadow 和生产路径的资格是分阶段建立的，不能把第一个接口合入日写成所有后端都已投入使用。</p>
-<h3>修正一条证据，为什么会重新触发已经结束的工作？</h3>
-<p>规划更新尤其容易出现看似无害的默认值错误。用户只修正一条证据，没有改监控状态；如果更新逻辑用缺省值重建整个对象，已经满足的 monitor 可能被重新启用。与此同时，调用方显式传入空列表或 <code>false</code>，也不能被当作“没有提供”。</p>
-<p>9 月 10 日的 <a href="https://github.com/loopx-project/loopx/pull/4178">#4178</a> 将规划更新收敛到同一份权威快照和完整 TS transaction：省略保留原意，显式清空按字段与权限解释，证据修正不重新武装已满足的 monitor。它还删掉了 Python 合成 Markdown 再解析回状态的路径。这既是边界收敛，也是行为修复，不能笼统宣称逐字迁移、行为完全不变。</p>
-<p>Song 后续的 <a href="https://github.com/loopx-project/loopx/pull/4433">#4433</a>、<a href="https://github.com/loopx-project/loopx/pull/4494">#4494</a> 把这种检查延伸到词表的定义、实际生产与消费：一个枚举能编译，不代表所有调用方都在表达同一个含义。前文的 <code>skip</code> / <code>quota_skip</code> 和 action / decision 分离，属于同一条语义主线。</p>
-<h3>怎样约束模型给出的“看起来正确”</h3>
-<p>让模型先指出错误假设，再构造会推翻它的执行序列：提交后断连、旧 lease 重放、只更新证据、显式清空。随后检查真实 owner、provider 和调用入口。</p>
-<p>强模型帮助把散在各处的条件连起来；反例、真实存储与拒绝路径约束它的答案。目前没有逐 PR 的模型型号对照，不能据此量化某个模型的独立收益。我们能展示的是这些机制怎样改变，以及为什么需要改变。后来的 <a href="https://github.com/loopx-project/loopx/pull/7145">#7145</a> 运行时路由、<a href="https://github.com/loopx-project/loopx/pull/7269">#7269</a> 原 Turn 收尾是这条主线的延续，不代替前中期的核心工作。</p>
-<h2 id="section-8">9. 调用方和默认值，决定迁移能否到用户手上</h2>
+<h2 id="section-8">8. 调用方和默认值，决定迁移能否到用户手上</h2>
 <p>完整事务还要求调用方准确表达意图。前述 <a href="https://github.com/loopx-project/loopx/pull/4178">#4178</a> 中，空白 note 表示不修改；显式空列表和 <code>false</code> 则是按对应字段解释的输入。不能把它们统一过滤为“没传”，也不能一律解释成“清空”。dry-run 要准确模拟，不能因为选定 provider 不可用就回退别处。随后 <a href="https://github.com/loopx-project/loopx/pull/4279">#4279</a> 也收敛了读取分类与投影交付语义；部分 Python read owner 被有意保留。一个 owner 是否清楚，比为了语言纯度再造一份解释更重要。</p>
 <p>新建默认值是另一个例子。当前 priority 回归保护以下区别：</p>
 <div class="table-scroll" role="region" tabindex="0" aria-label="可横向滚动的技术对照表"><table>
@@ -381,7 +229,7 @@ <h2 id="section-8">9. 调用方和默认值，决定迁移能否到用户手上<
 <p>这些区别由 <a href="https://github.com/loopx-project/loopx/blob/488e4438e0e51eca023ac3f5e690603120851b0c/tests/control_plane_ts/todo_priority.test.ts">File/SQLite 回归</a> 保护。把“新建默认值”放在原回执恢复之后，才能避免升级替历史做决定。</p>
 <p>最后一轮评审还发现：TS 核心的 metadata-only completion repair 可以通过直接测试，普通 Python producer 却会自动带上 completion policy 和 auto-acquire 等默认参数，被核心视为混入了新工作，导致 File/SQLite、dry-run/执行的实际入口都失败。<a href="https://github.com/loopx-project/loopx/pull/6396#pullrequestreview-5516847052">公开反例</a> 记录了这一点。</p>
 <p>这个恢复缺口在基线也存在，不能全部归因给最后的贡献者。修复要走到普通调用方，同时继续拒绝真正的新正文、continuation、所有权或验证修改。直接构造正确 typed request，仅证明内层会处理它。</p>
-<h2 id="section-9">10. 恢复原结果，同时保护当前执行权</h2>
+<h2 id="section-9">9. 恢复原结果，同时保护当前执行权</h2>
 <p>恢复最容易混淆两个时间点：原操作当时合法，现在的执行者是否还能继续改状态。</p>
 <p>设想一次 team-plan 已经提交，响应丢了。升级后，调用者拿原 operation ID 重试，新准入规则却变严了。若先按新操作拒绝，就会把原成功结果挡住。最后的 <a href="https://github.com/loopx-project/loopx/pull/6396#pullrequestreview-5514510958">恢复评审</a> 抓到了这个问题。</p>
 <figure><div class="figure-scroll" tabindex="0" role="region" aria-label="原回执恢复与当前执行权的分离"><a href="../../images/typescript-control-plane-refactor/replay-zh.svg" target="_blank" rel="noopener"><img src="../../images/typescript-control-plane-refactor/replay-zh.svg" alt="原回执恢复与当前执行权的分离" width="1100" height="640" loading="lazy"></a></div><figcaption>原回执恢复与当前执行权的分离 窄屏可横向滚动；点击查看原图。</figcaption></figure>
@@ -389,7 +237,7 @@ <h2 id="section-9">10. 恢复原结果，同时保护当前执行权</h2>
 <p>返回原结果不会续租，不会覆盖后来提交，也不会复活旧 writer。租约转交、epoch 改变和后续状态，都有自己的保护。</p>
 <p>类型也表达这种区别：历史解码仍认识 <code>legacy</code>，当前新执行的 handoff 配置只接受 <code>soft_claim</code> 与 <code>hard_lease</code>。旧记录可读、原操作可恢复、当前执行获准，各自有独立条件。</p>
 <p>内部回执保护的范围也有限。一次外部远端 effect 若没有可核验的幂等身份与回读，不能只凭控制面只结算一次，就宣称远端恰好执行一次。unknown 应在它实际发生的边界上保留。</p>
-<h2 id="section-10">11. CLI 输出约束：压缩前先保护决策语义</h2>
+<h2 id="section-10">10. CLI 输出约束：压缩前先保护决策语义</h2>
 <p>对 Agent 来说，CLI 的文字会参与决策。这项工程约束早于最后的 writer 退役，在迁移中继续作为验证边界。</p>
 <p><a href="https://github.com/loopx-project/loopx/blob/488e4438e0e51eca023ac3f5e690603120851b0c/docs/reference/contracts/interface-budget-contract.md">接口预算合同</a> 关注：</p>
 <ul>
@@ -402,7 +250,7 @@ <h2 id="section-10">11. CLI 输出约束：压缩前先保护决策语义</h2>
 <p>自然语言还需要逐条看：义务、顺序、证据来源、权限限定、适用范围、继续和停止条件。删除一句“仅在原证明成立时”可能比改一个字段更影响行为。</p>
 <p>一个有界实例是去掉 JSON 缩进与分隔空白。在同一历史 fixture 的 36 个 Todo、12 条 run 上，输出从 48,418 降到 39,726 字符，完整 payload 解码保持一致，字符数减少约 18%。它证明展示体积变化；token、费用和 Agent 效果需要另测。</p>
 <p>预算保护的是消费者能用的接口。新增指导确实有用，可以带同条件证据提高预算；为了变绿而删掉决定所需的条件，反而损坏接口。</p>
-<h2 id="section-11">12. 最后退役：保留贡献，核对删除的究竟是什么</h2>
+<h2 id="section-11">11. 最后退役：保留贡献，核对删除的究竟是什么</h2>
 <p>9 月下旬已经删除了未使用的 authority prototype，以及实验性 Todo event overlay、dual-writer 和 backfill；其中有数据的旧来源有显式保留或拒绝处理。这里没有删除所有 event logging，也没有取消新 authority 的原子事件与回执。</p>
 <p>10 月继续隔离普通 Markdown writer，验证模块不在时真实后续写入仍走正确 owner。等 consumer 路由与替代路径接上，才具备集中删除的条件。</p>
 <p><a href="https://github.com/loopx-project/loopx/pull/6396">#6396</a> 由 <strong>Duang777</strong> 主导，<strong>Song</strong> 和维护侧 Agent 接力补恢复、producer 与集成，沿原分支保留贡献历史。这一轮 3 位开发者与 Agent 的接力，是整个两个月工程的收尾阶段。</p>
@@ -442,6 +290,158 @@ <h2 id="section-11">12. 最后退役：保留贡献，核对删除的究竟是
 </tr>
 </tbody></table></div>
 <p>大部分删除也包括旧测试。不能把被删测试行当成业务能力；应继续核对原来保护的 invariant 是否由现有入口和独立反例接住。这里的数字用于说明收尾范围，不能替代整个迁移的结果验证。</p>
+<h2 id="section-2">12. 只统计核心 control plane：研发规模与代码变化</h2>
+<p>为了把整段工程的规模说清楚，这里固定一个可复算的窄范围：<strong><code>loopx/control_plane/**</code></strong>。其他目录的 App、benchmark、文档、测试套件不计入核心代码量。这个目录自身的测试支持工具仍在目录口径内。</p>
+<p>基线是正式 TS RFC 合入前的 <code>d1fe059</code>，终点是 10 月 16 日的 <code>488e443</code>。从正式 RFC 到终点约 <strong>62 天</strong>，跨 63 个日历日期；其中 62 个日期有核心目录的主干提交。<a href="https://github.com/loopx-project/loopx/compare/d1fe05932ac28690d393a38c78b4738ac12c78c0...488e4438e0e51eca023ac3f5e690603120851b0c">起止源码对照</a>可以复查版本。</p>
+<h3>整个周期的研发活动</h3>
+<div class="table-scroll" role="region" tabindex="0" aria-label="可横向滚动的技术对照表"><table>
+<thead>
+<tr>
+<th>指标</th>
+<th align="right">核心目录口径</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>触及核心目录的主干落地提交，按第一父链去重</td>
+<td align="right"><strong>1,144</strong></td>
+</tr>
+<tr>
+<td>可核验关联的已合并 PR，按 PR 编号去重</td>
+<td align="right"><strong>1,121</strong></td>
+</tr>
+<tr>
+<td>这些 PR 的作者账号</td>
+<td align="right"><strong>56</strong></td>
+</tr>
+<tr>
+<td>本次 API 快照中的 review 记录</td>
+<td align="right"><strong>2,329</strong></td>
+</tr>
+<tr>
+<td>本次 API 快照中的会话评论，不含行内 review comments</td>
+<td align="right"><strong>1,631</strong></td>
+</tr>
+<tr>
+<td>有 review 记录的关联 PR</td>
+<td align="right"><strong>1,031 / 1,121</strong></td>
+</tr>
+<tr>
+<td>PR 创建至合并的中位历时</td>
+<td align="right"><strong>5.0 小时</strong></td>
+</tr>
+<tr>
+<td>PR 创建至合并的 P90 / P95 历时</td>
+<td align="right"><strong>25.4 / 45.0 小时</strong></td>
+</tr>
+</tbody></table></div>
+<p>这组范围包含同期的迁移、新能力、修复与维护。56 是 GitHub 账号数，其中有自动化与共享账号；它不等于 56 个人或 56 个 Agent。review 数也包含自审、重复审查等记录，部分讨论发生在合并后。合并历时包含等待，不能换算成有效研发工时。</p>
+<p>新 maintainer Song 在这个窄目录口径下关联 <strong>53 个 PR</strong>。他在 <code>loopx/semantics/</code> 等目录的贡献没有全部进入这个数，具体技术归属仍以本文的贡献说明和原 PR 为准。</p>
+<h3>代码结构与累计变化量</h3>
+<p>下表按物理行统计，包含注释和空行；列出的文件量只计相应语言源码。</p>
+<div class="table-scroll" role="region" tabindex="0" aria-label="可横向滚动的技术对照表"><table>
+<thead>
+<tr>
+<th>核心目录源码</th>
+<th align="right">基线</th>
+<th align="right">取证终点</th>
+<th align="right">期间累计新增 / 删除</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>Python</td>
+<td align="right">256 个文件；80,473 行</td>
+<td align="right">471 个文件；142,371 行</td>
+<td align="right">+120,899 / −59,001 行</td>
+</tr>
+<tr>
+<td>TypeScript</td>
+<td align="right">0 个文件；0 行</td>
+<td align="right">323 个文件；87,268 行</td>
+<td align="right">+104,769 / −17,501 行</td>
+</tr>
+<tr>
+<td>Python + TypeScript</td>
+<td align="right">80,473 行</td>
+<td align="right">229,639 行</td>
+<td align="right"><strong>+225,668 / −76,502 行</strong></td>
+</tr>
+</tbody></table></div>
+<p>TS 占终点这两种语言源码物理行数的 <strong>38.0%</strong>。这是目录里的语言结构，不能当作“38% 的控制面已完成迁移”：一部分旧入口本来就在目录外，迁移中也有模块归位、新能力与测试支持代码进入。</p>
+<figure><div class="figure-scroll" tabindex="0" role="region" aria-label="核心 control plane 的 Python 与 TypeScript 源码存量变化"><a href="../../images/typescript-control-plane-refactor/core-source-stock.svg" target="_blank" rel="noopener"><img src="../../images/typescript-control-plane-refactor/core-source-stock.svg" alt="核心 control plane 的 Python 与 TypeScript 源码存量变化" width="1100" height="640" loading="lazy"></a></div><figcaption>核心 control plane 的 Python 与 TypeScript 源码存量变化 窄屏可横向滚动；点击查看原图。</figcaption></figure>
+<p>累计新增和删除按主干每次落地差分相加，同一行反复修改会重复计数；两端存量只看各自快照。本次将累计净变化与端点差分、源码存量变化逐项对齐。这里能看到约 <strong>30.2 万行次</strong>的 Python/TS 改动，不能据此计算独立产出、质量或模型生产率。</p>
+<h3>节奏：这段工程怎样持续推进</h3>
+<div class="table-scroll" role="region" tabindex="0" aria-label="可横向滚动的技术对照表"><table>
+<thead>
+<tr>
+<th>北京日期，按周分桶</th>
+<th align="right">核心主干提交</th>
+<th align="right">关联合并 PR</th>
+<th align="right">当周 PR 作者账号</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>08-15—08-21</td>
+<td align="right">52</td>
+<td align="right">48</td>
+<td align="right">10</td>
+</tr>
+<tr>
+<td>08-22—08-28</td>
+<td align="right">87</td>
+<td align="right">86</td>
+<td align="right">14</td>
+</tr>
+<tr>
+<td>08-29—09-04</td>
+<td align="right">61</td>
+<td align="right">61</td>
+<td align="right">16</td>
+</tr>
+<tr>
+<td>09-05—09-11</td>
+<td align="right">92</td>
+<td align="right">92</td>
+<td align="right">14</td>
+</tr>
+<tr>
+<td>09-12—09-18</td>
+<td align="right">133</td>
+<td align="right">133</td>
+<td align="right">14</td>
+</tr>
+<tr>
+<td>09-19—09-25</td>
+<td align="right">150</td>
+<td align="right">147</td>
+<td align="right">10</td>
+</tr>
+<tr>
+<td>09-26—10-02</td>
+<td align="right">161</td>
+<td align="right">161</td>
+<td align="right">17</td>
+</tr>
+<tr>
+<td>10-03—10-09</td>
+<td align="right">216</td>
+<td align="right">214</td>
+<td align="right">12</td>
+</tr>
+<tr>
+<td>10-10—10-16</td>
+<td align="right">192</td>
+<td align="right">179</td>
+<td align="right">14</td>
+</tr>
+</tbody></table></div>
+<figure><div class="figure-scroll" tabindex="0" role="region" aria-label="整个重构期间，触及核心目录的关联合并 PR 按周分布"><a href="../../images/typescript-control-plane-refactor/core-weekly-prs.svg" target="_blank" rel="noopener"><img src="../../images/typescript-control-plane-refactor/core-weekly-prs.svg" alt="整个重构期间，触及核心目录的关联合并 PR 按周分布" width="1100" height="640" loading="lazy"></a></div><figcaption>整个重构期间，触及核心目录的关联合并 PR 按周分布 窄屏可横向滚动；点击查看原图。</figcaption></figure>
+<p>首末周只覆盖统计起止时间以内的部分。周内按合并时间计 PR、按提交时间计主干提交，两种时间可能不同，因此不要把两个数逐行当成一一对应。</p>
+<p>再按标题前缀观察，<code>fix</code> 为 <strong>658</strong>，<code>feat</code> 为 <strong>208</strong>，<code>refactor</code> 为 <strong>137</strong>，<code>perf</code> 为 <strong>28</strong>，其他为验证、文档或未按这些前缀命名的工作。它们是标题分类，不能把其中某一类当作全部迁移工作。</p>
+<figure><div class="figure-scroll" tabindex="0" role="region" aria-label="同一核心目录 PR 集合的标题类别分布"><a href="../../images/typescript-control-plane-refactor/core-work-types.svg" target="_blank" rel="noopener"><img src="../../images/typescript-control-plane-refactor/core-work-types.svg" alt="同一核心目录 PR 集合的标题类别分布" width="1100" height="640" loading="lazy"></a></div><figcaption>同一核心目录 PR 集合的标题类别分布 窄屏可横向滚动；点击查看原图。</figcaption></figure>
+<p>这些数据让我更愿意把后面的机制按阶段讲：规则搬迁之后，还有调用方接入、语义修复、恢复验证和旧路径退役。最后的 #6396 是整个过程中的一个集中切片。</p>
+<h3>统计如何复查</h3>
+<p>公开安全的<a href="../../images/typescript-control-plane-refactor/core-pr-cohort.csv">PR 清单</a>、<a href="../../images/typescript-control-plane-refactor/core-mainline-commits.csv">核心主干提交清单</a>和<a href="../../images/typescript-control-plane-refactor/core-statistics.json">指标 JSON</a>随稿提供。PR 集合来自触及该目录的主干提交与 GitHub 合并元数据的对应关系；同一 PR 只计一次。2 次主干提交没有可核验的合并 PR 对应，仍计入提交和代码变化量。</p>
+<p>取证中先枚举公开 PR，再用 Git 主干反查；直接读取补齐了搜索索引漏掉的 14 个 PR 元数据。源数据与处理脚本保留在本次调研材料中。没有从这份盘点推算 token、模型费用、CI 算力、研发工时或 benchmark 收益。</p>
 <h2 id="section-12">13. 社区贡献与下一步</h2>
 <p>这项工程有多位贡献者逐步推进。下面按具体边界列出代表工作，便于继续读历史。</p>
 <div class="table-scroll" role="region" tabindex="0" aria-label="可横向滚动的技术对照表"><table>
@@ -489,6 +489,6 @@ <h2 id="section-12">13. 社区贡献与下一步</h2>
 <p>2.0 也没有把所有 RFC 目标画上句号。保留的 Python transport 与专业 provider 有明确用途，更广的 native CLI、持续运行资格继续按各自路径验证。工程闭环更清楚以后，我们还要在 EdgeBench、LHTB 这类通用长程 benchmark 上做能力与效率对照，尤其是 single session。</p>
 <p>我希望这次重构留下的，是下一轮修改更容易定位、验证和回滚的系统，以及遇到反例时愿意继续修正的工作方式。</p>
 
-</article></div></main>
+<nav class="article-route" aria-label="继续阅读"><p>控制规则怎样到达下一次决定？读<a href="../context-delivery/">上下文的渐进与差分交付</a>。这些机制是否改善了研究？读<a href="../edgebench-feedback-and-memory/">EdgeBench 的结果与反证</a>。</p></nav></article></div></main>
 <footer class="site-footer"><a class="brand" href="../../../">LoopX</a><p>让工作持续推进，让判断由人掌握。</p><a href="#main" aria-label="返回开头">↑</a></footer>
 </body></html>