Skip to content

feat(workspace): diagnose Agent runtime readiness in place - #6537

Open
songoow wants to merge 6 commits into
loopx-project:mainfrom
songoow:codex/runtime-readiness-20261015
Open

songoow wants to merge 6 commits into
loopx-project:mainfrom
songoow:codex/runtime-readiness-20261015

Conversation

@songoow

@songoow songoow commented Oct 15, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

A brand-new install with no Agent CLI on PATH gave the owner nothing to act on: Codex, Claude Code and Kiro CLI only showed up as disabled entries in the runtime picker ("· 不可用"), with no reason, no next step and no way to confirm a repair short of reloading. The roadmap's first-use journey asks the Dashboard to "diagnose … tool readiness in place" and to offer "a concrete repair".

This makes readiness visible and repairable in place, without installing or granting anything.

  • The service names what is missing. Built-in endpoint rows now carry the probe they failed: unavailable_reason: "executable_not_found" with the probed executable for Codex, Claude Code and Kiro CLI, or unavailable_reason: "api_key_not_set" with the environment_variable for the Anthropic/OpenAI API rows. Available rows carry the same name without a reason. unavailable_reason is the field extension endpoints and bindings already use; the two literals are new values of it.
  • The home says so when nothing is ready. With every execution runtime unavailable, the manager overview shows one notice: what LoopX needs (a CLI such as Codex, Claude Code or Kiro CLI, or an API key), one line per runtime naming the missing command or variable, a Check again button and a Setup guide link to the getting-started doc. The read-only status projection and the loading placeholder never count as runtimes, so an empty catalog stays "detecting" rather than "nothing installed".
  • The composer explains why it cannot send. In a Goal or manager conversation, when nothing is ready or the selected runtime is unavailable on this machine, a one-line status above the composer says so with the same re-check and guide.
  • Check again reads back. It re-reads the service's runtime catalog (the existing capabilities revision); the notice withdraws only when the catalog reports an available runtime. Nothing is installed, no credential is written, no grant changes.
  • Three hard-coded Chinese agent labels on the dashboard page ("可用/需要配置/正在检测", "当前 Goal 写入前验证") move to i18n on the way.

No runtime ready: the home notice and the composer line

Review round 2 (head after 9f8b82e7b)

  • Readable on a phone. The notice's single grid track now shrinks (minmax(0, 1fr)), its children and list items have no minimum width and wrap anywhere, and a probed path (code) breaks inside the card; the composer line wraps the same way. No component, state or probe change.

