ci: schedule bounded hourly product development - #504
Conversation
pip-audit against the runtime lock (uv export --no-dev) flagged real advisories in the exact PDF/image parsing path this service depends on. Re-locked with targeted upgrades (all within the existing pyproject.toml version ranges): - pillow 12.2.0 -> 12.3.0 (PYSEC-2026-3451/3452/3453/3454/3493/3494/3495/3496: eight image-decoder advisories). - pypdf 6.13.3 -> 6.14.2 (CVE-2026-59935/59936/59937/59938: PDF parsing). - click 8.3.2 -> 8.4.2 (PYSEC-2026-2132). - setuptools 81.0.0 -> 83.0.0 (CVE-2026-59890, build tool). Verification: `uv export --frozen --no-emit-project --no-dev | pip-audit` -> No known vulnerabilities found. Lock diff is confined to these four packages and their hashes. Residual (documented, not fixable in place): pymdown-extensions 10.21.3 CVE-2026-61632 requires a major bump to 11.0.0, but mkdocs-material 9.6.x caps pymdown-extensions to <11. It is a docs-build-only dependency (mkdocs), not on the runtime/API surface, so it does not affect the shipped image or the `/parse` path; clearing it needs a coordinated docs-toolchain upgrade. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Msz8Dni5zRaqPatNCmZJZ8
…fting mkdocs-material to 9.7.x The org Security Scan `trivy-fs` job fails on this repo (base branch and every open PR) with: [MEDIUM (security-severity=5.3)] CVE-2026-61632 uv.lock - pymdown-extensions pymdown-extensions 10.21.3 is vulnerable; the fix is 11.0.0+. It could not be upgraded because mkdocs-material 9.6.x pins `pymdown-extensions~=10.2` (i.e. <11). The docs toolchain deliberately held `mkdocs-material<9.7` to avoid the 9.7 "MkDocs 2.0" warning banner (encoded in pyproject, two tests, and CONTRIBUTING.md). That caution-hold now blocks a real security fix and fails required CI, so it is lifted to the minimum extent needed: bump only the theme to `mkdocs-material>=9.7,<9.8` (which relaxes its pymdown-extensions cap to `>=10.2`). The MkDocs *core* stays on the 1.x line (`mkdocs>=1.6,<2.0` unchanged) — the 9.7 theme still builds on MkDocs 1.x. Resulting lock: pymdown-extensions 10.21.3 -> 11.0.1, mkdocs-material 9.6.23 -> 9.7.7 (plus the runtime pillow/pypdf/click and setuptools bumps from the previous commit). Governance re-documented coherently: - CONTRIBUTING.md: explains the theme now tracks 9.7.x for the CVE fix while the MkDocs core stays 1.x; the 9.7 banner is informational and non-fatal under --strict. - tests/test_project_metadata.py: assertions updated to the new pin and the CONTRIBUTING rationale (CVE-2026-61632). Verification: - `uv run --frozen --extra docs mkdocs build --strict` -> builds cleanly (informational MkDocs 2.0 banner only, exit 0). - `uv export --frozen --no-emit-project --all-extras | pip-audit --no-deps` -> No known vulnerabilities found (runtime and full sets). - `PYTHONWARNINGS=error uv run --frozen --all-extras pytest` -> 430 passed. - No src/ change, so the 100% branch-coverage gate is unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Msz8Dni5zRaqPatNCmZJZ8
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
|
Parking this hourly product-development workflow until security baseline PR #467 is merged. The branch and full TDD/documentation work are preserved. Reopen after |
Summary
Add a fail-closed hourly product-development loop that creates at most one bounded Copilot cloud-agent task when the repository has no open pull requests and no active or unknown Agent Task.
TDD evidence
.github/workflows/hourly-product-development.ymldid not exist.Behavior
workflow_dispatch.GITHUB_TOKENonly for PR inventory and a fine-grainedCOPILOT_GITHUB_TOKENfor the Agent Tasks API.develop.Primary-source verification
GitHub's current Agent Tasks REST documentation identifies the endpoints as public preview, requires
Agent tasksrepository permission (readfor inventory andread/writefor task creation), supports fine-grained personal access tokens or GitHub App user access tokens, and explicitly excludes GitHub App installation access tokens. The workflow therefore does not useGITHUB_TOKENfor Agent Tasks calls and pins the supported REST API version2022-11-28.Files
.github/workflows/hourly-product-development.ymltests/test_hourly_product_development.pydocs/workflow/hourly-product-development.mdCHANGELOG.mdOperational prerequisite
Configure
COPILOT_GITHUB_TOKENas a repository or organization secret with Agent tasks read/write permission for this repository. The authenticating user also needs an eligible Copilot Business or Enterprise subscription and organization policy access. Without the credential, or when task inventory cannot be proven complete, the workflow records the reason and creates no work.Scheduled workflows execute from the default branch, so this loop becomes active only after it is merged into
develop.Stacked dependency
This draft is stacked on security PR #467. After #467 lands, the comparison against
developmust contract to this workflow change and be revalidated on the resulting current head before this PR is marked ready.Git Flow target
ci/*→develop.