用 dsh 搭一座博客：从规范开始

这是骨架期写入的样章，用于验证「schema → loader → 派生函数 → 页面」的全链路可用性。

为什么要先写规范

dsh 是 AI 开发 Agent，它最怕的不是难，而是含糊。同一句「做个好看的博客」，在不同轮次里会被理解成完全不同的东西； 而 docs/SPEC.md 把「好看」拆成了色值、字号、间距、动效时长这些可以被执行、也可以被验收的条目。

规范的价值不在于文档本身，而在于让「返工」发生在纸上而不是代码里。

两层架构

层	内容	是否上线
开发工具层	dsh + 插件 / 技能 + SDD 工作流	否，仅开发期存在
博客运行时层	Astro 构建产物 + CDN + 第三方服务	是

这个分离带来的直接好处：dsh 的破坏性变更、插件质量问题只会影响开发层；运行时层是确定性的静态产物，随时可回滚。

代码块验证

// src/lib/posts.ts 的派生函数契约（SPEC §6.4）
export async function getFeatured(n = 5): Promise<PostSummary[]> {
  const all = await getPostSummaries();
  return all.filter((p) => p.pinned).concat(all.filter((p) => p.featured)).slice(0, n);
}

下一步

阶段 3 会把首页从「方向预览页」替换为真实组件（Hero / PostCard / PostList），所有视觉细节仍以 docs/SPEC.md §3 的 token 为准。