project-tiny-context-harness 0.8.5 → 0.8.6

package/README.md

@@ -158,7 +158,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.8.5.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.8.6.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -179,19 +179,28 @@ 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 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. 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, 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.
+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.
+
+### Multi-Area and monorepo repositories
+
+Area is a durable product/technical owner and discovery entry; workspace/package/root is a code, build and dependency unit. They need not map one-to-one: one Area may own several workspaces, and shared/infrastructure/governance Areas may own none. When the mapping matters, give each code/workspace root one primary Area owner and record it in Area `Code Entry Points`, architecture Context or a project-owned resolver. Existing manifest fields remain sufficient.
+
+The default set plus manifest/search candidates is an expandable working set, not read isolation or a maximum. Read any additional Area/shared Context or code needed for an indirect dependency, but keep read scope separate from the intended product change target. If user language and durable repository ownership still leave materially different sibling product targets ambiguous, ask one concise target question before product edits. Explicitly enumerate intentional cross-Area targets; shared/backend reads do not silently expand edit scope.
+
+After implementation, use a repository-owned changed-path/target-scope verifier on exact task-attributable paths when available, or review the final diff against durable owners during Conformance. Tiny Context adds no required workspace/applicability schema, full-graph default, persistent target state, registry, generic path/import/runtime scanner or duplicate Long-Task scope classifier. Single-Area projects keep the same initialization and validation path; an already unambiguous single-target task adds no clarification.
+
+Ordinary tasks:
+
+1. resolve minimum relevant Context through manifest routing plus bounded Context search;
+2. widen the Context working set when shared or indirect dependencies require it, and disambiguate a genuinely unclear sibling product target before product edits;
+3. surface one concise, repository-bound Architecture Deliberation;
+4. decide `Context Delta: none|required` and update durable facts before code when required;
+5. use the platform's internal plan;
+6. implement and run project-owned verification, including an available changed-path/target-scope check;
+7. perform Contract Conformance, including Architecture Conformance and final change-scope review on the current candidate;
+8. perform the separate Context drift check and hand off.
+
+The default workflow has no required plan artifact, target declaration, matrix, verdict, evidence ledger, persistent retrieval index or second plan. Duration, file count and complexity never auto-enable long-task state.
 
 Plan Validator commands no longer exist; existing plan, matrix or verdict files remain ordinary user files.
 
@@ -409,7 +418,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.8.5.tgz`.
+The synchronized local preview tarball is named `project-tiny-context-harness-0.8.6.tgz`.
 
 ## Community And Further Reading
 

package/assets/README.md

@@ -154,7 +154,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.8.5.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.8.6.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -181,11 +181,19 @@ project_context/context.toml
 minimum graph-relevant area/role Context
 ```
 
-Only near-universal recovery facts should use `read_policy = "default"`; specialized architecture, contract, deployment and historical detail should be task-triggered `on-demand` Context. Before deciding `Context Delta`, the Agent also runs 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 language. Matching files are merged with manifest candidates and filtered by semantic relevance. This is not a vector or persistent retrieval system and creates no index, cache, registry, search state or authority.
-
-`ty-context doctor` reports the deterministic default read footprint, per-file/total soft-budget overages, byte-identical default files and `DESIGN.md` authority status. These are advisory maintenance signals, not a new validation gate or workflow state. If genuine near-universal recovery facts exceed a byte heuristic, preserve the facts and accept the warning; never omit, obscure or misclassify required Context merely to fit the budget.
-
-Typical roles are area/domain, contract, foundation, decision-rationale, implementation-index, verification and deployment. Context owns durable intended boundaries; code owns current implementation; tests, CI, browser/runtime evidence and people own behavior and product acceptance.
+Only near-universal recovery facts should use `read_policy = "default"`; specialized architecture, contract, deployment and historical detail should be task-triggered `on-demand` Context. Before deciding `Context Delta`, the Agent also runs 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 language. Matching files are merged with manifest candidates and filtered by semantic relevance. This is not a vector or persistent retrieval system and creates no index, cache, registry, search state or authority.
+
+`ty-context doctor` reports the deterministic default read footprint, per-file/total soft-budget overages, byte-identical default files and `DESIGN.md` authority status. These are advisory maintenance signals, not a new validation gate or workflow state. If genuine near-universal recovery facts exceed a byte heuristic, preserve the facts and accept the warning; never omit, obscure or misclassify required Context merely to fit the budget.
+
+Typical roles are area/domain, contract, foundation, decision-rationale, implementation-index, verification and deployment. Context owns durable intended boundaries; code owns current implementation; tests, CI, browser/runtime evidence and people own behavior and product acceptance.
+
+### Multi-Area And Monorepo Repositories
+
+Area and workspace are related but different. An Area owns durable product or technical meaning and helps discovery; a workspace/package/root is a code, build and dependency unit. One Area may own several workspaces, and a shared/infrastructure/governance Area may own none. When the mapping matters, give each code/workspace root one primary Area owner and record it in Area `Code Entry Points`, architecture Context or a project-owned resolver—no extra manifest field or one-Area-per-workspace migration is required.
+
+The core/default set, manifest candidates and bounded search are the starting working set, not a read ACL or maximum. Read any additional Area, shared backend, cross-client contract, `DESIGN.md`, selected resource or code needed to understand the task. Do not make the complete Context graph the ordinary default, and do not treat reading a sibling Area as permission to edit it.
+
+Before product edits, separate read scope from change target. If explicit user language and durable repository ownership still leave several materially different sibling product targets plausible, ask one concise target question rather than choosing the default Area, recent client or a generic keyword match. Intentional cross-Area work names every target; shared/supporting reads remain separate. After implementation, run the repository's own changed-path/target-scope verifier on exact task-attributable paths when available, or review the final diff against durable owners during Conformance. Tiny Context adds no persistent target declaration, workspace registry, applicability matrix, generic import/path/runtime scanner or duplicate Long-Task scope classifier. Single-Area projects keep the same schema and state model; an already unambiguous single-target task adds no clarification.
 
 Every engineering handoff reports one Context result:
 
@@ -197,18 +205,19 @@ Context: no durable fact change
 
 ## Default Workflow Contract
 
-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. 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, 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.
+Ordinary tasks stay lightweight:
+
+1. read core/default Context and collect manifest candidates;
+2. run one bounded Context search over `project_context/**`, read relevant matches and widen when dependencies require more Context;
+3. in a multi-target repository, resolve the intended change target without turning Area selection into read/edit permission;
+4. surface one concise, repository-bound Architecture Deliberation;
+5. decide `Context Delta: none|required` and update the owning Context first when durable semantics change;
+6. use the platform's internal plan;
+7. implement and run project-owned verification, including an available changed-path/target-scope check on task-attributable paths;
+8. perform Contract Conformance, including Architecture Conformance on the current candidate and final change-scope review;
+9. perform the separate Context drift check and hand off.
+
+The default workflow creates no required `plan.md`, target declaration, matrix, verdict, evidence ledger, persistent Context-search index or second execution plan. Task length, file count and complexity never auto-enable long-task state.
 
 Plan Validator commands no longer exist; existing plan, matrix or verdict files remain ordinary user files.
 
@@ -665,7 +674,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.8.5.tgz` under the preview output directory.
+`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.8.6.tgz` under the preview output directory.
 
 ## Community And Further Reading
 

package/assets/README.zh-CN.md

@@ -90,24 +90,33 @@ manifest/trigger 命中的少量 area/role Context
 3. 合并两路候选，只读取真正相关的 Context；
 4. 再判断 `Context Delta: none|required`。
 
-这次搜索只补充语义判断，不会把所有关键词命中都当成 Authority，也不会创建向量/持久索引、缓存、Registry、search state 或第二权威。它仍可能漏掉完全不同的同义词或间接依赖，因此每个实现需求仍要执行 Architecture Deliberation 与收尾 Conformance。
-
-`ty-context doctor` 会报告确定性的默认 Context 文件/字节规模、单文件与总量软预算超限、字节完全相同的默认文件，以及 `DESIGN.md` 权威状态。这些只是维护提示，不是新验证 Gate 或运行时状态。如果真实的近乎通用恢复事实超过字节启发式预算，应保留事实并接受 warning；绝不能为了满足预算而遗漏、过度压缩或错误分类必需 Context。
-
-Context 负责耐久的意图和边界，代码负责当前实现，测试/CI/浏览器或运行时证据/人工负责行为与产品验收。
-
-普通任务：
-
-1. 读取 core/default Context，收集 manifest 候选；
-2. 在 `project_context/**` 做一次 bounded Context search；
-3. 对用户可见地给出一次简洁、仓库事实绑定的 Architecture Deliberation；
-4. 决定 `Context Delta: none|required`，耐久语义改变时先更新 owner Context；
-5. 使用平台内部计划；
-6. 实现并运行项目验证；
-7. 执行 Contract Conformance，其中包含对当前候选快照的 Architecture Conformance；
-8. 单独执行 Context drift check 后交付。
-
-默认工作流不要求 `plan.md`、matrix、verdict、evidence ledger、持久检索索引或第二份执行计划。任务时长、文件数和复杂度不会自动激活长程状态。
+这次搜索只补充语义判断，不会把所有关键词命中都当成 Authority，也不会创建向量/持久索引、缓存、Registry、search state 或第二权威。它仍可能漏掉完全不同的同义词或间接依赖，因此每个实现需求仍要执行 Architecture Deliberation 与收尾 Conformance。
+
+`ty-context doctor` 会报告确定性的默认 Context 文件/字节规模、单文件与总量软预算超限、字节完全相同的默认文件，以及 `DESIGN.md` 权威状态。这些只是维护提示，不是新验证 Gate 或运行时状态。如果真实的近乎通用恢复事实超过字节启发式预算，应保留事实并接受 warning；绝不能为了满足预算而遗漏、过度压缩或错误分类必需 Context。
+
+Context 负责耐久的意图和边界，代码负责当前实现，测试/CI/浏览器或运行时证据/人工负责行为与产品验收。
+
+### Multi-Area 与 Monorepo
+
+Area 与 workspace 有关联，但不是同一种单元。Area 负责耐久的产品/技术语义、ownership 和发现；workspace/package/root 是代码、构建与依赖单元。一个 Area 可以拥有多个 workspace，共享、基础设施或仓库治理 Area 也可以不直接拥有 workspace。映射有长期价值时，每个代码/workspace root 只指定一个 primary Area owner，并写进 Area `Code Entry Points`、architecture Context 或项目自己的 resolver；不需要新增 manifest 字段，也不要求一个 workspace 对应一个 Area。
+
+core/default 集合、manifest 候选和 bounded search 是起始 working set，不是读取 ACL 或最大可读集合。任务需要时可以继续读取其他 Area、共享后端、跨客户端 contract、`DESIGN.md`、选定资源或代码。不要把全量 Context 设成普通任务的全局默认，也不要把“读到兄弟 Area”解释为“获得修改它的权限”。
+
+产品编辑前应把 read scope 与 change target 分开。只有当用户明确表达和仓库耐久 ownership 仍无法区分多个实质不同的同级产品目标时，才问一个精确的目标问题；不能默认选择 default Area、最近改过的客户端或通用关键词命中。跨 Area 任务列全目标，共享/supporting 读取保持独立。实现后，如果仓库已有 changed-path / target-scope verifier，就用本任务准确变更路径调用；否则在 Conformance 中按 durable owner 检查最终 diff。Tiny Context 不增加持久 target declaration、workspace Registry、applicability matrix、通用 import/path/runtime scanner 或第二套 Long-Task scope classifier。单 Area 项目没有新增 schema 或状态；已经明确的单目标任务没有新增询问。
+
+普通任务：
+
+1. 读取 core/default Context，收集 manifest 候选；
+2. 在 `project_context/**` 做一次 bounded Context search，并在依赖需要时继续扩读；
+3. 多目标仓库先消歧 change target，但不把 Area 变成读取/修改权限；
+4. 对用户可见地给出一次简洁、仓库事实绑定的 Architecture Deliberation；
+5. 决定 `Context Delta: none|required`，耐久语义改变时先更新 owner Context；
+6. 使用平台内部计划；
+7. 实现并运行项目验证，包括仓库已有的 changed-path / target-scope check；
+8. 执行 Contract Conformance，其中包含当前候选快照的 Architecture Conformance 和最终 change-scope 审查；
+9. 单独执行 Context drift check 后交付。
+
+默认工作流不要求 `plan.md`、target declaration、matrix、verdict、evidence ledger、持久检索索引或第二份执行计划。任务时长、文件数和复杂度不会自动激活长程状态。
 
 每次交接只报告一个 Context 结果：
 

package/assets/agents/AGENTS_CORE.md

@@ -13,14 +13,15 @@ After implementation and project verification, perform one current-candidate `Ar
 Unless a valid Long-Task binding is active, this prompt-level protocol applies automatically. It guides Agent execution but creates no validator result, Receipt, persisted phase state or machine-completion authority.
 
 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 high-signal set: explicit area/module names plus relevant API/schema/state/security/verification/deployment terms. Merge matches with manifest candidates and read only relevant Context; search supplements rather than replaces semantic judgment.
-3. For every material non-UI product or technical change, complete the task-local semantic obligation below before implementation: inventory all material inputs, atomize every applicable semantic Fact and condition, extend the standard catalog for domain-specific meaning, and bind every Fact to an owner and attributable proof. Missing authority stays decision-required rather than becoming an implementation default.
-4. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes. For material UI, reconcile affected stable surface/control/target keys as Context-covered, requiring a Context update, task-local, out of scope or decision-required; traverse owning Context and `DESIGN.md`; and open every affected selected `exact-target` or `constraint`. Missing, stale, unreadable or conflicting authority fails closed for the affected claim. Local fixes and explicit non-fidelity prototypes stay lightweight.
-5. Complete `Architecture Deliberation`, then decide exactly one `Context Delta: none|required`. Update owning Context before code for durable product ownership, architecture, API/schema/data, state/recovery, dependency, security, product-surface responsibility or repeatable verification/deployment change. Local fixes preserving durable semantics are `none`.
-6. 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 questions, not artifacts or extra deltas.
-7. Implement precisely, run project-owned verification, perform Contract Conformance including `Architecture Conformance`, the non-UI semantic closure and any selected-design closure below, then run the separate Context drift check. Report implementation, verification, architecture conformance, Context status and blockers. For material UI, use the first useful independently runnable production slice as a recommended real-entry feedback point when its expected early-localization value exceeds the run cost; it is not a prerequisite for expanding implementation. Always rerun the affected cold-start journey on the final candidate. Detached routes, specimens and deep links remain supplemental.
-
-The default workflow never requires a plan artifact, matrix, verdict, evidence ledger or result document. Optional scratch is not Context or proof. Bounded Context search creates no index, cache, state or second authority.
+2. Before deciding `Context Delta`, run one bounded text search over `project_context/**` using a small high-signal set: explicit area/module names plus relevant API/schema/state/security/verification/deployment terms. Merge matches with manifest candidates, read relevant Context and widen whenever another Area/shared dependency becomes relevant; search supplements rather than replaces semantic judgment.
+3. In a multi-Area or otherwise multi-target repository, separate the expandable read scope from the intended change target. Area/default/read-policy selection is neither a read ACL nor edit authorization, and Areas need not map one-to-one to workspaces. If user language plus durable repository ownership still leaves materially different sibling product targets ambiguous, ask one concise target question before product edits; enumerate every intentional cross-Area target and keep shared/backend/supporting reads distinct from edit scope.
+4. For every material non-UI product or technical change, complete the task-local semantic obligation below before implementation: inventory all material inputs, atomize every applicable semantic Fact and condition, extend the standard catalog for domain-specific meaning, and bind every Fact to an owner and attributable proof. Missing authority stays decision-required rather than becoming an implementation default.
+5. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes. For material UI, reconcile affected stable surface/control/target keys as Context-covered, requiring a Context update, task-local, out of scope or decision-required; traverse owning Context and `DESIGN.md`; and open every affected selected `exact-target` or `constraint`. Missing, stale, unreadable or conflicting authority fails closed for the affected claim. Local fixes and explicit non-fidelity prototypes stay lightweight.
+6. Complete `Architecture Deliberation`, then decide exactly one `Context Delta: none|required`. Update owning Context before code for durable product ownership, architecture, API/schema/data, state/recovery, dependency, security, product-surface responsibility or repeatable verification/deployment change. Local fixes preserving durable semantics are `none`.
+7. 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 questions, not artifacts or extra deltas.
+8. Implement precisely and run project-owned verification. When the repository exposes a changed-path/target-scope check, run it against the intended/supporting targets and exact task-attributable paths; otherwise review the final diff against durable owners during Conformance. Do not attribute unrelated pre-existing dirty paths to the task without provenance. Perform Contract Conformance including `Architecture Conformance`, the non-UI semantic closure and any selected-design closure below, then run the separate Context drift check. Report implementation, verification, architecture conformance, Context status and blockers. For material UI, use the first useful independently runnable production slice as a recommended real-entry feedback point when its expected early-localization value exceeds the run cost; it is not a prerequisite for expanding implementation. Always rerun the affected cold-start journey on the final candidate. Detached routes, specimens and deep links remain supplemental.
+
+The default workflow never requires a plan artifact, target declaration, matrix, verdict, evidence ledger or result document. Optional scratch is not Context or proof. Bounded Context search creates no index, cache, state or second authority; it also creates no read isolation. Do not make the full Context graph the ordinary default or add a required workspace/applicability schema, target registry, generic path/import/runtime scanner or duplicate Long-Task scope classifier.
 
 ## Shared Non-UI Semantic Completeness Obligation
 

package/assets/context_templates/architecture.md

@@ -6,9 +6,10 @@ This is the restrained architecture context. Keep only facts that help a fresh a
 
 - Describe what is inside this project and what external systems, providers or runtime assumptions sit outside it.
 
-## Component Map
-
-- List the smallest useful set of components, areas or context units and how they relate.
+## Component Map
+
+- List the smallest useful set of components, areas or context units and how they relate.
+- In a monorepo, record durable Area-to-code/workspace ownership and shared dependency direction where it helps recovery. Do not assume one Area per workspace or turn the map into a read/edit ACL.
 
 ## Data / Control Flow
 

package/assets/context_templates/area.md

@@ -25,9 +25,10 @@
 
 - List constraints that are not obvious from code alone, including product rules, responsive/a11y needs or visual boundaries.
 
-## Code Entry Points
-
-- `src/` or the concrete file/function entry points.
+## Code Entry Points
+
+- `src/` or the concrete file/function entry points.
+- In a monorepo, name the code/workspace roots this Area primarily owns and any shared/supporting roots future work commonly needs. Give each root one primary Area owner when the mapping is material; one Area may own several workspaces. This documents ownership and discovery, not read isolation or edit permission.
 
 ## Related Role Context
 

package/assets/context_templates/context.toml

@@ -1,9 +1,15 @@
-# Schema v4 Minimal Context graph manifest.
-# Keep the default product/domain area for ordinary projects. Role context nodes
-# are read-purpose slices owned by an area or, only when cross-domain, by the project root.
-# Use read_policy = "default" only for near-universal recovery facts; prefer
-# "on-demand" for specialized architecture, contract, deployment or history detail.
-# `ty-context doctor` reports the deterministic default read footprint and exact duplicates.
+# Schema v4 Minimal Context graph manifest.
+# Keep the default product/domain area for ordinary projects. Role context nodes
+# are read-purpose slices owned by an area or, only when cross-domain, by the project root.
+# An area is a durable ownership/discovery unit, not a read/edit ACL or a required
+# one-to-one workspace mapping. One area may own several code/workspace roots.
+# Use read_policy = "default" only for near-universal recovery facts; prefer
+# "on-demand" for specialized architecture, contract, deployment or history detail.
+# Default/on-demand selection defines the starting read set, not a maximum:
+# widen to any relevant area/shared Context when task dependencies require it.
+# Monorepos need no additional manifest fields; record useful code/workspace
+# ownership in area or architecture Context and use project-owned scope checks.
+# `ty-context doctor` reports the deterministic default read footprint and exact duplicates.
 # When migrating deep files under project_context/areas/**, refine obvious
 # contract/foundation/subdomain/verification/deployment/implementation-index/
 # decision-rationale/archive files into [[context]] entries instead of keeping

package/assets/context_templates/verification.md

@@ -8,8 +8,9 @@ This role Context records critical repeat-execution paths for the owning area. K
 
 ## Verification Paths
 
-- `npm test` or the shortest project-specific test, smoke, CI, probe or validation command.
-- Verification paths are reusable execution instances, not independent definitions of the verification target. For capability, metric or acceptance claims, first use the owning module's design Context to decide what claim should be proven, then choose the command or probe.
+- `npm test` or the shortest project-specific test, smoke, CI, probe or validation command.
+- Verification paths are reusable execution instances, not independent definitions of the verification target. For capability, metric or acceptance claims, first use the owning module's design Context to decide what claim should be proven, then choose the command or probe.
+- For a multi-Area repository with a project-owned changed-path/target-scope verifier, record its stable command and inputs here. It validates intended/supporting change scope for task-attributable paths; it does not restrict which Context or code may be read.
 
 ## Required Preparation
 

package/assets/skills/context_development_engineer/SKILL.md

@@ -17,14 +17,15 @@ When an active `long-task-workflow` binding exists, that Skill owns lifecycle, t
 
 ## 默认工作方式
 
-1. 读取 `project_context/global.md`、`project_context/architecture.md`、`project_context/context.toml`、default area root，并按 triggers/read policy 收集相关 on-demand Context 候选。
-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. 第一处实现编辑前，完成并对用户可见地给出一次简洁、仓库事实绑定的 `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。
+1. 读取 `project_context/global.md`、`project_context/architecture.md`、`project_context/context.toml`、default area root，并按 triggers/read policy 收集相关 on-demand Context 候选。
+2. 在判断 `Context Delta` 前，用任务中明确的 area/module/API/Schema/state/security/verification/deployment 等少量高信号词，对 `project_context/**` 做一次 bounded text search；把命中的 Context 与 manifest 候选合并，读取真正相关文件，并在代码或语义依赖暴露其他 owner 时继续扩读。搜索只补充语义判断，不创建索引、缓存或第二权威，也不创建读取隔离。
+3. 在 multi-Area、monorepo 或其他多产品目标仓库中，把“为理解任务而读取什么”和“用户要修改哪个产品目标”分开。Area/default/read policy 既不是读取 ACL，也不是修改授权；Area 与 workspace 不要求一一对应。若用户表达和耐久 ownership 仍无法区分多个实质不同的同级产品目标，在产品编辑前只问一个精确的目标问题；跨 Area 任务显式列全目标，共享/后端读取只进入 supporting scope。
+4. 确认目标、约束、成功标准、影响域、验证/部署路径和风险。能从代码或 Context 得到的事实不要重复询问。
+5. Context 决定“应该是什么”；代码说明“现在是什么”；测试和运行证据证明行为。冲突是实现漂移、缺失工作或 stale Context，不能由代码静默重定义归属。
+6. 第一处实现编辑前，完成并对用户可见地给出一次简洁、仓库事实绑定的 `Architecture Deliberation`。不输出私有思维链；输出结论及其 Context、模块/路径、symbol/extension point 和验证依据。风险只改变深度，不取消这个环节。
+7. 根据架构考量决定唯一 `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 映射表。
+8. 用 Agent 内部计划保持 goal、non-goals、owner、boundaries、implementation surfaces、risk 和 verification 清晰。默认流程不要求或验证固定 `plan.md`、matrix、verdict 或 evidence ledger。
+9. 实现后先运行 project-owned verification。仓库已有 changed-path / target-scope checker 时，以本任务准确变更路径和 intended/supporting targets 调用；没有时在 Conformance 中按 durable owner 审查最终 diff，不能把无 provenance 的既有脏改动算进本任务。再在 `Contract Conformance` 中对当前候选快照执行 `Architecture Conformance`，随后单独做 Context drift check；报告实现、验证、架构符合性、Context 状态和 blockers。
 
 ## 必经 Architecture Deliberation
 
@@ -67,7 +68,16 @@ When an active `long-task-workflow` binding exists, that Skill owns lifecycle, t
 
 发现问题就返回实现并重跑受影响验证；候选代码或配置再变化，先前 closure 失效。新增或加重技术债默认阻塞交付，除非项目已有显式、收窄、带 owner/reason/tracking/removal condition 的例外。无关 legacy debt 不自动扩张任务范围，但本次触达、依赖或加重的债不能隐藏。
 
-active Long-Task 下不再执行这个默认 closure；同一架构义务由 Contract 中现有 obligations/constraints/forbidden shortcuts、owners/paths/Bindings 和 executable Checks 表达，并只由 Final Gate 对最终快照收口。
+active Long-Task 下不再执行这个默认 closure；同一架构义务由 Contract 中现有 obligations/constraints/forbidden shortcuts、owners/paths/Bindings 和 executable Checks 表达，并只由 Final Gate 对最终快照收口。
+
+## Multi-Area / Monorepo Context 与修改边界
+
+- Context 的职责是把 UI/UX Authority、产品、后端、架构、安全、验证/部署等耐久事实存进正确的全局、共享或 Area owner，并让 Agent 低成本找回；它不能保证软约束下的 Agent 一定正确应用，行为仍由项目检查和 review 证明。
+- Workspace/package/repository root 是代码、构建和依赖单元；Area 是产品/技术责任和 Context owner。一个 Area 可以拥有多个 workspace，共享/基础设施/治理 Area 可以没有独立 workspace。ownership 有长期价值时，每个代码/workspace root 只指定一个 primary Area owner，并把映射写进 Area `Code Entry Points`、architecture Context 或项目自己的 ownership resolver；不要机械地为每个 workspace 新建 Area。
+- 默认集合、manifest/trigger 候选和 bounded search 只是起始 working set，不是最大可读集合。开发 B 时可以读取 A/C 或共享后端；只有它们变成用户意图中的修改目标时才进入 target scope。不要把全量 Context 设成所有任务默认，也不要做强制读取闭包。
+- “首页、页面、客户端、前端”等泛词只有在仓库中确实对应多个实质不同的同级产品目标、且用户/路径/owner 事实仍不能消歧时才阻塞。不能仅凭 default Area、最近修改、最近读取或通用关键词选择客户端。已明确的单目标直接继续；跨端目标全部列明。
+- 最终 scope check 区分 intended product targets、allowed supporting changes、forbidden sibling targets 与实际 task-attributable paths。优先复用 verification Context 指向的项目原生 verifier；它可以理解项目自己的 ownership/applicability。Tiny Context 不创建通用 npm/Nx/Bazel/Cargo/Maven workspace mapper、import/path/runtime scanner、持久 target declaration、applicability matrix、Registry 或第二 Authority。
+- 单 Area/非 monorepo 不增加 schema、迁移或状态；只有仓库实际暴露多个仍然歧义的产品目标时才需要询问。显式 Long-Task 继续由既有 expected/supporting/forbidden/unclassified classifier、Authority Revision、`scope_escape` 和 Final Gate 负责，不再运行一套默认 classifier。
 
 ## Capability-First Delivery Boundary
 

package/dist/lib/context-default-footprint.js

@@ -44,6 +44,8 @@ export async function inspectDefaultContextFootprint(projectRootInput) {
             .sort(([left], [right]) => left.localeCompare(right)),
     };
 }
+// This is the advisory startup set only. It does not restrict later reads or
+// turn default Area/read-policy selection into a Context or edit permission.
 export function selectDefaultContextPaths(manifest) {
     const selected = new Map();
     const add = (value, reason) => {

package/dist/lib/context-manifest.js

@@ -6,6 +6,12 @@ export function defaultContextManifestTemplate() {
         "# Schema v4 Minimal Context graph manifest.",
         "# Keep the default product/domain area for ordinary projects. Role context nodes",
         "# are read-purpose slices owned by an area or, only when cross-domain, by the project root.",
+        "# An area is a durable ownership/discovery unit, not a read/edit ACL or a required",
+        "# one-to-one workspace mapping. One area may own several code/workspace roots.",
+        "# Default/on-demand selection defines the starting read set, not a maximum;",
+        "# widen to any relevant area/shared Context when task dependencies require it.",
+        "# Monorepos need no additional manifest fields; record useful code/workspace",
+        "# ownership in area or architecture Context and use project-owned scope checks.",
         "# When migrating deep files under project_context/areas/**, refine obvious",
         "# contract/foundation/subdomain/verification/deployment/implementation-index/",
         "# decision-rationale/archive files into [[context]] entries instead of keeping",

package/package.json

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