chore: release main - #58
Merged
Merged
Conversation
github-actionsBotforce-pushed
the
release-please--branches--main
branch
from
July 27, 2026 17:05
6a3f9e3 to
bba2559Compareforkwright added a commit
that referenced
this pull request
Jul 28, 2026
Fixes the permanent block on release PRs described in #68. `gate-attestation` waived on `github.actor == 'dependabot[bot]' || github.actor == 'release-please[bot]'`. Neither value occurs on this repo's release PRs — release-please under `GITHUB_TOKEN` opens them as `github-actions[bot]` — so the waiver never fired and the trailer check failed against generated version-bump commits. It is a required check on `main`, so #58 is red on this and nothing else, and every future release PR would be too. ## Changes - Waiver keys off `github.event.pull_request.user.login` instead of `github.actor`. `github.actor` is whoever caused the current run, so it flips to a maintainer login on "Re-run failed jobs" and re-arms the check on a bot PR that already passed. - Release-please additionally matched branch-shaped (`startsWith(github.head_ref, 'release-please--branches--')`), because the author varies between GITHUB_TOKEN and PAT operation while the branch name does not. - Trailer verification bound to the PR tip instead of the whole commit range. The range form passed whenever *any* ancestor carried a trailer, so an unstamped tip could ride an earlier commit's attestation and the merged tree was never gated. Both conditions match the fleet's canonical reusable at `forkwright/.github/.github/workflows/gate-attestation.yml`; this is convergence toward it, not a new local dialect. ## Verification - The tip-binding predicate was exercised both ways against real commits before committing: a tip with no trailer whose *ancestor* carries one exits 1 (the old code's false green), and a tip carrying one exits 0. - `kanon gate --tier full` green on this branch — fmt, check, clippy, nextest (78/78), deny, lint — and this commit carries its `Gate-Passed` trailer, so the new tip-bound check is being asked to pass on its own terms. - Workflow YAML parses. The job keeps its `gate-attestation` name, so the required-check context is unchanged and no branch-protection edit is needed. Migration to the shared reusable caller — which does carry a required-check rename to `gate / gate` — stays with kanon#2522. Refs #68
github-actionsBotforce-pushed
the
release-please--branches--main
branch
from
July 28, 2026 21:01
bba2559 to
9710ae9Compareforkwright added a commit
that referenced
this pull request
Jul 28, 2026
…e release (#71) Fixes the recurring release breakage described in #70. `release-please-config.json` rewrote exactly one value — `[workspace.package] version`. Members inherit it via `version.workspace = true`, but two other places name the same version and were left behind: the workspace-dependency requirement `hamma-core = { path = "crates/hamma-core", version = "0.1.0" }` and the two workspace-member entries in `Cargo.lock`. A release that moves the minor therefore makes the workspace unresolvable. #58 (`chore: release main`, 0.1.0 -> 0.2.0) fails the required `cargo deny` check with `failed to select a version for the requirement hamma-core = "^0.1.0"`, and that is the only red check left on it. Patch releases hid this because `^0.1.0` still admits `0.1.x`. ## Changes Two `extra-files` entries added to the existing package block: - `$.workspace.dependencies.hamma-core.version` — zetesis carries one such entry per internal workspace dependency for exactly this reason. - `$.package[?(!@.source)].version` on `Cargo.lock` — harmonia and koinon both carry this, so the lock's source-less (workspace-member) entries move with the release. Both are fleet-established shapes rather than new local invention. ## Verification The premise was exercised both ways against a real 0.2.0 bump, since release-please's own behaviour is only observable when it regenerates the PR: - Bumping `$.workspace.package.version` alone — what the config does today — reproduces the exact CI failure: `cargo metadata` exits 101 with `failed to select a version for the requirement hamma-core = "^0.1.0"`. - Applying that plus the two edits the new entries produce resolves clean (exit 0). So the added jsonpaths are confirmed to name the values that actually break, not merely plausible ones. `kanon gate --tier full` is green on this branch. Once this lands, #58 needs release-please to regenerate its branch so the bump includes the new edits. Refs #70
github-actionsBotforce-pushed
the
release-please--branches--main
branch
from
July 28, 2026 21:09
9710ae9 to
d934b0fCompareUh oh!
There was an error while loading. Please reload this page.
This was referenced Aug 26, 2026
forkwright
commented
Aug 26, 2026
Owner
Diagnosed why this PR has sat Fix: #121 (removes both fields — every other fleet release-please repo Expected on merge: the next release-please run should find this PR, build + If it does not self-heal, the fallback is a manual |
forkwright added a commit
that referenced
this pull request
Aug 26, 2026
…se-please (#121) ## Finding Release Please has aborted every single run since PR #58 merged 2026-07-28T21:12:21Z — a full month, entirely unrelated to today's Actions outage/billing lockout (hamma is public). hamma has zero git tags and zero GitHub Releases while `.release-please-manifest.json` and `CHANGELOG.md` both already declare v0.2.0 shipped. ## Evidence `gh api repos/forkwright/hamma/tags` and `.../releases` both return `[]`. PR #58 ("chore: release main") still carries the `autorelease: pending` label today — it was never flipped to `autorelease: tagged`, which only happens when release-please successfully creates the release. The run immediately after the merge (id 30399683185, 2026-07-28T21:12:24Z, conclusion=success) and the most recent run before this PR (id 33002219225, 2026-08-26T18:53:53Z, run *after* PR #117's healer merged) both log the identical sequence: ``` ✔ Building releases ❯ Found pull request #58: 'chore: release main' ✔ Building release for path: . ⚠ PR component: undefined does not match configured component: hamma ... ❯ Building candidate release pull request for path: . ❯ Found pull request #58: 'chore: release main' ⚠ There are untagged, merged release PRs outstanding - aborting ``` Traced against `googleapis/release-please` v17.6.0 (the pinned action version) source: - `Manifest.createReleases()` → `buildReleases()` → per-strategy `buildRelease()` (`src/strategies/base.ts:640-656`) parses the merged PR's **branch name** via `BranchName.parse()`. hamma's branch is `release-please--branches--main` — matches `DefaultBranchName` (`src/util/branch-name.ts`), which **never sets `.component`** (only `AutoreleaseBranchName`/`ComponentBranchName` do, neither of which this repo's shape produces, since `separate-pull-requests: false` always yields the plain branch pattern). - That `undefined` is compared against `getBranchComponent()` (`src/strategies/base.ts:191`), which returns `this.component || getDefaultComponent()` — **ignoring `include-component-in-tag` entirely** — and falls back through `package-name` when `component` is unset. hamma's config set both to `"hamma"`, so this always resolves to `"hamma"`. - `"hamma" !== undefined` → `buildRelease()` returns early with no release built → `createReleases()` creates nothing, silently. - `Manifest.createPullRequests()` (`src/manifest.ts:920-933`) then finds the same still-`autorelease: pending` PR #58 via `findMergedReleasePullRequests()` and aborts opening a new PR too — the exact log line above. This is not a one-off: every future hamma release PR will produce the identical component-less branch name, so this wedges every release forever, not just this one. **Fleet comparison** (`gh api repos/forkwright/<repo>/contents/release-please-config.json`): akroasis, epistole, harmonia, gnomon, and thumos all carry **neither** `package-name` nor `component` in their package block, and all have real tags. hamma is the only one of the six checked that sets both — and the only one stuck. `include-component-in-tag: false` is already set, so removing both fields changes no *observable* tag/branch/PR-title format: PR #58's actual body (`<summary>0.2.0</summary>`, no `hamma:` prefix) and branch name were already component-less before this fix — `getComponent()` already returns `''` when `include-component-in-tag` is false. The bug is purely in `getBranchComponent()`'s separate, unguarded fallback. ## Why this matters A missing release is worse than a failing one to notice, but this is actively worse than "release-please is idle": it looks like nothing is wrong (CHANGELOG.md and the manifest both say 0.2.0 shipped), until someone tries to depend on hamma via a tagged version, or `cargo add --git ... --tag v0.2.0`, and there is nothing there. ## Desired correction Remove `package-name`/`component` from `release-please-config.json`'s `.` package block so `getBranchComponent()` resolves to the same empty value the branch name already carries. **Done when:** the next release-please run after this merges creates the `v0.2.0` tag + GitHub Release for PR #58 and flips its label from `autorelease: pending` to `autorelease: tagged`, without manual intervention. **This is unverified** — see below. ## Not verified, and why I could not run release-please locally (`npx`/network package execution is outside what this lane is authorized to do) or dispatch this fix on a feature branch to test it: the reusable workflow's `release-please` job does no repo checkout and reads `release-please-config.json` from the `main` branch via the GitHub Contents API regardless of which ref triggers the run (confirmed in both run logs above — `Fetching release-please-config.json from branch main`), so a feature-branch `workflow_dispatch` would not exercise this change at all. The diagnosis above is source-traced against the exact pinned release-please version, not guessed, but the merge itself is the first real test. I also verified, and did **not** perform, the alternative direct fix: create the `v0.2.0` tag at PR #58's merge commit (`6cc5781693ab276cc0f53369c86ac0062087cbf7`, confirmed on `main` via `git merge-base --is-ancestor`) and the matching GitHub Release from CHANGELOG.md's 0.2.0 section — both blocked by this session's own sandbox policy (direct tag-push and `gh release create` were both refused). If the config fix above does **not** self-heal on the next run, that manual recipe is the fallback and is fully worked out; it needs write authority this session doesn't have. **Watch the first release-please run after this merges** and confirm the tag/release/label actually land. Co-authored-by: forkwright <cody@forkwright.com>
forkwright added a commit
that referenced
this pull request
Aug 26, 2026
#120) ## Finding Two live docs-drift defects. `_llm/current_state.toml` hadn't been touched since 2026-05-25 (3 commits total, `git log --follow`) and still carried an unfilled `<canonical-state-doc>/STATE.md` template placeholder in `source_docs`. The same broken placeholder was copy-pasted into `_llm/architecture.toml`, `_llm/decisions.toml`, and `_llm/glossary.toml` (4 sites total, `grep -rn canonical-state-doc`). `README.md`'s Status paragraph named issue #20 ("Phase 3 audit: missing PeersChangedPatch...") as the "current audit backlog" topic set. #20 closed 2026-05-25T19:46:08Z. Of the issues open when the underlying finding was written, neither #65 nor #67 was named, and a third (#61, open since 2026-07-21) wasn't caught either — issue numbers embedded in prose go stale the moment the tracker moves, independent of whether anyone remembers to update the doc. ## Evidence - `git log -1 --format='%ci %h' -- _llm/current_state.toml` → `2026-05-25 ... 3b5b82b` while the file said `updated = "2026-05-01"`. - Since that commit: `crates/hamma-core` renamed to `crates/mitos` (#86, landed 2026-08-08 per `git log --diff-filter=A -- crates/mitos/Cargo.toml`), `crates/dictyon/src/wire.rs` split into `wire/mod.rs`, PR #58 cut the v0.2.0 changelog (2026-07-28), and 100+ PRs merged after that (`git log --oneline 3b5b82b..origin/main | wc -l`). - `grep -rn "canonical-state-doc" .` → 4 hits, all `_llm/*.toml`. - The placeholder was never a mystery token: hamma's own README auto-metadata block already resolves it — `Planning state: projects/hamma/STATE.md` — and `gh api repos/forkwright/kanon/contents/projects/hamma/STATE.md` confirms the file exists. `_llm/*.toml` now point at the same target via the full URL hamma's own `CLAUDE.md` already uses for this cross-repo link (`https://github.com/forkwright/kanon/blob/main/projects/hamma/STATE.md`). - `gh issue list --repo forkwright/hamma --state closed` → #20 closed 2026-05-25T19:46:08Z. `gh issue list --repo forkwright/hamma --state open` → #61 (2026-07-21), #65 (2026-07-21), #67 (2026-07-21), #118 (2026-08-26, opened today) — none is #20's topic set. ## Why this matters `_llm/*.toml` is the corpus other agents and tools read instead of re-deriving repo state from scratch; a doc that's been silently wrong for three months defeats that purpose worse than no doc at all, since it reads as authoritative. A broken placeholder that's been copy-pasted across four files is the same defect four times, not four defects. README's Status section is the first thing a human or agent reads; naming a closed issue as "the current backlog" points readers at the wrong problem set entirely. ## Desired correction Refresh `_llm/current_state.toml`'s `summary`, `current_phase`, `updated`, and `recent[]`/`open_threads[]` against present-day repo state; point every `<canonical-state-doc>` placeholder at the real STATE.md; stop naming specific issue numbers in README's Status prose and point at the tracker instead. **Done when:** `grep -rn "canonical-state-doc\|map deltas, zstd framing"` returns nothing, and `_llm/current_state.toml`'s `updated` field and `open_threads[]` reflect the tree at merge time. Both hold in this PR — see the diff. ## Note (out of scope, flagged for the right owner) `forkwright/kanon`'s `projects/hamma/STATE.md` — the doc `_llm/*.toml` now points at — is itself stale in a worse way than what this PR fixes: its frontmatter claims `last_updated: 2026-08-15` but its body still says `Version: v0.1.0 (unreleased)`, references `crates/hamma-core` (renamed 2026-08-08, before the claimed update date), and says "No dictyon code touched since 2026-04-13" against 100+ merged PRs. That's a `forkwright/kanon` planning-doc defect, not a `forkwright/hamma` one — this PR doesn't touch it, since kanon is a shared planning tree outside this lane's scope. Co-authored-by: forkwright <cody@forkwright.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 I have created a release beepboop
0.2.0
0.2.0 (2026-07-28)
Features
Bug Fixes
Refactoring
Documentation
This PR was generated with Release Please. See documentation.