fyaic · veil-chow-fyaic · Sep 8, 2026 · Sep 8, 2026 · Sep 8, 2026 · Sep 8, 2026
@@ -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.

@@ -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)

@@ -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,15 +117,16 @@ 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
 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

@@ -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,20 +38,21 @@ 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.
 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,30 @@ 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.
+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
 
 An already attached native task reference also works. If you prefer an exact

@@ -103,3 +103,61 @@ 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 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
+[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.