diff --git a/AMICODE-PATCHES.md b/AMICODE-PATCHES.md index 0a839a745e..e5eba9e0fb 100644 --- a/AMICODE-PATCHES.md +++ b/AMICODE-PATCHES.md @@ -225,6 +225,7 @@ Rebuilt with the exact T3 recipe (`OPENCODE_VERSION=1.17.3 bun run script/build. - index.css: @font-face for both (JuliaMono full glyph set — Julia Unicode; Racing Sans One latin subset, font-display swap). logo.tsx + wordmark-v2.tsx: font-family 'Racing Sans One' first, weight 700→400. settings.tsx: monoDefault/monoFallback lead with JuliaMono. theme.css: --font-family-mono leads with JuliaMono. Terminal font DELIBERATELY unchanged (JetBrainsMono Nerd Font Mono via separate terminalFallback). - New assets (git-added — build breaks without them): public/assets/RacingSansOne-Regular.woff2 (21 KB) + JuliaMono-Regular.woff2 (946 KB). - Font build sha256: `2a15da111be516516fb1fbd1a4fb5ae02ad9bddd6373ede08cdf7b28c19d163a` (dist/opencode-local + vendored path, write-temp + mv -f swap; SUPERSEDES #13's a73d8583… — same code, fonts now committed). Verify (scratch port 14099): `GET /assets/RacingSansOne-Regular.woff2` → 200 font/woff2 21804 B; `GET /assets/JuliaMono-Regular.woff2` → 200 font/woff2 946516 B; "Racing Sans One" in built css + index/new-session chunks, "JuliaMono" in `index-Dwtxigfs.css`; `GET /amicode/problems` → 200; `GET /` → 200 `Amicode`; ui `bun test src` → 70 pass; typecheck green ui+app (no snapshots assert fonts, per Aaron — confirmed nothing went red). Bonus confirmation: KaTeX\_\* woff2 assets now in dist — the entity view's katex import (#13) pulls its font set into the embed. + 9. (home CTA fallback) — amicode(home): "Open chat" works on a fresh profile. - BUG: `startWithPrompt` (fork wiring for the Meet-Amico card, patch 5ef6b7e0e) dead-ended silently when the persisted client-side project list was empty (fresh browser profile @@ -246,7 +247,30 @@ Rebuilt with the exact T3 recipe (`OPENCODE_VERSION=1.17.3 bun run script/build. if something else (e.g. the harmoniqs website dev server) holds 3000. - Checks: `tsgo -b` clean; `bun run test:unit` 376 pass / 0 fail. -15. (mark drift fix, synced to amicode PR #99 final) — amicode: consolidated the fork's brand mark to ONE geometry, matching amicode's redesigned mark. The "kept in sync manually" cross-repo promise from patch #8 had already silently failed. +15. (Aero wordmark, re-added) — amicode: AMICODE wordmark/logo font-family gains `'Aero'` ahead of the existing fallback chain, both call sites: logo.tsx (`'Aero', var(--font-family-sans, ...)`) and wordmark-v2.tsx (`'Aero', 'Racing Sans One', var(--font-family-mono, ...)`). Additive only — no fallback removed, no sizing/weight/spacing touched. This had been iterated as uncommitted working-tree WIP before the branch fast-forwarded 57 commits to current `origin/local/amicode` (e9b695191); re-applied fresh against the current font stacks (logo.tsx's had independently moved to a sans-serif stack + weight 750/letter-spacing 4 in the interim — preserved as-is, only the family list changed). + + > ⚠️ **LICENSE-PENDING — release blocker.** "Aero" by Nirmal Biswas (Picatype) is donationware, USD 25+ to nirmalbiswas@gmail.com. Bundled at `packages/app/public/assets/Aero-Regular.ttf` for PREVIEW ONLY; not locked as the official face. Before any release: pay the license and record proof here, or drop `'Aero'` from both `font-family` chains + remove its `@font-face` (index.css) + the asset. + + - index.css: new `@font-face` for "Aero" (truetype, weight 400, `font-display: swap`), inserted immediately before the existing Racing Sans One face; carries the license-pending comment inline. + - New asset (git-added): `public/assets/Aero-Regular.ttf` (44,464 B). + - Verify: `bun run typecheck` green in both `packages/ui` and `packages/app` (tsgo, no errors). Visual/glyph confirmation is manual-only (see build note under #16, which builds and vendors this alongside the paste fix). + +16. (composer paste bridge) — amicode: wire the main chat composer's `handlePaste` (prompt-input/attachments.ts) to the extension-clipboard bridge that patch #14's PR already shipped for a different input (home-cards.tsx's `readClipboardViaBridge`/`pasteFallback`, commit `5a2f1dde44`) — that bridge answers `{source:"amicode", kind:"clipboard-request"}` on the extension side (`packages/extension/src/chat_panel.ts`, already on `main`), but nothing in the composer's own paste path ever sent it. Root cause matches home-cards.tsx's own comment verbatim: the chat iframe is sandboxed + cross-origin, so `navigator.clipboard` is denied and the native `paste` event's `clipboardData` arrives empty — Cmd/Ctrl+V into the composer was a silent no-op. + + - platform.tsx: new optional capability `readClipboardText?(): Promise`, alongside the existing `readClipboardImage?`. + - entry.tsx: implements it — no-op (`null`) when not framed (`window.parent === window`, i.e. plain browser/opencode.ai/desktop — zero behavior change there); when framed, posts `{source:"amicode", kind:"clipboard-request", nonce}` to `window.parent` and resolves on the matching `{kind:"clipboard", nonce}` reply or a 1500 ms timeout — same nonce/timeout/listener shape as the proven `readClipboardViaBridge`, just exposed as a platform capability instead of a component-local closure (this file already hosts the analogous `readClipboardImage`). + - attachments.ts: `handlePaste` no longer bails out when `event.clipboardData` is null (only when it's ALSO missing `readClipboardText`, i.e. non-amicode contexts are untouched); after the existing file/image-bridge attempts, falls back to `readClipboardText()` when there's still no plain text. + - prompt-input.tsx: threads `readClipboardText: platform.readClipboardText` into `createPromptAttachments`, mirroring `readClipboardImage`. + - No shared bridge module extracted — matches this codebase's existing precedent (home-cards.tsx's bridge is also component-local, not a shared util); two call sites isn't yet worth a shared abstraction. + - Tests: app `bun test` (66 files) → 376 pass / 0 fail, incl. the untouched `attachments.test.ts` (pure-function coverage only — `handlePaste` itself has no unit coverage in this codebase, matching home-cards.tsx's own bridge having none either; verification here is typecheck + build + the manual live-paste check below). Typecheck green in `packages/app`. + - Build sha256 (composer-only build, superseded by the generalization below): `564a4cd783524e0f50541b716d9db4048b2e02430ebc77786a11a4504431c085`. + - **ADDENDUM (same session, live-test finding — Aaron): composer-only wiring wasn't enough.** Confirmed live: pasting into a _different_ editable (the generic "Connect \" API-key dialog, `dialog-connect-provider.tsx` — one of many such generic settings/connect forms) was still a silent no-op, because that dialog is a plain `` with no knowledge of the bridge at all. This is the exact gap patch #14's era of WIP had already found and fixed once before (composer-only interception "left every OTHER editable broken (provider API-key field, etc.)") — generalized properly this time instead of re-patching one dialog at a time: + - entry.tsx: new `installGlobalPasteFallback()`, installed once at app mount (alongside `readClipboardText`, not a separate file — same feature area). A single `document`-level `paste` listener: activates only when the event target is a form field or `contenteditable` AND the native `event.clipboardData` gave no plain text (the sandboxed-iframe symptom) — everywhere clipboardData already works (plain browser tabs, desktop) it's a pure no-op, no framed-check needed at the call site. On activation: fetches text via the same `readClipboardText` bridge, then splices it into ``/`