project-tiny-context-harness 0.8.5 → 0.8.7

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.7.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.
+
+### Sparse Context workspaces and monorepo repositories
+
+Monorepos may keep Context centralized while sparsely mirroring only implementation workspaces that own durable non-code facts under `project_context/workspaces/<workspace-id>/**`. Each represented Context workspace maps exactly one repository-relative code root through existing `[[areas]].root` and `context` and may contain several workspace-local Area/role owners. Package-manager workspaces with no durable Context need no empty directory; cross-workspace/repository/shared Areas stay under top-level `project_context/areas/**`. Package-manager/build files remain the complete code-workspace inventory. Single-workspace and non-monorepo projects keep the existing layout and validation path.
+
+Prefer a small top-level repository-common default Area in a monorepo; keep workspace-local Context `on-demand` unless it is genuinely near-universal. The default set plus manifest/search candidates is an expandable working set, not read isolation, a maximum or a requirement to read the entire target workspace. Read any additional Area/shared Context, root `DESIGN.md` or code needed for an indirect dependency. Root `DESIGN.md` remains the current shared project Design Authority; Context workspace placement does not create independent design systems.
+
+Resolve task-local intended workspace(s) from explicit user/product/path/repository facts. If materially different siblings remain ambiguous, ask one concise target question before product edits; intentional multi-workspace work enumerates every target and supporting/shared 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 `[[workspaces]]` schema, automatic topology scan, forced migration, full-graph default, persistent target state, registry, generic path/import/runtime scanner or duplicate Long-Task scope classifier.
+
+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.7.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.7.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -181,11 +181,30 @@ 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.
+
+### Sparse Context Workspaces And Monorepo Repositories
+
+Monorepos may keep Context centralized while mirroring only the implementation workspaces that actually own durable non-code facts:
+
+```text
+project_context/
+  areas/                              # cross-workspace/repository/shared owners
+  workspaces/
+    mobile/areas/...
+    wechat-miniapp/areas/...
+    api/areas/...
+```
+
+Each represented `project_context/workspaces/<workspace-id>/**` maps to exactly one repository-relative code root through existing `[[areas]].root` and `context`; it may contain several workspace-local Area/role owners. The mapping is sparse in the other direction: package-manager workspaces with no durable Context get no empty directory. Cross-workspace, repository-wide, shared and governance Areas stay under top-level `project_context/areas/**`. Package-manager/build files remain the complete code-workspace inventory. Single-workspace and non-monorepo projects keep the existing top-level Area layout, initialization and validation.
+
+For a monorepo, prefer a small top-level repository-common default Area; keep workspace-local Context `on-demand` unless it is genuinely near-universal. The core/default set, manifest candidates and bounded search remain an expandable starting set, not a read ACL, a maximum or an instruction to read an entire target workspace. Read any additional sibling Area, shared backend, cross-client contract, root `DESIGN.md`, selected resource or code needed to understand dependencies. Root `DESIGN.md` remains the current shared project Design Authority; Context workspace placement does not create independent design systems.
+
+Before product edits, resolve task-local intended workspace(s) from explicit user/product/path/repository facts. If materially different siblings remain plausible, ask one concise target question rather than choosing the default Area, recent client or a generic keyword match. Intentional multi-workspace work names every target and any supporting/shared scope. After implementation, run the repository's 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 `[[workspaces]]` schema, automatic package-manager topology scan, forced migration, persistent target state, generic import/path/runtime scanner or duplicate Long-Task scope classifier.
 
 Every engineering handoff reports one Context result:
 
@@ -197,18 +216,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 task-local intended workspace(s) without turning Context workspace or 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 +685,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.7.tgz` under the preview output directory.
 
 ## Community And Further Reading
 

package/assets/README.zh-CN.md

@@ -90,24 +90,44 @@ 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/浏览器或运行时证据/人工负责行为与产品验收。
+
+### 稀疏 Context Workspace 与 Monorepo
+
+Monorepo 可以让 Context 继续集中维护，同时只镜像确实拥有耐久非代码事实的实现 workspace：
+
+```text
+project_context/
+  areas/                              # 跨 workspace、仓库级、共享 owner
+  workspaces/
+    mobile/areas/...
+    wechat-miniapp/areas/...
+    api/areas/...
+```
+
+每个已表示的 `project_context/workspaces/<workspace-id>/**` 通过现有 `[[areas]].root` 与 `context` 精确对应一个仓库相对代码根，内部可以有多个 workspace-local Area/role owner。反向映射是稀疏的：没有耐久 Context 的 package-manager workspace 不创建空目录。真正跨 workspace、仓库级、共享或治理 Area 仍放在顶层 `project_context/areas/**`；完整代码 workspace 清单继续由 package-manager/build 配置拥有。单 workspace/非 monorepo 项目保持原有顶层 Area 布局、初始化和验证。
+
+Monorepo 应优先用一个小型顶层 Area 保存仓库公共的 default Context；workspace-local Context 默认 `on-demand`，除非它确实近乎所有任务都需要。core/default 集合、manifest 候选和 bounded search 仍只是可扩展的起始 working set，不是读取 ACL、最大集合，也不要求读完整个目标 workspace。任务需要时可以继续读取兄弟 Area、共享后端、跨客户端 contract、根 `DESIGN.md`、选定资源或代码。根 `DESIGN.md` 仍是当前共享项目 Design Authority；Context workspace 目录不会自动拆出多套设计系统。
+
+产品编辑前，用用户、产品、路径和仓库事实解析本任务 intended workspace(s)。只有仍无法区分多个实质不同的同级目标时，才问一个精确问题；不能默认选择 default Area、最近改过的客户端或通用关键词命中。跨 workspace 任务列全目标和 supporting/shared scope。实现后，如果仓库已有 changed-path / target-scope verifier，就用本任务准确变更路径调用；否则在 Conformance 中按 durable owner 检查最终 diff。Tiny Context 不新增 `[[workspaces]]` schema、自动 package-manager 拓扑扫描、强制迁移、持久 target 状态、通用 import/path/runtime scanner 或第二套 Long-Task scope classifier。
+
+普通任务：
+
+1. 读取 core/default Context，收集 manifest 候选；
+2. 在 `project_context/**` 做一次 bounded Context search，并在依赖需要时继续扩读；
+3. 多目标仓库先解析本任务 intended workspace(s)，但不把 Context workspace 或 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 monorepo or otherwise multi-target repository, separate the expandable read scope from the task-local intended workspace(s). An optional sparse `project_context/workspaces/<workspace-id>/**` directory maps each represented Context workspace to one code root through existing manifest `root/context`; workspace-local Areas own semantic responsibilities inside it, cross-workspace Areas stay top-level, and code workspaces without durable Context need no empty mirror. Keep the monorepo default Area small and repository-common; workspace-local Context stays `on-demand` unless genuinely near-universal. This structure/default/read policy is neither a read ACL nor edit authorization. Resolve intended workspaces from explicit user/product/path/repository facts; if materially different siblings remain ambiguous, ask one concise target question before product edits. Enumerate intentional multi-workspace targets and supporting/shared 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. Root `DESIGN.md` remains the current shared project Design Authority; Context workspace placement does not create independent design systems. 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 Context directory for every package-manager workspace, workspace/applicability schema, automatic topology scan, migration, 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 each represented `project_context/workspaces/<workspace-id>/**` to one code-root mapping, workspace-local Area responsibilities and cross-workspace/shared dependency direction. Do not list code workspaces that have no durable Context merely to complete a mirror, and do not turn the map into a read/edit ACL.
 
 ## Data / Control Flow
 

package/assets/context_templates/area.md

@@ -25,13 +25,14 @@
 
 - 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, a workspace-local Area belongs under `project_context/workspaces/<workspace-id>/areas/**`; its manifest entry maps that Context workspace to one code root. Name this Area's semantic responsibility within that root and any shared/supporting owners commonly needed. Cross-workspace Areas stay under top-level `project_context/areas/**`. This documents ownership and discovery, not read isolation or edit permission.
 
 ## Related Role Context
 
-- Verification paths live in this area's `verification` role Context, such as `project_context/areas/main/verification.md`.
+- Verification paths live in this area's `verification` role Context, such as `project_context/areas/main/verification.md` or `project_context/workspaces/mobile/areas/verification.md`.
 - Deployment/runtime/bootstrap paths live in this area's optional `deployment` role Context when those facts exist.
 
 ## Open Risks

package/assets/context_templates/context.toml

@@ -1,9 +1,20 @@
-# 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.
+# A monorepo may place only Context-bearing implementation workspaces under
+# project_context/workspaces/<workspace-id>/**. Each represented Context workspace
+# maps one code root through existing area root/context fields and may contain several Areas.
+# Keep cross-workspace Areas under project_context/areas/**; do not create empty
+# Context directories for code workspaces with no durable facts.
+# Prefer a small top-level repository-common default Area; keep workspace-local
+# Context on-demand unless its facts are genuinely near-universal.
+# 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.
+# This optional sparse mirror adds no workspace schema or read/edit ACL. Use
+# project-owned scope checks for task-local intended/supporting changed paths.
+# `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-workspace repository with a project-owned changed-path/target-scope verifier, record its stable command and inputs here. It validates intended workspace(s) plus allowed supporting changes 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. 在 monorepo 或其他多产品目标仓库中，把“为理解任务而读取什么”和“本任务 intended workspace(s)”分开。可选的 `project_context/workspaces/<workspace-id>/**` 只镜像确有耐久 Context 的实现 workspace；每个已表示 Context workspace 用现有 manifest `root/context` 精确对应一个代码根，内部 Area 负责语义 ownership，跨 workspace Area 留在顶层，未表示的代码 workspace 不建空目录。目录/default/read policy 既不是读取 ACL，也不是修改授权。用用户、产品、路径和仓库事实消歧；仍有多个实质不同的同级目标时，产品编辑前只问一个精确问题。跨 workspace 任务显式列全 intended 与 supporting/shared 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,18 @@ 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 对最终快照收口。
+
+## 稀疏 Context Workspace / Monorepo 修改边界
+
+- Context 的职责是把 UI/UX Authority、产品、后端、架构、安全、验证/部署等耐久事实存进正确的全局、共享或 Area owner，并让 Agent 低成本找回；它不能保证软约束下的 Agent 一定正确应用，行为仍由项目检查和 review 证明。
+- Context 继续集中在 `project_context/**`。Monorepo 可以只为确有耐久非代码事实的实现 workspace 建 `project_context/workspaces/<workspace-id>/**`；每个已表示 Context workspace 通过现有 `[[areas]].root/context` 精确映射一个仓库相对代码根，并可包含多个负责不同语义的 Area。完整 workspace 清单仍由 package-manager/build 配置拥有，没 Context 的 workspace 不建空目录。
+- 只属于一个实现 workspace 的 Area/role Context 放在该 Context workspace 内；真正跨 workspace、仓库级、共享、基础设施或治理 Area 继续放在顶层 `project_context/areas/**`。单 workspace/非 monorepo 保持原有顶层布局。不要新增 `[[workspaces]]`、`workspace` 字段、自动拓扑扫描或迁移。
+- Monorepo 的 default Area 通常只保留顶层、仓库公共的最小恢复事实；workspace-local Context 默认 `on-demand`，除非它确实近乎所有任务都需要。不能因为某个客户端被表示，就把它变成隐式全局默认。
+- 默认集合、manifest/trigger 候选和 bounded search 只是起始 working set，不是最大可读集合。开发 B 时可以按需读取 A/C、共享后端、`DESIGN.md` 或相关代码；不要把全量 Context 设成所有任务默认，也不要把 Context workspace 变成强制读取闭包。
+- “首页、页面、客户端、前端”等泛词只有在仓库中确实对应多个实质不同的同级 workspace、且用户/产品/路径/owner 事实仍不能消歧时才阻塞。不能仅凭 default Area、最近修改、最近读取或通用关键词选择客户端。已明确的单目标直接继续；跨端任务列全 intended workspace，并明确 supporting/shared scope。
+- 最终 scope check 区分 intended workspaces、allowed supporting changes、forbidden sibling targets 与实际 task-attributable paths。优先复用 verification Context 指向的项目原生 verifier；没有时在最终 diff/owner Conformance 中检查，且不归因无 provenance 的既有脏改动。Tiny Context 不创建通用 workspace mapper、import/path/runtime scanner、持久 target declaration、Registry 或第二 Authority。
+- 根 `DESIGN.md` 仍是当前共享项目 Design Authority；Context workspace 目录不会自动拆出多套设计系统。单 Area/非 monorepo 不增加 schema、迁移、状态或行为成本。显式 Long-Task 继续由既有 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,17 @@ 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.",
+        "# A monorepo may place only Context-bearing implementation workspaces under",
+        "# project_context/workspaces/<workspace-id>/**. Each represented Context workspace",
+        "# maps one code root through existing area root/context fields and may contain several Areas.",
+        "# Keep cross-workspace Areas under project_context/areas/**; do not create empty",
+        "# Context directories for code workspaces with no durable facts.",
+        "# Prefer a small top-level repository-common default Area; keep workspace-local",
+        "# Context on-demand unless its facts are genuinely near-universal.",
+        "# Default/on-demand selection defines the starting read set, not a maximum;",
+        "# widen to any relevant area/shared Context when task dependencies require it.",
+        "# This optional sparse mirror adds no workspace schema or read/edit ACL. Use",
+        "# project-owned scope checks for task-local intended/supporting changed paths.",
         "# 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.7",
   "description": "Minimal project memory and validation harness for AI coding agents.",
   "license": "MIT",
   "author": "Seven128",