| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix(release-drop): kill the render-blocking remote font fetch (a) A release drop paints NOTHING until its stylesheets resolve, and the frame carried two remote font fetches: an app-injected Google Fonts <link> in every drop, and whatever @import an author wrote (the current RELEASE.md has one). On a network where fonts.googleapis.com is blocked — China — that fetch does not fail, it hangs to a TCP timeout, so the first thing a user sees on a new version is a blank paper rectangle for tens of seconds. This is the same render-blocking Google Fonts fetch the app itself removed for launch; the drop still did it. Three independent parts, so no single one is load-bearing: - The CSP can no longer permit a remote stylesheet or font. `style-src` drops `https:` (authored `<style>` still works via 'unsafe-inline'); `font-src` is `data:` only. A remote @import is now DENIED, and a denied import fails FAST and the frame paints immediately in the fallback, instead of hanging. - The design fonts are self-hosted as `data:` URIs (the same Inter + JetBrains Mono woff2 the app ships), so nothing legitimate needs the network and the drop keeps its typography with zero fetches. Inter answers the drop's --font-sans (its declared Geist substitute); JetBrains Mono is exact. - stripActiveContent drops an authored REMOTE @import outright, so the frame never even attempts it and no CSP-violation is logged. The regex consumes the whole statement including url-internal `;` (a font url is `wght@400;500;600`), which a naive `[^;]*` would truncate; a `data:` import is left alone. Proven, not asserted: rendered in a real sandboxed frame with the font host pointed at a non-routable IP (the honest simulation of a firewall DROP), the old build is a blank paper frame at 1.5s while this one is fully painted at the same instant, heading in self-hosted JetBrains Mono and body in self-hosted Inter. RELEASE.md is untouched — this makes ANY authored drop safe, not just the current one. Tests mutation-checked. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LDbmAwrgtGskFGCRkYZBx4 | 11 天前 | |
docs(contributors): land the 28 the workflow generated but could not push CONTRIBUTORS.md said 38 people and contained none of the v050 wave. A contributor had to write in and ask why he was not on it (#218, AmIrRX0), and he was right to. The generator was never the problem. It ran on the merges and produced the correct file; the push was rejected, because a bot pushing straight at main carries no status checks and main requires three: remote: error: GH006: Protected branch update failed for refs/heads/main. remote: - 3 of 3 required status checks are expected. So this is that same regeneration, run by hand and pushed the way the wave was. 38 people -> 52. Nobody who was already listed was dropped. All 20 authors from the wave now appear, AmIrRX0 and wckleinhenz among them. Two prose changes, both in the generator rather than the .md, because a hand edit to the .md is wiped by the next run: - Added a paragraph under the avatar strip. Those avatars come from GitHub's contributors graph, which keys on commit author email, so five people in this wave are missing from it: two used a work address they can still attach to their account, and two used a .local machine name that can never be attached because GitHub cannot verify a fake domain. The paragraph says so plainly and says this table is the list to go by. - Softened one existing sentence. It claimed the file 'regenerates whenever a pull request merges', which is the exact promise that just failed in public. It now says it is regenerated from merged pull requests, which is true either way and does not depend on the push path being unblocked. Not fixed here, deliberately: the workflow still cannot push to a protected main. That is a branch protection decision and it is the founder's to make. No history was rewritten and no commit's authorship was touched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EmZGHZkLeKXWxrFVPmUPxW | 6 小时前 | |
feat(i18n): localize long-tail components (T1b) Extend react-i18next coverage to the remaining UI surfaces: SetupPanel, AiEnginesSettings, McpDefaultsSettings, RealtimeDevicePicker, RealtimeMichaelToggle, triggers/* (all tabs + shared ui), MessageQueueComposer, TasksKanban, FileTree, GitTab, FullscreenFileEditor, FullscreenTerminal, MemoryPanel, MemoryGraphPanel, ThreadsPanel, SkillsTab, WorkersTab, IntegrationsRegistry, UpdatesSection, IdePanel, GitPanes, ImagePreview. Locale files grow to 1122 keys each, still perfectly aligned. Adds a scripts/merge-i18n-fragments.cjs helper (batched fragment merge with collision + parity checks). Kept English by design: Slack/Webhook long API docs, HIRE_PROMPT and agent-prompt templates, CLI endpoint hints, and model/engine proper nouns. Co-Authored-By: Claude <noreply@anthropic.com> | 13 天前 | |
fix(hive): re-arm message router on system resume so delivery survives sleep The hive outbox→inbox router is a setInterval (hive.routeOnce every ~1.5s) that freezes during true macOS system sleep, just like the mission scheduler and the always-on beats. onSystemResume() already re-armed the scheduler, the fleet/breaker beats, and keep-awake on powerMonitor resume/unlock-screen — but never re-armed the router. After a long sleep (laptop closed overnight) the scheduler→god path recovered (it injects straight into god's inbox) while every agent's outbox silently stopped draining: god→worker, worker↔worker, and broadcast mail piled up undelivered and no `message` event was logged. Fix: in onSystemResume, re-arm the router (clear-then-set, idempotent) and immediately drain the backlog accrued during sleep instead of waiting for the first post-wake tick. The renderer's existing idle inbox-wake nudge then wakes each parked recipient once its mail lands. - Completes the 0.3.0 wake-reliability hardening (schedules + terminals) with the router, the one wake-frozen timer that was left out. - Extends scripts/verify-keepalive-catchup.mjs to reproduce the pre-fix backlog stall and prove the re-arm + immediate flush (all 13 checks pass). - Docs: CHANGELOG/RELEASE 0.3.1, README wake-reliability line, landing version strings, package.json 0.3.0 → 0.3.1. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> | 2 个月前 | |
feat(worker): P4 lifecycle hardening — worktree GC + token-cap wiring + Workers tab Hardens the Phase-1 ephemeral-worker loop (god-triggered Slack workers) in three parts; all main-process + one additive renderer tab, no push (god integrates). (a) GC of preserved worktrees + scratch dirs. finalizeWorkerWorktree now TRACKS every worktree it preserves (held because it had unintegrated work); a throttled sweep in the worker tick reclaims each — the worktree + its hive scratch dir (HIVE_ROOT/agents/<id>) — once its work is integrated, or when god removed the worktree by hand. Fail-safe: a new git helper worktreeIsGcSafe removes ONLY when the tree is clean AND the content is in base (rev-list base..HEAD==0 OR `git diff base HEAD` empty), handling FF, merge-commit AND squash landings; any uncertainty KEEPS the worktree. No-op (zero cost) when nothing is preserved. Scratch-dir removal is DEFERRED to the delayed sweep even on clean teardown, so the MemPalace miner has a window to ingest the worker's memory.md before it's reclaimed. Sweep skips any worker id that is live again (reqId reuse) so it never GCs an active run. (b) Per-worker token-cap mechanism, DEFAULT UNLIMITED. WorkerRec carries an optional tokenCap from the spawn-request; new config defaultWorkerTokenCap (default 0 = unlimited) is the global fallback. The tick reaps a worker only when an effective cap > 0 is exceeded (usageProvider total tokens). Pure plumbing — never throttles unless a positive cap is set (human directive: NO per-worker cap today). (c) Workers tab. New workers:list / workers:stop IPC + preload bridge + WorkersTab.tsx + a Command Center tab: lists live workers (status, age, idle, tokens/cap, slack) with a manual Stop (safety-gated teardown), plus the preserved-worktrees-awaiting-GC list. Verify: typecheck:node + typecheck:web + electron-vite build all exit 0; scripts/verify-worker-gc.mjs proves the GC gate 6/6 (un-integrated/dirty/ untracked KEEP; fast-forward/squash/empty GC) exit 0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> | 2 个月前 | |
fix(wall-sync): the scope-filter comment keeps the reasoning, drops the count The epoch filter's comment carried an absolute count of records in our Razorpay account. The count is not load-bearing: the comment only has to explain why the date guard exists, and "the much larger body of legacy records that predates the wall" explains it exactly as well. Same shape as #233 on costLifetime.ts. Per the standing rule: absolute internal figures never go public; a base-free ratio that characterises a bug or behaviour is not an internal figure and may stay. The test is whether a reader can recover a business quantity from it. This reduces the surface going forward. It retracts nothing — the git history still carries the figure. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0111uSG4Ge2U6nUxnea7ZfeY | 15 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 11 天前 | ||
| 6 小时前 | ||
| 13 天前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 15 天前 |