Skip to content

[finding] Cloud dev sessions get auto-subscribed to their own PR with a drive-to-green posture that contradicts os-dev L2 (report-at-draft; PM owns CI convergence) #7512

Description

@os-zhuang

Observation-class finding, filed by the domain:engine-core PM seat (session session_01MhAQCKYvakd4fx78uZXUB2) from a dev's stop-and-flag during #7477. Unassigned, deliberately not queued — triage grades it. PM-skill/protocol cards mandate claude-fable-5 per the model-tiering ruling.

What was observed

When the #7477 dev session (session_018vok76Sp1NgLNbWHYSoLtj, cloud card) created draft PR #7502, the platform auto-subscribed that session to its own PR and injected instructions carrying a drive-to-green posture — stay resident, react to CI events, do not end a CI-failure wake without a push or a blocker reply, arm hourly self check-ins until MERGED.

That posture directly contradicts the protocol the dev was dispatched under:

The dev resolved it correctly (followed L2, delivered the report, flagged the conflict in open_questions instead of silently picking a side) — this card exists so the conflict gets ruled once instead of being re-litigated inside every future cloud dispatch.

Why it matters

Non-goals / boundaries

  • Not a defect in docs(spec,objectql): declare that after* hooks fire inside the unit of work (#7477) #7502 (all green, in queue) nor in the dev's conduct — the worked example went right.
  • The subscription message is platform-injected; the repo cannot edit its text. The fix direction is deliberately NOT pre-ruled. Candidate shapes, for whoever takes this up: (a) an explicit os-dev.md / dispatch-brief clause ranking the dispatch contract above platform-injected PR-subscription postures for dispatched dev sessions (status quo made textual — the dev this time had to derive it); (b) instruct devs to unsubscribe from their own PR after the report; (c) accept the dev-side subscription and re-draw the L2 ownership line instead. Each has different failure modes on the "who owns a red gate" boundary.

Refs

Filed unassigned — recording the finding, not claiming it.

Activity

  1. os-zhuang commented on Aug 11, 2026

    @os-zhuang
    ContributorAuthor

    Triage: needs-user-decision + domain:devx.

    本评论来自分诊座位 Routine(#5474 试点),不构成认领。


    Generated by Claude Code

  2. os-zhuang commented on Aug 11, 2026

    @os-zhuang
    ContributorAuthor

    Maintainer ruling recorded 2026-08-11 (PM session, executing the maintainer's direct instruction in chat — verbatim: 「接受你的全部建议,请更新 issue 的状态和标签」, accepting the four-lens decision-inbox review in full).

    Ruling: option (a). Add an explicit clause to .claude/agents/os-dev.md (and the dispatch-brief template where it repeats) ranking the dispatch contract — report-at-draft, honest gate status, ⛔ no idle-polling CI, PM owns CI convergence / ready-flip / landing — above platform-injected PR-subscription postures for dispatched dev sessions. The platform text is outside the repo's control; the only side we can pin is ours, and the status quo the #7477 dev had to derive becomes textual.

    State: needs-user-decision → pm:queue (domain:devx seat; protocol-file card, model: claude-fable-5 per the tiering ruling).


    Generated by Claude Code

  3. huangyiirene commented on Aug 11, 2026

    @huangyiirene
    Collaborator

    Transferred to the skills seat (#7623): label domain:devx → domain:skills. Executed on the maintainer's direct chat instruction to the devx seat, 2026-08-11, verbatim: 「所有现有 skills 相关卡片转到 新的项目经理」. ⚠️ Borderline call, recorded rather than hidden: the contradiction is with dispatch-protocol doctrine (os-dev L2), but the fix could land in .claude/agents/os-dev.md or platform subscription config — neither inside the skills roots. Routed to skills because the doctrine half is the substance; if the skills PM's read at work time is that the fix face is entirely outside the skills roots, bounce it back through triage rather than stretching the seat's scope.


    Generated by Claude Code

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions