project-tiny-context-harness 0.8.6 → 0.8.8

package/README.md

@@ -62,7 +62,7 @@ No-install preview:
 
 ## Why It Exists
 
-`project_context/**` preserves small durable facts across sessions. The default workflow reads graph-relevant Context, supplements that route with one bounded Context search before `Context Delta`, and uses the platform's internal plan. For explicit long work, `long-task-delivery-v2` adds one complete Contract authority, fail-closed Source ownership, Control/applicability closure, semantic Counterfactuals, a one-time user model choice after Authority Lock, scoped progress and a protected-input-recompiled Live Final Gate.
+`project_context/**` preserves small durable facts across sessions. Both implementation routes share one risk-proportional Architecture Deliberation with applicable-quality routing before implementation, Goal-owned boundary-preserving implementation guardrails, and one current-candidate Engineering Quality Conformance that includes Architecture Conformance. The default workflow reads graph-relevant Context, supplements that route with one bounded Context search before `Context Delta`, and uses the platform's internal plan. For explicit long work, `long-task-delivery-v2` adds one complete Contract authority, fail-closed Source ownership, Control/applicability closure, semantic Counterfactuals, a one-time user model choice after Authority Lock, scoped progress and a protected-input-recompiled Live Final Gate.
 
 Tiny Context does not invoke or switch models, create agents, branches or worktrees, merge, push, create PRs, deploy, or replace project tests and human acceptance.
 
@@ -71,10 +71,10 @@ Tiny Context does not invoke or switch models, create agents, branches or worktr
 | Capability | When and how to use it | What it owns |
 |---|---|---|
 | **Minimal Context** | Installed by default. Every delivery route reads and updates `project_context/**` as needed. | Durable goals, ownership, architecture/interface/state boundaries and repeatable verification/deployment facts; never a test-pass claim. |
-| **Workflow Contract** | Prompt-level default after `init`. Give ordinary work to the current coding Goal; there is no Skill command or `delivery-contract.yaml`. | Context discovery, Architecture Deliberation, one `Context Delta`, implementation, project checks, Contract Conformance and Context drift; no validator result, Receipt, persisted workflow state or machine completion. |
+| **Workflow Contract** | Prompt-level default after `init`. Give ordinary work to the current coding Goal; there is no Skill command or `delivery-contract.yaml`. | Context discovery, Architecture Deliberation with applicable-quality routing, one `Context Delta`, Goal-owned implementation, project checks, Contract Conformance carrying Engineering Quality Conformance, and Context drift; no validator result, Receipt, persisted workflow state or machine completion. |
 | **Long-Task Workflow** | Enable the profile once, then explicitly select the `long-task-workflow` Skill, or resume a valid existing binding. Task size alone does not activate it. | One Source-bound Delivery Contract, Authority Lock, recoverable scoped progress, protected revision and a current-snapshot Live Final Gate. |
 
-Every delivery uses Minimal Context. Ordinary delivery uses the default Workflow Contract; an explicitly selected Long-Task uses `long-task-workflow` as the sole long-task execution and completion carrier. `design-system-authoring` and `design-resource-authoring` are independent optional upstream Skills, not Long-Task stages. Their selected outputs may feed either route.
+Every delivery uses Minimal Context. Ordinary delivery uses the default Workflow Contract; an explicitly selected Long-Task uses `long-task-workflow` as the sole long-task execution and completion carrier. Its Final Gate carries Engineering Quality/Architecture Conformance instead of duplicating the default closure. `design-system-authoring` and `design-resource-authoring` are independent optional upstream Skills, not Long-Task stages. Their selected outputs may feed either route.
 
 Skill names here are host-neutral. In Codex, explicitly select one with `$skill-name` (for example `$long-task-workflow`) or use `/skills`; other hosts use their own Skill selector.
 
@@ -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.8.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -181,44 +181,46 @@ 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:
 
 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;
+3. surface one concise, repository-bound Architecture Deliberation with triggered quality attributes or a concrete preservation basis;
 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;
+6. implement under Goal-owned boundary-preserving quality guardrails and run project-owned verification, including an available changed-path/target-scope check;
+7. perform Contract Conformance, including Engineering Quality Conformance and its Architecture Conformance subset plus 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.
 
-### Architecture And Modularity Guidance
-
-Technical architecture support is a shared Workflow obligation. Every implementation delivery visibly completes `Architecture Deliberation` before its first implementation edit. Risk changes depth, not occurrence. A small change names the concrete owner/current extension point, confirms durable boundaries remain unchanged and explains why it adds or worsens no debt. Material work additionally covers the unique source of truth, dependency and interface/state/lifecycle boundaries, failure/recovery/compatibility, selected and rejected alternatives, one plausible future change and its extension point, touched technical debt, forbidden shortcuts and project-owned executable checks. `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` remain internal routing questions; no Task Contract or fixed `plan.md` is required.
-
-After implementation and project verification, `Architecture Conformance` checks the current candidate for scope/path escape, owner or dependency-direction violations, service/facade bypass, duplicate authority or a second source of truth, undeclared API/schema/state/persistence change, missing architecture checks and new or worsened debt. A changed candidate invalidates the result. Default work embeds this closure in Contract Conformance; Long-Task work encodes material invariants with existing obligations/constraints/forbidden shortcuts, owners/paths/Bindings and executable Checks and lets Final Gate be the sole closure owner. The two closures never both run for one candidate.
+### Engineering Quality And Modularity Guidance
+
+Shared Engineering Quality extends the architecture obligation without adding a workflow. Every implementation delivery visibly completes `Architecture Deliberation` before its first implementation edit. Risk changes depth, not occurrence. A small change names the concrete owner/current extension point, confirms durable boundaries and applicable quality attributes remain preserved, and explains why it adds or worsens no debt. Material work additionally covers the unique source of truth, dependency and interface/state/resource-lifecycle boundaries, selected and rejected alternatives, one plausible future change and its extension point, touched technical debt, forbidden shortcuts, project-owned executable checks and triggered failure/load/threat scenarios. Correctness/invariants and maintainability/changeability always receive at least preservation; reliability/resource lifecycle, concurrency/consistency, performance/capacity/cost, security/privacy/safety, compatibility/migration/rollout and operability/observability/testability activate only when material. `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` remain internal routing questions; no Task Contract or fixed `plan.md` is required.
+
+Implementation order, methods and feedback cadence remain Goal-owned. The thin discipline is to reuse the owning service/facade/adapter and one source of truth, make the smallest complete change, preserve explicit failure/resource semantics and add abstraction only for a stable concept or evidenced change axis. Exact product/technical predicates remain owned by Semantic Facts and selected UI/UX values by selected-design closure.
+
+After implementation and project verification, `Engineering Quality Conformance` includes `Architecture Conformance` and checks the current candidate for scope/path escape, owner/dependency violations, owner bypass, duplicate truth, undeclared boundary/lifecycle change, silent failure, applicable resource/concurrency/security/compatibility/operability defects, unsupported performance claims, missing declared checks and new or worsened debt. A performance claim requires workload, metric, baseline or budget, environment, comparator/tolerance and a project-owned benchmark/probe; static shape is not runtime proof. Any candidate or controlling-input change invalidates the result. Default work embeds this closure in Contract Conformance; Long-Task maps every material independently falsifiable invariant into existing Source-backed obligations/constraints/forbidden shortcuts, owners/paths/Bindings, executable Checks and separate Assertions where functional behavior could pass independently. Final Gate is the sole Long-Task carrier and proves only that declared project-check-bound set—not overall code quality. The two carriers never both run for one candidate.
 
 Contract Conformance asks whether current Source and Context reached implementation and verification; the separately named Context drift check asks whether implementation or a new decision made durable Context stale. New or worsened debt blocks handoff unless the project has an explicit bounded exception with owner, rationale, tracking and a removal condition. Unrelated legacy debt does not automatically expand task scope, but debt touched, relied on or worsened by the change cannot remain hidden.
 
-The visible checkpoint proves that architecture consideration occurred; it does not expose private chain-of-thought, guarantee the best design or anticipate every unknowable future request. Store stable reasons, rejected alternatives or tradeoffs only in the smallest durable Context surface. Harness routes repository-native checks rather than becoming a language-generic architecture analyzer or adding architecture artifact/state. Modularity diagnostics identify the highest-risk function and line.
-
-`ty-context check-modularity` audits selected handwritten source. `validate-code-modularity` and `validate-harness` enforce it separately from `validate-context`.
+The visible checkpoint proves only that the reviewable deliberation occurred; it does not expose private chain-of-thought, guarantee the best design or anticipate every unknowable future request. Store stable reasons, rejected alternatives or tradeoffs only in the smallest durable Context surface. The obligation creates no quality plan, stage, matrix, second Authority, Contract field/aspect/Claim/risk type, Gate, state or Receipt. Harness routes repository-native type/compiler/lint/AST/dependency/contract/behavior/benchmark/probe checks rather than becoming a language-generic architecture, quality or performance analyzer.
+
+`ty-context check-modularity` is a capability-aware portable risk signal. All selected handwritten source/config formats receive physical-line analysis; JS/TS-family files additionally receive lexical per-function statement/branch, export, state-transition and responsibility heuristics; Python receives a dedicated lexical per-function statement/branch heuristic; every other included format, including Vue without an SFC parser, is line-only. Output names `analysis=js-ts-heuristic|python-heuristic|line-only`; unsupported metrics are `null` internally and `n/a` in CLI output, never zero, and cannot affect risk or regression. This is not complete static analysis, architecture proof or runtime-performance evidence. `validate-code-modularity` and `validate-harness` enforce the supported signals separately from `validate-context`.
 
 #### Modularity Policy
 
-Newly generated Harness configs default to `strict_except_generated`. Generated/build files remain excluded; `strict_except_generated` rejects configured `modularity.waivers`. Projects with bounded legacy exceptions may opt into `scoped_waivers`, whose entries require `path`, `category`, `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
+Newly generated Harness configs default to `strict_except_generated`. Generated/build files remain excluded; `strict_except_generated` rejects configured `modularity.waivers`. Projects with bounded legacy exceptions may opt into `scoped_waivers`, whose entries require `path`, `category`, `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`. An explicit `ty-context upgrade` removes only waivers that existed solely for unsupported metrics from the retired cross-language JS heuristic and whose targets have no current supported risk; ordinary `sync` never performs that migration, and every other stale or invalid waiver remains fail-closed.
 
 ### Product Surface Contract
 
@@ -304,7 +306,7 @@ Raw/revised proposals, selected design resources and mixed attachments enter one
 
 Before the first successful formal Compile, `delivery-contract.yaml` is one non-authoritative Contract Draft. `long-task-workflow` opens it at entry and revises the same Draft across Source refinement, repository/Context reads, mapping and Preflight repairs; a complete Contract need not fit one response. Source completeness is a convergence condition for Preflight/Compile, not a prior phase. There is no standalone Contract Draft Skill or Authoring State.
 
-The Long-Task Skill keeps objective/boundary/activity routing in its main file and loads one-level Source-bound Draft/Contract-mapping, evidence-design and authority-lifecycle references as applicable. Draft input repair and Contract mapping are concurrent activities, not serial phases. This is instruction packaging only, not a second authority. It performs the shared Architecture Deliberation during Draft authoring. Declared architecture invariants use existing obligations/constraints/forbidden shortcuts, owner/path/Binding boundaries and project-owned executable Checks; a functional AC cannot substitute for an independently failing architecture claim. Final Gate is the sole Long-Task Architecture Conformance carrier.
+The Long-Task Skill keeps objective/boundary/activity routing in its main file and loads one-level Source-bound Draft/Contract-mapping, evidence-design and authority-lifecycle references as applicable. Draft input repair and Contract mapping are concurrent activities, not serial phases. This is instruction packaging only, not a second authority. It performs the shared Architecture Deliberation and applicable-quality routing during Draft authoring. Declared independently falsifiable architecture or engineering-quality invariants use existing Source-backed obligations/constraints/forbidden shortcuts, owner/path/Binding boundaries, project-owned executable Checks and separate Assertions when functional behavior could pass independently. Final Gate is the sole Long-Task Engineering Quality/Architecture Conformance carrier and proves only that declared project-check-bound set.
 
 A Draft Outcome is simply an Outcome before Authority Lock. Outcomes decompose independently observable, decidable and target-verifiable results to project acceptance/verification readiness, localize failures, resume findings and invalidate stale results. `depends_on` means acceptance and intermediate-proof readiness, not implementation permission, and the Rolling Frontier is a temporary advisory projection. The current Goal chooses implementation order and may optionally use one or multiple platform-native agents/subagents; Harness creates no delegation runtime, scheduler, state or proof, agent reports are non-authoritative, and all accepted output converges into the selected verification workspace. An Outcome is not a Worker, scheduler task, queue or parallel unit. Outcome decomposes diagnosis and proof ownership, not completion authority, so one complete current-snapshot Final Gate remains mandatory.
 
@@ -416,9 +418,9 @@ make validate-harness
 
 `test:affected` is the edit/fix loop. In inferred local discovery it reports and omits only untracked `.work_products/**`; tracked and explicit paths still route fail safe. `test:long-task:trust` is the frozen-candidate high-impact boundary gate used by pull-request CI. Reviewed Trust/focused/hotspot budgets prevent silent feedback-tier growth, while complete discovery remains exhaustive. `npm test` is the complete release regression retained on `main` and publish; do not rerun it after every small repair. Controlled Ubuntu CI uses generous per-suite catastrophic time ceilings, but local timing stays diagnostic. Explicit delivery-contract and complete Long-Task gates remain available as package workspace scripts.
 
-The modularity gate is `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
+The modularity gate is the capability-aware `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`; unsupported metrics never appear as passing zeroes.
 
-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.8.tgz`.
 
 ## Community And Further Reading
 

package/assets/README.md

@@ -67,7 +67,7 @@ Coding agents need two different kinds of help:
 - durable facts that survive sessions without loading the whole repository;
 - trustworthy completion checks when a task spans many edits or context compactions.
 
-Tiny Context keeps those concerns narrow. `project_context/**` records durable ownership, architecture, contracts and repeatable verification. Both implementation routes share one visible, risk-proportional Architecture Deliberation before implementation and one current-candidate Architecture Conformance after project verification. The default Workflow Contract combines manifest routing with one bounded Context search before `Context Delta`; the explicit Long-Task Workflow adds one machine-checked Delivery Contract, a one-time post-Authority-Lock model choice, rolling repair verification, a same-snapshot Final Gate and Stop freshness.
+Tiny Context keeps those concerns narrow. `project_context/**` records durable ownership, architecture, contracts and repeatable verification. Both implementation routes share one visible, risk-proportional Architecture Deliberation with applicable-quality routing before implementation, Goal-owned boundary-preserving implementation guardrails, and one current-candidate Engineering Quality Conformance that includes Architecture Conformance after project verification. The default Workflow Contract combines manifest routing with one bounded Context search before `Context Delta`; the explicit Long-Task Workflow adds one machine-checked Delivery Contract, a one-time post-Authority-Lock model choice, rolling repair verification, a same-snapshot Final Gate and Stop freshness.
 
 It does not launch or switch models, spawn agents, create branches or worktrees, merge, push, open pull requests, deploy, or claim to replace project tests and human acceptance.
 
@@ -76,10 +76,10 @@ It does not launch or switch models, spawn agents, create branches or worktrees,
 | Capability | When and how to use it | What it owns |
 |---|---|---|
 | **Minimal Context** | Installed by default. Agents read and update `project_context/**` on every delivery route. | Durable goals, ownership, architecture/interface/state boundaries and repeatable verification/deployment facts. It never claims that implementation or tests passed. |
-| **Workflow Contract** | The prompt-level default after `init`. Ask the coding agent to do ordinary work normally; there is no Skill command or `delivery-contract.yaml`. | The lightweight loop: Context discovery, Architecture Deliberation, one `Context Delta`, implementation, project checks, Contract Conformance and Context drift. It creates no validator result, Receipt, persisted workflow state or machine completion. |
+| **Workflow Contract** | The prompt-level default after `init`. Ask the coding agent to do ordinary work normally; there is no Skill command or `delivery-contract.yaml`. | The lightweight loop: Context discovery, Architecture Deliberation with applicable-quality routing, one `Context Delta`, Goal-owned implementation, project checks, Contract Conformance carrying Engineering Quality Conformance, and Context drift. It creates no validator result, Receipt, persisted workflow state or machine completion. |
 | **Long-Task Workflow** | Enable the `long-task` profile once, then explicitly select the `long-task-workflow` Skill, or resume an existing valid binding. Task size alone never activates it. | One Source-bound Delivery Contract, Authority Lock, recoverable scoped progress, protected revision and one current-snapshot Live Final Gate. |
 
-The relationship is deliberately one-of-two at execution time: every delivery consumes Minimal Context, then ordinary work uses the default Workflow Contract while an explicitly selected Long-Task uses `long-task-workflow` as its execution and completion carrier. Long-Task Final Gate carries the final architecture and selected-design closure instead of duplicating the default Contract Conformance closure.
+The relationship is deliberately one-of-two at execution time: every delivery consumes Minimal Context, then ordinary work uses the default Workflow Contract while an explicitly selected Long-Task uses `long-task-workflow` as its execution and completion carrier. Long-Task Final Gate carries Engineering Quality/Architecture Conformance and selected-design closure instead of duplicating the default Contract Conformance closure.
 
 The base managed set also provides two explicitly triggered Open Design adapters: `design-system-authoring` generates/selects/adopts project Design Authority at cold start, while `design-resource-authoring` commissions task-local resources. They are optional upstream Skills, not a fourth mechanism and not stages inside Long-Task. Their selected outputs may feed either execution route, and `long-task-workflow` is the only active long-task execution Skill. `source-plan-authoring` remains only as a retired compatibility pointer because Long-Task inputs now enter one Source-bound Contract Draft loop directly.
 
@@ -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.8.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,33 +220,35 @@ 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;
+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 with triggered quality attributes or a concrete preservation basis;
 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;
+7. implement under Goal-owned boundary-preserving quality guardrails and run project-owned verification, including an available changed-path/target-scope check on task-attributable paths;
+8. perform Contract Conformance, including Engineering Quality Conformance and its Architecture Conformance subset on the current candidate plus 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.
 
-### Architecture And Modularity Guidance
-
-Technical architecture support is a shared Workflow obligation. Every implementation delivery visibly completes `Architecture Deliberation` before its first implementation edit. Risk changes depth, not occurrence. A small change names the concrete owner/current extension point, confirms durable boundaries remain unchanged and explains why it adds or worsens no debt. Material work additionally covers the unique source of truth, dependency and interface/state/lifecycle boundaries, failure/recovery/compatibility, selected and rejected alternatives, one plausible future change and its extension point, touched technical debt, forbidden shortcuts and project-owned executable checks. `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` remain internal routing questions; no Task Contract or fixed `plan.md` is required.
-
-After implementation and project verification, `Architecture Conformance` checks the current candidate for scope/path escape, owner or dependency-direction violations, service/facade bypass, duplicate authority or a second source of truth, undeclared API/schema/state/persistence change, missing architecture checks and new or worsened debt. A changed candidate invalidates the result. Default work embeds this closure in Contract Conformance; Long-Task work encodes material invariants with existing obligations/constraints/forbidden shortcuts, owners/paths/Bindings and executable Checks and lets Final Gate be the sole closure owner. The two closures never both run for one candidate.
+### Engineering Quality And Modularity Guidance
+
+Shared Engineering Quality extends the architecture obligation without adding a workflow. Every implementation delivery visibly completes `Architecture Deliberation` before its first implementation edit. Risk changes depth, not occurrence. A small change names the concrete owner/current extension point, confirms durable boundaries and applicable quality attributes remain preserved, and explains why it adds or worsens no debt. Material work additionally covers the unique source of truth, dependency and interface/state/resource lifecycle boundaries, selected and rejected alternatives, one plausible future change and its extension point, touched technical debt, forbidden shortcuts, project-owned executable checks and triggered failure/load/threat scenarios. Correctness/invariants and maintainability/changeability always receive at least preservation; reliability/resource lifecycle, concurrency/consistency, performance/capacity/cost, security/privacy/safety, compatibility/migration/rollout and operability/observability/testability activate only when material. `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` remain internal routing questions; no Task Contract or fixed `plan.md` is required.
+
+Implementation order, methods and feedback cadence remain Goal-owned. The thin discipline is to reuse the owning service/facade/adapter and one source of truth, make the smallest complete change, preserve explicit failure/resource semantics and add abstraction only for a stable concept or evidenced change axis. Exact product/technical predicates remain owned by Semantic Facts and selected UI/UX values by selected-design closure.
+
+After implementation and project verification, `Engineering Quality Conformance` includes `Architecture Conformance` and checks the current candidate for scope/path escape, owner/dependency violations, owner bypass, duplicate truth, undeclared boundary/lifecycle change, silent failure, applicable resource/concurrency/security/compatibility/operability defects, unsupported performance claims, missing declared checks and new or worsened debt. A performance claim requires workload, metric, baseline or budget, environment, comparator/tolerance and a project-owned benchmark/probe; static shape is not runtime proof. Any candidate or controlling-input change invalidates the result. Default work embeds this closure in Contract Conformance; Long-Task maps every material independently falsifiable invariant into existing Source-backed obligations/constraints/forbidden shortcuts, owners/paths/Bindings, executable Checks and separate Assertions where functional behavior could pass independently. Final Gate is the sole Long-Task carrier and proves only that declared project-check-bound set—not overall code quality. The two carriers never both run for one candidate.
 
 Contract Conformance asks whether current Source and Context reached implementation and verification; the separately named Context drift check asks whether implementation or a new decision made durable Context stale. New or worsened debt blocks handoff unless the project has an explicit bounded exception with owner, rationale, tracking and a removal condition. Unrelated legacy debt does not automatically expand task scope, but debt touched, relied on or worsened by the change cannot remain hidden.
 
-The visible checkpoint proves that architecture consideration occurred; it does not expose private chain-of-thought, guarantee the best design or anticipate every unknowable future request. Store stable reasons, rejected alternatives or tradeoffs only in the smallest durable Context surface. Harness may route repository-native lint/AST/dependency/contract checks, but it does not become a language-generic architecture analyzer or add an architecture artifact/state.
-
-`ty-context check-modularity` audits selected handwritten source and identifies the highest-risk function and line for statement/branch findings. `validate-code-modularity` and `validate-harness` enforce it separately from `validate-context`.
+The visible checkpoint proves only that the reviewable deliberation occurred; it does not expose private chain-of-thought, guarantee the best design or anticipate every unknowable future request. Store stable reasons, rejected alternatives or tradeoffs only in the smallest durable Context surface. The obligation creates no quality plan, stage, matrix, second Authority, Contract field/aspect/Claim/risk type, Gate, state or Receipt. Harness routes repository-native type/compiler/lint/AST/dependency/contract/behavior/benchmark/probe checks rather than becoming a language-generic architecture, quality or performance analyzer.
+
+`ty-context check-modularity` is a capability-aware portable risk signal. All selected handwritten source/config formats receive physical-line analysis; JS/TS-family files additionally receive lexical per-function statement/branch, export, state-transition and responsibility heuristics; Python receives a dedicated lexical per-function statement/branch heuristic; every other included format, including Vue without an SFC parser, is line-only. Output names `analysis=js-ts-heuristic|python-heuristic|line-only`; unsupported metrics are `null` internally and `n/a` in CLI output, never zero, and cannot affect risk or regression. This is not complete static analysis, architecture proof or runtime-performance evidence. `validate-code-modularity` and `validate-harness` enforce the supported signals separately from `validate-context`.
 
 #### Modularity Policy
 
-Newly generated Harness configs default to `strict_except_generated`. Generated/build files remain excluded; `strict_except_generated` rejects configured `modularity.waivers`. Projects with bounded legacy exceptions may opt into `scoped_waivers`, whose entries require `path`, `category`, `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
+Newly generated Harness configs default to `strict_except_generated`. Generated/build files remain excluded; `strict_except_generated` rejects configured `modularity.waivers`. Projects with bounded legacy exceptions may opt into `scoped_waivers`, whose entries require `path`, `category`, `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`. An explicit `ty-context upgrade` removes only waivers that existed solely for unsupported metrics from the retired cross-language JS heuristic and whose targets have no current supported risk; ordinary `sync` never performs that migration, and every other stale or invalid waiver remains fail-closed.
 
 ### Product Surface Contract
 
@@ -338,7 +351,7 @@ The first successful Compile creates Authority Lock and returns `execution_model
 
 Later revisions separate authority change from user decision. Formally monotonic strengthening; raw Source/Context snapshot changes with unchanged locked Claims/targets/proof obligations; operational Runner/input repair; repository-bound scope expansion; risk strengthening; and equivalent Counterfactual coverage with the same carrier, mutation and Check and no lost Claim/assertion-failure coverage auto-adopt. Product/Source Claim/target/external-confirmation changes, lost scenario/Claim/Evidence Capability/failure interception, forbidden or owner-Context removal, runner type/effect changes, verifier-kernel changes and unknown reasons are preview-only and require the exact revision identity; risk downgrade is rejected. `diagnose-revision` remains side-effect-free and can exercise eligible scope candidates, so withdrawn/replaced candidates coalesce in the same `delivery-contract.yaml` and never ask. The final pending decision begins with a plain-language Authority Revision introduction and separates `user_decision_reasons` from mechanically bounded changes. Present it first. An explicit current-task instruction that exactly covers every listed decision reason may be mechanically relayed without a second question; generic continue, blanket approval, recommendation or Agent inference does not count. Exact identity, previous-Authority continuity, evidence invalidation and the complete Final Gate apply to every adoption, which never means delivery completion.
 
-The package-managed Long-Task Skill uses progressive disclosure: its main `SKILL.md` keeps the objective, boundaries and activity routing; one-level references are read for Source-bound Draft input/Contract mapping, evidence design or authority lifecycle as applicable. Draft input repair and Contract mapping are concurrent activities, not serial phases. This reduces routine instruction load without moving any rule into a second authority. It performs the shared Architecture Deliberation during Draft authoring. When Source or controlling Context declares an architecture invariant, the Contract uses existing technical obligations/global constraints/forbidden shortcuts, owner/path/Binding boundaries and a project-owned executable Check. Functional acceptance cannot substitute when the architecture invariant can fail independently, and Final Gate is the sole Long-Task Architecture Conformance carrier.
+The package-managed Long-Task Skill uses progressive disclosure: its main `SKILL.md` keeps the objective, boundaries and activity routing; one-level references are read for Source-bound Draft input/Contract mapping, evidence design or authority lifecycle as applicable. Draft input repair and Contract mapping are concurrent activities, not serial phases. This reduces routine instruction load without moving any rule into a second authority. It performs the shared Architecture Deliberation and applicable-quality routing during Draft authoring. When Source or controlling Context declares an independently falsifiable architecture or engineering-quality invariant, the Contract uses existing technical obligations/global constraints/forbidden shortcuts, owner/path/Binding boundaries, a project-owned executable Check and a separate Assertion when functional behavior could pass independently. Final Gate is the sole Long-Task Engineering Quality/Architecture Conformance carrier and proves only that declared project-check-bound set.
 
 A Draft Outcome is simply an Outcome before Authority Lock. Outcomes split independently observable, decidable, vertical and target-verifiable results so the current Goal can project a smaller acceptance/verification-ready working set, localize failures, resume findings and invalidate stale local results. `depends_on` expresses acceptance and intermediate-proof readiness, not implementation permission. Every Outcome belongs to one ordered Stage; its Stage gate transitively depends on the other Outcomes in that Stage, and later Stages depend on earlier gates. The Rolling Frontier and Stage status are derived from ordinary Outcome Progress and are temporary advisory projections. The Goal may implement, inspect or repair any in-scope Outcome in the order current code favors and may optionally use one or multiple platform-native agents/subagents. Harness allocates and records none of them, agent reports are not Progress or proof, and all outputs converge into the selected verification workspace. An Outcome is not a Worker, scheduler task, queue or parallelism unit, and a Stage owns no Receipt or second Gate. Outcome decomposes diagnosis and proof ownership, not completion authority: targeted passes never replace the one complete Final Gate on the current final snapshot.
 
@@ -674,7 +687,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.8.tgz` under the preview output directory.
 
 ## Community And Further Reading
 

package/assets/README.zh-CN.md

@@ -10,7 +10,7 @@ Project Tiny Context Harness 是给 AI coding agents 用的轻量项目记忆层
 
 编码 Agent 同时需要两类能力：跨会话仍然可靠的少量项目事实，以及长任务经历多轮修改或上下文压缩后仍可信的完成检查。
 
-Tiny Context 将这些能力保持为窄边界。
+Tiny Context 将这些能力保持为窄边界。两条实现路径共用一次实现前、风险比例化的 Architecture Deliberation 与适用质量路由，实施过程保留 Goal 自主但遵守边界型实现质量 guardrails，项目验证后只由一个 carrier 对当前候选执行包含 Architecture Conformance 的 Engineering Quality Conformance。
 
 它不会启动或切换模型，不会创建 Agent、分支或 worktree，不会 merge、push、创建 PR 或部署，也不会取代项目测试和人工产品验收。
 
@@ -19,10 +19,10 @@ Tiny Context 将这些能力保持为窄边界。
 | 机制 | 何时、如何使用 | 负责什么 |
 |---|---|---|
 | **Minimal Context** | 默认安装；每种交付路径都会读取并按需更新 `project_context/**`。 | 保存目标、归属、架构/接口/状态边界和可重复验证/部署等耐久事实；不声称实现或测试已经通过。 |
-| **Workflow Contract** | `init` 后自动生效的 prompt-level 默认协议。普通任务直接交给当前 coding Goal；没有 Skill 命令，也不创建 `delivery-contract.yaml`。 | 执行轻量循环：Context 发现、Architecture Deliberation、唯一 `Context Delta`、实现、项目检查、Contract Conformance 与 Context drift；不产生 validator 结果、Receipt、持久工作流状态或机器完成权威。 |
+| **Workflow Contract** | `init` 后自动生效的 prompt-level 默认协议。普通任务直接交给当前 coding Goal；没有 Skill 命令，也不创建 `delivery-contract.yaml`。 | 执行轻量循环：Context 发现、带适用质量路由的 Architecture Deliberation、唯一 `Context Delta`、Goal-owned 实现、项目检查、承载 Engineering Quality Conformance 的 Contract Conformance 与 Context drift；不产生 validator 结果、Receipt、持久工作流状态或机器完成权威。 |
 | **Long-Task Workflow** | 先启用一次 `long-task` profile，再显式选择 `long-task-workflow` Skill；已有有效绑定时恢复。不能因为任务看起来很长就自动启用。 | 持有一份 Source-bound Delivery Contract、Authority Lock、可恢复的局部进度、受保护修订和当前快照 Live Final Gate。 |
 
-三者的关系是：每个任务都使用 Minimal Context；普通任务走默认 Workflow Contract；只有显式选择或恢复有效绑定时，才由 `long-task-workflow` 承担执行与完成权威。Long-Task 的 Final Gate 承载最终架构与选定设计闭环，不再重复默认 Contract Conformance。
+三者的关系是：每个任务都使用 Minimal Context；普通任务走默认 Workflow Contract；只有显式选择或恢复有效绑定时，才由 `long-task-workflow` 承担执行与完成权威。Long-Task 的 Final Gate 承载 Engineering Quality/Architecture Conformance 与选定设计闭环，不再重复默认 Contract Conformance。
 
 `design-system-authoring` 与 `design-resource-authoring` 是基础 Profile 中独立、可选的上游设计 Skill，不是第四个机制，也不是 Long-Task 的阶段。其选定产物可以进入默认或 Long-Task 任一路径；当前唯一活跃的长程执行 Skill 是 `long-task-workflow`。
 
@@ -96,24 +96,35 @@ 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 变成读取/修改权限；
-4. 对用户可见地给出一次简洁、仓库事实绑定的 Architecture Deliberation；
+3. 多目标仓库先解析本任务 intended workspace(s)，但不把 Context workspace 或 Area 变成读取/修改权限；
+4. 对用户可见地给出一次简洁、仓库事实绑定的 Architecture Deliberation，并说明触发的质量属性或具体 preservation basis；
 5. 决定 `Context Delta: none|required`，耐久语义改变时先更新 owner Context；
 6. 使用平台内部计划；
-7. 实现并运行项目验证，包括仓库已有的 changed-path / target-scope check；
-8. 执行 Contract Conformance，其中包含当前候选快照的 Architecture Conformance 和最终 change-scope 审查；
+7. 在 Goal-owned 边界型质量 guardrails 下实现并运行项目验证，包括仓库已有的 changed-path / target-scope check；
+8. 执行 Contract Conformance，其中包含当前候选快照的 Engineering Quality Conformance、其 Architecture Conformance 子集和最终 change-scope 审查；
 9. 单独执行 Context drift check 后交付。
 
 默认工作流不要求 `plan.md`、target declaration、matrix、verdict、evidence ledger、持久检索索引或第二份执行计划。任务时长、文件数和复杂度不会自动激活长程状态。
@@ -126,17 +137,21 @@ Context: updated <文件/原因>
 Context: no durable fact change
 ```
 
-### 架构与模块质量
-
-技术架构能力是两条实现路径共享的 Workflow 义务。每个实现需求都在第一处实现编辑前，对用户可见地完成一次 `Architecture Deliberation`；风险改变深度，不取消这个环节。小修改要指出具体 owner / 当前 extension point、未改变的耐久边界，以及为何没有新增或加重技术债。material 工作还要覆盖唯一 source of truth、dependency 与 interface/state/lifecycle 边界、failure/recovery/compatibility、选中和拒绝的方案、至少一个合理未来变化及其扩展点、触达的技术债、forbidden shortcuts 和项目原生可执行检查。
-
-实现和项目验证之后，`Architecture Conformance` 对当前候选快照检查 scope/path escape、owner 或 dependency direction 违规、service/facade 绕过、重复权威或第二 source of truth、未声明 API/Schema/state/persistence 变化、缺失架构检查和新增/加重技术债。候选再变化就使结果失效。普通任务把它放在 Contract Conformance 内；Long-Task 用已有 obligation/constraint/forbidden shortcut、owner/path/Binding 和 executable Check 表达不变量，只由 Final Gate 收口，同一候选不会执行两次。
+### 工程质量与模块化
+
+Shared Engineering Quality 在不增加工作流的前提下扩展原有架构义务。每个实现需求都在第一处实现编辑前，对用户可见地完成一次 `Architecture Deliberation`；风险改变深度，不取消这个环节。小修改要指出具体 owner / 当前 extension point、未改变的耐久边界、适用质量属性的 preservation，以及为何没有新增或加重技术债。material 工作还要覆盖唯一 source of truth、dependency 与 interface/state/resource lifecycle 边界、选中和拒绝的方案、至少一个合理未来变化及其扩展点、触达的技术债、forbidden shortcuts、项目原生可执行检查和触发的 failure/load/threat 场景。correctness/invariant 与 maintainability/changeability 至少给出 preservation；reliability/resource lifecycle、concurrency/consistency、performance/capacity/cost、security/privacy/safety、compatibility/migration/rollout、operability/observability/testability 只在 material 时激活。
+
+实现顺序、方法和反馈节奏仍由 Goal 决定。轻量纪律只要求复用 owning service/facade/adapter 与唯一 source of truth，做最小而完整的变化，保留明确 failure/resource 语义，并仅为稳定概念或有证据的变化轴增加抽象。精确产品/技术谓词继续由 Semantic Facts 拥有，精确选定 UI/UX 值由 selected-design closure 拥有。
+
+实现和项目验证之后，`Engineering Quality Conformance` 包含 `Architecture Conformance`，对当前候选快照检查 scope/path escape、owner/dependency 违规或 bypass、重复 truth、未声明 boundary/lifecycle 变化、silent failure、适用 resource/concurrency/security/compatibility/operability 缺陷、无证据性能声称、缺失声明检查和新增/加重技术债。性能声称必须绑定 workload、metric、baseline 或 budget、environment、comparator/tolerance 和项目原生 benchmark/probe；静态形状不证明运行时性能。候选或 controlling input 再变化就使结果失效。普通任务把它放在 Contract Conformance 内；Long-Task 用已有 Source-backed obligation/constraint/forbidden shortcut、owner/path/Binding、executable Check，以及功能 pass 时仍可能独立失败的 Assertion 表达不变量。Final Gate 是唯一 Long-Task carrier，只证明该声明、可证伪、项目检查绑定的集合，不证明整体代码质量；同一候选不会执行两套 carrier。
 
 Contract Conformance 主要检查当前 Source/Context 是否到达实现和验证；单独命名的 Context drift check 反向检查实现或新决策是否让耐久 Context 过时。新增或加重技术债默认阻塞，除非项目有带 owner、rationale、tracking 和 removal condition 的显式 bounded exception。无关 legacy debt 不自动扩张任务范围，但本次触达、依赖或加重的债不能隐藏。
 
-`Architecture Context Hit`、`Decision Rationale Hit: existing|required|none` 和 `Modularity Check: none|required|exception` 仍是内部路由问题，不创建 Task Contract 或固定 `plan.md`。可见检查点证明“做过架构考量”，不暴露私有思维链，也不保证最佳设计或预知所有未知未来需求。
-
-Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨语言通用架构分析器或新增架构 artifact/state。`check-modularity` 的语句数/分支风险会定位到最高风险函数和行号。
+`Architecture Context Hit`、`Decision Rationale Hit: existing|required|none` 和 `Modularity Check: none|required|exception` 仍是内部路由问题，不创建 Task Contract 或固定 `plan.md`。可见检查点只证明“存在可审查的考量”，不暴露私有思维链，也不保证最佳设计或预知所有未知未来需求。该义务不增加质量 plan/stage/matrix、第二 Authority、Contract field/aspect/Claim/risk kind、Gate、state 或 Receipt。
+
+Harness 只路由仓库原生 type/compiler/lint/AST/dependency/contract/behavior/benchmark/probe，不实现跨语言通用架构、质量或性能分析器。`ty-context check-modularity` 是 capability-aware portable risk signal：所有纳入格式检查物理行；JS/TS family 另做 lexical 单函数语句/分支、export、state-transition 与 responsibility 启发式；Python 只做专用 lexical 单函数语句/分支；其他格式（包括没有 SFC parser 的 Vue）只做 line-only。输出明确 `analysis=js-ts-heuristic|python-heuristic|line-only`；不支持指标内部为 `null`、CLI 为 `n/a`，绝不伪装成零，也不参与 risk/regression。它不是完整 static analysis、架构证明或运行时性能证据。
+
+新配置默认 `strict_except_generated`；需要 bounded legacy exception 的项目可使用 lifecycle-complete `scoped_waivers`。显式 `ty-context upgrade` 只清理那些纯粹因退役跨语言 JS 启发式的现已不支持指标而存在、且目标没有当前受支持风险的 waiver；普通 `sync` 不执行该迁移，其他 stale/invalid waiver 继续 fail closed。
 
 ### Product Surface 与 Screen Contract
 
@@ -254,7 +269,7 @@ Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）
 
 锁定后的修订把“Authority 有变化”和“需要用户决策”分开：单调增强、锁定 Claims/targets/proof obligations 不变的 Source/Context snapshot 更新、Runner/input 实装修复、repo-bound scope 扩展、风险增强，以及 carrier、mutation、Check 相同且 Claim/预期失败断言覆盖不减少的等价 Counterfactual 覆盖可自动采用；产品/Source Claim/target/external-confirmation 变化，丢失 scenario/Claim/Evidence Capability/失败拦截，移除 forbidden/owner Context，runner type/effect、verifier kernel 或未知 reason 则只预览并等待精确 identity，风险降级直接拒绝。`diagnose-revision` 无副作用，撤回/替换候选只在同一 `delivery-contract.yaml` 合并，不产生询问。最终 pending brief 先解释 Authority Revision 是什么，再区分 `user_decision_reasons` 与机械边界变化。必须先展示 brief；若当前任务已有明确指令精确覆盖全部决策 reason，可机械转录而不二次询问，泛化“继续”、一揽子批准、建议或 Agent 推断不算。每次采用都保留 exact identity、旧 Authority 连续性、证据失效和完整 Final Gate，并返回滚动实现，绝不表示完成。
 
-Long-Task Skill 采用渐进读取：主 `SKILL.md` 只保留目标、硬边界和路由；Draft 输入/Contract Authoring、Evidence Design 与 Authority Lifecycle 细节按当前活动读取一层 reference，其中 Draft 输入与 Contract mapping 同时进行。这只是指令组织，不产生第二权威。共享 Architecture Deliberation 在 Source-bound Draft authoring 中完成；material 架构不变量使用已有 obligations/constraints/forbidden shortcuts、owner/path/Binding 和项目原生 executable Checks，Final Gate 是唯一的 Long-Task Architecture Conformance 承载点。
+Long-Task Skill 采用渐进读取：主 `SKILL.md` 只保留目标、硬边界和路由；Draft 输入/Contract Authoring、Evidence Design 与 Authority Lifecycle 细节按当前活动读取一层 reference，其中 Draft 输入与 Contract mapping 同时进行。这只是指令组织，不产生第二权威。共享 Architecture Deliberation 与适用质量路由在 Source-bound Draft authoring 中完成；material 且可独立证伪的架构/工程质量不变量使用已有 Source-backed obligations/constraints/forbidden shortcuts、owner/path/Binding、项目原生 executable Checks，以及功能行为可独立通过时的单独 Assertion。Final Gate 是唯一的 Long-Task Engineering Quality/Architecture Conformance 承载点，只证明该声明、项目检查绑定的集合。
 
 Draft Outcome 只是 Authority Lock 前的 Outcome。Outcome 按可独立观察、判断、纵向闭环和定向验证的结果拆分，用于投影 acceptance/verification-ready 工作集、定位失败、恢复 finding 并精确失效旧局部结果。`depends_on` 只表示 acceptance 与中间证明 readiness，不授权或禁止实现编辑。每个 Outcome 属于一个有序 Stage；Stage gate 传递依赖同 Stage 其余 Outcome，后续 Stage 依赖前置 gate。Rolling Frontier 和 Stage 状态都由普通 Outcome Progress 临时派生，只是建议性验证/诊断投影。当前 Goal 可按代码现实跨 Outcome/Stage 实现、检查或返工，也可使用平台原生 opaque delegation；Harness 不创建 delegation scheduler、不把委派当证明，所有结果必须汇入选定验证 worktree。Outcome 不是 Worker、scheduler task、queue 或并行单元，Stage 也没有 Receipt 或第二个 Gate。Outcome 拆分诊断和证明归属，不拆分完成权威，因此最终仍必须在当前最终快照运行一次完整 Final Gate。
 
@@ -369,7 +384,7 @@ make validate-harness
 
 `test:affected` 用于日常修改和修复循环；本地推断只会报告并略过未跟踪的 `.work_products/**`，tracked 与显式路径仍按 fail-safe 路由。`test:long-task:trust` 是冻结候选版本后的高风险边界门，也是 PR CI 使用的层级；经审阅的 Trust/focused/hotspot 预算防止反馈层静默膨胀，但完整套件发现不设裁剪上限。`npm test` 是 `main` 和发布保留的完整发布回归，不应在每次小修复后重跑。受控 Ubuntu CI 使用有充分余量的分层灾难性耗时上限，本地耗时仍只做诊断。Delivery Contract 和完整 Long-Task 门仍可通过 package workspace scripts 显式执行。
 
-模块化门禁是 `ty-context check-modularity`；例外必须包含 `owner`、`introduced_at`、`reason`、`tracking_issue` 和 `expiry_condition`。
+模块化门禁是 capability-aware 的 `ty-context check-modularity`；例外必须包含 `owner`、`introduced_at`、`reason`、`tracking_issue` 和 `expiry_condition`，不支持指标不会以零值制造通过假象。
 
 ## 诚实限制
 

package/assets/agents/AGENTS_CORE.md

@@ -2,11 +2,13 @@
 
 This project uses Tiny Context. The Harness maintains durable Context and workflow authority; project tests, CI, runtime evidence and human acceptance prove product quality. Its three capabilities are Minimal Context, the automatically applicable default Workflow Contract and the explicitly selected Single-Goal Long-Task Workflow.
 
-## Shared Architecture Quality Obligation
+## Shared Engineering Quality Obligation
 
-Before the first implementation edit, every delivery surfaces one externally observable, repository-bound `Architecture Deliberation`. Depth is risk-proportional, but the checkpoint always names affected owners, the current extension point/source of truth, dependency and state/lifecycle boundaries, the selected design and material alternatives, one plausible future-change challenge, touched technical debt and its disposition, forbidden shortcuts and project-owned checks. A small change may record preservation, but it still names the concrete owner/extension point and why no new or worsened debt is introduced. Refresh the checkpoint when scope, ownership or selected design materially changes.
+Before the first implementation edit, every delivery surfaces one externally observable, repository-bound `Architecture Deliberation`. Depth is risk-proportional, but the checkpoint always names affected owners, the current extension point/source of truth, dependency and state/lifecycle boundaries, the selected design and material alternatives, one plausible future-change challenge, touched technical debt and its disposition, forbidden shortcuts, project-owned checks and triggered engineering-quality attributes or their concrete preservation basis. Correctness/invariants and maintainability/changeability always receive at least a preservation judgment; reliability/resource lifecycle, concurrency/consistency, performance/capacity/cost, security/privacy/safety, compatibility/migration/rollout and operability/observability/testability activate only when the change or an explicit claim makes them material. Exact product/technical predicates remain owned by Semantic Facts and exact selected UI/UX values by selected-design closure. Refresh the checkpoint when scope, ownership, selected design, quality applicability or debt disposition materially changes.
 
-After implementation and project verification, perform one current-candidate `Architecture Conformance`. Default work embeds it in Contract Conformance; an active Long-Task embeds it only in Final Gate. Never schedule both, and recheck after any candidate change. New/worsened debt, a duplicate source of truth, wrong dependency direction, owner bypass, scope escape or a forbidden shortcut blocks handoff unless a bounded project-owned exception records owner, rationale, tracking and removal condition. This creates no architecture artifact, second Authority, workflow state or generic analyzer.
+Implementation order, method and feedback cadence remain Goal-owned. Reuse the owning service/facade/adapter and one source of truth, keep the change minimal but complete, preserve explicit failure and resource-lifecycle semantics, and add abstraction only for a stable concept or evidenced change axis. These are guardrails, not a phase, per-edit mandate or proof that code is globally clean.
+
+After implementation and project verification, perform one current-candidate `Engineering Quality Conformance` that includes `Architecture Conformance` and every triggered falsifiable invariant. Default work embeds it in Contract Conformance; an active Long-Task embeds it only in Final Gate through existing Source-backed obligations/constraints/forbidden shortcuts, owner/path/Bindings, executable Checks and independent Assertions when functional behavior could pass separately. Never schedule both carriers, and recheck after any candidate or controlling-input change. Final Gate proves only that declared project-check-bound set, not overall code quality. A performance claim additionally requires a workload, metric, baseline or budget, environment, comparator/tolerance and project-owned measurement; static shape is not runtime proof. New/worsened debt, duplicate truth, wrong dependency direction, owner bypass, silent failure, resource-lifecycle defect, scope escape, unsupported quality claim or forbidden shortcut blocks handoff unless a bounded project-owned exception records owner, rationale, tracking and removal condition. This creates no quality artifact, matrix, second Authority, Contract field/aspect/Claim/risk type, Gate, workflow state or generic analyzer.
 
 ## Default Workflow Contract
 
@@ -14,14 +16,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.
-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`.
+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`, including applicable-quality routing or a concrete preservation basis, 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.
+8. Implement precisely under the Goal-owned quality guardrails 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 `Engineering Quality Conformance`, its `Architecture Conformance` subset, the non-UI semantic closure and any selected-design closure below, then run the separate Context drift check. Report implementation, verification, engineering/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
 
@@ -65,7 +67,7 @@ The loaded Skill and its progressive references own Source/Contract authoring, C
 
 After the first Authority Lock, `execution_model_checkpoint.required: true` is a terminal-turn boundary. Unless the user already stated an explicit task-specific current-model or switch-and-resume strategy, stop before product implementation, edits, builds or tests and ask the user to choose `continue_current_model` or switch models and then resume. Generic continue/resume/finish/continue-goal language does not satisfy it; later revisions do not repeat it and Harness records no model route or checkpoint acknowledgement state.
 
-Long-Task Final Gate is the sole `Architecture Conformance` and selected-design closure owner. It source-recompiles and reruns every declared Check on one current snapshot; targeted Progress, prose, historical tests, Receipts, compiled cache or Agent judgment never create acceptance. Exactly fresh `machine_accepted` with no pending External Confirmation is the complete declared-machine terminal; qualified/external-pending results never complete the platform-native Goal.
+Long-Task Final Gate is the sole `Engineering Quality Conformance`, `Architecture Conformance` and selected-design closure owner. It source-recompiles and reruns every declared Check on one current snapshot; targeted Progress, prose, historical tests, Receipts, compiled cache or Agent judgment never create acceptance. It proves the declared falsifiable project-check-bound invariants, not overall code quality. Exactly fresh `machine_accepted` with no pending External Confirmation is the complete declared-machine terminal; qualified/external-pending results never complete the platform-native Goal.
 
 The `F = Implementation Freedom Boundary` keeps implementation order, methods, local feedback cadence and optional platform-native one-agent/multi-agent execution Goal-owned within Source/Contract, architecture, safety, forbidden-shortcut and external-action boundaries. Harness creates no development method Gate, per-edit mandate, agent scheduler/delegation state or proof from delegated reports; all proof-bearing output converges into the selected verification workspace.
 

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
 
@@ -21,13 +21,16 @@ This is the restrained architecture context. Keep only facts that help a fresh a
 - Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, debug history, agent reasoning or reasons inferred only from current code shape.
 - Architecture boundary changes should be captured here before implementation alignment.
 
-## Constraints And Tradeoffs
-
-- Capture performance, safety, integration, deployment or maintainability constraints that matter for future changes.
-
-## Verification Implications
-
-- List project-specific verification entry points affected by architectural changes; do not claim tests already passed.
+## Constraints And Tradeoffs
+
+- Capture only durable engineering-quality constraints and tradeoffs that materially shape future work: failure/recovery or resource lifecycle, concurrency/consistency, performance/capacity/cost, security/privacy/safety, compatibility/migration/rollout, integration/deployment/operability or maintainability/changeability.
+- Name the stable owner and extension point, one plausible future-change/load/failure/threat scenario when it explains the constraint, and any bounded debt/exception lifecycle. Do not create a generic quality checklist or duplicate exact product/technical values owned by a contract or other Context.
+
+## Verification Implications
+
+- List the project-native type/compiler/lint/architecture/contract/behavior/benchmark/probe entry points that can falsify durable boundaries or quality constraints; state only what each path is capable of proving.
+- For a durable performance constraint, preserve workload, metric, environment, baseline or budget and comparator/tolerance ownership here or in the narrower owning Context. Static shape checks are not runtime-performance proof.
+- Do not record one-off results or claim that checks already passed.
 
 ## Open Risks
 

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