Activity

1. tucktuck101

   self-assigned this

   on Aug 21, 2026
2. tucktuck101

   added

   type:prdProblem, evidence and success criteria — delivered through child features and tasksProblem, evidence and success criteria — delivered through child features and tasks

   area:processHow the cohort works: templates, labels, conventionsHow the cohort works: templates, labels, conventions

   by:agentFiled or authored by an AI agent, not a humanFiled or authored by an AI agent, not a human

   area:agents-and-automationAgentic workflows and automation — proposals and delivery (see #40)Agentic workflows and automation — proposals and delivery (see #40)

   on Aug 21, 2026
3. tucktuck101 commented on Aug 21, 2026

   

   tucktuck101

   on Aug 21, 2026

   CollaboratorAuthor

   More actions

   Proposal — completing PRD #273 (the change agent)

   Nothing was written. All work below is read-only: gh issue view, gh api, git fetch, git diff, git merge-tree, and reading launchpad/AGENTS.md, ADR-0005, ADR-0017, launchpad/AGENT_PR_TEMPLATE.md.

   ---

   0. Re-measured facts, and four places the PRD is wrong

   I re-derived everything I rely on. The tip moved; three of the changes matter.

   PRD says	Measured today (after git fetch upstream main)
   255 ahead / 60 behind	259 ahead / 67 behind
   324 files / 282 in launchpad/ / 42 upstream	327 / 279 / 48
   3 conflicts	4 — Cargo.lock has joined
   merge-base 2026-08-17	unchanged (f8692fa9b)

   $ git rev-list --left-right --count launchpad/launchpad...upstream/main
   259	67
   $ git merge-tree --write-tree --name-only launchpad/launchpad upstream/main
   7f3833a261c463db0861f36d6d8dad9cac9d07cc
   .github/workflows/ci.yml
   Cargo.lock
   desktop/src-tauri/src/managed_agents/runtime.rs
   lefthook.yml
   

   0.1 The "42 diverged upstream files" is not a 42-file conflict surface

   Classifying all 48 by status against the merge-base and against upstream/main:

   • 21 are pure fork additions with no upstream counterpart — the six .claude/skills/*, the six .github/ISSUE_TEMPLATE/0*.yml, the five launchpad-*.yml workflows, LAUNCHPAD.md, bin/.lefthook-2.1.10.pkg, desktop/src-tauri/src/managed_agents/runtime/summary.rs, scripts/test-ci-changed-paths-filter.sh. These cannot conflict unless upstream one day creates a file at the same path.
   • 2 are deletions (bug-report.md, feature-request.md) — these conflict only as modify/delete.
   • 25 are true modifications of files upstream still owns.
   • Of those 25, upstream has touched only 8 since the merge-base. Four of the eight conflict.

   So the register has ~27 rows that can ever matter and 8 that matter now. That is good news for scope and it changes sequencing: the register is insurance against future syncs, not the thing blocking this one.

   0.2 ADR-0017 does not document lefthook.yml

   The PRD says lefthook.yml's divergence is "documented (ADR-0017), so the winner is already known." It is not. ADR-0017 is scoped to "exactly bin/lefthook and bin/.lefthook-*.pkg." lefthook.yml's divergence is a one-line branch-skew redirect, documented only in an in-file comment citing #15. It is an undocumented divergence for register purposes, and its conflict is in the semantic class, not the register-driven one. That moves the PRD's "one conflict in each of the three classes" claim: today it is two mechanical-ish, two semantic, not one of each.

   0.3 merge=ours drivers are wrong for almost every candidate the PRD names

   This is the largest correction. Three of the four candidate groups fail on inspection:

   lefthook.yml — actively harmful. Our divergence is one line. Upstream's change since the merge-base is a near-rewrite: it adds rc: bin/.lefthookrc, adds files: git diff --name-only origin/main...HEAD scoping to six lanes, adds push-head-scope and file-size-check lanes, and renames mobile-fix→mobile-fmt and mobile-test→mobile-checks. merge=ours would silently discard all of it to preserve one line. The correct resolution is theirs, then re-apply our line.

   The five ADR-0005 deployment files — contradicts the ADR. ADR-0005 explicitly rejects a fork-local copy of docker.yml and states the reasoning: "A conflict you must resolve is better than a copy you forget to." merge=ours reintroduces exactly the silent-drift failure that ADR rejected. Adding those drivers would be reversing a decided ADR inside a plumbing PR.

   bin/lefthook and bin/.lefthook-*.pkg — the ADR states a different rule. ADR-0017: "resolved by taking whichever version is newer." That is neither ours nor theirs; it is a comparison. merge=ours would pin us to 2.1.10 forever and block an upstream bump to 2.2.x.

   Only .github/ISSUE_TEMPLATE/* survives, and mostly it does not need a driver: six of the nine files are fork-only additions, two are deletions, and config.yml is the single genuine ours-wins case.

   0.4 A concrete hazard already sitting in the 67-commit backlog

   Upstream's new bin/.lefthookrc sets LEFTHOOK_BIN to the Hermit-pinned bin/lefthook at 2.1.3 — the exact version ADR-0017 records as crashing every first push in this fork, because the branch name launchpad collides with the launchpad/ directory. lefthook.yml and bin/.lefthookrc auto-merge or arrive clean; the interaction with our 2.1.10 pin does not. A textually clean merge here reintroduces a known, filed bug (#196). This is the best available argument for the PRD's own "no unattended semantic resolution" non-goal, and it should be the worked example in the escalation contract.

   ---

   1. The eight success criteria

   SC1 — mirror never stale by more than one cadence period

   Blocked by a permission I cannot grant, and the PRD does not know it.

   $ gh api repos/launchpad-26/buzz/branches/main/protection --jq '.restrictions.users[].login'
   joshuavial
   $ gh api repos/launchpad-26/buzz --jq '.default_branch'
   launchpad
   

   Push to main is restricted to one named user. restrictions.apps is empty, so the Actions GITHUB_TOKEN cannot fast-forward it. allow_fork_syncing is false.

   Three ways out, in preference order: (a) an admin adds github-actions to restrictions.apps — one API call, keeps the design intact; (b) the mirror moves to an unprotected upstream-mirror branch and main stays a human-maintained artifact; (c) a PAT, which I would argue against on ADR-0015 grounds.

   How I'd satisfy it: scheduled launchpad-upstream-sync.yml, contents: write + pull-requests: write only, fetching block/buzz and fast-forwarding. Evidence: a run log showing the FF, plus a deliberate failure injection (point it at a non-fast-forwardable ref) showing the job goes red rather than silent. Not achievable without (a) or (b) being decided by a human with admin.

   SC2 — clean upstream merge reaches a reviewable PR with no human involvement

   Achievable and cheap. Pure shell in the same workflow: git merge --no-ff, and on success push a branch and gh pr create with the by:agent label and an AGENT_PR_TEMPLATE-shaped body. No model in the loop.

   Evidence: a run where merge exits 0, the PR exists, and the workflow log shows no model invocation. The honest caveat is that this path is currently unexercised — the backlog conflicts, so the clean-merge branch will not run for real until the four conflicts are cleared. I would prove it against a synthetic ancestor pair rather than claim it works.

   SC3 — every diverged upstream file has a recorded reason and a stated conflict winner

   Achievable, and the most valuable single deliverable. launchpad/upstream-sync/DIVERGENCE-REGISTER.md, one row per file: path, category, status vs merge-base, why it diverges, conflict winner, authority (ADR / issue / in-file comment / unrecorded), and who to ask.

   Two things I would insist on. First, the honest rows: the eight modified product-code files trace to four commits (f36d10f9c pack JSON output, 35cab546a cfg(unix) gating, 975e6d444 configured-relay dial, 43366affa file-size ratchet split) but none of those has a recorded statement of upstream-conflict intent. I would record the commit as provenance and mark the winner UNDECIDED — see ADR-0018, not invent one. Second, "add to the register in the PR that creates the divergence" needs a check to be real; a convention nobody enforces decays. I would extend launchpad-pr-check.yml to fail when a PR modifies an upstream-owned file with no matching register row.

   Evidence: row count equals the generator's file count; a script that regenerates the file list and diffs it against the register.

   SC4 — a conflict resolved once is not resolved again

   Achievable in weaker form than the PRD assumes. Two structural facts the PRD does not account for:

   • rerere state lives in .git/rr-cache/, which is per-clone and never committed. A GitHub Actions runner is ephemeral, so rerere gives the sync agent nothing unless rr-cache is persisted — via actions/cache, or committed to a dedicated branch. Contributor machines each get their own, independently.
   • Custom merge drivers are defined in git config, not in .gitattributes — deliberately, for security. merge=ours in .gitattributes is inert until every clone runs git config merge.ours.driver true. union is built in; ours is not.

   So both halves of the PRD's mechanism need a bootstrap that the PRD does not list. I would add a just upstream-sync-setup recipe (enable rerere, define the drivers) wired into just setup, plus a documented rr-cache persistence strategy for CI.

   Evidence: the PRD's own test — resolve lefthook.yml, discard the merge, re-merge, and paste git rerere status showing the replay. Run it twice on the same machine, and once on a second machine to demonstrate the sharing gap honestly.

   SC5 — semantic conflicts escalate with context

   Achievable. On non-zero merge exit: emit conflicted paths, the matching register rows, git log --oneline merge-base..upstream/main -- <path> per file, and a one-command local entry point (just upstream-sync-resume) that recreates the merge with the toolchain live. The escalation should be a GitHub issue or a draft PR with the conflict markers committed, not a Discord ping alone.

   Containment: upstream diff text is attacker-influenceable. launchpad/review-agent/CONTAINMENT.md and contain.py already exist for PR-authored text and should be reused verbatim rather than reinvented — the PRD says this and it is right.

   Evidence: the escalation artifact for today's real runtime.rs conflict, showing it names the code-motion cause.

   SC6 — just ci gates every sync PR

   Cannot be fully satisfied, and it is broken twice, not once.

   The PRD identifies one break: no required status checks (gh api .../branches/launchpad/protection returns "checks": null), and making one required is out of scope for me.

   The second break is not in the PRD. A PR opened by the Actions GITHUB_TOKEN does not trigger pull_request workflows. ci.yml's triggers are push: branches: [main, release] and pull_request: — a sync branch matches neither. So CI would not merely be un-required on the sync PR; it would not run at all. Fixing that needs either a GitHub App / PAT to author the PR, or an explicit push/workflow_dispatch trigger for sync branches.

   I can make CI run. I cannot make it required. I would state that gap in the register and the ADR rather than paper over it.

   SC7 — a contributor mid-feature is never first to discover an upstream conflict

   Satisfiable in practice, unfalsifiable as written. Contributors branch from and merge to launchpad; they never merge upstream. The real content is "the sync agent gets there first," which follows from cadence plus SC2/SC5. Evidence: a log of sync runs with dates and conflicted paths, so a contributor who does hit one can be traced to a specific gap. I would rewrite the criterion as a negative-observation record rather than pretend it is testable.

   SC8 — the agent never merges to launchpad

   Achievable, and enforced by the platform rather than by the agent's good behaviour: launchpad requires one approving review, and can_approve_pull_request_reviews is false for the Actions token. Evidence: the workflow's permissions: block, plus that API output. Belt and braces — a plan that relies only on the agent choosing not to merge is not a plan, given what the cohort already lost.

   ---

   2. Work items

   Each is one branch, one PR, against launchpad.

   #	Work item	Size	Depends on
   W1	Divergence register — launchpad/upstream-sync/DIVERGENCE-REGISTER.md, ~48 rows with a generator script for the file list. Winners recorded only where an authority exists; the rest marked UNDECIDED.	M	—
   W2	rerere + bootstrap — just upstream-sync-setup, wired into just setup; contributor docs. No .gitattributes change.	S	—
   W3	.gitattributes drivers, narrow — .github/ISSUE_TEMPLATE/config.yml only, plus the driver definition in W2's recipe. Explicitly not the ADR-0005 five, not bin/lefthook*, not lefthook.yml, with the reasoning in the PR body.	S	W1, W2
   W4	Clear the four conflicts — the first real sync, hand-resolved, with rerere recording. Four PRs or one, per §3.	L	W1, W2
   W5	Mirror workflow — scheduled FF of launchpad-26/main from upstream/main, failing loudly.	S	admin decision on main push restriction
   W6	Merge + PR workflow — attempt merge, open PR on success.	M	W5
   W7	Escalation path — conflict context bundle, just upstream-sync-resume, containment reuse.	M	W6, ADR-0021
   W8	Register enforcement — extend launchpad-pr-check.yml to require a register row for upstream-file changes.	S	W1
   W9	Sync-PR CI trigger — make ci.yml actually run on sync branches.	S	W6

   Four ADR issues (§4) are filed alongside, not counted as work items — per launchpad/AGENTS.md §4, an ADR is not a work item.

   ---

   3. Sequencing, and where the PRD's ordering is wrong

   W1 register ──┬─► W3 gitattributes ──┐
   W2 rerere  ───┴─► W4 clear conflicts ─┴─► W6 merge/PR ─► W7 escalate
                                         ▲                   W9 CI trigger
   W8 enforcement (after W1)             │
   W5 mirror ────────────────────────────┘   [gated on admin]
   

   Three departures from the PRD's implied order.

   (a) rerere must precede the first hand-resolution, not follow it. The PRD lists plumbing and register as parallel setup. But rerere only records resolutions performed while it is enabled. Resolving the four conflicts first and enabling rerere afterwards throws away the single most valuable training set the fork will ever produce. W2 is small and blocks nothing — it should land first, before anyone touches a conflict.

   (b) The register must precede the merge drivers, and it did the work of shrinking them. The brief I was originally given assumed the ADR-0005 five, bin/lefthook*, lefthook.yml, and the issue templates were all merge-driver candidates. Writing the register is what shows that all but one are wrong (§0.3). Any ordering that lets the drivers land first ships a change that reverses ADR-0005 by side effect.

   (c) Clearing the four conflicts should come before the automation, not after. The PRD treats the current backlog as the thing automation will handle. It is not — it is the thing that proves the automation is needed and supplies its test fixtures. A sync workflow built while the branch is 67 behind has no clean-merge path to exercise; every run escalates, and you learn nothing about SC2. Clear the backlog by hand with rerere on, then automate the steady state.

   On W4's shape: I would split it. Cargo.lock (regenerate) and .github/workflows/ci.yml (small — upstream replaced two of our steps with just file-size-check) are one PR. lefthook.yml is its own PR, because resolving it correctly means noticing the .lefthookrc/2.1.3 hazard in §0.4 and that is a reviewable judgement in itself. runtime.rs is its own PR: it is a code-motion-versus-edit conflict — we extracted persona_drift_state, workspace_pair_key and build_managed_agent_summary into runtime/summary.rs for the file-size ratchet, and upstream edited that block in place. Resolving it means porting upstream's edit into our extracted file and building it. No mechanism helps here; this is what escalation is for, and it is the best evidence for ADR-0020's boundary.

   ---

   4. The four ADRs

   ADR	Question	Blocks	Can proceed without it
   0018	Conflict-winner policy for the undecided divergences — per-file or per-category	W3 (which drivers), the winner column of W1	W1's reason/provenance columns; W2; W4's four resolutions (each is a specific technical call, not a policy)
   0019	Cadence — daily vs upstream-tag-triggered	The schedule: line in W5	Everything. Ship with daily and amend one cron line. Genuinely low-stakes; I would not let it block.
   0020	How far mechanical resolution may go before escalating	W6/W7's decision boundary	W1–W5, W8, W9
   0021	Where escalation runs — contributor machine vs provisioned environment; interacts with buzz-infrastructure #103	The runner half of W7	W7's context-bundle half. Emitting the bundle is independent of where the resume happens.

   0018 is the real gate and the one most likely to stall, because answering it means eight product-code files whose authors may not have thought about upstream conflict at all. I would file it with the register attached as evidence and a recommended default — upstream wins on product code unless a row says otherwise, fork wins on process and deployment files — so the decision is a yes/no on a concrete proposal rather than an open design question. 0019 should be decided by fiat in the PRD, not as an ADR; it is a cron expression, and giving it ADR weight adds a week of latency to a one-line change.

   ---

   5. What I would do first

   W2 then W1, in that order, and they are cheap.

   W2 is roughly an hour: a just upstream-sync-setup recipe running git config rerere.enabled true, git config rerere.autoUpdate true, and the merge-driver definition; a hook into just setup; a paragraph in launchpad/AGENTS.md §3 or a new launchpad/upstream-sync/README.md. It blocks nothing, it is reversible, and every hour it is not landed is an hour in which someone might resolve a conflict that is then lost. Evidence would be git config --get rerere.enabled before and after, pasted raw.

   W1 is most of a day. I have already derived the classification (48 files, 21/2/25 split, upstream-touched-since-merge-base per file) with a loop over git diff --name-status against both sides, so the mechanical part is done. The expensive part is the ~35 unrecorded reasons, which means reading four product-code commits and roughly a dozen process-file commits and writing down what they were actually for. Where I cannot determine intent I would write unrecorded — see #<commit>, not guess.

   What it would take beyond my own time: one admin decision before W5 can start — whether github-actions joins restrictions.apps on main, or the mirror moves to an unprotected branch. And one human to name owners for the product-code rows in the register; the "who to ask" column is worthless if I fill it in from commit authorship alone.

   ---

   6. What cannot be done

   Cannot be done at all, by me:

   • SC6 in full. Making a check required needs admin and is explicitly out of scope. I can make CI run on sync PRs (W9); I cannot make it block. Until someone does, a red sync PR is one approval away from landing, and the PRD's own security section is right to flag it.
   • The main fast-forward (SC1) until the push restriction is resolved. I have no path around it and would not want one.
   • Deciding any of the four ADRs. launchpad/AGENTS.md §5.1: draft everything, approve nothing.

   Cannot be done well in 27 days:

   • A register that is genuinely trustworthy on all 48 rows. I can produce all 48 rows with accurate mechanics and honest provenance. I cannot produce 48 rows with confident, owner-endorsed conflict winners without the ADR-0018 decision and several people's attention. A register with fabricated confidence is worse than one with UNDECIDED in it, so I would ship the honest version and let the winners fill in.
   • A proven steady state. SC4's real test is a repeat sync over the same file pair, and SC1's is a cadence sustained across periods. With 27 days and an unclear start on W5, there is time for perhaps two or three real sync cycles. That is enough to demonstrate the mechanism and not enough to demonstrate it is reliable. I would say so rather than let three green runs read as proof.

   Should not be done, though it was asked for:

   • merge=ours on the ADR-0005 five, bin/lefthook*, or lefthook.yml. §0.3. Each contradicts a written decision or discards substantial upstream work. If the intent behind that instruction was "make these stop conflicting," the honest answer is that they should keep conflicting, and the register's job is to make each conflict cheap to resolve rather than to make it disappear.

   Not verified: I have not run just ci, have not attempted a real merge in a working tree (I used git merge-tree --write-tree, which reports textual conflicts only), have not confirmed the four resolutions produce a building tree, have not tested rerere replay end to end, have not confirmed that adding github-actions to restrictions.apps actually permits the FF, and have not read the ~12 process-file commits behind the unrecorded divergences — only the four product-code ones. No VPS access and none needed here.

   ---

   _{Written by an AI agent (Claude Opus 5) on behalf of @tucktuck101, from direction given in session on 2026-08-21. Read-only investigation: gh issue view, gh api, git fetch, git diff, git merge-tree, and reading launchpad/AGENTS.md, ADR-0005, ADR-0017, launchpad/AGENT_PR_TEMPLATE.md. No repository files were changed, no commits, no pushes, no pull requests. This is a proposal, not a decision — nothing here is approved.}
4. tucktuck101

   added sub-issues on Aug 21, 2026

   • adr: the fork's standing position on each contested upstream file, and how each is enforced on a drop #294
   • adr: what prompts a vendor drop, and whether anything about it is scheduled #295
   • adr: how far the sync agent may resolve a conflict before escalating to a human #296
   • adr: where an escalated upstream merge conflict actually gets resolved #297
   • adr: who may advance launchpad-26/main to a chosen vendor point, and how #298
   • adr: what identity opens a sync pull request, given GITHUB_TOKEN-authored PRs do not trigger CI #299
   • adr: where rerere state and merge-driver config live, given git cannot ship them in the repo #300
   • adr: whether the divergence register is machine-checked, and what that costs contributors #301
   • adr: may a second vendor drop start before the previous one lands (narrowed — possibly foldable) #302
5. 36 remaining items

   Load more
6. tucktuck101

   removed sub-issues on Aug 24, 2026

   • adr: what identity opens a sync pull request, given GITHUB_TOKEN-authored PRs do not trigger CI #299
   • adr: where rerere state and merge-driver config live, given git cannot ship them in the repo #300
   • adr: whether the divergence register is machine-checked, and what that costs contributors #301
   • adr: may a second vendor drop start before the previous one lands (narrowed — possibly foldable) #302
   • adr: whether the review-agent containment contract extends to upstream-authored content #303
   • adr: what point launchpad-26/main is pinned to, and what advances it #305
   • adr: what the change agent produces for a vendor drop, and at what unit adoption is decided #306
   • adr: whether a standing disagreement is expressed as an edit to upstream's file or a fork-owned override #307
   • task: find out how downstreams detect a clean merge that is wrong, and how large that class is here #363
   • task: establish this fork's expected lifetime and who owns upstream adoption after the cohort #357
   • task: establish which upstream paths can affect what this cohort actually operates #355
7. tucktuck101

   added this to the Daily upstream sync live milestone on Aug 24, 2026
8. tucktuck101

   added a commit that references this issue on Aug 31, 2026

   Merge pull request #1923 from launchpad-26/sync-upstream-2026-08-31

   ...

   ed133f4
9. serina-mcfall

   added sub-issues on Aug 31, 2026

   • enhancement: PR #1925's security-implications section wrongly claims 'no executable code' #1976
   • task: reconcile PR #1925's launchpad/skills/ placement against PRD #273's stated launchpad/upstream-sync/ component table #1977