task: Harness evaluation-mode CPU execute for Apps #429

Activity

1. zengchuang-hw

   added

   kind:taskBounded delivery task with a delegated sliceBounded delivery task with a delegated slice

   area:harnessHarness module: profile, A/B loop, quality gates, evidence reportsHarness module: profile, A/B loop, quality gates, evidence reports

   status:proposedWaiting for the decision named in the status blockWaiting for the decision named in the status block

   on Nov 13, 2026
2. zengchuang-hw

   added a parent issue on Nov 13, 2026

   • task: Apps 应用层详细设计与迁移计划（CLI / Python / Plugin） #371
3. amy-why-3459 commented on Nov 13, 2026

   

   amy-why-3459

   on Nov 13, 2026 – with Cursor

   Collaborator

   More actions

   Thanks for splitting this out. #427 (approved on 6778eb19) is the producer of the spec this slice consumes, so I've written a few points from the Apps side for whoever picks this up:

   1. Deadline without a step timeout. The Bind saved Apps requests to frozen worker specs #427 binder emits the attempt root with a null step timeout, because OperationRecipe v1 has no per-step timeout. Harness evaluation mode then has to enforce the preserved attempt deadline and budget at the attempt level. Could the acceptance state this explicitly and include a test where the deadline expires mid-candidate, covering the recorded outcome and cancellation?
   2. Which failures are recorded, and which are rejected? Bullet 1 validates the prepared binding and expected worker digest before registration. T37-N1/N2 record committed not_started / not_performed facts, which implies registration already happened. Please spell out the boundary: (a) a malformed spec or binding mismatch is rejected with no RunStore record; (b) once registered, an entry-identity mismatch or unavailability becomes a committed fact. Two separate tests would keep that boundary from drifting.
   3. Evidence for T40 replay. "No new attempt or process on replay" needs an observable check, e.g. the RunStore attempt count stays the same and a process-spawn counter or fake launcher records zero starts. It should also say what the replay key is (saved request digest vs. attempt id).
   4. Dependency order. Harness can develop against the D023 golden ExecutionSpec now. The production T37/T40 runs still need task: Benchmark production prepare and frozen resource closure #430's real prepare output. It would help to note that under "Next action" so the two implementers don't block on each other.

   Once an implementer is confirmed, linking their PR here will make independent review easier to track.
4. amy-why-3459 commented on Nov 13, 2026

   

   amy-why-3459

   on Nov 13, 2026 – with Cursor

   Collaborator

   More actions

   Thanks, the updated acceptance covers all four points: the pre-registration vs. post-registration boundary, T37-N1/N2 with zero starts, attempt-level deadline/budget enforcement under a null step timeout, and an observable T40 replay key and evidence. Developing against the D023 golden independently of #430 is also clear now.

   One small gap in the new T40 bullet: it defines replay for a completed attempt (return the original RecordRef) and for a digest conflict. What should happen when the same request and digest are replayed while the original attempt is still running, or after it ended without a committed record (crash, persistence error)? Stating the expected outcome, e.g. a conflict/in-progress error with zero starts versus a resumable record, would keep that path from being decided ad hoc in the PR.
5. zengchuang-hw commented on Nov 13, 2026

   

   zengchuang-hw

   on Nov 13, 2026 – with ChatGPT Codex Connector

   ContributorAuthor

   More actions

   给 #429 实现和联调用的 D023 对照值。保留现有 golden 的全部字段，只把 steps[0].timeout_seconds 从 "30" 改成 null，与 #427 当前 Apps binder 输出逐字段一致。规范编码仍是 2069 字节，request_digest 为 sha256:62ce11e6d458b5c581245d0988189e1bd834f2ed1e1880d15242faf70c5b6fe9。这是本地由 binder 和 Harness 公开摘要函数交叉计算出的 fixture 值，生产 T40 仍以实际保存请求和 RunStore 验证。
6. Dong1017 commented on Nov 14, 2026

   

   Dong1017

   on Nov 14, 2026

   Collaborator

   More actions

   Decision — Harness implementer + bounded delivery (Dong-bot as @Dong1017 delegate)

   Recorded 2026-11-15 (Asia/Shanghai). Authority: Dong-bot decision authority for @Dong1017 accept/decide. Thread basis: Amy acceptance coverage (6853603852); D023 null-timeout fixture values from author (6856118851); #362 S2 Harness owner = Dong1017 (6763626721).

   Accepted — bounded evaluation-mode delivery

   Accept this issue’s acceptance text as the bounded Harness evaluation-mode CPU execute delivery for #371 step 2:

   • Pre-registration rejects malformed/inconsistent prepared bindings with no RunStore record; post-registration T37-N1/N2 commit not_started / not_performed with zero starts.
   • Null step timeout → enforce attempt deadline and budget (mid-run expiry, cleanup, cancellation on the real CPU path).
   • T40 replay of the same saved request + attempt identity + canonical digest returns the original fixed RecordRef for a completed attempt; digest conflict remains a conflict. Observable zero additional starts / unchanged attempt count.
   • Develop against the D023 golden ExecutionSpec independently of task: Benchmark production prepare and frozen resource closure #430; production Apps T37/T40 integration waits until both ports exist.

   Author’s posted D023 control values (null timeout_seconds, 2069-byte encoding, request_digest sha256:62ce11e6…) are the integration fixture for this slice; production T40 still verifies against the real saved request and RunStore.

   Accepted — Harness implementer

   Implementer / accountable delivery owner: @Dong1017 (S2 Harness owner). PR authorship may be delegated; accountable review and delivery against this acceptance stay with the Harness owner. This does not treat the on-disk src/inferrsi/harness/ tree as the final accepted package boundary (#362 constraint unchanged).

   Status

   Flipping status:proposed → status:accepted for this bounded delivery. First CPU task family for cross-module pairing remains D023 / t108-v4 (same as #430/#434).
7. Dong1017

   added

   status:acceptedThe decision owner accepted it in a recorded commentThe decision owner accepted it in a recorded comment

   and removed

   status:proposedWaiting for the decision named in the status blockWaiting for the decision named in the status block

   on Nov 14, 2026