[upstream-sync] Sync upstream block/buzz → 2026-07-30 (17 commits) - #7
Merged
Merged
Conversation
adrienlacombe
marked this pull request as ready for review
July 30, 2026 17:36
adrienlacombe
added a commit
that referenced
this pull request
Jul 30, 2026
PR #7 landed upstream's *content* but not its history. gh-aw's create-pull-request safe output ships the agent's work as a git patch (`/tmp/gh-aw/aw-*.patch`, upstream-sync.lock.yml:1040), and a patch cannot carry a merge commit's second parent. So b111a7b arrived with a single parent despite its "Merge remote-tracking branch 'upstream/main'" subject, the merge base stayed at 63496cc, and GitHub kept reporting this fork 23 commits behind while those commits' changes were already in the tree. This is a real `git merge upstream/main`, so the merge base finally advances. Future syncs become incremental instead of re-resolving the same conflicts against a stale base every night. Three files conflicted, all already on the fork-local patch list: - desktop/src-tauri/src/lib.rs — both sides inserted a `mod` after `mod huddle;`: ours `linux_media` via the flattened patch, upstream `key_backup`. Union, alphabetical order kept. - Cargo.lock — `rlp` is fork-local and sits immediately before `rmcp`, which upstream touched. Pure union, checked with `cargo metadata --locked`. - .github/workflows/release.yml — see below. Two regressions the auto-merge introduced silently, both in release.yml, and neither raised as a conflict: 1. `assemble-manifest`'s gate. Upstream block#3568 added `needs.release.result == 'success'` plus the same for `release-macos-x64`. Both jobs are pinned to `block/buzz` and so always report `skipped` here, making the gate unsatisfiable in a fork — the exact failure 67917a9 fixed, where every updater archive and .sig uploaded and only latest.json was missing. Git saw no conflict because our side had *removed* a condition while upstream *added* these. Re-patched to accept either darwin-aarch64 lane and to tolerate `skipped` only for the signed x64 lane, so on block/buzz every lane must still succeed. 2. `release-macos-unsigned` was stranded on the pre-block#3568 release model. Upstream moved every platform lane to handing assemble-manifest a `desktop-release-*` workflow artifact; this lane is fork-local, so neither the restructure nor the `v` -> `desktop-v` tag rename reached it. Left alone it would `gh release upload` to a `v${VERSION}` tag that is no longer created, and its updater archive would never reach `staged` — leaving the fork's only darwin-aarch64 asset out of both the release and latest.json, which is the failure this lane exists to prevent. Ported to upload-artifact, tag prefix corrected, and `contents` dropped to `read` now that it touches no release. Verified: `cargo check --manifest-path desktop/src-tauri/Cargo.toml --all-targets` clean, `cargo metadata --locked` clean, release.yml parses, and the fork-local relay allowlist, productName, APP_DISPLAY_NAME, app_name, GHCR overrides and mesh-llm-rev patches all survived the merge. Signed-off-by: adrienlacombe <6303520+adrienlacombe@users.noreply.github.com>
adrienlacombe
added a commit
that referenced
this pull request
Jul 30, 2026
`PROD_ORIGIN`, `DEV_ORIGIN` and `is_trusted_media_origin` are reachable only from the `cfg(target_os = "linux")` `enable_media_capture` and from the tests, so in the lib target on macOS or Windows `clippy -- -D warnings` fails with three dead_code errors. That breaks `just desktop-tauri-clippy`, and with it the pre-push hook, for anyone developing on a Mac. Upstream's CI runs that lint on Linux only and so never sees it: the file arrived byte-identical from upstream in PR #7 (c9aa555) and has been failing locally ever since. An `allow` and not a `cfg`: the items must stay compiled on every platform because `mod tests` unit-tests the origin check everywhere, which is what the doc comment on `is_trusted_media_origin` explicitly asks for. Gating them to Linux would trade three lint errors for three broken tests. Verified both halves on darwin: Tauri clippy is clean and the three linux_media tests still pass. One module-level attribute rather than three item-level ones, to keep this to a single hunk at the top of the file. The fix belongs upstream in block/buzz. Signed-off-by: adrienlacombe <6303520+adrienlacombe@users.noreply.github.com>
adrienlacombe
added a commit
that referenced
this pull request
Jul 30, 2026
…nces The sync agent ran `git merge` correctly and kept the merge commit, exactly as its prompt says to, and still produced a single-parent commit on every run. gh-aw's create-pull-request safe output moves the agent's work into a separate job as a git patch (`/tmp/gh-aw/aw-*.patch`), and a patch carries file deltas but not a merge commit's second parent. The effect was invisible in the diff and obvious in the graph: PR #7 landed all 17 commits' content, the merge base stayed at 63496cc, and GitHub kept reporting the fork 23 commits behind. Each night then re-merged from that same stale base and re-resolved the same conflicts. Repaired by hand in 3ce7c8a. None of that was a reasoning failure, so a better model would not have fixed it. What matters is who pushes. So the merge moves to a plain workflow with no AI in it — the runner pushes, and the merge commit that lands is the one git made, with both parents. Two stages, split along whether judgement is actually required: - 01:30 UTC, upstream-sync-merge.yml: fetch, exit if not behind, exit if a sync PR is already open, `git merge --no-ff`. Clean merges become a PR. Conflicts abort and hand off. This is ~90% of days and costs no AI credits. - 02:00 UTC, the existing agentic run: now stops if a pushed sync branch already contains upstream/main, so it cannot stack a second PR on the 01:30 one. Its prompt also no longer claims to preserve upstream history, and says to state in the PR body that the merge base will not advance without a manual re-merge. Deliberately still opens a PR rather than pushing to main: the PR is the review gate for changes this fork did not author, and deploy-aws.yml deploys every push to main to the live relay. Neither stage can catch a merge that is clean but wrong — upstream block#3568 auto-merged without conflict and still broke two fork-local patches in release.yml. Both the PR body and AGENTS.md now say to read the diff anyway. AGENTS.md: rewrote "How the sync works", which claimed upstream history stays intact; that was the assumption the bug hid behind. Added rows for the two new workflows, the CI-status watcher that was never listed, the linux_media patch from dabf964, and the NIP-SW Starknet code in ingest.rs and builders.rs — fork divergence in upstream files that the table did not record at all. Signed-off-by: adrienlacombe <6303520+adrienlacombe@users.noreply.github.com>
adrienlacombe
added a commit
that referenced
this pull request
Jul 31, 2026
The 2026-07-31 agentic run resolved all 17 commits correctly — including moving KIND_STARKNET_WALLET_BINDING to 30900 per the rule added in 7c83857 — and then could not deliver it: ! [remote rejected] refusing to allow a GitHub App to create or update workflow `.github/workflows/ci.yml` without `workflows` permission Upstream changed ci.yml in that batch. GITHUB_TOKEN and GitHub App tokens cannot create or update workflow files, and there is no `workflows` key in Actions `permissions:` to grant, so a PAT with the `workflow` scope is the only route. Yesterday's PR #7 pushed fine only because its range happened to touch no workflow files at all. This applies to *both* stages. upstream-sync-merge.yml pushes with `SYNC_PUSH_TOKEN || GITHUB_TOKEN`, so with no PAT set it fails identically the first time a sync touches a workflow file — its smoke test exited at the not-behind check and never reached a push, so the gap stayed hidden. The comment there described the token as only affecting whether CI fires, which understated it; corrected, and the settings table now lists the secret as required. Also recorded two things worth not re-deriving: gh-aw prints its own flattening ("refusing unsigned push fallback", then "Rewriting bundled commits to a single linear commit"), so it is deliberate and not configurable; and gh-aw converts an intended PR into an issue when the push fails, keeping the full PR body and appending the git error. Issue #8 reads like a conflict escalation and is in fact a finished resolution — worth knowing before assuming the agent gave up. Signed-off-by: adrienlacombe <6303520+adrienlacombe@users.noreply.github.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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Upstream sync:
3b8567a05..06582ee6f(17 commits)Merges 17 commits from
block/buzzmain into this fork.Changes by area
Desktop
3b8567a05fix(desktop): remove Projects overview card fills7fb008f93fix(desktop): explain open agent access310df2ec3desktop: restore direct community member addsc9aa55505desktop: enable getUserMedia in Linux WebKitGTK webview4672ee55cFix pending message feedbackd0a24bcb5Add macOS agent menu-bar menu73589408dfix: align responsive agent viewsc55e421a0fix(desktop): remove remaining Projects panel fills9a386a0deRefine agent sharing dialogMobile
85edc0572feat(mobile): desktop-parity emoji and thread experience06582ee6fRender mobile agent mention chipsRelay / ACP / CLI
53771c8f5fix(acp): preserve truncated thread context262f2392efix(cli): resolve agents from owner recordsCatalog / Mesh
02be413b8feat(catalog): resolve publisher display name in catalog detail pane61b96c982fix(catalog): update Amp description4933672ebfeat(mesh): upgrade embedded mesh to v0.74 and harden shared computeDocs / NIPs
33bf7caa6docs(nips): specify kind:30621 multi-repo projects (NIP-MP)Conflicts
desktop/src-tauri/Cargo.locknum_enum_derivedeps: fork hadproc-macro-crate 3.5.0, upstream had2.0.2. Took upstream's version (2.0.2) —proc-macro-crate 2.0.2is already present elsewhere in the lock file and matches upstream's resolved dep tree.Needs a human look
desktop/src-tauri/Cargo.lock: The resolved conflict takes upstream'sproc-macro-crate 2.0.2fornum_enum_derive. Our fork's lock file already had both 2.x and 3.x entries forproc-macro-crate; verify that the build still compiles after merge.4933672eb): touchesbuzz-acpand shared-compute harness. Worth checking against this fork's relay/ACP configuration.desktop/src-tauri/src/lib.rsauto-merged cleanly, but it's on the fork-local patch list (mod relay_allowlist;). Verify the allowlist module registration survived the merge.