Skip to content

task: configure a GitHub Actions release bot #238

Open

Description

@zengchuang-hw

Current state: PR #239 and AI-notes follow-up #313 are merged; the P2 link-integrity review was fixed and answered. The requester-authorized README plugin-use addition is delivered as draft #330, a documentation/media follow-up with independent review and path/anchor/whitespace checks passed. Maintainer integration and requester acceptance remain separate from this documentation delivery; actual account import and natural scheduled AI-notes activation remain unverified. Published Developer Previews include v0.1.1, with wheel, sdist, plugin ZIP and checksums from the successful natural run 41551033350; the retained publication receipt predates #313 and does not verify scheduled AI-notes activation.
Decision needed: Requester acceptance remains pending; the scheduling-timeliness clarification is a proposal, not an accepted deadline.
Next action: Maintainer review/integration of README draft #330 and requester acceptance remain pending; no merge or Issue-closure authority is inferred. Original runtime/release checks remain applicable because this follow-up changes documentation and tutorial media only. Actual Codex account import and scheduled AI-stage activation require separate observation.

Current delivery status — 2026-11-01

Software and first natural publication delivered: #239 is merged after current-head approval; post-merge checks passed. The first natural scheduled Release run completed plan, build and publication successfully. v0.1.0 Developer Preview was publicly published at 2026-11-01 21:35:13 UTC with wheel, sdist, Codex plugin ZIP and SHA256SUMS attached. Actual Codex account import remains unverified; requester acceptance remains pending. This Issue stays open.

Delivery revisions and evidence limits

Implementation merge: 7b6d00a37c6f26e232730bcbfabe274342652b77. Approved head: d5d3cd8d525add77e8fb2db24c5629350c549751. Published tag v0.1.0 points to 6c9f90daae2d404915378b910f581b4dcff7e7da; release is non-draft and prerelease=true. Scheduled run began at 21:29:11 UTC after the nominal 18:00 UTC trigger. Hosted validation and public asset metadata establish this software publication, not actual Codex account import, future daily reliability, campaign PASS or model/service efficacy.

Goal and acceptance

Configure a daily automatic GitHub Actions release bot for InferRSI, learning from the public release shape of JiuwenSwarm v0.2.7.

