From c0a0a913439732229a2bb811d23cc790c2dd0408 Mon Sep 17 00:00:00 2001
From: veil-chow-fyaic <247294299+veil-chow-fyaic@users.noreply.github.com>
Date: Tue, 8 Sep 2026 14:57:14 +0800
Subject: [PATCH 1/3] feat: clarify native task readiness and read-only status
---
.../skills/threadmesh-codex/SKILL.md | 35 +++++++++++++++++--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/plugins/threadmesh-codex/skills/threadmesh-codex/SKILL.md b/plugins/threadmesh-codex/skills/threadmesh-codex/SKILL.md
index 8290ae2..4cd42c6 100644
--- a/plugins/threadmesh-codex/skills/threadmesh-codex/SKILL.md
+++ b/plugins/threadmesh-codex/skills/threadmesh-codex/SKILL.md
@@ -93,8 +93,9 @@ archived, unavailable or unclear, retain a pending suggestion here; do not send,
steer, interrupt or start a monitoring loop. Resume assessment on a later normal
checkpoint. Do not install an automation without a separate user request.
-If the target is observed idle and the current authorization permits automatic
-advice, send once using the native send tool and the observed target reference.
+Only after the selected peer's setup is confirmed (see visible status below),
+the target is freshly observed idle and the current authorization permits
+automatic advice, send once using the native send tool and observed reference.
Omit model/thinking overrides. The host supplies the source attribution. Keep
the message human-readable and narrow:
@@ -122,6 +123,33 @@ send acceptance is not proof of a correct edit. Where appropriate, inspect the
receiver's scoped result and its actual artifact/test before reporting success;
don't call a re-created thread the original receiver.
+## Visible status in the original task
+
+Keep setup, delivery and outcome understandable in this conversation, not in a
+separate webpage. After setup say **this task is ready** (with peer title, scope
+and send mode), not **both tasks are connected**. Report the peer's setup as
+unknown unless its confirmation has actually been observed. An idle task is
+not necessarily configured. Before the first automatic advice, if confirmation
+is missing, use one bounded selected-peer read when authorized to check its
+agreement; if still unclear, keep the advice pending and say what is missing.
+A peer's reported agreement does not expand this task's user authorization.
+
+On a meaningful handoff or blocker, give a short outcome in the user's language:
+**not sent** and why; **sent, result unverified**; **receiver reports done**; or
+**verified** with the checked artifact/test. A send acknowledgement alone never
+advances to done. Pending here means retained in this conversation for a later
+normal checkpoint, not a durable ThreadMesh queue or scheduled retry. Avoid
+repeated status chatter when nothing relevant changes.
+
+When asked to **check ThreadMesh status**, report the current local agreement,
+selected peer, last advice/outcome and evidence freshness. This is read-only:
+do not enable, resume, resend, edit files or send a status request to the peer.
+Use at most one scoped native status snapshot and, only if needed and permitted,
+one bounded selected-peer read. Missing/empty observations mean unknown; don't
+infer setup, completion or available quota. Do not start a polling loop.
+
+## Stop this task's collaboration
+
On user stop/mute, stop initiating sends from this conversation immediately,
mark existing pending suggestions cancelled and retain no new pending sends.
Re-enabling does not automatically dispatch cancelled suggestions. Do not send
@@ -129,3 +157,6 @@ a final stop broadcast without explicit
authorization. A skill cannot recall submitted messages or atomically revoke a
peer's separate permission: explain that limitation, and ask the user to stop
the other task too if needed. Never claim global revocation or race-free queues.
+Confirm **this task stopped; pending advice cancelled**. Report the other side
+as unknown unless its stop is observed. A later status check keeps this stop in
+effect and must not reconstruct or reactivate cancelled advice.
From f104b0d3a75ba6338b91c59cfe96b2f13cea478e Mon Sep 17 00:00:00 2001
From: veil-chow-fyaic <247294299+veil-chow-fyaic@users.noreply.github.com>
Date: Tue, 8 Sep 2026 15:02:09 +0800
Subject: [PATCH 2/3] docs: restore local-first entry and ordered product
acceptance
---
README.md | 23 ++++++----
README.zh-CN.md | 15 ++++---
ROADMAP.md | 40 +++++++++++------
docs/06-guides/codex-native-tasks.md | 42 ++++++++++++++----
.../2026-09-08-pairing-helper-acceptance.md | 43 +++++++++++++++++++
docs/10-planning/desktop-entry-2026-09-07.md | 15 +++++--
docs/10-planning/project-status.md | 15 +++++++
docs/zh-CN/codex-native-tasks.md | 35 ++++++++++++---
web/connect/app.mjs | 16 +++----
web/connect/index.html | 10 ++---
web/connect/pairing.mjs | 2 +-
11 files changed, 196 insertions(+), 60 deletions(-)
diff --git a/README.md b/README.md
index 49aad54..e094e92 100644
--- a/README.md
+++ b/README.md
@@ -83,14 +83,21 @@ not a screenshot. Simultaneous typing races and plugin hot-loading remain unveri
### Want to connect your existing desktop tasks?
-[**Open the pairing helper →**](https://fyaic.github.io/threadmesh/)
-
-Paste two copied **chat links**, choose what they may share, and copy the setup
-prepared for each task. No terminal, installation, account or hand-editing long
-prompts. Inputs stay in the browser page; the helper does not read chats or send
-messages. In Codex, **Copy chat deep link** is **⌘⌥L** on macOS or **Ctrl+Alt+L**
-on Windows. Paste and send each setup yourself; wait for both confirmations,
-then work normally. [Manual entry and limits](docs/06-guides/codex-native-tasks.md).
+[**Start in your existing Codex tasks →**](docs/06-guides/codex-native-tasks.md)
+
+Set the selected peer and shared topic in each original task, wait for both
+setup confirmations, then give one task your ordinary business request. The
+effect to look for is **the other original task acting correctly**, not a
+generated prompt or a sent badge. Ask **“Check ThreadMesh status”** in the task
+to distinguish setup, pending advice and observed results; stop in both tasks
+to stop both directions. These are natural-language requests, not slash commands
+or a separate control service.
+
+No browser is required for collaboration. The optional
+[setup-text helper](https://fyaic.github.io/threadmesh/) saves manual template
+editing only: it does not run agents, connect tasks, show live status or stop
+them. You still paste/send both setups in Codex. It is neither a demo nor a
+hosted version of ThreadMesh.
Another real case: A changed an API contract; original B updated its own client
and tests, retaining the earlier timeout and cursor-encoding decisions.
diff --git a/README.zh-CN.md b/README.zh-CN.md
index 9e8a51d..6d79d15 100644
--- a/README.zh-CN.md
+++ b/README.zh-CN.md
@@ -77,13 +77,16 @@ B 早已知道按钮名称不能改。明确配对后,只向 A 提出普通业
### 想连接已有的桌面任务?
-[**打开免安装配对页面 →**](https://fyaic.github.io/threadmesh/)
+[**直接在已有 Codex 任务中开始 →**](docs/zh-CN/codex-native-tasks.md)
-粘贴两个**聊天链接**,选择允许交流的话题,分别复制为它们生成的设置提示。
-不用终端、安装、注册账号或手工修改长提示词。输入留在浏览器页面中,页面不读聊天、
-不代发消息。Codex 的“复制聊天深链”快捷键是 macOS **⌘⌥L**、Windows **Ctrl+Alt+L**。
-你仍需在两个原任务分别粘贴发送;等双方确认后正常工作。
-[手动入口与限制](docs/zh-CN/codex-native-tasks.md)。
+在两个原任务中分别设置协作对象和允许话题,等双方确认后,只向其中一个提出普通
+业务需求。真正要看的效果是**另一个原任务自己做对了事情**,不是生成提示词或显示
+已发送。在任务里说“检查 ThreadMesh 状态”,区分本端设置、待发建议和已观察到的结果;
+要停止双向协作,在两个任务中分别说停止。这些是自然语言请求,不是斜杠命令或独立控制服务。
+
+协作不需要浏览器。可选的[设置提示词辅助工具](https://fyaic.github.io/threadmesh/)
+只省去手工改模板:它不运行 Agent、不连接任务、不显示实时状态,也不能停止它们。
+你仍需在 Codex 中分别粘贴发送。它不是功能演示,也不是 ThreadMesh 云端版本。
另一个真实案例:A 修改 API 约定后,原 B 自己更新客户端和测试,同时保留此前的
超时、特殊游标编码约定。[页面检查与实际 API 协作记录 →](docs/09-reviews/2026-09-08-pairing-helper-acceptance.md)
diff --git a/ROADMAP.md b/ROADMAP.md
index caf9e9e..c77c79b 100644
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -13,6 +13,27 @@ policy layer; A2A, Cotal, ACP, or harness-native APIs may supply transport.
## Active priority — existing desktop clients (2026-09-08)
+**Current order, confirmed by the user:** independent first use → visible local
+status and stop → demonstrated relay savings → a real user case → DeepSeek and
+quota handoff. Work happens in original local agent conversations. The website
+is an optional setup-text utility, not the product runtime, control plane or
+demonstration. Do not expand it into a dashboard to substitute for native value.
+
+| Order | User outcome | Remaining acceptance |
+|---|---|---|
+| 1 | An ordinary Codex desktop user gets a useful result without maintainer help | One independent user's original pair, using the public guide; record actual setup steps, first blocker and B's own correct result. Maintainer and subagent runs do not count. |
+| 2 | Know what happened and stop safely | In-task readiness/pending/result/stop explanations; never confuse idle with configured or sent with done. Guidance is being improved; persistent receipt/control and simultaneous-input safety remain open (#135/#136). |
+| 3 | Less relaying than native-only use | A small matched case counts setup actions, manual relays, correct edits and unwanted contact. No new benchmark framework; keep optional guidance small if it adds no benefit. |
+| 4 | Others can understand and reproduce the value | A consented real native recording and independent case, followed by relevant community sharing. No recreated conversation or promised star count. |
+| 5 | Extend a proven useful workflow | Provider-configured DeepSeek initiative, then continuation from an actual quota-blocked task's already saved checkpoint. Neither has a completed live acceptance. |
+
+Orders 1 and 2 form the immediate product work: fix observed local usability
+while seeking an independent participant, without pretending an internal test
+is that participant. The old #91/#93 multi-role loop and #7 formal review remain
+separate open tracks, not new prerequisites for this desktop-first alpha.
+
+### Completed evidence — do not repeat as a new gate
+
**Setup simplification shipped:** the bilingual [no-install pairing helper](https://fyaic.github.io/threadmesh/)
generates separate setups from two chat links and a chosen topic. Users still
paste/send and wait for both confirmations; it is not an automatic connection.
@@ -32,13 +53,6 @@ and continuation. The skill is optional guidance, not new transport. Read the
The [retained desktop evidence](docs/evidence/codex-native-2026-09-07/README.md)
shows feasibility, not improvement over native Codex alone.
-The next product slice must reduce a real user's setup/relay burden: simple
-explicit pair selection, retained decisions, and clear pending/applied outcomes.
-Then compare a small matched native-only workflow with the added guidance;
-record setup actions, manual relays, correct receiver edits and unwanted contact.
-Do not build a benchmark platform or add harnesses for this comparison. If no
-gain is observed, retain a lightweight optional recipe rather than a new platform.
-
For community growth, first make one independent Codex user's own pair succeed;
fix their first blocker, then prepare a consented real recording and a concise
case study. A [consolidated evidence-backed reply](https://github.com/fyaic/threadmesh/issues/158#issuecomment-5570614068)
@@ -56,7 +70,7 @@ now passes with the default command in 272.604 seconds; [alpha.3 is published](h
and its public install was checked. Earlier timeout and outdated-runtime failures remain recorded. This
is new-session CLI acceptance, not the primary existing-desktop gate.
-Next native slice: the [skill-only workflow](docs/06-guides/codex-native-tasks.md)
+Completed native slice: the [skill-only workflow](docs/06-guides/codex-native-tasks.md)
uses task tools already exposed by Codex, with an explicitly selected pair.
It needs no Node/MCP/hook setup. [One controlled opted-in desktop pair passed](docs/09-reviews/2026-09-07-native-desktop-acceptance.md),
including prior context, B's own edit and busy/stop checks. The subsequent
@@ -90,8 +104,9 @@ to existing-session desktop entry instead of further prompt tuning.
- [ ] Verify plugin loading, native identity and adoption of a prior conversation.
[Native attempt](docs/09-reviews/2026-09-07-desktop-native-adoption.md): installation
succeeded, but neither prior conversation exposed the diagnostic; keep open.
-- [ ] Connect two existing conversations in one client, explicitly selected,
- without shared-path or JSON setup; one conversation per product is not this test.
+- [x] Controlled native-skill pair: two original same-client tasks with explicit
+ links and scope, without a shared path or JSON setup. Independent user setup
+ and the separate external-plugin adapter are not covered by this pass.
- [x] Prove one controlled model-selected native advice and same-receiver edit;
source attribution verified in turn data, not a rendered UI recording.
- [ ] Verify full business constraints, unrelated silence and user-input priority.
@@ -102,7 +117,7 @@ The controlled skill route does not close those gates. Do not substitute a new C
unscoped remote control or a promotional UI for existing-conversation acceptance.
Existing quality, quota and DeepSeek live gaps remain open.
-### Immediate delivery checkpoint — community feedback
+### Earlier delivery checkpoint — community feedback
The independent [first-use report #158](https://github.com/fyaic/threadmesh/issues/158)
was submitted on September 5 and acknowledged on September 7. It found a
@@ -110,7 +125,8 @@ roughly five-minute, mostly quiet install and a Codex quota block before a model
turn. Its public-API harness check is real external evidence, not a live agent
collaboration pass. One report is not a community popularity ranking.
-The next delivery must address this first failed user journey:
+The following delivered work addressed that first failed user journey; the
+current ordered acceptance above supersedes its implementation sequence:
Implementation checkpoint: the packaged `try --live` entry, bounded failure
handling and bilingual guides are implemented. Real copy and installed-package
diff --git a/docs/06-guides/codex-native-tasks.md b/docs/06-guides/codex-native-tasks.md
index 9ff5de5..71d40a0 100644
--- a/docs/06-guides/codex-native-tasks.md
+++ b/docs/06-guides/codex-native-tasks.md
@@ -9,12 +9,12 @@ a new model, an MCP server or a polling daemon.
## No-terminal workflow
-Prefer the [browser pairing helper](https://fyaic.github.io/threadmesh/) if you
-do not want to edit the template below. Paste two local chat links, choose a
-shared topic and advice mode, confirm, then copy each prepared setup and open
-its original task. Inputs are not uploaded or saved by the page. It generates
-text, not a connection: you still paste/send in both tasks and wait for their
-confirmations. [Browser and generated-prompt acceptance](../09-reviews/2026-09-08-pairing-helper-acceptance.md).
+**Work in the original Codex tasks. No website needs to stay open.** The setup
+below is an instruction to each task, not registration with a hosted service.
+If editing the template is inconvenient, the optional
+[setup-text helper](https://fyaic.github.io/threadmesh/) prepares the two strings
+locally in your browser. It cannot observe or control collaboration and is not
+a live demo. [What the helper was actually tested for](../09-reviews/2026-09-08-pairing-helper-acceptance.md).
Choose two disposable existing Codex tasks with useful prior context. For
example, a brand task maintains approved product facts; a website task already
@@ -38,7 +38,7 @@ repository or open a terminal.
```text
Use the ThreadMesh workflow at this pinned public URL. Read the complete file:
-https://raw.githubusercontent.com/fyaic/threadmesh/93da0c6fc9814c1a28e95eaf34d287e11a4331f7/plugins/threadmesh-codex/skills/threadmesh-codex/SKILL.md
+https://raw.githubusercontent.com/fyaic/threadmesh/c0a0a913439732229a2bb811d23cc790c2dd0408/plugins/threadmesh-codex/skills/threadmesh-codex/SKILL.md
Pair only this task with OTHER TASK LINK. Each keeps its own current job and
earlier decisions. Allowed shared topic: SHARED TOPIC.
@@ -46,12 +46,13 @@ Use the supplied local chat link to identify the peer and verify only that
task with native read/status tools. Do not list all tasks or read unrelated
conversations. If the link or target cannot be verified, leave collaboration off.
-I authorize automatic, relevant peer advice after setup. I understand an idle
+I authorize automatic, relevant peer advice after both tasks complete setup. I understand an idle
check cannot guarantee that sending never races with new user input.
This setup turn must not send any peer messages or change any business files.
Do not install software, change permissions or create tasks.
Confirm the selected peer by title, allowed topic, available native tools and
-whether this task is enabled. If anything is unavailable, leave collaboration off.
+whether this task is ready. Do not claim both are connected from this setup alone.
+If anything is unavailable, leave collaboration off.
```
Want to check first without enabling? Replace the automatic-advice
@@ -91,6 +92,29 @@ result is an attributed native message, followed by that **same** website task
updating its own copy while keeping its earlier button decision and price.
Read the receiver's actual result; a delivery notification alone is insufficient.
+### 3. Check the result and stop, in the same conversations
+
+Ask **“Check ThreadMesh status”** when unclear. This read-only request must not
+enable collaboration or resend anything. Expect a concise account of the local
+scope/mode, selected peer, last observed result and what remains unknown:
+
+| Task says | What it establishes |
+|---|---|
+| This task is ready | Only this end completed setup; the peer's agreement still needs confirmation |
+| Not sent: receiver busy / setup unknown | Advice stays in this conversation; no automatic retry or durable queue is implied |
+| Sent, result unverified | A message was submitted, not proof of a useful edit |
+| Receiver reports done | A completion report exists; check the artifact before treating it as verified |
+| Verified + artifact/test | The stated business result was actually checked |
+| This task stopped | Local pending advice is cancelled; it does not prove the other side stopped |
+
+These are plain-language reports from the agent, not a persistent status service
+or guaranteed host-enforced state machine. Empty reads remain unknown. Say
+**“Stop ThreadMesh collaboration”** in both tasks to stop both directions;
+checking status afterward must not resume cancelled advice. Previously submitted
+messages cannot be recalled by this skill.
+These reporting rules passed internal review; the latest native status attempt
+did not produce a verifiable result. [Validation boundary](../09-reviews/2026-09-08-pairing-helper-acceptance.md#later-correction-local-tasks-first-not-a-website-demo).
+
### Optional: use a task name instead
An already attached native task reference also works. If you prefer an exact
diff --git a/docs/09-reviews/2026-09-08-pairing-helper-acceptance.md b/docs/09-reviews/2026-09-08-pairing-helper-acceptance.md
index 55bda03..b215946 100644
--- a/docs/09-reviews/2026-09-08-pairing-helper-acceptance.md
+++ b/docs/09-reviews/2026-09-08-pairing-helper-acceptance.md
@@ -103,3 +103,46 @@ recovery, or an incremental advantage over native-only Codex. An idle check
does not make the following send atomic. Review-only mode drafts advice; it is
not permission to send. Agent guidance is not a hard host-enforced security
boundary. Neither this case nor the helper repacks the alpha.3 CLI release.
+
+## Later correction: local tasks first, not a website demo
+
+Following user feedback on September 8, the helper was demoted to an optional
+setup-text utility. The bilingual README/guide now start in the original Codex
+tasks. The webpage explicitly states that it neither runs agents nor shows live
+progress and that closing the page does not stop collaboration. Its revised
+Chinese heading and boundary text were inspected in actual Chrome. This is a
+positioning correction, not a new integration or native demonstration.
+
+The skill at `c0a0a913439732229a2bb811d23cc790c2dd0408` adds concise in-task
+status guidance: local readiness is not peer readiness, idle is not configured,
+sent is not done, unknown observations stay unknown, and read-only status must
+not reactivate a stop. Both guide templates and the optional generator pin this
+revision. Earlier successful cases above used the earlier pinned workflow;
+their outcomes are not retroactive live validation of this revision.
+
+An independent internal subagent performed a read-only behavioral review of
+three cases: idle peer with unknown setup, accepted send with empty result, and
+status after stop. It passed; the suggested explicit peer-confirmation condition
+was incorporated into the send rule. This was a tabletop review, not a real
+agent exchange or an independent user's onboarding. Skill validation, all 14
+helper regression tests, the full 474-pass/one-skip suite and documentation lint
+passed. The system Python lacked PyYAML; the validator passed in an isolated
+`uv --with pyyaml` environment without changing project dependencies.
+
+One read-only status request was also dispatched to the original, previously
+stopped receiver using the new public workflow. **No live status pass is
+claimed.** The desktop wait surface reported an active turn with no readable
+result, while the official read-only App Server capture marked that selected
+turn interrupted and retained only the incoming request. Neither proves a
+completed check. There were no outgoing sends or file changes in the captured
+items, and the four checked receiver files retained their pre-request hashes.
+This is a bounded negative observation, not proof that no later activity can
+occur. No retry or additional business request was dispatched. Its selected-turn
+capture is retained privately with SHA-256
+`b87454bfb173bb6c113c5d534efb7aad1bbcb9e8935ee028aeea54fefa901ead`.
+
+Independent GUI first use, persistent desktop control, simultaneous-input
+safety and measured native-only advantage remain open. The reordered
+[roadmap](../../ROADMAP.md#active-priority--existing-desktop-clients-2026-09-08)
+is the active acceptance plan; old completed pairing gates must not be restarted
+as substitutes for these outcomes.
diff --git a/docs/10-planning/desktop-entry-2026-09-07.md b/docs/10-planning/desktop-entry-2026-09-07.md
index 973cd0a..c2abc62 100644
--- a/docs/10-planning/desktop-entry-2026-09-07.md
+++ b/docs/10-planning/desktop-entry-2026-09-07.md
@@ -4,6 +4,13 @@ Date: 2026-09-07. Starting revision: `19a9b13`.
## Decision and desired experience
+**September 8 current decision:** follow the [ordered product acceptance](../../ROADMAP.md#active-priority--existing-desktop-clients-2026-09-08).
+The controlled public-source original-pair gate below is **complete**, including
+the [API/client case](../09-reviews/2026-09-08-pairing-helper-acceptance.md).
+Remaining immediate work is independent first use and understandable status/
+stop in original Codex tasks. The website is optional template assistance,
+not a local agent demonstration or a control service. No new website platform.
+
Audience correction: Codex is the primary client. Do not split the critical path
equally across Codex and ZCode, or require Codex users to install Pi. A Codex-only
sample can remove that immediate first-use barrier but does not close the existing
@@ -22,10 +29,10 @@ The [controlled native run](../09-reviews/2026-09-07-native-desktop-acceptance.m
now passes: two authorized disposable desktop tasks completed prior work, then
adopted the skill. A chose advice; original B edited correctly; busy/stop checks
passed. Setup used manager-supplied native references and a local skill path.
-The current delivery gate is public workflow retrieval, supported task selection,
+The now-completed controlled delivery gate was public workflow retrieval, supported task selection,
explicit activation, an ordinary request, original receiver-owned useful work
-and a final stop in the same run. Independent desktop-user onboarding follows;
-it is not a reason to stop before completing this maintainer-run gate. Plugin
+and a final stop in the same run. Independent desktop-user onboarding remains;
+do not repeat the completed maintainer gate as a substitute. Plugin
hot-loading and the external adapter sequence below remain separate open work,
not prerequisites for this native workflow.
@@ -106,7 +113,7 @@ tokens, private IPC or desktop database writes as a ThreadMesh adapter.
## Ordered implementation and acceptance
-### Current native skill delivery gate
+### Completed controlled native skill gate — retained criteria
1. Retrieve the pinned public workflow and resolve only the selected existing
peer through a supported app-provided reference, such as a copied chat deep
diff --git a/docs/10-planning/project-status.md b/docs/10-planning/project-status.md
index 087780c..6161a83 100644
--- a/docs/10-planning/project-status.md
+++ b/docs/10-planning/project-status.md
@@ -2,6 +2,21 @@
## Current product update — 2026-09-08
+**Local native work is the product entry; the website is optional template
+assistance.** Follow the [new ordered acceptance](../../ROADMAP.md#active-priority--existing-desktop-clients-2026-09-08):
+independent first use → visible local status/stop → measured relay savings →
+real user case → DeepSeek and quota continuation. No independent GUI success,
+persistent desktop control service or native-only advantage is claimed.
+The native skill now explicitly distinguishes local readiness, peer confirmation,
+pending advice, sent/unverified, receiver-reported completion and checked result.
+Status requests do not reactivate stopped collaboration. These are agent
+instructions, not a new host-enforced state machine.
+Read-only internal behavior review and regressions passed; the new original-task
+status attempt produced inconsistent host observations and no readable result,
+so it is **not** a native status pass. [Result and limits](../09-reviews/2026-09-08-pairing-helper-acceptance.md#later-correction-local-tasks-first-not-a-website-demo).
+
+### Last completed evidence
+
**The no-install pairing helper is now public:** [open it](https://fyaic.github.io/threadmesh/),
paste two chat links and choose a topic; copy the separately generated setups.
Chinese/English, browser interaction and clipboard-failure handling were tested.
diff --git a/docs/zh-CN/codex-native-tasks.md b/docs/zh-CN/codex-native-tasks.md
index 50096c9..fcbcbb4 100644
--- a/docs/zh-CN/codex-native-tasks.md
+++ b/docs/zh-CN/codex-native-tasks.md
@@ -7,10 +7,10 @@
## 免终端工作流
-不想手工改下面的长提示词,可以直接打开[配对页面](https://fyaic.github.io/threadmesh/):
-填两个本地聊天链接,选择话题和建议方式,勾选确认,然后分别复制设置、打开原任务。
-页面不上传或保存输入,只生成文字,不建立连接;你仍需在两个任务中分别粘贴发送,
-等待它们确认。[页面与生成提示的验证记录](../09-reviews/2026-09-08-pairing-helper-acceptance.md)。
+**直接在原来的 Codex 任务中工作,不需要保持任何网页打开。** 下面的设置是发给
+各任务的指令,不是在云服务中注册。不方便手改模板时,可选的
+[设置提示词辅助工具](https://fyaic.github.io/threadmesh/)只在浏览器里生成两段文字,
+不能观察或控制协作,也不是实时演示。[它实际验证了什么](../09-reviews/2026-09-08-pairing-helper-acceptance.md)。
选择两个已有上下文、没有业务副作用的 Codex 测试任务。例如,一个维护品牌信息,
另一个维护网页,且已经约定按钮名称必须保留 **Create my workspace**。
@@ -30,17 +30,18 @@
```text
使用这个固定版本公开链接中的 ThreadMesh 工作流,请完整读取文件:
-https://raw.githubusercontent.com/fyaic/threadmesh/93da0c6fc9814c1a28e95eaf34d287e11a4331f7/plugins/threadmesh-codex/skills/threadmesh-codex/SKILL.md
+https://raw.githubusercontent.com/fyaic/threadmesh/c0a0a913439732229a2bb811d23cc790c2dd0408/plugins/threadmesh-codex/skills/threadmesh-codex/SKILL.md
只把当前任务与“对方任务链接”配对。双方保留自己正在做的工作和此前约定。
允许交流的话题:允许交流的话题。
从提供的本地聊天链接确定对方,只用原生读取/状态工具核对这个任务。
不要列出所有任务或读取无关对话。链接或目标无法核实时,保持协作关闭。
-我授权设置完成后自动发送相关的同伴建议,理解空闲检查不能保证绝不与新输入竞争。
+我授权双方各自完成设置后自动发送相关的同伴建议,理解空闲检查不能保证绝不与新输入竞争。
本次设置回合不许给对方发消息,也不修改业务文件。
不要安装软件、修改权限或新建任务。
-请按名称确认选中的对方、允许话题、已有原生工具,以及当前任务是否已启用。
+请按名称确认选中的对方、允许话题、已有原生工具,以及当前任务是否就绪。
+不能仅凭本端设置就声称双方已经连接。
任何一项不可用,都保持协作关闭。
```
@@ -72,6 +73,26 @@ https://raw.githubusercontent.com/fyaic/threadmesh/93da0c6fc9814c1a28e95eaf34d28
需要知道变化。有用的结果是:出现带来源的原生消息,**同一个**网页任务接着自己
改对文案,同时保留此前的按钮约定和价格。请看实际结果,不只看“消息送达”。
+### 3. 在原对话里检查结果和停止
+
+不清楚进展时,说**“检查 ThreadMesh 状态”**。这是只读请求,不应启用协作或重发
+任何消息。任务应简短说明本端范围/模式、协作对象、最后观察到的结果及未知项:
+
+| 任务的说明 | 实际代表什么 |
+|---|---|
+| 本端就绪 | 只确认这一端设置完成,不代表对方已经同意并就绪 |
+| 未发送:对方忙碌/设置不明 | 建议留在本对话,不代表有自动重试或持久队列 |
+| 已发送,结果未核实 | 消息已提交,不代表对方做对了事情 |
+| 对方报告完成 | 有完成报告,核验实际产物后才能说已验证 |
+| 已验证+产物/测试 | 明确的业务结果已经实际检查 |
+| 本端已停止 | 本端待发建议已取消,不代表另一端也停止了 |
+
+这些是 Agent 的自然语言说明,不是持久状态服务或宿主强制的状态机。读取为空时应
+保持“未知”。要停止双向协作,在两个任务中分别说**“停止 ThreadMesh 协作”**;
+之后查询状态不得恢复取消的建议。Skill 不能撤回此前已提交的消息。
+这些状态说明规则通过了内部评审;最近一次原生状态尝试没有取得可核实结果,
+不能声称实测通过。[验证边界](../09-reviews/2026-09-08-pairing-helper-acceptance.md#later-correction-local-tasks-first-not-a-website-demo)。
+
### 可选:按任务名称查找
已经附上的原生任务引用也可以使用。若想直接填写完整任务标题,请明确允许读取
diff --git a/web/connect/app.mjs b/web/connect/app.mjs
index db7e816..b40d4a7 100644
--- a/web/connect/app.mjs
+++ b/web/connect/app.mjs
@@ -2,10 +2,10 @@ import { buildPair, EXAMPLES } from "./pairing.mjs";
const copy = {
en: {
- pageTitle: "Set up two Codex tasks · ThreadMesh", skip: "Skip to setup", language: "Language",
- title: "Let two tasks keep each other informed.",
- intro: "Prepare two setup prompts. Paste one into each existing Codex task, then continue your work.",
- scope: "This page only prepares text. It does not connect tasks, read chats or send messages.",
+ pageTitle: "Optional setup-text helper · ThreadMesh", skip: "Skip to setup", language: "Language",
+ title: "Prepare setup text for your local tasks.",
+ intro: "Optional template helper—not an agent demo. Paste the results into your original Codex tasks; collaboration happens there, not on this website.",
+ scope: "This page cannot run agents, connect tasks, show live progress or stop collaboration. It only prepares text; closing it does not stop your tasks.",
tasksTitle: "Choose your two tasks", taskA: "Task A link", taskB: "Task B link",
linkHelp: "Open each task in Codex and copy its chat deep link: ⌘⌥L on macOS, Ctrl+Alt+L on Windows.",
official: "Official shortcuts", localOnly: "Use two different local Codex tasks. Copy the whole link, not a shared-chat snapshot. You do not need to find an ID.",
@@ -36,10 +36,10 @@ const copy = {
consent_required: "Review the scope and select the confirmation checkbox before preparing prompts.",
},
zh: {
- pageTitle: "设置两个 Codex 任务 · ThreadMesh", skip: "跳到设置", language: "语言",
- title: "让两个任务主动交流,不再靠你转述。",
- intro: "生成两份设置提示,分别粘贴到已有的 Codex 任务中,然后正常工作。",
- scope: "这个页面只生成文字,不会连接任务、读取聊天或发送消息。",
+ pageTitle: "可选设置提示词工具 · ThreadMesh", skip: "跳到设置", language: "语言",
+ title: "为本地任务准备设置文字。",
+ intro: "这是可选的模板辅助工具,不是 Agent 演示。将结果粘贴到原来的 Codex 任务中;协作发生在那里,不在这个网页上。",
+ scope: "页面不运行 Agent、不连接任务、不显示实时进度,也不能停止协作。它只生成文字;关闭页面不会停止你的任务。",
tasksTitle: "选择你的两个任务", taskA: "任务 A 的链接", taskB: "任务 B 的链接",
linkHelp: "在 Codex 中分别打开任务,复制聊天深链:macOS 按 ⌘⌥L,Windows 按 Ctrl+Alt+L。",
official: "官方快捷键说明", localOnly: "请选择两个不同的本地 Codex 任务。复制完整聊天深链,不是分享聊天快照,无需查找 ID。",
diff --git a/web/connect/index.html b/web/connect/index.html
index 469be1a..d763ce5 100644
--- a/web/connect/index.html
+++ b/web/connect/index.html
@@ -5,8 +5,8 @@
-
-
Set up two Codex tasks · ThreadMesh
+
+ Optional setup-text helper · ThreadMesh
@@ -20,9 +20,9 @@
-
Let two tasks keep each other informed.
-
Prepare two setup prompts. Paste one into each existing Codex task, then continue your work.
-
This page only prepares text. It does not connect tasks, read chats or send messages.
+
Prepare setup text for your local tasks.
+
Optional template helper—not an agent demo. Paste the results into your original Codex tasks; collaboration happens there, not on this website.
+
This page cannot run agents, connect tasks, show live progress or stop collaboration. It only prepares text; closing it does not stop your tasks.
diff --git a/web/connect/pairing.mjs b/web/connect/pairing.mjs
index 1968505..8724501 100644
--- a/web/connect/pairing.mjs
+++ b/web/connect/pairing.mjs
@@ -1,5 +1,5 @@
// Pure browser/Node generator. No I/O: pasted links and topics stay with the caller.
-export const WORKFLOW_URL = "https://raw.githubusercontent.com/fyaic/threadmesh/93da0c6fc9814c1a28e95eaf34d287e11a4331f7/plugins/threadmesh-codex/skills/threadmesh-codex/SKILL.md";
+export const WORKFLOW_URL = "https://raw.githubusercontent.com/fyaic/threadmesh/c0a0a913439732229a2bb811d23cc790c2dd0408/plugins/threadmesh-codex/skills/threadmesh-codex/SKILL.md";
export const EXAMPLES = {
en: [
From 31804101e89f98db1c661bad11c9acaa2d70d160 Mon Sep 17 00:00:00 2001
From: veil-chow-fyaic <247294299+veil-chow-fyaic@users.noreply.github.com>
Date: Tue, 8 Sep 2026 15:04:28 +0800
Subject: [PATCH 3/3] test: retain completed native read-only status evidence
---
docs/06-guides/codex-native-tasks.md | 5 +--
.../2026-09-08-pairing-helper-acceptance.md | 35 +++++++++++++------
docs/10-planning/project-status.md | 8 +++--
docs/zh-CN/codex-native-tasks.md | 4 +--
4 files changed, 35 insertions(+), 17 deletions(-)
diff --git a/docs/06-guides/codex-native-tasks.md b/docs/06-guides/codex-native-tasks.md
index 71d40a0..709a862 100644
--- a/docs/06-guides/codex-native-tasks.md
+++ b/docs/06-guides/codex-native-tasks.md
@@ -112,8 +112,9 @@ or guaranteed host-enforced state machine. Empty reads remain unknown. Say
**“Stop ThreadMesh collaboration”** in both tasks to stop both directions;
checking status afterward must not resume cancelled advice. Previously submitted
messages cannot be recalled by this skill.
-These reporting rules passed internal review; the latest native status attempt
-did not produce a verifiable result. [Validation boundary](../09-reviews/2026-09-08-pairing-helper-acceptance.md#later-correction-local-tasks-first-not-a-website-demo).
+One original-task read-only check preserved the stop and reported unknown peer
+state correctly. It took about 142 seconds, not an instant lookup; incomplete
+early observations are retained. [Validation boundary](../09-reviews/2026-09-08-pairing-helper-acceptance.md#later-correction-local-tasks-first-not-a-website-demo).
### Optional: use a task name instead
diff --git a/docs/09-reviews/2026-09-08-pairing-helper-acceptance.md b/docs/09-reviews/2026-09-08-pairing-helper-acceptance.md
index b215946..c8bbc1a 100644
--- a/docs/09-reviews/2026-09-08-pairing-helper-acceptance.md
+++ b/docs/09-reviews/2026-09-08-pairing-helper-acceptance.md
@@ -129,17 +129,32 @@ helper regression tests, the full 474-pass/one-skip suite and documentation lint
passed. The system Python lacked PyYAML; the validator passed in an isolated
`uv --with pyyaml` environment without changing project dependencies.
-One read-only status request was also dispatched to the original, previously
-stopped receiver using the new public workflow. **No live status pass is
-claimed.** The desktop wait surface reported an active turn with no readable
-result, while the official read-only App Server capture marked that selected
-turn interrupted and retained only the incoming request. Neither proves a
-completed check. There were no outgoing sends or file changes in the captured
-items, and the four checked receiver files retained their pre-request hashes.
-This is a bounded negative observation, not proof that no later activity can
-occur. No retry or additional business request was dispatched. Its selected-turn
-capture is retained privately with SHA-256
+One read-only status request was dispatched to the original, previously stopped
+receiver using the new public workflow. **The completed check passed narrowly:**
+the receiver fetched the complete pinned workflow, made one native status
+snapshot of its selected peer, and reported:
+
+- local collaboration remains stopped and pending advice cancelled;
+- the peer is `notLoaded`, not proof of peer stop or readiness;
+- the earlier client edit and five tests have historical evidence, but files
+ were not rechecked in this turn; later file changes remain unknown.
+
+The full completed turn contains the workflow fetch and one read-only native
+snapshot, zero outgoing peer sends and zero file changes. The four checked
+receiver files retained their pre-request hashes. The desktop returned to idle.
+The turn took **141.667 seconds**, including workflow retrieval and model work:
+this is not an instant status service. No retry or second business request was
+dispatched. Private completed-turn SHA-256:
+`a35cf89921c8039b39ef91694ae279e67d9d4c7749cb854c87d7b18bcc20999f`.
+
+The earlier in-progress read is retained, not discarded: desktop wait reported
+active with no readable result while an App Server capture marked interrupted
+and contained only the request. It was **not** accepted as completion. After
+the terminal event, the full original items were recovered with the official
+read-only App Server. Early-capture SHA-256:
`b87454bfb173bb6c113c5d534efb7aad1bbcb9e8935ee028aeea54fefa901ead`.
+This exposes a host observation limitation, not a diagnosed root cause. The
+public record separates the incomplete observation from the final outcome.
Independent GUI first use, persistent desktop control, simultaneous-input
safety and measured native-only advantage remain open. The reordered
diff --git a/docs/10-planning/project-status.md b/docs/10-planning/project-status.md
index 6161a83..8b3d98f 100644
--- a/docs/10-planning/project-status.md
+++ b/docs/10-planning/project-status.md
@@ -11,9 +11,11 @@ The native skill now explicitly distinguishes local readiness, peer confirmation
pending advice, sent/unverified, receiver-reported completion and checked result.
Status requests do not reactivate stopped collaboration. These are agent
instructions, not a new host-enforced state machine.
-Read-only internal behavior review and regressions passed; the new original-task
-status attempt produced inconsistent host observations and no readable result,
-so it is **not** a native status pass. [Result and limits](../09-reviews/2026-09-08-pairing-helper-acceptance.md#later-correction-local-tasks-first-not-a-website-demo).
+Internal behavior review and regressions passed. The original-task read-only
+status check then passed: local stop preserved, unloaded peer kept unknown,
+historical evidence distinguished from current verification, zero sends/edits.
+It took 141.667 seconds; incomplete early host observations are retained, so
+this is not an instant or generally reliable state service. [Result and limits](../09-reviews/2026-09-08-pairing-helper-acceptance.md#later-correction-local-tasks-first-not-a-website-demo).
### Last completed evidence
diff --git a/docs/zh-CN/codex-native-tasks.md b/docs/zh-CN/codex-native-tasks.md
index fcbcbb4..42fd908 100644
--- a/docs/zh-CN/codex-native-tasks.md
+++ b/docs/zh-CN/codex-native-tasks.md
@@ -90,8 +90,8 @@ https://raw.githubusercontent.com/fyaic/threadmesh/c0a0a913439732229a2bb811d23cc
这些是 Agent 的自然语言说明,不是持久状态服务或宿主强制的状态机。读取为空时应
保持“未知”。要停止双向协作,在两个任务中分别说**“停止 ThreadMesh 协作”**;
之后查询状态不得恢复取消的建议。Skill 不能撤回此前已提交的消息。
-这些状态说明规则通过了内部评审;最近一次原生状态尝试没有取得可核实结果,
-不能声称实测通过。[验证边界](../09-reviews/2026-09-08-pairing-helper-acceptance.md#later-correction-local-tasks-first-not-a-website-demo)。
+一次原任务只读检查保留了停止状态,并正确报告对方状态未知。耗时约 142 秒,
+不是即时查询;早期不完整的观察也已保留。[验证边界](../09-reviews/2026-09-08-pairing-helper-acceptance.md#later-correction-local-tasks-first-not-a-website-demo)。
### 可选:按任务名称查找