Validation

  • runtime-readiness-live now also switches to a 390px viewport and asserts from bounding boxes that every paragraph, list item, code token and heading ends inside the card and the viewport (the document's scroll width alone could not show the clipping).
  • Real service, end to end (runtime-readiness-live, packaged lane): a disposable loopx chat (serve_chat on a temporary runtime, no registry, no credentials) is started with Codex, Claude Code and Kiro executables that do not exist. The packaged page reads the real catalog, status and projects; the home notice names the real probed paths and the unset ANTHROPIC_API_KEY/OPENAI_API_KEY. The scenario then creates an exit-only Codex stub in its temporary bin directory and clicks Check again: the real probe reports it available, the notice withdraws, and the service's own catalog reads back available: true with no reason. The HTTP catalog and filesystem probe are real; the browser transport and temporary Agent executable are controlled fixtures. No host installation, login or model execution is exercised.
  • tests/test_chat_endpoint_readiness.py: missing executables and keys name their requirement; present ones report available without a reason. test_chat_ordinary_project.py, test_chat_manager_context.py, test_chat_server_cors.py pass.
  • runtime-readiness.test.mjs (5 cases): empty catalog is detecting; none available lists all; selected-unavailable names alternatives; available selection or no selection is ready; requirements come only from the service's reason fields.
  • Browser scenario runtime-readiness (dev build, fixture reports the catalog): all runtimes missing → home notice with the exact command and variable names and the guide link; the fixture repairs Codex → Check again withdraws the notice; with a Goal conversation open and nothing ready → composer line; repaired → line withdraws; no Turn was ever sent. agent-model-selection and steward-journey pass.
  • personal-workspace-contract.test.mjs pins the detecting rule, the projection/placeholder exclusion, the re-check wiring and both locales. dashboard tsc --noEmit, check:css-custom-properties, generate_semantic_inventory.py --changed-from HEAD (no new carriers).

Not covered. Installed App; login state after installation is not probed here, as today. The guide link points at the GitHub blob of docs/guides/getting-started.md, like the existing acceptance-contract link.

Observed on the real service, not changed here. With no Codex on PATH the header's steward chip still reads "codex · 个人 CLI 登录 · gpt-6-astra · high": that chip comes from the manager channel binding projection, which reports the configured binding rather than probing the executable. The readiness notice and the chip therefore disagree on a fresh machine. That projection has its own owner; recorded as a follow-up rather than patched from the frontend.

Default change. None. With at least one runtime available the home and composer render exactly as before.

🤖 Generated with Claude Code

Current source qualification

Current published head: 540477ae6bafd525553b812394cbaa1f3dfaea24. It addresses the independently reproduced phone clipping at the preceding head: the existing readiness grid permits its children to shrink and long command paths to wrap. No runtime probe or execution authority changes. The backend/provider and readiness rule/test blobs are unchanged from 9f8b82e7b5300d46a35d9d8d0a6b29ddcbbf6422; earlier Python receipts remain tied to their original source heads, not relabeled as a new run.

A fresh clean checkout of this exact head passes the workspace contract, TypeScript and CSS checks, 27 readiness/return/suggestion unit cases, a normal Chat bundle build and source-bundle integrity. Five compiled packaged scenarios pass: runtime-readiness-live, runtime-readiness, agent-model-selection, since-you-looked and goal-suggestions. The real disposable service names its explicit missing Agent paths; at390px each heading, paragraph, list item and code token stays inside both the card and viewport. A temporary exit-only executable followed by Check again changes the real catalog to available and withdraws the notice. Both desktop and phone were observed; no real CLI/model, installation, credential write or Turn is involved.

This validates the bounded diagnostic and repair-readback journey, including phone content containment. It does not qualify Agent login, real model use, installed App, sustained operation or the configured-binding/live-probe discrepancy disclosed above. Current-head independent review and complete natural hosted CI remain required. No duplicate source integration or push was needed for this qualification.

@mergify

mergify Bot commented Oct 15, 2026

Copy link
Copy Markdown

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @songoow.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

@mergify mergify Bot added the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 15, 2026
@songoow
songoow force-pushed the codex/runtime-readiness-20261015 branch from 49e3afb to be73508 Compare October 15, 2026 15:23
@mergify mergify Bot removed the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 15, 2026
@songoow
songoow force-pushed the codex/runtime-readiness-20261015 branch from be73508 to 13b94c1 Compare October 15, 2026 16:18
@mergify

mergify Bot commented Oct 15, 2026

Copy link
Copy Markdown

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @songoow.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

@mergify mergify Bot added the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 15, 2026
songoow and others added 2 commits October 16, 2026 01:44
A fresh install without an Agent CLI on PATH showed Codex, Claude Code and
Kiro CLI only as disabled picker entries, with no reason, no next step and
no way to confirm a repair short of reloading. The first-use journey asks
the Dashboard to diagnose tool readiness in place and offer a concrete
repair.

Built-in endpoint rows now name the probe they failed: `unavailable_reason`
"executable_not_found" with the probed `executable`, or "api_key_not_set"
with the `environment_variable`; available rows carry the name without a
reason. The frontend derives one typed readiness from the execution
runtimes only (the read-only status projection and the loading placeholder
never count): nothing available, the selected runtime unavailable here, or
ready. The manager home shows a notice naming each missing command or
variable with Check again and a Setup guide link; a Goal or manager
conversation shows the same above the composer. Check again re-reads the
service's runtime catalog and withdraws the notice only when it reports an
available runtime. Nothing is installed, written or granted. Three
hard-coded Chinese agent labels move to i18n on the way.

Validation: Python readiness test and the chat test families; node test
for the derivation; browser scenario covering the home notice with exact
names, re-check withdrawal, the composer line and no Turn sent;
agent-model-selection and steward-journey unchanged; contract test pins
the detecting rule and the projection/placeholder exclusion.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: song <liusongstep@gmail.com>
Add an end-to-end scenario that starts a disposable real `loopx chat`
(serve_chat on a temporary runtime, no registry, no credentials) whose
Codex, Claude Code and Kiro executables do not exist, routes the packaged
page's catalog, status and project reads to it, and asserts the home
notice names the real probed path and the unset API variable. The
scenario then installs a Codex executable and clicks Check again: the
real probe reports it available and the notice withdraws, read back from
the service's own catalog. Nothing on this path is synthetic except the
browser; the fixture-driven scenario keeps the timing and negative cases.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: song <liusongstep@gmail.com>
@songoow
songoow force-pushed the codex/runtime-readiness-20261015 branch from 13b94c1 to 6bf1947 Compare October 15, 2026 17:46
@mergify mergify Bot removed the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 15, 2026
@mergify

mergify Bot commented Oct 15, 2026

Copy link
Copy Markdown

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @songoow.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

@mergify mergify Bot added the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 15, 2026
Signed-off-by: song <liusongstep@gmail.com>
@mergify mergify Bot removed the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 15, 2026
@mergify

mergify Bot commented Oct 15, 2026

Copy link
Copy Markdown

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @songoow.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

@mergify mergify Bot added the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 15, 2026
…ss-20261015

Signed-off-by: song <liusongstep@gmail.com>

# Conflicts:
#	apps/presentation/dashboard/package.json
#	apps/presentation/dashboard/src/features/personal-workspace/personal-workspace-contract.test.mjs
#	apps/presentation/dashboard/src/features/personal-workspace/personal-workspace-page.tsx
#	examples/personal-workspace-browser-smoke.mjs
@mergify mergify Bot removed the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 15, 2026
@mergify

mergify Bot commented Oct 15, 2026

Copy link
Copy Markdown

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @songoow.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

@mergify mergify Bot added the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 15, 2026
…ss-20261015

Signed-off-by: song <liusongstep@gmail.com>

# Conflicts:
#	apps/presentation/dashboard/package.json
#	apps/presentation/dashboard/src/features/personal-workspace/personal-workspace-contract.test.mjs
#	apps/presentation/dashboard/src/features/personal-workspace/personal-workspace-page.tsx
@mergify mergify Bot removed the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 15, 2026

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=max

REQUEST_CHANGES — head 9f8b82e7b5300d46a35d9d8d0a6b29ddcbbf6422。 服务端缺项诊断与重新检查有效;一项 P2 仍阻塞窄屏旅程:实际命令路径会撑宽提示内部内容,所需修复信息被裁掉。

动机

首次打开工作区、机器尚未装好 Agent 命令或设置 API 密钥的所有者。

以前只能看到灰色的不可用运行时;现在页面应说明缺哪个命令或变量,修好后在原处重新检查。

真实 Chat 目录能报告缺项,创建临时可执行文件后原页重新检查会撤下提示,零模型 Turn;390px 下诊断文字仍被裁切。

不安装运行时,不写入凭证,不验证真实登录或模型,不新增执行权限。

诊断需在窄屏完整可读;真实登录、模型可用性和安装 App 资格仍由原有后续验收负责。

不改动会让首次使用者只能猜灰色选项缺什么;复用原有目录读回比增加安装器或独立健康服务更小。按原 roadmap 的首次使用步骤,这能交付缺项诊断的一段,不等于完整登录、模型或常驻 Agent 已经就绪。

改动思路

运行时探测仍由原 endpoint/provider owner 负责,前端只派生诊断并重读目录;无需添加安装器或并行健康状态,但必须让现有提示在窄屏完整可读。

本 PR 的边界是本机缺项诊断及原页重新检查;修复提示布局即可闭合这一段,不把命令存在当成登录、模型或安装 App 资格。

本 head 的源码路径对照如下;这是说明表,实际服务与页面观察另列。

路径 结果和边界
原 endpoint 目录 仍由 shutil.which / 变量存在性及原 provider 给出 available;现在补上缺项名称
新 UI 读模型 排除 status-only 和 loading 占位;空目录保持 detecting;区分全部不可用与选中项不可用
重新检查 递增原 capability revision,重读同一目录;不安装、不写凭证、不发送 Turn
恢复/错误 临时503保留已知缺项提示;后续真实成功读回可撤下提示;窄屏内容仍须完整可读

这里的 Python helper 是原有主机 IO,TS union 负责本地投影,generic control-plane 决策没有迁出或另立 owner。真实 SDK、登录和 provider 账户健康仍是其它 owner 的职责,不能从一个可执行文件存在推导出来。

具体改动

独立基准为 docs/development/design.md,固定 revision a99cb07addfc163fda9435c6455cc9462b657855;同时先读同版本 overall roadmap 的 “One first-use journey and one flagship result” 第1/2步与 frontend-delivery 规则。PR 新增使用指南只作为被审内容。

  • Earn The User's Attention:implemented,限缺项诊断增量。 原页面没有缺项解释;当前真实 Chat capabilities 明确返回缺失命令或环境变量。原页重新检查实际撤下已修复提示,未发生模型调用或权限变化。
  • Responsive Behavior:not_met。 390px 下新提示卡右边界为374,段落和列表右边界约468.8。内容已经超出可见卡片与视口,却被上层裁切;“没有页面横向滚动”不能证明这些字可读。

关键代码讲解

  1. _executable_readiness:沿原 provider IO 返回命令名与缺失原因,shutil.which 的真假判定保持;没有安装动作,也不验证登录。
  2. deriveRuntimeReadiness:从原目录派生四分支 UI 状态:空目录未知、全部缺失、选中不可用、可用;排除只读与加载占位后才判断。
  3. RuntimeReadinessNotice/recheckRuntimes:home/composer 显示同源说明,重新检查只让原 capability revision 重读;available 的变化才撤提示,不发送 Turn。
  4. .personal-runtime-readiness:新提示承担缺项的可读呈现;当前 grid 内部最小内容宽度未受限,实际390px下正文与列表都撑出可见边界。

其余 wiring 把可选 reason/executable/environment_variable 从既有 capabilities schema 带进选项,复用原目录 revision;中英文案说明缺项、检查与指引,旧硬编码状态标签也被本地化。fixture override 只服务测试,新增 real-service 场景独立运行实际目录探测。整批19文件、+498/-13、5个提交 DCO 完整,没有新增 native state、schema authority 或 privileged apply。

对主干的风险

P2:让诊断正文和命令路径在卡片内真正收缩和换行。 用一次性真实 Chat 服务配置不存在的绝对 Codex/Claude/Kiro 路径,正常编译页面确实显示这些原探测路径。在390px下,358px宽的卡片内部段落/ul实际宽约435.8px,命令列表与正文延伸到468.8;当前 display:grid 的隐式轨道保留 min-content 宽度,长路径又未允许充分换行。所有者看不到完整缺项名称和部分操作说明。这是新诊断的实际内容裁切,不是要求调整个人审美。

最小修复限于现有 notice CSS:允许轨道/子项收缩,并让长路径可换行;不另造组件或改变探测状态。新增390px真实目录回归应检查文字/列表子项的可见边界,而不只检查 document.scrollWidth。我的第一版探针只查后者会得到 false“无溢出”;截图暴露裁切后增加独立子项边界断言,该断言在当前 head 明确失败,未改产品或放宽阈值。桌面、修复后撤提示、再移除可执行文件后的不可用状态须保留。

独立当前结果:122个 Python 用例、27个 readiness/return/suggestion 单元、完整 workspace contract、项目 tsc、CSS、正常 Chat build/source verify 通过;六个正常打包场景通过;原生 canary 5 direct +16 selected 通过。基线与当前 head 均读取相同类型的实际缺项目录,原 available 语义保留;当前页面才提供具体缺项。另测一次503后恢复、创建临时可执行文件后重新检查、再移除后的诊断回归,全程0 Turn。最终390px内容边界断言失败须保留,不能被正常场景的通过覆盖。未读取或等待 GitHub CI。

managed binding chip 在基线已经展示配置的绑定而不是 live 可执行资格,当前 PR 已披露该差异。保留这个独立后续,不把它归成新回归或声称本次验证了登录。真实服务是真实目录和 IO;可执行文件为合成 fixture,未触发模型、账户、安装 App 或生产操作。503控制的是传输故障,预期 console503仍保留在记录中。

语义与 CI 对齐

复用 endpoint 的已有 open unavailable_reason 字段;两个诊断值延伸其数据,不是新执行状态/authority vocabulary。四分支 RuntimeReadiness 与 requirement 是 TS 本地读模型。advisory 后完整语义检查通过;没有把诊断叫作强制执行义务,也没有从 available 推导额外授权。前瞻性 pass 抽出小型同源 IO helper,避免各 built-in 重复原因规则;当前修复继续留在同一 CSS 边界。

我的整体评价

这是有用、可回滚且规模适当的 justified_increment,architecture assessment 为 retain。long_horizon 为 preserved:只是探测与读回,未新增工作、安装和授权;user_experience 在窄屏为 regression,因为所需诊断内容不可读。因此 REQUEST_CHANGES,先修正文/路径可见边界,再保持原真实探测与恢复。完整 first-use、真实登录/模型与安装态仍沿原验收,不以本地测试数关闭,也不把本评审当作合并授权。

English verdict: REQUEST_CHANGES - 9f8b82e; real catalog diagnosis and in-place recovery work without Turn or permission effects, but the new readiness grid clips required text and executable paths at390px. Bound and wrap the existing grid children, then assert visible content containment. 122 Python cases,27 frontend cases,six packaged scenarios and local canary pass; login/model/installed-App qualification remains open.

Review measured the packaged 390px page against a real Chat service that
reports absolute executable paths: the notice card ended at 374px while
its paragraph and list ran to about 469px, because the implicit grid
track kept its min-content width and a probed path is one unbreakable
token. The owner could not read the missing command names or the end of
the repair text.

The notice's single track may now shrink (minmax(0, 1fr)), its children
and list items have no minimum width and wrap anywhere, and a code token
breaks inside the card; the composer line gets the same wrapping. No
component, state or probe changes.

The real-service scenario now also sets a 390px viewport and asserts that
every paragraph, list item, code token and heading ends inside the card
and the viewport, since the document's scroll width alone could not show
the clipping.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: song <liusongstep@gmail.com>
@songoow

songoow commented Oct 15, 2026

Copy link
Copy Markdown
Collaborator Author

Fixed on head 540477ae6bafd525553b812394cbaa1f3dfaea24.

P2, the notice clipped on a phone. The implicit grid track kept its min-content width and a probed absolute path is one unbreakable token. The notice's single track now shrinks (grid-template-columns: minmax(0, 1fr)), its direct children and list items have min-width: 0 with overflow-wrap: anywhere, a code token breaks inside the card, and the composer line wraps the same way. No component, state or probe change.

Regression. runtime-readiness-live (real Chat service, real probed paths, packaged bundle) now also switches to a 390px viewport and asserts that every paragraph, list item, code token and heading ends inside the card and inside the viewport, measured from their bounding boxes rather than the document's scroll width. Desktop readback, the temporary-503 hold, the install → "重新检查" withdrawal and the removed-executable return are unchanged and still pass; the fixture scenario and the CSS token check pass.

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=max

APPROVE — head 540477ae6bafd525553b812394cbaa1f3dfaea24。 上轮窄屏裁切已在真实目录、正常编译页面上独立验证修复;本次重新判断完整提案,批准这段缺项诊断与原页重新检查。

动机

首次打开工作区、机器尚未装好 Agent 命令或设置 API 密钥的所有者。

以前只能看到灰色的不可用运行时;现在页面应说明缺哪个命令或变量,修好后在原处重新检查。

真实 Chat 目录能说明缺项,修好后原页重新检查撤下提示;390px 下正文和完整命令路径已能在卡片内换行,全程零模型 Turn。

不安装运行时,不写入凭证,不验证真实登录或模型,不新增执行权限。

本段缺项诊断与重新检查已验证;真实登录、模型可用性和安装 App 资格仍沿既有首次使用验收推进。

不修改时,首次使用者只能从灰色选项猜缺少什么,再自行刷新。更小的合法路线是沿现有目录说明缺项、修好后原处读回,而非先构造团队、复制诊断命令或增加独立安装器。缺项诊断是一段可独立使用、验证和回滚的首次使用增量;不能把它等同于完整首次研究结果或真实模型可用性。

改动思路

运行时探测继续复用原 endpoint/provider owner,前端派生诊断并重读目录;同一提示的 CSS 收缩和换行已闭合窄屏读回,无需并行健康服务或安装器。

本 PR 交付本机缺项诊断及原页重新检查;命令存在仍不等于登录、模型或安装 App 已就绪,后续沿原首次使用验收继续。

以下表格解释本 head 的源码路径,表格本身不是执行证据。

输入或操作 结果及边界
原 executable / environment 探测 仍由原 provider 给出 available;新增名称解释原来的不可用原因
目录为空或只有占位 保持 detecting,不误报“全部缺失”
运行时缺失或选中项不可用 原首页或 composer 显示相应诊断、指引和重新检查
修复后重新检查 通过原 capabilities revision 重读同一目录,不安装、不写凭证、不发送 Turn
临时读取失败 保留上次已知诊断,后续成功读回再更新

Python helper 留在已有主机 IO 边界;TS 的判别联合只派生展示状态,未另立控制面决策源。原 managed/extension provider 继续拥有自己的 availability 和 reason。已有登录、账户或执行授权不会被一个命令存在性探测替代。

具体改动

独立依据先于 diff 固定为 docs/development/design.md 的 Earn The User's Attention 与 Responsive Behavior,同时核对同版本 overall roadmap 的 “One first-use journey and one flagship result” 第1/2步及 frontend-delivery。新使用指南是被审内容,不是它自己的批准依据。

  • 注意力与首次使用:implemented,限本段。 正常编译页面连接真实一次性 Chat 目录,能明确显示缺失命令或环境变量;实际修复后在原处重新检查撤下提示,不经过模型或权限写入。
  • 窄屏可读:implemented。 保留旧 9f8b82e7b 的失败:390px 下段落/列表曾越过卡片。当前相同真实目录与独立探针中,卡片右边界374,段落和列表右边界357,所测子项均在卡内,完整路径换行可读。已检查桌面和390px整屏截图。

关键代码讲解

  1. _executable_readiness:沿原 executable 探测返回可用性与缺失命令名,不代替登录或模型健康。
  2. deriveRuntimeReadiness:将原目录派生为 detecting、none_available、selected_unavailable、ready,排除状态投影与占位。
  3. RuntimeReadinessNotice/recheckRuntimes:首页解释真实缺项;recheckRuntimes 递增原 capabilities revision,读回修复结果,不执行安装或 Turn。
  4. .personal-runtime-readiness:轨道 minmax(0,1fr)、子项 min-width:0 和长路径换行让390px诊断保持在卡片内。

_environment_readiness 同样复用变量存在性;schema 的可选字段经过原 dashboard/runtime 选项接通。recheckRuntimes(page:1044)递增原目录 revision;原首页和 composer 都有读回入口。两种语言、旧状态标签的 i18n、一个截图/指南、节点测试、真实后端测试及两个浏览器场景共同覆盖完整19个路径,+517/-13;6个提交均带 DCO。与上一头逐路径比较,17个提案路径 blob 不变,只更新同一 CSS 边界和真实场景的几何断言,未引入新组件、状态或探测器。

对主干的风险

旧裁切的最小修复已落在原 notice CSS:单列轨道 minmax(0,1fr)、子项 min-width:0、长词和命令路径换行,composer line 同样有收缩限制。当前还执行了更宽的原始旅程:全部缺项 → 注入一次临时503仍保留诊断 → 创建临时可执行文件 → 重新检查后提示消失且真实目录 available=true → 删除文件后重新出现。全程0 Turn。预期的503 console 记录没有被抹去,也不被冒充页面正常请求失败。

当前独立验证包括122个 Python 用例、27个 readiness/return/suggestion 单元、完整 workspace contract、显式项目 TypeScript、CSS、正常 Chat bundle build/source verify;六个正常打包场景(readiness、真实目录、Agent/model选择、return、suggestion、steward)通过。语义 advisory 在完整语义检查前执行,原生 canary 为5 direct +16 selected,0 failure、0 manual hold。上轮实际 base/head 的目录差分按同源规则、消费者、依赖和平台失效矩阵复用;受 CSS 影响的当前编译 UI、真实探测、恢复及子项几何重新执行。没有从旧 verdict 推导本次批准,也没有查询、触发或等待远程 CI。

本测试的“真实”限于 Chat 目录、文件存在性和原调用方;临时 executable 是合成 fixture,未认证登录、模型账户、已安装 App、自然宿主或长期成本。managed binding chip 在基线已显示配置而非 live 探测,PR 也披露了这一独立后续。本次不把它改写成登录资格,也不把未合并主干组合冒称已执行。

语义与前瞻性检查

两个原因值扩展已有开放诊断字段,TS readiness/requirement 是本地读模型;没有新增共享 authority vocabulary、配额规则或 agent obligation。失败说明保持通用,不用文字子串推导权限。前瞻性 pass 保留已有小型 IO helper,修复也收敛在同一 CSS owning boundary;无需扩展成安装、登录或健康框架。原意和既有授权已足够,诊断读回没有增加强制澄清轮次;修复真实外部前提仍是必要工作,页面没有替用户悄悄执行。

我的整体评价

完整提案是合适的 justified_increment,architecture assessment 为 retain。long_horizon 为 preserved:没有新安装、执行或重试权威;user_experience 为 improved:原来猜测/刷新变成可读缺项与原处确认,窄屏反例已修复。批准当前源码与受测打包旅程,旧裁切 blocker 可按当前证据关闭;保留真实登录、模型、安装态和更大首次使用验收,既不以测试数宣布整体完成,也不把本评审当成 merge 授权。

English verdict: APPROVE - 540477a; the complete runtime-diagnosis proposal passes current real-catalog recovery and packaged tests. The prior390px clipping counterexample now fits within the card;122 Python cases,27 frontend cases,six packaged scenarios and local canary pass. Presence-only fixtures do not qualify real login/model or installed-App readiness.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants