project-tiny-context-harness 0.6.0 → 0.6.1

package/README.md

@@ -137,7 +137,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.6.0.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.6.1.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -197,7 +197,9 @@ An explicit Long-Task uses its existing Requirement, Control, Assertion, `ui_bro
 
 ### Optional Source Plan Authoring
 
-Use `/source-plan-authoring` only for an explicitly requested initial plan, Source Plan, source draft, or an audit/refinement of such a plan for later implementation or Contract authoring. It produces one self-contained Markdown document with preserved direct requirements, traceable necessary derivations, `DEC`/`decision_required` product choices, semantic Outcome boundaries, stable keys/anchors, independently meaningful decided `CTRL` fields, Runtime-exact Fact/Affected-Outcome `RISK` items, distinct `OBL`/`HINT` items and one observable scenario per `AC` with explicit accepted `REQ`/`CTRL`/`OBL` keys. Risk names are the ten Contract facts: use `data_migration`, split critical-path weak observability into `critical_user_path` plus `weak_observability`, and preserve `multi_repository_change` for Compiler rejection.
+Use `/source-plan-authoring` for an explicitly requested initial plan, Source Plan, source draft, or synthesis/refinement/audit of later implementation or Contract-authoring Source. It accepts either one substantially complete plan or a sparse goal plus mixed notes, product/technical documents, screenshots, diagrams and other attachments; a short instruction identifying their roles, the goal, reference authority and desired elaboration is sufficient.
+
+It produces one self-contained Markdown document with a complete input inventory, preserved direct requirements, traceable necessary derivations and explicitly delegated low-impact/reversible product choices. Unsupported high-impact choices remain `DEC`/`decision_required`. Interactive products are expanded through every in-scope surface to material control level, including placement, behavior, validation, navigation, loading/empty/success/failure/recovery/permission feedback and accessibility. The plan retains semantic Outcome boundaries, stable keys/anchors, Runtime-exact Fact/Affected-Outcome `RISK` items, distinct `OBL`/`HINT` items and one observable scenario per `AC` with explicit accepted `REQ`/`CTRL`/`OBL`/`NCOMP` keys. Risk names are the ten Contract facts: use `data_migration`, split critical-path weak observability into `critical_user_path` plus `weak_observability`, and preserve `multi_repository_change` for Compiler rejection.
 
 It does not update Context, bind a repository, generate Delivery Contract YAML, execute implementation, create workflow state or claim completion. `HINT` is not a Material Source Item, and the Skill emits no `ty-source-item` markers. A Source Plan is Source, not a Contract Draft. The structure is optional; ordinary prose remains valid Long-Task Source.
 
@@ -205,7 +207,7 @@ It does not update Context, bind a repository, generate Delivery Contract YAML,
 
 The explicit Long-Task Workflow uses one platform-native Goal, one user-selected repository/workspace, one complete `long-task-delivery-v2` Contract and one Final Gate. Outcomes are independently decidable acceptance units; Delivery Set orchestration and top-level Contract splitting inside one selected delivery are retired.
 
-Contract authoring preserves stable Source keys/anchors where practical. Meaning-preserving structural decomposition and evidence-backed repository binding may continue, while new product semantics require `decision_required`. Missing recommended Source Plan structure alone never blocks authoring.
+Contract authoring preserves stable Source keys/anchors where practical. A product choice already recorded in Source under explicit user delegation remains ordinary Source meaning, but Contract authoring cannot extend that delegation. Meaning-preserving structural decomposition and evidence-backed repository binding may continue, while any other new product semantics require `decision_required`. Missing recommended Source Plan structure alone never blocks authoring.
 
 Before the first successful formal Compile, `delivery-contract.yaml` is one non-authoritative Contract Draft. `/long-task-workflow` revises the same Draft across repository/Context reads and Preflight repairs; a complete Contract need not fit one response. Integrated authoring keeps repository evidence and findings attached to the same object and avoids a second handoff, plan, authority or Receipt. There is no standalone Contract Draft Skill or Authoring State.
 
@@ -305,7 +307,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.6.0.tgz`.
+The synchronized local preview tarball is named `project-tiny-context-harness-0.6.1.tgz`.
 
 ## Community And Further Reading
 

package/assets/README.md

@@ -137,7 +137,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.6.0.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.6.1.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -218,20 +218,21 @@ An explicit Long-Task expresses material visual expectations through the existin
 
 ### Optional Source Plan Authoring
 
-Use `/source-plan-authoring` only when explicitly asking for an initial plan, Source Plan, source draft, or an audit/refinement of such a plan for later implementation or Contract authoring.
+Use `/source-plan-authoring` when explicitly asking for an initial plan, Source Plan, source draft, or synthesis/refinement/audit of later implementation or Contract-authoring Source. The input may be one substantially complete plan or a sparse goal plus mixed notes, product/technical documents, screenshots, diagrams and other attachments. A short request that identifies the artifact roles, product goal, reference authority and desired elaboration is enough; no intake questionnaire or pre-normalized outline is required.
 
 It outputs one self-contained Markdown Source Plan that:
 
+- inventories every supplied artifact, inspects all material pages/frames/screens and records coverage gaps instead of silently sampling;
 - preserves direct requirements and their qualifiers;
 - marks necessary derivations and cites what they derive from;
-- turns unsupported product choices into `DEC`/`decision_required`;
+- when the user delegates synthesis or elaboration, makes traceable low-impact, reversible product choices marked `delegated`, while keeping permissions, destructive behavior, pricing, retention, security policy and other high-impact choices as `DEC`/`decision_required`;
 - splits Outcomes only by independently decidable observable results;
 - uses stable semantic keys and explicit anchors for important Source items;
 - separates mandatory `OBL` obligations from advisory `HINT` suggestions;
-- independently records each decided `CTRL` Location, User task, Trigger, Input, Loading, Empty, Success, Failure and Feedback field;
+- for interactive products, inventories every in-scope surface and material control, then independently records its surface/region/type/label, placement, task, visibility/availability, trigger/input/validation/default, interaction/navigation, loading/empty/success/failure/recovery/permission/feedback and accessibility fields;
 - uses `NCOMP` for explicit results that must not count as completion;
 - states each `RISK` Fact, one Affected Outcome, Basis and Consequence, or emits `DEC` when the pair is unknown; Fact is exactly one of `public_api_or_schema_change`, `persistent_data_change`, `data_migration`, `security_boundary_change`, `permission_boundary_change`, `irreversible_external_effect`, `critical_user_path`, `full_population_operation`, `multi_repository_change` or `weak_observability`;
-- writes one Given/When/Then scenario per `AC`, names its accepted `REQ`/`CTRL`/`OBL`/`NCOMP` keys, and hides no new requirement in AC text.
+- writes one Given/When/Then scenario per `AC`, names its accepted `REQ`/`CTRL`/`OBL`/`NCOMP` keys, hides no new requirement in AC text and reports whether the document is ready for Contract authoring.
 
 It does not update project Context, bind real repository owners/paths/runners, generate Delivery Contract YAML, run implementation, create workflow state or claim completion. `HINT` is not a Material Source Item, and Source Plan authoring emits no `ty-source-item` markers; repository-aware Long-Task authoring inserts markers later. A Source Plan is Source, not a Contract Draft. Its structure is an authoring fast path, not a required input protocol; ordinary prose plans remain valid Long-Task Source.
 
@@ -249,7 +250,7 @@ Use `/long-task-workflow` only when explicitly requested or when the current wor
 - a complete Final Gate on one current snapshot;
 - a Stop Hook that rejects stale completion.
 
-Long-Task Contract authoring preserves stable Source keys and anchors where practical. Meaning-preserving structural decomposition and evidence-backed repository binding may continue; new business rules, defaults, recovery behavior, permissions or scope become `decision_required` instead of being silently added. Missing recommended Source Plan structure never blocks authoring, but the marker-only Material Source Item enumeration required for activation does.
+Long-Task Contract authoring preserves stable Source keys and anchors where practical. A product choice already recorded in Source under explicit user delegation remains ordinary Source meaning, but Contract authoring cannot extend that delegation. Meaning-preserving structural decomposition and evidence-backed repository binding may continue; any other new business rule, default, recovery behavior, permission or scope becomes `decision_required` instead of being silently added. Missing recommended Source Plan structure never blocks authoring, but the marker-only Material Source Item enumeration required for activation does.
 
 Before the first successful formal Compile, `delivery-contract.yaml` is one non-authoritative Contract Draft. `/long-task-workflow` keeps revising that same Draft across repository/Context reads and Preflight repair rounds; it does not require one response to produce a complete Contract. Draft authoring is integrated because repository bindings and verification inputs need real evidence, Preflight findings must feed back into the same object, and a separate handoff would risk lost meaning or a second plan/authority. No standalone Contract Draft Skill, Draft Receipt or Authoring State exists.
 
@@ -451,7 +452,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.6.0.tgz` under the preview output directory.
+`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.6.1.tgz` under the preview output directory.
 
 ## Community And Further Reading
 

package/assets/README.zh-CN.md

@@ -111,20 +111,21 @@ Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨
 
 ### 可选 Source Plan Authoring
 
-只有用户明确要求初版方案、源方案、方案源稿、Source Plan，或要求审计/重构这类后续实现与 Contract Authoring 的输入时，才使用 `/source-plan-authoring`。
+用户明确要求初版方案、源方案、方案源稿、Source Plan，或要求综合、细化、审计后续实现与 Contract Authoring 的 Source 时，使用 `/source-plan-authoring`。输入既可以是一份接近完成的方案，也可以只是目标，加上零散笔记、产品/技术文档、截图、图表等混合附件。用户只需说明附件角色、产品目标、参考资料是精确目标还是灵感，以及希望 Skill 细化即可；不需要先填问卷或整理统一大纲。
 
 它输出一份自包含 Markdown Source Plan：
 
+- 为每份附件建立 Input Inventory，完整检查有实质含义的页面、画面与屏幕，未读内容或覆盖缺口必须显式报告，不能静默抽样；
 - 保留直接要求及其限定条件；
 - 必要推导必须标记并写明 `Derived From`；
-- 无来源的新产品选择进入 `DEC`/`decision_required`；
+- 用户明确委托综合或细化时，可以自主作出低影响、可逆的产品选择，但必须标记为 `delegated` 并记录委托语句与依据；权限、破坏性行为、付费、数据保留、安全策略等高影响选择仍进入 `DEC`/`decision_required`；
 - Outcome 只按可独立判断的可观察结果拆分；
 - 重要 Source 项使用稳定语义 Key 与显式 Anchor；
 - 强制技术义务使用 `OBL`，非强制实现建议使用 `HINT`；
-- 每个已决定的 `CTRL` 分别记录 Location、User task、Trigger、Input、Loading、Empty、Success、Failure 与 Feedback；
+- 对交互产品，先穷举范围内的 surface，再细化到每个实质控件，分别记录页面/区域/类型/文案、位置、任务、可见与可用条件、触发/输入/校验/默认值、交互/跳转，以及 Loading、Empty、Success、Failure、Recovery、Permission、Feedback 和 Accessibility；
 - 明确“不算完成”的 Source 含义使用 `NCOMP`；
 - 每个 `RISK` 明确 Fact、单个 Affected Outcome、Basis 与 Consequence，无法确定时进入 `DEC`；Fact 精确使用 Runtime 的十个名称：`public_api_or_schema_change`、`persistent_data_change`、`data_migration`、`security_boundary_change`、`permission_boundary_change`、`irreversible_external_effect`、`critical_user_path`、`full_population_operation`、`multi_repository_change`、`weak_observability`；
-- 每个 AC 只代表一个 Given/When/Then 可观察场景，显式列出对应 `REQ`/`CTRL`/`OBL`/`NCOMP` Key，且不能首次偷渡新需求。
+- 每个 AC 只代表一个 Given/When/Then 可观察场景，显式列出对应 `REQ`/`CTRL`/`OBL`/`NCOMP` Key，不能首次偷渡新需求，并在文末报告是否已可交给 Contract Authoring。
 
 它不更新项目 Context，不绑定真实仓库 owner/path/runner，不生成 Delivery Contract YAML，不执行实现，不创建工作流状态，也不声明完成。`HINT` 不是 Material Source Item；Source Plan Skill 不输出 `ty-source-item` Marker，Marker 由后续 repository-aware Long-Task Authoring 插入。Source Plan 是 Source，不是 Contract Draft。推荐结构只是 Authoring Fast Path；普通 prose/Source Plan 或普通文本方案仍可直接作为 Long-Task Source。
 
@@ -142,7 +143,7 @@ Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨
 - Final Gate 在一个当前快照上重跑全部 Check；
 - Stop Hook 在结果 stale 时阻止完成。
 
-Long-Task Contract Authoring 会尽量保留 Source 中已有的稳定 Key 与 Anchor。保持产品含义的结构分解和有真实证据的仓库绑定可以继续；新增业务规则、默认值、恢复行为、权限或范围必须进入 `decision_required`，不能静默加入。缺少推荐 Source Plan 结构不构成阻塞，但激活前必须完成只插入标记、不改写原文的 Material Source Item 枚举。
+Long-Task Contract Authoring 会尽量保留 Source 中已有的稳定 Key 与 Anchor。已经在 Source Plan 中依据用户显式委托记录的产品选择属于普通 Source 含义，但 Contract Authoring 不能扩大这份委托。保持产品含义的结构分解和有真实证据的仓库绑定可以继续；除此之外新增业务规则、默认值、恢复行为、权限或范围必须进入 `decision_required`，不能静默加入。缺少推荐 Source Plan 结构不构成阻塞，但激活前必须完成只插入标记、不改写原文的 Material Source Item 枚举。
 
 第一次正式 Compile 成功前，`delivery-contract.yaml` 是同一份非权威 Contract Draft。`/long-task-workflow` 可以跨多轮仓库/Context 读取和 Preflight 修复持续修改它，不要求一次响应生成完整 Contract。不存在单独 Contract Draft Skill、Draft Receipt 或 Authoring State。
 

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

@@ -49,7 +49,7 @@ A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema
 4. Preserve at least one real `source_path`. Wrap every material Source item in its original Markdown with non-rendering `ty-source-item:start/end` markers without rewriting the text; marked Source Item keys and `source_claim` keys are exactly equal.
 5. An ordinary prose plan or optional Source Plan remains valid Source after marker-only enumeration and does not need to match the recommended Source Plan structure. Preserve stable semantic keys and Markdown anchors where practical.
 6. Continue reading repository, Source and Context and revise the same Draft. Return for a real decision when requirements conflict, critical semantics are missing, multiple materially different product designs remain, the user must choose a product rule or no falsifiable acceptance standard can be formed.
-7. Contract expansion is limited to meaning-preserving structural decomposition and repository binding supported by real repository and Context evidence. A new business rule, default, threshold, recovery behavior, permission or platform/data scope is `decision_required` and must not be silently added.
+7. Contract expansion is limited to meaning-preserving structural decomposition and repository binding supported by real repository and Context evidence. A product choice already authored in Source under a recorded explicit user delegation is Source meaning: preserve it, but do not extend that delegation. Any other new business rule, default, threshold, recovery behavior, permission or platform/data scope is `decision_required` and must not be silently added.
 8. Run read-only `ty-context long-task preflight <workdir>`, repair every error and `decision_required` finding in the same Draft, then formally Compile only when ready.
 9. When the first Compile returns `execution_model_checkpoint.required: true`, stop before implementation and ask the user to choose `continue_current_model` or switch models and then resume the active Long-Task. A task-specific choice already stated explicitly satisfies the checkpoint. Later revisions return `required: false` and do not repeat it.
 

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

@@ -10,6 +10,7 @@ Read this only while authoring or structurally revising the one `delivery-contra
 - Every non-decision Source item owns exactly one same-kind, text-identical canonical target; no target may collapse multiple Source items. `out_of_scope` is not a resolution.
 - A Source AC maps criterion-identically to one named Assertion and proves at least one independently Source-backed non-Result Claim.
 - Missing recommended Source Plan headings or keys never blocks authoring. Missing mandatory Material Source Item markers does.
+- `delegated` in a Source Plan is provenance, not a Contract disposition or new Claim kind. When the plan records the explicit user instruction, basis and added meaning, preserve that keyed item as ordinary Source of its semantic kind. Do not use its delegation to invent further product choices during Contract authoring.
 
 ## Outcome Boundary
 

package/assets/skills/source-plan-authoring/SKILL.md

@@ -1,20 +1,21 @@
 ---
 name: source-plan-authoring
-description: Use only when the user explicitly asks for 初版方案、源方案、方案源稿、Source Plan, initial delivery plan, or asks to refine or audit such a plan as input for later implementation or Contract authoring. Produce one self-contained Markdown Source Plan with stable semantic keys, traceable derivations, acceptance scenarios, non-goals, risks and unresolved decisions. Do not trigger for ordinary product discussion, routine coding, implementation work, Delivery Contract authoring or long-task execution.
+description: Use only when the user explicitly asks for 初版方案、源方案、方案源稿、Source Plan, initial delivery plan, source draft, or asks to synthesize, refine or audit later implementation or Contract-authoring Source from one draft or mixed inputs such as notes, product/technical documents, screenshots, diagrams or other attachments. Produce one self-contained Markdown Source Plan with complete input coverage, traceable direct/derived/delegated content, control-level UI detail when applicable, stable semantic keys, acceptance scenarios, non-goals, risks and unresolved decisions. Do not trigger for ordinary product discussion, routine coding, implementation work, Delivery Contract authoring or long-task execution.
 ---
 
 # Source Plan Authoring
 
 ## Objective
 
-Produce one high-fidelity, self-contained Markdown Source Plan that preserves the user's real intent, supports later refinement and makes every added inference traceable.
+Produce one high-fidelity, self-contained Markdown Source Plan from either a nearly finished plan or a sparse brief plus mixed supplied artifacts. Preserve the user's real intent, expand it to the detail needed by later `long-task-workflow` Contract authoring and make every added inference or delegated choice traceable.
 
-Record every product, technical and acceptance meaning that later work must not omit, change or silently add. Prefer semantic completeness over template completeness.
+Record every product, technical and acceptance meaning that later work must not omit, change or silently add. For an in-scope user interface, reach page, region, control, state and feedback granularity. Prefer semantic completeness over template completeness.
 
 ## Boundaries
 
 - Produce or revise one Markdown Source Plan. If it does not fit in one response, continue the same document instead of inventing extra Outcomes or plans.
-- Preserve the original meaning and every material qualifier from the user's discussion, research and supplied source material.
+- Preserve the original meaning and every material qualifier from the user's discussion, research and every supplied artifact.
+- Do not require the user to pre-normalize inputs or restate content already available in an attachment.
 - Do not update `project_context/**` or treat the Source Plan as durable project Context.
 - Do not independently turn current repository implementation into product intent. If supplied repository or Context evidence is relevant, cite it and distinguish durable constraints from incidental code shape.
 - Do not bind owners, files, runners, verification inputs, proof surfaces or Assertion observations for a real repository. Later Contract authoring owns those bindings.
@@ -30,15 +31,35 @@ Record every product, technical and acceptance meaning that later work must not
 - Use `context_product_plan` separately when a Tiny Context project needs product decisions classified and written as durable facts in `project_context/**`. This Skill does not replace or invoke that responsibility.
 - Use `long-task-workflow` later to read ordinary Source or a Source Plan with real Context/repository evidence, author one Delivery Contract, bind owners/paths/runners/proof, implement and run the Live Final Gate.
 
+## Intake Modes And Source Coverage
+
+Infer the working mode without asking the user to choose it:
+
+- **Refinement mode:** preserve and improve one substantially complete plan.
+- **Synthesis mode:** turn a goal plus mixed notes, documents, images, diagrams, tables or examples into a new plan.
+- **Hybrid mode:** use an existing plan as the backbone and fill its gaps from the remaining artifacts.
+
+A short request is sufficient when it identifies the artifact roles, states the product or delivery goal, explains whether references are exact targets or inspiration and asks for synthesis, refinement or elaboration. Do not require a questionnaire or a pre-existing outline. Ask only when a supplied artifact cannot be accessed or when a blocking choice falls outside the delegated expansion boundary.
+
+Before authoring:
+
+1. Assign every supplied artifact a stable input ID and inspect it with format-appropriate capabilities. Cover all pages, frames, screens, tables, diagrams, annotations and visible states that can carry material meaning; never silently sample a multi-part artifact.
+2. Classify each input as user instruction, authoritative product requirement, authoritative technical constraint, existing plan, repository/Context evidence, reference or inspiration. User-stated precedence wins; otherwise report material conflicts as `DEC` instead of merging them silently.
+3. For screenshots or visual references, inventory visible surfaces, regions, controls, content hierarchy, navigation cues and represented states. Treat them as inspiration rather than an exact reproduction target unless the user says otherwise; do not import unrelated branding, sample data or product scope.
+4. Record an Input Inventory in the Source Plan with each input ID, role, authority, material content incorporated and any unreadable or intentionally unused portion. The inventory is traceability, not a new semantic type or authority.
+5. Make the resulting plan self-contained: incorporate every material requirement or constraint into a keyed item. Keep an external artifact reference only when the artifact itself remains necessary for exact visual, legal or other non-textual comparison.
+
 ## Authoring Workflow
 
-1. Inventory every material source statement, including constraints, exceptions, examples that change meaning and already-decided controls or recovery behavior.
+1. Build the complete Input Inventory and extract every material statement, including constraints, exceptions, examples that change meaning and already-decided controls or recovery behavior.
 2. Preserve direct requirements before reorganizing them. Never compress several distinct requirements into a broad capability statement that loses qualifiers.
-3. Classify every addition as `direct`, `derived`, evidence-backed repository/Context information, or `decision_required`.
-4. Define Outcomes only where observable results can be independently judged and later mapped to Requirements and acceptance.
-5. Assign stable semantic keys and explicit anchors to important items.
-6. Write product requirements, applicable flows/states, meaningful controls, technical obligations, implementation hints and observable acceptance without hiding new semantics between types.
-7. Run the completeness check, revise the same document and end with a compact status summary.
+3. Classify every material addition as `direct`, `derived`, `delegated`, evidence-backed repository/Context information, or `decision_required`.
+4. Resolve the end-to-end user journey and applicable surfaces before enumerating their regions, controls, states and feedback.
+5. Define Outcomes only where observable results can be independently judged and later mapped to Requirements and acceptance.
+6. Assign stable semantic keys and explicit anchors to important items.
+7. Write product requirements, applicable flows/states, controls, technical obligations, implementation hints and observable acceptance without hiding new semantics between types.
+8. Trace every input to incorporated items or an explicit unused/unreadable disposition.
+9. Run the completeness check, revise the same document and end with a compact readiness summary.
 
 ## Expansion Boundary
 
@@ -59,6 +80,22 @@ For every derived item:
 
 Do not disguise one possible product choice as a necessary derivation.
 
+### Delegated elaboration
+
+When the user explicitly asks the Skill to synthesize, refine, complete, flesh out or use its judgment, treat that as bounded authorization to make coherent, low-impact and reversible product choices needed by the stated goal. Do not stop for minor choices that a competent product author can resolve from the supplied evidence and familiar interaction conventions.
+
+Typical delegated choices include information hierarchy, screen grouping, navigation between already requested capabilities, control placement and labels, input validation implied by the data, non-destructive loading/empty/error/retry feedback, and representative content needed to make acceptance falsifiable.
+
+For every delegated item or tightly coupled group:
+
+- mark it `delegated`;
+- state `Delegated By`, citing the user's authoring instruction;
+- state `Basis`, citing the relevant input IDs, constraints or convention;
+- state why the choice is coherent and what product meaning it adds;
+- keep it within the stated goal and do not contradict a higher-authority input.
+
+Delegation does not authorize unsupported permissions or roles, destructive or irreversible behavior, pricing/quota/budget rules, legal or security policy, persistent-data retention, external automation, business thresholds, platform support scope or sample-versus-full-population scope. These remain `DEC` unless directly decided by an authoritative input.
+
 ### Repository or Context evidence
 
 When supplied project evidence establishes an existing module boundary, state model, interface constraint, component system or verification entry, record the evidence and its source. Do not promote incidental current implementation into a product requirement.
@@ -67,9 +104,9 @@ Leave real owner/path/binding/runner selection to later repository-aware Contrac
 
 ### New product semantics
 
-Use a `DEC` item with status `decision_required` whenever more than one materially different choice remains or the sources do not authorize a decision.
+Use a `DEC` item with status `decision_required` whenever more than one materially different choice remains and neither direct evidence nor the delegated elaboration boundary authorizes a choice.
 
-Never silently choose:
+Never choose without a direct or recorded delegated basis:
 
 - a new user capability or changed business rule;
 - a default, threshold, range or metric;
@@ -128,9 +165,9 @@ Use only the types that apply.
 | `OUT` | Independently decidable observable result | Outcome |
 | `REQ` | Required product or system behavior | Requirement |
 | `CTRL` | Decided control task, placement or state | Control |
-| `OBL` | Mandatory technical obligation | Technical obligation |
-| `NCOMP` | Explicit result that must not be treated as completion | Non-completing Claim |
-| `AC` | Falsifiable observable acceptance scenario | Acceptance Assertion |
+| `OBL` | Mandatory technical obligation | Technical obligation |
+| `NCOMP` | Explicit result that must not be treated as completion | Non-completing Claim |
+| `AC` | Falsifiable observable acceptance scenario | Acceptance Assertion |
 | `NG` | Explicit non-goal | Non-goal |
 | `FS` | Forbidden shortcut or disallowed result | Forbidden shortcut |
 | `RISK` | Fact that changes design, verification or recovery | Risk fact |
@@ -140,9 +177,11 @@ Use only the types that apply.
 
 Keep `OBL` and `HINT` distinct: an `OBL` must be satisfied; a `HINT` may be replaced by another valid implementation.
 
-## Controls And States
+## Product Surfaces, Controls And States
 
-Do not force every Source Plan to define every control.
+Do not force a non-interface Source Plan to invent controls. For an in-scope interactive product, however, enumerate every user-visible surface and every material interactive control at control level; a broad feature or screen name is not enough.
+
+For each surface, state its purpose, entry and exit, persistent navigation, major regions, overlays or transient layers, and the Control keys it contains. Treat buttons, links, fields, selectors, tabs, toggles, menus, list or card actions, map or canvas gestures and other actionable elements as controls. Treat material status, validation, permission and recovery feedback as Control fields or independently keyed Requirements rather than decorative prose.
 
 Include a `CTRL` when:
 
@@ -150,17 +189,17 @@ Include a `CTRL` when:
 - its location, task or state changes product meaning;
 - leaving it open would permit materially different product designs.
 
-For each included control, state every independently decided field separately: `Location`, `User task`, `Trigger`, `Input`, `Loading`, `Empty`, `Success`, `Failure` and `Feedback`. Use `not applicable` when a field was considered and genuinely does not apply; do not hide an undecided product choice behind that phrase. Preserve permission and recovery states separately when they genuinely apply.
-
-Give every decided Control field its own stable semantic meaning. Do not compress location, trigger, input, loading, empty, success, failure or feedback into one broad sentence when more than one field has been decided; later repository-aware authoring must be able to map each field independently.
+For each included control, state every independently decided field separately: `Surface`, `Region`, `Control type`, `Label/content`, `Location`, `User task`, `Visibility`, `Availability`, `Trigger`, `Input`, `Validation`, `Default`, `Interaction`, `Navigation/result`, `Loading`, `Empty`, `Success`, `Failure`, `Recovery`, `Permission`, `Feedback` and `Accessibility`. Use `not applicable` when a field was considered and genuinely does not apply; do not hide an undecided product choice behind that phrase.
+
+Give every decided Control field its own stable semantic meaning. Do not compress placement, behavior, state or feedback into one broad sentence when more than one field has been decided; later repository-aware authoring must be able to map each field independently. Do not claim exact visual styling, animation, copy or responsive behavior unless it is direct, evidence-backed or within recorded delegation.
 
 ## Acceptance Scenarios
 
-Write `AC` items as observable behavior, not low-level test commands.
-
-Each `AC` represents exactly one acceptance scenario and explicitly names the `REQ`, `CTRL`, `OBL` and/or `NCOMP` keys it accepts. It contains one `Given`, one `When` and one `Then`; each may be multiline, but together they describe only one independently decidable scenario. Never label one AC as proof for several materially different success, failure, boundary or recovery scenarios; author separate ACs instead.
+Write `AC` items as observable behavior, not low-level test commands.
 
-For every important `REQ`, provide at least one of:
+Each `AC` represents exactly one acceptance scenario and explicitly names the `REQ`, `CTRL`, `OBL` and/or `NCOMP` keys it accepts. It contains one `Given`, one `When` and one `Then`; each may be multiline, but together they describe only one independently decidable scenario. Never label one AC as proof for several materially different success, failure, boundary or recovery scenarios; author separate ACs instead.
+
+For every important `REQ` and every material `CTRL` state, provide at least one of:
 
 - a corresponding `AC`;
 - an `EXT`;
@@ -170,30 +209,30 @@ For every important `REQ`, provide at least one of:
 
 Cover the scenarios that actually exist: success, failure, boundary, recovery, permission, empty state, sample/full-population scope and forbidden results. Do not mechanically generate a fixed scenario set.
 
-Never introduce a product requirement for the first time inside an `AC`. Move hidden behavior, defaults, retention periods or recovery policies into a source-backed `REQ` or unresolved `DEC`.
-
-## Risk And Advisory Boundaries
-
-Each `RISK` states `Fact`, `Affected Outcome`, `Basis` and `Consequence`. `Fact` uses one exact name from the complete Runtime Risk Fact set:
-
-```text
-public_api_or_schema_change
-persistent_data_change
-data_migration
-security_boundary_change
-permission_boundary_change
-irreversible_external_effect
-critical_user_path
-full_population_operation
-multi_repository_change
-weak_observability
-```
-
-Do not invent or accept aliases. A data migration uses `data_migration`, never `migration`. A critical path with weak observability produces two independent `RISK` items with distinct stable keys: one `critical_user_path` and one `weak_observability`, both naming the affected Outcome. Preserve `multi_repository_change` in Source even though the current Runtime rejects multi-repository delivery; the Compiler owns that unsupported-delivery decision. Each risk item names one affected Outcome; repeat the item with a distinct stable key when the same fact affects multiple Outcomes. If Fact or Affected Outcome cannot be determined from Source, create a `DEC` with `decision_required` instead of guessing. Generic risk prose without an affected Outcome is not actionable Source. `HINT` remains advisory and is never a Material Source Item: promote it to `OBL` if the implementation constraint is mandatory.
-
-Use `NCOMP` for an explicit, source-authoritative statement that names an outcome or shortcut that must not count as completion. It is neither an ordinary Requirement nor a non-goal: later Contract authoring maps it to a non-completing Claim and must provide negative or Counterfactual proof.
-
-This Skill emits ordinary Markdown only. Do not emit `ty-source-item` markers; repository-aware `/long-task-workflow` inserts those non-rendering markers later without rewriting the selected Source text.
+Never introduce a product requirement for the first time inside an `AC`. Move hidden behavior, defaults, retention periods or recovery policies into a source-backed `REQ` or unresolved `DEC`.
+
+## Risk And Advisory Boundaries
+
+Each `RISK` states `Fact`, `Affected Outcome`, `Basis` and `Consequence`. `Fact` uses one exact name from the complete Runtime Risk Fact set:
+
+```text
+public_api_or_schema_change
+persistent_data_change
+data_migration
+security_boundary_change
+permission_boundary_change
+irreversible_external_effect
+critical_user_path
+full_population_operation
+multi_repository_change
+weak_observability
+```
+
+Do not invent or accept aliases. A data migration uses `data_migration`, never `migration`. A critical path with weak observability produces two independent `RISK` items with distinct stable keys: one `critical_user_path` and one `weak_observability`, both naming the affected Outcome. Preserve `multi_repository_change` in Source even though the current Runtime rejects multi-repository delivery; the Compiler owns that unsupported-delivery decision. Each risk item names one affected Outcome; repeat the item with a distinct stable key when the same fact affects multiple Outcomes. If Fact or Affected Outcome cannot be determined from Source, create a `DEC` with `decision_required` instead of guessing. Generic risk prose without an affected Outcome is not actionable Source. `HINT` remains advisory and is never a Material Source Item: promote it to `OBL` if the implementation constraint is mandatory.
+
+Use `NCOMP` for an explicit, source-authoritative statement that names an outcome or shortcut that must not count as completion. It is neither an ordinary Requirement nor a non-goal: later Contract authoring maps it to a non-completing Claim and must provide negative or Counterfactual proof.
+
+This Skill emits ordinary Markdown only. Do not emit `ty-source-item` markers; repository-aware `/long-task-workflow` inserts those non-rendering markers later without rewriting the selected Source text.
 
 ## Default Markdown Structure
 
@@ -216,7 +255,14 @@ Write in the user's language unless requested otherwise.
 - Why this delivery is needed
 - Known constraints
 
-## 3. Delivery Scope
+## 3. Input Inventory And Interpretation
+
+- Input ID
+- Role and authority
+- Material content incorporated
+- Unreadable or intentionally unused content
+
+## 4. Delivery Scope
 
 ### In Scope
 
@@ -224,13 +270,19 @@ Write in the user's language unless requested otherwise.
 
 ### Forbidden Shortcuts
 
-## 4. Outcome Overview
+## 5. Product Surface Inventory
+
+- Surface purpose
+- Entry, exit and navigation
+- Regions, overlays and Control keys
+
+## 6. Outcome Overview
 
 - Outcome key
 - Observable result
 - Dependencies
 
-## 5. Outcomes
+## 7. Outcomes
 
 <a id="outcome.<outcome-key>"></a>
 
@@ -243,7 +295,17 @@ Write in the user's language unless requested otherwise.
 <a id="<outcome-key>.requirement.<requirement-key>"></a>
 
 - **REQ `<requirement-key>`**
-  ...
+  - Origin: direct | derived | delegated | evidence-backed
+  - Source basis:
+  - Requirement:
+
+#### Surface And Region Model
+
+- Surface:
+- Purpose:
+- Entry / exit:
+- Regions / overlays:
+- Included Control keys:
 
 #### User Flow And States
 
@@ -257,27 +319,42 @@ Write in the user's language unless requested otherwise.
 <a id="<outcome-key>.control.<control-key>"></a>
 
 - **CTRL `<control-key>`**
+  - Origin: direct | derived | delegated | evidence-backed
+  - Source basis:
+  - Surface:
+  - Region:
+  - Control type:
+  - Label/content:
   - Location:
   - User task:
-      - Trigger:
-      - Input:
-      - Loading:
-      - Empty:
-      - Success:
-      - Failure:
-      - Feedback:
+  - Visibility:
+  - Availability:
+  - Trigger:
+  - Input:
+  - Validation:
+  - Default:
+  - Interaction:
+  - Navigation/result:
+  - Loading:
+  - Empty:
+  - Success:
+  - Failure:
+  - Recovery:
+  - Permission:
+  - Feedback:
+  - Accessibility:
 
 #### Technical Obligations And Boundaries
 
 <a id="<outcome-key>.obligation.<obligation-key>"></a>
 
-- **OBL `<obligation-key>`**
-  ...
-
-<a id="<outcome-key>.non-completing.<non-completing-key>"></a>
-
-- **NCOMP `<non-completing-key>`**
-  ...
+- **OBL `<obligation-key>`**
+  ...
+
+<a id="<outcome-key>.non-completing.<non-completing-key>"></a>
+
+- **NCOMP `<non-completing-key>`**
+  ...
 
 #### Implementation Hints
 
@@ -288,34 +365,35 @@ Write in the user's language unless requested otherwise.
 
 <a id="<outcome-key>.acceptance.<acceptance-key>"></a>
 
-- **AC `<acceptance-key>`**
-  - Accepts: REQ `<key>`, CTRL `<key>`, OBL `<key>`, NCOMP `<key>`
-  - Given:
+- **AC `<acceptance-key>`**
+  - Accepts: REQ `<key>`, CTRL `<key>`, OBL `<key>`, NCOMP `<key>`
+  - Given:
   - When:
   - Then:
 
-#### Risks And Recovery
-
-<a id="<outcome-key>.risk.<risk-key>"></a>
-
-- **RISK `<risk-key>`**
-  - Fact:
-  - Affected Outcome:
-  - Basis:
-  - Consequence:
+#### Risks And Recovery
+
+<a id="<outcome-key>.risk.<risk-key>"></a>
+
+- **RISK `<risk-key>`**
+  - Fact:
+  - Affected Outcome:
+  - Basis:
+  - Consequence:
 
-## 6. Cross-Outcome Constraints
+## 8. Cross-Outcome Constraints
 
-## 7. External Confirmations
+## 9. External Confirmations
 
-## 8. Derived Content And Sources
+## 10. Source Traceability And Authoring Decisions
 
-- Derived Item:
-- Derived From:
-- Reason:
-- Changes product meaning: no
+- Item or group:
+- Origin: direct | derived | delegated | evidence-backed
+- Source / Derived From / Delegated By:
+- Basis and reason:
+- Changes product meaning: no for derived; yes or no for delegated
 
-## 9. Decisions Required
+## 11. Decisions Required
 
 <a id="decision.<decision-key>"></a>
 
@@ -326,7 +404,7 @@ Write in the user's language unless requested otherwise.
   - Why it cannot be reliably derived:
   - Affected REQ / AC:
 
-## 10. Completeness Check
+## 12. Completeness Check
 
 - Covered core requirements
 - Unresolved product semantics
@@ -340,27 +418,37 @@ Before returning the plan, verify:
 
 1. Every material original requirement is preserved.
 2. Distinct requirements were not collapsed into one vague Outcome.
-3. Every `REQ` has an `AC`, `EXT`, `DEC` or explicit exception.
-4. Every declared `CTRL` independently states Location, User task, Trigger, Input, Loading, Empty, Success, Failure and Feedback.
-5. Every `OBL` is mandatory rather than a suggestion.
-6. No `AC` introduces undeclared product semantics.
-7. Every derived item identifies its basis.
-8. Multiple reasonable product choices remain decisions rather than silent model choices.
-9. Sample, framework, representative validation and full population are not confused.
-10. Partial implementation is not worded as full completion.
-11. Non-goals and forbidden shortcuts are explicit.
-12. Risks concretely affect scope, verification or recovery rather than repeat a generic template.
-13. No unsupported number, threshold, metric or conclusion appears.
-14. Every `AC` names accepted `REQ`/`CTRL`/`OBL`/`NCOMP` keys and contains exactly one Given/When/Then scenario.
-15. Every `NCOMP` is an explicit source meaning rather than a restated Requirement or non-goal.
-16. Every `RISK` has one exact Fact, one Affected Outcome, Basis and Consequence; ambiguity is a `DEC`.
-17. Every decided control field remains independently traceable instead of being compressed into an aggregate state sentence.
+3. Every supplied artifact appears in the Input Inventory with complete coverage or an explicit gap/disposition.
+4. Every material input statement maps to a keyed plan item or an explicit unused/conflict disposition.
+5. Every `REQ` and material `CTRL` state has an `AC`, `EXT`, `DEC` or explicit exception.
+6. Every in-scope interactive surface has purpose, entry/exit, regions and contained Control keys.
+7. Every material interactive control is independently enumerated with applicable placement, behavior, state, feedback and accessibility fields.
+8. Every declared `CTRL` independently states Surface, Region, Control type, Label/content, Location, User task, Visibility, Availability, Trigger, Input, Validation, Default, Interaction, Navigation/result, Loading, Empty, Success, Failure, Recovery, Permission, Feedback and Accessibility.
+9. Every `OBL` is mandatory rather than a suggestion.
+10. No `AC` introduces undeclared product semantics.
+11. Every derived item identifies its basis and changes no user capability, business rule or product scope.
+12. Every delegated item identifies `Delegated By`, its evidence basis and the product meaning it adds.
+13. Delegated choices stay within the low-impact reversible boundary; reserved or conflicting choices remain `DEC`.
+14. Multiple reasonable choices outside recorded delegation remain decisions rather than silent model choices.
+15. Reference or inspiration inputs are not treated as exact targets unless the user requested that authority.
+16. Sample, framework, representative validation and full population are not confused.
+17. Partial implementation is not worded as full completion.
+18. Non-goals and forbidden shortcuts are explicit.
+19. Risks concretely affect scope, verification or recovery rather than repeat a generic template.
+20. No unsupported number, threshold, metric or conclusion appears.
+21. Every `AC` names accepted `REQ`/`CTRL`/`OBL`/`NCOMP` keys and contains exactly one Given/When/Then scenario.
+22. Every `NCOMP` is an explicit source meaning rather than a restated Requirement or non-goal.
+23. Every `RISK` has one exact Fact, one Affected Outcome, Basis and Consequence; ambiguity is a `DEC`.
+24. Every decided control field remains independently traceable instead of being compressed into an aggregate state sentence.
+25. The document contains enough incorporated meaning for later Contract authoring without requiring the original conversation; any still-required external artifact is named explicitly.
 
 Do not emit a matrix or machine gate. End with:
 
 ```text
 Completeness status:
-- Ready for further refinement: yes|no
+- Ready for Contract authoring: yes|no
+- Input coverage gaps: none|...
+- Surface/control coverage: complete|not applicable|...
 - Decisions required: DEC-...
 - Advisory implementation hints: HINT-...
 - Unbound project facts: ...

package/package.json

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