feat: release TFD v3.5.0 with AUTO_REVIEW

Author: Howe829

.agents/plugins/marketplace.json

@@ -9,7 +9,7 @@
       "source": {
         "source": "local",
         "path": "./plugins/tfd",
-        "version": "3.4.1"
+        "version": "3.5.0"
       },
       "policy": {
         "installation": "AVAILABLE",

CHANGELOG.md

@@ -4,6 +4,15 @@ All notable public changes to Team First Development are documented here.
 
 ## Unreleased
 
+## 3.5.0 - 2026-08-13
+
+- Add opt-in, session-only `AUTO_REVIEW` with one confirmed Autonomy Envelope,
+  Orchestrator approval for in-envelope gates, bounded repair and evidence
+  recovery, and no repeated user reply between approved steps.
+- Keep independent review as risk-scaled evidence, preserve exact external
+  targets, and leave out-of-envelope, production, destructive, privileged,
+  messaging, security, and structural Wiki changes human-gated.
+
 ## 3.4.1 - 2026-08-05
 
 - Remove all Superpowers Skill bindings from TFD documentation and example

README-CN.md

@@ -7,7 +7,7 @@
 Team First Development（TFD）是一套选择性使用的 Codex 团队开发方法。它通过
 目标对齐、模型与职责匹配、聚焦上下文和独立审核，改善一个边界明确的开发结果。
 
-当前源码版本为 `3.4.1`。是否已发布以 `v3.4.1` 标签和 GitHub Release 为准；
+当前源码版本为 `3.5.0`。是否已发布以 `v3.5.0` 标签和 GitHub Release 为准；
 本地检出本身不能证明已经安装、部署或发布。
 
 ## 使用
@@ -32,6 +32,26 @@ workstream。精确确认方案必须展示每个 workstream 的责任成员、
 Agent。只有无依赖且写入范围不重叠的 workstream 才可并行；`BLOCKER` 会停止
 下游，Coordinator 最后把已接受的产出整合成一个不可变审核候选。
 
+## AUTO_REVIEW 模式
+
+默认仍是人工确认。用户显式选择 `AUTO_REVIEW` 后，只需先确认一个会话级
+Autonomy Envelope，其中列明范围、Roster、workstream、可自动审核的 Gate、有界修复
+策略、证据要求和精确外部目标。当前 Coordinator 随即成为 Orchestrator，自动审核
+并通过每个 Envelope 内 Gate，不再等待用户逐次回复。只有风险或 Envelope 要求时
+才调用独立 reviewer；reviewer 提供证据，Orchestrator 才是审批权威。
+
+只有证据充分的 Orchestrator `PASS` 会推进。`BLOCKER` 可以进入 Envelope 内的
+有界修复循环，`UNVERIFIED` 可以触发已列明的补证，但都不能直接释放下游。Envelope
+可以预先授权精确 commit、non-force merge、branch/tag-ref push、tag、Release、本地
+first install/reinstall 和 non-production deployment。production deployment、破坏性
+或 force 操作、付费资源、提权、外部消息、安全或身份变更、用户验收、扩大范围，
+以及修改 Envelope/Orchestrator，始终只能由用户确认；宿主或平台确认也不能绕过。
+
+未来才产生的 candidate、commit、tag、Release、artifact、install 和 deployment 值，
+必须用 late-bound 引用绑定到一个命名 Gate 输出。Orchestrator 在下游 Gate 前冻结完整
+digest/OID 并校验 lineage，因此一次确认即可驱动完整链路，不会依赖可漂移的
+`latest`，也不必在每个产物出现后再次询问。有界修复会作废并重算全部下游派生输出。
+
 ## 工程合同
 
 凡是修改源码或软件架构的任务，TFD 都必须在最终确定 `PLAN` 前完整读取
@@ -144,11 +164,16 @@ daemon、远程存储、进度状态或恢复权威。可以把 Obsidian 当作
 
 ### 知识确认
 
-初始化、摄取、修复、冲突解决和 schema 变更都遵循
-`PROPOSE -> CONFIRM -> APPLY`。确认前，`wiki/` 下任何文件都不能变化。TFD
-展示团队、来源与摘要、页面差异、冲突、index/log 影响、当前 Wiki baseline、
-完整 SHA-256 和 12 字符指纹。自然语言确认可以引用短指纹，但 Guard 只接受
-完整匹配摘要。提案或 baseline 的任何实质变化都需要重新确认。
+人工模式下，初始化、摄取、修复、冲突解决和 schema 变更都遵循
+`PROPOSE -> CONFIRM -> APPLY`。已确认 `AUTO_REVIEW` Envelope 时，初始化和常规
+add-only ingest 可以用 Guard 校验加 Orchestrator `PASS` 代替逐次人工确认；修复、
+冲突解决和 schema 变更仍只能由用户确认。在取得其中一种授权前，`wiki/` 下任何
+文件都不能变化。TFD 展示团队、来源与摘要、页面差异、冲突、index/log 影响、
+当前 Wiki baseline、完整 SHA-256 和 12 字符指纹。自然语言确认可以引用短指纹，
+但 Guard 只接受完整匹配摘要。提案或 proposal-local Wiki baseline 的实质变化，
+在人工模式下需要重新确认；仍在 Envelope 内的 initialization 或常规 add-only ingest
+则要重新通过 Guard 并取得绑定新摘要的 Orchestrator `PASS`。只要混入 conflict、repair、schema 或其他
+human-only effect，整个提案都回到人工确认。Envelope 字段变化始终要用户确认。
 
 来源只增不改。新版本创建新的摘要寻址快照，绝不覆盖旧版本。相互冲突且都有
 来源的结论保留在 `disputed` 页面，直到用户单独确认解决方案。
@@ -206,18 +231,21 @@ Wiki 存在后，最终交付只记录一个 `delivery` activity，不再创建
 
 ## 授权边界
 
-团队确认只授权方案中列明的本地资料写入和/或成员激活，不授权安装、合并、
+人工团队确认只授权方案中列明的本地资料写入和/或成员激活，不授权安装、合并、
 推送、打标签、发布、部署、对外消息、破坏性清理、特权命令、付费动作或扩大
-范围；这些动作继续遵循各自的正常审批边界。
+范围。`AUTO_REVIEW` 只能预授权已确认 Envelope 定义的精确内部与外部 Gate 和目标；
+Orchestrator 随后无需用户再次回复即可完成 TFD 审批。其他动作继续保留人工审批边界。
 
-本地检出目录中的版本号本身不能证明已经安装或部署。请以 `v3.4.1` 标签和
+本地检出目录中的版本号本身不能证明已经安装或部署。请以 `v3.5.0` 标签和
 GitHub Release 作为发布证据。
 
 ## 仓库结构
 
 ```text
 plugins/tfd/.codex-plugin/plugin.json      插件清单
 plugins/tfd/skills/using-tfd/SKILL.md      唯一用户 Skill
+plugins/tfd/skills/using-tfd/references/auto-review.md
+                                           按需加载的 AUTO_REVIEW 协议
 plugins/tfd/skills/using-tfd/references/engineering-constraints.md
                                            按需加载的工程合同
 plugins/tfd/skills/using-tfd/references/team-wiki.md

README.md

@@ -8,7 +8,7 @@ Team First Development (TFD) is a selective Codex team-development method.
 It improves a bounded development result through alignment, model-role fit,
 focused context, and independent review.
 
-This source tree is version `3.4.1`. The `v3.4.1` tag and GitHub Release are
+This source tree is version `3.5.0`. The `v3.5.0` tag and GitHub Release are
 the publication evidence; a local checkout alone does not prove installation,
 deployment, or publication.
 
@@ -37,6 +37,33 @@ unconfirmed helper Agents. Dependency-free workstreams may run in parallel only
 when their write scopes do not overlap; a blocker stops its dependents, and the
 Coordinator integrates accepted outputs into one immutable review candidate.
 
+## AUTO_REVIEW mode
+
+Manual confirmation remains the default. With explicit `AUTO_REVIEW`, the user
+confirms one session-only Autonomy Envelope containing the scope, roster,
+workstreams, eligible gates, bounded repair policy, evidence requirements, and
+exact external targets. The current Coordinator becomes the Orchestrator and
+auto-approves each in-envelope Gate; there is no repeated user reply between
+those Gates. Independent review supplies evidence only when risk or the
+Envelope requires it.
+
+Only an evidence-bound Orchestrator `PASS` advances. A `BLOCKER` may enter an
+in-envelope bounded repair loop, and `UNVERIFIED` may trigger named evidence
+collection; neither advances dependent work or becomes success. The Envelope
+may pre-authorize exact commit, non-force merge, branch/tag-ref push, tag,
+Release, local first install/reinstall, and non-production deployment Gates.
+Production deployment, destructive or force operations, paid resources,
+privileges, external messages, security or identity changes, user acceptance,
+scope expansion, and Envelope/Orchestrator changes remain human-only. Host or
+platform confirmations still apply.
+
+Future candidate, commit, tag, Release, artifact, install, and deployment values
+use an exact late-bound reference to one named Gate output. The Orchestrator
+freezes the full digest or OID, validates lineage, and then reviews the dependent
+Gate. This lets one confirmed Envelope drive the complete chain without using a
+mutable `latest` value or asking for another reply after each artifact appears.
+Bounded repair invalidates and recomputes every downstream derived output.
+
 ## Engineering contract
 
 For every source-code or architecture change, TFD reads
@@ -165,13 +192,20 @@ runtime or write authority.
 
 ### Knowledge confirmation
 
-Initialization, ingest, repair, conflict resolution, and schema changes use
-`PROPOSE -> CONFIRM -> APPLY`. Before confirmation, no file under `wiki/`
-changes. TFD displays the team, sources and digests, page differences,
-conflicts, index/log effects, current Wiki baseline, complete SHA-256, and
-12-character fingerprint. Natural-language confirmation may cite the short
-fingerprint; only the complete matching digest authorizes the Guard. Any
-material proposal or baseline change requires renewed confirmation.
+In manual mode, initialization, ingest, repair, conflict resolution, and schema
+changes use `PROPOSE -> CONFIRM -> APPLY`. Under a confirmed `AUTO_REVIEW`
+envelope, initialization and routine add-only ingest may replace the per-proposal
+human confirmation with Guard validation plus an Orchestrator `PASS`; repair,
+conflict resolution, and schema changes stay human-only. Before either authority
+is present, no file under `wiki/` changes. TFD displays the team, sources and
+digests, page differences, conflicts, index/log effects, current Wiki baseline,
+complete SHA-256, and 12-character fingerprint. Natural-language confirmation
+may cite the short fingerprint; only the complete matching digest authorizes
+the Guard. A material proposal or proposal-local Wiki baseline change requires
+new manual confirmation, or fresh Guard validation plus a new Orchestrator `PASS`
+for still-in-envelope initialization or routine add-only ingest. A mixed proposal with any conflict,
+repair, schema, or other human-only effect returns as a whole to manual
+confirmation. Changing an Envelope field always requires user confirmation.
 
 Sources are add-only. A revision creates a new digest-addressed snapshot and
 never overwrites an earlier version. Conflicting sourced claims remain on a
@@ -240,20 +274,24 @@ recovery system, or management control plane.
 
 ## Authority boundary
 
-Team confirmation authorizes only the named local profile writes and/or member
+Manual team confirmation authorizes only the named local profile writes and/or member
 activation. It does not authorize installation, merge, push, tag, release,
 deployment, publication, external messages, destructive cleanup, privileged
-commands, paid actions, or scope expansion. Each keeps its normal approval
-boundary.
+commands, paid actions, or scope expansion. `AUTO_REVIEW` can pre-authorize only
+the exact internal and external Gates and targets defined in its confirmed
+Envelope; the Orchestrator then supplies their TFD approval without another
+user reply. Everything outside it keeps its normal human approval boundary.
 
 A version in a local checkout does not by itself prove installation or
-deployment. Use the `v3.4.1` tag and GitHub Release as publication evidence.
+deployment. Use the `v3.5.0` tag and GitHub Release as publication evidence.
 
 ## Repository layout
 
 ```text
 plugins/tfd/.codex-plugin/plugin.json      Plugin manifest
 plugins/tfd/skills/using-tfd/SKILL.md      Single user-facing Skill
+plugins/tfd/skills/using-tfd/references/auto-review.md
+                                           On-demand AUTO_REVIEW protocol
 plugins/tfd/skills/using-tfd/references/engineering-constraints.md
                                            On-demand engineering contract
 plugins/tfd/skills/using-tfd/references/team-wiki.md

plugins/tfd/.codex-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "tfd",
-  "version": "3.4.1",
-  "description": "Session-first development with Coordinator-decomposed workstreams, YAML team profiles, member-selected Codex Runtimes, a progressively loaded engineering contract, and a per-team Markdown Team Wiki.",
+  "version": "3.5.0",
+  "description": "Session-first development with Coordinator-decomposed workstreams, Orchestrator-approved AUTO_REVIEW, YAML team profiles, member-selected Codex Runtimes, a progressively loaded engineering contract, and a per-team Markdown Team Wiki.",
   "author": {
     "name": "Howe829",
     "url": "https://github.com/Howe829"
@@ -13,8 +13,8 @@
   "skills": "./skills/",
   "interface": {
     "displayName": "Team First Development",
-    "shortDescription": "按需求拆分 workstream 并组建最小团队",
-    "longDescription": "Route simple work to one Agent, or decompose TEAM work into confirmed workstreams assigned to the minimum configured members with exact Codex Runtime bindings; apply one progressively loaded engineering contract to code changes; and retain session-scoped delivery, independent review, and a Git-native per-team Markdown Team Wiki.",
+    "shortDescription": "拆分 workstream，由 Orchestrator 自动过 Gate",
+    "longDescription": "Route simple work to one Agent, or decompose TEAM work into confirmed workstreams assigned to the minimum configured members with exact Codex Runtime bindings; optionally let the Orchestrator approve in-envelope AUTO_REVIEW gates, bounded repairs, and evidence recovery after one session-only Autonomy Envelope confirmation; apply one progressively loaded engineering contract to code changes; and retain risk-scaled independent review and a Git-native per-team Markdown Team Wiki.",
     "developerName": "Howe829",
     "category": "Developer Tools",
     "capabilities": ["Interactive", "Write"],