project-tiny-context-harness 0.8.6 → 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.6.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,13 +181,13 @@ Before deciding `Context Delta`, the Agent combines two low-state routes:
 
 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
+### Sparse Context workspaces 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.
+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.
 
-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.
+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.
 
-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.
+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:
 
@@ -418,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.6.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.6.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
 ```
@@ -187,13 +187,24 @@ Only near-universal recovery facts should use `read_policy = "default"`; special
 
 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
+### Sparse Context Workspaces 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.
+Monorepos may keep Context centralized while mirroring only the implementation workspaces that actually own durable non-code facts:
 
-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.
+```text
+project_context/
+  areas/                              # cross-workspace/repository/shared owners
+  workspaces/
+    mobile/areas/...
+    wechat-miniapp/areas/...
+    api/areas/...
+```
 
-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.
+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:
 
@@ -209,7 +220,7 @@ 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;
+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;
@@ -674,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.6.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

@@ -96,19 +96,30 @@ manifest/trigger 命中的少量 area/role Context
 
 Context 负责耐久的意图和边界，代码负责当前实现，测试/CI/浏览器或运行时证据/人工负责行为与产品验收。
 
-### Multi-Area 与 Monorepo
+### 稀疏 Context Workspace 与 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。
+Monorepo 可以让 Context 继续集中维护，同时只镜像确实拥有耐久非代码事实的实现 workspace：
 
-core/default 集合、manifest 候选和 bounded search 是起始 working set，不是读取 ACL 或最大可读集合。任务需要时可以继续读取其他 Area、共享后端、跨客户端 contract、`DESIGN.md`、选定资源或代码。不要把全量 Context 设成普通任务的全局默认，也不要把“读到兄弟 Area”解释为“获得修改它的权限”。
+```text
+project_context/
+  areas/                              # 跨 workspace、仓库级、共享 owner
+  workspaces/
+    mobile/areas/...
+    wechat-miniapp/areas/...
+    api/areas/...
+```
 
-产品编辑前应把 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 或状态；已经明确的单目标任务没有新增询问。
+每个已表示的 `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. 多目标仓库先消歧 change target，但不把 Area 变成读取/修改权限；
+3. 多目标仓库先解析本任务 intended workspace(s)，但不把 Context workspace 或 Area 变成读取/修改权限；
 4. 对用户可见地给出一次简洁、仓库事实绑定的 Architecture Deliberation；
 5. 决定 `Context Delta: none|required`，耐久语义改变时先更新 owner Context；
 6. 使用平台内部计划；

package/assets/agents/AGENTS_CORE.md

@@ -14,14 +14,14 @@ Unless a valid Long-Task binding is active, this prompt-level protocol applies a
 
 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, 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.
+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. 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. 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 workspace/applicability schema, target registry, generic path/import/runtime scanner or duplicate Long-Task scope classifier.
+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

@@ -9,7 +9,7 @@ This is the restrained architecture context. Keep only facts that help a fresh a
 ## 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.
+- 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

@@ -28,11 +28,11 @@
 ## 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.
+- 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,14 +1,19 @@
 # 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.
+# 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.
-# Monorepos need no additional manifest fields; record useful code/workspace
-# ownership in area or architecture Context and use project-owned scope checks.
+# 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/

package/assets/context_templates/verification.md

@@ -10,7 +10,7 @@ This role Context records critical repeat-execution paths for the owning area. K
 
 - `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.
+- 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

@@ -19,7 +19,7 @@ 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 候选合并，读取真正相关文件，并在代码或语义依赖暴露其他 owner 时继续扩读。搜索只补充语义判断，不创建索引、缓存或第二权威，也不创建读取隔离。
-3. 在 multi-Area、monorepo 或其他多产品目标仓库中，把“为理解任务而读取什么”和“用户要修改哪个产品目标”分开。Area/default/read policy 既不是读取 ACL，也不是修改授权；Area 与 workspace 不要求一一对应。若用户表达和耐久 ownership 仍无法区分多个实质不同的同级产品目标，在产品编辑前只问一个精确的目标问题；跨 Area 任务显式列全目标，共享/后端读取只进入 supporting scope。
+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 和验证依据。风险只改变深度，不取消这个环节。
@@ -70,14 +70,16 @@ When an active `long-task-workflow` binding exists, that Skill owns lifecycle, t
 
 active Long-Task 下不再执行这个默认 closure；同一架构义务由 Contract 中现有 obligations/constraints/forbidden shortcuts、owners/paths/Bindings 和 executable Checks 表达，并只由 Final Gate 对最终快照收口。
 
-## Multi-Area / Monorepo Context 与修改边界
+## 稀疏 Context Workspace / Monorepo 修改边界
 
 - 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。
+- 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-manifest.js

@@ -6,12 +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.",
-        "# 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.",
+        "# 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.",
-        "# Monorepos need no additional manifest fields; record useful code/workspace",
-        "# ownership in area or architecture Context and use project-owned scope checks.",
+        "# 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.6",
+  "version": "0.8.7",
   "description": "Minimal project memory and validation harness for AI coding agents.",
   "license": "MIT",
   "author": "Seven128",