Skip to content

Stage 3 P1: the handoff pool runs in shadow, verdicts recorded, nothing gated #1862

Closed

Description

@Birfy

Written-by: Chief

Stage 3 P0 (#1853, PR #1857) writes the seven handoff validations as one pure contract with tests and wires nothing. P1 is the shadow step: the pool computes and records a verdict for a real pull request while the existing PR fast lane still decides, so the pool's answer can be compared with the human path before anything depends on it.

Scope

  • plugins/workflow/: a shadow pass that takes an open pull request, runs the P0 contract over its handoff inputs, and records shadow: <verdict> on the run record and in the run's own comment — it never blocks, never enqueues, never merges.
  • core/src/host/: no behaviour change; a seam only if the plugin needs the board read.
  • Tests: a shadow verdict on a fixture handoff that the P0 contract rejects, and the same pull request still merging on the human path.
  • docs/subsystems/workflow.md in the same pull request (owned path).

Depends on

#1853 / PR #1857 merged first (the contract must be in main).

Acceptance

TZ=UTC npm run verify green; one real pull request carries a shadow verdict and still merges through the queue untouched.

Tier

T2 (plugins/**) — PASS at the tip plus green tests-ok.

Activity

  1. Birfy commented on Oct 30, 2026

    @Birfy
    CollaboratorAuthor

    Written-by: Project Assistant (FlyBot 开发)

    前置核对(本评论时间读取 GitHub API):

    本评论只记事实,不改任何标签;agent-ready 与否由 Triage 判。

  2. Birfy commented on Oct 30, 2026

    @Birfy
    CollaboratorAuthor

    Written-by: Triage

    判定:agent-ready(promote) — 三条判据全中。读盘 2026-10-30T17:33Z,main 21e4880e;本单无开放 PR、评论 0、无 hold。

    判据 1(设计冲突已闭):前件 #1853 / PR #1857 已于 17:07:26Z 合入(merge commit 9a0b7c8f),main 上有 plugins/workflow/src/pool-contract.js(blob 611c8129b0)与 plugins/workflow/test/pool-contract.test.js;Stage 3 由所有者 2026-10-30 拍板(#1853 正文引用),P1 的形状就是"记录 shadow 判决、什么都不拦",没有待所有者决定的问题。

    判据 2(范围清楚)

    • plugins/workflow/:新增一次只读的 shadow pass(建议新 src/shadow.js,或在 service.js 的 assign / 派发处调一次;pool-contract.js 不动)。输入是该 run 的 handoff 输入,即 validateHandoff(handoff, ctx) 已经吃的那组事实(card / fromRole / toRole / attempt + acceptance / PR 事实);输出在 run 记录上加 shadow: { verdict, code?, reason? }(今天 blankRun() :137-152 没有这个字段),并经 push()(:298)在该 run 自己的 stage 日志里落一行 shadow: …。
    • 只记录、不判:validateHandoff 的返回值不被 service.js 任何"是否继续 / 是否拒"的判断读取;不入队、不合 PR、不发 PR 评论;shadow 为 reject 时 run 与卡照原样走。
    • core/src/host/:只在插件读板确实需要时加 seam,否则不动(正文原话)。
    • docs/subsystems/workflow.md 同 PR(owned path;在 "Pool contract (Stage 3 P0: the seven handoff validations as one pure contract and its tests (nothing wired) #1853)" 一节后补 P1 的读法)。
    • 测试:新增 plugins/workflow/test/shadow.test.js。

    红先怎么写:先提测试、函数还不存在 → 红(1 file failed,# fail 1)。变绿后三个用例:

    1. 契约会拒的 fixture handoff(如 cycle-budget,或 acceptance 要求 tests-ok 而 PR 没有绿)→ run 记录出现 shadow.verdict === 'reject' 与 code,run 的 status / steps 与今天一致;
    2. 契约通过的 handoff → shadow.verdict === 'pass';
    3. shadow 开着时 run 照今天的路径走完,且对 rt / fb 打桩断言零次 enqueue / merge / PR 评论调用。

    验收命令:cd plugins/workflow && node --test test/shadow.test.js;TZ=UTC npm run verify(动了 core/ 就再加 node scripts/ds-bot-patches.mjs check)。上线后一条真 PR 带 shadow: 且照常走合并队列,是 PR 正文里写明的 live check。

    判据 3:非 hold、非 tracking / umbrella(#1550 是提案,本单是它的 P1 切片)、非组间工作。
    Tier:T2(plugins/**;plugins/*/test/** 单独是 T1),要 tip 上 PASS + 绿 tests-ok。

  3. added
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 30, 2026
  4. Birfy commented on Oct 30, 2026

    @Birfy
    CollaboratorAuthor

    Written-by: Triage

    Promoted to agent-ready — three criteria checked at 2026-10-30T17:41Z. Dependency verified live: PR #1857 (Fixes #1853) merged 2026-10-30T17:07:26Z as 9a0b7c8f9e1949bd7293c47d7d9a53402a073894; plugins/workflow/src/pool-contract.js (7,856 bytes) and plugins/workflow/test/pool-contract.test.js are on main, and #1853 is closed.

    Files to change:

    • plugins/workflow/src/ — one new module for the shadow pass (for example pool-shadow.js): take an open pull request, run the P0 contract (pool-contract.js) over its handoff inputs, and record shadow: <verdict> on the run record. The existing run path calls it; no other behaviour changes.
    • the run's own comment carries the same one-line shadow: <verdict> — not a Verdict: block, so it can never be read as a conclusion.
    • core/src/host/ — no behaviour change; add a read seam only if the plugin cannot get the board read otherwise, and say so in the PR.
    • plugins/workflow/test/pool-shadow.test.js — new.
    • docs/subsystems/workflow.md (owned path) in the same PR.
    • changelog.d/1862-*.added.md (user-visible).

    Red first: fixture handoffs — one the P0 contract rejects, one it accepts — and run
    cd plugins/workflow && node --import ./test/resolve.mjs --test test/pool-shadow.test.js
    before the shadow pass: the run record and its comment carry no shadow: line (red). After it: the rejected fixture records its own verdict, the accepted one records its own, and neither changes the human-path decision.

    Acceptance at the tip:

    • cd plugins/workflow && node --import ./test/resolve.mjs --test test/pool-shadow.test.js — green; reverting the shadow module turns it red.
    • TZ=UTC npm run verify — green.
    • Boundary stays exactly as written: record only — never blocks, never enqueues, never merges, and the PR fast lane still decides. Put in the PR body the pair of facts that one real open pull request carries the shadow: line and still merges through the queue untouched.
  5. removed
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:automationScheduled tasks and automationenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions