@pieai/pro-gov 0.4.4 → 0.4.5

package/assets/docs/reference/adoption/adoption-playbook.md

@@ -221,7 +221,7 @@ Add:
 - AI-in-the-Loop rules linked from the project's external shared-rule source
 - canon/provenance/archive rules in `docs/policy/best-practice-for-this-project.md`
 
-Do not add engineering TDD workflow plugins or Directed Development by default.
+Do not add engineering test workflow plugins by default.
 Use `capture-learning` only for a real reusable lesson that belongs in that
 workspace.
 

package/assets/docs/reference/adoption/recommended-agent-tooling.md

@@ -30,9 +30,9 @@ work; tools and skills add capabilities only when their narrow trigger matches.
 | `@pieai/doc-gov` | required | Governed-document and router validation |
 | mattpocock/skills | available | Optional specialist toolbox; no bootstrap or workflow owner |
 | `capture-learning` | available | Save a verified reusable lesson after completed work |
-| Superpowers | not installed | Retired mandatory workflow plugin |
-| Compound Engineering | not installed | Retired; native PGS capture keeps the useful learning loop |
-| Ponytail | not installed | Retired global mode/hooks; ordinary engineering judgment stays lean |
+| Superpowers | do not install | Retired mandatory workflow plugin |
+| Compound Engineering | do not install | Retired; native PGS capture keeps the useful learning loop |
+| Ponytail | do not install | Retired global mode/hooks; ordinary engineering judgment stays lean |
 
 Before non-trivial work:
 

package/assets/profiles/doc-only/manifest.yml

@@ -8,8 +8,6 @@ required:
     source: external shared-rule SSOT
   agents_routing: docs/governance/agents-routing/doc-only-v0.9.md
   current_work: docs/reference/execution/current-work.md
-optional:
-  directed_development: false
 project_local_required:
   - docs/policy/best-practice-for-this-project.md
   - canon/provenance/approval boundaries

package/assets/profiles/doc-only/profile.md

@@ -14,7 +14,6 @@ Use for non-runtime projects: IP development, AI media production, research vaul
 ## Does Not Include By Default
 
 - engineering-runtime agents routing
-- Directed Development
 - engineering TDD workflow plugins
 - behavior-critical code lanes
 

package/assets/profiles/engineering-runtime/manifest.yml

@@ -9,7 +9,6 @@ required:
   agents_routing: docs/governance/agents-routing/engineering-runtime-v0.9.md
   current_work: docs/reference/execution/current-work.md
 optional:
-  directed_development: integrations/directed-development.md
   mattpocock_skills: integrations/mattpocock-skills.md
 project_local_required:
   - docs/policy/best-practice-for-this-project.md

package/assets/profiles/engineering-runtime/profile.md

@@ -9,7 +9,6 @@ Use for code-heavy projects: apps, games, runtimes, services, browser products,
 - `docs/governance/ssot-v0.9.md`
 - external AI-in-the-Loop policy linked by target projects under `docs/policy/shared-rules/ai-in-the-loop.md`
 - `docs/governance/agents-routing/engineering-runtime-v0.9.md`
-- `integrations/directed-development.md`
 - `integrations/mattpocock-skills.md`
 - starter `docs/governance/` and `docs/policy/` templates
 

package/assets/starter/AGENTS.template.md

@@ -40,11 +40,9 @@
 
 - Name this project's adopted profile: `engineering-runtime` or `doc-only`.
 - Point to the chosen agents-routing file from `docs/governance/agents-routing/`.
-- Codex and this router own normal execution. Optional skills run only when their own narrow trigger directly matches the selected lane.
-- mattpocock/skills may remain available as an unchanged shared toolbox; there is no bootstrap skill or mandatory workflow owner.
 - Before non-trivial work, use Learning Recall. After verified work, use `capture-learning` only when a non-obvious reusable lesson exists.
 - Do not install Stop/SubagentStop workflow reminder hooks.
-- Doc-only projects should say that engineering TDD and Directed Development are not enabled by default.
+- Doc-only projects should say that engineering test workflows are not enabled by default.
 
 <!-- PGS-ROUTER:END -->
 

package/assets/starter/docs/governance/agents-routing/doc-only-v0.9.md

@@ -24,7 +24,7 @@ superseded_by: null
 
 Shared routing algorithm for non-runtime projects such as AI media, IP development, research, and asset governance workspaces.
 
-This route does not use engineering TDD or Directed Development by default.
+This route does not use engineering test workflows by default.
 
 ## Core Flow
 
@@ -52,7 +52,6 @@ flowchart TD
 ## Rules
 
 - Do not ask whether the task needs TDD unless the project has actual runtime code.
-- Do not trigger Directed Development unless the project explicitly opts in.
 - Prefer SSOT, provenance, and approval clarity over engineering ceremonies.
 - Use AI-in-the-Loop for evidence: inspect source, change one thing, verify the target document or asset path.
 
@@ -76,8 +75,7 @@ written as Markdown. Governed docs record decisions, plans, references, policies
 and workspace truth. Product artifacts stay in the project package or workbench
 unless the project explicitly opts them into doc-gov.
 
-## External Workflow Boundary
+## Host Adapter Boundary
 
-This route runs before optional skill packs.
 Host-specific adapters such as `CLAUDE.md` may adapt the route for a specific AI
 client, but they must not replace the project `AGENTS.md` route.

package/assets/starter/docs/governance/agents-routing/engineering-runtime-v0.9.md

@@ -32,12 +32,8 @@ This file decides **how to choose a workflow**, not what the project is currentl
 flowchart TD
   A["Task arrives"] --> B["Read project router and current work"]
   B --> C["Classify with local lane profile"]
-  C --> D{"Mixed / cross-domain / interdependent product work?"}
-  D -- "yes" --> E["Use Directed Development to split ordered DD Blocks"]
-  E --> C
-  D -- "no" --> F["Enter local lane"]
-  F --> G["Use a narrowly matched skill only when helpful"]
-  G --> H["Use AI-in-the-Loop evidence cycle"]
+  C --> F["Enter local lane"]
+  F --> H["Use AI-in-the-Loop evidence cycle"]
   H --> I["Record evidence in doc-gov"]
 ```
 
@@ -45,16 +41,6 @@ flowchart TD
 
 Use this router only to pick depth and workflow. Do not use it as a project roadmap.
 
-## DD Trigger
-
-Use Directed Development only when all are true:
-
-- the task is product work
-- it crosses local lanes or shared contracts
-- sequencing risk makes a flat plan unsafe
-
-Do not trigger DD for broad mechanical edits, renames, formatting, or ordinary docs migration.
-
 ## Project-Local Lane Profile
 
 Every engineering project must define its own lane profile in `AGENTS.md` or `docs/policy/best-practice-for-this-project.md`.
@@ -68,12 +54,7 @@ Typical lanes:
 
 But the shared router must not define project-specific lanes.
 
-## External Workflow Boundary
-
-This route runs before optional skill packs such as mattpocock/skills. Skills
-may provide reviews, browser workflows, PRD/issue shaping, or domain-modeling
-artifacts, but their own narrow trigger must match the selected lane. No skill
-pack owns every engineering task.
+## Host Adapter Boundary
 
 Host-specific adapters such as `CLAUDE.md` may adapt the route for a specific AI
 client, but they must not replace the project `AGENTS.md` route.

package/dist/cli.js

@@ -93,6 +93,7 @@ function createNpxSkillsMaintenancePlan(options) {
   if (options.operation === "update") {
     assertNoReportedPartialUpdateFailure(result.stdout, result.stderr);
   }
+  assertNoDeprecatedMattSkills(tempRoot);
   const after = snapshotFiles(tempRoot);
   const changes = diffSnapshots(before, after);
   return {
@@ -117,6 +118,16 @@ ${stderr}`.replace(/\u001B\[[0-?]*[ -/]*[@-~]/g, "");
     throw new Error(`npx skills update reported a partial failure: ${failure[0]}`);
   }
 }
