notturno: upstream merge 2026-08-04 (v1.18.10 → v1.18.12) - #119
Conversation
Co-authored-by: Luke Parker <10430890+Hona@users.noreply.github.com>
Co-authored-by: Aiden Cline <rekram1-node@users.noreply.github.com>
Co-authored-by: LukeParkerDev <10430890+Hona@users.noreply.github.com>
Co-authored-by: Aiden Cline <rekram1-node@users.noreply.github.com>
CI review — compared against base
|
| check | base | this branch | verdict |
|---|---|---|---|
| typecheck | pass | pass | clean |
| unit (linux) | 11 fail | 9 fail | strict SUBSET of base — 8 documented pasqal reds + 1 slow subprocess flake; zero new failures |
| e2e (linux) | failure | failure | shared flakes only, plus 2 merge-new specs (below) |
| e2e (windows) | failure (6 workbench specs) | failure (2 specs) | the 6 base workbench failures PASS here; plus the same 2 merge-new specs |
The 2 merge-new e2e failures — deterministic, root-caused
Both live in upstream's OWN new spec from v1.18.12, packages/app/e2e/regression/project-picker-recent-search.spec.ts ("just the five most recent", "caps the recent list at five"). All 12 attempts (2 specs × 3 tries × 2 platforms) die at the same place: expectAppVisible(add) — the 45s wait for getByRole("button", { name: "Add project" }).
Root cause: the spec drives upstream's home chrome; the fork's home renders that control conditionally — titlebar button iff exactly one server (home.tsx:1304), otherwise hover-gated per-row buttons — and the fork's own e2e suite opens the dialog via [data-action="home-add-project-row"] (home-projects-view.tsx:397). This is a chrome-contract divergence (ADR 0001 home rebuild), not a product regression: the v1.18.12 search-across-all-projects logic merged fine, the fork's dialog exists, and the assertions past the entry point were never reached.
Recommendation
Patch the spec's entry selector to the fork's affordance (one line — matches the fork's own e2e convention), keeping upstream's five-cap + search-all assertions intact:
// was: page.getByRole("button", { name: "Add project" }).first()
const add = page.locator('[data-action="home-add-project-row"]').first()(or take it as a follow-up issue and merge as-is — e2e red is the fork's status quo modulo these two specs.)
… no add-project surface (see #120) The spec drives upstream's home-projects surface ('Add project' on the home page). The fork's NewHome (ADR 0001) has no add-project entry point and the legacy interface is compile-time retired (settings.tsx: newLayoutDesigns is hard-coded true). The v1.18.12 five-cap + search-all logic ships intact in dialog-select-directory.tsx; re-enable per #120.
Resolution of the 2 e2e failures — skipped, with a paper trailPushed Why skip rather than patch the selector (the full archaeology is in the comments above): every fork path to the dialog turned out to be closed by design —
The v1.18.12 logic the spec guards (five-cap display, search across all recents) ships intact in Expected CI shape now: typecheck pass; unit = the base's known reds (8 pasqal + flaky subprocess timeouts); e2e = base's shared flakes minus this spec (skipped) — i.e., strictly the fork's status quo. |
Final CI verdict (
|
| check | result | vs base cf4f06b41 |
|---|---|---|
| typecheck | pass | — |
| unit (linux) | fail 11m | subset of base: same 8 pasqal known-reds + subprocess-spawn timeout flakes (count varies 1/3/6 across identical-tree runs incl. base — runner load, documented flaky family) |
| e2e (linux) | fail 31m | zero new failures — failure set identical to base; the project-picker spec reports as skipped |
| e2e (windows) | fail 35m | zero new failures — and 3 of base's workbench flakes passed here |
The merge is ready for human review and merge. Remaining out-of-band items: rotate HARMONIQS_ORG_READ_PAT (leaked into harmoniqs/amico#322's original body — redacted since), add HARMONIQS_ORG_WRITE_PAT to harmoniqs/amico so the sentinel can open its own PRs, and merge harmoniqs/amico#324 so the sentinel's next run creates its merge commit in-CI.
11 participants
Upstream merge sentinel — 2026-08-04 (hand-completed)
upstream/dev@7fe99387(v1.18.12) intolocal/amicode@cf4f06b41reasoning_text, custom field names); Azure GPT-5.5+ reasoning fix; composer draft-store; project search across all recent projects; stale-error clearing; legacy-config skip for v2 servers; desktop fixessession-side-panel.tsxdeletions (ADR 0001) stand, versions at 1.18.12Why hand-completed
The sentinel's first dry-runs tonight (harmoniqs/amico#322) merged the tree cleanly but died creating the merge commit: the hermetic clone had no git identity, so
git merge --no-ffexited nonzero with zero conflicted paths — reported as a phantom "merge conflict (0 path(s))". Module fix: harmoniqs/amico#324. This branch was produced locally by the same machinery (same SHAs, parity re-verified post-merge) with an identity present.Verification
parity_checkon the merged tree: no missing files, no missing strings, no conflict markers.git diff local/amicode...HEAD --statfiltered to amicode paths: empty — the merge touched no fork patch.reasoning_textpresent inpackages/llm/src/protocols/openai-responses.ts(the v1.18.11 provider fix landed).Release-gate CI should do the rest; build + smoke-verify on the dev host before tagging
v1.18.12-amicode.1(per the AMICODE-PATCHES.md release ritual).Sentinel rule: it never pushes to a protected branch; a human reviews and merges.