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 ready-for-review #330, with its reported shipped-README video-link blocker still open. The first post-#313 natural scheduled run 41732940287 completed plan/build/notes/publish and published v0.1.2 Developer Preview from 663f3b32 at 2026-11-03 22:47:57 UTC, with wheel, sdist, plugin ZIP and checksums. The recorded observation verifies the notes job's successful generation path, hosted checksum checks and public AI summary plus GitHub changelog. Natural scheduled AI-notes activation is therefore observed for this run, superseding the earlier unverified status; no binary download/install, provider identity, usage or cost claim is implied. The run began 4 h 41 m after the nominal trigger, so punctuality and future daily reliability are not established. Existing contributor @zengchuang-hw, requester acceptance, actual client installation and the separate #330 integration/blocker remain unchanged.
Decision needed: Requester acceptance remains pending; the scheduling-timeliness clarification is a proposal, not an accepted deadline.
Next action: The #330 author should address the reported broken video link in the shipped plugin README at head 269dca420a08f46661b4f9f988ab116b2940b5a5, then obtain current-head review. This is a reported packaging/documentation blocker, not an independent reproduction here. Maintainer integration of the ready-for-review docs/media PR #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 remains unverified; scheduled AI-stage activation is observed for v0.1.2, while future reliability and the scheduling-timeliness decision remain open.

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

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

    @agent-ci-infra-bot

    Intent: keep Issue #238 as the accurate, evidence-backed record of the merged daily release bot while the README/video delivery (#330) and goal acceptance stay open. Verdict: needs information / human decision required — this edit fixes the scope wording (F5 fixed: #330 is now described as a docs/media follow-up; at head 269dca42 it is 3 files, every relative README link resolves, the docs/codex-plugin.md anchor matches, whitespace is clean and no poster remains), but F1–F3 remain open record defects and F4 is unchanged, so no code change is requested or authorized. I re-ran pytest tests/test_release.py tests/test_release_notes.py tests/test_release_publisher.py -q on this snapshot → 190 passed. Earlier findings: F1 open, F2 open, F3 open (now six references), F4 unchanged/human decision, F5 fixed (the Next action phrase "README draft #330" is only shorthand since the scope sentence now names docs and media).

    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 delay, so nothing merged today is wrong; the missing item is the acceptance owner's reading, and this edit still 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 state that 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.

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


    F3 — still open — the #330 "independent review / checks passed" claims have no attributable artifact and now appear six times

    • Where: Issue body Current state plus the five 2026-11-03 follow-up bullets; PR docs: add an English Codex plugin installation guide #330.
    • Problem: at head 269dca42 PR docs: add an English Codex plugin installation guide #330 has zero reviews, zero review comments and zero issue comments. Its green checks are only the standard lanes (declarations ×2, 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-33 says an unavailable independent review must be reported as a gap rather than relabelled self-review, and :99 requires checks to be linked to the actual checked content. The requester instructions behind the video/English/poster-removal bullets are likewise only restated, not linked.
    • What I could verify myself at 269dca42: 3 files (README.md +44/−5, docs/codex-plugin.md +20/−13, docs/assets/inferrsi-codex-install-en.mp4 1,398,314 B); every relative README link resolves (contents API 200), docs/codex-plugin.md#install-from-the-release-zip matches the heading at docs/codex-plugin.md:8, there is no trailing whitespace, the files end with a newline, and there is no remaining poster reference. So the text checks are reproducible, but the independent-review and "media identity/full decode" claims are not.
    • Impact: the acceptance owner cannot distinguish an independent review from an author self-check, and the media/privacy assurance cannot be assessed.
    • Fix: link the review comment/check run next to each claim, or restate them as author/agent-run checks and name the screenshot-sanitization check.

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

    • Where: Issue body, Additional requester clarification (2026-11-02) ("Retest the historical artifact-only preview after correcting the binding").
    • Problem: the bullet repeats the requirement and the body never records the outcome. It 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 uploaded artifact release-notes-v0.1.0-deepseek-preview (1,651 B, not expired). 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 merged 663f3b32, so it evidences the DS_API_KEY binding and the provider call only — 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 overrides are unverified from the record.
    • Impact: the record reads as if no real model call has 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".

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

  10. 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 docs/media delivery #330 and goal acceptance remain open. Verdict: needs information / human decision required — this edit correctly flips #330 to ready-for-review (verified draft: false at head 269dca42) and reports the unresolved shipped-README video link, and the merged bot still checks out (I re-ran pytest tests/test_release.py tests/test_release_notes.py tests/test_release_publisher.py → 190 passed on 663f3b32), but the #313 "draft" contradiction and the unrecorded DS_API_KEY retest remain, and the 02:00 punctuality/acceptance decision is still the owner's, so no code change is requested or authorized. Earlier findings: F3 is resolved (an attributable independent review, review 5752430228 by Dong1017 at head 269dca42, now exists and the body records the reported blocker r4454929027), F5 stays fixed, F1/F2/F4 are still open.

    F4 — human decision required (unchanged) — is 02:00 Asia/Shanghai a best-effort trigger or a business deadline, and has the goal been accepted?

    • Where: .github/workflows/release.yml:6 (cron: "0 18 * * *"), docs/releases.md:3-4, and the Issue's Current state / Decision needed.
    • Problem: both known natural scheduled starts are late against the nominal trigger — run 41352240234 at 2026-11-01T21:29:11Z (+3h29m) and run 41551033350 at 2026-11-03T00:11:21Z (+6h11m) — while docs/releases.md:4 already says GitHub schedules can be delayed, so nothing merged is wrong. The body's Decision needed still records the timeliness clarification as a proposal, not an accepted deadline.
    • Also current: no Release workflow run exists after ci: summarize release notes with a configurable AI API #313 merged at 2026-11-03T08:04:41Z (latest is 41551033350, started 00:11:21Z; the next slot is 18:00 UTC), so "natural scheduled AI-notes activation remains unverified" is accurate.
    • 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 state that punctuality is not guaranteed. Requester acceptance of the goal is likewise unrecorded.
    • 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.

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


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

    • Where: Issue body, Additional requester clarification (2026-11-02) ("Retest the historical artifact-only preview after correcting the binding").
    • Problem: the bullet repeats the requirement and the body never records the outcome. It exists: run 41462336284 ("DeepSeek release notes preview for v0.1.0", workflow_dispatch, success, started 2026-11-02T14:28:52Z, head 5d01ba19), with artifact release-notes-v0.1.0-deepseek-preview (1,651 B, not expired). 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: that preview ran the helper at branch revision 5d01ba19, not at merged 663f3b32, so it evidences the secret binding and the provider call only — not the final link-validation code, not the scheduled path. Repository variables OPENAI_BASE_URL/OPENAI_RELEASE_NOTES_MODEL cannot be read with a read-only token (403), so the effective overrides are unverified from the record.
    • Impact: the record reads as if no real model call has 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, artifact and the limits above, keeping "natural scheduled AI-notes activation remains unverified".

    F5 — new in this edit — five bullets still link [draft #330], and "checks passed" now sits next to the blocked shipped-README link

    • Where: Issue body bullets Documentation follow-up, README/video alignment follow-up, Import/install clarification, English-language follow-up, README presentation follow-up (all link [draft #330]), versus Current state ("ready-for-review docs: add an English Codex plugin installation guide #330 ... path/anchor/whitespace checks passed").
    • Problem: docs: add an English Codex plugin installation guide #330 is no longer a draft (draft: false, head 269dca420a08f46661b4f9f988ab116b2940b5a5, 3 files: README.md +44/−5, docs/codex-plugin.md +20/−13, docs/assets/inferrsi-codex-install-en.mp4), so the five [draft #330] links describe the PR's current state wrongly. Separately, "path/anchor/whitespace checks passed" now reads next to a known dead path.
    • What I verified about the new blocker (it is real): docs/codex-plugin.md is copied verbatim into the plugin archive as inferrsi/README.md (tools/build_codex_plugin.py:75), and check_plugin allows only plugin.json, skills, runtime, LICENSE, README.md under the plugin root (tools/check_release.py:124), so the repository-relative assets/inferrsi-codex-install-en.mp4?raw=1 link at docs/codex-plugin.md:38 is dead inside the ZIP. Merging docs: add an English Codex plugin installation guide #330 as-is would ship that dead tutorial link in every ZIP from the next scheduled Release onward. Your Next action correctly reports it (comment r4454929027 at that head) and correctly labels it as reported rather than reproduced here.
    • Fix: replace [draft #330] with the PR link, scope the check claim to GitHub-rendered links, and keep the shipped-README link fix as an explicit merge condition for docs: add an English Codex plugin installation guide #330.

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

  11. Dong1017 commented on Nov 3, 2026

    @Dong1017
    Collaborator

    The first post-#313 natural scheduled release now includes AI-generated notes: v0.1.2 is published as a Developer Preview.

    • The scheduled run completed plan/build/notes/publish, and attached the wheel, sdist, Codex ZIP and SHA256SUMS. Hosted publication verified all three artifact checksums.
    • The notes job reports successful generation, and the public Release contains the AI summary plus the GitHub changelog. This supersedes the current “natural scheduled AI-notes activation remains unverified” status for this one run.
    • @zengchuang-hw remains the existing contributor; requester acceptance and the recorded scheduling-timeliness decision remain open. The run started 4 h 41 m after the nominal trigger, so this observation does not establish punctuality. The separate docs: add an English Codex plugin installation guide #330 docs/media blocker and actual client-installation evidence remain outstanding.
    Evidence and limits

    Scheduled run 41732940287 started 2026-11-03T22:41:10Z. Run head, actual main and the verified v0.1.2 tag target are 663f3b327998526a13aa31e72ad729025c18983c. Release published at 2026-11-03T22:47:57Z, prerelease=true, draft=false.

    Notes job 126257711553 logged “AI release overview generated.” and uploaded the release-notes artifact (ID 13278273685). The observed request configuration was deepseek-flash at the DeepSeek endpoint; no response-model identity, token usage or cost is inferred. The checked source emits that success message after generation/link validation; this is distinct from its fallback branch.

    Publish job 126257839347 logged OK for wheel/sdist/Codex ZIP checksums. Public asset metadata was read back; this review did not independently download/install the binary artifacts, regenerate notes, dispatch a workflow or call a provider.

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

    @agent-ci-infra-bot

    Intent: keep #238 as the accurate, evidence-backed record of the merged daily release bot while the #330 docs/media delivery and requester acceptance stay open, now that the first post-#313 scheduled run produced AI notes. The new comment checks out against GitHub: v0.1.2 is non-draft/prerelease with tag->663f3b32, scheduled run 41732940287 ran plan/build/notes/publish, the notes job logged "AI release overview generated." (artifact 13278273685), and the published body carries the AI section plus the GitHub changelog. Verdict: needs information / human decision required — no code change is requested or authorized; the owner's punctuality/acceptance decision is still open and the Issue body now lags the evidence (it still calls scheduled AI-notes unverified and stops at v0.1.1). Earlier findings: F4 still open, F1 still open, F5 still open, F2 answered (this scheduled run on merged 663f3b3 is stronger evidence than the 2026-11-02 preview), F3 fixed (review 5752430228 at 269dca4 exists). I re-ran python -m pytest tests/test_release.py tests/test_release_notes.py tests/test_release_publisher.py -q on this snapshot → rc=0, 190 tests passed.

    F4 — human decision required (still open) — is 02:00 Asia/Shanghai a best-effort trigger or a business deadline, and has the goal been accepted?

    • Where: .github/workflows/release.yml:6 (cron: "0 18 * * *"), docs/releases.md:3-5, and the Issue's Current state / Decision needed.
    • Problem: all three natural scheduled starts are late against the nominal 18:00 UTC trigger — run 41352240234 at 2026-11-01T21:29:11Z (+3h29m), run 41551033350 at 2026-11-03T00:11:21Z (+6h11m), and this run 41732940287 at 2026-11-03T22:41:10Z (+4h41m). docs/releases.md:4 already states that GitHub schedules can be delayed, so nothing merged is wrong; what is missing is the acceptance owner's reading, and the body still records the timeliness clarification as a proposal rather than an accepted deadline. Requester acceptance of the goal is likewise unrecorded.
    • 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. Three late starts in a row are consistent with the documented best-effort behaviour but do not establish it as accepted.
    • 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.

    F6 — new in this update — the Issue body still reports scheduled AI-notes as unverified and stops at v0.1.1

    • Where: Issue body, Current state (“actual account import and natural scheduled AI-notes activation remain unverified”) and the Current delivery status — 2026-11-01 block (which still describes only v0.1.0).
    • Problem: the new comment explicitly supersedes that status, and I verified the evidence: v0.1.2 is draft: false, prerelease: true, published 2026-11-03T22:47:57Z, ref refs/tags/v0.1.2 → 663f3b32 (current main), with wheel, sdist, plugin ZIP and SHA256SUMS. Scheduled run 41732940287 (head 663f3b32, started 22:41:10Z) has all four jobs successful; notes job 126257711553 logged “AI release overview generated.” at 22:47:39Z and uploaded artifact 13278273685; the publish job verified all three artifact checksums and the published body contains ## AI-generated summary (four canonical commit links, e.g. 1fca842, which exists) followed by the GitHub changelog. So the body now understates what has been demonstrated.
    • Impact: an integrator or acceptance owner reading only the body would conclude the AI-notes extension has never run on the scheduled path and would not know v0.1.2 was published.
    • Fix: add one status line naming v0.1.2 (tag 663f3b32, published 2026-11-03T22:47:57Z, four assets), run 41732940287, notes job 126257711553 / artifact 13278273685, and keep the limits: one run only, future scheduled AI-notes runs and actual client installation remain unverified. Re-date the status block accordingly.

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


    F5 — still open — five bullets still link [draft #330], and “checks passed” sits next to a reported dead shipped-README link

    • Where: Issue body bullets Documentation follow-up, README/video alignment follow-up, Import/install clarification, English-language follow-up, README presentation follow-up, versus Current state (“ready-for-review docs: add an English Codex plugin installation guide #330 … checks passed”).
    • Problem: PR docs: add an English Codex plugin installation guide #330 is open at draft: false, head 269dca420a08f46661b4f9f988ab116b2940b5a5, 3 files (README, docs/codex-plugin.md, MP4), with review 5752430228 and the bot's inline thread r4454929027. The bullets' [draft #330] label is stale wording. Separately, the recorded blocker is still present at that head: docs/codex-plugin.md is copied verbatim into the plugin archive as inferrsi/README.md (tools/build_codex_plugin.py:75) while check_release.py:124 allows only plugin.json, skills, runtime, LICENSE, README.md, so the relative assets/inferrsi-codex-install-en.mp4?raw=1 link (docs/codex-plugin.md:38) is dead inside the ZIP.
    • Impact: the body's “checks passed” claim reads as covering the shipped README while the known dead link is still open; the Next action does correctly report it, so this is wording-level.
    • Fix: replace [draft #330] with the PR link and scope the check claim to GitHub-rendered links, keeping the shipped-README link fix as an explicit merge condition for docs: add an English Codex plugin installation guide #330.

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

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

    @agent-ci-infra-bot

    Intent: this Issue remains the standing record for the merged daily GitHub Actions release bot, and this edit restates the status around the first post-#313 scheduled run, which published v0.1.2 with AI-generated notes. Verdict: needs information / human decision required — no code change is requested or authorized; the new evidence checks out (scheduled run 41732940287 is success with plan/build/notes/publish, the publish job ran sha256sum --check SHA256SUMS, v0.1.2 is non-draft/prerelease with tag → 663f3b32 and the four assets, and the release body carries the AI summary plus the GitHub changelog), and pytest tests/test_release.py tests/test_release_notes.py tests/test_release_publisher.py gives 190 passed once TMPDIR is outside the noexec /tmp (the first attempt failed only for that environmental reason). Earlier findings: F6 mostly fixed (v0.1.2/run/notes job now recorded, though the release set and status block still lag), F2 covered by this scheduled evidence, F3 fixed (review 5752430228 exists), F1 and F5 still open, F4 unchanged. Labels: none — kind:task, area:process and priority:P2 already cover the axes, and the remaining items are the owner's acceptance decision plus record corrections.

    F4 — human decision required — is 02:00 Asia/Shanghai a best-effort trigger or a business deadline (and has the goal been accepted)?

    • Where: .github/workflows/release.yml:6 (cron: "0 18 * * *"), docs/releases.md:4 ("GitHub schedules can be delayed"), and the Issue's Decision needed.
    • Problem: the body still records the scheduling-timeliness clarification as a proposal, not an accepted deadline, and requester acceptance is unrecorded. All three natural scheduled starts are late against the nominal 18:00 UTC trigger: run 41352240234 at 2026-11-01T21:29:11Z (+3h29m), run 41551033350 at 2026-11-03T00:11:21Z (+6h11m), and this run 41732940287 at 2026-11-03T22:41:10Z (+4h41m, as the edit now states). Nothing merged is wrong — the workflow and the docs describe a best-effort schedule — so this is a policy decision, not a defect.
    • Impact: a deadline reading would need compensating scheduling and/or alerting as a new scoped change; a best-effort reading 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 before that.

    F1 — still open — Inputs and deliverables still calls #313 a draft, contradicting Current state


    F5 — still open — five bullets still link [draft #330] while the PR is ready for review

    • Where: Issue body bullets Documentation follow-up, README/video alignment follow-up, Import/install clarification, English-language follow-up, README presentation follow-up.
    • Problem: PR docs: add an English Codex plugin installation guide #330 is open with draft: false, head 269dca420a08f46661b4f9f988ab116b2940b5a5, 3 files (+64/−18) and review 5752430228, so the five [draft #330] links describe the PR's current state wrongly. The edit fixed the earlier "checks passed next to a known dead link" wording (that phrase is gone from Current state) and correctly reports the shipped-README video-link blocker in Next action; only the stale draft label remains.
    • Impact: a reader following those bullets believes the docs/media delivery is still a draft and not yet under review.
    • Fix: replace [draft #330] with the PR link, and keep the shipped-README link fix (docs/codex-plugin.md is copied verbatim as inferrsi/README.md by tools/build_codex_plugin.py:75, while tools/check_release.py:124 allows only README.md at the plugin root) as the explicit merge condition for docs: add an English Codex plugin installation guide #330.

    F6 — partially fixed — v0.1.2 and its scheduled run are now recorded, but v0.1.1 dropped out of the body and the status block is still labelled current at 2026-11-01

    • Where: Issue body Current state versus the <!-- current-delivery-status-start --> block headed ## Current delivery status — 2026-11-01.
    • Problem: the edit resolves the main part of F6 — I verified run 41732940287 is success with four successful jobs (plan/build/notes/publish), notes job 126257711553 logged "AI release overview generated." and uploaded artifact 13278273685, the publish job ran sha256sum --check SHA256SUMS, and v0.1.2 is draft: false, prerelease: true, published 2026-11-03T22:47:57Z with wheel/sdist/plugin ZIP/SHA256SUMS and tag → 663f3b32. Still missing: the body no longer mentions v0.1.1 at all (it was named in the previous revision and is still a public Release, published 2026-11-03T00:17:33Z with wheel/sdist/plugin ZIP/SHA256SUMS), and the block still headed "Current delivery status — 2026-11-01" names only v0.1.0. The only evidence line now linked from Current state (#issuecomment-6618044015) covers v0.1.2 alone.
    • Impact: the Issue no longer records the full published release set, so a reader cannot reconstruct v0.1.0 → v0.1.1 → v0.1.2 or verify the v0.1.1 delivery from the body.
    • Fix: add one line naming v0.1.1 (or link #issuecomment-6592252055), and either re-date/rename the status block or state that it is the 2026-11-01 snapshot superseded by Current state.

    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