project-tiny-context-harness 0.8.4 → 0.8.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (254) hide show
  1. package/LICENSE +21 -21
  2. package/README.md +394 -363
  3. package/assets/README.md +570 -514
  4. package/assets/README.zh-CN.md +331 -300
  5. package/assets/agents/.gitkeep +1 -1
  6. package/assets/agents/AGENTS_CORE.md +45 -25
  7. package/assets/context_templates/architecture.md +26 -25
  8. package/assets/context_templates/area.md +32 -31
  9. package/assets/context_templates/context.toml +30 -24
  10. package/assets/context_templates/deployment.md +35 -35
  11. package/assets/context_templates/global.md +57 -57
  12. package/assets/context_templates/product-surface-contract.md +70 -70
  13. package/assets/context_templates/screen-contract.md +189 -189
  14. package/assets/context_templates/verification.md +31 -30
  15. package/assets/github/.gitkeep +1 -1
  16. package/assets/github/harness.yml +39 -39
  17. package/assets/make/.gitkeep +1 -1
  18. package/assets/make/ty-context.mk +48 -48
  19. package/assets/skills/context_development_engineer/SKILL.md +155 -122
  20. package/assets/skills/context_full_project_export/SKILL.md +28 -28
  21. package/assets/skills/context_harness_upgrade/SKILL.md +60 -60
  22. package/assets/skills/context_product_plan/SKILL.md +99 -79
  23. package/assets/skills/context_surface_contract/SKILL.md +191 -191
  24. package/assets/skills/context_uiux_design/SKILL.md +171 -171
  25. package/assets/skills/design-resource-authoring/SKILL.md +86 -84
  26. package/assets/skills/design-resource-authoring/references/downstream-handoff.md +138 -123
  27. package/assets/skills/design-resource-authoring/references/open-design-provider.md +132 -127
  28. package/assets/skills/design-resource-authoring/references/resource-selection.md +181 -154
  29. package/assets/skills/design-system-authoring/SKILL.md +57 -57
  30. package/assets/skills/design-system-authoring/agents/openai.yaml +6 -6
  31. package/assets/skills/design-system-authoring/references/authority-adoption.md +48 -48
  32. package/assets/skills/design-system-authoring/references/open-design-design-system-provider.md +110 -110
  33. package/assets/skills/long-task-workflow/SKILL.md +98 -92
  34. package/assets/skills/long-task-workflow/agents/openai.yaml +3 -1
  35. package/assets/skills/long-task-workflow/references/authority-lifecycle.md +72 -72
  36. package/assets/skills/long-task-workflow/references/contract-authoring.md +122 -101
  37. package/assets/skills/long-task-workflow/references/evidence-design.md +82 -61
  38. package/assets/skills/long-task-workflow/references/source-authoring.md +109 -90
  39. package/assets/skills/source-plan-authoring/SKILL.md +14 -14
  40. package/assets/tools/validate_context.py +442 -442
  41. package/dist/commands/long-task-authoring.js +27 -2
  42. package/dist/lib/context-default-footprint.js +2 -0
  43. package/dist/lib/context-manifest.js +6 -0
  44. package/dist/lib/context-templates.js +1 -1
  45. package/dist/lib/design-resource-fact-enums.d.ts +20 -0
  46. package/dist/lib/design-resource-fact-enums.js +170 -0
  47. package/dist/lib/design-resource-fact-locator-extractors.d.ts +8 -0
  48. package/dist/lib/design-resource-fact-locator-extractors.js +108 -0
  49. package/dist/lib/design-resource-fact-locator-resolver.d.ts +3 -0
  50. package/dist/lib/design-resource-fact-locator-resolver.js +112 -0
  51. package/dist/lib/design-resource-fact-locator-validation.d.ts +5 -0
  52. package/dist/lib/design-resource-fact-locator-validation.js +16 -0
  53. package/dist/lib/design-resource-fact-manifest-catalog.d.ts +4 -0
  54. package/dist/lib/design-resource-fact-manifest-catalog.js +249 -0
  55. package/dist/lib/design-resource-fact-manifest-model.d.ts +91 -0
  56. package/dist/lib/design-resource-fact-manifest-model.js +21 -0
  57. package/dist/lib/design-resource-fact-manifest-shape-axes.d.ts +6 -0
  58. package/dist/lib/design-resource-fact-manifest-shape-axes.js +159 -0
  59. package/dist/lib/design-resource-fact-manifest-shape-evidence.d.ts +4 -0
  60. package/dist/lib/design-resource-fact-manifest-shape-evidence.js +59 -0
  61. package/dist/lib/design-resource-fact-manifest-shape-facts.d.ts +4 -0
  62. package/dist/lib/design-resource-fact-manifest-shape-facts.js +109 -0
  63. package/dist/lib/design-resource-fact-manifest-shape-inspector.d.ts +5 -0
  64. package/dist/lib/design-resource-fact-manifest-shape-inspector.js +144 -0
  65. package/dist/lib/design-resource-fact-manifest-shape.d.ts +7 -0
  66. package/dist/lib/design-resource-fact-manifest-shape.js +75 -0
  67. package/dist/lib/design-resource-fact-manifest-types.d.ts +3 -0
  68. package/dist/lib/design-resource-fact-manifest-types.js +3 -0
  69. package/dist/lib/design-resource-fact-manifest-universe.d.ts +5 -0
  70. package/dist/lib/design-resource-fact-manifest-universe.js +50 -0
  71. package/dist/lib/design-resource-fact-manifest-validation.d.ts +3 -0
  72. package/dist/lib/design-resource-fact-manifest-validation.js +106 -0
  73. package/dist/lib/design-resource-fact-policy.d.ts +18 -0
  74. package/dist/lib/design-resource-fact-policy.js +72 -1
  75. package/dist/lib/design-resource-fact-property-methods.d.ts +3 -0
  76. package/dist/lib/design-resource-fact-property-methods.js +158 -0
  77. package/dist/lib/design-resource-fact-shape-primitives.d.ts +3 -0
  78. package/dist/lib/design-resource-fact-shape-primitives.js +18 -0
  79. package/dist/lib/design-resource-fact-types.d.ts +164 -0
  80. package/dist/lib/design-resource-fact-types.js +1 -0
  81. package/dist/lib/design-resource-fact-universe-assets.d.ts +4 -0
  82. package/dist/lib/design-resource-fact-universe-assets.js +71 -0
  83. package/dist/lib/design-resource-fact-universe-catalog.d.ts +4 -0
  84. package/dist/lib/design-resource-fact-universe-catalog.js +151 -0
  85. package/dist/lib/design-resource-fact-universe-conditions.d.ts +2 -0
  86. package/dist/lib/design-resource-fact-universe-conditions.js +92 -0
  87. package/dist/lib/design-resource-fact-universe-facts.d.ts +4 -0
  88. package/dist/lib/design-resource-fact-universe-facts.js +108 -0
  89. package/dist/lib/design-resource-fact-universe-helpers.d.ts +30 -0
  90. package/dist/lib/design-resource-fact-universe-helpers.js +167 -0
  91. package/dist/lib/design-resource-fact-universe-inspector.d.ts +7 -0
  92. package/dist/lib/design-resource-fact-universe-inspector.js +119 -0
  93. package/dist/lib/design-resource-fact-universe-proof.d.ts +4 -0
  94. package/dist/lib/design-resource-fact-universe-proof.js +113 -0
  95. package/dist/lib/design-resource-fact-universe-subjects.d.ts +5 -0
  96. package/dist/lib/design-resource-fact-universe-subjects.js +97 -0
  97. package/dist/lib/design-resource-fact-universe-variations.d.ts +2 -0
  98. package/dist/lib/design-resource-fact-universe-variations.js +75 -0
  99. package/dist/lib/design-resource-fact-value-validation.d.ts +2 -0
  100. package/dist/lib/design-resource-fact-value-validation.js +80 -0
  101. package/dist/lib/design-resource-handoff-file-primitives.js +2 -0
  102. package/dist/lib/design-resource-handoff-file-validation.js +13 -100
  103. package/dist/lib/design-resource-handoff-policy.d.ts +1 -0
  104. package/dist/lib/design-resource-handoff-policy.js +118 -11
  105. package/dist/lib/design-resource-handoff-shape-evidence.js +46 -3
  106. package/dist/lib/design-resource-handoff-shape-primitives.d.ts +5 -0
  107. package/dist/lib/design-resource-handoff-shape-primitives.js +28 -0
  108. package/dist/lib/design-resource-handoff-shape-structure.js +143 -22
  109. package/dist/lib/design-resource-handoff-shape.js +25 -0
  110. package/dist/lib/design-resource-handoff-types.d.ts +97 -21
  111. package/dist/lib/design-resource-handoff-types.js +22 -0
  112. package/dist/lib/design-resource-handoff-validation-coverage.d.ts +1 -1
  113. package/dist/lib/design-resource-handoff-validation-coverage.js +145 -118
  114. package/dist/lib/design-resource-handoff-validation-fact-cells.d.ts +2 -0
  115. package/dist/lib/design-resource-handoff-validation-fact-cells.js +60 -0
  116. package/dist/lib/design-resource-handoff-validation-fact-records.d.ts +2 -0
  117. package/dist/lib/design-resource-handoff-validation-fact-records.js +90 -0
  118. package/dist/lib/design-resource-handoff-validation-facts.js +10 -94
  119. package/dist/lib/design-resource-handoff-validation-proofs.d.ts +2 -0
  120. package/dist/lib/design-resource-handoff-validation-proofs.js +67 -0
  121. package/dist/lib/design-resource-handoff-validation-resource-closure.d.ts +3 -0
  122. package/dist/lib/design-resource-handoff-validation-resource-closure.js +88 -0
  123. package/dist/lib/design-resource-handoff-validation-structure.js +43 -14
  124. package/dist/lib/design-resource-handoff-validation.js +32 -0
  125. package/dist/lib/design-resource-handoff-web-dependency-validation.d.ts +2 -1
  126. package/dist/lib/design-resource-handoff-web-dependency-validation.js +67 -7
  127. package/dist/lib/execution-target-capabilities.d.ts +1 -1
  128. package/dist/lib/execution-target-capabilities.js +14 -0
  129. package/dist/lib/long-task-activation-validation.js +6 -2
  130. package/dist/lib/long-task-applicability-shape.js +3 -3
  131. package/dist/lib/long-task-authoring-authority-preview.js +1 -0
  132. package/dist/lib/long-task-authority-policy.d.ts +1 -0
  133. package/dist/lib/long-task-authority-policy.js +1 -0
  134. package/dist/lib/long-task-authority.js +13 -0
  135. package/dist/lib/long-task-claim-definitions.js +13 -1
  136. package/dist/lib/long-task-claims.js +23 -1
  137. package/dist/lib/long-task-contract-types.d.ts +3 -0
  138. package/dist/lib/long-task-delivery-compiler.js +1 -0
  139. package/dist/lib/long-task-delivery-parser.js +11 -1
  140. package/dist/lib/long-task-delivery-types.d.ts +1 -0
  141. package/dist/lib/long-task-delivery-types.js +1 -0
  142. package/dist/lib/long-task-delivery-validation.js +17 -0
  143. package/dist/lib/long-task-design-resource-handoff.js +62 -38
  144. package/dist/lib/long-task-design-target-capabilities.d.ts +14 -0
  145. package/dist/lib/long-task-design-target-capabilities.js +126 -0
  146. package/dist/lib/long-task-evidence-capability-codec.d.ts +94 -0
  147. package/dist/lib/long-task-evidence-capability-codec.js +395 -22
  148. package/dist/lib/long-task-evidence-capability-policy.js +18 -0
  149. package/dist/lib/long-task-evidence-capability-runtime.js +78 -0
  150. package/dist/lib/long-task-evidence-capability-types.d.ts +114 -1
  151. package/dist/lib/long-task-outcome-parser.js +4 -0
  152. package/dist/lib/long-task-playwright-capability-records.d.ts +5 -0
  153. package/dist/lib/long-task-playwright-capability-records.js +146 -0
  154. package/dist/lib/long-task-playwright-case-evidence.d.ts +3 -2
  155. package/dist/lib/long-task-playwright-case-evidence.js +10 -79
  156. package/dist/lib/long-task-playwright-case-primitives.d.ts +28 -0
  157. package/dist/lib/long-task-playwright-case-primitives.js +143 -0
  158. package/dist/lib/long-task-playwright-evidence.d.ts +1 -1
  159. package/dist/lib/long-task-playwright-evidence.js +10 -75
  160. package/dist/lib/long-task-runner-freeze.d.ts +2 -2
  161. package/dist/lib/long-task-runner-freeze.js +15 -1
  162. package/dist/lib/long-task-runtime-types.d.ts +4 -1
  163. package/dist/lib/long-task-semantic-contract-types.d.ts +1 -1
  164. package/dist/lib/long-task-semantic-drift-migration.js +2 -2
  165. package/dist/lib/long-task-semantic-fact-binding-types.d.ts +57 -0
  166. package/dist/lib/long-task-semantic-fact-binding-types.js +1 -0
  167. package/dist/lib/long-task-semantic-fact-closure-primitives.d.ts +5 -0
  168. package/dist/lib/long-task-semantic-fact-closure-primitives.js +43 -0
  169. package/dist/lib/long-task-semantic-fact-closure.d.ts +13 -0
  170. package/dist/lib/long-task-semantic-fact-closure.js +48 -0
  171. package/dist/lib/long-task-semantic-fact-contract-closure.d.ts +4 -0
  172. package/dist/lib/long-task-semantic-fact-contract-closure.js +24 -0
  173. package/dist/lib/long-task-semantic-fact-contract-facts.d.ts +4 -0
  174. package/dist/lib/long-task-semantic-fact-contract-facts.js +30 -0
  175. package/dist/lib/long-task-semantic-fact-contract-proofs.d.ts +4 -0
  176. package/dist/lib/long-task-semantic-fact-contract-proofs.js +97 -0
  177. package/dist/lib/long-task-semantic-fact-evidence.d.ts +21 -0
  178. package/dist/lib/long-task-semantic-fact-evidence.js +165 -0
  179. package/dist/lib/long-task-semantic-fact-input-closure.d.ts +4 -0
  180. package/dist/lib/long-task-semantic-fact-input-closure.js +101 -0
  181. package/dist/lib/long-task-semantic-fact-provenance-closure.d.ts +4 -0
  182. package/dist/lib/long-task-semantic-fact-provenance-closure.js +140 -0
  183. package/dist/lib/long-task-semantic-fact-shape.d.ts +3 -0
  184. package/dist/lib/long-task-semantic-fact-shape.js +89 -0
  185. package/dist/lib/long-task-semantic-fact-value-closure.d.ts +3 -0
  186. package/dist/lib/long-task-semantic-fact-value-closure.js +110 -0
  187. package/dist/lib/long-task-shape-primitives.d.ts +2 -1
  188. package/dist/lib/long-task-shape-primitives.js +7 -0
  189. package/dist/lib/long-task-source-item-parser.js +25 -6
  190. package/dist/lib/long-task-source-target-continuity.js +4 -1
  191. package/dist/lib/long-task-source-target-index.d.ts +1 -1
  192. package/dist/lib/long-task-source-target-index.js +5 -1
  193. package/dist/lib/long-task-ui-design-policy.js +8 -4
  194. package/dist/lib/long-task-ui-surface-shape.js +83 -1
  195. package/dist/lib/long-task-ui-surface-types.d.ts +29 -0
  196. package/dist/lib/modularity.js +7 -1
  197. package/dist/lib/semantic-fact-base-types.d.ts +14 -0
  198. package/dist/lib/semantic-fact-base-types.js +1 -0
  199. package/dist/lib/semantic-fact-catalog.d.ts +8 -0
  200. package/dist/lib/semantic-fact-catalog.js +191 -0
  201. package/dist/lib/semantic-fact-condition-shape.d.ts +48 -0
  202. package/dist/lib/semantic-fact-condition-shape.js +111 -0
  203. package/dist/lib/semantic-fact-input-shape.d.ts +34 -0
  204. package/dist/lib/semantic-fact-input-shape.js +111 -0
  205. package/dist/lib/semantic-fact-inventory-types.d.ts +147 -0
  206. package/dist/lib/semantic-fact-inventory-types.js +1 -0
  207. package/dist/lib/semantic-fact-manifest-shape.d.ts +4 -0
  208. package/dist/lib/semantic-fact-manifest-shape.js +135 -0
  209. package/dist/lib/semantic-fact-manifest-types.d.ts +58 -0
  210. package/dist/lib/semantic-fact-manifest-types.js +19 -0
  211. package/dist/lib/semantic-fact-policy-authority.d.ts +8 -0
  212. package/dist/lib/semantic-fact-policy-authority.js +79 -0
  213. package/dist/lib/semantic-fact-policy-census.d.ts +2 -0
  214. package/dist/lib/semantic-fact-policy-census.js +80 -0
  215. package/dist/lib/semantic-fact-policy-condition-references.d.ts +7 -0
  216. package/dist/lib/semantic-fact-policy-condition-references.js +19 -0
  217. package/dist/lib/semantic-fact-policy-conditions.d.ts +2 -0
  218. package/dist/lib/semantic-fact-policy-conditions.js +105 -0
  219. package/dist/lib/semantic-fact-policy-facts.d.ts +3 -0
  220. package/dist/lib/semantic-fact-policy-facts.js +73 -0
  221. package/dist/lib/semantic-fact-policy-primitives.d.ts +26 -0
  222. package/dist/lib/semantic-fact-policy-primitives.js +169 -0
  223. package/dist/lib/semantic-fact-policy-proofs.d.ts +2 -0
  224. package/dist/lib/semantic-fact-policy-proofs.js +75 -0
  225. package/dist/lib/semantic-fact-policy-properties.d.ts +3 -0
  226. package/dist/lib/semantic-fact-policy-properties.js +84 -0
  227. package/dist/lib/semantic-fact-policy-units.d.ts +4 -0
  228. package/dist/lib/semantic-fact-policy-units.js +103 -0
  229. package/dist/lib/semantic-fact-policy.d.ts +17 -0
  230. package/dist/lib/semantic-fact-policy.js +41 -0
  231. package/dist/lib/semantic-fact-proof-shape.d.ts +51 -0
  232. package/dist/lib/semantic-fact-proof-shape.js +121 -0
  233. package/dist/lib/semantic-fact-proof-types.d.ts +74 -0
  234. package/dist/lib/semantic-fact-proof-types.js +1 -0
  235. package/dist/lib/semantic-fact-property-shape.d.ts +29 -0
  236. package/dist/lib/semantic-fact-property-shape.js +77 -0
  237. package/dist/lib/semantic-fact-shape-constants.d.ts +3 -0
  238. package/dist/lib/semantic-fact-shape-constants.js +38 -0
  239. package/dist/lib/semantic-fact-shape-primitives.d.ts +15 -0
  240. package/dist/lib/semantic-fact-shape-primitives.js +68 -0
  241. package/dist/lib/semantic-fact-source-parser.d.ts +9 -0
  242. package/dist/lib/semantic-fact-source-parser.js +46 -0
  243. package/dist/lib/semantic-fact-support-shape.d.ts +21 -0
  244. package/dist/lib/semantic-fact-support-shape.js +59 -0
  245. package/dist/lib/semantic-fact-types.d.ts +5 -0
  246. package/dist/lib/semantic-fact-types.js +5 -0
  247. package/dist/lib/semantic-fact-unit-shape.d.ts +34 -0
  248. package/dist/lib/semantic-fact-unit-shape.js +89 -0
  249. package/dist/lib/semantic-fact-value-shape.d.ts +12 -0
  250. package/dist/lib/semantic-fact-value-shape.js +39 -0
  251. package/dist/schemas/long-task-delivery-v2/long-task-delivery-v2.schema.json +1339 -131
  252. package/migrations/README.md +15 -15
  253. package/package.json +84 -84
  254. package/source-mappings.yaml +25 -25
@@ -1,86 +1,88 @@
1
- ---
2
- name: design-resource-authoring
3
- description: Use when the user explicitly asks to generate, author, plan, commission, or iterate design resources; use Open Design; create a scoped wireframe, prototype, visual candidate, component/control state study, implementation handoff, or the design resources needed for an explicitly named development scope from raw drafts, product/technical plans, visual briefs, screenshots, or existing design resources; or asks to “生成设计资源”, “使用 Open Design”, “生成原型图”, “生成高保真/低保真设计”, “为开发准备设计资源”, or “先看一个控件/页面效果” in a Minimal Context Harness project. Do not trigger for generic design discussion, UX audits, ordinary UI implementation without an explicit resource request, local CSS fixes, durable Design Authority adoption, initial-proposal authoring itself, or Long-Task execution.
4
- ---
5
-
6
- # Design Resource Authoring
7
-
8
- Commission the smallest sufficient set of design resources for the explicitly requested output or development scope from live Open Design capabilities. For a selected implementation handoff, the default indexing unit is every complete observable design fact exposed by the acquired resource and supported inspector/oracle capability; exact targets additionally require condition-specific full-target layout and pixel facts. This Skill is a thin task-local planner, provider adapter, iteration guide, final proposal reconciler and handoff layer; Open Design owns generation logic and Tiny Context owns neither its prompts nor runtime.
9
-
10
- ## Hard boundaries
11
-
12
- - A raw initial proposal is a valid input. Never require, invoke, regenerate or edit a Source Plan.
13
- - During candidate iteration, keep accepted/rejected/unresolved proposal effects in a task-local delta buffer. Only after a direction is final may this Skill reconcile the initial proposal once. Never continuously rewrite it.
14
- - Proposal reconciliation changes only the initial proposal: never mutate `project_context/**`, `DESIGN.md`, a Source Plan, Delivery Contract, production code or tests as a design-resource side effect.
15
- - Never make a prototype, wireframe, high-fidelity candidate, design-system slice, provider-native file, variant count or directory layout universally mandatory.
16
- - Treat the user's explicit output/development scope as the hard ceiling. Include only the surrounding context needed to design that slice.
1
+ ---
2
+ name: design-resource-authoring
3
+ description: Use when the user explicitly asks to generate, author, plan, commission, or iterate design resources; use Open Design; create a scoped wireframe, prototype, visual candidate, component/control state study, implementation handoff, or the design resources needed for an explicitly named development scope from raw drafts, product/technical plans, visual briefs, screenshots, or existing design resources; or asks to “生成设计资源”, “使用 Open Design”, “生成原型图”, “生成高保真/低保真设计”, “为开发准备设计资源”, or “先看一个控件/页面效果” in a Minimal Context Harness project. Do not trigger for generic design discussion, UX audits, ordinary UI implementation without an explicit resource request, local CSS fixes, durable Design Authority adoption, initial-proposal authoring itself, or Long-Task execution.
4
+ ---
5
+
6
+ # Design Resource Authoring
7
+
8
+ Commission the smallest sufficient set of design resources for the explicitly requested output or development scope from live Open Design capabilities. “Smallest” governs artifact count and surrounding scope, never information granularity. For a formal selected Web/App implementation handoff, first derive the complete material in-scope Expected Fact Universe from requirements, product semantics, adopted design system, target platforms and observable conditions; then require canonical resources to express it and a frozen Inspector to enumerate it. The default identity is one atomic Fact Cell—not a Product Control, page, screenshot, broad dimension row or provider summary—and exact targets additionally require condition-specific full-target layout and pixel facts. This Skill is a thin task-local planner, provider adapter, iteration guide, final proposal reconciler and handoff layer; Open Design owns generation logic and Tiny Context owns neither its prompts nor runtime.
9
+
10
+ ## Hard boundaries
11
+
12
+ - A raw initial proposal is a valid input. Never require, invoke, regenerate or edit a Source Plan.
13
+ - During candidate iteration, keep accepted/rejected/unresolved proposal effects in a task-local delta buffer. Only after a direction is final may this Skill reconcile the initial proposal once. Never continuously rewrite it.
14
+ - Proposal reconciliation changes only the initial proposal: never mutate `project_context/**`, `DESIGN.md`, a Source Plan, Delivery Contract, production code or tests as a design-resource side effect.
15
+ - Never make a prototype, wireframe, high-fidelity candidate, design-system slice, provider-native file, variant count or directory layout universally mandatory.
16
+ - Treat the user's explicit output/development scope as the hard ceiling. Include only the surrounding context needed to design that slice.
17
17
  - Never require one artifact per control. Reuse selected component sources and group repeated controls by family; commission a dedicated study only for unique or complex uncovered meaning.
18
18
  - Do not confuse Product Control granularity with design-fact granularity. An image, text run, icon, component part, smaller visual primitive, layout relation, geometry/style/token/content/state/behavior fact remains independently material when the selected resource expresses it.
19
- - Never infer that a page frame or prototype covers states, responsiveness, accessibility or interaction it does not explicitly specify or demonstrate.
20
- - Exploration and unselected previews stay schema-free. Only a final selected implementation handoff requires the shared strict Markdown adapter; this is input preparation, not a resource pack or acceptance result.
21
- - Design resources may express user-visible interaction and presentation, but must not invent or become sole owner of business, data, permission or algorithmic rules.
22
- - Candidates are ordinary external Source. They do not select themselves, become `exact-target`, create Design Authority or prove acceptance.
23
- - Do not install or persistently configure MCP, plugins, authentication or disclosure paths without separate authorization.
24
- - Do not create a resource pack, provider registry, workflow state, Contract artifact, acceptance record or parallel authority lifecycle.
25
-
26
- ## Read the references
27
-
28
- 1. Always read [resource-selection.md](references/resource-selection.md) before deciding what to generate or whether the request is style-bearing.
29
- 2. Read [open-design-provider.md](references/open-design-provider.md) before capability discovery, Design Authority gating, provider execution, implementation-source acquisition or recovery.
30
- 3. Read [downstream-handoff.md](references/downstream-handoff.md) before final selection, initial-proposal reconciliation, handoff or downstream use. A simple unselected non-fidelity preview may stop before this reference.
31
-
32
- ## Core workflow
33
-
34
- 1. **Fix the scope ceiling.** Name in-scope surfaces, flows, regions, component families, unique controls, conditions, necessary context, exclusions and whether the intent is exploration, handoff or selected-source preparation.
35
- 2. **Inventory inputs.** Accept initial proposals, notes, product/technical plans, visual briefs, screenshots, references and existing resources. Preserve each role as exact target, constraint, inspiration, current-implementation evidence or background; report unreadable/unused material.
36
- 3. **Classify visual-style dependency.** Mark the commission `style-bearing` when it materially expresses visual fidelity, brand, typography/color/density, component visual treatment or a production-style prototype. Mark it `non-fidelity` for IA/flow topology, low-fidelity structure, semantics-only behavior/state studies or an explicitly non-fidelity prototype. Mixed work is style-bearing unless split into an independent non-fidelity commission.
37
- 4. **Apply the conditional Design Authority gate.** For style-bearing work, read `DESIGN.md` and its token source. If authority is unconfigured, stop before project/run creation and tell the user to explicitly invoke `$design-system-authoring`; do not invoke it automatically. A combined explicit request authorizes running that Skill first and then resuming this one. Non-fidelity work remains allowed.
38
- 5. **Find design gaps.** For handoff, account for every in-scope observable design fact across structure, control/component anatomy and smaller primitives, content/visual treatment and exact style/layout values, states, interaction/feedback/motion, adaptation/input, accessibility and assets. Subtract only coverage explicitly supplied by selected Source; unsupported or unreadable facts remain blocking rather than silently absent.
39
- 6. **Discover live capabilities.** Inspect the current Open Design agent/model, skills, templates, design systems, plugins and export paths. Treat absent/non-enumerable capabilities honestly.
40
- 7. **Choose the minimum sufficient commission.** Give each considered resource `selected`, `optional`, `not-needed`, `unavailable` or `decision-required` with one reason. Ask only when a missing preference materially changes the commission.
41
- 8. **Bind and commission through Open Design.** For style-bearing work, create or verify the Open Design project with the adopted design-system ID and require `get_project.designSystemId` to match. Send a bounded product commission through structured MCP; use documented fallbacks only when required.
42
- 9. **Acquire a complete implementation source when applicable.** For Web/App implementation handoff, require Open Design to emit a canonical machine-readable entry plus the full declared dependency set—not only a screenshot or preview. Enumerate and retrieve every selected file without truncation, preserve exact bytes/digests, record one `implementation_web` or `implementation_app` source profile with `acquisition: complete`, and make all local HTML/CSS/JS dependencies resolve inside that frozen set. Non-Web resources use the bounded `reference` profile and are not forced into HTML.
43
- 10. **Observe, inspect and iterate.** Keep provider execution, artifact readiness and design suitability separate. Iterate within scope. Keep proposal effects only in the delta buffer while candidates remain unsettled.
44
- 11. **Finalize selection and reconcile once.** After explicit human selection or explicit delegated selection, preserve immutable identity and consolidate accepted, rejected and unresolved effects. Apply only accepted decisions once to a writable initial-proposal file; if it exists only in conversation, return one complete revised proposal. Preserve original intent/provenance and make reruns idempotent. Do not write unresolved or rejected choices as requirements.
45
- 12. **Compile the residual implementation handoff when requested.** For final selected resources intended for development, write one project-native Markdown Source at an authorized path. Preserve readable `ty-source-item` facts and exactly one fenced `design-resource-handoff-v1` YAML block. Keep exact code-expressible UI values in the canonical resources; atomically index every observable fact through typed, locally resolvable locators, close every resource as `material_with_facts` or honestly `supporting_only`, and add only scope, applicability, residual product meaning, explicit exclusions/unresolved items, blockers and downstream bindings. Close every applicable subject × target × condition × dimension cell and make its `fact_refs`, evidence, Source Items and verification methods exactly equal the indexed fact unions. Every exact target needs full-target `layout_geometry` and `visual_pixel` facts per condition; otherwise classify it as a partial constraint or unresolved. Run `ty-context design-resource preflight <handoff.md>`. Missing/unresolvable locators, partial dependency or resource-fact closure, `decision_required`/`unavailable`, stale digests and unsupported evidence are blocking. Do not create this file for exploration.
46
- 13. **Return an intent-sized result.** Exploration shows the artifact promptly. An implementation handoff returns the validated handoff path, selected immutable resources, stable-key coverage, provenance, binding, limitations and preflight result. Include the reconciled initial proposal or its updated path when final selection occurred.
47
-
48
- ## Conditional Design Authority gate
49
-
50
- Unconfigured means `DESIGN.md` is missing, explicitly says `Design authority status: unconfigured`, remains a starter, contains only style prose/inspiration, or lacks one authored exact-value token source/generation direction. This gate applies only to style-bearing resource authoring; it is not a general project-init gate and configured system-level authority does not by itself prove surface-level implementation readiness.
51
-
52
- The stop message must state:
53
-
54
- ```text
55
- Style-bearing design resources require an adopted project design system. Explicitly invoke $design-system-authoring to generate/select/adopt one, then resume $design-resource-authoring. I will not initialize it automatically.
56
- ```
57
-
58
- ## Initial-proposal reconciliation
59
-
60
- The normal design-first loop is:
61
-
62
- ```text
63
- initial proposal
64
- -> bounded Open Design candidates
65
- -> feedback and iteration with a task-local delta buffer
66
- -> explicit or delegated final selection
67
- -> one consolidated, idempotent initial-proposal reconciliation
68
- -> revised proposal + selected immutable resources
69
- + canonical source-rich resource set
70
- -> validated residual design-resource-handoff-v1 (implementation intent only)
71
- -> default Goal execution or long-task-workflow
72
- ```
73
-
74
- Small requests may complete generation, selection and reconciliation in one turn; the invariant is one final semantic writeback, not an artificial pause. Reconciliation may clarify product information, controls/states, interaction and visual constraints supported by the selected resource. It preserves original requirements and records selected resource keys/locators/digests without turning provider output into product authority. If selection never occurs, return candidates and the buffered delta only; do not rewrite.
75
-
76
- ## Stop and route elsewhere
77
-
78
- - Route explicit design-system initialization/adoption to `design-system-authoring`.
79
- - Route broader durable UI/UX authority repair during development to `context_uiux_design`.
80
- - Route ordinary implementation with sufficient authority to the default Workflow Contract and current native Goal.
81
- - Route a complete explicit Single-Goal delivery, using the revised proposal plus selected resources, to `long-task-workflow`.
82
- - If no new resource is justified, say so instead of generating filler.
83
-
84
- ## Completion response
85
-
86
- Report scope, necessary context/exclusions, style dependency and gate result; selected/omitted/unavailable resources; visible artifacts/typed locators; provider, project/run and design-system binding status; review and selection basis; immutable provenance; implementation source profile, entry/dependency closure and acquisition completeness when applicable; material applicability/coverage and unresolved decisions; proposal reconciliation status/path; and forbidden inferences. For implementation intent, report the residual `design-resource-handoff-v1` path and successful shared preflight; never call a failing or unresolved handoff ready.
19
+ - For a formal selected Web/App handoff, do not let initially generated output define its own obligation universe. Derive that universe before commissioning from scoped subjects, target conditions, subject-local variations and the atomic property catalog. A label such as `all-states`, one default page, representative screenshots, pairwise sampling or an Inspector `complete` Boolean cannot stand in for enumerated identities.
20
+ - Artifact grouping and exact-value ownership remain separate: one HTML/CSS/JS/JSON/SVG source set may carry thousands of atomic facts. Exact values stay in that canonical source; the manifest, residual handoff and downstream Contract preserve typed locators, digests, comparison authority and Fact identities rather than copying CSS into a second value owner.
21
+ - Never infer that a page frame or prototype covers states, responsiveness, accessibility or interaction it does not explicitly specify or demonstrate.
22
+ - Exploration and unselected previews stay schema-free. Only a final selected implementation handoff requires the shared strict Markdown adapter; this is input preparation, not a resource pack or acceptance result.
23
+ - Design resources may express user-visible interaction and presentation, but must not invent or become sole owner of business, data, permission or algorithmic rules.
24
+ - Candidates are ordinary external Source. They do not select themselves, become `exact-target`, create Design Authority or prove acceptance.
25
+ - Do not install or persistently configure MCP, plugins, authentication or disclosure paths without separate authorization.
26
+ - Do not create a resource pack, provider registry, workflow state, Contract artifact, acceptance record or parallel authority lifecycle.
27
+
28
+ ## Read the references
29
+
30
+ 1. Always read [resource-selection.md](references/resource-selection.md) before deciding what to generate or whether the request is style-bearing.
31
+ 2. Read [open-design-provider.md](references/open-design-provider.md) before capability discovery, Design Authority gating, provider execution, implementation-source acquisition or recovery.
32
+ 3. Read [downstream-handoff.md](references/downstream-handoff.md) before final selection, initial-proposal reconciliation, handoff or downstream use. A simple unselected non-fidelity preview may stop before this reference.
33
+
34
+ ## Core workflow
35
+
36
+ 1. **Fix the scope ceiling.** Name in-scope surfaces, flows, regions, component families, unique controls, conditions, necessary context, exclusions and whether the intent is exploration, handoff or selected-source preparation.
37
+ 2. **Inventory inputs.** Accept initial proposals, notes, product/technical plans, visual briefs, screenshots, references and existing resources. Preserve each role as exact target, constraint, inspiration, current-implementation evidence or background; report unreadable/unused material.
38
+ 3. **Classify visual-style dependency.** Mark the commission `style-bearing` when it materially expresses visual fidelity, brand, typography/color/density, component visual treatment or a production-style prototype. Mark it `non-fidelity` for IA/flow topology, low-fidelity structure, semantics-only behavior/state studies or an explicitly non-fidelity prototype. Mixed work is style-bearing unless split into an independent non-fidelity commission.
39
+ 4. **Apply the conditional Design Authority gate.** For style-bearing work, read `DESIGN.md` and its token source. If authority is unconfigured, stop before project/run creation and tell the user to explicitly invoke `$design-system-authoring`; do not invoke it automatically. A combined explicit request authorizes running that Skill first and then resuming this one. Non-fidelity work remains allowed.
40
+ 5. **Derive the authoring obligation universe before generation.** For a formal selected Web/App handoff, start from requested Surfaces/flows, product semantics, adopted design-system snapshot and target platforms—not from whatever a first render happens to contain. Enumerate stable subjects and hierarchy for every Surface, region, overlay/system UI, component family and instance, Control, Anatomy Part/slot, primitive, text, icon, media, asset and typed multi-subject relation. Explicitly disposition every standard condition axis—platform/OS/device/form factor, exact viewport, orientation, density, Safe Area, window/fold/display/color modes, locale/language/script/direction/pseudo-localization, content/data stress, text scale, input/assistive technology, motion/transparency/contrast/bold text/button shapes, system UI/IME, permission/capability/connectivity/lifecycle—plus scoped custom axes. For each subject enumerate `variant × state × interaction_phase × presence_phase × instance_case`, including compound precedence, conditional/lazy/virtualized/portal population and exact exclusions. Apply the standard atomic property catalog across geometry, layout/scroll, typography/color/decoration/content/icon/media, interaction/navigation/motion/feedback, responsive, accessibility, assets/system and relations; add inspector-declared custom properties without weakening the standard set. The Expected Fact Universe is the exact applicable `subject × target × condition × variation × property` cell set. Every cell is covered or has an exact source/basis-backed `not_applicable`/`excluded_by_scope`; `decision_required`/`unavailable` remains blocking. Continuous widths, text pressure and animation expose breakpoints/ranges/interpolation/reflow/timeline rules rather than only sampled snapshots. Never truncate, sample, summarize the remainder or let aggregate strings such as `all-states` impersonate atomic identities.
41
+ 6. **Discover live capabilities.** Inspect the current Open Design agent/model, skills, templates, design systems, plugins and export paths. Treat absent/non-enumerable capabilities honestly.
42
+ 7. **Choose the minimum sufficient commission.** Give each considered resource `selected`, `optional`, `not-needed`, `unavailable` or `decision-required` with one reason. Ask only when a missing preference materially changes the commission.
43
+ 8. **Bind and commission through Open Design.** For style-bearing work, create or verify the Open Design project with the adopted design-system ID and require `get_project.designSystemId` to match. Send the bounded product commission and the derived obligation universe through structured MCP: require the canonical implementation source to encode every applicable atomic value/behavior and require explicit dispositions for non-applicable, excluded or unresolved cells. Use documented fallbacks only when required; if the live provider cannot emit/read a required fact family, preserve that gap as blocking rather than silently narrowing the commission.
44
+ 9. **Acquire complete canonical source and its independent Fact manifest.** For Web/App implementation handoff, require Open Design to emit a canonical machine-readable entry, the full locally resolvable dependency set and one `design-resource-observable-fact-manifest-v1` inside that closure—not only a screenshot, preview or prose spec. The manifest freezes the design-system snapshot; exact Inspector identity/version/digest or named external TCB, capabilities, input paths/digests, complete enumeration and dynamic-discovery policy; addressable resource/node/declaration/token/asset/relation/variant/state/interaction/dynamic-population Census; all condition and variation axes/combinations; subject hierarchy; property catalog; Fact Cells/Facts; value and design-system lineage; evidence; Fact × required-method proof obligations; comparator/tolerance/mask, Oracle and render-environment authority; asset bindings; blockers; and non-sampling/non-truncating collection counts/digests. Enumerate and retrieve every selected file without truncation, preserve exact bytes/digests, record one `implementation_web` or `implementation_app` source profile with `acquisition: complete`, and make all local source, token, SVG, font, image, media, worker and asset dependencies resolve inside that frozen set. Non-Web resources use the bounded `reference` profile and are not forced into HTML.
45
+ 10. **Inspect, compare and iterate to exact closure.** Run the frozen Inspector over the frozen canonical entry/dependencies. Require every Census item to map to Facts/Fact Cells or a source/basis-backed `non_material` disposition, and require the manifest Fact universe to equal the precommission Expected Fact Universe. Exercise every required verification method with its method-compatible evidence, comparator, Oracle and environment; preserve design-system token/override/conflict lineage and exact asset consumers. Iterate the provider until `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts` can hold. Keep provider execution, artifact readiness and design suitability separate, and keep proposal effects only in the delta buffer while candidates remain unsettled.
46
+ 11. **Finalize selection and reconcile once.** After explicit human selection or explicit delegated selection, preserve immutable identity and consolidate accepted, rejected and unresolved effects. Apply only accepted decisions once to a writable initial-proposal file; if it exists only in conversation, return one complete revised proposal. Preserve original intent/provenance and make reruns idempotent. Do not write unresolved or rejected choices as requirements.
47
+ 12. **Compile the residual implementation handoff when requested.** For final selected resources intended for development, write one project-native Markdown Source at an authorized path. Preserve readable `ty-source-item` facts and exactly one fenced `design-resource-handoff-v1` YAML block. Keep exact code-expressible UI values in canonical resources; project their stable identities through typed, locally resolvable located digests instead of copying values into a second authority. The residual block must be exactly equal to the target manifest for axes/exclusions/conditions, subjects, variations, properties, lineage, Fact Cells/Facts, evidence, proof obligations, Oracles, environments, asset bindings and blockers. Each covered Fact Cell binds one Fact; each Fact binds its atomic subject/target/condition/variation/property, value kind, sensitivity, value/lineage/evidence/Source; each required method has its own proof obligation with comparator parameters, exact/tolerance mode, optional authoritative mask, Oracle and environment. Close every resource as `material_with_facts` or honestly `supporting_only`; extend roll-up coverage to exact `subject/target/condition/variation/property/fact-cell/fact/proof` sets. Every exact target needs full-target `layout_geometry` and `visual_pixel` Facts per condition. Run `ty-context design-resource preflight <handoff.md>`. Any mismatch with the manifest/Expected Universe, ambiguous profile key, unenumerated Census item, missing standard axis/property/method, aggregate identity, sampling/truncation, unresolved locator/dependency/lineage/conflict, unsafe sensitive observation, `decision_required`/`unavailable`, blocker, stale digest or unsupported evidence blocks `ready`. Do not create this file for exploration.
48
+ 13. **Return an intent-sized result.** Exploration shows the artifact promptly. An implementation handoff returns the validated handoff path, selected immutable resources, stable-key coverage, provenance, binding, limitations and preflight result. Include the reconciled initial proposal or its updated path when final selection occurred.
49
+
50
+ ## Conditional Design Authority gate
51
+
52
+ Unconfigured means `DESIGN.md` is missing, explicitly says `Design authority status: unconfigured`, remains a starter, contains only style prose/inspiration, or lacks one authored exact-value token source/generation direction. This gate applies only to style-bearing resource authoring; it is not a general project-init gate and configured system-level authority does not by itself prove surface-level implementation readiness.
53
+
54
+ The stop message must state:
55
+
56
+ ```text
57
+ Style-bearing design resources require an adopted project design system. Explicitly invoke $design-system-authoring to generate/select/adopt one, then resume $design-resource-authoring. I will not initialize it automatically.
58
+ ```
59
+
60
+ ## Initial-proposal reconciliation
61
+
62
+ The normal design-first loop is:
63
+
64
+ ```text
65
+ initial proposal
66
+ -> bounded Open Design candidates
67
+ -> feedback and iteration with a task-local delta buffer
68
+ -> explicit or delegated final selection
69
+ -> one consolidated, idempotent initial-proposal reconciliation
70
+ -> revised proposal + selected immutable resources
71
+ + canonical source-rich resource set
72
+ -> validated residual design-resource-handoff-v1 (implementation intent only)
73
+ -> default Goal execution or long-task-workflow
74
+ ```
75
+
76
+ Small requests may complete generation, selection and reconciliation in one turn; the invariant is one final semantic writeback, not an artificial pause. Reconciliation may clarify product information, controls/states, interaction and visual constraints supported by the selected resource. It preserves original requirements and records selected resource keys/locators/digests without turning provider output into product authority. If selection never occurs, return candidates and the buffered delta only; do not rewrite.
77
+
78
+ ## Stop and route elsewhere
79
+
80
+ - Route explicit design-system initialization/adoption to `design-system-authoring`.
81
+ - Route broader durable UI/UX authority repair during development to `context_uiux_design`.
82
+ - Route ordinary implementation with sufficient authority to the default Workflow Contract and current native Goal.
83
+ - Route a complete explicit Single-Goal delivery, using the revised proposal plus selected resources, to `long-task-workflow`.
84
+ - If no new resource is justified, say so instead of generating filler.
85
+
86
+ ## Completion response
87
+
88
+ Report scope, necessary context/exclusions, style dependency and gate result; selected/omitted/unavailable resources; visible artifacts/typed locators; provider, project/run and design-system binding status; review and selection basis; immutable provenance; implementation source profile, entry/dependency closure and acquisition completeness when applicable; material applicability/coverage and unresolved decisions; proposal reconciliation status/path; and forbidden inferences. For implementation intent, report the residual `design-resource-handoff-v1` path and successful shared preflight; never call a failing or unresolved handoff ready.
@@ -1,77 +1,85 @@
1
- # Design Resource Handoff And Proposal Reconciliation
1
+ # Design Resource Handoff And Proposal Reconciliation
2
+
3
+ Generated resources remain ordinary external Source. Preserve enough identity and meaning for downstream work without creating a Tiny Context pack, registry or authority lifecycle.
4
+
5
+ ## Candidate, selection and authority are separate
6
+
7
+ - **Candidate:** provider output proposed for review; it authorizes no fidelity.
8
+ - **Selection:** an explicit user/team choice, or explicit delegation with known criteria; it permits proposal reconciliation and selected-source preparation.
9
+ - **Authority adoption:** a downstream development workflow reconciles selected Source with product/surface Context and `DESIGN.md` and binds implementation/verification to declared conditions.
10
+
11
+ This Skill may preserve an input already classified as `exact-target`; it may not promote its own candidate to one. Unknown coverage remains unknown.
12
+
13
+ ## Development-scope coverage
14
+
15
+ For every material in-scope surface/flow/region/component/control condition, record selected existing Source, newly generated Source, `not-applicable`, `excluded-by-scope`, `decision-required` or `unavailable`. Include only necessary surrounding context and explicit exclusions. One larger addressable artifact may cover several items; a static frame covers only conditions it actually shows.
16
+
17
+ Design resources may show user-visible triggers, transitions, states, feedback and product-rule presentation. Business, data, permission and algorithmic rules remain owned by product/technical Source and must not be invented by visuals.
18
+
19
+ Canonical implementation resources own exact code-expressible layout, visual, content, state, interaction, adaptation, motion, semantic and asset values. The structured handoff is the residual semantic and index layer for scope, applicability and downstream binding: it projects every observable Fact through typed located digests, records complete inspection/proof closure and is not a second numeric/style source. Product Controls remain semantic interaction units and do not cap Fact granularity; addressable images, text, icons, component instances and Anatomy Parts, smaller primitives, relations, geometry/style/token/content/state/behavior facts remain independently queryable. For a formal selected Web/App target, completeness is:
2
20
 
3
- Generated resources remain ordinary external Source. Preserve enough identity and meaning for downstream work without creating a Tiny Context pack, registry or authority lifecycle.
4
-
5
- ## Candidate, selection and authority are separate
6
-
7
- - **Candidate:** provider output proposed for review; it authorizes no fidelity.
8
- - **Selection:** an explicit user/team choice, or explicit delegation with known criteria; it permits proposal reconciliation and selected-source preparation.
9
- - **Authority adoption:** a downstream development workflow reconciles selected Source with product/surface Context and `DESIGN.md` and binds implementation/verification to declared conditions.
10
-
11
- This Skill may preserve an input already classified as `exact-target`; it may not promote its own candidate to one. Unknown coverage remains unknown.
12
-
13
- ## Development-scope coverage
14
-
15
- For every material in-scope surface/flow/region/component/control condition, record selected existing Source, newly generated Source, `not-applicable`, `excluded-by-scope`, `decision-required` or `unavailable`. Include only necessary surrounding context and explicit exclusions. One larger addressable artifact may cover several items; a static frame covers only conditions it actually shows.
16
-
17
- Design resources may show user-visible triggers, transitions, states, feedback and product-rule presentation. Business, data, permission and algorithmic rules remain owned by product/technical Source and must not be invented by visuals.
18
-
19
- Canonical implementation resources own exact code-expressible layout, visual, content, state, interaction, adaptation, motion, semantic and asset facts. The structured handoff is the residual semantic and index layer for scope, applicability and downstream binding: it atomically indexes every observable fact through typed locators, records a complete inspection closure for every resource instead of manually duplicating values, and is not a second numeric/style source. Product Controls remain semantic interaction units and do not cap fact granularity; addressable images, text, icons, component parts, smaller primitives, geometry/style/token/state/behavior facts are indexed when expressed.
20
-
21
- ## Final proposal reconciliation
22
-
23
- Keep a task-local buffer during candidate iteration:
24
-
25
- ```yaml
26
- selection_basis: explicit user/team choice | explicit delegated selection
27
- selected_resources:
28
- - stable key, provider/project/run/entry, declared conditions, immutable digest/snapshot, editable upstream owner/locator/update method
29
- accepted:
30
- - decision, rationale and affected proposal section/stable keys
31
- rejected:
32
- - alternative and reason
33
- unresolved:
34
- - genuine remaining choice
35
- impacts:
36
- product_rules: []
37
- information_hierarchy: []
38
- surface_keys: []
39
- control_keys: []
40
- state_keys: []
41
- interaction_rules: []
42
- visual_constraints: []
43
- ```
44
-
45
- This is an explanatory shape, not a schema or required file. Do not write during iteration. Once the direction is final:
46
-
47
- 1. confirm the selection basis and immutable resource identity;
48
- 2. consolidate duplicate/intermediate notes;
49
- 3. apply accepted decisions once while preserving all unaffected original requirements and source provenance;
50
- 4. exclude rejected and unresolved choices from requirements, keeping unresolved items visibly unresolved;
51
- 5. record selected resource keys, conditions, immutable locators/digests and editable upstream owner/locator/update method in the proposal where downstream consumers can recover and later change them;
52
- 6. make reruns idempotent—update the existing decision/reference instead of appending it again;
53
- 7. if the initial proposal has an authorized writable path, edit that file; otherwise return the full revised proposal in the response.
54
-
55
- Never mutate a Source Plan, `project_context/**`, `DESIGN.md`, Delivery Contract, production code or tests. A small request may generate, select and reconcile in one turn; “once” describes final semantic writeback, not a required waiting phase.
56
-
57
- If no selection occurs, return candidates plus a consolidated pending delta and leave the proposal unchanged.
58
-
59
- ## Intent-sized handoff
60
-
61
- ### Exploration
62
-
63
- Return scope/intent, visible candidates, resource dispositions, obvious limitations, provider/artifact qualifiers and the sanity review performed. Do not require a pack, hash or validator for a throwaway unselected preview unless retrieval needs it.
64
-
65
- ### Implementation handoff
66
-
67
- After final selection for implementation, add one project-native Markdown Source at an authorized repository path. It is ordinary Source, not a pack or Authority. Frozen canonical resources carry addressable implementation facts, while this residual handoff closes scope, applicability, uncovered meaning, product/technical semantics, blockers and downstream bindings. The file contains readable `ty-source-item:start/end` facts plus exactly one:
68
-
69
- ````markdown
70
- ```yaml design-resource-handoff-v1
71
- ...
21
+ ```text
22
+ Expected Fact Universe
23
+ = Canonical Resource Facts enumerated by the frozen Inspector
24
+ = Handoff Indexed Facts
72
25
  ```
73
- ````
74
26
 
27
+ The Expected Universe is derived before generation from scoped requirements, product semantics, the adopted design system, target environments, stable subjects, condition axes, subject-local variation axes and the atomic property catalog. It is not whatever an initially generated default page happens to expose.
28
+
29
+ ## Final proposal reconciliation
30
+
31
+ Keep a task-local buffer during candidate iteration:
32
+
33
+ ```yaml
34
+ selection_basis: explicit user/team choice | explicit delegated selection
35
+ selected_resources:
36
+ - stable key, provider/project/run/entry, declared conditions, immutable digest/snapshot, editable upstream owner/locator/update method
37
+ accepted:
38
+ - decision, rationale and affected proposal section/stable keys
39
+ rejected:
40
+ - alternative and reason
41
+ unresolved:
42
+ - genuine remaining choice
43
+ impacts:
44
+ product_rules: []
45
+ information_hierarchy: []
46
+ surface_keys: []
47
+ control_keys: []
48
+ state_keys: []
49
+ interaction_rules: []
50
+ visual_constraints: []
51
+ ```
52
+
53
+ This is an explanatory shape, not a schema or required file. Do not write during iteration. Once the direction is final:
54
+
55
+ 1. confirm the selection basis and immutable resource identity;
56
+ 2. consolidate duplicate/intermediate notes;
57
+ 3. apply accepted decisions once while preserving all unaffected original requirements and source provenance;
58
+ 4. exclude rejected and unresolved choices from requirements, keeping unresolved items visibly unresolved;
59
+ 5. record selected resource keys, conditions, immutable locators/digests and editable upstream owner/locator/update method in the proposal where downstream consumers can recover and later change them;
60
+ 6. make reruns idempotent—update the existing decision/reference instead of appending it again;
61
+ 7. if the initial proposal has an authorized writable path, edit that file; otherwise return the full revised proposal in the response.
62
+
63
+ Never mutate a Source Plan, `project_context/**`, `DESIGN.md`, Delivery Contract, production code or tests. A small request may generate, select and reconcile in one turn; “once” describes final semantic writeback, not a required waiting phase.
64
+
65
+ If no selection occurs, return candidates plus a consolidated pending delta and leave the proposal unchanged.
66
+
67
+ ## Intent-sized handoff
68
+
69
+ ### Exploration
70
+
71
+ Return scope/intent, visible candidates, resource dispositions, obvious limitations, provider/artifact qualifiers and the sanity review performed. Do not require a pack, hash or validator for a throwaway unselected preview unless retrieval needs it.
72
+
73
+ ### Implementation handoff
74
+
75
+ After final selection for implementation, add one project-native Markdown Source at an authorized repository path. It is ordinary Source, not a pack or Authority. Frozen canonical resources carry addressable implementation facts, while this residual handoff closes scope, applicability, uncovered meaning, product/technical semantics, blockers and downstream bindings. The file contains readable `ty-source-item:start/end` facts plus exactly one:
76
+
77
+ ````markdown
78
+ ```yaml design-resource-handoff-v1
79
+ ...
80
+ ```
81
+ ````
82
+
75
83
  The strict block includes:
76
84
 
77
85
  - output/development scope, necessary context and exclusions;
@@ -79,61 +87,68 @@ The strict block includes:
79
87
  - selected exact-target/constraint/supporting classification; candidates and inspiration do not enter covered implementation rows;
80
88
  - provider version, project/run, capability/template, agent/model and live design-system binding;
81
89
  - each repository-local immutable resource path, media type and exact SHA-256;
82
- - for implementation Web/App targets, a canonical entry, complete declared dependency set and `acquisition: complete`; non-Web resources use `reference` and are not forced into HTML;
90
+ - for implementation Web/App targets, a canonical entry, complete locally resolvable dependency set, one canonical `design-resource-observable-fact-manifest-v1` inside that set and `acquisition: complete`; non-Web resources use `reference` and are not forced into HTML;
83
91
  - editable upstream owner, locator and update/export method, or an explicit manual/external-update boundary when unavailable;
84
- - declared platform, viewport, mode, state, content, input and full/reduced/not-applicable motion conditions;
85
- - typed, locally resolvable evidence locators (`html_selector`, `markdown_anchor`, `json_pointer`, `css_selector`, `css_custom_property` or bounded `whole_resource`) whose kinds distinguish frame/component variant/prototype state or transition/motion/responsive/input/accessibility/semantic/token/asset/annotation meaning;
86
- - atomic `facts`, each naming exactly one subject, target, condition, dimension, `subject|full_target` observation scope, same-target/same-condition evidence set, Source-item set and verification method;
87
- - exactly one `resource_fact_closure` entry per resource with a named complete inspector, rationale and either `material_with_facts` plus the exact fact set or `supporting_only` plus no facts;
88
- - stable subjects grouped only when they truly share meaning;
89
- - every declared scope surface represented by one unambiguous surface subject, with no stable key owned by two subjects;
90
- - explicit target applicability for each subject and complete subject × target × condition × dimension coverage for `surface_flow`, `visual_content`, `component_control`, `state_interaction`, `motion`, `adaptation_input`, `accessibility` and `assets`;
91
- - exactly one disposition per applicable cell: `covered`, `not_applicable`, `excluded_by_scope`, `decision_required` or `unavailable`;
92
- - covered-cell `fact_refs`, same-target/same-condition evidence, Source-item refs and dimension-appropriate project verification methods, each set exactly equal to the union of its facts; every fact appears in exactly one coverage row, and referenced design Source Items use `requirement`, `control` or `acceptance` markers;
92
+ - a frozen Inspector identity/version/digest or named external TCB; exact capabilities, canonical entry, all input resource paths/digests, `complete_enumeration`, fully enumerated dynamic discovery and an addressable Census of every material resource/node/declaration/token/asset/relation/custom property/variant/state/interaction phase/dynamic population item;
93
+ - each Census row bound to exact Fact/Fact Cell sets or a source/basis-backed `non_material` rationale. An Inspector `complete` Boolean, resource count or provider statement does not replace the Census;
94
+ - all 33 standard target-condition axes—platform, OS, device profile, form factor, exact viewport width/height, orientation, density/pixel ratio, Safe Area insets, window/fold/display/color modes, locale/language/script/direction/pseudo-localization, content/data stress, text scale/multiplier, input/assistive technology, motion/transparency/contrast/bold text/button shapes, system UI/IME, permission/capability/connectivity/lifecycle—plus scoped custom axes. Each has an explicit applicable/not-applicable disposition and stable values; reuse of one viewport/density/Safe-Area/text-scale key with conflicting geometry is invalid;
95
+ - the complete target-condition Cartesian universe, with every applicable combination present and every omitted combination carrying an exact source/basis-backed exclusion. Continuous viewport/text-pressure behavior additionally exposes exact breakpoints, ranges, interpolation and reflow rules;
96
+ - stable subjects for every in-scope Surface, flow, region, overlay/system UI, component family and instance, Control, Anatomy Part/slot, primitive, text, icon, media, asset and typed multi-subject relation; exact parent/instance/family/override/slot/portal/presence/population/Census lineage prevents a family or one rendered instance from hiding internal or repeated subjects;
97
+ - for every subject, explicit `variant`, `state`, `interaction_phase`, `presence_phase` and `instance_case` axis dispositions plus the complete compound variation universe and exact exclusions. Labels such as `all-21-state-catalog` cannot impersonate 21 atomic states;
98
+ - the complete standard atomic property catalog plus justified inspector-declared custom properties. Properties carry stable key, family, UI/UX dimension, typed value kind, required verification methods, Inspector capabilities and Census lineage. The eight dimensions—`surface_flow`, `visual_content`, `component_control`, `state_interaction`, `motion`, `adaptation_input`, `accessibility`, `assets`—remain reporting roll-ups, not the Fact ceiling;
99
+ - one explicit Fact Cell for every applicable `subject × target × condition × variation × property` identity. Every cell is `covered`, source/basis-backed `not_applicable`/`excluded_by_scope`, or blocking `decision_required`/`unavailable`; sampling, pairwise coverage, summaries and implicit defaults are forbidden;
100
+ - one atomic Fact for every covered cell, carrying exactly one subject/target/condition/variation/property, dimension, `subject|full_target` observation scope, `plain|protected` sensitivity, typed value kind, canonical value located digest, same-target/condition evidence, Source-item lineage and effective design-system lineage. Exact token/alias/platform/mode/state/instance overrides and resolved conflicts remain traceable;
101
+ - typed, locally resolvable value/evidence locators for HTML/CSS/JS/JSON/Markdown/SVG or bounded binary whole-resource identity. Critical values cannot live only in a bitmap, preview or prose. Exact values stay in canonical resources; the handoff preserves locator/digest identity rather than copying CSS;
102
+ - separate `proof_obligations` for every Fact × property-required verification method. Each names method-compatible evidence, comparator, exact/tolerance mode, canonical parameter/tolerance and optional narrow mask located digests, one frozen executable or named external Oracle with method capability, and one frozen render environment. A Fact needing token and pixel proof keeps both;
103
+ - exact asset bindings to asset subjects, immutable resources, target/condition Facts and consumer subjects, including density/platform/theme/mode/locale variants, crop/focal/mask/placeholder/error/decode/fallback behavior;
104
+ - generation metadata proving `complete_explicit`, `sampling: forbidden`, `truncation: forbidden`, contiguous chunk indexes, and exact count plus identity digest for every Inspector input/Census, axis, condition, subject, variation, property, lineage, Fact Cell/Fact, evidence/proof, Oracle/environment, asset and blocker collection;
105
+ - exact manifest↔handoff row/set equality for every projected collection, so the residual handoff cannot certify its own narrower universe;
106
+ - exactly one `resource_fact_closure` entry per resource with named complete inspection, rationale and either `material_with_facts` plus the exact Fact set or honestly `supporting_only` plus no Facts;
107
+ - roll-up coverage whose subject/target/condition/variation/property/Fact Cell/Fact/proof/evidence/Source/method sets exactly equal their indexed unions; every Fact Cell, Fact and proof appears exactly once in coverage;
93
108
  - for every `exact_target` condition, one `full_target` `layout_geometry` fact and one `full_target` `visual_pixel` fact backed by exact-target evidence; if complete visible fidelity cannot be extracted/compared, keep the resource a `constraint` or unresolved;
94
- - source-backed rationales for non-applicable/excluded rows; unresolved rows remain visible and make preflight fail;
109
+ - source/Inspector-backed rationales for every non-applicable/excluded cell; unresolved rows remain visible and make preflight fail;
95
110
  - target-local acceptance blockers with exact target/subject/dimension/Source-item/verification-method lineage and a non-empty `required_capabilities` set; use the narrowest truthful capability such as physical device, sensor, camera, orientation, haptic, screen reader, pixel-density, safe-area, input or production runtime rather than weakening it to an available proxy;
96
111
  - selection basis, proposal reconciliation path/status and known limitations;
97
112
  - outer review and separate provider/artifact/design qualifiers.
98
113
 
99
- Unknown fields fail closed. Every resource must be inspected; a material resource cannot be hidden as `supporting_only`, and unsupported/unreadable extraction remains blocking inside the named inspector/oracle TCB. A static frame may support only visible layout/visual/component facts for its shown condition; pixel evidence cannot cover unseen interaction, motion, adaptation/input or accessibility. Run:
100
-
101
- ```text
102
- ty-context design-resource preflight <handoff.md>
103
- ```
104
-
105
- Do not call the handoff ready until it passes. Exploration, candidates and unselected previews still require no file, schema, hash sequence or validator. There is no fixed directory or one-file-per-control requirement.
106
-
107
- ## Recommended downstream routing
108
-
109
- ```text
110
- initial proposal
111
- -> design-resource-authoring
112
- -> selected immutable resources
113
- + complete canonical implementation resources
114
- + reconciled initial proposal
115
- -> validated residual design-resource-handoff-v1
116
- -> long-task-workflow (explicit long delivery)
117
- OR current native Goal + default Workflow Contract (non-long delivery)
118
- ```
119
-
120
- `source-plan-authoring` is not an intermediate stage. A legacy Source Plan remains valid ordinary Source if supplied, but design-resource authoring never creates or edits one.
121
-
122
- ### Default Workflow consumption
123
-
124
- The consuming Goal brings the revised proposal, selected resources and residual handoff as ordinary Source. It reruns shared preflight before UI Authority Closure, opens affected exact/constraint resources before deciding, classifies coverage, decides `Context Delta`, and makes every adopted decision-relevant target Context-reachable through existing owners. It routes every fact, covered Source Item and verification method through the production owner and real-entry checks. Any unread, unsupported, unmapped, unimplemented, unverified or indistinguishable applicable fact blocks the complete claim. A later update creates a new immutable version rather than overwriting the adopted baseline.
125
-
126
- ### Long-Task consumption
127
-
128
- The same revised proposal, selected resources and validated residual handoff enter `long-task-workflow`'s Source-bound Contract Draft loop immediately. The marked handoff is `task.source_paths`; each Contract design target's frozen `source_paths` and Check `verification_inputs` equal that handoff plus every declared resource path and condition. Covered Source Items map through `source_claims` to the root conformance Assertion. Every verification method maps to an independently failing Assertion carrying its relevant Source Claims; each method × condition evidence cell carries the exact handoff `fact_refs`, the union equals the target fact set, and current typed `design_method` evidence repeats the exact set. Every blocker preserves its Source-item/method/required-capability lineage into a machine Claim proved on the exact capability-qualified target or a target-blocking External Confirmation. Authority Lock, Authority Revision and Final Gate remain the sole lifecycle. This Skill creates no Contract Draft, Outcome, Receipt, Check result or Gate.
129
-
130
- ## Forbidden inferences
131
-
132
- Unless independently proven downstream, never infer that a generated resource:
133
-
134
- - is selected, authoritative or accepted;
135
- - covers unlisted states, viewports, modes, platforms or accessibility;
136
- - is native implementation because an HTML/image preview renders;
137
- - is complete because a preview, URL, metadata response, file hash or provider run exists; implementation handoff requires the declared entry/dependency closure and resolvable evidence;
138
- - changed Context, `DESIGN.md`, a Source Plan, code or Contract;
139
- - proves production fidelity, correctness, test completion or release readiness.
114
+ Unknown fields fail closed. Every resource must be inspected; a material resource cannot be hidden as `supporting_only`, and unsupported/unreadable extraction remains blocking inside the named Inspector/Oracle TCB. All `decision_required`, `unavailable` and acceptance blockers prevent a `ready` result. A static frame may support only visible layout/visual/component Facts for its shown condition; pixel evidence cannot cover unseen interaction, motion, adaptation/input or accessibility. Protected Facts retain canonical-source ownership while downstream observations use attributable digest-only or redacted representations and never persist raw sensitive values. Run:
115
+
116
+ ```text
117
+ ty-context design-resource preflight <handoff.md>
118
+ ```
119
+
120
+ Do not call the handoff ready until it passes. Passing proves acquisition, integrity and exact declared-universe closure relative to the frozen Inspector/Oracle TCB; it does not prove production implementation conformance. Exploration, candidates and unselected previews still require no file, schema, hash sequence or validator. There is no fixed directory, one-file-per-Control or one-file-per-Fact requirement.
121
+
122
+ ## Recommended downstream routing
123
+
124
+ ```text
125
+ initial proposal
126
+ -> design-resource-authoring
127
+ -> selected immutable resources
128
+ + complete canonical implementation resources
129
+ + reconciled initial proposal
130
+ -> validated residual design-resource-handoff-v1
131
+ -> long-task-workflow (explicit long delivery)
132
+ OR current native Goal + default Workflow Contract (non-long delivery)
133
+ ```
134
+
135
+ `source-plan-authoring` is not an intermediate stage. A legacy Source Plan remains valid ordinary Source if supplied, but design-resource authoring never creates or edits one.
136
+
137
+ ### Default Workflow consumption
138
+
139
+ The consuming Goal brings the revised proposal, selected resources and residual handoff as ordinary Source. It reruns shared preflight before UI Authority Closure, opens affected exact/constraint resources before deciding, classifies coverage, decides `Context Delta`, and makes every adopted decision-relevant target Context-reachable through existing owners. It keeps one ephemeral exact accounting of every Fact Cell, Fact and Fact × method obligation; routes each through the production owner and real-entry check; compares the current candidate with the frozen expected locator/digest using the declared comparator/tolerance/mask, Oracle and environment; and retains an attributable per-Fact actual observation and pass/fail verdict. Any unread, unsupported, unmapped, unimplemented, unverified, stale, failed or indistinguishable applicable Fact blocks the complete claim. A later update creates a new immutable version rather than overwriting the adopted baseline.
140
+
141
+ ### Long-Task consumption
142
+
143
+ The same revised proposal, selected resources and validated residual handoff enter `long-task-workflow`'s Source-bound Contract Draft loop immediately. The marked handoff is `task.source_paths`; each Contract design target's frozen `source_paths` and Check `verification_inputs` equal that handoff plus every declared resource path and condition. Covered Source Items map through `source_claims` to the root conformance Assertion. Every verification method maps to an independently failing Assertion carrying its relevant Source Claims; each method × condition evidence cell carries exact handoff `fact_refs` plus canonical `fact_expectations` for subject/variation/property, sensitivity, expected located digest, comparator/parameters/tolerance/mask, Oracle and environment. Their exact union equals the target Fact set and all property-required Fact × method obligations. Current typed `design_method` evidence repeats the exact Fact set and supplies one `fact_results` row per Fact: attributable actual observation and actual environment, comparison record, exact authority identities and pass/fail verdict. Protected observations are digest-only/redacted according to the frozen sensitivity policy. Missing, extra, duplicate, stale, failed, authority-drifted or reused/indistinguishable rows fail the Assertion. Every blocker preserves its Source-item/method/required-capability lineage into a machine Claim proved on the exact capability-qualified target or a target-blocking External Confirmation. Authority Lock, Authority Revision and Final Gate remain the sole lifecycle and Final Gate source-recompiles/reruns the whole current snapshot. This Skill creates no Contract Draft, Outcome, Receipt, Check result or Gate.
144
+
145
+ ## Forbidden inferences
146
+
147
+ Unless independently proven downstream, never infer that a generated resource:
148
+
149
+ - is selected, authoritative or accepted;
150
+ - covers unlisted states, viewports, modes, platforms or accessibility;
151
+ - is native implementation because an HTML/image preview renders;
152
+ - is complete because a preview, URL, metadata response, file hash or provider run exists; implementation handoff requires the declared entry/dependency closure and resolvable evidence;
153
+ - changed Context, `DESIGN.md`, a Source Plan, code or Contract;
154
+ - proves production fidelity, correctness, test completion or release readiness.