@te-river/opencode-team-mode 1.4.6 → 1.4.7

package/README.md

@@ -24,7 +24,7 @@ Instead of one agent trying to do everything, you get:
 | 🏗️ **Architect** | System designer | Design docs, module structure, API contracts |
 | 💻 **Implementer** | Code writer | Building features, writing production code |
 | 🔍 **Reviewer** | Dimension-focused auditor | Single-dimension review (completeness / correctness / impact) — the lead runs 3 in parallel |
-| 🧪 **Tester** | Test engineer | Unit tests, integration tests, edge-case coverage, UI verification |
+| 🧪 **Tester** | Test engineer | Unit tests, integration tests, edge-case coverage, static verification (build / typecheck / lint / API tests) |
 | 🔎 **Researcher** | Knowledge finder | Library evaluation, API docs, best practices |
 
 ---
@@ -187,43 +187,43 @@ types into a fresh chat:
 > `src/legacy/`.
 
 ```text
-team   Breaking this down: design → implement → review → test.
-       Task board: .git/opencode-team/20260831-143012/rate-limiter/   (session folder + board inside .git/, auto-swept after idle TTL)
+team   Route: product behavior change → implementer → tester → reviewer
+       (3 dispatches → approval gate applies)
 
-       ▸ @architect — designing (writes 01-architect-design.md)
-       ✓ in-memory token bucket, per-user key, 429 + Retry-After
-         summary above, full design on the board
+       Research: read README, src/app.ts, src/middleware/*
+       Blocking questions: none — 1 assumption listed below
 
-       ▸ @implementer — building (Reads: 01; writes 02-implementer-middleware.md)
-       ✓ src/middleware/rateLimit.ts (new), wired into src/app.ts (+3 lines)
+       PLAN
+       Goal: token-bucket limiter, 100 req/min/user, 429 + Retry-After
+       Scope: src/middleware/rateLimit.ts (new), src/app.ts (+3 lines)
+       Pipeline: implementer → tester → reviewer (correctness)
+       Assumption: in-memory bucket, not Redis — say the word to change
+       Boundary: src/legacy/** untouched
+       Approve to proceed?
 
-       ▸ @reviewer — auditing the diff (Reads: 01, 02; writes 03-reviewer-findings-r1.md)
-       ⚠ 1 MAJOR — bucket refill does read-modify-write in two steps;
-         races under concurrent requests
-         → converted to a fix task; dispatched to @implementer with the
-           finding text (the user was not asked to approve this step)
+user   approved, go
 
-       ▸ @implementer r2 — fixing the race (Reads: 03-r1 §MAJOR; writes 04-implementer-r2.md)
-       ✓ refill restructured to single atomic update
+team   ▸ @implementer — STATUS: done
+       CHANGES: src/middleware/rateLimit.ts (new) · src/app.ts (+3)
+       HANDOFF: bucket {tokens, lastRefill}; refill() is a single atomic pass
+       EVIDENCE: tsc clean (output above)
 
-       ▸ @reviewer r2 — re-review of fixed scope only
-       ✓ clean — r1 finding resolved, no regressions
+       ▸ @tester — STATUS: done · VERDICT: pass (14/14)
+       FINDINGS: burst edge, window expiry, concurrent refill covered;
+                 src/legacy/** byte-identical
+       EVIDENCE: vitest 14 passed
 
-       ▸ @tester — covering limiter + boundaries (writes 05-tester-report.md)
-       ✓ 14/14 pass — burst edge, window expiry, concurrent refill,
-         src/legacy/** byte-identical (user boundary verified in tests)
+       ▸ @reviewer — STATUS: done · VERDICT: approve (correctness)
+       FINDINGS: no Critical/Major; 1 Minor (log line noise) noted
 
 team   Done.
        rate limiter shipped: rateLimit.ts (new) · app.ts (+3) · 14 tests green
-       review loop: 1 major found → fixed → clean
-       assumption: in-memory only — say the word if you want Redis
-       src/legacy/ untouched
-       task board left in place — TTL sweep will reclaim it
+       review: approve · assumption: in-memory only · src/legacy/ untouched
 ```
 