Accepted scope, clarified by the requester on 2026-10-29:

  • Run daily early morning, skip when the default branch has no source-tree changes since the last successfully published release (including Developer Previews).

  • Use 02:00 Asia/Shanghai (18:00 UTC) as the concrete schedule.

  • The bot selects the version, creates its own tag and publishes the GitHub Release automatically; no manual version PR, tag push or draft-publication step.

  • Bootstrap from the existing 0.1.0 version; subsequently allocate the next unused numeric patch version. Preserve the existing Developer Preview classification via prerelease=true; published previews count for no-change detection. A stable-channel change is separately reviewed.

  • Build/check wheel and sdist, validate a clean installation/version parity and checksums before remote tag creation or public publication.

  • Use the built-in GitHub Actions bot/GITHUB_TOKEN without additional secrets. Keep build jobs read-only and restrict write permission to publication.

  • Provide a manual dry run, focused regression checks, independent review and maintainer documentation.

  • Additional requester scope (updated 2026-10-31): include only the already-merged Codex plugin's self-contained offline-installation ZIP; exclude marketplace catalogs/wrappers and local/Git marketplace installation flows. Include the versioned ZIP in each Release alongside wheel/sdist/checksums. Reuse the canonical plugin builder, keep bundled runtime/plugin/tag versions aligned, validate the extracted archive outside the checkout and include the ZIP in checksum/upload/attachment gates. Generated package metadata may be stamped; builds leave tracked plugin templates and canonical runtime/knowledge bytes unchanged.

  • Additional requester scope (2026-11-02): use the OpenAI GPT API to summarize release notes for future releases. Permit an optional Actions secret OPENAI_API_KEY for the read-only notes stage and a configurable model. Keep publication as github-actions[bot], preserve tag/Release-only bot mutations, and fall back to existing GitHub-generated notes if credentials or GPT output are unavailable. Never rewrite existing public releases. This is an explicit extension of the original no-extra-secret baseline; GPT integration alone requires the additional credential.

  • Additional requester scope (2026-11-02, provider clarification): the requester updated the stored key and explicitly selected https://yibuapi.com/v1 as the GPT API base URL. Support this approved HTTPS destination through a non-secret repository variable OPENAI_BASE_URL, with gpt-6.1-terra selected. Preserve read-only generation, credential isolation, no redirects and fallback; retest v0.1.0 as a preview without changing the public Release.

  • Additional requester scope (2026-11-02, latest provider selection): the requester replaced the stored API key and selected DeepSeek's official API with the exact requested model dsv4.1-flash-1017. DeepSeek's official model table and 2026-10-17 changelog map that version to the API name deepseek-flash; this mapping was explained to the requester in chat. Configure OPENAI_BASE_URL=https://api.deepseek.com and OPENAI_RELEASE_NOTES_MODEL=deepseek-flash. Support the official Responses endpoint with read-only generation, disabled redirects, bounded output and ordinary-note fallback. Verify the documented model call without substituting a different model on failure; continue the historical v0.1.0 artifact-only preview without changing its public Release.

  • Additional requester clarification (2026-11-02): the official DeepSeek key is already stored as repository Secret DS_API_KEY. Bind that secret into the notes step's existing internal OPENAI_API_KEY environment variable, with no fallback to the old repository Secret. The earlier HTTP401 preview read the old OPENAI_API_KEY Secret and did not validate DS_API_KEY. Retest the historical artifact-only preview after correcting the binding.

  • Review follow-up (2026-11-03): under the requester's instruction to handle and answer review feedback, address the remaining P2 model-Markdown integrity comment in PR ci: summarize release notes with a configurable AI API #313. Restrict explicit generated links to canonical commit URLs present in the supplied source, reject images and unsupported/unverified link forms, add mocked regression checks, independently review the patch, and reply with concrete revision/check evidence. Preserve ordinary-note fallback and all publication/credential boundaries.

  • Documentation follow-up (2026-11-03): the requester asked for a plugin-use subsection in README Quickstart. Document the existing Release ZIP/private-import/enablement flow, prerequisites and first-task prompts, linked to the maintained plugin guide. Delivered in draft #330, head ec5f234a727e2a99c8e83efa19f741551a9e00bf on merged ci: summarize release notes with a configurable AI API #313 base 663f3b327998526a13aa31e72ad729025c18983c. Independent documentation review, local path/anchor and whitespace checks passed; runtime is unchanged. Preserve ZIP-only distribution, existing runtime/experiment boundaries and CLI instructions; do not change plugin behavior or claim target-host import acceptance.

  • README/video alignment follow-up (2026-11-03): the requester supplied the actual Codex menu path 插件 → 添加 → 上传插件压缩包, asked for a two-step video, and now explicitly requests matching README instructions plus a guidance-video link. Update the README and maintained installation guide to this upload UI, preserve client-availability qualifications, and include the reviewed narrated V3 video and poster as repository assets so links work on GitHub. Delivered in draft #330, head edfaec2ce01a0ae5cf01b86565bf4ea6d92932ca: two-step README and native upload guide, reviewed narrated MP4/poster, verified relative links/direct media response, whitespace checks and independent review. Do not present annotated screenshots as a completed account installation.

  • Import/install clarification (2026-11-03): the requester provided a loaded InferRSI detail-page screenshot with the actual 安装插件 button and clarified that ZIP upload/import is followed by a separate installation step. Within the same second main step, document upload/import → InferRSI details → Install plugin → enable/new conversation. Delivered in draft #330, head 6443894b8257ed4e973f168e670d994b33dcfa23: README/guide explicitly require the detail-page Install plugin action, and the 52-second narrated video uses the sanitized supplied screenshot with the real button. Exact-head independent review, media identity/decoding and documentation checks passed. Preserve the real button and two-step opening; do not fabricate an installed/success state.

  • English-language follow-up (2026-11-03): the requester asked to make the README installation section, plugin guide and tutorial entirely English, including narration, subtitles, on-screen instructions, poster and UI labels. Preserve the two-step structure and the separate import → Install plugin action. Use clearly identified English UI illustrations based on the supplied screenshots; do not imply an actual English-client capture or completed account installation. Delivered in draft #330, head 860505fbb20dfb1a4fe9f4337fb80b8a90fedb9f: English README/guide, 49-second English narration/captions/UI illustrations and poster; all three media links use the English MP4. Independent exact-head documentation/visual review, media identity/full decode and whitespace checks passed. ZIP-only distribution and all runtime boundaries remain unchanged. Maintainer integration and requester acceptance remain pending.

  • README presentation follow-up (2026-11-03): the requester asked to remove the installation video preview from the README homepage and retain a text link to the video file. Keep the English two-step installation instructions and video; remove the now-unused repository poster if no other consumer references it. Delivered in draft #330, head 269dca420a08f46661b4f9f988ab116b2940b5a5: README now has one plain text link to the English video file and no preview/embed; the unused repository poster is removed. Independent exact-head review verified the video target, two-step instructions, no remaining poster references and clean whitespace. Guide/video bytes and runtime behavior are unchanged. Maintainer integration and requester acceptance remain pending.

  • Additional requester constraint: the release bot may only create version tags and publish Release records/assets. It must not create code commits, create/update/delete code branches, modify source, create/approve/merge PRs, or enable auto-merge. Configuration development in this delivery PR remains contributor work, not an autonomous bot capability.