+function assertNoDeprecatedMattSkills(npxRoot) {
+  const lockPath = join3(npxRoot, "skills-lock.json");
+  const lock = JSON.parse(readFileSync2(lockPath, "utf8"));
+  const deprecated = Object.entries(lock.skills ?? {}).filter(
+    ([, entry]) => entry.source === "mattpocock/skills" && entry.skillPath?.startsWith("skills/deprecated/")
+  ).map(([name]) => name).sort();
+  if (deprecated.length > 0) {
+    throw new Error(`npx skills plan contains deprecated mattpocock skills: ${deprecated.join(", ")}`);
+  }
+}
 function assertNativeNpxRoot(npxRoot) {
   if (!existsSync3(join3(npxRoot, "skills-lock.json"))) {
     throw new Error(`npx skills root is missing skills-lock.json: ${npxRoot}`);
@@ -2441,6 +2452,10 @@ function formatProjectLensAuditCheckText(result) {
 function formatProjectLensInspection(report) {
   return [
     `target: ${report.targetDir}`,
+    `scan-scope: ${report.scanScope.mode}`,
+    `candidate-files: ${report.scanScope.candidateFileCount}`,
+    `included-files: ${report.scanScope.includedFileCount}`,
+    `excluded-files: ${report.scanScope.excludedFileCount}`,
     `ai-entry-files: ${formatList(report.aiEntryFiles)}`,
     `ai-config-files: ${formatList(report.aiConfigFiles)}`,
     `package-scripts: ${formatList(report.packageJson?.scripts ?? [])}`,
@@ -2462,6 +2477,10 @@ function renderProjectLensMarkdownReport(report) {
     `- Target: \`${report.targetDir}\``,
     `- Generated: ${(/* @__PURE__ */ new Date()).toISOString()}`,
     "- Scope: local read-only evidence for AI-assisted project review",
+    `- Evidence mode: ${report.scanScope.mode}`,
+    `- Candidate files: ${report.scanScope.candidateFileCount}`,
+    `- Included files: ${report.scanScope.includedFileCount}`,
+    `- Excluded vendor/cache files: ${report.scanScope.excludedFileCount}`,
     "",
     "## AI Entry Files",
     "",
@@ -2522,11 +2541,20 @@ var ignoredDirectories = /* @__PURE__ */ new Set([
 ]);
 function scanProjectLensTarget(targetDir, options = {}) {
   const largeFileBytes = options.largeFileBytes ?? 5e4;
-  const files = listProjectFiles(targetDir);
-  const markdownFiles = files.filter((file) => file.endsWith(".md"));
+  const candidateFiles = listProjectFiles(targetDir);
+  const files = candidateFiles.filter(isFirstPartyEvidenceFile);
+  const markdownFiles = files.filter(
+    (file) => file.startsWith("docs/") && file.endsWith(".md")
+  );
   const packageJson = readPackageJson(targetDir);
   return {
     targetDir,
+    scanScope: {
+      mode: "first-party",
+      candidateFileCount: candidateFiles.length,
+      includedFileCount: files.length,
+      excludedFileCount: candidateFiles.length - files.length
+    },
     aiEntryFiles: ["AGENTS.md", "CLAUDE.md"].filter(
       (file) => existsSync17(join17(targetDir, file))
     ),
@@ -2575,10 +2603,31 @@ function runGit(targetDir, args) {
   return { ok: true, stdout: result.stdout.trim() };
 }
 function listProjectFiles(targetDir) {
+  const gitFiles = runGit(targetDir, [
+    "ls-files",
+    "--cached",
+    "--others",
+    "--exclude-standard",
+    "-z"
+  ]);
+  if (gitFiles.ok) {
+    return gitFiles.stdout.split("\0").filter(Boolean).map(toUnixPath4).filter((file) => existsSync17(join17(targetDir, file))).sort();
+  }
   const files = [];
   collectFiles2(targetDir, targetDir, files);
   return files.sort();
 }
+var excludedEvidencePrefixes = [
+  ".agents/manual-skills/",
+  ".agents/skills/",
+  "agent-assets/skills/npx-skills/",
+  "third-party/",
+  "third_party/",
+  "vendor/"
+];
+function isFirstPartyEvidenceFile(file) {
+  return !excludedEvidencePrefixes.some((prefix) => file.startsWith(prefix));
+}
 function collectFiles2(rootDir, currentDir, files) {
   if (!existsSync17(currentDir)) return;
   for (const entry of readdirSync7(currentDir, { withFileTypes: true })) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pieai/pro-gov",
-  "version": "0.4.4",
+  "version": "0.4.5",
   "description": "Project-level distribution kit for Project Governance System.",
   "keywords": [
     "ai-agents",
@@ -35,7 +35,7 @@
     "access": "public"
   },
   "dependencies": {
-    "@pieai/doc-gov": "^0.4.4"
+    "@pieai/doc-gov": "^0.4.5"
   },
   "devDependencies": {
     "@types/node": "24.13.2",

package/assets/docs/reference/adoption/agent-workflow-methodology-comparison.md

@@ -1,339 +0,0 @@
----
-id: REF-AGENT-WORKFLOW-METHODOLOGY-COMPARISON
-title: Agent Workflow Methodology Comparison
-type: reference
-status: superseded
-canonical: false
-owner: project
-created: 2026-07-06
-last_reviewed: 2026-07-06
-domain: adoption
-tags:
-  - agent-workflows
-  - superpowers
-  - compound-engineering
-  - mattpocock-skills
-  - wayfinder
-pinned: false
-related:
-  - REF-PUBLIC-RELEASE-CHECKLIST
-  - REF-DOWNSTREAM-PROJECT-REGISTRY
-superseded_by: REF-RECOMMENDED-AGENT-TOOLING
----
-
-# Agent Workflow Methodology Comparison
-
-> Historical snapshot only. The current decision is documented in
-> [Recommended Agent Tooling](recommended-agent-tooling.md): Superpowers,
-> Compound Engineering, and Ponytail are retired from the installed PGS stack;
-> Matt skills remain a trigger-based library, and `capture-learning` preserves
-> the small reusable-learning loop. The older analysis below is retained as
-> decision history, not current guidance.
-
-本文比较 4 套 AI agent 工作方法，观察时间点是 2026-07-06：
-
-1. **Superpowers**
-2. **Compound Engineering**
-3. **Matt Pocock skills 主流程**
-4. **Matt Pocock Wayfinder**
-
-小学生版本：这 4 套东西都不是“更聪明的魔法咒语”。它们更像 4 个不同的帮手。
-
-- Superpowers 像工地施工队长。
-- Compound Engineering 像厨师的复盘菜谱本。
-- Matt 主流程像采访员、产品经理、拆票员三个人排队帮你。
-- Wayfinder 像走进大雾森林前的画地图的人。
-
-## 版本和证据
-
-这是一个时间点快照，不是永久真理。Wayfinder 现在变化尤其快。
-
-| 系统 | 本次观察到的版本或来源 | 证据 |
-| --- | --- | --- |
-| PGS | 本地 package 版本 `0.4.0` | `package.json`，2026-07-06 检查 |
-| Superpowers | 本机 Codex 插件 `6.1.1` | 本地 `.codex/plugins/cache/superpowers-dev/superpowers/6.1.1`；上游项目：[obra/superpowers](https://github.com/obra/superpowers) |
-| Compound Engineering | 本机插件 `3.18.0` | 本地 `.codex/plugins/cache/compound-engineering-plugin/compound-engineering/3.18.0`；上游项目：[EveryInc/compound-engineering-plugin](https://github.com/EveryInc/compound-engineering-plugin) |
-| Matt Pocock skills | PGS 本地 lock 记录 GitHub 来源和 hash，不记录 semver | 上游项目：[mattpocock/skills](https://github.com/mattpocock/skills)；Skill Vault 在 2026-07-05 显示 `1.0.31`、commit `66f92b6` |
-| Wayfinder | 属于 `mattpocock/skills`，2026-07-06 仍在 `skills/in-progress/wayfinder` | 上游文件：[Wayfinder SKILL.md](https://github.com/mattpocock/skills/blob/main/skills/in-progress/wayfinder/SKILL.md)；GitHub Actions 显示 Wayfinder 已连续多次发布到 Release #46 |
-
-重要提醒：PGS 本地 `wayfinder` 已在 2026-07-07 通过 `pro-gov assets npx update --skill wayfinder --plan` 更新到包含 **"Plan, don't do"** 和 destination 说明的新版。Wayfinder 仍处在高流动期，后续如果继续升级，需要重新复查这篇文档。
-
-## 一句话结论
-
-PGS 最稳的组合是：
-
-- **Superpowers** 继续当默认工程流程负责人。
-- **Compound Engineering** 继续当默认复利记录和经验沉淀工具。
-- **Matt 主流程** 用在“想法还模糊，需要问清楚、写 PRD、拆 issue”的时候。
-- **Wayfinder** 只用在“大到一个 session 装不下、前路还在雾里”的任务上。
-
-Wayfinder 暂时不应该自动启动。它很有潜力，但现在更像侦察兵，不像自动驾驶车。要用它，最好满足 4 个条件：用户明确叫它、目的地说清楚、issue tracker 支持它的地图/子票规则、关键节点有人类确认。
-
-## 两个贯穿例子
-
-为了更好懂，下面一直用两个例子：
-
-- **小安要开发一个 App。** 可能只是一个习惯打卡小工具，也可能是一个很大的 EMS 管理系统。
-- **小宁要写一本小说。** 可能只是一本短篇推理，也可能是一个多卷本奇幻系列。
-
-## Superpowers：工地施工队长
-
-Superpowers 像工地施工队长。施工队长不会一上来就让人搬砖。他会先问：要建什么？图纸在哪里？怎么验收？有没有安全检查？
-
-小安做 App 时，Superpowers 会帮：
-
-- 问清楚这个功能到底要解决什么问题。
-- 写计划。
-- 尽量用 TDD，先写测试再实现。
-- 完工前检查测试、review、分支状态。
-
-小宁写小说时，Superpowers 也能帮一点，比如安排写作计划。但它脑子里更多是“软件工程施工”。如果小宁只是想探索人物和情绪，Superpowers 可能显得有点硬。
-
-最适合：工程实现、调 bug、测试验证、分支收尾。
-
-PGS 判断：Superpowers 继续做默认工程流程负责人。PGS 已在 [integrations/superpowers.md](../../../integrations/superpowers.md) 里这样定位。
-
-## Compound Engineering：厨师的复盘菜谱本
-
-Compound Engineering 像厨师的菜谱本。厨师这次做菜发现“火候应该小一点”“这个酱汁可以提前一天做”，就记下来。下次做同类菜，就不用重新踩坑。
-
-小安做 App 时，CE 会帮：
-
-- 修完一个难部署 bug 后，把可复用经验记下来。
-- 下次遇到类似问题，AI 可以先读以前的经验。
-- CE 也有计划、review、debug 等完整流程，但 PGS 默认不让它接管整条开发线。
-
-小宁写小说时，CE 可以记录写作经验，比如“多卷本小说需要先做时间线表”。但如果只是自由创作，完整 CE 流程可能也会显得太工程化。
-
-最适合：把一次工作变成下一次工作的优势。
-
-PGS 判断：默认只用 **Compound Gate** 做经验沉淀。完整 CE 流程必须用户明确要求。见 [integrations/compound-engineering.md](../../../integrations/compound-engineering.md)。
-
-## Matt 主流程：采访员 + 产品经理 + 拆票员
-
-Matt 主流程像 3 个人接力：
-
-1. 采访员先不停追问，把模糊想法问清楚。
-2. 产品经理把答案整理成 PRD。
-3. 拆票员把 PRD 切成一个个能独立完成的小 issue。
-
-小安做 App 时：
-
-- `/grill-with-docs` 像采访员，边问边更新项目上下文。
-- `/to-prd` 像产品经理，把讨论整理成 PRD。
-- `/to-issues` 像拆票员，把 PRD 拆成竖切 issue。
-- `/implement` 像工程执行员，拿一个 issue 做 TDD、review、commit。
-
-小宁写小说时：
-
-- `/grill-me` 可以问清楚题材、主角、冲突、结尾。
-- `/to-prd` 可以变成故事圣经或写作 brief。
-- `/to-issues` 可以变成章节卡、设定任务、资料研究任务。
-- 但它的形状还是偏“产品开发”，所以对纯文学创作可能有点像用项目管理工具写诗。
-
-最适合：把模糊需求变成可保存、可拆分、可执行的东西。
-
-PGS 判断：Matt skills 可以完整安装、原样使用，但它产生的原生产物不应该被 PGS 乱改。PGS 不应该为了 Doc Gov 给它的产物硬加 frontmatter。正确做法是：Matt 产物保留原味；只有当人明确决定“这个东西要升级为 PGS 治理真相”时，才另建或更新 PGS 文档。见 [integrations/mattpocock-skills.md](../../../integrations/mattpocock-skills.md)。
-
-## Wayfinder：大雾森林里的画地图的人
-
-Wayfinder 像你站在一片大雾森林前。你知道森林另一边可能有城堡，但不知道路在哪里，也不知道哪些桥断了。这时最聪明的事不是冲进去盖房子，而是先画地图。
-
-小安做一个小习惯 App：
-
-- 不建议用 Wayfinder。太重了。Matt 主流程或 Superpowers 就够。
-
-小安做一个大型 EMS 系统：
-
-- Wayfinder 可以创建一个 map issue。
-- 然后创建子票，比如“决定权限模型”“研究 EMS 审计要求”“原型验证派单时间线 UI”“追问升级规则”。
-- 每个 session 只解决一个票，把答案记回地图。
-
-小宁写短篇推理：
-
-- 一般不需要 Wayfinder。
-
-小宁写多卷奇幻系列：
-
-- Wayfinder 很可能有用。它可以画出“魔法规则是否影响经济”“第二卷由谁推动主线”“结局前必须先决定哪些世界观问题”等地图。
-- 每张票解决一个大问题。
-
-最适合：很大、很模糊、一个 session 装不下、下一步不清楚的工作。
-
-PGS 判断：Wayfinder 只能显式调用。用户说 `/wayfinder`，或者清楚表达“我要为一个大而不清楚的任务画地图”，再用。
-
-## 总对比表
-
-| 维度 | Superpowers | Compound Engineering | Matt 主流程 | Wayfinder |
-| --- | --- | --- | --- | --- |
-| 小学生比喻 | 施工队长 | 复盘菜谱本 | 采访员 + 产品经理 + 拆票员 | 大雾地图师 |
-| 主要工作 | 把代码小心做出来 | 让下一次工作更容易 | 把想法变成 PRD / issue / code | 在未知里找到路线 |
-| 最适合规模 | 小到大的工程任务 | 重复出现的工程经验 | 中等复杂产品/功能 | 超大、模糊、多 session |
-| 主要产物 | 计划、测试、review、分支收尾 | `docs/solutions/**` 等经验文档 | `CONTEXT.md`、ADR、PRD、issue | 一个 map issue + 多个 child ticket |
-| 如何启动 | skill routing / session startup | 显式 CE skill 或 PGS Compound Gate | 通常显式 slash command | 显式 `/wayfinder` |
-| 人类角色 | 批准计划和关键选择 | 判断什么值得沉淀 | 回答采访、批准 issue 颗粒度 | 批准目的地、地图、下一步 |
-| 自主程度 | 中等 | PGS 默认低；完整 CE 时较高 | 中等 | 如果不设边界会偏高 |
-| 停止条件 | 测试、review、分支完成 | 学习记录完成或跳过 | PRD / issue / implementation 完成 | 路线清楚，没有更多必须先决定的问题 |
-| 最大优点 | 工程纪律强 | 真正复利 | 需求澄清和竖切很强 | 不假装大雾已经清楚 |
-| 最大风险 | 小任务可能仪式太重 | 用多了会变流程负担 | 可能偏重、偏线性 | 可能造太多票，或选错下一步 |
-| PGS 默认态度 | 默认工程负责人 | 默认复利尾巴 | 可选工具箱 | 显式侦察兵 |
-
-## 外部证据和评论
-
-### Wayfinder
-
-一手来源：Wayfinder 自己说，它处理的是“一个 session 太大、路还在雾里”的工作。它会在 issue tracker 上建共享地图，然后一个 ticket 一个 ticket 解决，直到目的地路线清楚。最新版上游还明确说默认是 **Plan, don't do**：默认产出决策，不产出最终交付物，除非 map Notes 明确允许执行。来源：[Wayfinder SKILL.md](https://github.com/mattpocock/skills/blob/main/skills/in-progress/wayfinder/SKILL.md)。
-
-GitHub Actions 显示 Wayfinder 近期更新非常密集，包括 destination/purpose、deferred section、native blocking、assignment claiming、plan big work 等。来源：[mattpocock/skills Actions](https://github.com/mattpocock/skills/actions)。
-
-GitHub issue #450 报告了一个真实风险：Wayfinder 在 work-through-map 时没有充分追问资源冲突，导致一个部署任务影响了另一个已存在服务。来源：[Issue #450](https://github.com/mattpocock/skills/issues/450)。
-
-用户提供的 2026-07-06 X 截图也显示两面性：有人觉得 Wayfinder 很震撼，但也观察到它可能继续执行错误的下一张票；Matt 回复说这不应该发生，听起来像 bug。这个证据说明：它很有潜力，但还不能当稳定自动驾驶。
-
-PGS 解释：Wayfinder 是侦察兵，不是总司令。
-
-### Matt 主流程
-
-一手来源：Matt README 说这些 skills 是小而可组合、可改造、用于真实工程，不是 vibe coding。它把 `/grill-with-docs`、`CONTEXT.md`、`/to-prd`、`/to-issues`、`/tdd`、`/code-review` 组合成一个流程。来源：[mattpocock/skills](https://github.com/mattpocock/skills)。
-
-公开 `to-issues` 指南说，它会把 PRD 拆成可独立抓取的竖切 issue，并让用户批准颗粒度和依赖。来源：[AI Hero to-issues guide](https://www.aihero.dev/skills-to-issues)。
-
-外部评论是“有用但可能重”。有 Reddit 用户说 Matt 风格的 GitHub issues / TDD / audit loop 质量好，但也担心每个小 issue 都耗时较多。来源：[Reddit discussion](https://www.reddit.com/r/PiCodingAgent/comments/1t2tm5c/am_i_overengineering_matt_pococks_ai_coding/)。
-
-另一个公开写法认为，这套流程适合触达多个模块的 feature/refactor，但不能替代人的判断。来源：[Danny Shmueli writeup](https://dannyshmueli.com/2026/04/29/Matt-Pocock-Skills-Hermes-Subagents-Feature-Work/)。
-
-PGS 解释：Matt 主流程适合“把话问明白、把需求切小”。但不要为了治理洁癖去改它原生输出。
-
-### Superpowers
-
-一手来源：Superpowers 自称是基于 composable skills 和启动指令的软件开发方法论，覆盖 brainstorming、worktree、planning、subagent execution、TDD、debugging、review、verification。来源：[obra/superpowers](https://github.com/obra/superpowers)。
-
-Superpowers 6 发布说明称，它在作者测试中更快、更省 token，并支持或改进了多个 coding agent，包括 Codex。来源：[Superpowers 6 announcement](https://blog.fsck.com/2026/06/15/Superpowers-6/)。
-
-社区评论也分两面。有些用户喜欢它前半段：澄清假设、写 spec、识别风险、做计划。也有人认为它对小任务会太重，甚至更耗用量。来源：[Reddit ClaudeCode thread](https://www.reddit.com/r/ClaudeCode/comments/1uk7dzk/fable_5_and_superpowers_plugin/) 和 [Reddit Codex thread](https://www.reddit.com/r/codex/comments/1sp7di6/have_any_of_you_guys_been_using_the_superpower/)。
-
-PGS 解释：Superpowers 仍然是最适合当默认工程负责人的，因为它端到端纪律强。但 PGS 需要保留轻量路径，小事不要被拖进大仪式。
-
-### Compound Engineering
-
-一手来源：CE 插件强调“每一次工程工作都应该让下一次更容易”，提供 `/ce-brainstorm`、`/ce-plan`、`/ce-code-review`、`/ce-compound` 等技能。来源：[EveryInc/compound-engineering-plugin](https://github.com/EveryInc/compound-engineering-plugin)。
-
-Every 的 Compound Engineering 指南强调 safety nets、agent-native environment、parallel work、plan as artifact。来源：[Compound Engineering guide](https://every.to/guides/compound-engineering)。
-
-Will Larson 的评论认为它是一个便宜、有用、值得试的实验，同时也提醒有些实践未来可能会被 agent harness 吸收。来源：[Lethain review](https://lethain.com/everyinc-compound-engineering/)。
-
-PGS 解释：CE 最珍贵的是“把经验留下来”。但如果 CE 和 Superpowers 同时想当整个流程的老板，AI 就像同时听两个教练喊口令，会乱。PGS 因此让 Superpowers 默认负责施工，让 CE 默认负责复盘。
-
-## 用 Loopy 外骨骼检查
-
-`loopy` 技能说，一个好 loop 应该有 6 步：观察、选择、行动、验证、记录、重复或停止。它还要求有明确终点，比如成功、阻塞、需要批准、用尽、停滞。
-
-把 4 套方法放进去看：
-
-| 系统 | 观察 | 选择 | 行动 | 验证 | 记录 | 停止 |
-| --- | --- | --- | --- | --- | --- | --- |
-| Superpowers | 强：会问、会读代码 | 强：会写计划 | 强：会实现 | 强：测试/review | 中：计划和 review 记录 | 强，但要真的跑验证 |
-| CE | 中：读任务上下文 | 中：CE plan/review | 中：可执行但 PGS 默认不用 | 中：review/check | 强：复利文档 | capture 很清楚，完整流程较重 |
-| Matt 主流程 | 强：grilling/docs | 强：PRD/issues | 强：implement | 强：TDD/code review | 强：context/ADR/PRD/issues | 中：依赖 smart context hygiene |
-| Wayfinder | 强：map/fog/tickets | 如果 frontier 对，就强 | 默认低：应该 plan，不应该 do | 中：依赖 ticket resolution 质量 | 强：map 和 resolution comments | 需要特别小心：一 session 一票 |
-
-Loopy 角度的 PGS 结论：Wayfinder 最大问题不是“不聪明”，而是“权限和刹车”。地图必须写清楚什么时候问人、什么时候停、什么时候绝对不执行。
-
-## 五轮真实评估迭代
-
-### 第 1 轮：先看 PGS 边界
-
-问题：PGS 能不能引入 Wayfinder，而不让 4 套方法互相打架？
-
-判断：可以，但每套方法要分工清楚。
-
-- Superpowers 负责默认工程施工。
-- CE 负责默认经验复利。
-- Matt 主流程负责需求澄清、PRD、issue 拆分。
-- Wayfinder 负责大雾任务的地图。
-
-我否掉的方案：让 Wayfinder 自动替代 Matt 旧流程。这太激进，像把整个施工队换成一张地图。
-
-### 第 2 轮：看 Wayfinder 上游原意
-
-问题：Wayfinder 自己到底说它是什么？
-
-判断：它不是更强的 `/implement`。它更像“路线发现”和“决策地图”。上游最新版还明确写了默认 plan，不默认 do。
-
-这改变了推荐：Wayfinder 不应该直接拿来替代实现流程。
-
-### 第 3 轮：看外部评论是不是只有夸
-
-问题：大家是在无脑夸，还是有真实问题？
-
-判断：两者都有。
-
-- 夸：有人觉得它能做以前不敢交给 AI 的大规划。
-- 风险：GitHub issue #450 和用户截图都说明，它可能在下一步选择或冲突追问上出错。
-
-这让 PGS 不应该过早自动化采用。
-
-### 第 4 轮：用 Loopy 查循环质量
-
-问题：4 套方法哪个循环最完整？
-
-判断：
-
-- Superpowers 和 Matt 主流程的“构建循环”更成熟。
-- CE 的“记录/复利循环”最强。
-- Wayfinder 的“观察/记录”很强，但“谁决定下一步”和“什么时候停止”需要额外护栏。
-
-结论：Wayfinder 必须一 session 一票，chart map 后要人工确认，默认只做决策，不做执行。
-
-### 第 5 轮：看 PGS 最小采用方式
-
-问题：最小、稳妥、有价值的采用方式是什么？
-
-判断：先写边界文档，不急着改运行规则。
-
-如果后续要真正 operationalize Wayfinder，需要：
-
-1. 保持 Matt skill pack 更新到包含最新版 Wayfinder 文案的版本。
-2. 保持 PGS 中央 `docs/agents/issue-tracker.md` 有 Wayfinding operations。
-3. 保持 Matt 原生产物不被 PGS 修改。
-4. Doc Gov 继续忽略 Matt 原生产物，除非人工提升为治理文档。
-5. 本地主控 AI 保留最终 merge / commit / push 权限。
-
-## PGS 推荐路由
-
-| 场景 | 推荐用什么 |
-| --- | --- |
-| 小而明确的代码修复 | Superpowers，必要时直接 TDD |
-| 难 bug | Superpowers systematic debugging；有复用经验再 CE capture |
-| 现有 repo 里的模糊功能想法 | Matt `/grill-with-docs`，然后可能 `/to-prd`、`/to-issues` |
-| 已经有 PRD，需要拆票 | Matt `/to-issues` |
-| 单个 issue 要实现 | Matt `/implement` 或 Superpowers 实现流程，看用户怎么叫 |
-| 巨大、模糊、多 session 的任务 | Wayfinder |
-| 工作结束后有可复用经验 | CE `/ce-compound` 或 PGS fallback capture |
-| 小说、课程、非代码创作 | Matt grilling 或 Wayfinder；不要默认套 Superpowers 工程仪式 |
-
-## 采用 Wayfinder 的护栏
-
-如果 PGS 以后真正启用 Wayfinder，请保留这些护栏：
-
-1. **只能显式启动。** 用户说 `/wayfinder`，或清楚要求“给大任务画地图”。
-2. **必须说清目的地。** 没有目的地的地图，只是一堆便利贴。
-3. **一个 session 只解决一张票。** 这样不会跑飞，也保护上下文。
-4. **默认只计划，不执行。** 除非 map Notes 明确写这个 effort 包含执行。
-5. **第一次 chart map 后要人工确认。** 不要一口气造几十张票然后自动往下冲。
-6. **Matt 原生产物保持原味。** 不要为了 PGS Doc Gov 给 map tickets、PRD、scratch、context docs 硬加 frontmatter。
-7. **要升级为 PGS 真相时，另行提升。** 也就是新建或更新受治理的 PGS 文档，而不是改原生产物。
-8. **issue tracker 必须保留规则。** PGS 中央的 `docs/agents/issue-tracker.md` 必须包含 Wayfinding operations；正式跑之前先检查它还在。
-
-## 最终建议
-
-PGS 应该支持 Wayfinder，但不要把它封王。
-
-最好的搭配是：
-
-- **Superpowers**：平时工程施工。
-- **Matt 主流程**：把模糊想法问清楚、写成 PRD、拆成 issue。
-- **Wayfinder**：遇到巨大迷雾任务时先画地图。
-- **CE**：工作结束后把可复用经验存下来。
-
-用小孩能懂的话说：Superpowers 帮你盖树屋，Matt 主流程问清楚你想要什么树屋，Wayfinder 在你连哪棵树能爬都不知道时先画森林地图，CE 把“梯子怎么做更结实”记进小本本，下次少摔一次。

package/assets/integrations/compound-engineering.md

@@ -1,11 +0,0 @@
-# Compound Engineering Integration (Retired)
-
-PGS no longer requires the Compound Engineering plugin or a Compound Gate.
-
-The retained idea is small: verified work sometimes produces a reusable lesson.
-The PGS-owned `capture-learning` skill decides whether a lesson is worth keeping,
-checks for duplicates, and writes it through `pro-gov learn capture`. There are
-no Stop hooks, modes, plugin configuration, or mandatory final-report ceremony.
-
-Historical `docs/solutions/**` records remain valid inputs to
-`pro-gov learn recall`.

package/assets/integrations/directed-development.md

@@ -1,44 +0,0 @@
-# Directed Development Integration
-
-Directed Development is an optional workflow for mixed, cross-domain, interdependent product work.
-
-It is not the default for every task.
-
-It is a small PGS routing rule for cases where product work must be split into
-ordered dependency-aware Blocks before execution.
-
-## Boundary
-
-Directed Development may define:
-
-- ordered DD Blocks
-- dependencies between Blocks
-- BDD-style acceptance scenarios
-- verification gates
-
-Directed Development must not define:
-
-- artifact locations
-- optional skill invocation rules
-- project document paths
-- project lane names
-- runtime truth
-
-Those remain owned by the project and doc-gov.
-
-Agents routing decides whether this workflow applies. Directed Development does
-not replace the project router.
-
-BDD-style scenarios are allowed only as acceptance language for a DD Block. They
-do not turn Directed Development into a default BDD ceremony and do not replace
-project-specific testing, debugging, or verification.
-
-## Trigger
-
-Use Directed Development only when all are true:
-
-- the task is product work
-- it crosses local lanes or shared contracts
-- sequencing risk makes a flat plan unsafe
-
-Doc-only projects do not use Directed Development unless explicitly opted in.

package/assets/integrations/ponytail.md

@@ -1,9 +0,0 @@
-# Ponytail Integration (Retired)
-
-PGS no longer requires or configures the Ponytail plugin.
-
-Prefer the smallest correct implementation, reuse mature tools, and avoid
-speculative abstractions as ordinary engineering judgment. A global mode and
-prompt/session hooks are unnecessary for those principles.
-
-This file remains only as a stable target for historical links.

package/assets/integrations/superpowers.md

@@ -1,12 +0,0 @@
-# Superpowers Integration (Retired)
-
-PGS no longer requires or routes through the Superpowers plugin.
-
-The useful principles—understand before editing, diagnose root causes, verify
-before claiming completion, and use tests proportionate to risk—are already part
-of Codex and project-level engineering rules. Keeping a mandatory bootstrap
-workflow duplicated those responsibilities and made small tasks unnecessarily
-ceremonial.
-
-This file remains only so historical decisions and links have a stable target.
-Do not add Superpowers startup instructions or make it a portfolio requirement.