-The only message the user typed was the first one. The reviewer's finding
-became the implementer's work order without a prompt; every artifact stayed
-out of chat and on the board, read only by the dispatch that needed it.
+The only message the user typed was the task and "approved, go". The
+pipeline was a routing-table lookup, execution waited for plan approval,
+and every handoff traveled as a structured skeleton — no file ceremony.
 
 ### Desktop-specific features
 
@@ -266,60 +266,68 @@ opencode-team-mode/
 
 ---
 
-## 🗂️ Shared Blackboard (with automatic cleanup)
-
-Sub-agents cannot message each other live (platform limitation), so TeamMode coordinates them through a **file blackboard** with strict ownership:
-
-- **Session isolation:** every conversation owns ONE timestamped session
-  folder, and each multi-agent task gets its own directory inside it:
-  `<repo>/.git/opencode-team/<session-key>/<task-slug>/` — inside `.git/`,
-  so your working tree and commits are **never polluted**. (Non-git
-  workspaces fall back to the OS temp dir.) Since boards now linger until
-  the TTL sweep, the session layer keeps a fresh conversation from bumping
-  into — or reading stale artifacts from — a not-yet-swept board (timestamps
-  are second-granular, so overlap needs two conversations starting in the
-  same second).
-- **File ownership:** every artifact is one topic-sized file written by
-  exactly one agent (`01-architect-auth-design.md`, `03-reviewer-auth-r1.md`).
-  ~100 lines max per file — split topics instead of letting files balloon.
-- **Writes are frozen:** a revision is a new round-suffixed file
-  (`…-r2.md`); nothing is ever appended to or later agents reading stale rounds.
-- **The Team Lead is the router:** every dispatch carries a manifest —
-  `Task:` (self-contained brief), `Reads:` (only the files that work package
-  needs), `Write to:` (the one file the agent owns). Specialists read nothing
-  that isn't listed, so long tasks never drown sub-agents in unnecessary context.
-- **`MANIFEST.md` is the lead's state board:** a file index plus a ≤50-line
-  `## Current state` section (phase, decisions still valid, next steps),
-  updated every converged round — the lead's compressed memory across long tasks.
-- The Team Lead also enforces a review/test **feedback loop**: Critical/Major
-  findings and product bugs automatically become tracked fix tasks until the
-  deliverable converges.
-
-### Ultra Review, pipeline gates & evidence (v1.4.6)
-
-- **Ultra Review:** every non-trivial change is reviewed by three parallel
-  Reviewer dispatches, one dimension each — completeness (requirements
-  coverage), correctness (logic & security), impact (regressions & blast
-  radius) — each told to ignore the other two. The lead merges the three
-  reports into one severity-grouped list before the fix loop starts.
-  Trivial changes may skip review with a one-line reason.
-- **Pipeline gates:** research completes before planning; design before
-  code; code before verify; verify before review; user-visible frontend
-  changes get UI verification before "done"; the final report waits for
-  every agent and a truthful todo board. Skipping a phase on a trivial task
-  costs one line of rationale.
-- **Evidence standard:** "done / fixed / passed" claims need verifiable
-  evidence — command output, logs, diffs, screenshots. Narratives are
-  progress notes, not proof (enforced on specialists and the lead alike).
-- **README-first:** the lead reads the project's README (plus AGENTS.md /
-  CLAUDE.md) before planning, and restates binding conventions in every
-  dispatch; specialists treat listed project conventions as binding.
-- **Verbatim contracts:** parallel implementers that must interoperate get
-  the exact data contract (endpoints, field names, types) pasted verbatim
-  into every affected dispatch — mismatches are the #1 source of
-  integration bugs.
-- **CHANGELOG care:** delivered changes append an entry to the project's
-  CHANGELOG.md (Keep a Changelog style) when one exists.
+## 🗂️ Coordination: structured handoffs first, files second (hybrid)
+
+Sub-agents cannot message each other live (platform limitation), so TeamMode
+coordinates them through a **structured reply skeleton**, with a file
+blackboard reserved for oversized output:
+
+- **Reply skeleton (primary channel):** every specialist's final reply starts
+  with `STATUS: / CHANGES: / FINDINGS: / EVIDENCE: / HANDOFF:` and stays ≤50
+  lines. Deliverables at that size travel inline — zero file I/O, nothing to
+  fall out of sync. The lead relays `HANDOFF` verbatim into the next
+  dispatch and machine-checks the skeleton (missing → one retry with it
+  inline, then downgrade and note the violation).
+- **Board files (exception only):** when a full deliverable exceeds ~50 lines
+  (e.g. a complete architecture doc), the dispatch names ONE file:
+  `<repo>/.git/opencode-team/<session-key>/<task-slug>/NN-<role>-<topic>.md`
+  — inside `.git/`, so your working tree and commits are **never polluted**
+  (non-git workspaces fall back to the OS temp dir). Writes are frozen: a
+  revision is a new round-suffixed file (`…-r2.md`); session folders keep a
+  fresh conversation from touching a not-yet-swept board.
+- **No MANIFEST.md:** the lead's state memory is its todo list.
+- **Feedback loop:** Critical/Major findings and product bugs automatically
+  become tracked fix tasks until the deliverable converges (max 2 loops,
+  then escalate to you).
+
+### Deterministic routing, approval gate & adaptive review (v1.4.7)
+
+- **Routing table:** the lead picks a fixed pipeline row by task shape —
+  question → direct answer; docs-only → implementer; product behavior
+  change → implementer → tester → reviewer; multi-module feature →
+  architect → implementer → tester → reviewer(s); unknown external tech →
+  researcher first. Pipelines have fixed minimums: a product change routed
+  below 3 dispatches is a routing bug, and splitting one request into
+  sub-3-dispatch pieces to dodge the gate is a protocol violation.
+- **Approval gate (count-based):** ≥3 planned dispatches → the lead
+  researches (reading the repo itself; a researcher dispatch only for
+  unknown external tech), presents a ≤30-line plan, and **waits for your
+  approval** before executing anything. 0-2 dispatches run with a 1-2 line
+  notice. A task that grows a third dispatch mid-run pauses for approval.
+  Blocking uncertainties are batched and asked immediately — never guessed,
+  never drip-fed.
+- **Adaptive review:** default is ONE reviewer dispatch (correctness);
+  three parallel dimensions (completeness / correctness / impact) only for
+  high-risk profiles — auth/security surface, cross-module data contracts,
+  public APIs across ≥3 files.
+- **Static verification:** testers verify via build, typecheck, static
+  analysis, and API/unit tests. Improvised browser automation (headless
+  screenshots, DOM stubs) is banned; user-visible frontend changes end with
+  `UI NOT VERIFIED: <what needs manual checking>` unless the project
+  already ships real browser-test tooling.
+- **No-ceremony fast path:** a root cause the lead has already verified
+  (file:line evidence) goes straight to the implementer as a fix spec —
+  investigation dispatches serve unknowns, not ritual.
+- **Brevity discipline:** route selection is a table lookup; user-visible
+  planning text stays ≤5 lines.
+- **Evidence standard (kept):** "done / fixed / passed" claims need
+  verifiable evidence — command output, logs, diffs. Narratives are
+  progress notes, not proof.
+- **Verbatim contracts (kept):** parallel implementers that must
+  interoperate get the exact data contract (endpoints, field names, types)
+  pasted verbatim into every affected dispatch.
+- **CHANGELOG care (kept):** delivered changes append an entry to the
+  project's CHANGELOG.md (Keep a Changelog style) when one exists.
 
 ### Triage — questions don't become code edits
 

package/README.zh-CN.md

@@ -24,7 +24,7 @@ TeamMode 将 OpenCode 桌面版从一个单 Agent 编码助手，升级为**一
 | 🏗️ **Architect** | 系统设计师 | 设计文档、模块结构、API 契约 |
 | 💻 **Implementer** | 代码实现者 | 编写生产代码、实现功能 |
 | 🔍 **Reviewer** | 单维审查员 | 单维度审查（完整性 / 正确性 / 影响面）——lead 三路并行后合并 |
-| 🧪 **Tester** | 测试工程师 | 单元测试、集成测试、边界覆盖、UI 验证 |
+| 🧪 **Tester** | 测试工程师 | 单元测试、集成测试、边界覆盖、静态验证（构建 / 类型检查 / lint / API 测试） |
 | 🔎 **Researcher** | 知识调研员 | 库评估、API 文档、最佳实践调研 |
 
 ---
@@ -108,7 +108,7 @@ npm link
 
 > 💡 **提示：** 修改 `opencode.json` 后，请**重启 OpenCode 桌面版**使更改生效。
 
-> ⚠️ **模型选择很重要。** 工作流里的每一个判断——分诊、拆解、派发清单、
+> ⚠️ **模型选择很重要。** 工作流里的每一个判断——分诊、拆解、派单、
 > 整合、审查/测试闭环裁决——都经过 **Team Lead**。这个位置上放弱模型，
 > 专家再强也救不回整条流水线。如需自定义，还请给你的 `team` agent 钉上你能负担的最强
 > 推理模型（配方见下方「自定义」节）。
@@ -183,41 +183,42 @@ TeamMode 为 OpenCode 添加了六个斜杠命令，在聊天输入框中输入
 > 超限返回 429。不要动 `src/legacy/` 下的任何东西。
 
 ```text
-team   拆解任务：设计 → 实现 → 审查 → 测试。
-       任务黑板：.git/opencode-team/20260831-143012/rate-limiter/（会话目录 + 任务板，都在 .git/ 内，闲置超 TTL 自动清理）
+team   路由：产品行为变更 → implementer → tester → reviewer
+       （3 次派发 → 触发审批门）
 
-       ▸ @architect — 设计中（写入 01-architect-design.md）
-       ✓ 内存令牌桶、按用户键控、429 + Retry-After
-         聊天里只有摘要，设计全文在黑板上
+       调研：已读 README、src/app.ts、src/middleware/*
+       阻塞性问题：无 —— 1 条假设列在下方
 
-       ▸ @implementer — 实现中（Reads: 01；写 02-implementer-middleware.md）
-       ✓ src/middleware/rateLimit.ts（新增），接入 src/app.ts（+3 行）
+       计划
+       目标：令牌桶限流，100 请求/分/用户，429 + Retry-After
+       范围：src/middleware/rateLimit.ts（新增）、src/app.ts（+3 行）
+       流水线：implementer → tester → reviewer（correctness）
+       假设：内存桶而非 Redis —— 要改说一声
+       边界：src/legacy/** 不动
+       批准后开工？
 
-       ▸ @reviewer — 审查改动（Reads: 01、02；写 03-reviewer-findings-r1.md）
-       ⚠ 1 个 MAJOR — 桶回充分两步读-改-写，并发下有竞态
-         → 已自动转为修复任务，发现原文随任务书派给 @implementer
-           （这一步没有要求用户拍板）
+用户   批准，开始
 
-       ▸ @implementer r2 — 修竞态（Reads: 03-r1 §MAJOR；写 04-implementer-r2.md）
-       ✓ 回充重构为单次原子更新
+team   ▸ @implementer — STATUS: done
+       CHANGES: src/middleware/rateLimit.ts（新增）· src/app.ts（+3）
+       HANDOFF: bucket {tokens, lastRefill}；refill() 单次原子完成
+       EVIDENCE: tsc 无错误（输出见上）
 
-       ▸ @reviewer r2 — 只复审改动范围
-       ✓ 通过 — r1 发现已解决，无回归
+       ▸ @tester — STATUS: done · VERDICT: pass（14/14）
+       FINDINGS: 覆盖突发边界、窗口过期、并发回充；
+                 src/legacy/** 逐字节未变
+       EVIDENCE: vitest 14 passed
 
-       ▸ @tester — 覆盖限流器与边界（写 05-tester-report.md）
-       ✓ 14/14 通过 — 突发边界、窗口过期、并发回充、
-         src/legacy/** 逐字节未变（用户边界写进了测试断言）
+       ▸ @reviewer — STATUS: done · VERDICT: approve（correctness）
+       FINDINGS: 无 Critical/Major；1 条 Minor（日志噪音）已记录
 
 team   完成。
        限流器已交付：rateLimit.ts（新增）· app.ts（+3）· 14 测试全绿
-       审查闭环：1 个 major → 已修 → 清零
-       假设：仅内存存储——要接 Redis 说一声
-       src/legacy/ 未动
-       任务黑板留在原地，TTL 到期自动回收
+       审查：通过 · 假设：仅内存存储 · src/legacy/ 未动
 ```
 
-用户输入的消息只有第一条。reviewer 的发现直接变成 implementer 的下一张
-工单；每份制品都留在黑板上而不是聊天里，只被需要它的那次派发读取。
+用户只输入了任务本身和"批准，开始"。流水线是路由表查表的结果；执行在
+计划获批前一步不动；每次交接都是结构化骨架——零文件仪式。
 
 ### 桌面版专属特性
 
@@ -260,44 +261,52 @@ opencode-team-mode/
 
 ---
 
-## 🗂️ 共享黑板（带自动清理）
-
-子代理之间无法实时互发消息（平台限制），TeamMode 通过**严格所有权的文件黑板**让它们协作：
-
-- **会话隔离：** 每个会话拥有一个时间戳会话目录，多 Agent 任务在其内再各自
-  独立建任务目录：`<repo>/.git/opencode-team/<session-key>/<task-slug>/` ——
-  位于 `.git/` 内，**绝不污染**你的工作区和 commit（非 git 工作区自动回退到系统临时目录）。
-  正因为黑板现在会留到 TTL 清扫才消失，会话层让新对话几乎不可能撞上（或误读到）
-  上一场还没被收走的旧黑板 —— 时间戳精确到秒，理论上只有同一秒开跑的两个会话才会重名。
-- **文件所有权**：每个制品是一个"一主题一文件"，只由一个 Agent 写
-  （`01-architect-auth-design.md`、`03-reviewer-auth-r1.md`）。单文件约 ≤100 行，
-  超长就拆主题文件而不是任其膨胀。
-- **写入即冻结**：修订 = 新的轮次后缀文件（`…-r2.md`）；绝不追加旧文件，
-  后续 Agent 也永远读不到过时轮次。
-- **Team Lead 是路由器**：每次 dispatch 携带清单——`Task:`（自包含任务书）、
-  `Reads:`（仅列出该工作包需要的文件）、`Write to:`（该 Agent 本次拥有的唯一文件）。
-  子代理不读清单之外的任何东西，超长任务因此不会把无关上下文灌进子代理。
-- **`MANIFEST.md` 是 lead 的状态板**：文件索引 + 顶部 ≤50 行的 `## Current state`
-  节（阶段、仍然有效的决策、下一步），每轮闭环后更新——lead 跨长任务的压缩记忆。
-- Team Lead 同时强制执行审查/测试**反馈闭环**：Critical/Major 问题和产品 bug
-  自动转化为跟踪的修复任务，直到交付物收敛。
-
-### Ultra Review、流水线门禁与证据标准（v1.4.6）
-
-- **Ultra Review**：每个非平凡变更由**三个并行 Reviewer 派单**审查，各管一个
-  维度——完整性（需求覆盖）/ 正确性（逻辑与安全）/ 影响面（回归与波及面）——
-  且各自被明令忽略其余两维。Lead 先把三份报告合并去重成一份按严重度分组的
-  清单，再进入修复闭环。平凡变更可跳过审查，但须一行理由。
-- **流水线门禁**：调研全部完成才定计划；设计先行于实现；实现归队才测试；
-  测试通过才审查；用户可见的前端改动必须通过 UI 验证才算完成；最终报告
-  等所有代理收工、看板状态属实。平凡任务跳过阶段须一行理由。
-- **证据标准**："完成 / 修复 / 通过"的声明必须附可验证证据——命令输出、
-  日志、diff、截图。纯叙述只是进度说明，不是证明（对子代理和 lead 同样生效）。
-- **README 优先**：lead 在规划前先读项目 README（及 AGENTS.md / CLAUDE.md），
-  并把有约束力的约定复述进每次派单；子代理对清单内项目约定视同强制。
-- **逐字契约**：需要互通的并行实现代理，其数据契约（端点、字段名、类型）只写
-  一份并**逐字**贴进每个相关派单——契约错配是集成 bug 之首。
-- **CHANGELOG 维护**：项目带有 CHANGELOG.md 时，交付的改动会按
+## 🗂️ 协作机制：结构化交接优先，文件其次（混合制）
+
+子代理之间无法实时互发消息（平台限制），TeamMode 通过**结构化回复骨架**协调它们，
+文件黑板只保留给超大产出：
+
+- **回复骨架（主通道）**：每个专家的最终回复以
+  `STATUS: / CHANGES: / FINDINGS: / EVIDENCE: / HANDOFF:` 开头，全文 ≤50 行。
+  这个尺寸的产出直接内联传递——零文件 I/O，没有"文件没写上"这种故障面。
+  Lead 把 `HANDOFF` 原文转贴进下一次派单，并对骨架做机器校验
+  （缺失 → 带 skeleton 原文重试一次 → 仍违规则降级记入报告）。
+- **黑板文件（仅例外）**：完整产出确实超过 ~50 行时（如完整架构设计文档），
+  派单点名唯一文件：
+  `<repo>/.git/opencode-team/<session-key>/<task-slug>/NN-<role>-<topic>.md`
+  ——位于 `.git/` 内，**绝不污染**工作区和 commit（非 git 工作区回退系统临时目录）。
+  写入即冻结：修订 = 新的轮次后缀文件（`…-r2.md`）；会话目录层让新对话
+  不会撞上尚未清扫的旧黑板。
+- **没有 MANIFEST.md**：lead 的状态记忆就是它的 todo list。
+- **反馈闭环**：Critical/Major 发现和产品 bug 自动转化为跟踪的修复任务，
+  直到交付物收敛（最多 2 轮，之后升级给用户）。
+
+### 确定性路由、审批门与自适应评审（v1.4.7）
+
+- **路由表**：lead 按任务形状查固定流水线行——提问 → 直接回答；纯文档 →
+  implementer；产品行为变更 → implementer → tester → reviewer；多模块/跨接口
+  功能 → architect → implementer → tester → reviewer(s)；未知外部技术 →
+  researcher 前置。流水线有固定下限：产品变更路由到少于 3 次派发即是路由 bug；
+  把一个请求拆成多个 <3 派发的子任务以规避审批门 = 协议违规。
+- **审批门（按计数触发）**：预计派发 ≥3 → lead 先调研（亲自读仓库；仅未知外部
+  技术才派 researcher），呈交 ≤30 行计划，然后**等待你的批准**才执行任何东西。
+  0-2 次派发的小任务以 1-2 行通报直接开工。执行中发现需要第 3 次派发 →
+  暂停等批准。阻塞性不确定**立即批量问一次**——不猜测、不挤牙膏。
+- **自适应评审**：默认 1 个 reviewer 派单（correctness 维度）；仅高风险画像
+  ——鉴权/安全面、跨模块数据契约、≥3 文件的公共 API 变更——才升级为
+  3 维并行（完整性 / 正确性 / 影响面）。
+- **静态验证**：tester 通过构建、类型检查、静态分析、API/单元测试验证。
+  禁止即兴发明浏览器自动化（headless 截图、DOM stub）；用户可见前端改动
+  以 `UI NOT VERIFIED: <待人工检查项>` 如实收尾，除非项目本身已带真实
+  浏览器测试设施。
+- **无仪式捷径**：lead 已亲自验证的根因（file:line 证据）直接变成修复规格
+  派给 implementer——调查性派单服务于未知，不服务于仪式感。
+- **简明纪律**：路由选择是查表；用户可见的计划性文字 ≤5 行。
+- **证据标准（保留）**："完成 / 修复 / 通过"的声明必须附可验证证据——命令
+  输出、日志、diff。纯叙述只是进度说明，不是证明。
+- **逐字契约（保留）**：需要互通的并行实现代理，其数据契约（端点、字段名、
+  类型）逐字贴进每个相关派单——契约错配是集成 bug 之首。
+- **CHANGELOG 维护（保留）**：项目带有 CHANGELOG.md 时，交付的改动按
   Keep a Changelog 风格追加条目。
 
 ### Triage —— 提问不会变成代码修改
@@ -361,7 +370,7 @@ Team-as-default 出厂行为。若你在 v1.4.4 期间加过 `{ "defaultAgent":
 
 ### Team Lead 的模型最关键
 
-Lead 是编排大脑：它给每条消息分类、把工作切成包、写每份派发清单、裁决
+Lead 是编排大脑：它给每条消息分类、按路由表查流水线、写每份派单、裁决
 reviewer/tester 的发现、合成最终交付。这里的质量问题会**沿流水线放大**——
 平庸的 Lead 拆错任务、给专家的指令含糊、放走劣质产出；没有任何专家能
 救回一份从一开始就派错的工单。

package/dist/agents.d.ts

@@ -6,15 +6,21 @@
  * Users see them in the agent picker of OpenCode Desktop and can invoke
  * them with `@agent-name` or via the `/team-*` commands.
  *
- * Prompt design principles (v1.2):
- *  - TodoList discipline is a hard rule for the Team Lead (plan-first for
- *    medium+ tasks, live status updates).
- *  - Explicit failure-classification retry policy.
- *  - Mandatory feedback loop: review findings and test failures are
- *    converted into tracked fix tasks before "done" can be declared.
- *  - Context-relay rule: sub-agents cannot talk to each other, so every
- *    dispatch embeds the relevant prior outputs.
- *  - Research findings carry confidence tags and critical ones are verified.
+ * Prompt design principles (v1.4.7 — "subtraction" release):
+ *  - Deterministic routing table replaces free-form scheduling deliberation
+ *    (fixes the lead's "inner monologue" — route selection is a lookup).
+ *  - Structured reply skeleton (STATUS/CHANGES/FINDINGS/EVIDENCE/HANDOFF)
+ *    is the primary inter-agent channel; the file blackboard is demoted to
+ *    an oversized-deliverable exception (>~50 lines). MANIFEST.md is gone.
+ *  - Approval gate is a mechanical dispatch count (>=3 -> plan + wait);
+ *    blocking uncertainties are batched and asked immediately.
+ *  - Verified root causes go straight to the implementer — no ceremonial
+ *    research dispatches.
+ *  - Verification defaults to static checks; improvised browser automation
+ *    is explicitly banned.
+ *  - Adaptive review: one reviewer by default, three dimensions only for
+ *    high-risk profiles.
+ *  - All agents run at temperature 0.2 for format discipline.
  */
 import type { AgentConfig } from "./types.js";
 export declare const agents: Record<string, AgentConfig>;

package/dist/agents.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"agents.d.ts","sourceRoot":"","sources":["../src/agents.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,YAAY,CAAA;AA2jB7C,eAAO,MAAM,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,WAAW,CAO9C,CAAA"}
+{"version":3,"file":"agents.d.ts","sourceRoot":"","sources":["../src/agents.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,YAAY,CAAA;AA4hB7C,eAAO,MAAM,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,WAAW,CAO9C,CAAA"}