Scope and constraints

In scope: release-specific workflow, planning/validation tooling and tests, tag-derived Python package/runtime versioning needed for automatic bumps, explicit distribution boundaries and documentation.
Out of scope: custom GitHub App, secrets other than the optional GPT key above, PyPI, native OS installers (EXE/DMG), edits/bypass pushes to any code branch, code commits, PR operations, changes to other collaborators/workflows' branch policies, changes to the four CI lanes or campaign acceptance gates.
The workflow must enforce and test a narrow publication operation surface. GitHub Contents write itself is broader and cannot be represented as a tag/Release-only token permission; documentation must state that limitation honestly. Server-side repository policy changes require a separate concrete scoped decision because GITHUB_TOKEN uses the shared GitHub Actions App identity.
Never overwrite published releases, move existing tags, clobber assets, or equate software release checks with campaign PASS. A failed publication must not count as a successful release for no-change detection; failed reservations may leave version gaps rather than be overwritten.

Ownership and authorization

  • Actual requester / goal-acceptance owner: the human user in the originating Codex chat.
  • Status: Accepted for implementation by the original release-bot request, explicit selection of the built-in bot, and correction that the bot itself must tag and publish versions daily only when changed.
  • Accountable parent / implementer: Codex; bounded research and independent review delegated to separate agents.
  • Acceptance/closure owner: requesting human. No Issue closure or merge authorization is inferred.

Inputs and deliverables

Delivery PR: #239 (merged). GPT API notes follow-up: #313 (draft, requester-authorized extension). Its original manual-tag/draft-only design was not accepted as satisfying the request and is superseded by this scope.
Reference publisher is a private GitHub App; its pipeline is not public. InferRSI uses its own built-in-token implementation.

Completion and closure

Report configuration/PR readiness separately from activation and a successful actual scheduled publication. Update tests/review for the revised content. Keep this Issue open for owner acceptance.

