Skip to content

Fold T1-T3 into the [0.1.0] changelog; re-stage for go-live (T4) - #78

Merged
jothimani-rajendran merged 1 commit into
mainfrom
feat/w6-t4-release-restaging
Aug 29, 2026
Merged

jothimani-rajendran merged 1 commit into
mainfrom
feat/w6-t4-release-restaging

Conversation

@jothimani-rajendran

Copy link
Copy Markdown
Collaborator

Summary

T1 (bundler, #77), T2 (opt-in content-comparison install identity, #75), and T3 (ContentRule, honestly refused everywhere today, #76) close the gaps plan/spine-a/reports/w3.md's Blocked section recorded against the chock migration. The release never shipped, so this is still [0.1.0] content per Option B (org-plan plan/spine-a/contract.md owner decision #7), not [0.2.0] — folded into the existing [0.1.0] entry, matching how every prior work session in this changelog appended to it rather than opening a new version header.

Re-verified clean-venv wheel build + import smoke with no chock-family code present (mirrors W1's own verification exactly):

$ python -m build --wheel --outdir dist
Successfully built agentseam-0.1.0-py3-none-any.whl
$ twine check dist/*.whl
PASSED

$ /tmp/agentseam-smoke-venv/bin/python3 -c "
import agentseam
from agentseam import packaging, bundler, install
plan = packaging.plan('claude_code', packaging.Bundle('smoke-test',
    parts=[packaging.Part(packaging.SKILL, 'demo', '# demo skill')]))
print('plan complete:', plan.complete)
print('bundler agents:', bundler.SUPPORTED_AGENTS)
src = bundler.bundle('claude_code')
print('installed() content mode:', install.installed('claude_code', '/tmp', events=['pre_tool'], command='x'))
"
plan complete: True
bundler agents: ('antigravity', 'claude_code', 'codex_cli', 'cursor', 'devin', 'gemini_cli', 'grok', 'junie', 'kimi_code', 'tabnine', 'vscode_copilot', 'windsurf')
installed() content mode: False

$ /tmp/agentseam-smoke-venv/bin/pip list
Package    Version
---------- -------
agentseam  0.1.0
pip        24.0
setuptools 79.0.1

No tag, no publish — owner-only, at go-live, per contract.md and W1's report. This PR is the last code change before that event; the go-live tag target is main HEAD after this PR merges (recorded in the handback report at open-coder-ai/org-plan plan/spine-a/reports/w6.md).

Test plan

  • Full suite green on the fully-integrated tree: pytest -q → 1201 passed, 4 skipped
  • ruff check . / ruff format --check . clean
  • tests/check_stdlib_only.py clean
  • Clean-venv wheel build, twine check, fresh-venv install + import/call smoke — see above
  • Changelog-only diff; no source changes

Refs open-coder-ai/org-plan#53 (Spine A, W6 brief T4). Based on main after #75, #76, #77 all merged.


Generated by Claude Code

T1 (bundler), T2 (opt-in content-comparison install identity) and T3
(ContentRule, honestly refused everywhere today) close the gaps
plan/spine-a/reports/w3.md's Blocked section recorded against the
chock migration -- the release never shipped, so this is still
v0.1.0 content per Option B (contract.md owner decision #7), not
0.2.0.

Re-verified clean-venv wheel build + import smoke with no chock-family
code present: python -m build --wheel, twine check (PASSED), installed
into a fresh venv, and a direct import/call smoke of packaging,
bundler, and install (including the new content-comparison mode)
all succeed with only agentseam on the venv's pip list.

No tag, no publish -- owner-only, at go-live, per contract.md D2/D3
and W1's report.

Signed-off-by: Claude <noreply@anthropic.com>

Copy link
Copy Markdown
Collaborator Author

CI is red here, and it is not this PR's diff — infra, not code.

Every check (dco, lint, stdlib-only, no-private-data, examples, all three test matrix legs, zizmor, actionlint, semgrep) failed within ~3 seconds of the run starting, including checks a changelog-only diff cannot plausibly break. get_workflow_job on the lint job shows runner_id: 0, runner_name: "" — the job never had a runner assigned before being marked failed, which rules out an actual test/lint/DCO failure.

This is not scoped to this PR: main's own post-merge CI shows the identical instant-failure signature on the last two merges, 5f64984 (#77, T1) and 8aa34e8 (#76, T3), while the merge just before them (f99e51a, #75, T2) is green. So main itself is currently red for the same infra reason, not from anything in those diffs — I re-verified 5f64984 locally (fresh clone equivalent: git fetch + pytest -q → 1201 passed, 4 skipped; ruff check/ruff format --check clean; tests/check_stdlib_only.py clean) before merging #77, and again just now on this PR's tree.

I re-ran the failed jobs once (rerun_failed_jobs on this PR's run and on both of main's red runs) per this repo's CI-red handling — same instant failure, same runner_id: 0 pattern, ruling out a one-off blip. I'm not retrying further or attempting any workaround (no skipping/disabling checks, no forcing a merge past red CI); this needs the runner infrastructure itself to recover, which is outside this diff's or this repo's control.

Local validation this PR actually needs — all green:

  • pytest -q → 1201 passed, 4 skipped
  • ruff check . / ruff format --check . clean
  • tests/check_stdlib_only.py clean
  • Clean-venv wheel build + twine check (PASSED) + fresh-venv install/import/call smoke — see PR body

Keeping this PR watched and will merge once CI reports real results (green, or a genuine failure I can act on).


Generated by Claude Code

Copy link
Copy Markdown
Collaborator Author

Blocked on CI infrastructure, not on this diff. Recording the evidence once so nobody re-diagnoses it:

  • All 12 checks across three independent workflows (CI, security, CodeQL) complete as failure 3–5 seconds after starting, on every attempt. That includes dco, which only reads commit trailers — nothing is executing.
  • Job logs return HTTP 404 for every failed job.
  • Sharp time boundary on this repo's history: runs created up to 20:55:39Z succeeded (T1/T2/T3 PRs and their main pushes all green); every run created from 20:55:52Z onward fails this way, including plain main pushes untouched by this branch.
  • This is now attempt 3 (one re-run by the worker, one by the orchestrator). Identical result each time, so it is not a flake and no further re-runs will be spent.

Two causes fit: a GitHub Actions incident, or exhausted Actions minutes / a spending limit on this private repository (private-repo minutes are billed; the org's public repos would be unaffected). Both are outside this PR. Handing to the maintainer to check the Actions billing/usage page and githubstatus.com — from a sandbox with restricted egress neither is reachable to confirm.

The change itself was validated locally before this PR: full suite green, clean-venv wheel install and import smoke with no consumer code present. No workaround will be attempted, and this PR stays open pending green CI and the owner's go-live.


Generated by Claude Code

@jothimani-rajendran
jothimani-rajendran merged commit 6816052 into main Aug 29, 2026
1 of 31 checks passed

Copy link
Copy Markdown
Collaborator Author

Resolved: the Actions failure was the private-repo minutes ceiling, and going public fixed it

Closing the loop on the diagnosis in this thread. agentseam is now public, and CI run #199
on dca9cd4 — dispatched to test exactly this — came back completed / success.

The contrast is unambiguous:

Under the ceiling Now (public)
Run duration 3–5s, every job ~32s, real work
Runner runner_id: 0, no name GitHub Actions 1000007386
Job logs HTTP 404 present
dco on a signed-off commit failure n/a (PR-only job, correctly skipped)
pytest -q never executed ran, passed on 3.9 / 3.11 / 3.13

Every job did real work this time: lint (ruff check + format), stdlib-only (import with user
site-packages disabled), examples, brand-assets, and the three test matrix legs.

The go-live prerequisite recorded here is now satisfied. The concern was that tagging
v0.1.0 would publish nothing because release.yml could not actually run. Runners are being
allocated again, so the tag will fire the workflow. That was the reason the sequence was
reordered to put the public flip before the tag (contract decision #10), and the reorder did
what it was meant to.

No workaround was ever applied — no vendoring, no git-URL deps, no CI edits, and after the three
attempts spent diagnosing it here, no further re-runs. The single dispatch above was the
confirmation step the sequence called for, not a retry.


Generated by Claude Code

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants