fix(release): produce a clean source-only tarball and gate it in verify-rc - #829
Conversation
…fy-rc The 0.1.0 rc1 source zip drew a binding -1: it bundled 181 .pyc files in 61 __pycache__ dirs (zipped from a working tree, not exported from the tag) and carried 138 dangling symlinks because .gitattributes export-ignored .agents/ while the committed .claude/skills / .kiro/skills relays and the specs still referenced into it; the same stripping broke skill/spec link integrity (.github templates, projects/_template/.gitignore). Packaging (.gitattributes): - Ship .agents/ so every relay symlink resolves to skills/ (0 dangling). - Strip only real CI/dev under .github/ (workflows, dependabot.yml); keep ISSUE_TEMPLATE/ and PULL_REQUEST_TEMPLATE.md, which shipped skills link. - Anchor root-only dotfiles with `/` so projects/_template/.gitignore ships. Verification hardening (release-verify-rc): - Step 6 always surfaces and hard-fails on .pyc / __pycache__. - New Step 7 "source-tree integrity": no dangling symlinks, and run symlink-lint + skill-and-tool-validate + spec-validate against the unpacked tarball; hard-fail on broken internal references. Renumber the following steps and add failure-mode rows. - Reinforce in release-build.md: always `git archive <tag>`, never `zip -r`. Verified against a real git archive of the fixed tree: 0 .pyc, 0 dangling symlinks, all three validators exit 0, no VCS metadata.
|
Note this has introduced a bug whcih causes this to fail: I'm just fixing that |
Does that indicate a bug or omission in the system? |
…p 8 (#830) PR #829 inserted "Step 7 — Source-tree integrity" into the release-verify-rc skill, bumping "Version string consistency" from Step 7 to Step 8. The eval fixture still referenced "## Step 7 — Version string consistency", which no longer exists in SKILL.md, so load_step_config raised ValueError and aborted the entire eval run (all step-configs load up front). Rename step-7-version-consistency -> step-8-version-consistency and update the step-config heading, the output-spec title, and the README suite table and grading rules to Step 8. Generated-by: Claude (Claude Opus 4.8)
Those checks are run with local agents - for people who use agents when they run PRs locally - when relevant part changes. Running those eveals on every CI is a terrible waste of tokens - especially if tokens will be API ones. For now evals are "eventually consistent" - when we break it, the idea is that they will be fixed by the next agentic PR that touches this area. |
Why
The 0.1.0 rc1 source zip drew a binding -1. Four defects, one packaging root cause:
.pycin 61__pycache__dirs — the tarball waszip -r'd from a working tree that had run tests, not exported from the tag..gitattributesexport-ignored.agents/, but the committed.claude/skills/*and.kiro/skills/*relays point through.agents/skills/* → skills/*, so every relay dangled once.agents/was stripped..github/templates,projects/_template/.gitignore, and.claude/skills/magpie-*/SKILL.md.Changes
Packaging —
.gitattributes.agents/so every relay symlink resolves toskills/(0 dangling)..github/(workflows/,dependabot.yml); keepISSUE_TEMPLATE/andPULL_REQUEST_TEMPLATE.md(linked by shipped skills)./so identically-named files deeper in the tree (e.g.projects/_template/.gitignore) still ship.Gate —
skills/release-verify-rc/SKILL.md.pyc/__pycache__.symlink-lint+skill-and-tool-validate+spec-validateagainst the unpacked tarball; hard-fail on broken internal references. Renumbered later steps; added failure-mode rows.projects/magpie/release-build.md: reinforce "alwaysgit archive <tag>, neverzip -r".Verification
Against a real
git archiveof the fixed tree (extracted):The exact validators that failed on rc1 now pass on the exported tarball, and
release-verify-rcwould catch a regression of any of these before the[VOTE].