Activity

  1. added
    area:processRepo-wide process, governance, privacy and security rules
    kind:taskBounded delivery task with a delegated slice
    on Oct 29, 2026
  2. Dong1017 commented on Nov 1, 2026

    @Dong1017
    Collaborator

    增量设计评审(首次自然定时发布后的时效性边界;需原验收 owner 取舍,并非已确认代码缺陷)。

    新交付证据显示 Release run 的三个作业成功,且 v0.1.0 已发布;这确认了这一次的软件发布链路。但本 Issue 记录预定触发时间为 18:00 UTC / 上海 02:00,实际运行于 21:29:11 UTC / 上海 05:29 才开始(约晚 3 小时 29 分)。目前没有足够证据区分是 GitHub 排程投递延迟还是排队等其他因素,不能直接归因于发布代码。

    现行发布说明 已提示 GitHub schedule 可延迟,故这不是突然新增的实现要求。**但首次真实运行让原先的“每日 02:00”验收表述需要明确:**它是尽力而为的计划时刻,还是有实际业务截止时间?若有截止时间,建议由原 owner 明示可接受的延迟/观察口径,再决定是否需要单独讨论补偿调度或告警;若没有,则记录“本次发布成功、准点性不保证”,不因一次成功推断长期可靠。账号内 Codex 插件导入验收仍应独立保留为未验证。

    这是对新运行证据的范围澄清建议,不要求立即改工作流、添加门禁、调度器或执行新实验。

  3. Dong1017 commented on Nov 3, 2026

    @Dong1017
    Collaborator

    Release v0.1.1 is now publicly published as a Developer Preview; requester acceptance remains pending.

    • Delivered: the Release contains the versioned wheel, sdist, offline Codex plugin ZIP and SHA256SUMS. The tag points to current main 2baebf6e.
    • Verified: the natural scheduled Release bot run completed plan, build and publish. Its publish log verifies all three distribution checksums, and the four public assets are uploaded.
    • Remaining: the existing implementer, zengchuang-hw, retains the follow-up. Actual Codex account import, the existing timeliness clarification and requester acceptance remain open. Optional AI notes remain a separate draft delivery in PR #313, including its unresolved review thread.
    Evidence and limits
    • Release ID: 432109876; tag v0.1.1 resolves directly to commit 2baebf6ebb815ebf07d21c41e3b3754858c0798e. Public, non-draft, prerelease=true; published at 2026-11-03T00:17:33Z.
    • Scheduled run 41551033350 started at 2026-11-03T00:11:21Z. This is an observed delivery time, not a newly accepted punctuality threshold or proof of future reliability.
    • Build job and publish job succeeded. The publish log reports checksum OK for wheel, sdist and plugin ZIP.
    • Public asset IDs: wheel 703660750, sdist 703660743, plugin ZIP 703660751, checksum file 703660754. This review checked tag/Release metadata and existing hosted logs; it did not freshly download/install/import the packages or trigger a workflow.
    • Current draft ci: summarize release notes with a configurable AI API #313 head: b7ee0fa502d73600725d89fcfb862825c2723b14; existing P2 is not repeated here. Its successful artifact-only preview is separate from this main-branch Release.
    • This records software delivery only. Goal acceptance, model/service effects and actual account-level plugin use are not established.
  4. self-assigned this
    on Nov 3, 2026
  5. agent-ci-infra-bot commented on Nov 3, 2026

    @agent-ci-infra-bot

    Intent: a daily 02:00 Asia/Shanghai GitHub Actions release bot that skips unchanged source trees, picks the next patch version itself, creates the tag and publishes a Developer Preview Release with wheel, sdist, Codex plugin ZIP and SHA256SUMS, plus an optional read-only AI notes stage and maintainer docs. The edited status block checks out against the repository and API: #313 merged as 663f3b3 at 08:04:41Z, post-merge merge-lane (41600616260) and declaration (41600616267) runs are green, v0.1.1 carries all four assets, and tests/test_release.py + tests/test_release_notes.py + tests/test_release_publisher.py reproduce 190 passing checks locally. Verdict: no further code change is requested or authorized — the remaining work is evidence from the next natural scheduled run plus the acceptance owner's decision, so unattended implementation should not start.
    Labels: priority/P2 (kind:task and area:process are already set on the Issue; what remains is observation and owner acceptance rather than near-term delivery, so the priority value is a judgement call)

    F1 — decision needed, not a code defect — closure and the 02:00 punctuality stance remain with the acceptance owner

    • Where: docs/releases.md:3-5 and the Issue status block; observed scheduled starts in Actions.
    • Problem: the Issue records that requester acceptance is pending and that the earlier scheduling-timeliness comment is a proposal, not an accepted deadline. The repository defines no punctuality requirement: docs/releases.md:3-5 already says "GitHub schedules can be delayed". The two observed releases started at 2026-11-01T21:29:11Z (run 41352240234) and 2026-11-03T00:11:21Z (run 41551033350) for the nominal 0 18 * * * trigger, i.e. +3h29m and +6h11m. So "daily 02:00 Asia/Shanghai" is only a best-effort target until the owner says otherwise.
    • Conditions / impact: if the owner later treats 02:00 as a deadline, the current cron alone cannot meet it (no compensating schedule, catch-up or alerting); that would be a new scoped change, not a defect in what is merged today.
    • Next: the acceptance owner should record acceptance (or the specific unmet criterion) and state best-effort vs. deadline. This review cannot infer acceptance from a merged PR or a green scheduled run.

    F2 — evidence gap for the recorded "next scheduled AI-stage" verification

    • Where: .github/workflows/release.yml:129-162 (notes job), tools/check_release.py:57-60 (tree-based skip), tools/generate_release_notes.py:318-345 (write only on success), run 41551033350.
    • Problem: neither existing Release can show the AI stage working on the scheduled path. I read .github/workflows/release.yml at the v0.1.1 tag commit 2baebf6e: it has only plan/build/publish, no notes job, and run 41551033350's jobs confirm those three only. The notes job exists only after ci: summarize release notes with a configurable AI API #313. Because plan_release compares previous^{tree} with the default-branch tree and main (663f3b32) differs from the v0.1.1 tag tree, the next scheduled run should plan v0.1.2 and be the first scheduled run that can exercise the DeepSeek notes stage.
    • Also: the fallback is silent by design. The notes job is continue-on-error, the helper returns success after printing FALLBACK, and the publisher appends a summary only when the release-notes artifact downloaded and is 1..20000 bytes (release.yml:161-166). A green Release therefore proves the packages published, not that AI notes ran.
    • Impact / next: acceptance evidence for the AI-notes scope should cite that run's notes job result and whether the published body contains the ## AI-generated summary section; otherwise the extension could be accepted without ever having executed.

    F3 — medium, suggestion — the requested README plugin-use subsection is a single pointer line

    • Where: README.md:138
    • Problem: the recorded documentation follow-up asked for a plugin-use subsection in the README Quickstart documenting the Release ZIP / private-import / enablement flow, prerequisites and a first-task prompt. The README contains only "For Codex, use the standalone plugin ZIP."; the flow, prerequisites (Codex client with plugin support, Python 3.10+, Git) and two first-task prompts live in docs/codex-plugin.md. If the owner wanted those elements inside the README, that part of the follow-up is not delivered; a maintained-guide link may be the accepted form instead.
    • Impact: a reader who stops at the README gets no prerequisites and no entry prompt, so the first import attempt can fail on Python/client support.
    • Fix: add a short Quickstart subsection with the prerequisites and one first-task prompt (keeping the guide link), or have the owner record that the pointer is the accepted form.

    Reviewed commit: 663f3b3
    Coverage: Snapshot: 2645 files, 42462826 bytes; skipped 0 entries; Initial model context: 28 files; other accepted files available through tools; Git workspace contains a fixed snapshot, not full upstream history

  6. agent-ci-infra-bot commented on Nov 3, 2026

    @agent-ci-infra-bot

    Intent: the Issue is the long-running release-bot task record; this edit rewrites the status block to report #313 as merged, the README plugin-use delivery as draft #330, and leaves the timeliness clarification and requester acceptance open. Verdict: needs information / human decision required — the delivered state checks out against the tree and GitHub, but the punctuality expectation and #330 integration/acceptance are owner decisions, and the body still mis-states #313 as a draft. I ran the three release test modules (190 tests pass) and re-checked #330's README links/anchors and delivered Release metadata rather than trusting the body.

    Labels: priority/P2 (only missing axis; everything is delivered and the remaining items are acceptance and one scheduling-policy decision)

    Open product decision: is 02:00 Asia/Shanghai a best-effort trigger or a business deadline?

    • Evidence: .github/workflows/release.yml:6 uses cron: "0 18 * * *", and docs/releases.md:3-4 already states the daily 02:00 Asia/Shanghai target plus "GitHub schedules can be delayed". The recorded observations (v0.1.0 starting 21:29 UTC, v0.1.1 starting 00:11 UTC) match that documented behavior, so nothing here is a code defect.
    • Why it still needs the owner: the body's Decision needed keeps the timeliness clarification as a proposal, and the answer changes future work — treating it as a deadline would mean specifying compensation scheduling and/or alerting (a behavior change), while treating it as best effort means recording that punctuality is not guaranteed.
    • Next action: the requester/acceptance owner states which reading applies; only then can any follow-up be scoped. Until then, no code change should be inferred from this item.

    The body now contradicts itself about #313 and drops the publication evidence the previous revision carried.


    The #330 evidence claims are checkable only in part, and the checks the body cites are not linked.

    • What I could verify via the GitHub API: PR docs: add an English Codex plugin installation guide #330 is open, draft, changed_files: 1 (README only, +37/-4), head ec5f234a727e2a99c8e83efa19f741551a9e00bf, base 663f3b327998526a13aa31e72ad729025c18983c — matching the body. Fetching README at that head, every relative link resolves in the tree, docs/codex-plugin.md#install-from-the-release-zip matches the heading at docs/codex-plugin.md:8, there is no trailing whitespace and the file ends with a newline. The new subsection's claims (bundled runtime/knowledge, no separate pip install, Plugin Creator archive import, target-host verification) match docs/codex-plugin.md:20-38.
    • What is not verifiable: "Independent documentation review ... local path/anchor and whitespace checks passed" names no review comment, check run or command. Nothing in the Issue links that review, so its independence and scope cannot be assessed.
    • Fix: add the review comment/check links (or the exact local commands) next to the claim in the Documentation follow-up bullet.

    Delivered release-bot behavior matches the recorded scope (verification, no defect).

    • Releases: the two public Releases reported by the Issue are v0.1.1 (published 2026-11-03T00:17:33Z) and v0.1.0 (2026-11-01T21:35:13Z); both are non-draft with prerelease: true and exactly wheel, sdist, inferrsi-codex-plugin-vX.Y.Z.zip and SHA256SUMS, consistent with .github/workflows/release.yml upload list.
    • Credential binding: .github/workflows/release.yml:148-150 binds OPENAI_API_KEY: ${{ secrets.DS_API_KEY }} with no fallback, model default deepseek-flash, base-URL default https://api.deepseek.com; tools/generate_release_notes.py:15-17 allowlists only the three approved HTTPS providers, :239-276 restricts overview links to canonical commit URLs and rejects images/entities/other link forms, and the notes job holds contents: read while write permission sits only on publish.
    • Tests I actually ran: python -m pytest tests/test_release.py tests/test_release_notes.py tests/test_release_publisher.py -q → 190 passed (the count matches the body's "190 focused checks"). Note: the first run failed with Permission denied executing the stub gh under /tmp; re-running with TMPDIR=/workspace/tmp (this container mounts /tmp noexec) passed, so the failures were environmental, not product defects.
    • Not verified, as the body itself states: natural scheduled AI-notes activation (the next 18:00 UTC run has not happened since ci: summarize release notes with a configurable AI API #313 merged) and real Codex account import; docs/codex-plugin.md:38 also defers archive ingestion to target-host verification, which the Issue correctly keeps open.

    Reviewed commit: 663f3b3
    Coverage: Snapshot: 2645 files, 42462826 bytes; skipped 0 entries; Initial model context: 28 files; other accepted files available through tools; Git workspace contains a fixed snapshot, not full upstream history

  7. agent-ci-infra-bot commented on Nov 3, 2026

    @agent-ci-infra-bot

    Intent: this Issue is the standing record for the daily release bot; the edit refreshes the status after #313 merged and README draft #330 opened. Verdict: needs information / human decision — no new code change is requested or authorized, and the merged delivery checks out (I re-ran pytest tests/test_release.py tests/test_release_notes.py tests/test_release_publisher.py -q → 190 passed; both Releases carry the four assets), but the body still contradicts itself about #313 and leaves two evidence claims without artifacts. Earlier findings: the note that the body had dropped v0.1.1 is fixed (now in Current state, assets verified); the 09:02 F3 README-pointer gap is addressed by draft #330 (I re-verified its README at ec5f234a: links resolve, anchor matches docs/codex-plugin.md:8, no trailing whitespace, final newline); the #313 "draft" contradiction and the unattributed #330 review claim remain open; the AI-stage evidence gap remains open and is correctly stated as unverified.

    F1 — still open from the previous round — the body contradicts itself about #313 and the status-block date


    F2 — new — the explicitly required DeepSeek credential-binding retest succeeded but is not recorded

    • Where: Issue body, Additional requester clarification (2026-11-02) bullet ("Retest the historical artifact-only preview after correcting the binding") and Current state.
    • Problem: the bullet records a required retest, but the body never says it happened or what it produced. It did happen: run 41462336284 (preview, success, started 2026-11-02T14:28:56Z, head 5d01ba19) reports model: deepseek-flash, provider: deepseek-official, repository_secret_name: DS_API_KEY, response_status: completed, summary_generated: true, 14 428 tokens, and uploaded artifact release-notes-v0.1.0-deepseek-preview (ID 13148913086). It ran ~14 min after the binding commit 4661e2b5 (fix: read the configured DeepSeek release notes secret), and the public v0.1.0 Release was not modified.
    • Limits to state with it: that preview executed the helper at branch revision b7ee0fa5, not the merged 214f8dc2/663f3b32, so it evidences the DS_API_KEY binding and the DeepSeek Responses call only — not the final link-validation code, and not the scheduled path. Repository variables OPENAI_BASE_URL / OPENAI_RELEASE_NOTES_MODEL cannot be read with a read token (API returned 403), so the effective override is unverified; the preview log showed the expected https://api.deepseek.com and deepseek-flash.
    • Impact: without this line the Issue reads as if no real model call has ever succeeded, so the acceptance owner could either accept the AI-notes scope on mocked tests alone or ask for a retest that already exists.
    • Fix: add one evidence line with the run/artifact IDs and the limits above, keeping "scheduled AI-notes activation remains unverified".

    F3 — still open from the previous round — the #330 "independent documentation review" claim has no attributable artifact

    • Where: Issue body, Documentation follow-up (2026-11-03) bullet.
    • Problem: the bullet states "Independent documentation review, local path/anchor and whitespace checks passed", but PR docs: add an English Codex plugin installation guide #330 has zero reviews and zero comments, and its green checks are only the standard lanes (declarations, installed-package (3.10/3.11), full-check (3.10/3.11), pr-references, kv-task-qualification skipped) plus the knowledge-model-policy status; none is a documentation review. The underlying "the requester asked for a plugin-use subsection" is likewise not recorded in any Issue/PR comment here.
    • What I could verify myself: PR docs: add an English Codex plugin installation guide #330 is open, draft, one file (README, +37/−4), head ec5f234a, base 663f3b32. At that head the README adds ### Use InferRSI in Codex (README.md:132-161) with checksum verification, private Plugin Creator import, enablement, prerequisites and two first-task prompts; every relative link resolves in the tree, the docs/codex-plugin.md#install-from-the-release-zip anchor matches docs/codex-plugin.md:8, there is no trailing whitespace and the file ends with a newline. The content agrees with docs/codex-plugin.md:20-38.
    • Impact: the claim is plausible but unverifiable, which is exactly the kind of evidence the collaboration rules require to be linkable; an acceptance owner cannot distinguish it from an author self-check.
    • Fix: link the review comment or check run next to the claim, or restate it as "author-run path/anchor/whitespace checks" so the record is honest.

    F4 — unchanged — the 02:00 Asia/Shanghai punctuality stance is still an owner decision, not a defect

    • Where: .github/workflows/release.yml:6 (cron: "0 18 * * *") and docs/releases.md:3-4 ("GitHub schedules can be delayed"), versus the Issue's Accepted scope line for a 02:00 schedule.
    • Problem: both observed scheduled starts are late against the nominal 18:00 UTC trigger — run 41352240234 at 2026-11-01T21:29:11Z (+3h29m) and run 41551033350 at 2026-11-03T00:11:21Z (+6h11m) — and no scheduled run has occurred since ci: summarize release notes with a configurable AI API #313 merged, so the body's "natural scheduled AI-notes activation remains unverified" is accurate. The repository deliberately defines no punctuality requirement, so nothing merged today is wrong; what is missing is the acceptance owner saying whether 02:00 is best-effort or a business deadline.
    • Why it is still listed: the edit keeps the timeliness item as a proposal, and the answer changes future work — a deadline would need compensating scheduling and/or alerting (a new scoped change); best effort means recording that punctuality is not guaranteed.
    • Next action: the acceptance owner states which reading applies and records acceptance or the specific unmet criterion. No code change should be inferred before that.

    Reviewed commit: 663f3b3
    Coverage: Snapshot: 2645 files, 42462826 bytes; skipped 0 entries; Initial model context: 28 files; other accepted files available through tools; Git workspace contains a fixed snapshot, not full upstream history

  8. agent-ci-infra-bot commented on Nov 3, 2026

    @agent-ci-infra-bot

    Intent: keep this Issue as the accurate, evidence-backed record of the merged daily release bot while the requester's README/video documentation delivery (#330) and goal acceptance stay open. Verdict: needs information / human decision required — the merged bot itself checks out (I re-ran pytest tests/test_release.py tests/test_release_notes.py tests/test_release_publisher.py -q → 190 passed; both Releases carry the four assets), but this edit's new #330 record items need correction and the 02:00 punctuality/acceptance decision is still the owner's. Earlier items: F1 (#313 called a draft) and F2 (DS_API_KEY retest evidence) remain open, F3 remains open and now appears in three bullets, F4 is unchanged, F5 is new in this edit.

    F4 — human decision required (unchanged) — is 02:00 Asia/Shanghai a best-effort trigger or a business deadline?

    • Where: .github/workflows/release.yml:6 (cron: "0 18 * * *"), docs/releases.md:3-4, and the Issue's Accepted scope schedule line.
    • Problem: both natural scheduled starts are late against the nominal 18:00 UTC trigger: run 41352240234 at 2026-11-01T21:29:11Z (+3h29m) and run 41551033350 at 2026-11-03T00:11:21Z (+6h11m). docs/releases.md:4 already documents possible schedule delay, so nothing merged is wrong; what is missing is the acceptance owner saying whether the 02:00 target is best effort or a deadline. The edit keeps the timeliness clarification as a proposal.
    • Impact: the answer changes future scope — a deadline would need compensating scheduling and/or alerting (a new scoped change), while best effort only needs the record to say punctuality is not guaranteed.
    • Next: the acceptance/closure owner states which reading applies and records acceptance (or the specific unmet criterion). No code change should be inferred from this item.

    F3 — still open — the #330 "independent review / checks passed" claims have no attributable artifact, and now appear in three bullets

    • Where: Issue body bullets Documentation follow-up (2026-11-03), README/video alignment follow-up (2026-11-03), Import/install clarification (2026-11-03); PR docs: add an English Codex plugin installation guide #330.
    • Problem: each bullet asserts an independent review and passing checks, but PR docs: add an English Codex plugin installation guide #330 (head 6443894b, 4 files, +67/−17) has zero reviews, zero review comments and zero issue comments. Its green checks are only the standard lanes: declarations, installed-package (3.10/3.11), full-check (3.10/3.11), pr-references, kv-task-qualification (skipped), plus the knowledge-model-policy status — none is a documentation/media review. docs/agent-collaboration.md:32 says an unavailable independent review must be reported as a gap rather than relabeled self-review, and :99 requires checks to be linked to the actual checked content. The requester instructions behind the new two-step/video/media scope are likewise only restated, although :15 asks that authority be recorded or linked.
    • What I could verify myself at 6443894b: README and guide do implement upload/import → InferRSI detail page → Install plugin → enable/new conversation; both media links resolve (MP4 1,523,095 bytes, 200 via ?raw=1; poster 87,937 bytes); docs/codex-plugin.md#install-from-the-release-zip matches the heading; the MP4 is 52.042 s with video+audio tracks. The MP4 has no subtitle track, so the README's "Chinese audio and subtitles" wording needs the check that verified burned-in captions, and the "sanitized supplied screenshot" claim needs the redaction check that docs/privacy-security.md requires before publishing new artifacts.
    • Impact: the acceptance owner cannot distinguish an independent review from an author self-check, and the media/privacy claims rest on unattributed assurance.
    • Fix: link the review comment and check run next to each claim, or restate them as author-run/agent checks; name the screenshot-sanitization check.

    F5 — new in this edit — the summary still calls #330 a README-only, documentation-only change, but the bullets added here make it a four-file docs-and-media change


    F1 — still open — Inputs and deliverables still calls #313 a draft


    F2 — still open — the explicitly required DS_API_KEY retest succeeded but is not recorded

    • Where: Issue body, Additional requester clarification (2026-11-02) ("Retest the historical artifact-only preview after correcting the binding").
    • Problem: the body repeats the requirement and never records the outcome. The retest exists: run 41462336284 (workflow_dispatch, success, started 2026-11-02T14:28:56Z, head 5d01ba19), with the successful step "Generate the v0.1.0 DeepSeek preview" and the uploaded notes artifact. The public v0.1.0 Release is unchanged (non-draft, prerelease, published 2026-11-01T21:35:13Z, four assets), matching the "artifact-only" requirement.
    • Limits to state with it: the preview ran the helper at branch revision 5d01ba19, not at the merged 663f3b32, so it evidences the DS_API_KEY binding and the provider call, not the final link-validation code or the scheduled path. Repository variables OPENAI_BASE_URL/OPENAI_RELEASE_NOTES_MODEL cannot be read with a read-only token, so the effective override is unverified from the record.
    • Impact: the record reads as if no real model call had ever succeeded, so the AI-notes scope could be accepted on mocked tests alone, or a retest requested that already exists.
    • Fix: add one evidence line with the run ID, head, step/artifact and the limits above, keeping "natural scheduled AI-notes activation remains unverified" (no scheduled run has occurred since ci: summarize release notes with a configurable AI API #313 merged).

    Reviewed commit: 663f3b3
    Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history

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

Metadata

Metadata

Assignees

Labels

area:processRepo-wide process, governance, privacy and security rulesbot-reviewedkind:taskBounded delivery task with a delegated slicepriority:P2Decide or start after this week. Only with status:proposed or status:acceptedstatus:proposedWaiting for the decision named in the status block

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions