project-tiny-context-harness 0.7.8 → 0.7.9

package/README.md

@@ -144,7 +144,7 @@ npm ci
 npm run smoke:quickstart
 npm run preview:pack
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.8.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.9.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -165,16 +165,17 @@ Before deciding `Context Delta`, the Agent combines two low-state routes:
 2. run one bounded text search over `project_context/**` with a small set of high-signal task terms, including explicit area/module names and relevant API/schema/state/security/verification/deployment language;
 3. merge the candidates and read only semantically relevant files.
 
-The bounded search supplements rather than replaces Agent semantic judgment. It creates no vector or persistent index, cache, registry, search state or second authority. It can still miss unrelated synonyms or indirect dependencies, so high-risk work retains Architecture Context Hit and final Contract Conformance.
+The bounded search supplements rather than replaces Agent semantic judgment. It creates no vector or persistent index, cache, registry, search state or second authority. It can still miss unrelated synonyms or indirect dependencies, so every implementation delivery still performs Architecture Deliberation and final Conformance.
 
 Ordinary tasks:
 
 1. resolve minimum relevant Context through manifest routing plus bounded Context search;
-2. decide `Context Delta: none|required`;
-3. update durable facts before code when required;
+2. surface one concise, repository-bound Architecture Deliberation;
+3. decide `Context Delta: none|required` and update durable facts before code when required;
 4. use the platform's internal plan;
 5. implement and run project-owned verification;
-6. perform Contract Conformance and Context drift checks.
+6. perform Contract Conformance, including Architecture Conformance on the current candidate;
+7. perform the separate Context drift check and hand off.
 
 The default workflow has no required plan artifact, matrix, verdict, evidence ledger, persistent retrieval index or second plan. Duration, file count and complexity never auto-enable long-task state.
 
@@ -182,9 +183,13 @@ Plan Validator commands no longer exist; existing plan, matrix or verdict files
 
 ### Architecture And Modularity Guidance
 
-Technical architecture support is a Minimal Context capability. For high-risk work, `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` are internal routing questions inside the platform's internal plan. No Task Contract or fixed `plan.md` is required. The risk-triggered gate covers durable module/capability boundaries, public API/schema/data or persistence, source-of-truth/state ownership, dependency direction, cross-area work, migration/security/recovery and reusable abstractions; it resolves owner, unique source of truth, lifecycle/failure/compatibility, forbidden shortcuts and a project-owned executable architecture check. Small fixes do not pay this ceremony.
+Technical architecture support is a shared Workflow obligation. Every implementation delivery visibly completes `Architecture Deliberation` before its first implementation edit. Risk changes depth, not occurrence. A small change names the concrete owner/current extension point, confirms durable boundaries remain unchanged and explains why it adds or worsens no debt. Material work additionally covers the unique source of truth, dependency and interface/state/lifecycle boundaries, failure/recovery/compatibility, selected and rejected alternatives, one plausible future change and its extension point, touched technical debt, forbidden shortcuts and project-owned executable checks. `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` remain internal routing questions; no Task Contract or fixed `plan.md` is required.
 
-Do not invent rationale: store stable reasons, rejected alternatives or tradeoffs only in the smallest durable Context surface, and remember that architecture Context does not prove product quality. Harness routes repository-native checks rather than becoming a language-generic architecture analyzer. Modularity diagnostics identify the highest-risk function and line.
+After implementation and project verification, `Architecture Conformance` checks the current candidate for scope/path escape, owner or dependency-direction violations, service/facade bypass, duplicate authority or a second source of truth, undeclared API/schema/state/persistence change, missing architecture checks and new or worsened debt. A changed candidate invalidates the result. Default work embeds this closure in Contract Conformance; Long-Task work encodes material invariants with existing obligations/constraints/forbidden shortcuts, owners/paths/Bindings and executable Checks and lets Final Gate be the sole closure owner. The two closures never both run for one candidate.
+
+Contract Conformance asks whether current Source and Context reached implementation and verification; the separately named Context drift check asks whether implementation or a new decision made durable Context stale. New or worsened debt blocks handoff unless the project has an explicit bounded exception with owner, rationale, tracking and a removal condition. Unrelated legacy debt does not automatically expand task scope, but debt touched, relied on or worsened by the change cannot remain hidden.
+
+The visible checkpoint proves that architecture consideration occurred; it does not expose private chain-of-thought, guarantee the best design or anticipate every unknowable future request. Store stable reasons, rejected alternatives or tradeoffs only in the smallest durable Context surface. Harness routes repository-native checks rather than becoming a language-generic architecture analyzer or adding architecture artifact/state. Modularity diagnostics identify the highest-risk function and line.
 
 `ty-context check-modularity` audits selected handwritten source. `validate-code-modularity` and `validate-harness` enforce it separately from `validate-context`.
 
@@ -242,7 +247,7 @@ Long-Task now makes raw/revised proposals, selected design resources and mixed a
 
 Before the first successful formal Compile, `delivery-contract.yaml` is one non-authoritative Contract Draft. `/long-task-workflow` revises the same Draft across repository/Context reads and Preflight repairs; a complete Contract need not fit one response. Integrated authoring keeps repository evidence and findings attached to the same object and avoids a second handoff, plan, authority or Receipt. There is no standalone Contract Draft Skill or Authoring State.
 
-The Long-Task Skill keeps objective/boundary/phase routing in its main file and loads one-level Contract-authoring, evidence-design and authority-lifecycle references only when that phase applies. This is instruction packaging only, not a second authority. Declared architecture invariants use existing obligations/constraints/forbidden shortcuts, owner/path/Binding boundaries and project-owned executable Checks; a functional AC cannot substitute for an independently failing architecture claim.
+The Long-Task Skill keeps objective/boundary/phase routing in its main file and loads one-level Contract-authoring, evidence-design and authority-lifecycle references only when that phase applies. This is instruction packaging only, not a second authority. It performs the shared Architecture Deliberation during Source/Contract authoring. Declared architecture invariants use existing obligations/constraints/forbidden shortcuts, owner/path/Binding boundaries and project-owned executable Checks; a functional AC cannot substitute for an independently failing architecture claim. Final Gate is the sole Long-Task Architecture Conformance carrier.
 
 A Draft Outcome is simply an Outcome before Authority Lock. Outcomes decompose independently observable, decidable and target-verifiable results to improve dependency-ready implementation, targeted verification, failure localization, resume and stale-result invalidation. `depends_on` means acceptance readiness and the Rolling Frontier is temporary; an Outcome is not a Worker, scheduler task, queue or parallel unit. Outcome decomposes execution and diagnosis, not completion authority, so one complete current-snapshot Final Gate remains mandatory.
 
@@ -349,7 +354,7 @@ make validate-harness
 
 The modularity gate is `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
 
-The synchronized local preview tarball is named `project-tiny-context-harness-0.7.8.tgz`.
+The synchronized local preview tarball is named `project-tiny-context-harness-0.7.9.tgz`.
 
 ## Community And Further Reading
 

package/assets/README.md

@@ -67,7 +67,7 @@ Coding agents need two different kinds of help:
 - durable facts that survive sessions without loading the whole repository;
 - trustworthy completion checks when a task spans many edits or context compactions.
 
-Tiny Context keeps those concerns narrow. `project_context/**` records durable ownership, architecture, contracts and repeatable verification. The default Workflow Contract combines manifest routing with one bounded Context search before `Context Delta`. The explicit Long-Task Workflow adds one machine-checked Delivery Contract, a one-time post-Authority-Lock model choice, rolling repair verification, a same-snapshot Final Gate and Stop freshness.
+Tiny Context keeps those concerns narrow. `project_context/**` records durable ownership, architecture, contracts and repeatable verification. Both implementation routes share one visible, risk-proportional Architecture Deliberation before implementation and one current-candidate Architecture Conformance after project verification. The default Workflow Contract combines manifest routing with one bounded Context search before `Context Delta`; the explicit Long-Task Workflow adds one machine-checked Delivery Contract, a one-time post-Authority-Lock model choice, rolling repair verification, a same-snapshot Final Gate and Stop freshness.
 
 It does not launch or switch models, spawn agents, create branches or worktrees, merge, push, open pull requests, deploy, or claim to replace project tests and human acceptance.
 
@@ -146,7 +146,7 @@ The smoke packs the local workspace, installs it into a disposable repo and vali
 
 ```sh
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.8.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.9.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -193,11 +193,12 @@ Ordinary tasks stay lightweight:
 
 1. read core/default Context and collect manifest candidates;
 2. run one bounded Context search over `project_context/**` and read only relevant matches;
-3. decide `Context Delta: none|required`;
-4. update owning Context first when durable semantics change;
+3. surface one concise, repository-bound Architecture Deliberation;
+4. decide `Context Delta: none|required` and update the owning Context first when durable semantics change;
 5. use the platform's internal plan;
 6. implement and run project-owned verification;
-7. perform Contract Conformance and Context drift checks.
+7. perform Contract Conformance, including Architecture Conformance on the current candidate;
+8. perform the separate Context drift check and hand off.
 
 The default workflow creates no required `plan.md`, matrix, verdict, evidence ledger, persistent Context-search index or second execution plan. Task length, file count and complexity never auto-enable long-task state.
 
@@ -205,9 +206,13 @@ Plan Validator commands no longer exist; existing plan, matrix or verdict files
 
 ### Architecture And Modularity Guidance
 
-Technical architecture support is a Minimal Context capability. For high-risk work, `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` are internal routing questions inside the platform's internal plan. No Task Contract or fixed `plan.md` is required. The architecture gate is risk-triggered for durable module/capability boundaries, public API/schema/data or persistence, source-of-truth/state ownership, dependency direction, cross-area work, migration/security/recovery and reusable abstractions. It resolves owner, unique source of truth, dependency direction, interface/state lifecycle, failure/recovery/compatibility, forbidden shortcuts and the project-owned executable check that protects the boundary. Small fixes do not pay this ceremony.
+Technical architecture support is a shared Workflow obligation. Every implementation delivery visibly completes `Architecture Deliberation` before its first implementation edit. Risk changes depth, not occurrence. A small change names the concrete owner/current extension point, confirms durable boundaries remain unchanged and explains why it adds or worsens no debt. Material work additionally covers the unique source of truth, dependency and interface/state/lifecycle boundaries, failure/recovery/compatibility, selected and rejected alternatives, one plausible future change and its extension point, touched technical debt, forbidden shortcuts and project-owned executable checks. `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` remain internal routing questions; no Task Contract or fixed `plan.md` is required.
 
-Do not invent rationale: store stable reasons, rejected alternatives or tradeoffs only in the smallest durable Context surface, and remember that architecture Context does not prove product quality. Harness may route repository-native lint/AST/dependency/contract checks, but it does not become a language-generic architecture analyzer.
+After implementation and project verification, `Architecture Conformance` checks the current candidate for scope/path escape, owner or dependency-direction violations, service/facade bypass, duplicate authority or a second source of truth, undeclared API/schema/state/persistence change, missing architecture checks and new or worsened debt. A changed candidate invalidates the result. Default work embeds this closure in Contract Conformance; Long-Task work encodes material invariants with existing obligations/constraints/forbidden shortcuts, owners/paths/Bindings and executable Checks and lets Final Gate be the sole closure owner. The two closures never both run for one candidate.
+
+Contract Conformance asks whether current Source and Context reached implementation and verification; the separately named Context drift check asks whether implementation or a new decision made durable Context stale. New or worsened debt blocks handoff unless the project has an explicit bounded exception with owner, rationale, tracking and a removal condition. Unrelated legacy debt does not automatically expand task scope, but debt touched, relied on or worsened by the change cannot remain hidden.
+
+The visible checkpoint proves that architecture consideration occurred; it does not expose private chain-of-thought, guarantee the best design or anticipate every unknowable future request. Store stable reasons, rejected alternatives or tradeoffs only in the smallest durable Context surface. Harness may route repository-native lint/AST/dependency/contract checks, but it does not become a language-generic architecture analyzer or add an architecture artifact/state.
 
 `ty-context check-modularity` audits selected handwritten source and identifies the highest-risk function and line for statement/branch findings. `validate-code-modularity` and `validate-harness` enforce it separately from `validate-context`.
 
@@ -282,7 +287,7 @@ The first successful Compile creates Authority Lock and returns `execution_model
 
 Later revisions are classified into three paths. Formally monotonic evidence strengthening and other proven mechanical-safe changes auto-adopt. A candidate whose only protected reasons are owner, expected-change or allowed-support expansion may be exercised through `diagnose-revision` using existing active Check identities whose runner and verifier are unchanged; safe monotonic strengthening may coexist, and the results remain transient repair diagnostics rather than Progress or acceptance. Product/Source/Acceptance semantic changes, proof weakening, verifier-content or runner changes, and risk increases are preview-only and require the exact revision identity; risk downgrade remains rejected outright. A rolling blocker is not itself an External Confirmation or permission to remove machine-verifiable scope. A real scope change first becomes marked Source. Diagnosis never changes the active Authority or writes pending/approval state, cache, Progress or Receipt, so related edits can accumulate in the same `delivery-contract.yaml` before one `compile --revise` approval request. The pending decision contains a concise hash-bound summary with exact changed semantic fields, Source/Product Claim reductions, proof reductions and external-confirmation keys and is projected by `status`/`resume`. Adoption reports `delivery_completed_by_this_event: false`, invalidates affected evidence and returns to rolling implementation or repair; the complete Final Gate remains mandatory.
 
-The package-managed Long-Task Skill uses progressive disclosure: its main `SKILL.md` keeps the objective, boundaries and phase routing; one-level references are read only for Contract authoring, evidence design or authority lifecycle. This reduces routine instruction load without moving any rule into a second authority. When Source or controlling Context declares an architecture invariant, the Contract uses existing technical obligations/global constraints/forbidden shortcuts, owner/path/Binding boundaries and a project-owned executable Check. Functional acceptance cannot substitute when the architecture invariant can fail independently.
+The package-managed Long-Task Skill uses progressive disclosure: its main `SKILL.md` keeps the objective, boundaries and phase routing; one-level references are read only for Contract authoring, evidence design or authority lifecycle. This reduces routine instruction load without moving any rule into a second authority. It performs the shared Architecture Deliberation during Source/Contract authoring. When Source or controlling Context declares an architecture invariant, the Contract uses existing technical obligations/global constraints/forbidden shortcuts, owner/path/Binding boundaries and a project-owned executable Check. Functional acceptance cannot substitute when the architecture invariant can fail independently, and Final Gate is the sole Long-Task Architecture Conformance carrier.
 
 A Draft Outcome is simply an Outcome before Authority Lock. Outcomes split independently observable, decidable, vertical and target-verifiable results so the current Goal can keep a smaller dependency-ready working set, target verification, localize failures, resume findings and invalidate stale local results. `depends_on` expresses acceptance readiness. Every Outcome belongs to one ordered Stage; its Stage gate transitively depends on the other Outcomes in that Stage, and later Stages depend on earlier gates. The Rolling Frontier and Stage status are derived from ordinary Outcome Progress and are temporary. An Outcome is not a Worker, scheduler task, queue or parallelism unit, and a Stage owns no Receipt or second Gate. Outcome decomposes execution and diagnosis, not completion authority: targeted passes never replace the one complete Final Gate on the current final snapshot.
 
@@ -518,7 +523,7 @@ make validate-harness
 
 The modularity gate is `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
 
-`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.7.8.tgz` under the preview output directory.
+`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.7.9.tgz` under the preview output directory.
 
 ## Community And Further Reading
 

package/assets/README.zh-CN.md

@@ -78,7 +78,7 @@ manifest/trigger 命中的少量 area/role Context
 3. 合并两路候选，只读取真正相关的 Context；
 4. 再判断 `Context Delta: none|required`。
 
-这次搜索只补充语义判断，不会把所有关键词命中都当成 Authority，也不会创建向量/持久索引、缓存、Registry、search state 或第二权威。它仍可能漏掉完全不同的同义词或间接依赖，因此高风险任务还需要 Architecture Context Hit 与收尾 Conformance。
+这次搜索只补充语义判断，不会把所有关键词命中都当成 Authority，也不会创建向量/持久索引、缓存、Registry、search state 或第二权威。它仍可能漏掉完全不同的同义词或间接依赖，因此每个实现需求仍要执行 Architecture Deliberation 与收尾 Conformance。
 
 `ty-context doctor` 会报告确定性的默认 Context 文件/字节规模、单文件与总量软预算超限、字节完全相同的默认文件，以及 `DESIGN.md` 权威状态。这些只是维护提示，不是新验证 Gate 或运行时状态。
 
@@ -88,11 +88,12 @@ Context 负责耐久的意图和边界，代码负责当前实现，测试/CI/
 
 1. 读取 core/default Context，收集 manifest 候选；
 2. 在 `project_context/**` 做一次 bounded Context search；
-3. 决定 `Context Delta: none|required`；
-4. 耐久语义改变时先更新 owner Context；
+3. 对用户可见地给出一次简洁、仓库事实绑定的 Architecture Deliberation；
+4. 决定 `Context Delta: none|required`，耐久语义改变时先更新 owner Context；
 5. 使用平台内部计划；
 6. 实现并运行项目验证；
-7. 执行 Contract Conformance 与 Context drift 检查。
+7. 执行 Contract Conformance，其中包含对当前候选快照的 Architecture Conformance；
+8. 单独执行 Context drift check 后交付。
 
 默认工作流不要求 `plan.md`、matrix、verdict、evidence ledger、持久检索索引或第二份执行计划。任务时长、文件数和复杂度不会自动激活长程状态。
 
@@ -106,11 +107,15 @@ Context: no durable fact change
 
 ### 架构与模块质量
 
-技术架构能力属于 Minimal Context。高风险工作在平台内部计划中使用 `Architecture Context Hit`、`Decision Rationale Hit: existing|required|none` 和 `Modularity Check: none|required|exception`，不创建 Task Contract 或固定 `plan.md`。
+技术架构能力是两条实现路径共享的 Workflow 义务。每个实现需求都在第一处实现编辑前，对用户可见地完成一次 `Architecture Deliberation`；风险改变深度，不取消这个环节。小修改要指出具体 owner / 当前 extension point、未改变的耐久边界，以及为何没有新增或加重技术债。material 工作还要覆盖唯一 source of truth、dependency 与 interface/state/lifecycle 边界、failure/recovery/compatibility、选中和拒绝的方案、至少一个合理未来变化及其扩展点、触达的技术债、forbidden shortcuts 和项目原生可执行检查。
 
-只有新长期模块/能力、公共 API/Schema/data/persistence、source of truth/state ownership、dependency direction、跨 area、migration/security/recovery 或可复用抽象才触发架构 Gate；小修复不支付这项成本。Gate 要明确 owner、唯一事实源、依赖方向、接口/状态生命周期、失败/恢复/兼容、禁止绕过路径和项目自己的可执行架构检查。
+实现和项目验证之后，`Architecture Conformance` 对当前候选快照检查 scope/path escape、owner 或 dependency direction 违规、service/facade 绕过、重复权威或第二 source of truth、未声明 API/Schema/state/persistence 变化、缺失架构检查和新增/加重技术债。候选再变化就使结果失效。普通任务把它放在 Contract Conformance 内；Long-Task 用已有 obligation/constraint/forbidden shortcut、owner/path/Binding 和 executable Check 表达不变量，只由 Final Gate 收口，同一候选不会执行两次。
 
-Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨语言通用架构分析器。`check-modularity` 的语句数/分支风险会定位到最高风险函数和行号。
+Contract Conformance 主要检查当前 Source/Context 是否到达实现和验证；单独命名的 Context drift check 反向检查实现或新决策是否让耐久 Context 过时。新增或加重技术债默认阻塞，除非项目有带 owner、rationale、tracking 和 removal condition 的显式 bounded exception。无关 legacy debt 不自动扩张任务范围，但本次触达、依赖或加重的债不能隐藏。
+
+`Architecture Context Hit`、`Decision Rationale Hit: existing|required|none` 和 `Modularity Check: none|required|exception` 仍是内部路由问题，不创建 Task Contract 或固定 `plan.md`。可见检查点证明“做过架构考量”，不暴露私有思维链，也不保证最佳设计或预知所有未知未来需求。
+
+Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨语言通用架构分析器或新增架构 artifact/state。`check-modularity` 的语句数/分支风险会定位到最高风险函数和行号。
 
 ### Product Surface 与 Screen Contract
 
@@ -191,7 +196,7 @@ Agent 此时在实现前只暂停一次，请用户选择：继续当前模型
 
 锁定后的修订分三类：机器可证明的单调证据增强和机械安全变化自动采用；如果唯一的受保护原因只是扩大 owner、expected-change 或 allowed-support path（可以同时带有安全的单调增强），就能用 `diagnose-revision` 在不切换 Authority 的前提下运行原 Active Authority 已有且未更换的 Check；产品/Source/Acceptance 语义变化、证明弱化、verifier 内容或 runner 变化、风险上升只给摘要，不运行候选，风险降级则直接拒绝。滚动实现遇阻本身不是 External Confirmation，也不允许删除机器可验证范围；真正的范围变化必须先成为 marked Source。诊断结果不是 Progress 或 acceptance，也不会写 pending/approval、cache、Receipt 或 marker。相关修改只在同一份 `delivery-contract.yaml` 中累计，最终由一次 `compile --revise` 生成精确 hash 与包含语义字段、Source/Product Claim 缩减、proof 缩减和 external-confirmation key 的短摘要；`status`/`resume` 投影同一个待批决策。批准并原子采用后返回 `delivery_completed_by_this_event: false`，旧证据失效并回到滚动实现或修复，完整 Final Gate 仍必须重跑。
 
-Long-Task Skill 采用渐进读取：主 `SKILL.md` 只保留目标、硬边界和阶段路由；Source Authoring、Contract Authoring、Evidence Design 与 Authority Lifecycle 细节只在对应阶段读取一层 reference。这只是指令组织，不产生第二权威。
+Long-Task Skill 采用渐进读取：主 `SKILL.md` 只保留目标、硬边界和阶段路由；Source Authoring、Contract Authoring、Evidence Design 与 Authority Lifecycle 细节只在对应阶段读取一层 reference。这只是指令组织，不产生第二权威。共享 Architecture Deliberation 在 Source/Contract authoring 中完成；material 架构不变量使用已有 obligations/constraints/forbidden shortcuts、owner/path/Binding 和项目原生 executable Checks，Final Gate 是唯一的 Long-Task Architecture Conformance 承载点。
 
 Draft Outcome 只是 Authority Lock 前的 Outcome。Outcome 按可独立观察、判断、纵向闭环和定向验证的结果拆分，使当前 Goal 能缩小 dependency-ready 工作集、定向验证、定位失败、恢复 finding 并精确失效旧局部结果。`depends_on` 只表示 acceptance readiness。每个 Outcome 属于一个有序 Stage；Stage gate 传递依赖同 Stage 其余 Outcome，后续 Stage 依赖前置 gate。Rolling Frontier 和 Stage 状态都由普通 Outcome Progress 临时派生；Outcome 不是 Worker、scheduler task、queue 或并行单元，Stage 也没有 Receipt 或第二个 Gate。Outcome 拆分执行和诊断，不拆分完成权威，因此最终仍必须在当前最终快照运行一次完整 Final Gate。
 

package/assets/agents/AGENTS_CORE.md

@@ -4,6 +4,12 @@ This project uses Tiny Context. The Harness maintains durable Context and workfl
 
 Tiny Context has three capabilities: Minimal Context, the default Workflow Contract, and the explicitly enabled Single-Goal Long-Task Workflow.
 
+## Shared Architecture Quality Obligation
+
+Every implementation delivery performs one externally observable, repository-bound `Architecture Deliberation` before the first implementation edit. Its depth is risk-proportional, but the occurrence is universal: identify affected owners and the current extension point/source of truth, dependency and state/lifecycle boundaries, the selected design and material alternatives, one plausible future-change challenge, touched technical debt and its disposition, forbidden shortcuts, and project-owned checks. A small change may conclude that existing architecture is preserved, but must name the concrete owner/extension point and why no new or worsened debt is introduced. Surface conclusions and repository evidence, not private chain-of-thought, and refresh the checkpoint if scope, ownership or the selected design materially changes.
+
+After implementation and project verification, perform one `Architecture Conformance` closure on the current candidate snapshot. The default path embeds it in Contract Conformance; an active Long-Task embeds it only in Final Gate. Never schedule both. A changed candidate invalidates the closure and must be rechecked. New or worsened debt, an undeclared second source of truth, wrong dependency direction, owner bypass, scope escape or a forbidden shortcut blocks handoff unless an explicit project-owned bounded exception records owner, rationale, tracking and removal condition. This obligation creates no plan artifact, architecture document, second Authority, workflow state or generic architecture analyzer.
+
 ## Default Workflow Contract
 
 Unless an active Long-Task binding exists:
@@ -11,9 +17,9 @@ Unless an active Long-Task binding exists:
 1. Read `project_context/global.md`, `project_context/architecture.md`, `project_context/context.toml` and the default area root, then collect graph/trigger candidates.
 2. Before deciding `Context Delta`, run one bounded text search over `project_context/**` using a small set of high-signal task terms such as explicit area/module names and API/schema/state/security/verification/deployment terms. Merge matching Context with manifest candidates and read only relevant files; search supplements rather than replaces semantic judgment.
 3. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes; Product Surface Contracts own cross-surface interfaces and optional on-demand Screen Contracts use existing area/subdomain/contract/verification roles for deeper screen/control facts. Before material production UI implementation, reconcile each affected stable surface/control/target key as Context-covered, requiring a Context update, task-local, out of scope or decision-required, then read `DESIGN.md`, its token source and referenced design targets. An unconfigured starter, candidate, style-only guidance or inspiration does not authorize invented production layout; only a selected exact/constraint target with adequate declared coverage authorizes fidelity. `design-system-authoring` is an explicit-only cold-start/repair capability that uses Open Design to generate/select/adopt project Design Authority; never infer or auto-run it. For an explicit standalone request to generate or iterate resources, `design-resource-authoring` keeps the requested output/development content as the hard ceiling. Style-bearing work stops on unconfigured Design Authority and points to the explicit design-system Skill; non-fidelity work remains lightweight. Configured style-bearing Open Design projects bind and verify the adopted provider design-system ID. After final selection, design-resource authoring may reconcile accepted decisions into the initial proposal exactly once, but it never changes Context, `DESIGN.md`, a Source Plan, code or Contract. Its resources remain ordinary Source until the consuming workflow adopts durable meaning.
-4. Decide exactly one `Context Delta: none|required`. Update owning Context before code when durable product ownership, architecture, API/schema/data, state/recovery, dependency, security, product-surface responsibility or repeatable verification/deployment changes. Local fixes preserving durable semantics are `none`.
-5. Use the agent/platform internal plan. For high-risk work keep `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` as internal routing and maintenance questions, not artifacts or extra deltas.
-6. Implement precisely, run project-owned verification, perform Contract Conformance and a Context drift check, then report implementation, verification, Context status and blockers.
+4. Complete the shared `Architecture Deliberation`, then decide exactly one `Context Delta: none|required`. Update owning Context before code when durable product ownership, architecture, API/schema/data, state/recovery, dependency, security, product-surface responsibility or repeatable verification/deployment changes. Local fixes preserving durable semantics are `none`.
+5. Use the agent/platform internal plan. Keep `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` as internal routing and maintenance questions, not artifacts or extra deltas.
+6. Implement precisely, run project-owned verification, perform Contract Conformance including the shared `Architecture Conformance`, then run the separate Context drift check and report implementation, verification, architecture conformance, Context status and blockers.
 
 The default workflow never requires a plan artifact, matrix, verdict, evidence ledger or result document. Optional scratch is not Context or completion proof. The bounded Context search creates no index, cache, state or second authority.
 
@@ -37,7 +43,7 @@ After the first Authority Lock, stop once before implementation and ask the user
 
 Before authoring, proof design or authority lifecycle work, read the phase-specific references in the package-managed `long-task-workflow` Skill. Use `ty-context long-task help` for CLI syntax instead of treating this startup router as a command reference.
 
-Final Gate, Stop and close recompile the source Contract and rerun every declared Check on one clean current snapshot. Required targets cannot substitute for one another; presence cannot prove behavior; success and degradation remain distinct; typed boundary effects require an observer. Targeted verify is repair evidence only. Status, progress, Stage/frontier projections, receipts and compiled cache are audit/recovery surfaces only; prose, historical tests or Agent judgment never create acceptance. An adopted Authority Revision returns to rolling execution and is never delivery completion. External confirmations remain typed and explicit; machine acceptance reports target/stage qualification but cannot by itself authorize completing the platform-native Goal, CI, deployment or human acceptance.
+Final Gate, Stop and close recompile the source Contract and rerun every declared Check on one clean current snapshot. Final Gate is the Long-Task path's sole `Architecture Conformance` owner; do not run a second default-workflow closure. Required targets cannot substitute for one another; presence cannot prove behavior; success and degradation remain distinct; typed boundary effects require an observer. Targeted verify is repair evidence only. Status, progress, Stage/frontier projections, receipts and compiled cache are audit/recovery surfaces only; prose, historical tests or Agent judgment never create acceptance. An adopted Authority Revision returns to rolling execution and is never delivery completion. External confirmations remain typed and explicit; machine acceptance reports target/stage qualification but cannot by itself authorize completing the platform-native Goal, CI, deployment or human acceptance.
 
 Tiny Context does not create or restore platform Goals, invoke models, spawn agents, call an App Server, create branches/worktrees, merge, push, open PRs, deploy or manage process trees. `ty-context enable long-task` installs the Long-Task Workflow Skill, the retired Source Plan compatibility pointer and package-owned completion Hook.
 

package/assets/skills/context_development_engineer/SKILL.md

@@ -21,14 +21,16 @@ When an active `/long-task-workflow` binding exists, that Skill owns lifecycle,
 2. 在判断 `Context Delta` 前，用任务中明确的 area/module/API/Schema/state/security/verification/deployment 等少量高信号词，对 `project_context/**` 做一次 bounded text search；把命中的 Context 与 manifest 候选合并，只读取真正相关文件。搜索只补充语义判断，不创建索引、缓存或第二权威。
 3. 确认目标、约束、成功标准、影响域、验证/部署路径和风险。能从代码或 Context 得到的事实不要重复询问。
 4. Context 决定“应该是什么”；代码说明“现在是什么”；测试和运行证据证明行为。冲突是实现漂移、缺失工作或 stale Context，不能由代码静默重定义归属。
-5. 第一处编辑前决定唯一 `Context Delta: none|required`。影响 durable architecture boundary、module ownership、API / Schema / data contract、state / runtime semantics、dependency direction、verification / deployment semantics 或 durable rationale / tradeoff 时为 `required`，先更新 owning Context。不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。
-6. 用 Agent 内部计划保持 goal、non-goals、owner、boundaries、implementation surfaces、risk 和 verification 清晰。默认流程不要求或验证固定 `plan.md`、matrix、verdict 或 evidence ledger。
-7. 普通 bug fix、局部样式/实现漂移、小重构、package/release、测试修复或探索性 spike 不支付架构仪式成本；它们是 small code task，除非过程中形成了新的长期工程事实。
-8. 实现后运行 project-owned verification，做 `Contract Conformance` 和 Context drift check，只报告 `Context: 已更新 ...` 或 `Context: 本次无长期事实变化`。
+5. 第一处实现编辑前，完成并对用户可见地给出一次简洁、仓库事实绑定的 `Architecture Deliberation`。不输出私有思维链；输出结论及其 Context、模块/路径、symbol/extension point 和验证依据。风险只改变深度，不取消这个环节。
+6. 根据架构考量决定唯一 `Context Delta: none|required`。影响 durable architecture boundary、module ownership、API / Schema / data contract、state / runtime semantics、dependency direction、verification / deployment semantics 或 durable rationale / tradeoff 时为 `required`，先更新 owning Context。不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。
+7. 用 Agent 内部计划保持 goal、non-goals、owner、boundaries、implementation surfaces、risk 和 verification 清晰。默认流程不要求或验证固定 `plan.md`、matrix、verdict 或 evidence ledger。
+8. 实现后先运行 project-owned verification，再在 `Contract Conformance` 中对当前候选快照执行 `Architecture Conformance`，随后单独做 Context drift check；报告实现、验证、架构符合性、Context 状态和 blockers。
 
-## 风险触发 Architecture Gate
+## 必经 Architecture Deliberation
 
-仅在下列任一情况触发；这是内部判断，不是新 artifact、validator 或 delta：
+每个实现需求都执行一次。small code task 可以得到“保持现有架构”的浅层结论，但必须具体指出当前 owner / extension point、未改变的 durable boundary、验证入口，以及为何没有引入或加重技术债，不能用“无需架构考虑”跳过。
+
+出现下列任一情况时提高到完整深度：
 
 - 新长期模块/能力/公共抽象；
 - 公共 API、Schema、data contract、持久化或迁移；
@@ -37,7 +39,7 @@ When an active `/long-task-workflow` binding exists, that Skill owns lifecycle,
 - security/permission、兼容性、降级、重试、并发或不可逆边界；
 - 一个变化异常扩散到多个不相关模块，或现有扩展点无法承载。
 
-内部保持：
+对用户可见的简洁结论覆盖适用项：
 
 - `Architecture Context Hit`：哪个现有 Context 控制本次架构判断；
 - `Decision Rationale Hit: existing|required|none`：是否存在会改变未来选择的稳定原因；
@@ -45,10 +47,27 @@ When an active `/long-task-workflow` binding exists, that Skill owns lifecycle,
 - 正确 dependency direction 与禁止 bypass；
 - interface、input/output、state、persistence 和 lifecycle；
 - failure/retry/timeout/degraded/recovery、compatibility/migration；
+- 选择的设计与重要备选方案、拒绝原因；
+- 至少一个合理的相邻未来变化会落到哪个 extension point，且不会形成第二 source of truth 或反向依赖；
+- 触达的技术债：本次消除、保持隔离且不加重，或因缺少有 owner/reason/tracking/removal condition 的 bounded exception 而阻塞；
 - 应复用的 extension point，或新抽象为何确有净收益；
 - 哪个 project-owned lint/AST/dependency/contract test 能证明边界。
 
-持久结论进入最小 owning Context；实现细节留在代码。不要把“代码更优雅”当作架构要求，也不要让 Harness 变成跨语言通用 dependency analyzer。
+范围、owner、controlling Context、dependency direction 或选定设计发生实质变化时，原考量失效，继续实现前先更新。持久结论进入最小 owning Context；实现细节留在代码。不要把“代码更优雅”当作架构要求，也不要让 Harness 变成跨语言通用 dependency analyzer。
+
+## Architecture Conformance
+
+默认流程在项目验证之后，把架构符合性作为 `Contract Conformance` 的必检子项，只针对当前候选快照检查：
+
+- 实际改动是否逃逸预期 capability/path；
+- owner、dependency direction、service/facade/adapter 和唯一 source of truth 是否被绕过或复制；
+- API/Schema/data/state/persistence/lifecycle/recovery 是否出现未声明变化；
+- 是否命中 forbidden shortcut，是否运行了声明的 project-owned architecture/modularity checks；
+- 是否新增或加重重复、职责膨胀、脆弱耦合或无依据抽象等技术债。
+
+发现问题就返回实现并重跑受影响验证；候选代码或配置再变化，先前 closure 失效。新增或加重技术债默认阻塞交付，除非项目已有显式、收窄、带 owner/reason/tracking/removal condition 的例外。无关 legacy debt 不自动扩张任务范围，但本次触达、依赖或加重的债不能隐藏。
+
+active Long-Task 下不再执行这个默认 closure；同一架构义务由 Contract 中现有 obligations/constraints/forbidden shortcuts、owners/paths/Bindings 和 executable Checks 表达，并只由 Final Gate 对最终快照收口。
 
 ## Capability-First Delivery Boundary
 
@@ -105,8 +124,8 @@ If an active Long-Task applies, express material visual expectations through its
 
 - area/domain/subdomain：产品或包责任；contract：API/schema/event/workflow/interface；foundation：稳定概念；verification/deployment：可重复路径；implementation-index：导航；decision-rationale：会影响未来选择的稳定原因。
 - 模块 Context 只保留 principles、design logic、rejected alternative/tradeoff 和长期约束；不编造 rationale，不复制实现摘要、命令输出、debug 过程、截图、日志、临时 JSON、raw payload、测试报告或 secrets。
-- `Context Delta: none|required` 是唯一长期事实结果；`Architecture Context Hit`、`Decision Rationale Hit` 与 `Modularity Check` 仍只是内部路由问题。
+- `Context Delta: none|required` 是唯一长期事实结果；`Architecture Deliberation` 是可见但 task-local 的流程检查点，`Architecture Context Hit`、`Decision Rationale Hit` 与 `Modularity Check` 仍只是内部路由问题。
 
 ## 输出边界
 
-不默认创建 `.work_products/**`、tech plan、ADR、implementation doc、review/test/release 文档或 lifecycle phases。用户明确要求独立开发/技术方案时可以临时生成；稳定结论仍提炼回 `project_context/**`。
+不默认创建 `.work_products/**`、tech plan、ADR、implementation doc、review/test/release 文档或 lifecycle phases。`Architecture Deliberation` 与 `Architecture Conformance` 通过工作更新和交付状态可见，不生成新的持久产物。用户明确要求独立开发/技术方案时可以临时生成；稳定结论仍提炼回 `project_context/**`。

package/assets/skills/long-task-workflow/SKILL.md

@@ -44,7 +44,7 @@ A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema
 
 ## Entry And Authoring Loop
 
-1. Read the user request or external initial proposal, selected design resources and minimum controlling Context, then decide `Context Delta: none|required`.
+1. Read the user request or external initial proposal, selected design resources and minimum controlling Context. Collect the architecture owners, extension points and boundaries needed for the shared deliberation before deciding `Context Delta`.
    - For material production UI, read the Contract-authoring visual guidance before Compile. Inspect any external design resources as ordinary Source, including selection basis, stable identity and declared surface/viewport/mode/state coverage. An unconfigured starter, candidate, style-only rule or inspiration-only reference is incomplete design authority unless Source explicitly scopes the result as prototype/non-fidelity or supplies a selected target before implementation.
    - If the user is asking to generate or iterate standalone design resources before Contract authoring rather than execute this delivery, use `design-resource-authoring` instead. Its result may later return as ordinary Source; it creates no Contract Draft or Authority.
 2. If a valid active binding exists, run `ty-context long-task resume <workdir>` and read the lifecycle reference.
@@ -55,10 +55,11 @@ A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema
 7. Continue reading repository, Source and Context and revise the same Draft. A request to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent the user's tradeoff priorities. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. Infer them only from the user's words, Source, Context or controlling constraints. If quality versus cost, speed, reliability, privacy, lock-in, operational burden or another material priority is unknown or ambiguous, stop before that research or selection and ask one concise targeted clarification. Do not impose a questionnaire, re-ask known preferences or interrupt minor reversible choices whose recommendation would not change.
 8. Once the material preference envelope is clear, decide what research is needed. Use current authoritative or primary evidence for external capability, pricing, quota, license, compatibility, region, security posture or support claims. When one recommendation is then defensible, record it in real Source with the authoring instruction, preference/evidence basis and exact added meaning instead of pausing for approval. Append the delegated item without rewriting the user's original text when ordinary prose is the Source. Return only when authoritative requirements conflict, the user explicitly reserves the choice, a material preference remains unknown, critical semantics have no defensible recommendation or no falsifiable acceptance standard can be formed.
 9. Contract expansion remains limited to meaning-preserving structural decomposition, evidence-backed repository binding and choices first recorded as delegated real Source. Never place a new product rule, default, threshold, recovery behavior, permission or platform/data scope only in Contract YAML. Default plan delegation authorizes meaning, not action: payment, contracting, production deployment or publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named external confirmations. Any conflicting, user-reserved, missing-preference or unsupported semantic remains `decision_required`.
-10. Give every Check an atomic Given/When scenario and journey role; give every Assertion the minimum all-of Evidence Capabilities that can actually prove its Claim. Separate required success and degradation Checks. Type every external confirmation with impacted Claim refs and target-blocking effect. Run read-only `ty-context long-task preflight <workdir>`, repair every error and `decision_required` finding in the same Draft, then formally Compile only when ready.
-11. When the first Compile returns `execution_model_checkpoint.required: true`, stop before implementation and ask the user to choose `continue_current_model` or switch models and then resume the active Long-Task. A task-specific choice already stated explicitly satisfies the checkpoint. Later revisions return `required: false` and do not repeat it.
+10. Before formal Compile and the first implementation edit, complete the shared `Architecture Deliberation` once and surface concise repository-bound conclusions rather than private reasoning. Cover the current owner/extension point/source of truth, dependencies and lifecycle, selected and rejected alternatives, a plausible future-change challenge, touched debt and its disposition, forbidden shortcuts and project-owned Checks. Even a preservation result names concrete owners and why no new or worsened debt is introduced. Put durable conclusions in owning Context and material falsifiable delivery conclusions in real marked Source plus existing Contract fields, then decide `Context Delta: none|required`. A material scope, owner, Context or design change before implementation stales and refreshes the deliberation.
+11. Give every Check an atomic Given/When scenario and journey role; give every Assertion the minimum all-of Evidence Capabilities that can actually prove its Claim. Separate required success and degradation Checks. Type every external confirmation with impacted Claim refs and target-blocking effect. Run read-only `ty-context long-task preflight <workdir>`, repair every error and `decision_required` finding in the same Draft, then formally Compile only when ready.
+12. When the first Compile returns `execution_model_checkpoint.required: true`, stop before implementation and ask the user to choose `continue_current_model` or switch models and then resume the active Long-Task. A task-specific choice already stated explicitly satisfies the checkpoint. Later revisions return `required: false` and do not repeat it.
 
-Architecture quality uses the existing authority model, not a new gate: when Source or controlling Context declares an architecture invariant, encode it as a Source-backed technical obligation/global constraint/forbidden shortcut plus owner/path/Binding boundaries and a project-owned executable Check. Functional acceptance cannot substitute when the architecture claim can fail independently. An unverifiable design preference remains task-local, durable Context or `decision_required`; it must not be promoted into false proof.
+Architecture quality uses the existing authority model, not a new gate or field. The visible deliberation proves that architecture work occurred, not that subjective quality is machine-proven. Encode every material falsifiable invariant as a Source-backed technical obligation/global constraint/forbidden shortcut plus owner/path/Binding boundaries and a project-owned executable Check. Functional acceptance cannot substitute when the architecture claim can fail independently. An unverifiable design preference remains task-local, durable Context or `decision_required`; it must not be promoted into false proof.
 
 ## Rolling Execution
 
@@ -66,6 +67,8 @@ After Authority Lock and the one-time execution-model checkpoint are satisfied,
 
 Re-evaluate `Context Delta` whenever implementation or repair discovers a durable fact. Controlling Context changes use protected revision; graph-derived, non-explicit `implementation-index` and `archive` are Supporting Context in referenced mode and may auto-revise when only navigation/background changed. Full snapshot mode treats every selected Context file as controlling.
 
+If rolling implementation materially changes scope, ownership, dependency direction, the selected design or a debt disposition, refresh the Architecture Deliberation and express any authority change through marked Source/Context plus protected revision before continuing. This is refinement of the same checkpoint, not a second workflow stage.
+
 Use targeted `verify --outcome/--check` only to drive repair. Progress is repair evidence only and never acceptance authority. Keep precise findings attached to the owning Source item, Claim, Assertion, Check, Binding and owner path. Do not add another model-switch pause or coordinate parallel subagents.
 
 When the Contract declares a target-runtime Check because a proxy can pass while the target fails independently, run it at the earliest owning Outcome's first runnable boundary. Every required target is proved separately from its root; Browser evidence requires Playwright and Native/Desktop evidence requires the project binary. After accumulated changes to declared `input_paths` or Binding carriers make the result stale, rerun before dependent work grows. Coalesce related edits and use the cheapest reliable target Check; do not mandate a full environment rebuild per Outcome or per edit. This is rolling feedback through existing targeted verify, not acceptance, a trigger queue or per-target progress state.
@@ -78,10 +81,12 @@ Complete Context, implementation and project tests, create a clean candidate com
 
 Final Gate recompiles Source authority, validates active task/revision/compiled/worktree identity, creates one Git-tree snapshot, reruns every required Global and Outcome Check and rechecks active identity before acceptance. It derives Stage results and target qualification from that run; it does not trust targeted Progress as a Stage pass. A target-runtime Check must exercise its exact target in that current Gate execution; rerunning a reader for a historical or tracked status report is not live target proof. Final Gate, Stop and close never trust historical Progress, Receipt or compiled cache.
 
+Final Gate is the Long-Task path's sole `Architecture Conformance` carrier. It reruns the declared architecture obligations/constraints/forbidden shortcuts, owner/path/Binding boundaries and project-owned Checks on that same snapshot and blocks scope escape, bypass, duplicate authority, a second source of truth, wrong dependency direction, undeclared boundary change or new/worsened debt represented by those invariants. Do not also run the default Workflow's standalone Contract Conformance closure. Any later candidate or authority change invalidates the Gate and uses the existing freshness path again.
+
 Machine acceptance covers only declared machine authority. Preserve every pending external confirmation through `final-gate`, `status`, `resume`, `stop-check`, the package-owned Stop Hook and `close`; accepted output identifies `acceptance_scope: declared_machine_authority` and `native_goal_effect: none`, while `closed_scope: machine_authority` means only Authority cleanup. Do not invent external-confirmation or native-Goal tracking state.
 
 Before invoking platform-native Goal completion, perform one veto-only conformance review: compare the current Goal and user instructions with accepted marked Source, and check for pending revisions, unresolved blockers or omitted requirements. Any mismatch keeps the Goal active and returns to Source/Contract repair. A clean review does not add acceptance proof and never lets Agent judgment replace Final Gate.
 
 ## Handoff
 
-Report implementation, effective risk, Claim Coverage, Stage frontier/results, declared target profile, exact `target_state`, Live Gate result, acceptance scope, every pending external confirmation, Context status and blockers. Use verifier terms exactly: `progress_passing` means targeted repair evidence, `progress_stale` is not a current pass, `final_workflow_status: null` means unfinished, `authority_revision_adopted` means return to rolling execution, and `machine_accepted_external_pending` must retain its named confirmations. Contract target states are only `implementation_complete`, `target_profile_usable` and `production_release_ready`; terminal failure uses `not_accepted` or `blocked_external`. Never shorten targeted progress to “Outcome complete” or invent per-platform progress/status. State the threat-model limits: undeclared requirements cannot be discovered, installed verifier/Git metadata are trusted, native-Goal/model selection belongs to the host/user, and internal platform delegation is not observed.
+Report implementation, effective risk, Architecture Deliberation/Conformance status, Claim Coverage, Stage frontier/results, declared target profile, exact `target_state`, Live Gate result, acceptance scope, every pending external confirmation, Context status and blockers. Use verifier terms exactly: `progress_passing` means targeted repair evidence, `progress_stale` is not a current pass, `final_workflow_status: null` means unfinished, `authority_revision_adopted` means return to rolling execution, and `machine_accepted_external_pending` must retain its named confirmations. Contract target states are only `implementation_complete`, `target_profile_usable` and `production_release_ready`; terminal failure uses `not_accepted` or `blocked_external`. Never shorten targeted progress to “Outcome complete” or invent per-platform progress/status. State the threat-model limits: the visible checkpoint cannot prove private reasoning or universal future-proofing, undeclared requirements cannot be discovered, installed verifier/Git metadata are trusted, native-Goal/model selection belongs to the host/user, and internal platform delegation is not observed.

package/assets/skills/long-task-workflow/references/authority-lifecycle.md

@@ -48,7 +48,7 @@ Report their exact meaning: `progress_passing` is current targeted repair eviden
 
 ## Final Gate And Terminal Paths
 
-Before Final Gate, complete Context/code/tests and create a clean candidate commit. Final Gate captures active identity, recompiles Source authority, reads complete current Context, validates common-dir record/marker, creates a Git-tree snapshot, reruns all Checks and sensitivity controls and rechecks identity before acceptance. A target-runtime Check must exercise its exact target again in that Final Gate execution; rereading historical status does not become live proof merely because the reader reran. The Receipt reports the target profile/state and every Stage as `passed`, `failed`, `blocked_external` or `blocked_dependency`. A concurrent revision returns `active_authority_changed_during_final_gate`.
+Before Final Gate, complete Context/code/tests and create a clean candidate commit. Final Gate captures active identity, recompiles Source authority, reads complete current Context, validates common-dir record/marker, creates a Git-tree snapshot, reruns all Checks and sensitivity controls and rechecks identity before acceptance. This is the sole Long-Task `Architecture Conformance` carrier: material deliberation conclusions must already be declared through existing obligations/constraints/forbidden shortcuts, owners/paths/Bindings and project-owned Checks, and no separate default Contract Conformance closure runs. A target-runtime Check must exercise its exact target again in that Final Gate execution; rereading historical status does not become live proof merely because the reader reran. The Receipt reports the target profile/state and every Stage as `passed`, `failed`, `blocked_external` or `blocked_dependency`. A concurrent revision returns `active_authority_changed_during_final_gate`.
 
 Commit, verifier migration, clear and abandon share one active-state lock. Stop/close clear only the identity actually accepted through CAS and preserve `machine_accepted_external_pending` plus every named external confirmation in output. Final Gate/Stop/close identify `acceptance_scope: declared_machine_authority` and `native_goal_effect: none`; close additionally identifies `closed_scope: machine_authority`. The Stop Hook emits the same scope as one non-blocking message for either accepted machine status. A stale Receipt exposes no accepted workflow status.
 

package/assets/skills/long-task-workflow/references/contract-authoring.md

@@ -40,11 +40,11 @@ Global non-goals, constraints and forbidden shortcuts remain Global authority an
 - `task.target_profile` declares `required_state` plus a non-empty, duplicate-free `required_target_refs`. Each ref resolves to a `product` execution target with one bounded runtime family and root entrypoint. Every Stage Gate and every `critical_user_path` Outcome provides root `target_runtime` proof for every required ref; optional support/observer targets never substitute.
 - Use `implementation_complete` only when code-level implementation is the selected target, `target_profile_usable` when the declared required targets must be usable, and `production_release_ready` only when release gates are part of the selected target. These are terminal target qualifications, not Outcome progress states.
 
-## Architecture Closure
+## Architecture Deliberation And Closure
 
-Architecture protection is risk-triggered and project-specific. Use it when the delivery declares module ownership, unique source of truth, dependency direction, API/schema/data boundary, state lifecycle, persistence/recovery, security boundary, compatibility/migration or a forbidden bypass.
+Architecture Deliberation occurs once for every implementation delivery before formal Compile and the first implementation edit; risk changes depth, not occurrence. Surface concise conclusions and repository evidence rather than private chain-of-thought. A preservation result still names the concrete owner/extension point and explains why durable boundaries and debt do not worsen. Material work covers module ownership, unique source of truth, dependency direction, API/schema/data boundary, state lifecycle, persistence/recovery, security boundary, compatibility/migration, selected and rejected alternatives, one plausible future-change challenge, touched technical debt and forbidden bypasses.
 
-Represent the invariant with existing Contract fields:
+Represent every material falsifiable invariant with existing Contract fields:
 
 1. a Source-backed technical obligation, global constraint or forbidden shortcut;
 2. owner Context and expected/support/forbidden paths;
@@ -52,7 +52,9 @@ Represent the invariant with existing Contract fields:
 4. a project-owned executable architecture check, such as the repository's lint, AST, dependency or contract test;
 5. a separate Assertion when functional behavior could pass while the architecture invariant fails.
 
-Do not encode subjective “clean architecture” or generic quality prose as machine authority. If no reliable observation can falsify it, keep it as durable Context/review judgment or return `decision_required`. Harness routes the repository's architecture check; it does not become a language-generic dependency analyzer.
+New or worsened debt is unacceptable unless a project-owned bounded exception identifies owner, rationale, tracking and removal/expiry condition. Unrelated legacy debt does not automatically expand delivery scope, but debt touched, relied on or worsened by the implementation cannot remain hidden. Material changes to scope, owner, Context, dependency direction, selected design or debt disposition refresh the deliberation and, after Authority Lock, use protected revision.
+
+Do not encode subjective “clean architecture” or generic quality prose as machine authority. If no reliable observation can falsify it, keep it as durable Context/review judgment or return `decision_required`. Harness routes the repository's architecture check; it does not become a language-generic dependency analyzer. Final Gate is the only Long-Task Architecture Conformance carrier and reruns these declared Checks on its current snapshot; do not add a default-workflow closure, architecture field, second Gate or state.
 
 ## Proxy And Target Runtime Independence
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "project-tiny-context-harness",
-  "version": "0.7.8",
+  "version": "0.7.9",
   "description": "Minimal project memory and validation harness for AI coding agents.",
   "license": "MIT",
   "author": "Seven128",